RFC4740 日本語訳
4740 Diameter Session Initiation Protocol (SIP) Application. M.Garcia-Martin, Ed., M. Belinchon, M. Pallares-Lopez, C.Canales-Valenzuela, K. Tammi. November 2006. (Format: TXT=174175 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
エド、ワーキンググループのM.ガルシア-マーチンをネットワークでつないでください。コメントのために以下を要求してください。 4740年のノキアカテゴリ: 標準化過程M.Belinchon M.Pallares-ロペスC.カナレス-バレンズエラエリクソンK.Tammiノキア2006年11月
Diameter Session Initiation Protocol (SIP) Application
直径セッション開始プロトコル(一口)アプリケーション
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(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 Session Initiationプロトコル(SIP)アプリケーションを指定します。 これはDiameterクライアントが認証と承認情報を要求できるDiameterアプリケーションです。 このアプリケーションは、SIPに関連して使用されるように設計されていて、SIPサーバで共同見つけられたDiameterクライアントを提供します、Diameterサーバからユーザの認証とSIPリソース用法の承認を要求する能力で。
Garcia-Martin, et al. Standards Track [Page 1] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[1ページ]。
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
1. 序論…4 2. 用語…5 3. 定義…5 4. 頭文字語…6 5. 適用性声明…6 6. 操作の概要…7 6.1. 一般アーキテクチャ…7 6.2. 直径サーバはユーザを認証します…9 6.3. 最終的な認証を代表として派遣して、一口サーバにチェックしてください…12 6.4. サーバ要求認証と承認をちびちび飲んでください…15 6.5. 一口要求の受取人の居場所を見つけます…16 6.6. ユーザ・プロファイルのアップデート…17 6.7. 軟性国家終了をちびちび飲んでください…18 6.8. 直径サーバ発見…19 7. 広告アプリケーションサポート…21 8. 直径一口アプリケーションコマンドコード…22 8.1. ユーザ承認要求(UAR)は命令します…22 8.2. ユーザ承認答え(UAA)は命令します…23 8.3. サーバ課題要求(SAR)は命令します…27 8.4. サーバ課題答え(SAA)命令…29 8.5. 位置のインフォメーション要求(LIR)は命令します…33 8.6. 位置のインフォメーション答え(LIA)は命令します…33 8.7. Authが要求するマルチメディア(3月)は命令します…35 8.8. マルチメディアAuth答え(MAA)は命令します…36 8.9. 登録終了要求(RTR)は命令します…39 8.10. 登録終了答え(RTA)は命令します…39 8.11. プッシュプロフィール要求(PPR)は命令します…41 8.12. プッシュプロフィール答え(PPA)は命令します…42 9. 直径一口アプリケーションAVPs…44 9.1. 一口課金情報AVP…46 9.1.1. 一口会計サーバURI AVP…47 9.1.2. 一口クレジットコントロールサーバURI AVP…47 9.2. 一口サーバURI AVP…47 9.3. 一口サーバ能力AVP…47 9.3.1. 一口の義務的な能力AVP…48 9.3.2. 一口の任意の能力AVP…48 9.4. 一口サーバ課題タイプAVP…48 9.5. 一口Authデータ項目AVP…50 9.5.1. 一口認証体系AVP…50 9.5.2. 一口商品番号AVP…51 9.5.3. AVPを一口認証してください…51 9.5.4. 一口承認AVP…52 9.5.5. 一口認証インフォメーションAVP…52 9.5.6. AVPsを読みこなしてください…53 9.6. 一口数のAuthの品目AVP…55
Garcia-Martin, et al. Standards Track [Page 2] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[2ページ]。
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
9.7. 一口Deregistration理由AVP…55 9.7.1. 一口理由コードAVP…55 9.7.2. 一口理由インフォメーションAVP…56 9.8. 一口AOR AVP…56 9.9. 一口の訪問されたネットワークイドAVP…56 9.10. 一口ユーザ承認タイプAVP…56 9.11. ユーザデータ型であるとサポートされた一口AVP…57 9.12. 一口利用者データAVP…57 9.12.1. 一口ユーザデータ型AVP…58 9.12.2. 一口ユーザデータコンテンツAVP…58 9.13. 既に利用可能な一口ユーザデータAVP…58 9.14. 一口メソッドAVP…59 10. 既存のAVPsのための新しい値…59 10.1. 結果コードAVP値への拡大…59 10.1.1. 成功結果コードAVP値…59 10.1.2. AVPが評価する一時障害結果コード…60 10.1.3. AVPが評価する永久的な失敗結果コード…60 11. 認証の詳細…61 12. 半径からの移行…63 12.1. 半径クライアントから直径サーバまでのゲートウェイ…63 12.2. 直径クライアントから半径サーバまでのゲートウェイ…63 12.3. 制限を知っています…64 13. IANA問題…64 13.1. アプリケーション識別子…64 13.2. コマンドコード…65 13.3. AVPコード…65 13.4. 結果コードAVP価値のための追加値…65 13.5. AAAにおける一口サーバ課題タイプ部の創設…66 13.6. AAAにおける一口認証体系部の創設…66 13.7. AAA登録の一口理由コード部の創設…66 13.8. AAAにおける一口ユーザ承認タイプ部の創設…66 13.9. 中の既に利用可能な一口ユーザデータ部の創設、…66 14. セキュリティ問題…67 14.1. 直径クライアント/一口サーバにおける最終的な認証チェック…67 15. 貢献者…68 16. 承認…68 17. 参照…68 17.1. 標準の参照…68 17.2. 有益な参照…69
Garcia-Martin, et al. Standards Track [Page 3] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[3ページ]。
1. Introduction
1. 序論
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 Session Initiationプロトコル(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サービスの用法を認可するためにAuthentication、Authorization、およびAccounting(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 Network Access Server[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手順に従ったそれらのリンケージに関する何らかの指導と共に有益な記述を読者に提供します。
Garcia-Martin, et al. Standards Track [Page 4] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[4ページ]。
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-コードAttribute値の組(AVP)を広げています。 詳細はセクション10で説明されます。
This application defines some new AVPs. All these AVPs are described in Section 9.
このアプリケーションはいくつかの新しいAVPsを定義します。 これらのすべてのAVPsがセクション9で説明されます。
Some extra information about authentication is provided in Section 11.
認証に関する何らかのその他の情報をセクション11に提供します。
2. Terminology
2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「お勧めでなく」て「推薦され」て、「5月」の、そして、「任意」のNOTがこと解釈されるのは中でBCP14について説明しました、RFC2119[RFC2119]であり、対応する実装のために要件レベルを示すべきであるかをさせましょう。
3. Definitions
3. 定義
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:
RFC3261[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 Outboundプロキシo Proxy o Registrar o Server(SIPサーバ)o Userエージェント(UA)o UserエージェントClient(UAC)o UserエージェントServer(UAS)
For the purpose of this document, the following terms and definitions given in RFC 3588 [RFC3588] Section 1.3, apply:
RFC3588[RFC3588]部1.3で与えられた以下のこのドキュメント、用語、および定義の目的には、申し込んでください:
Garcia-Martin, et al. Standards Track [Page 5] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[5ページ]。
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 Authentication oはPair(AVP)o Diameter Client o Diameter Server oホームのRealm o Redirectエージェントo UserをAttribute評価します。
4. Acronyms
4. 頭文字語
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
別名: 認証と主要な協定LIR: 位置のインフォメーション要求LIA: 位置のインフォメーション答え3月: Authが要求するマルチメディアMAA: マルチメディアAuth答えPPR: プッシュプロフィール要求PPA: プッシュプロフィール答えRTR: 登録終了要求RTA: 登録終了答えSAR: サーバ課題要求SAA: サーバ課題答えSL: 加入者ロケータUAR: ユーザ承認要求UAA: ユーザ承認答え
5. Applicability Statement
5. 適用性証明
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.
このドキュメントはホームRealmがDiameterかSIPが機能であると実装する1つ以上のノードで構成される一般的なアーキテクチャを仮定します。 ユーザはSIPリソースにアクセスするという要求をSIPに出しています。 それぞれの特定のユーザのために、ホームRealmはそれらのリソース、そして/または、ルートの使用法を適切なノードに認証して、認可する必要があります。 私たちは、ユーザ関連のデータを含むデータベースが承認を必要とするSIPノードの外に位置していると思います。 異なったユーザのものであるデータはホームRealmの異なったノードに保存されるかもしれませんが、私たちは、特定のユーザに伝えるすべてのデータがただ一つのノードに保存されると思います。
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.
以下に注意してください。 アーキテクチャに主要であるのは、利用者データが1ポイントにネットワークで保存されるという事実です。 この制限は特定の実装を強制しません、例えば、冗長を提供するために鏡のモードで作動するデータベースのクラスタを実装するのが可能です。 この仕様によって必要とされた特性はDiameterサーバが近づく手段を持っている利用者データが見られるもので安全に保存されるということです、外部の観点から、シングルユーザーデータベースとして。
Garcia-Martin, et al. Standards Track [Page 6] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[6ページ]。
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.
このドキュメントはホームRealmのいくつかの構成を許します。 1つの構成では、サービスの引き金となって、実行する目的のために、SIPサーバ(プロキシ、記録係など)をユーザに割り当てます。 例えば、ユーザがネットワークで登録するとき、ダイナミックにSIPサーバの配分をするかもしれません。 この構成はユーザのために別の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 Userエージェントに構成されます(この仕様の範囲の外の手段で)。 SIPの外国行きのプロキシノードの外国行きのDiameterクライアントは、ユーザを認証して、SIP要求のために承認を要求して、会計活動を実行します。
6. Overview of Operation
6. 操作の概要
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.
このセクションはSIPと共にDiameter SIPアプリケーションをどう使用できるかに関する有益な記述を提供します。 このセクションがDiameter SIPアプリケーションのどんな特定の用法も強制することを意図しないで、またそれはSIPとDiameterメッセージの間の特定のマッピングを強制しません。 私たちはどうSIPに関連して必要なAAAの機能性を達成できるかを示している例の収集を提供します。
6.1. General Architecture
6.1. 一般アーキテクチャ
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.
AAAインフラストラクチャへのインタフェースがSIPリソースの用法を認証して、認可するのに必要であるSIP環境でDiameter SIPアプリケーションを使用できます。 このアプリケーションはSIP[RFC3261]によって強制された認証機構であるHTTP Digest認証[RFC2617]を実装して、使用するSIP Userエージェントとプロキシのサポートを提供します。 アプリケーションは広げることができます、そして、起こるとき、必要性が起こるなら、他の認証機構か拡大のサポートをHTTP Digest認証に提供するのは拡張できます。
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は以下にAAAアーキテクチャによるSIPアーキテクチャの統合の概要を示しています。
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によると、SIPトラフィックを開始するか、または終える1人以上のSIP Userエージェント(UAs)が1つ以上のSIPサーバを通しています。 両方のSIPサーバはDiameterがこの仕様で説明されたアプリケーションであるとサポートするDiameterクライアントを実装します。
Garcia-Martin, et al. Standards Track [Page 7] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[7ページ]。
+--------+
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 |
+--------+
+--------+ UAR/UAA+--->|直径| <、-、-、--+ PPR/PPA LIR/ライア| | サーバ| | 3月/MAA| +--------+ | SAR/SAA| | RTR/RTA| | v対+------+ 一口+--------+ 一口+--------+ 一口+------+ | 一口| <、-、-、-、-、-、-、-、--、>| 一口| <、-、-、-、-、-、-、--、>| 一口| <、-、-、-、-、-、-、-、--、>| 一口| | Ua| |サーバ1| |サーバ2| | Ua| +------+ +--------+ +--------+ +------+ ^ ^ UAR/UAA | | LIR/ライア| | 3月/MAA| +--------+ | SAR/SAA+--->|直径| <、-、-、--+ | 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が異なったDiameterコマンドを送って、SIPサーバ2によって送られて、受け取られたものと異なった応答を受けるのを見ることができます。 主なタスクはこれが図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(図1に従って)の収集を提供できる特徴のサポートを提供します。 ユーザが初めていったん登録すると、これらのSIPサーバの1つは選択されます、そして、ユーザに伝えるすべてのSIP要求が同じSIPサーバによって処理されます。
Garcia-Martin, et al. Standards Track [Page 8] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[8ページ]。
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 Subscriber Locator(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.
以下の小区分は合図するSIPとのDiameter SIPアプリケーション、コマンド、および可能な相互作用の有益な概要を提供します。
6.2. Diameter Server Authenticates the User
6.2. 直径サーバはユーザを認証します。
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要求の認証も要求するかもしれません。
Garcia-Martin, et al. Standards Track [Page 9] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[9ページ]。
+--------+ +--------+ +--------+
| 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 |
| |------------------>|
| | |
+--------+ +--------+ +--------+ | 一口| |直径| | 一口| |サーバ1| | サーバ| |サーバ2| +--------+ +--------+ +--------+ | | | 1. 一口レジスタ| | | -------------------->| 2. UAR| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| 3. UAA| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| 4. 一口レジスタ| |-------------------------------------->| | | 5. 3月| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| 6. MAA| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| 7. 一口401(権限のない)| 8. 一口401(Unauth。) |<--------------------------------------| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| 9. 一口レジスタ| | | -------------------->| 10. UAR| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| 11. UAA| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| 12. 一口レジスタ| |-------------------------------------->| | | 13. 3月| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| 14. MAA| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| 15. 一口200(OK)| 16. 一口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
図2によると、SIP UserエージェントClient(UAC)はSIP REGISTER要求(ステップ1)をSIPサーバ1に送ります。(それは、SIP要求を受け取ります)。 図2では、私たちは、このSIPサーバが管理ホームドメインの縁に位置していると思います。 SIPサーバ1のDiameterクライアントはこのユーザが受信できるかどうか決定するDiameter User承認要求(UAR)メッセージ(ステップ2)を送るのが修理して、そうだとすれば要求するDiameterサーバに連絡します。
Garcia-Martin, et al. Standards Track [Page 10] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[10ページ]。
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.
このユーザを扱うことができるローカルのSIPサーバのアドレス。 DiameterサーバにDiameter User承認答え(UAA)メッセージ(ステップ3)で答えます。(それは、SIPサーバ1がSIPサーバ2を示す適切なSIPサーバ(SIPサーバ2)、そして/または、SIPかSIPS URIを選択するのに使用するかもしれない能力のリストを示します)。
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サーバ(SIPサーバ2)にSIP REGISTER要求(ステップ4)を転送します。 そして、SIPサーバ2のDiameterクライアントは、DiameterサーバからDiameter Multimedia-Auth-要求(3月)メッセージ(ステップ5)を送ることによって、ユーザー認証を要求します。 また、この要求は、DiameterサーバをSIPサーバ2のSIPかSIPS URIを意識するようにするのに役立ちます、同じユーザを求めるその後の要求を同じSIPサーバ2に返すために。 DiameterサーバはAVPが値のDIAMETER_MULTI_に設定するResult-コードROUND_AUTHと共にDiameter Multimedia-Auth-答え(MAA)メッセージ(ステップ6)で反応します。 Diameterサーバは、また、一回だけを生成して、MAAメッセージに挑戦を含んでいます。 SIPサーバ2が写像するその挑戦を使用する、ヘッダーをWWW認証してください、SIP401の(権限のない)の応答(ステップ7)(ステップ8)で。(それは、SIPサーバ1と、そして、そして、SIP UACに返送されます)。
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はユーザ資格証明書(ステップ9)を含む次のSIP REGISTER要求を受け取ります。 SIPサーバ1が状態を維持する必要はないことに注意してください。そうすれば、さらにも、SIPが同じSIPサーバ1に到着するよう要求する保証が全くありません。 冗長構成で作動するSIPサーバ1の農場があるかもしれません。 ユーザに割り当てられたSIPサーバを決定するDiameter UARメッセージ(ステップ10)を送ることによって、SIPサーバ1のDiameterクライアントはDiameterサーバに連絡します。 DiameterサーバはDiameter UAAメッセージ(ステップ11)のSIPサーバ2のSIPかSIPS URIを送ります。
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サーバ2(ステップ12)にSIP REGISTER要求を転送します。 SIPサーバ2はSIP REGISTER要求から資格証明書を抽出します。 SIPサーバ2のDiameterクライアントはDiameter3月のメッセージ(ステップ13)でそれらの資格証明書をDiameterサーバに送ります。ここに、Diameterサーバはユーザ、および成功、リターンのAVP Result-コードセットがあるDiameter MAAメッセージ(ステップ14)を値のDIAMETER_SUCCESSに認証できます。
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は、結局、SIP200(OK)が応答(ステップ15)であるとSIP UAC(ステップ16)に生成します。(それは、SIPサーバ1に送られます)。
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
SIPサーバ2のDiameterクライアントがユーザプロフィール情報をダウンロードするのに関心がなければならないか、またはDiameterサーバのSIPサーバのアドレスを保存しなければならないなら、DiameterクライアントはDiameter SARメッセージ(ステップ17)をDiameterサーバに送ります。そしてDiameterサーバが要求されたユーザプロフィール情報を含むDiameter SAAメッセージ(ステップ18)で返答する。
Garcia-Martin, et al. Standards Track [Page 11] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[11ページ]。
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サーバアドレスストレージの承認。 SIPサーバが役立たれたユーザに対するサービスを提供するのに使用されるユーザ・プロファイルを検索しなければならない、さもなければ、SIPサーバがユーザのために状態を維持するとこれらの動作が必要であるので、Diameterサーバは、SIPサーバのアドレスを保存する必要があります。
6.3. Delegating Final Authentication Check to the SIP Server
6.3. 最終的な認証を代表として派遣して、一口サーバにチェックしてください。
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サーバの間の周遊旅行の数を最小にしたがっているかもしれません。私たちは、メカニズムのためにどこが最終的な認証がSIPサーバにチェックするDiameterサーバ代表であるかとサポートして、その結果、周遊旅行を貯蓄しながら、前提とします。 セクション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サーバがDiameterクライアントにそれを送る前にH(A1)を計算するためには一回だけのクライアントを必要とするので。 しかしながら、クライアント一回だけはその時、利用可能でないかもしれません。
Garcia-Martin, et al. Standards Track [Page 12] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[12ページ]。
+--------+ +--------+ +--------+
| 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) |<--------------------------------------|
<--------------------| | |
| | |
+--------+ +--------+ +--------+ | 一口| |直径| | 一口| |サーバ1| | サーバ| |サーバ2| +--------+ +--------+ +--------+ | | | 1. 一口レジスタ| | | -------------------->| 2. UAR| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| 3. UAA| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| 4. 一口レジスタ| |-------------------------------------->| | | 5. 3月| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| 6. MAA| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| 7. 一口401(権限のない)| 8. 一口401(Unauth。) |<--------------------------------------| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| 9. 一口レジスタ| | | -------------------->| 10. UAR| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| 11. UAA| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| 12. 一口レジスタ| |-------------------------------------->| | | 13. SAR| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| 14. SAA| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| 15. 一口200(OK)| 16. 一口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は、SIPサーバがDiameterサーバのサポートをSIP Userエージェントに供給するためにダイナミックにどこに割り当てられるかを例に示します。これはあるアーキテクチャのそうであるかもしれません、第3Generation Partnership Project(3GPP)IP Multimedia Core Network Subsystemのものなどのように。
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
最初のSIPサーバは目標がホームネットワークドメインであるSIP REGISTER要求(ステップ1)を受け取ります。 図3では、私たちは、このSIPサーバが管理ホームドメインの縁に位置していると思います。 登録で続かせるaを送るのによるDiameterサーバからのこのSIPサーバ要求承認におけるDiameterクライアント
Garcia-Martin, et al. Standards Track [Page 13] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[13ページ]。
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.
直径User承認要求(UAR)メッセージ(ステップ2)。 メッセージは他のAttribute値のペア(AVPs)にSIP REGISTER要求に含まれている記録のSIP Address(AOR)を含んでいます。 Diameterサーバは、SIP AORについて確かめて、それがホームネットワークで有効な定義されたユーザであるなら登録が続くのを認可します。 DiameterサーバはDiameter User承認答え(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サーバ(SIPサーバ2)にSIP REGISTER要求(ステップ4)を転送します。 SIPサーバ2のDiameterクライアントは、Diameter Multimedia-Auth-要求(3月)メッセージ(ステップ5)をDiameterサーバに送ることによって、認証パラメタを要求します。また、この要求で、DiameterサーバはSIPサーバ2のSIPかSIPS URIを意識するようになります、同じユーザのその後の要求を同じSIPサーバ2に返すために。 DiameterサーバはDiameter Multimedia-Auth-答え(MAA)メッセージ(ステップ6)で反応します。(それは、一回だけとユーザに関連している指定された認証アルゴリズムに必要なパラメタのすべての残りを含んでいます)。 特に、MAAメッセージはH(A1)(RFC2617[RFC2617]で定義されるように)を含んで、Diameterクライアントが予想された応答について計算するのを許容するDigest-HA1 AVPを含んでいます。 そして、DiameterクライアントはSIP UAから送られた挑戦への応答とこの予想された応答を比べることができます。 MAAのDigest-HA1 AVPの不在は、認証と承認がDiameterサーバで行われるのを示します、セクション6.2で説明されたシナリオに従って。
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).
MAAメッセージに挑戦に基づいたSIP応答(ステップ7)を含んでいて、SIPサーバ2は(権限のない)でSIP401を作成します、適切な資格証明書を含むようにSIP UserエージェントClient(UAC)によって必要とされた認証の材料を含んでいて。 SIPサーバ1はSIP UAC(ステップ8)へのSIP応答を進めます。
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はユーザ資格証明書(ステップ9)を含む次のSIP REGISTER要求を受け取ります。 SIPサーバ1が状態を維持する必要はないので(SIPが同じSIPサーバ1に到着するよう要求する保証が全くありません)、ユーザに割り当てられたSIPサーバを決定するDiameter UARメッセージ(ステップ10)を送ることによって、SIPサーバ1のDiameterクライアントは再びDiameterサーバに連絡します。 DiameterサーバはDiameter UAAメッセージ(ステップ11)のSIPサーバ2のSIPかSIPS URIを送ります。
Garcia-Martin, et al. Standards Track [Page 14] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[14ページ]。
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サーバ2(ステップ12)にSIP REGISTER要求を転送します。 SIPサーバ2は、SIPサーバ2(Diameterサーバから受け取られたH(A1)に基づいています)によって計算される予想された応答にSIP UAによって供給された応答をたとえることによって、資格証明書を有効にします。
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 Server課題要求(SAR)メッセージ(ステップ13)は認証手順の完成を確認して、現在ユーザに役立っているSIPサーバのSIPかSIPS URIを確認するようDiameterサーバに要求します。 また、Diameter SARメッセージはDiameterサーバがSIPサーバにユーザ・プロファイルを送るよう要求する目的に役立ちます。DiameterサーバはDiameter Server課題答え(SAA)メッセージ(ステップ14)で反応します。 Result-コードAVP価値が誤りについてSIP Server2に知らせないなら、SAAメッセージがゼロを含むことができますか、またはSIPサーバ2が、必要があるという情報を含むより多くのSIPユーザデータAVPsがユーザに対するサービスを提供します。
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は、結局、SIP200(OK)が応答(ステップ15)であるとSIP UAC(ステップ16)に生成します。(それは、SIPサーバ1に送られます)。
6.4. SIP Server Requests Authentication and Authorization
6.4. 一口サーバ要求認証と承認
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プロキシがDiameterサーバに認証情報と承認を要求する典型的なシナリオについて表現します、SIP Userエージェントに対するルーティングサービスをSIPに供給する目的のために。 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
図4によると、SIP Userエージェントは外国行きのSIPプロキシサーバにSIP要求を送ります。この場合、メッセージはSIP INVITE要求(ステップ1を見る)ですが、それはいかなる他のSIP要求であるかもしれません。 私たちは、このSIP要求がこのときどんな資格証明書も含まないと思います。 外国行きのSIPプロキシサーバは、ユーザに提供された代理業務を認証して、認可する必要があります。 SIPサーバのDiameterクライアントはMultimedia-Auth-要求(3月)メッセージ(ステップ2)を送ります。 Diameterサーバは、一回だけを生成して、一回だけを含んでいるMultimedia-Auth-答え(MAA)メッセージ(ステップ3)とSIPサーバがユーザに挑戦するのに必要なデータの残りを送ります、通常、HTTP Digest AuthenticationがMAAメッセージで示されている状態で。 このデータは、SIPサーバが挑戦を含むSIP407(プロキシAuthentication Required)応答(ステップ4)を作成するのを可能にします。 SIP UAは資格証明書を含む新しいINVITE要求(ステップ5)を作成します。 SIPサーバのDiameterクライアントは新しいDiameter3月のメッセージ(ステップ6)のDiameterサーバに資格証明書を送ります。 そしてDiameterサーバが資格証明書を有効にする。
Garcia-Martin, et al. Standards Track [Page 15] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[15ページ]。
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.
Diameter MAAメッセージ(ステップ7)のSIPトランザクションを認可してください。 SIPサーバは通常のSIP手順に従って目的地(ステップ8)にSIP INVITE要求を転送します。 結局、セッションセットアップはSIP UA(ステップ10)に送られるSIP200(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) |<----------------
<-----------------------------------|
| |
+--------+ +--------+ |直径| | 一口| | サーバ| | サーバ| +--------+ +--------+ | | | | 1. 一口招待| ----------------------------------->|、| 2. 3月| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| 3. MAA| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| 4. 一口407(プロキシ| 認証が必要です)| <-----------------------------------| | | 5. 一口招待| ----------------------------------->|、| 6. 3月| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| 7. MAA| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 8. 一口招待| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| 9. 一口200(OK。)10 一口200(OK)| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- <-----------------------------------| | |
Figure 4: SIP server requests authorization
図4: SIPサーバ要求承認
6.5. Locating the Recipient of the SIP Request
6.5. 一口要求の受取人の居場所を見つけます。
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
図5は、SIPサーバ1がSIP縁のプロキシサーバ(ネットワークの縁の処理SIPトラフィック)としてどこで構成されるかもしれないかをシナリオに示します。 SIPサーバ1はSIP INVITE要求(ステップ1)を受け取ります。 SIPサーバ1は、SIP要求の受取人に役立っているSIPサーバ2のアドレスを見つける必要があります。 SIPサーバ1のDiameterクライアントはDiameter Locationインフォメーション要求(LIR)メッセージ(ステップ2)をDiameterサーバに送ります。またはDiameterサーバがSIPを含むDiameter Locationインフォメーション答え(LIA)メッセージ(ステップ3)で反応する。
Garcia-Martin, et al. Standards Track [Page 16] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[16ページ]。
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).
SIPサーバ2のSIPS URI。 そして、SIPサーバ1はSIPサーバ2(ステップ4)にSIP INVITEを送ります。 SIPサーバ2は結局、適切なUAS(ステップ5)にSIP INVITEを送ります。
+--------+ +--------+ +--------+
| SIP | |Diameter| | SIP |
|server 1| | server | |server 2|
+--------+ +--------+ +--------+
| | |
1. SIP INVITE | | |
-------------->| 2. LIR | |
|---------------->| |
| 3. LIA | |
|<----------------| |
| 4. SIP INVITE |
|--------------------------------->|
| | | 5. SIP INVITE
| | |-------------->
| | |
| | |
+--------+ +--------+ +--------+ | 一口| |直径| | 一口| |サーバ1| | サーバ| |サーバ2| +--------+ +--------+ +--------+ | | | 1. 一口招待| | | -------------->| 2. LIR| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| 3. ライア| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| 4. 一口招待| |--------------------------------->| | | | 5. 一口招待| | |、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、|
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(登録、OPTIONSなどの)以外のどんなSIP要求も同じDiameterメッセージの引き金となるでしょう。 (SIP REGISTER要求は図2と図3にみられるように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に写像されます。
6.6. Update of the User Profile
6.6. ユーザ・プロファイルのアップデート
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
そのようなユーザ・プロファイルのアップデートがあるときはいつも、DiameterサーバがSIPサーバにユーザ・プロファイルを非同期にダウンロードするように、Diameter SIPアプリケーションはメカニズムを提供します。 また、DiameterサーバがDiameter Server課題答え(SAA)メッセージにユーザ・プロファイルを添付することに注意しなければなりません。 毎日の状況の大部分に、これは有効です。 しかしながら、管理者は、特定のユーザのためにユーザ・プロファイルをアップデートするか、または変更すると決めるかもしれません、当然です、例えばユーザにとって利用可能にされた新種業務。 これは人間などのこの仕様の範囲の外でメカニズムにかかわるかもしれません。
Garcia-Martin, et al. Standards Track [Page 17] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[17ページ]。
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サーバにおける介入. この状況で、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サーバはそのユーザ(例のSIPサーバ2)に割り当てられたSIPサーバでDiameter Pushプロフィール要求(PPR)メッセージ(ステップ1)をDiameterクライアントに送ります。 Diameter PPRメッセージは1SIPユーザデータAVPsかUser-名前AVPとゼロか、より多くのSIP-AOR AVPsを含んでいます。 SIPサーバ2のDiameterクライアントは、Diameter Pushプロフィール答え(PPA)メッセージ(ステップ2)をDiameterサーバに送ることによって、Diameter PPRメッセージを承認します。
+--------+ +--------+
|Diameter| | SIP |
| server | |server 2|
+--------+ +--------+
| |
| 1. PPR |
|------------------>|
| |
| 2. PPA |
|<------------------|
| |
+--------+ +--------+ |直径| | 一口| | サーバ| |サーバ2| +--------+ +--------+ | | | 1. PPR| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 2. PPA| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|
Figure 6: Diameter server pushes an update of the user profile
図6: 直径サーバはユーザ・プロファイルのアップデートを押します。
6.7. SIP Soft State Termination
6.7. 一口軟性国家終了
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サーバは、SIP軟性国家に写像するメカニズムとしてDiameterユーザセッションを使用するかどうか決めます。 Diameterサーバが、Diameterユーザセッションを使用すると決めるなら、Diameterユーザセッションの終了は対応するSIP軟性国家(例えば、登録、イベント購読)の終了を含意します、逆もまた同様に。 DiameterサーバがDiameterユーザセッションを使用しないなら、このDiameter SIPアプリケーションはSIP軟性国家を管理する特定のコマンドを提供します。 この仕様による対応することの実装はセッション管理の両方のメカニズムをサポートしなければなりません。
Garcia-Martin, et al. Standards Track [Page 18] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[18ページ]。
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セッションが使用されているかどうかによって、以下のメソッドの1つで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セッション州のAVPは以前に、_いいえ_州MAINTAINEDに用意ができていました)、DiameterクライアントはAVP(セクション9.4)が反登録値のいずれにも設定するSIPサーバ課題タイプでServer課題要求(SAR)メッセージを送らなければなりません: _ユーザ_DEREGISTRATION_店_サーバ_が、タイムアウト_DEREGISTRATION、ユーザ_DEREGISTRATION、タイムアウト_DEREGISTRATION_が_サーバ_名前を保存すると命名して、管理_が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セッション州のAVPは以前に、_州MAINTAINEDに用意ができていました)、RFC3588[RFC3588]に応じて、Diameterクライアントは通常の手順に従ってSession終了要求(STR)メッセージを送らなければなりません。
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セッション州のAVPは以前に、_いいえ_州MAINTAINEDに用意ができていました)、DiameterサーバはRegistration終了要求(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セッション州のAVPは以前に、_州MAINTAINEDに用意ができていました)、RFC3588[RFC3588]に応じて、Diameterサーバは通常の手順に従ってAbortセッション要求(ASR)メッセージを送らなければなりません。
6.8. Diameter Server Discovery
6.8. 直径サーバ発見
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サーバで保存されるということです。一般的な見解とは逆に、これは1ポイントの失敗を作成しません。 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
大きいネットワークには、Diameterサーバの数をスケーリングする必要があるかもしれません。そこでは、ユーザの数がかなり大きいかもしれません。 ユーザに関連しているすべてのデータが1Diameterにまだ保存されています。
Garcia-Martin, et al. Standards Track [Page 19] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[19ページ]。
server (typically, operating in a redundant configuration), but the data associated with different users may reside in different Diameter servers.
サーバ(通常冗長構成における作動)、しかし、異なったユーザに関連しているデータは異なった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のためのデータを保存しています。 私たちはRFC3588[RFC3588]で指定されたDiameterリダイレクションメカニズムからのインスピレーションに関するこの問題を解決します。 私たちはアーキテクチャでこのドキュメントの目的のためにDiameter Subscriber Locator(SL)として知られている新しいDiameterノードを入れます。 Diameter SLはDiameterサーバURIにSIP AORsを写像するデータベースか経路指定テーブルを含んでいます。 特定のDiameterサーバURIは特定のSIP AOR、および結果で話されたすべてのデータを保存する実際のDiameterサーバを示します、SIP AORを所有しているユーザに。 Diameter SLはDiameter Redirectエージェントへの同様の方法で行動します、Diameter要求(例えば、リダイレクションURIを答えに提供する)を派遣して。 Diameter SLはユーザへの値があるRedirectホスト用法AVPを設定するのによるすべての_USERを関係させるすべての要求を向け直すことができます、RFC3588[RFC3588]で指定されるように。
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 SLsの向こう側に一貫していなければなりません、等しいDiameter要求が等しいDiameter答えを起こすように、どのDiameter SLが要求を処理しても。
+--------+ +--------+ +--------+ +--------+
| 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
| | | | ------------->
| | | |
+--------+ +--------+ +--------+ +--------+ | 一口| |直径| |直径| | 一口| |サーバ1| |SL赤。 | |サーバ1| |サーバ2| +--------+ +--------+ +--------+ +--------+ | | | | 1. 一口招待| | | | ------------>| 2. LIR| | | |、-、-、-、-、-、-、-、-、--、>|、|、|、| 3. ライア| | | | <、-、-、-、-、-、-、-、-、--、|、|、|、| 4. LIR| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| 5. ライア| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| 6. 一口招待| | |----------------------------------->| 7. 一口招待| | | | ------------->|、|、|、|
Figure 7: Locating a Diameter server. SL redirecting requests
図7: Diameterサーバ要求を向け直すSLの場所を見つけます。
Garcia-Martin, et al. Standards Track [Page 20] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[20ページ]。
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 SLsのいずれにも送ります。 DiameterクライアントでそれらのSLsのアドレスがあらかじめ食糧を供給されると思われます。 SIP-AOR AVPとそれ自身の経路指定テーブルのコンテンツに基づくDiameter SLはそのようなユーザに割り当てられた情報を保存するDiameterサーバを決定します。 そして、それは値がそのようなユーザに伝える情報を保存するDiameterサーバのURIに設定されるAVPがDIAMETER_に設定するResult-コードREDIRECT_INDICATIONと1Redirect-ホストAVPを含んでいるDiameter LIAメッセージ(ステップ3)を築き上げます。 そして、SIPサーバ1のDiameterクライアントはRedirect-ホストAVPに受け取られたDiameterサーバに扱われた新しいLIRメッセージ(ステップ4)を築き上げます。 手順の残りは前項で説明されるように完成します。
7. Advertising Application Support
7. 広告アプリケーションサポート
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).
この仕様に従う直径実装はCapabilities交換要求(CER)とCapabilities交換答え(CEA)命令にAuthアプリケーションイドAVPを含んでいることによって、サポートの広告を出さなければなりません、Diameterベースプロトコルによると、RFC3588[RFC3588。] このAuthアプリケーションイドAVP MUST、このDiameter SIPアプリケーションの値に設定されてください(セクション13.1はIANAによって割り当てられた実価を示します)。
Garcia-Martin, et al. Standards Track [Page 21] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[21ページ]。
8. Diameter SIP Application Command Codes
8. 直径一口アプリケーションコマンドコード
All the Diameter implementations conforming to this specification MUST implement and support the list of Diameter commands listed in Table 1.
この仕様に従うすべてのDiameter実装が、Table1に記載された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 | +-------------------------------------+-------+------+--------------+
+-------------------------------------+-------+------+--------------+ | コマンド名| Abbr。 | コード| 参照| +-------------------------------------+-------+------+--------------+ | ユーザ承認要求| UAR| 283 | セクション8.1| | ユーザ承認答え| UAA| 283 | セクション8.2| | サーバ課題要求| SAR| 284 | セクション8.3| | サーバ課題答え| SAA| 284 | セクション8.4| | 位置のインフォメーション要求| LIR| 285 | セクション8.5| | 位置のインフォメーション答え| ライア| 285 | セクション8.6| | Authが要求するマルチメディア| 3月| 286 | セクション8.7| | マルチメディアAuth答え| MAA| 286 | セクション8.8| | 登録終了要求| RTR| 287 | セクション8.9| | 登録終了答え| RTA| 287 | セクション8.10| | プッシュプロフィール要求| PPR| 288 | セクション8.11| | プッシュプロフィール答え| PPA| 288 | セクション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].
コマンドを定義するセクションがその特定のコマンドのためのMessage Formatを含みます。 本書では含まれていたMessage FormatsはRFC3588[RFC3588]のセクション3.2に従って定義されます。
8.1. User-Authorization-Request (UAR) Command
8.1. ユーザ承認要求(UAR)命令
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承認要求(UAR)は283へのCommand-コードセットによって示されました、そして、Command Flags'R'のビットはセットしました。 SIPサーバのDiameterクライアントは、SIP UserエージェントがSIP REGISTER要求を発送するように承認を要求するためにこのコマンドをDiameterサーバに送ります。 SIP REGISTER要求がそれとなく連絡先にAORを縛る許可を運ぶので、Diameterクライアントは登録を認可するのに最初の承認要求としてDiameterサーバに向かってDiameter UARを使用します。 例えば、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).
可能な値の1つのSIPサーバ要求承認におけるDiameterクライアントはSIPユーザ承認タイプAVPで(セクション9.10)を定義しました。
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
ユーザの認証に使用されるユーザ名はUser-名前AVP(Diameterベースプロトコル、RFC3588[RFC3588]では、定義される)で伝えられます。 SIPの認証ユーザ名の位置
Garcia-Martin, et al. Standards Track [Page 22] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[22ページ]。
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要求は異なります。 認証機構がRFC2617[RFC2617]で定義されるようにHTTP Digestであるときに、認証ユーザ名はSIP Authorizationヘッダーフィールド価値の「ユーザ名」指示で見つけられます。 このDiameter SIPアプリケーションはSIPでのHTTP Digest認証のサポートを提供するだけです。 他の認証機構は現在、サポートされません。
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がネットワークイドを訪問しているAVPはSIP Userエージェントに対するサービス(例えば、SIPプロキシの機能性かいかなる他の種類のサービス)をSIPに供給しているネットワークを示します。
The Message Format of the UAR command is as follows:
UARコマンドのMessage Formatは以下の通りです:
<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 ]
<UAR>:、:= <直径ヘッダー: 283 REQ、PXY><セッションイド>AuthアプリケーションイドAuthセッション州の発生源ホスト発生源分野目的地分野一口AOR[あて先ホスト][ユーザ名][一口はネットワークイドを訪問しました][一口ユーザ承認タイプ]*[プロキシインフォメーション]*[ルート記録的な]*[AVP]
8.2. User-Authorization-Answer (UAA) Command
8.2. ユーザ承認答え(UAA)命令
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承認答え(UAA)は283へのCommand-コードセットときれいにされたCommand Flagsの'R'ビットによって示されます。 Diameterサーバは以前に受信されたDiameter User承認要求(UAR)命令に対応してこのコマンドを送ります。 Diameterサーバは要求された登録承認の結果を示します。 さらに、DiameterサーバはDiameterクライアントが登録中にAORのSIPプロキシを選ぶのを補助するSIP能力の収集を示すかもしれません。
Garcia-Martin, et al. Standards Track [Page 23] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[23ページ]。
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.
RFC3588[RFC3588]で既に定義された値に加えて、Result-コード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-名前AVP価値を必要としますが、Diameter UARメッセージがUser-名前AVP価値を含まなかったなら、Diameterサーバは、DIAMETER_USER_NAME_REQUIRED(セクション10.1.2を見る)にResult-コードAVP価値を設定して、Diameter UAAメッセージでそれを返さなければなりません。 DIAMETER_USER_NAME_REQUIREDへのResult-コードAVP選択値群があるこのDiameter UAAメッセージのレセプションでは、SIPサーバは、SIP401(権限のない)かSIP407(プロキシAuthentication Required)に創始者への応答を送ることによって、認証を通常要求します。
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サーバは(1) 既にユーザ名に割り当てられた、SIPサーバのアドレス、(2) ユーザのために別のSIPサーバを選択するためにSIPサーバ(直径クライアント)によって必要とされた能力、または(3) 前の2つのオプションの組み合わせを含まなければならないUser承認答え(UAA)メッセージを構成します。
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.
User-名前AVPがDiameter UARメッセージに存在しているなら、Diameterサーバは分野のユーザの存在について確かめなければなりません、すなわち、User-名前AVP価値がその分野の中の正規ユーザーです。 DiameterサーバがUser-名前AVPで受け取られたユーザ名を認識しないなら、Diameterサーバは、Diameter User承認答え(UAA)メッセージを築き上げなければならなくて、DIAMETER_ERROR_USER_UNKNOWNにResult-コードAVPを設定しなければなりません。
Garcia-Martin, et al. Standards Track [Page 24] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[24ページ]。
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.
User-名前AVPがDiameter UARメッセージに存在しているなら、SIP-AOR AVPにSIPかSIPS URIを含んでいる場合、DiameterサーバはAVP値が登録できるそのUser-名前を認可しなければなりません。 この承認が失敗するなら、Diameterサーバは、DIAMETER_ERROR_IDENTITIES_ドント_MATCHにResult-コードAVPを設定して、Diameter User承認答え(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.
以下に注意してください。 User-名前とSIP-AOR AVP値の間の相関関係が、別のユーザに割り当てられたSIP-AORの登録を避けるのに必要です。
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がネットワークイドを訪問しているAVPがあって、Diameter UARメッセージのSIPユーザ承認タイプAVP対価領収がREGISTRATIONかREGISTRATION&CAPABILITIESに設定されるなら、DiameterサーバSHOULDは、ユーザがDiameter UARメッセージのSIPがネットワークイドを訪問しているAVPで指定されたネットワークに移動できるかどうか確かめます。 ユーザがそのネットワークに移動できないなら、Diameter AAAサーバは_ALLOWEDではなく、DIAMETER_ERROR_ROAMING_へのDiameter UAAメッセージにResult-コードAVP価値をはめ込まなければなりません。
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ユーザ承認タイプAVP対価領収がREGISTRATIONかREGISTRATION&CAPABILITIESに設定されるなら、DiameterサーバSHOULDは、SIP-AOR AVP値がホームRealmに登録するのが認可されるかどうか確かめます。 SIP AORがホームRealmに登録するのは認可されないところに、Diameterサーバが、DIAMETER_AUTHORIZATION_REJECTEDにResult-コードAVPを設定して、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ユーザ承認タイプであるときに、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 AORsの登録証明書を含んでいる)のどんな前の登録も意識していないなら、Diameterサーバはユーザに割り当てられたどんなSIPサーバも知りません。 この場合、DiameterサーバはDiameter UAAメッセージにDIAMETER_FIRST_REGISTRATIONにResult-コードAVP価値を設定しなければなりません、そして、DiameterサーバSHOULDはDiameter UAAメッセージのSIPサーバ能力AVP価値で必要なSIPサーバ能力を含めます。 SIPサーバ能力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
o いくつかの場合、同じユーザ名に割り当てられた同じであるか異なったSIP AORsにおいて、Diameterサーバは以前に割り当てられたSIPサーバを意識しています。 これらのケース、新しいSIPの再割当てで
Garcia-Martin, et al. Standards Track [Page 25] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[25ページ]。
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.
サーバが必要であるかもしれません、SIPサーバの能力によって。DiameterサーバはUAAメッセージのSIPサーバURI AVPにいつも割り当てられたSIPサーバURIを含まなければなりません。 DiameterサーバがSIP能力を返さないなら、DiameterサーバはDIAMETER_SUBSEQUENT_REGISTRATIONへのDiameter UAAメッセージにResult-コードAVPをはめ込まなければなりません。 さもなければ(すなわち、DiameterサーバがSIPサーバ能力AVPを含んでいるなら)、そして、DiameterサーバはDIAMETER_SERVER_SELECTIONへのDiameter UAAメッセージにResult-コードAVPをはめ込まなければなりません。 そして、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ユーザ承認タイプAVP対価領収がREGISTRATION&CAPABILITIESに設定されると、Diameter ServerはDiameter UAAメッセージのSIPサーバ能力AVP価値における能力のリストを返さなければなりません、そして、DIAMETER_SUCCESSにResult-コードを設定しなければなりません、そして、それはSIPサーバURI AVPを返してはいけません。 必要な能力によって、ユーザのためにサービスを呼び出して、実行するAVPが、SIPサーバ(直径クライアント)が別の適切なSIPサーバを選択するのを可能にする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ユーザ承認タイプ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-コードAVPをDIAMETER_SUCCESSに設定しなければならなくて、SIPサーバ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サーバは_REGISTEREDではなく、DIAMETER_ERROR_IDENTITY_へのDiameter UAAメッセージにResult-コードAVPをはめ込まなければなりません。
The Message Format of the UAA command is as follows:
UAAコマンドのMessage Formatは以下の通りです:
<UAA> ::= < Diameter Header: 283, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ SIP-Server-URI ]
<UAA>:、:= <直径ヘッダー: 283 PXY><セッションイド>AuthアプリケーションイドAuthセッション州の結果コード発生源ホスト発生源分野[一口サーバURI]
Garcia-Martin, et al. Standards Track [Page 26] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[26ページ]。
[ SIP-Server-Capabilities ]
[ Authorization-Lifetime ]
[ Auth-Grace-Period ]
[ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
[一口サーバ能力] [承認生涯][再直接のホスト][ホスト用法を向け直してください][マックスキャッシュ時間を向け直す]の[Auth-据置期間]*[プロキシインフォメーション]*[ルート記録的な]*[AVP]
8.3. Server-Assignment-Request (SAR) Command
8.3. サーバ課題要求(SAR)命令
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課題要求(SAR)命令は284へのCommand-コードセットによって示されました、そして、Command Flags'R'のビットはセットしました。 SIPサーバのDiameterクライアントは、認証過程の完成を示して、Diameterサーバが現在ユーザに役立っているSIPサーバのURIを保存するよう要求するためにこのコマンドをDiameterサーバに送ります。 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課題要求(SAR)のSIPサーバ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サーバ課題タイプAVP(セクション9.4)値で特定されます。 例えば、SIPサーバのDiameterクライアントは、ユーザの反登録を要求するか、認証失敗のDiameterサーバを知らせるか、またはただユーザ・プロファイルをダウンロードするためにDiameterサーバに連絡するかもしれません。 すべてのSIPサーバ課題タイプ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要求のレセプションは、Diameter SARメッセージを送るためにSIPサーバでDiameterクライアントの引き金となるでしょう。 しかしながら、SIPサーバが他のSIPがINVITEなどのように要求する受信であり、SIPサーバがユーザ・プロファイルを持っていないなら、SIPサーバのDiameterクライアントは、ユーザ・プロファイルをダウンロードするためにDiameter SARメッセージをDiameterサーバに送って、Diameterサーバをユーザに割り当てられたSIPサーバを意識するようにするかもしれません。
Garcia-Martin, et al. Standards Track [Page 27] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[27ページ]。
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サーバ課題タイプAVPはDiameterクライアント(SIPサーバ)がDiameterサーバに連絡した理由を示します。DiameterクライアントがREGISTRATION、RE_REGISTRATION、UNREGISTERED_USER、いいえ_ASSIGNMENT、AUTHENTICATION_FAILUREまたはAUTHENTICATION_TIMEOUTにSIPサーバ課題タイプAVP価値を設定するなら、DiameterクライアントはちょうどDiameter SARメッセージの1SIP-AOR AVPを入れなければなりません。
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が、よりタイプしているAVPsを含むかもしれません。 それぞれのそれらはSIPサーバに解釈された一種の利用者データを含んでいます。これは、DiameterクライアントがSIPサーバに解釈された利用者データの異なった形式のDiameterサーバに指示を提供するのを許容します。Diameterサーバは、SAAメッセージに含まれている1SIPユーザデータAVPsを選択するのにこの情報を使用します。
The Message Format of the SAR command is as follows:
SARコマンドのMessage Formatは以下の通りです:
<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 ]
<SAR>:、:= <直径ヘッダー: 284 REQ、既に利用可能なPXYの発生源分野目的地分野一口サーバ課題タイプ一口ユーザ><セッションイド>AuthアプリケーションイドAuthセッション州の発生源ホストデータ[あて先ホスト][ユーザ名][一口サーバURI]*[ユーザデータ型であるとサポートされた一口]*[一口AOR]*[プロキシインフォメーション]*[ルート記録的な]*[AVP]
Garcia-Martin, et al. Standards Track [Page 28] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[28ページ]。
8.4. Server-Assignment-Answer (SAA) Command
8.4. サーバ課題答え(SAA)命令
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課題答え(SAA)は284へのCommand-コードセットときれいにされたCommand Flagsの'R'ビットによって示されます。 Diameterサーバは以前に受信されたDiameter Server課題要求(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.
RFC3588[RFC3588]で既に定義された値に加えて、Result-コード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-コードAVP価値はDiameter SARコマンドの実行における成功か誤りを示すかもしれません。 Diameter SAAメッセージのResult-コードAVP価値がエラーコードを含んでいないなら、SAAメッセージはユーザのプロフィールを通常含む1SIPユーザデータAVPsを含むかもしれません、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がタイプしているAVPsを含むかもしれません、各々がDiameterサーバでサポートされた一種のユーザデータの形式を特定して。DiameterクライアントとDiameterサーバの間には、一般的なサポートしているユーザデータ型がなければ、DiameterサーバSHOULDは、サポートしている利用者データのリストがDiameter SAAメッセージの1ユーザデータであるとサポートされたSIPがタイプしているAVPsを含んでいることによってタイプされると宣言します。 この指示は単にデバッグ理由であります、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-名前AVP価値を必要としますが、Diameter SARメッセージがUser-名前AVP価値を含まなかったなら、Diameterサーバは、DIAMETER_USER_NAME_REQUIRED(セクション10.1.2を見る)にResult-コードAVP価値を設定して、Diameter SAAメッセージでそれを返さなければなりません。 DIAMETER_USER_NAME_REQUIREDへのResult-コードAVP選択値群があるこのDiameter SAAメッセージのレセプションでは、SIP401(権限のない)かSIP407(プロキシAuthentication Required)が創始者への応答であって戻るのであると生成することによって、SIPサーバは認証を通常要求します。
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.
User-名前AVPがDiameter SARメッセージに含まれているなら、Diameter SARメッセージのレセプションでは、Diameterサーバは分野のユーザの存在について確かめなければなりません、すなわち、User-名前AVP価値がその分野の中の正規ユーザーです。 DiameterサーバがUser-名前AVPで受け取られたユーザ名を認識しないなら、Diameterサーバは、Diameter Server課題答え(SAA)メッセージを築き上げなければならなくて、DIAMETER_ERROR_USER_UNKNOWNにResult-コードAVPを設定しなければなりません。
Garcia-Martin, et al. Standards Track [Page 29] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[29ページ]。
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サーバは、Diameter SARメッセージのSIP-AOR AVPにSIPかSIPS URIを含むようにAVPが妥当な認証名であることを評価するそのUser-名前を認可しなければなりません。 この承認が失敗するなら、Diameterサーバは、DIAMETER_ERROR_IDENTITIES_ドント_MATCHにResult-コードAVPを設定して、Diameter Server課題答え(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サーバは「認証未定」の旗をきれいにしなければなりません、そして、SHOULDは一時保存されたSIPサーバURIを永久記録媒体に動かします。
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サーバ課題タイプの値に依存します:
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サーバ課題タイプAVP価値がREGISTRATIONかRE_REGISTRATIONに設定されるなら、DiameterサーバSHOULDは、1SIP-AOR AVPしかないことを確かめます。 さもなければ、DiameterサーバにAVPがDIAMETER_AVP_OCCURSにも_MANY_タイムズを設定して、少しのSIPユーザデータAVPも含んではいけないのを評価するResult-コードがあるDiameter SAAメッセージで答えなければなりません。 1SIP-AOR AVPしかなくて、既に利用可能なSIPユーザデータAVP価値が_AVAILABLEではなく、USER_DATA_に設定されるなら、DiameterサーバSHOULDはSIPかSIPS URI(SIP-AOR AVP)がある1つ以上のユーザ・プロファイルデータとDiameter SAAメッセージのSIPユーザデータAVP価値でそのAVPに関連している他のすべてのSIPのアイデンティティを含んでいます。 利用者データのタイプを選ぶと、DiameterサーバSHOULDはSIPサーバ(SARメッセージのユーザデータであるとサポートされたSIPがタイプしているAVP)におけるサポートしている形式とローカルの方針を考慮に入れます。 さらに、DiameterサーバはDiameter SAAメッセージのDIAMETER_SUCCESSにResult-コードAVP価値を設定しなければなりません。 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
o Diameter SARメッセージのSIPサーバ課題タイプAVP価値がUNREGISTERED_USERに設定されるなら、SIPサーバURI AVP値にサーバアドレスを含んでいる場合、DiameterサーバはSIPを保存しなければなりません。 DiameterサーバはDiameter Locationインフォメーション答え(LIA)メッセージのSIPサーバアドレスを返すでしょう。 既に利用可能なSIPユーザデータAVP価値が_AVAILABLEではなく、USER_DATA_に設定されるなら、DiameterサーバSHOULDはDiameter SAAメッセージのSIPユーザデータAVP価値にSIPかSIPS URI(SIP-AOR AVP)に関連している1つ以上のユーザ・プロファイルデータと関連アイデンティティを含んでいます。 利用者データのタイプを選ぶと、DiameterサーバSHOULDはSIPサーバ(SARメッセージのユーザデータであるとサポートされたSIPがタイプしているAVP)におけるサポートしている形式とローカルの方針を考慮に入れます。 DiameterサーバはResult-コードAVP価値をDIAMETER_SUCCESSに設定しなければなりません。 直径
Garcia-Martin, et al. Standards Track [Page 30] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[30ページ]。
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.
SIP AOR UNREGISTEREDを考えますが、サーバは登録されていないユーザにサービスの引き金となって、提供するためにSIPサーバを割り当てていてそうします。 UNREGISTERED_USER(SIPサーバ課題タイプAVP)の場合にDiameterサーバが、1SIP-AOR AVPしかないことを確かめなければならないことに注意してください。 さもなければ、DiameterサーバはDiameter SAAメッセージでDiameter SARメッセージに答えなければなりません、そして、それはResult-コードAVPを設定しなければなりません。DIAMETER_AVP_OCCURSにも_MANY_タイムズを評価して、少しのSIPユーザデータAVPも含めてはいけません。 User-名前AVPがDiameter SARメッセージに存在していなくて、またSIP-AORがDiameterサーバで知られていないなら、Diameterサーバは、Diameter SAAメッセージにUser-名前AVPを含んではいけなくて、DIAMETER_ERROR_USER_UNKNOWNにResult-コード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サーバ課題タイプAVP価値がTIMEOUT_DEREGISTRATION、USER_DEREGISTRATION、DEREGISTRATIONにも_を設定することであるなら、Diameter SARメッセージに値を含んでいる場合、非常に、DATA、またはADMINISTRATIVE_DEREGISTRATION、DiameterサーバがそれぞれのSIP-AOR AVPで示されるすべてのSIP AORsに関連しているSIPサーバアドレスをクリアしなければなりません。 Diameterサーバは登録されないようにこれらのSIP AORsのすべてを考えます。 DiameterサーバはDiameter SAAメッセージのDIAMETER_SUCCESSにResult-コードAVP価値を設定しなければなりません。
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サーバ課題タイプAVP価値が_TIMEOUT_DEREGISTRATION_ストアSERVER_NAMEか_USER_DEREGISTRATION_ストアSERVER_NAMEに設定されるなら、DiameterサーバはSIP AORsが登録されていなくなりますが、SIP AORsに関連しているアドレスがDiameter SARメッセージのSIP-AOR AVP値に含んだSIPサーバを保つかもしれません。 この特徴で、SIPサーバは、Diameterサーバが同じユーザ名に割り当てられたそれらのSIP AORs(SIP-AOR AVP値)のための割り当てられたSIPサーバのままで残っているよう要求して、SIPサーバ課題を避けます。 Diameterサーバは登録されないようにこれらのすべてのSIP AORsを考えなければなりません。 DiameterサーバがDiameterクライアント(SIPサーバ)が割り当てられたSIPサーバとして残っているという要求を光栄に思うなら、Diameterサーバは、ユーザ名に割り当てられたそれらのSIP AORsにSIPサーバを割り当て続けなければならなくて、Diameter SAAメッセージのDIAMETER_SUCCESSにResult-コードAVP価値を設定しなければなりません。 Diameterサーバが割り当てられたSIPサーバ、Diameterサーバが割り当てというSIPサーバー名をそれらのSIP AORsにクリアしなければならなくて、Result-コードを設定しなければならないときDiameterクライアント(SIPサーバ)が残っているという要求を光栄に思わないとき、さもなければ、AVPはDiameter SAAメッセージで__STOREDではなく、SERVER_NAME_をDIAMETER_SUCCESSに評価します。
Garcia-Martin, et al. Standards Track [Page 31] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[31ページ]。
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サーバ課題タイプAVP価値がいいえ_ASSIGNMENTに設定されるなら、DiameterサーバSHOULDは、最初に、Diameter SARメッセージのSIPサーバURI AVP値がSIP-AOR AVP値に割り当てられたものと同じURIであることを確かめます。 彼らが異なるなら、DiameterサーバはDiameter SAAメッセージにDIAMETER_UNABLE_TO_COMPLYにResult-コードAVP価値を設定しなければなりません。 さもなければ、既に利用可能なSIPユーザデータAVP価値が_AVAILABLEではなく、USER_DATA_に設定されるなら、DiameterサーバSHOULDはSIPかSIPS URI(SIP-AOR AVP)があるユーザ・プロファイルデータとDiameter SAAメッセージのSIPユーザデータAVP価値でそのAVPに関連している他のすべてのSIPのアイデンティティを含んでいます。 利用者データのタイプを選ぶと、DiameterサーバSHOULDはSIPサーバ(SARメッセージのユーザデータであるとサポートされたSIPがタイプしているAVP)におけるサポートしている形式とローカルの方針を考慮に入れます。
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サーバ課題タイプAVP価値がAUTHENTICATION_FAILUREかAUTHENTICATION_TIMEOUTに設定されるなら、Diameterサーバは、Diameter SARメッセージには1SIP-AOR AVPがまさにあることを確かめなければなりません。 DiameterサーバはSIP-AOR AVPの反復回数がちょうどない1であるなら、Result-コードを設定しなければなりません。AVPはDiameter SAAメッセージでDIAMETER_AVP_OCCURSにも_MANY_タイムズを評価します、そして、SHOULDは行動を取りません。 Diameter SARメッセージに1SIP-AOR AVPがまさにあれば、Diameterサーバはユーザ名に割り当てられたSIP AORに割り当てられたSIPサーバをアドレスから取り除かなければなりません、そして、DiameterサーバはDiameter SAAメッセージのDIAMETER_SUCCESSにResult-コードAVP価値を設定しなければなりません。 Diameterサーバは登録されないようにSIP AORを考えなければなりません。
The Message Format of the SAA command is as follows:
SAAコマンドのMessage Formatは以下の通りです:
<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 ]
<SAA>:、:= <直径ヘッダー: 284 PXY><セッションイド>Authアプリケーションイド結果コードAuthセッション州の発生源ホスト発生源分野*[一口利用者データ][一口課金情報]*[ユーザデータ型であるとサポートされた一口][ユーザ名][Auth-据置期間][承認生涯][再直接のホストの][再直接のホスト用法]
Garcia-Martin, et al. Standards Track [Page 32] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[32ページ]。
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
[マックスキャッシュ時間を向け直してください] *[プロキシインフォメーション]*[ルート記録的な]*[AVP]
8.5. Location-Info-Request (LIR) Command
8.5. 位置のインフォメーション要求(LIR)命令
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インフォメーション要求(LIR)は285へのCommand-コードセットによって示されました、そして、Command Flags'R'のビットはセットしました。 SIPサーバのDiameterクライアントは、ルーティング情報(例えば、ユーザに割り当てられたSIP-AOR AVP値に割り当てられたSIPサーバのURI)を要求するためにこのコマンドをDiameterサーバに送ります。
The Message Format of the LIR command is as follows:
LIRコマンドのMessage Formatは以下の通りです:
<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 ]
<LIR>:、:= <直径ヘッダー: 285 REQ、PXY><セッションイド>AuthアプリケーションイドAuthセッション州の発生源ホスト発生源分野目的地分野一口AOR[あて先ホスト]*[プロキシインフォメーション]*[ルート記録的な]*[AVP]
8.6. Location-Info-Answer (LIA) Command
8.6. 位置のインフォメーション答え(LIA)命令
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インフォメーション答え(LIA)は285へのCommand-コードセットときれいにされたCommand Flagsの'R'ビットによって示されます。 Diameterサーバは以前に受信されたDiameter Locationインフォメーション要求(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.
RFC3588[RFC3588]で既に定義された値に加えて、Result-コードAVPはセクション10.1で定義された値の1つを含むかもしれません。 Diameterサーバが、処理における誤りがDiameter LIRメッセージであることがわかるとき、DiameterサーバはResult-コードAVP価値に適切なエラーコードを含んでいるDiameter LIAメッセージでメッセージと答えのプロセスを止めなければなりません。 誤りが全くないとき、DiameterサーバはDiameter LIAメッセージのDIAMETER_SUCCESSにResult-コードAVP価値を設定しなければなりません。
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サーバは、DIAMETER_ERROR_USER_UNKNOWNにResult-コードAVP価値を設定して、Diameter LIAメッセージでそれを返さなければなりません。
Garcia-Martin, et al. Standards Track [Page 33] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[33ページ]。
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サーバは、例えば、データベース誤りのため、DIAMETER_UNABLE_TO_COMPLYにResult-コードAVP価値を設定して、Diameter LIAメッセージでそれを返さなければなりません。 DiameterサーバはDiameter LIAメッセージの少しのSIPサーバURIかSIPサーバ能力AVPも含んではいけません。
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 AVPのそのようなSIPサーバのURIを含んで、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-コード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サーバは、DIAMETER_UNREGISTERED_SERVICEにResult-コードAVP価値を設定して、Diameter LIAメッセージでそれを返さなければなりません。 また、Diameterサーバは、必要な能力がある適切なSIPサーバの選択でSIPサーバ(直径クライアント)を容易にするためにSIPサーバ能力AVPを含むかもしれません。 AVPがユーザのために割り当てるためにどんなSIPサーバも適当であることをSIPサーバ(直径クライアント)に示すSIP-サーバ能力の欠如。
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サーバは、_REGISTEREDではなく、DIAMETER_ERROR_IDENTITY_にResult-コードAVP価値を設定して、Diameter LIAメッセージのDiameterクライアントにそれを返さなければなりません。 SIPサーバ(直径クライアント)はオリジナルのSIP要求への適切なSIP応答(例えば、480(一時入手できない))を返すかもしれません。
The Message Format of the LIA command is as follows:
LIAコマンドのMessage Formatは以下の通りです:
<LIA> ::= < Diameter Header: 285, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
<ライア>:、:= <直径ヘッダー: 285 PXY><セッションイド>Authアプリケーションイド結果コード
Garcia-Martin, et al. Standards Track [Page 34] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[34ページ]。
{ 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 ]
Authセッション州の発生源ホスト発生源分野[一口サーバURI][一口サーバ能力][Auth-据置期間][承認生涯][再直接のホストの][再直接のホスト用法][再直接のマックスキャッシュ時間]*[プロキシインフォメーション]*[ルート記録的な]*[AVP]
8.7. Multimedia-Auth-Request (MAR) Command
8.7. Authが要求するマルチメディア(3月)コマンド
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-要求(3月)命令は286へのCommand-コードセットによって示されました、そして、Command Flags'R'のビットはセットしました。 SIPサーバのDiameterクライアントは、Diameterサーバが何らかのSIPサービスを利用するユーザ試みを認証して、認可するよう要求するためにこのコマンドをDiameterサーバに送ります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.
また、3月のコマンドはSIPサーバの自己のURIをDiameterサーバに登録するかもしれません、将来のLIR/LIAメッセージがこのURIを返すことができるように。 SIPサーバがSIP記録係として務めているなら(セクション6.2と6.3で例を見てください)、Diameterクライアントは3月のコマンドでSIPサーバ-URI AVPを入れなければなりません。 いかなる他の場合(セクション6.4で例を見る)ではも、Diameterクライアントは3月のコマンドでSIP-サーバURI AVPを入れてはいけません。
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 MUSTはこのDiameter3月のメッセージの引き金となったSIP要求のSIPメソッド名を含んでいます。 Diameterサーバは、メソッドによるいくつかのSIP要求を認可するのにこのAVPを使用できます。
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
Diameter3月のメッセージはSIP-AOR AVPを含まなければなりません。 SIP-AOR AVPはSIP要求の目標を示します。 AVPの値はSIP要求で異なった場所から抽出されます、SIP要求の意味論によって。 それは、SIP REGISTER要求のToヘッダーフィールド価値(RFC3261[RFC3261]に従ってaddr-仕様)で居住したSIP REGISTERメッセージに関しては、SIP-AOR AVP値が登録で意図している公共のユーザアイデンティティを示して、SIPかSIPS URIです。 登録、他のタイプのINVITEなどのSIP要求のために、MESSAGEなどは要求の意図している目的地を示しますSIP-AOR AVPが、評価する。 SIP要求のRequest-URIでこれに通常居住します。 SIP-AOR AVP値を抽出します。
Garcia-Martin, et al. Standards Track [Page 35] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[35ページ]。
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.
適切なSIPから、ヘッダーフィールドは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クライアントはUser-名前AVP価値でSIP要求に関する認証情報から抜粋されたユーザ名を入れなければなりません。
The Message Format of the MAR command is as follows:
3月のコマンドのMessage Formatは以下の通りです:
<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 ]
<3月の>:、:= <直径ヘッダー: 286 REQ、PXY><セッションイド>AuthアプリケーションイドAuthセッション州の発生源ホスト発生源分野目的地分野一口AOR一口メソッド[あて先ホスト][ユーザ名][一口サーバURI][一口数のAuthの品目][一口Authデータ項目]*[プロキシインフォメーション]*[ルート記録的な]*[AVP]
8.8. Multimedia-Auth-Answer (MAA) Command
8.8. マルチメディアAuth答え(MAA)命令
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-答え(MAA)は286へのCommand-コードセットときれいにされたCommand Flagsの'R'ビットによって示されます。 Diameterサーバは以前に受信されたDiameter Multimedia-Auth-要求(3月)命令に対応してこのコマンドを送ります。
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.
RFC3588[RFC3588]で既に定義された値に加えて、Result-コード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
DiameterサーバがDiameter3月の要求を処理するためにUser-名前AVP価値を必要としますが、Diameter3月のメッセージがUser-名前AVP価値を含まなかったなら、Diameterサーバは、DIAMETER_USER_NAME_REQUIRED(セクション10.1.2を見る)にResult-コードAVP価値を設定して、Diameter MAAメッセージでそれを返さなければなりません。 Diameterサーバは認証情報(例えば、挑戦)があるSIP数のAuthの品目AVPと1SIP-Authデータの品目AVPsを含むかもしれません。 レセプションに関して
Garcia-Martin, et al. Standards Track [Page 36] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[36ページ]。
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_USER_NAME_REQUIREDへのResult-コードAVP選択値群があるこのDiameter MAAメッセージでは、SIP401(権限のない)かSIP407(プロキシAuthentication Required)が創始者への応答であって戻るのであると生成することによって、SIPサーバは認証を通常要求します。
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.
User-名前AVPがDiameter3月のメッセージに存在しているなら、Diameterサーバは分野のユーザの存在について確かめなければなりません、すなわち、User-名前AVP価値がその分野の中の正規ユーザーです。 DiameterサーバがUser-名前AVPで受け取られたユーザ名を認識しないなら、Diameterサーバは、Diameter Multimedia-Auth-答え(MAA)メッセージを築き上げなければならなくて、DIAMETER_ERROR_USER_UNKNOWNにResult-コードAVPを設定しなければなりません。
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.
Diameter3月のメッセージのSIP-メソッドAVP価値がREGISTERに設定されて、User-名前AVPが存在しているなら、SIP-AOR AVPにURIを含んでいる場合、DiameterサーバはAVP値が使用できるそのUser-名前を認可しなければなりません。 この承認が失敗するなら、Diameterサーバは、DIAMETER_ERROR_IDENTITIES_ドント_MATCHにResult-コードAVPを設定して、Diameter Multimedia-Auth-答え(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.
以下に注意してください。 User-名前とSIP-AOR AVP値の間の相関関係が、SIP REGISTER要求にユーザが別のユーザに割り当てられたSIP-AORを登録するのを防ぐのに必要であるだけです。 他のタイプの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認証体系AVP価値)が、分類されたSIP-Authデータの品目でAVPがサポートされるのを示したかどうか確かめなければなりません。 その認証体系がサポートされないなら、Diameterサーバは、_SUPPORTEDではなく、DIAMETER_ERROR_AUTH_SCHEME_にResult-コードAVPを設定して、Diameter Multimedia-Auth-答え(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.
AVPがSIP数のAuthの品目であるならDiameter3月のメッセージに存在している、それはDiameterクライアントが要求している認証データ項目の数を示します。 Diameter MAAメッセージを築き上げるとき、DiameterサーバがDiameter3月のメッセージのSIP数のAuthの品目AVP価値でDiameterクライアントによって要求された認証データ項目の部分集合である多くのSIP-Authデータの品目AVPsを含んでいるのは、RECOMMENDEDです。
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
SIPサーバURI AVPがDiameter3月のメッセージに存在しているなら、DiameterサーバはSIPサーバURI AVP値(Diameter3月のメッセージでは、受信する)に保存されたSIPサーバ(ユーザに割り当てられる)をたとえなければなりません。 彼らが合っていないなら、Diameterサーバは、ユーザに割り当てられた新たに受け取られたSIPサーバを一時節約させなければならなくて、「認証未定」の旗をユーザに設定しなければなりません。 それらです。
Garcia-Martin, et al. Standards Track [Page 37] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[37ページ]。
match, the Diameter server shall clear the "authentication pending" flag for the user.
合ってください、そして、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.
いかなる他の状況でも、成功がDiameter3月のコマンドを処理するのをあって、DiameterサーバがSIPサーバURIを保存したなら、Diameterサーバは、Result-コード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:
成功がDiameter3月のコマンドを処理するのをありますが、AVPがDiameter3月のコマンドで存在していなかったのでDiameterサーバがSIPサーバURIを保存しないなら、DiameterサーバはResult-コードAVP価値をどちらかに設定しなければなりません:
1. DIAMETER_SUCCESS_AUTH_SENT_SERVER_NOT_STORED, if the Diameter
server is sending authentication credentials to create a
challenge.
1. _STOREDではなく、DIAMETER_SUCCESS_AUTH_SENT_SERVER_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. _STOREDではなく、DIAMETER_SUCCESS_SERVER_NAME_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サーバはDIAMETER_UNABLE_TO_COMPLYにResult-コードAVP価値を設定しなければなりません、そして、それは少しのSIP-Authデータの品目AVPも含めてはいけません。
The Message Format of the MAA command is as follows:
MAAコマンドのMessage Formatは以下の通りです:
<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 ]
<MAA>:、:= <直径ヘッダー: 286 PXY><セッションイド>Authアプリケーションイド結果コードAuthセッション州の発生源ホスト発生源分野[ユーザ名][一口AOR][一口数のAuthの品目]*[一口Authデータ項目][承認生涯][Auth-据置期間][再直接のホストの][再直接のホスト用法][再直接のマックスキャッシュ時間]*[プロキシインフォメーション]*[ルート記録的な]*[AVP]
Garcia-Martin, et al. Standards Track [Page 38] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[38ページ]。
8.9. Registration-Termination-Request (RTR) Command
8.9. 登録終了要求(RTR)命令
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終了要求(RTR)命令は287へのCommand-コードセットによって示されました、そして、Command Flags'R'のビットはセットしました。 Diameterサーバは1SIP AORsが反登録されなければならないのをSIPサーバに示すDiameterクライアントへの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サーバは、1SIP AORだけが反登録されるべきである行くこと、SIP AORsのリスト、またはすべて、ユーザに割り当てられたSIP AORsであるかを決めることができます。
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-名前AVPによって特定されたユーザに割り当てられたすべてのSIP AORsが反登録されているのを示します。
The Diameter server MUST include a SIP-Deregistration-Reason AVP value to indicate the reason for the deregistration.
Diameterサーバは、反登録の理由を示すためにSIP-Deregistration-理由AVP価値を含まなければなりません。
The Message Format of the RTR command is as follows:
RTRコマンドのMessage Formatは以下の通りです:
<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 ]
<RTR>:、:= <直径ヘッダー: 287 REQ、PXY><セッションイド>AuthアプリケーションイドAuthセッション州の発生源ホスト発生源分野あて先ホスト一口Deregistration理由[目的地分野][ユーザ名]*[一口AOR]*[プロキシインフォメーション]*[ルート記録的な]*[AVP]
8.10. Registration-Termination-Answer (RTA) Command
8.10. 登録終了答え(RTA)命令
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終了答え(RTA)は287へのCommand-コードセットときれいにされたCommand Flagsの'R'ビットによって示されます。 Diameterクライアントは以前に受信されたDiameter Registration終了要求(RTR)命令に対応してこのコマンドを送ります。
Garcia-Martin, et al. Standards Track [Page 39] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[39ページ]。
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.
RFC3588[RFC3588]で既に定義された値に加えて、Result-コード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 RTR要求を処理するためにUser-名前AVP価値を必要としますが、Diameter RTRメッセージがUser-名前AVP価値を含まなかったなら、Diameterクライアントは、DIAMETER_USER_NAME_REQUIRED(セクション10.1.2を見る)にResult-コードAVP価値を設定して、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.
または、Diameter RTR要求の現在のどんなSIP-AOR AVPもなければそれぞれのSIP-AOR AVP値にそれぞれのURIへの管理反登録を含んでいて、SIPサーバ(直径クライアント)は適用されます、User-名前AVP価値に割り当てられたすべてのURIに。
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コマンドにおけるAVPが動作に影響を与えるSIP-Deregistration-理由の値はSIPサーバ(直径クライアント)で働きました:
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サーバ(直径クライアント)はそうするでしょう。 SIP Server SHOULDのDiameter Clientは新しいユーザ登録を要求しません。 SIPサーバは登録状態からderegistered AORsを取り除きます。
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サーバ(直径クライアント)に知らせます、何らかの理由のため。 SIPサーバであって、SIP手順でサポートされます、管理反登録に関してこのSIPサーバで利害関係者(例えば、"reg"イベント[RFC3680]への加入者)に知らせるでしょう。SIPサーバSHOULD NOTのDiameterクライアントは新しいユーザ登録を要求します。 SIPサーバは登録状態からderegistered SIP AORsを取り除きます。
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サーバがユーザに割り当てられなければならないことをSIPサーバ(直径クライアント)に知らせます、例えば、現在のSIPサーバの十分なリソースではなく、新しいSIPサーバを必要とするユーザの能力のため。利害関係者の受け取ったことを知らせるなら、SIP手順(例えば、"reg"イベント[RFC3680]の購読)で管理反登録はサポートされて、SIPサーバはそうするでしょう。 SIP Server SHOULDのDiameterクライアントは新しいユーザ登録を要求しません。 SIPサーバは登録状態からderegistered SIP AORsを取り除きます。
Garcia-Martin, et al. Standards Track [Page 40] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[40ページ]。
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 値が_削除、SIP_SERVERに設定されるなら、Diameterサーバは、SIPサーバがもうそのユーザと共にDiameterサーバで制限しないことをSIPサーバ(直径クライアント)に知らせます。 SIPサーバはユーザに伝えるすべてのデータを削除できます。
The Message Format of the RTA command is as follows:
RTAコマンドのMessage Formatは以下の通りです:
<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 ]
<RTA>:、:= <直径ヘッダー: 287 PXY><セッションイド>Authアプリケーションイド結果コードAuthセッション州の発生源ホスト発生源分野[承認生涯][Auth-据置期間][再直接のホストの][再直接のホスト用法][再直接のマックスキャッシュ時間]*[プロキシインフォメーション]*[ルート記録的な]*[AVP]
8.11. Push-Profile-Request (PPR) Command
8.11. プッシュプロフィール要求(PPR)命令
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プロフィール要求(PPR)命令は288へのCommand-コードセットによって示されました、そして、Command Flags'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 Pushプロフィール要求(PPR)命令をDiameterクライアントに送ります、それらの新種業務を適用し始めるために。
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会計情報AVPを含むかもしれません。 会計サーバのアドレスにおける変化はすぐに、効きます。 DiameterクライアントSHOULDはどんな既存の会計セッションのときにも既存のサーバを閉じて、新たに取得された会計サーバに課金情報を提供し始めます。
Garcia-Martin, et al. Standards Track [Page 41] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[41ページ]。
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コマンドはゼロか新しいユーザ・プロファイルを含むより多くのSIPユーザデータAVP値を含むかもしれません。 利用者データのタイプを選ぶと、DiameterサーバSHOULDはSIPサーバ(ユーザデータであるとサポートされたSIPがタイプしているAVPは前のSARメッセージを送った)におけるサポートしている形式とローカルの方針を考慮に入れます。
The User-Name AVP indicates the user to whom the profile is applicable.
User-名前AVPはプロフィールが適切であるユーザを示します。
The Message Format of the PPR command is as follows:
PPRコマンドのMessage Formatは以下の通りです:
<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 ]
<PPR>:、:= <直径ヘッダー: 288、REQ、PXY><セッションイド>AuthアプリケーションイドAuthセッション州の発生源ホスト発生源分野目的地分野ユーザ名、*[一口利用者データ][一口課金情報][あて先ホスト][承認生涯][Auth-据置期間]*[プロキシインフォメーション]*[ルート記録的な]*[AVP]
8.12. Push-Profile-Answer (PPA) Command
8.12. プッシュプロフィール答え(PPA)命令
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プロフィール答え(PPA)は288へのCommand-コードセットときれいにされたCommand Flagsの'R'ビットによって示されます。 Diameterクライアントは以前に受信されたDiameter Pushプロフィール要求(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.
RFC3588[RFC3588]で既に定義された値に加えて、Result-コード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サーバ(直径クライアント)はそれがUser-名前AVP価値で指定されるユーザに関連づけたDiameter PPRメッセージと店のSIPユーザデータ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
SIPサーバは、認識しないか、またはSIPユーザデータAVP値、中のSIPサーバがaを含んでいるDiameter PPAメッセージを返さなければならないDiameterクライアントで移されたいくつかのデータをサポートしません。
Garcia-Martin, et al. Standards Track [Page 42] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[42ページ]。
Result-Code AVP set to the value DIAMETER_ERROR_NOT_SUPPORTED_USER_DATA.
結果コードAVPは_SUPPORTED_USER_DATAではなく、値のDIAMETER_ERROR_にセットしました。
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サーバ(直径クライアント)が未知であることのUser-名前AVPと共にDiameter PPRメッセージを受け取るなら、Diameterクライアントは、DIAMETER_ERROR_USER_UNKNOWNにResult-コードAVP価値を設定しなければならなくて、Diameter PPAメッセージのDiameterサーバにそれを返さなければなりません。
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ユーザデータ内容AVP価値(分類されたSIPユーザデータAVPの)のデータに受け取るSIPサーバが受け入れることができるなら、それは、AVPがDIAMETER_ERRORにも_非常に評価するResult-コード_DATAを設定しなければならなくて、Diameter PPAメッセージのDiameterサーバにそれを返さなければなりません。 SIPサーバはPPRメッセージにものを受け取っている既存のユーザ・プロファイルに優越してはいけません。
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サーバが中でAVPがDIAMETER_ERRORにも_を非常に設定するのを評価するResult-コード_DATAを受けるなら、a Diameter PPAは通信して、それはSIP-Deregistration-理由AVP価値があるDiameter Registration終了要求(RTR)をDiameterクライアントに送るのによるユーザの新しい再登録がSIP_SERVER_CHANGEに設定するSHOULD力です。 これは、ユーザの再登録を強制して、新しい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クライアントがコマンドを光栄に思うことができないなら、いかなる他の理由でも、DIAMETER_UNABLE_TO_COMPLYにResult-コードAVP価値を設定しなければなりません、そして、Diameter PPAメッセージでそれを返さなければなりません。
The Message Format of the PPA command is as follows:
PPAコマンドのMessage Formatは以下の通りです:
<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 ]
<PPA>:、:= <直径ヘッダー: 288 PXY><セッションイド>Authアプリケーションイド結果コードAuthセッション州の発生源ホスト発生源分野[再直接のホストの][再直接のホスト用法][再直接のマックスキャッシュ時間]*[プロキシインフォメーション]*[ルート記録的な]*[AVP]
Garcia-Martin, et al. Standards Track [Page 43] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[43ページ]。
9. Diameter SIP Application AVPs
9. 直径一口アプリケーションAVPs
This section defines new AVPs used in this Diameter SIP application. Applications compliant with this specification MUST implement these AVPs.
このセクションはこのDiameter SIPアプリケーションで使用される新しいAVPsを定義します。 この仕様による対応することのアプリケーションはこれらのAVPsを実装しなければなりません。
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アプリケーションで定義された新しいAVPsを記載します。 以下の略語はData-タイプコラムで使用されます:
o DURI: DiameterURI o E: Enumerated o G: Grouped o OS: OctetString o UTF8S: UTF8String o U32: Unsigned32
o ドゥーリ: DiameterURI o E: 列挙されたo G: 分類されたo OS: OctetString o UTF8S: UTF8String o U32: Unsigned32
Garcia-Martin, et al. Standards Track [Page 44] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[44ページ]。
+-----------------------------------+------+----------------+-------+ | 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 | +-----------------------------------+------+----------------+-------+
+-----------------------------------+------+----------------+-------+ | 属性名| AVP| 参照| データ| | | コード| | タイプ| +-----------------------------------+------+----------------+-------+ | 一口課金情報| 368 | セクション9.1| G| | 一口会計サーバURI| 369 | セクション9.1 .1| ドゥーリ| | 一口クレジットコントロールサーバURI| 370 | セクション9.1 .2| ドゥーリ| | 一口サーバURI| 371 | セクション9.2| UTF8S| | 一口サーバ能力| 372 | セクション9.3| G| | 一口の義務的な能力| 373 | セクション9.3 .1| U32| | 一口の任意の能力| 374 | セクション9.3 .2| U32| | 一口サーバ課題タイプ| 375 | セクション9.4| E| | 一口Authデータ項目| 376 | セクション9.5| G| | 一口認証体系| 377 | セクション9.5 .1| E| | 一口商品番号| 378 | セクション9.5 .2| U32| | 一口認証します。| 379 | セクション9.5 .3| G| | 一口承認| 380 | セクション9.5 .4| G| | 一口認証インフォメーション| 381 | セクション9.5 .5| G| | 一口数のAuthの品目| 382 | セクション9.6| U32| | 一口Deregistration理由| 383 | セクション9.7| G| | 一口理由コード| 384 | セクション9.7 .1| E| | 一口理由インフォメーション| 385 | セクション9.7 .2| UTF8S| | 一口はネットワークイドを訪問しました。| 386 | セクション9.9| UTF8S| | 一口ユーザ承認タイプ| 387 | セクション9.10| E| | ユーザデータ型であるとサポートされた一口| 388 | セクション9.11| UTF8S| | 一口利用者データ| 389 | セクション9.12| G| | 一口ユーザデータ型| 390 | セクション9.12 .1| UTF8S| | 一口ユーザデータコンテンツ| 391 | セクション9.12 .2| OS| | 既に利用可能な一口ユーザデータ| 392 | セクション9.13| E| | 一口メソッド| 393 | セクション9.14| UTF8S| +-----------------------------------+------+----------------+-------+
Table 2: Defined AVPs
テーブル2: 定義されたAVPs
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].
RFC3588[RFC3588]のセクション4.5にAVPsのテーブルを含んでいて、テーブル3は広がります。 テーブルは、Diameter AVPsが、このDiameter SIP Application、彼らの可能な旗で値とAVPが暗号化されるかもしれないかどうかを定義したのを示します。 頭文字語'M'、'P'、および'V'は意味論がRFC3588[RFC3588]で説明されるAVP旗を示します。 また、'Encr'コラムの値はRFC3588[RFC3588]で説明されます。
Garcia-Martin, et al. Standards Track [Page 45] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[45ページ]。
+----------------------------------+------+-----+-----+------+------+ | 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 | +----------------------------------+------+-----+-----+------+------+
+----------------------------------+------+-----+-----+------+------+ | 属性名| 必須| 5月| SHD| 必須| Encr| | | | | NOT| NOT| | +----------------------------------+------+-----+-----+------+------+ | 一口課金情報| M| P| | V| N| | 一口会計サーバURI| M| P| | V| N| | 一口クレジットコントロールサーバURI| M| P| | V| N| | 一口サーバURI| M| P| | V| N| | 一口サーバ能力| M| P| | V| N| | 一口の義務的な能力| M| P| | V| N| | 一口の任意の能力| M| P| | V| N| | 一口サーバ課題タイプ| M| P| | V| N| | 一口Authデータ項目| M| P| | V| N| | 一口認証体系| M| P| | V| N| | 一口商品番号| M| P| | V| N| | 一口認証します。| M| P| | V| N| | 一口承認| M| P| | V| N| | 一口認証インフォメーション| M| P| | V| N| | 一口数のAuthの品目| M| P| | V| N| | 一口Deregistration理由| M| P| | V| N| | 一口理由コード| M| P| | V| N| | 一口理由インフォメーション| M| P| | V| N| | 一口はネットワークイドを訪問しました。| M| P| | V| N| | 一口ユーザ承認タイプ| M| P| | V| N| | ユーザデータ型であるとサポートされた一口| M| P| | V| N| | 一口利用者データ| M| P| | V| N| | 一口ユーザデータ型| M| P| | V| N| | 一口ユーザデータコンテンツ| M| P| | V| N| | 既に利用可能な一口ユーザデータ| M| P| | V| N| | 一口メソッド| M| P| | V| N| +----------------------------------+------+-----+-----+------+------+
Table 3: Summary of the new AVPs flags
テーブル3: 新しいAVPs旗の概要
9.1. SIP-Accounting-Information AVP
9.1. 一口課金情報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会計情報(AVP Code368)は、タイプGroupedにはあって、課金情報を集めることができるそれらのノードのDiameterアドレスを含んでいます。
The SIP-Accounting-Information AVP is defined as follows (per the grouped-avp-def of RFC 3588 [RFC3588]):
SIP会計情報AVPが以下の通り定義される、(分類されたavpクールである、RFC3588[RFC3588)について:
SIP-Accounting-Information ::= < AVP Header: 368 >
* [ SIP-Accounting-Server-URI ]
* [ SIP-Credit-Control-Server-URI ]
* [ AVP]
一口課金情報:、:= <AVPヘッダー: 368 >*[一口会計サーバURI]*[一口クレジットコントロールサーバURI]*[AVP]
Garcia-Martin, et al. Standards Track [Page 46] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[46ページ]。
9.1.1. SIP-Accounting-Server-URI AVP
9.1.1. 一口会計サーバ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.
タイプDiameterURIにはSIP会計サーバURI AVP(AVP Code369)があります。 このAVPはSIPセッション関連の課金情報を受け取ることができるDiameterサーバのアドレスを含んでいます。
9.1.2. SIP-Credit-Control-Server-URI AVP
9.1.2. 一口クレジットコントロールサーバURI AVP
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.
タイプDiameterURIにはSIPクレジットコントロールサーバURI AVP(AVP Code370)があります。 このAVPはリアルタイムの金融調整用法を認可できるDiameterサーバのアドレスを含んでいます。 Diameter Credit-コントロールApplication[RFC4006]はこのために使用されるかもしれません。
9.2. SIP-Server-URI AVP
9.2. 一口サーバURI AVP
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.
タイプUTF8StringにはSIPサーバURI AVP(AVP Code371)があります。 このAVPはSIPサーバを特定するSIPかSIPS URI(RFC3261[RFC3261]で定義されるように)を含んでいます。
9.3. SIP-Server-Capabilities AVP
9.3. 一口サーバ能力AVP
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.
タイプGroupedにはSIPサーバ能力AVP(AVP Code372)があります。 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.
AVPがユーザに対するサービスを引き金となるか、または実行するための別のSIPサーバをDiameterクライアント(SIPサーバ)を選択させるSIPサーバ能力。 ユーザはそれらのサービスを引き金となるか、または実行するSIPサーバのある能力の実装を必要とするいくつかのサービスを可能にしたかもしれません。 例えば、このユーザに対するサービスを引き金となるか、または実行するSIPサーバは、SIPサーブレットが[JSR-000116](Call Processing Language(CPL)[RFC3880]、またはいかなる他の種類の能力も)であると実装する必要があるかもしれません。 または、恐らく、そのユーザは速いSIPサーバを必要とするある厳しいサービスの質協定を持っているプレミアムユーザグループに属します。与えられたユーザに必要であった、または推薦された能力はSIPサーバ能力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
そのAVPが、すべての利用可能なSIPサーバの部分集合を作成するDiameterクライアント(SIPサーバ)がホームでユーザに割り当てられるのを補助するSIPサーバ能力Realmに注意してください。 これは1ユーザあたり1個のベースで能力の要件を従わせる部分集合です。 通常、この部分集合は独身のSIP以上について形成されるでしょう。
Garcia-Martin, et al. Standards Track [Page 47] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[47ページ]。
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サーバの部分集合がいったん特定されると、これらのSIPサーバのいくつかのインスタンスが存在するのが、サーバによって可能である、その場合、Diameterクライアント(SIPサーバ)は実行する1つの特定のSIPサーバとこのユーザに対する引き金のサービスを選ぶべきです。 そんなにここに、SIPサーバ(直径クライアント)が1つのSIPサーバをユーザに割り当てるためにRFC3263[RFC3263]の手順に従うと予想されます。
The SIP-Server-Capabilities AVP is defined as follows (per the grouped-avp-def of RFC 3588 [RFC3588]):
SIPサーバ能力AVPが以下の通り定義される、(分類されたavpクールである、RFC3588[RFC3588)について:
SIP-Server-Capabilities ::= < AVP Header: 372 >
* [ SIP-Mandatory-Capability ]
* [ SIP-Optional-Capability ]
* [ SIP-Server-URI ]
* [ AVP ]
一口サーバ能力:、:= <AVPヘッダー: 372 >*[一口の義務的な能力]*[一口の任意の能力]*[一口サーバURI]*[AVP]
9.3.1. SIP-Mandatory-Capability AVP
9.3.1. 一口の義務的な能力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.
タイプUnsigned32にはSIPの義務的な能力AVP(AVP Code373)があります。 値はユーザに割り当てられた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.
それ自身のネットワークの中にそれ自身の意味論を割り当てるのが、管理ネットワークの問題であるので、標準化されません異なることの意味論が、評価する。 各値は管理ネットワークの中にただ一つの能力を表さなければなりません。
9.3.2. SIP-Optional-Capability AVP
9.3.2. 一口の任意の能力AVP
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.
タイプUnsigned32にはSIPの任意の能力AVP(AVP Code374)があります。 値はユーザに割り当てられた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.
それ自身のネットワークの中にそれ自身の意味論を割り当てるのが、管理ネットワークの問題であるので、標準化されません異なることの意味論が、評価する。 各値は管理ネットワークの中にただ一つの能力を表さなければなりません。
9.4. SIP-Server-Assignment-Type AVP
9.4. 一口サーバ課題タイプAVP
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:
SIPサーバ課題タイプAVP(AVP Code375)はタイプEnumeratedにはあって、Diameter Server課題要求(SAR)操作で実行されるサーバアップデートのタイプを示します。 以下の値は定義されます:
Garcia-Martin, et al. Standards Track [Page 48] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[48ページ]。
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.
o Diameterクライアントのいいえ_ASSIGNMENT(0)はSIP AORに関するユーザ・プロファイルを要求するのにこの値を使用します、そのアイデンティティの登録状態に影響しないで。
o REGISTRATION (1)
First SIP registration of a SIP AOR.
o SIP AORのREGISTRATION(1)最初のSIP登録。
o RE_REGISTRATION (2)
Subsequent SIP registration of a SIP AOR.
o SIP AORのRE_REGISTRATIONの(2)のその後の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 SIPサーバにはあるUNREGISTERED_USER(3)は登録されなかったSIP AORのために扱われたSIP要求(例えば、SIP INVITE)を受け取りました。
o TIMEOUT_DEREGISTRATION (4)
The SIP registration timer of an identity has expired.
o アイデンティティのSIP登録タイマが吐き出したTIMEOUT_DEREGISTRATION(4)。
o USER_DEREGISTRATION (5)
The SIP server has received a request to deregister a SIP AOR.
o 容認されたaがSIPサーバから「反-レジスタ」a SIP AORに要求するUSER_DEREGISTRATION(5)。
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 アイデンティティのSIP登録タイマが吐き出したTIMEOUT_DEREGISTRATION_ストア_SERVER_NAME(6)。 SIPサーバは、利用者データを保存し続けて、SIPサーバアドレスを保存するようDiameterサーバに要求します。
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 SIPサーバにはあるUSER_DEREGISTRATION_ストア_SERVER_NAME(7)はユーザによって開始された反登録要求を受け取りました。 SIPサーバは、利用者データを保存し続けて、SIPサーバアドレスを保存するようDiameterサーバに要求します。
o ADMINISTRATIVE_DEREGISTRATION (8)
The SIP server, due to administrative reasons, has deregistered a
SIP AOR.
o 管理理由のためSIPサーバにはあるADMINISTRATIVE_DEREGISTRATION(8)は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、___また、SIPサーバにはあるDATA(11)は非常に、Diameterサーバからユーザプロフィール情報を要求して、受け入れることができるより高いデータのa量を受けました。
Garcia-Martin, et al. Standards Track [Page 49] RFC 4740 Diameter SIP Application November 2006
ガルシア-マーチン、他 規格は直径一口アプリケーション2006年11月にRFC4740を追跡します[49ページ]。
9.5. SIP-Auth-Data-Item AVP
9.5. 一口Authデータ項目AVP
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データの品目(AVP Code376)は、タイプGroupedにはあって、ユーザに関係する認証、そして/または、承認情報を含んでいます。
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.
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.
The SIP-Auth-Data-Item AVP is defined as follows (per the grouped-avp-def of RFC 3588 [RFC3588]):
The SIP-Auth-Data-Item AVP is defined as follows (per the grouped-avp-def of RFC 3588 [RFC3588]):
SIP-Auth-Data-Item ::= < AVP Header: 376 >
{ SIP-Authentication-Scheme }
[ SIP-Item-Number ]
[ SIP-Authenticate ]
[ SIP-Authorization ]
[ SIP-Authentication-Info ]
* [ AVP ]
SIP-Auth-Data-Item ::= < AVP Header: 376 > { SIP-Authentication-Scheme } [ SIP-Item-Number ] [ SIP-Authenticate ] [ SIP-Authorization ] [ SIP-Authentication-Info ] * [ AVP ]
9.5.1. SIP-Authentication-Scheme AVP
9.5.1. SIP-Authentication-Scheme 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:
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:
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 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].
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
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
Garcia-Martin, et al. Standards Track [Page 50] RFC 4740 Diameter SIP Application November 2006
Garcia-Martin, et al. Standards Track [Page 50] RFC 4740 Diameter SIP Application November 2006
SIP-Authentication-Info grouped AVPs that correspond to the SIP WWW- Authenticate/Proxy-Authentication, Authorization/Proxy-Authorization, and Authentication-Info headers fields, respectively.
SIP-Authentication-Info grouped AVPs that correspond to the SIP WWW- Authenticate/Proxy-Authentication, Authorization/Proxy-Authorization, and Authentication-Info headers fields, respectively.
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.
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.
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.
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.
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].
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].
9.5.2. SIP-Item-Number AVP
9.5.2. SIP-Item-Number AVP
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.
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.
9.5.3. SIP-Authenticate AVP
9.5.3. SIP-Authenticate AVP
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.
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.
Garcia-Martin, et al. Standards Track [Page 51] RFC 4740 Diameter SIP Application November 2006
Garcia-Martin, et al. Standards Track [Page 51] RFC 4740 Diameter SIP Application November 2006
The SIP-Authenticate AVP is defined as follows (per the grouped-avp-def of RFC 3588 [RFC3588]):
The SIP-Authenticate AVP is defined as follows (per the grouped-avp-def of RFC 3588 [RFC3588]):
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 ]
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 ]
9.5.4. SIP-Authorization AVP
9.5.4. SIP-Authorization 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.
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.
The SIP-Authorization AVP is defined as follows (per the grouped-avp-def of RFC 3588 [RFC3588]):
The SIP-Authorization AVP is defined as follows (per the grouped-avp-def of RFC 3588 [RFC3588]):
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 ]
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 ]
9.5.5. SIP-Authentication-Info AVP
9.5.5. SIP-Authentication-Info 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.
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.
Garcia-Martin, et al. Standards Track [Page 52] RFC 4740 Diameter SIP Application November 2006
Garcia-Martin, et al. Standards Track [Page 52] RFC 4740 Diameter SIP Application November 2006
The SIP-Authentication-Info AVP is defined as follows (per the grouped-avp-def of RFC 3588 [RFC3588]):
The SIP-Authentication-Info AVP is defined as follows (per the grouped-avp-def of RFC 3588 [RFC3588]):
SIP-Authentication-Info ::= < AVP Header: 381 >
[ Digest-Nextnonce ]
[ Digest-QoP ]
[ Digest-Response-Auth ]
[ Digest-CNonce ]
[ Digest-Nonce-Count ]
* [ AVP ]
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.
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.
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).
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).
9.5.6. Digest AVPs
9.5.6. Digest AVPs
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.
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.
9.5.6.1. Considerations about Digest-HA1 AVP
9.5.6.1. Considerations about Digest-HA1 AVP
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.
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.
This scenario is not applicable when the Diameter server is configured to use a session MD5 (MD5-sess) algorithm, because the
This scenario is not applicable when the Diameter server is configured to use a session MD5 (MD5-sess) algorithm, because the
Garcia-Martin, et al. Standards Track [Page 53] RFC 4740 Diameter SIP Application November 2006
Garcia-Martin, et al. Standards Track [Page 53] RFC 4740 Diameter SIP Application November 2006
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 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.
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.
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.
Section 11 provides further normative details about the usage of the Digest-HA1 AVP.
Section 11 provides further normative details about the usage of the Digest-HA1 AVP.
9.5.6.2. Considerations about Digest-Entity-Body-Hash AVP
9.5.6.2. Considerations about Digest-Entity-Body-Hash 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").
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").
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.
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.
9.5.6.3. Considerations about Digest-Auth-Param AVP
9.5.6.3. Considerations about Digest-Auth-Param 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].
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].
Garcia-Martin, et al. Standards Track [Page 54] RFC 4740 Diameter SIP Application November 2006
Garcia-Martin, et al. Standards Track [Page 54] RFC 4740 Diameter SIP Application November 2006
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.
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.
9.6. SIP-Number-Auth-Items AVP
9.6. SIP-Number-Auth-Items AVP
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.
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.
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.
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.
9.7. SIP-Deregistration-Reason AVP
9.7. SIP-Deregistration-Reason AVP
The SIP-Deregistration-Reason AVP (AVP Code 383) is of type Grouped and indicates the reason for a deregistration operation.
The SIP-Deregistration-Reason AVP (AVP Code 383) is of type Grouped and indicates the reason for a deregistration operation.
The SIP-Deregistration-Reason AVP is defined as follows (per the grouped-avp-def of RFC 3588 [RFC3588]):
The SIP-Deregistration-Reason AVP is defined as follows (per the grouped-avp-def of RFC 3588 [RFC3588]):
SIP-Deregistration-Reason ::= < AVP Header: 383 >
{ SIP-Reason-Code }
[ SIP-Reason-Info ]
* [ AVP ]
SIP-Deregistration-Reason ::= < AVP Header: 383 > { SIP-Reason-Code } [ SIP-Reason-Info ] * [ AVP ]
9.7.1. SIP-Reason-Code AVP
9.7.1. SIP-Reason-Code 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:
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:
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)
Garcia-Martin, et al. Standards Track [Page 55] RFC 4740 Diameter SIP Application November 2006
Garcia-Martin, et al. Standards Track [Page 55] RFC 4740 Diameter SIP Application November 2006
9.7.2. SIP-Reason-Info AVP
9.7.2. SIP-Reason-Info AVP
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.
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.
9.8. SIP-AOR AVP
9.8. SIP-AOR AVP
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).
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).
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.
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.
9.9. SIP-Visited-Network-Id AVP
9.9. SIP-Visited-Network-Id 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.
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.
9.10. SIP-User-Authorization-Type AVP
9.10. SIP-User-Authorization-Type 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:
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:
Garcia-Martin, et al. Standards Track [Page 56] RFC 4740 Diameter SIP Application November 2006
Garcia-Martin, et al. Standards Track [Page 56] RFC 4740 Diameter SIP Application November 2006
o REGISTRATION (0)
This value is used for initial registration or re-registration.
This is the default value.
o REGISTRATION (0) This value is used for initial registration or re-registration. This is the default value.
o DEREGISTRATION (1)
This value is used for deregistration.
o DEREGISTRATION (1) This value is used for deregistration.
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) 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.
9.11. SIP-Supported-User-Data-Type AVP
9.11. SIP-Supported-User-Data-Type AVP
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.
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.
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).
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).
9.12. SIP-User-Data AVP
9.12. SIP-User-Data AVP
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.
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.
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.
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.
The SIP-User-Data AVP is defined as follows (per the grouped-avp-def of RFC 3588 [RFC3588]):
The SIP-User-Data AVP is defined as follows (per the grouped-avp-def of RFC 3588 [RFC3588]):
Garcia-Martin, et al. Standards Track [Page 57] RFC 4740 Diameter SIP Application November 2006
Garcia-Martin, et al. Standards Track [Page 57] RFC 4740 Diameter SIP Application November 2006
SIP-User-Data ::= < AVP Header: 389 >
{ SIP-User-Data-Type }
{ SIP-User-Data-Contents }
* [ AVP ]
SIP-User-Data ::= < AVP Header: 389 > { SIP-User-Data-Type } { SIP-User-Data-Contents } * [ AVP ]
9.12.1. SIP-User-Data-Type AVP
9.12.1. SIP-User-Data-Type 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).
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).
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).
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).
9.12.2. SIP-User-Data-Contents AVP
9.12.2. SIP-User-Data-Contents AVP
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.
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.
The AVP contains the user profile data required for a SIP server to give service to the user.
The AVP contains the user profile data required for a SIP server to give service to the user.
9.13. SIP-User-Data-Already-Available AVP
9.13. SIP-User-Data-Already-Available AVP
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:
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:
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) The Diameter client (SIP server) does not have the data that it needs to serve the user.
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) The Diameter client (SIP server) already has received the data that it needs to serve the user.
Garcia-Martin, et al. Standards Track [Page 58] RFC 4740 Diameter SIP Application November 2006
Garcia-Martin, et al. Standards Track [Page 58] RFC 4740 Diameter SIP Application November 2006
9.14. SIP-Method AVP
9.14. SIP-Method AVP
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.
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.
10. New Values for Existing AVPs
10. New Values for Existing AVPs
This section defines new values that the Diameter SIP application extends to already existing AVPs.
This section defines new values that the Diameter SIP application extends to already existing AVPs.
10.1. Extension to the Result-Code AVP Values
10.1. Extension to the Result-Code AVP Values
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:
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:
10.1.1. Success Result-Code AVP Values
10.1.1. Success Result-Code AVP Values
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.
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.
o DIAMETER_FIRST_REGISTRATION 2003
The user was not previously registered. The Diameter server has
now authorized the registration.
o DIAMETER_FIRST_REGISTRATION 2003 The user was not previously registered. The Diameter server has now authorized the registration.
o DIAMETER_SUBSEQUENT_REGISTRATION 2004
The user is already registered. The Diameter server has now
authorized the re-registration.
o DIAMETER_SUBSEQUENT_REGISTRATION 2004 The user is already registered. The Diameter server has now authorized the re-registration.
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 The user is not currently registered, but the requested service can still be granted to the user.
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 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_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 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.
Garcia-Martin, et al. Standards Track [Page 59] RFC 4740 Diameter SIP Application November 2006
Garcia-Martin, et al. Standards Track [Page 59] RFC 4740 Diameter SIP Application November 2006
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 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.
10.1.2. Transient Failures Result-Code AVP Values
10.1.2. Transient Failures Result-Code AVP Values
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.
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.
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 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.
10.1.3. Permanent Failures Result-Code AVP Values
10.1.3. Permanent Failures Result-Code AVP Values
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.
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.
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 The SIP-AOR AVP value does not belong to a known user in this realm.
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 The value in one of the SIP-AOR AVPs is not allocated to the user specified in the User-Name 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 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_ROAMING_NOT_ALLOWED 5035
The user is not allowed to roam to the visited network.
o DIAMETER_ERROR_ROAMING_NOT_ALLOWED 5035 The user is not allowed to roam to the visited network.
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 The identity being registered has already been assigned a server and the registration status does not allow that it is overwritten.
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 The authentication scheme indicated in an authentication request is not supported.
Garcia-Martin, et al. Standards Track [Page 60] RFC 4740 Diameter SIP Application November 2006
Garcia-Martin, et al. Standards Track [Page 60] RFC 4740 Diameter SIP Application November 2006
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 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_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 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_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 The SIP server informs the Diameter server that the received subscription data contained information that was not recognized or supported.
11. Authentication Details
11. Authentication Details
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.
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.
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.
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.
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.
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.
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
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
Garcia-Martin, et al. Standards Track [Page 61] RFC 4740 Diameter SIP Application November 2006
Garcia-Martin, et al. Standards Track [Page 61] RFC 4740 Diameter SIP Application November 2006
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.
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.
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.
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.
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.
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.
It must be noted that nonces are always generated in the Diameter server.
It must be noted that nonces are always generated in the Diameter server.
Garcia-Martin, et al. Standards Track [Page 62] RFC 4740 Diameter SIP Application November 2006
Garcia-Martin, et al. Standards Track [Page 62] RFC 4740 Diameter SIP Application November 2006
12. Migration from RADIUS
12. Migration from RADIUS
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 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.
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.
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.
The following sections discuss several configurations in which a gateway translates RADIUS to Diameter and vice versa.
The following sections discuss several configurations in which a gateway translates RADIUS to Diameter and vice versa.
12.1. Gateway from RADIUS Client to Diameter Server
12.1. Gateway from RADIUS Client to Diameter Server
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.
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.
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.
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.
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.
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.
12.2. Gateway from Diameter Client to RADIUS Server
12.2. Gateway from Diameter Client to RADIUS Server
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
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
Garcia-Martin, et al. Standards Track [Page 63] RFC 4740 Diameter SIP Application November 2006
Garcia-Martin, et al. Standards Track [Page 63] RFC 4740 Diameter SIP Application November 2006
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.
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.
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.
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.
12.3. Known Limitations
12.3. Known Limitations
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.
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.
13. IANA Considerations
13. IANA Considerations
This document serves as IANA registration request for a number of items that should be registered in the AAA parameters registry.
This document serves as IANA registration request for a number of items that should be registered in the AAA parameters registry.
13.1. Application Identifier
13.1. Application Identifier
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:
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:
ID values Name Reference
----------- ------------------------ ---------
6 Diameter Session Initiation RFC 4740
Protocol (SIP) Application
ID values Name Reference ----------- ------------------------ --------- 6 Diameter Session Initiation RFC 4740 Protocol (SIP) Application
Garcia-Martin, et al. Standards Track [Page 64] RFC 4740 Diameter SIP Application November 2006
Garcia-Martin, et al. Standards Track [Page 64] RFC 4740 Diameter SIP Application November 2006
13.2. Command Codes
13.2. Command Codes
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.
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.
Table 1 in Section 8 contains the detailed list of Command Code names and values that are part of this Diameter application.
Table 1 in Section 8 contains the detailed list of Command Code names and values that are part of this Diameter application.
13.3. AVP Codes
13.3. AVP Codes
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.
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.
Table 2 in Section 9 contains the detailed list of AVP names and AVP codes that are part of this Diameter application.
Table 2 in Section 9 contains the detailed list of AVP names and AVP codes that are part of this Diameter application.
13.4. Additional Values for the Result-Code AVP Value
13.4. Additional Values for the Result-Code AVP Value
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.
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.
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.
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.
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.
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.
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.
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.
Garcia-Martin, et al. Standards Track [Page 65] RFC 4740 Diameter SIP Application November 2006
Garcia-Martin, et al. Standards Track [Page 65] RFC 4740 Diameter SIP Application November 2006
13.5. Creation of the SIP-Server-Assignment-Type Section in the AAA
Registry
13.5. Creation of the SIP-Server-Assignment-Type Section in the AAA Registry
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.
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.
13.6. Creation of the SIP-Authentication-Scheme Section in the AAA
Registry
13.6. Creation of the SIP-Authentication-Scheme Section in the AAA Registry
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.
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.
13.7. Creation of the SIP-Reason-Code Section in the AAA Registry
13.7. Creation of the SIP-Reason-Code Section in the AAA Registry
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.
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.
13.8. Creation of the SIP-User-Authorization-Type Section in the AAA
Registry
13.8. Creation of the SIP-User-Authorization-Type Section in the AAA Registry
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.
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.
13.9. Creation of the SIP-User-Data-Already-Available Section in the
AAA Registry
13.9. Creation of the SIP-User-Data-Already-Available Section in the AAA Registry
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.
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.
Garcia-Martin, et al. Standards Track [Page 66] RFC 4740 Diameter SIP Application November 2006
Garcia-Martin, et al. Standards Track [Page 66] RFC 4740 Diameter SIP Application November 2006
14. Security Considerations
14. Security Considerations
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.
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.
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.
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.
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.
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.
14.1. Final Authentication Check in the Diameter Client/SIP Server
14.1. Final Authentication Check in the Diameter Client/SIP Server
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:
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:
o Both Diameter client and server must trust each other, such as
when both client and server belong to the same administrative
domain.
o Both Diameter client and server must trust each other, such as when both client and server belong to the same administrative domain.
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 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.
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.
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.
Garcia-Martin, et al. Standards Track [Page 67] RFC 4740 Diameter SIP Application November 2006
Garcia-Martin, et al. Standards Track [Page 67] RFC 4740 Diameter SIP Application November 2006
15. Contributors
15. Contributors
The authors would like to thank the following contributors who made substantial contributions to this work:
The authors would like to thank the following contributors who made substantial contributions to this work:
Pete McCann Lucent
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) provided the text in Section 12, "Migration from RADIUS".
16. Acknowledgements
16. Acknowledgements
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.
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.
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.
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.
17. References
17. References
17.1. Normative References
17.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[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., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[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., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[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., and V. Torvinen, "Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)", RFC 3310, September 2002.
Garcia-Martin, et al. Standards Track [Page 68] RFC 4740 Diameter SIP Application November 2006
Garcia-Martin, et al. Standards Track [Page 68] RFC 4740 Diameter SIP Application November 2006
[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., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[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., and W. Beck, "RADIUS Extension for Digest Authentication", RFC 4590, July 2006.
17.2. Informative References
17.2. Informative References
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.1", RFC 4346, April
2006.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[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, March 2004.
[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., and H. Schulzrinne, "Call Processing Language (CPL): A Language for User Control of Internet Telephony Services", RFC 3880, October 2004.
[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., and P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, August 2005.
[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., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005.
[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., and J. Loughney, "Diameter Credit-Control Application", RFC 4006, August 2005.
[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, "Cx and Dx interfaces based on the Diameter protocol; Protocol details", 3GPP TS 29.229 5.12.0, June 2006.
[JSR-000116] Java Community Process, "SIP Servlet API Specification
1.0 Final Release", JSR 000116, March 2003.
[JSR-000116] Java Community Process, "SIP Servlet API Specification 1.0 Final Release", JSR 000116, March 2003.
Garcia-Martin, et al. Standards Track [Page 69] RFC 4740 Diameter SIP Application November 2006
Garcia-Martin, et al. Standards Track [Page 69] RFC 4740 Diameter SIP Application November 2006
Authors' Addresses
Authors' Addresses
Miguel A. Garcia-Martin (Editor) Nokia P.O. Box 407 NOKIA GROUP, FIN 00045 Finland
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
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 Madrid 28033 Spain
Phone: +34 91 339 3535 EMail: maria.carmen.belinchon@ericsson.com
Phone: +34 91 339 3535 EMail: maria.carmen.belinchon@ericsson.com
Miguel A. Pallares-Lopez Ericsson Via de los Poblados 13 Madrid 28033 Spain
Miguel A. Pallares-Lopez Ericsson Via de los Poblados 13 Madrid 28033 Spain
Phone: +34 91 339 4222 EMail: miguel-angel.pallares@ericsson.com
Phone: +34 91 339 4222 EMail: miguel-angel.pallares@ericsson.com
Carolina Canales-Valenzuela Ericsson Via de los Poblados 13 Madrid 28033 Spain
Carolina Canales-Valenzuela Ericsson Via de los Poblados 13 Madrid 28033 Spain
Phone: +34 91 339 2680 EMail: carolina.canales@ericsson.com
Phone: +34 91 339 2680 EMail: carolina.canales@ericsson.com
Garcia-Martin, et al. Standards Track [Page 70] RFC 4740 Diameter SIP Application November 2006
Garcia-Martin, et al. Standards Track [Page 70] RFC 4740 Diameter SIP Application November 2006
Kalle Tammi Nokia P.O.Box 785 Tampere 33101 Finland
Kalle Tammi Nokia P.O.Box 785 Tampere 33101 Finland
Phone: +358 40 505 8670 EMail: kalle.tammi@nokia.com
Phone: +358 40 505 8670 EMail: kalle.tammi@nokia.com
Garcia-Martin, et al. Standards Track [Page 71] RFC 4740 Diameter SIP Application November 2006
Garcia-Martin, et al. Standards Track [Page 71] RFC 4740 Diameter SIP Application November 2006
Full Copyright Statement
Full Copyright Statement
Copyright (C) The IETF Trust (2006).
Copyright (C) The 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.
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.
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.
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.
Intellectual Property
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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はこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Garcia-Martin, et al. Standards Track [Page 72]
ガルシア-マーチン、他 標準化過程[72ページ]
一覧
スポンサーリンク
