RFC4083 日本語訳
4083 Input 3rd-Generation Partnership Project (3GPP) Release 5Requirements on the Session Initiation Protocol (SIP). M.Garcia-Martin. May 2005. (Format: TXT=80203 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Garcia-Martin Request for Comments: 4083 Nokia Category: Informational May 2005
コメントを求めるワーキンググループM.ガルシア-マーチンの要求をネットワークでつないでください: 4083年のノキアカテゴリ: 情報の2005年5月
Input 3rd-Generation Partnership Project (3GPP)
Release 5 Requirements on the Session Initiation Protocol (SIP)
セッション開始プロトコルに関する入力第3世代パートナーシッププロジェクト(3GPP)リリース5要件(一口)
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
The 3rd-Generation Partnership Project (3GPP) has selected Session Initiation Protocol (SIP) as the session establishment protocol for the 3GPP IP Multimedia Core Network Subsystem (IMS). IMS is part of Release 5 of the 3GPP specifications. Although SIP is a protocol that fulfills most of the requirements for establishing a session in an IP network, SIP has never been evaluated against the specific 3GPP requirements for operation in a cellular network. In this document, we express the requirements identified by 3GPP to support SIP for Release 5 of the 3GPP IMS in cellular networks.
セッション設立が3GPP IP Multimedia Core Network Subsystem(IMS)のために議定書を作るとき、第3世代Partnership Project(3GPP)はSession Initiationプロトコル(SIP)を選択しました。 IMSは3GPP仕様のRelease5の一部です。 SIPはIPネットワークにセッションを確立するための要件の大部分を実現させるプロトコルですが、操作のための特定の3GPP要件に対してSIPはセルラー・ネットワークで一度も評価されたことがありません。 本書では、私たちは3GPP IMSのRelease5のためにセルラー・ネットワークでSIPをサポートするために3GPPによって特定された要件を言い表します。
Garcia-Martin Informational [Page 1] RFC 4083 3GPP R5 Requirements on SIP May 2005
一口2005年5月に関するガルシア-マーチンの情報[1ページ]のRFC4083 3GPP R5要件
Table of Contents
目次
1. Introduction ....................................................4
2. Conventions .....................................................4
3. Overview of the 3GPP IMS ........................................5
4. 3GPP Requirements on SIP ........................................7
4.1. General Requirements .......................................7
4.1.1. Efficient Use of the Radio Interface ................7
4.1.2. Minimum Session Setup Time ..........................7
4.1.3. Minimum Support Required in the Terminal ............8
4.1.4. Roaming and Non-roaming .............................8
4.1.5. Terminal Mobility Management ........................8
4.1.6. IP Version 6 ........................................8
4.2. SIP Outbound Proxy .........................................8
4.2.1. SIP Outbound Proxy ..................................8
4.2.2. Discovery of the SIP Outbound Proxy .................8
4.3. Registration ...............................................9
4.3.1. Registration Required ...............................9
4.3.2. Efficient Registration .............................10
4.3.3. Registration for Roaming and Non-roaming Cases .....10
4.3.4. Visited Domain Name ................................10
4.3.5. De-registration ....................................10
4.4. SIP Compression ...........................................11
4.4.1. Compression Algorithm Independence .................12
4.4.2. Extensibility of the SIP Compression ...............12
4.4.3. Minimal Impact of SIP Compression on the Network ...12
4.4.4. Optionality of SIP Compression .....................12
4.5. QoS Requirements Related to SIP ...........................13
4.5.1. Independence between QoS Signaling and SIP .........13
4.5.2. Coordination between SIP and QoS/Resource
Allocation .........................................13
4.6. Prevention of Theft of Service ............................14
4.7. Radio Resource Authorization ..............................14
4.8. Prevention of Malicious Usage .............................14
4.9. Prevention of Denial of Service ...........................14
4.10. Identification of Users ..................................15
4.10.1. Private User Identity ............................15
4.10.2. Public User Identities ...........................15
4.10.3. Delivery of the Dialed Public User ID ............17
4.11. Identifiers Used for Routing .............................17
4.12. Hiding Requirements ......................................17
4.12.1. Hiding of the Network Structure ..................17
4.12.2. Hiding of IP Addresses ...........................17
4.12.3. SIP Hiding Proxy .................................18
4.13. Cell-ID ..................................................18
4.13.1. Cell-ID in Signaling from the UA to the
Visited and Home .................................18
4.13.2. Format of the Cell-ID ............................18
1. 序論…4 2. コンベンション…4 3. 3GPP IMSの概要…5 4. 一口に関する3GPP要件…7 4.1. 一般要件…7 4.1.1. ラジオインタフェースの効率的な使用…7 4.1.2. 最小のセッション準備時間…7 4.1.3. 最小のサポートが端末で必要です…8 4.1.4. ローミングと非ローミング…8 4.1.5. 端末の移動性管理…8 4.1.6. IPバージョン6…8 4.2. 外国行きのプロキシをちびちび飲んでください…8 4.2.1. 外国行きのプロキシをちびちび飲んでください…8 4.2.2. 一口の外国行きのプロキシの発見…8 4.3. 登録…9 4.3.1. 登録が必要です…9 4.3.2. 効率的な登録…10 4.3.3. ローミングのための登録と非ローミングケース…10 4.3.4. ドメイン名を訪問します…10 4.3.5. 反-登録…10 4.4. 圧縮をちびちび飲んでください…11 4.4.1. 圧縮アルゴリズム独立…12 4.4.2. 一口圧縮の伸展性…12 4.4.3. ネットワークにおける一口圧縮の最小量の影響…12 4.4.4. 一口圧縮のOptionality…12 4.5. QoS要件は一口に関連しました…13 4.5.1. QoSシグナリングと一口の間の独立…13 4.5.2. 一口とQoS/資源配分の間のコーディネート…13 4.6. サービスの窃盗の防止…14 4.7. ラジオリソース承認…14 4.8. 悪意がある用法の防止…14 4.9. サービス妨害の防止…14 4.10. ユーザの識別…15 4.10.1. 個人的なユーザのアイデンティティ…15 4.10.2. 公共のユーザのアイデンティティ…15 4.10.3. ダイヤルされた公共のユーザIDの配送…17 4.11. ルート設定に使用される識別子…17 4.12. 要件を隠します…17 4.12.1. ネットワーク構造の隠れること…17 4.12.2. IPアドレスの隠れること…17 4.12.3. 隠れることプロキシをちびちび飲んでください…18 4.13. Cell ID…18 4.13.1. UAから訪問まで合図することにおけるCell IDとホーム…18 4.13.2. Cell IDの形式…18
Garcia-Martin Informational [Page 2] RFC 4083 3GPP R5 Requirements on SIP May 2005
一口2005年5月に関するガルシア-マーチンの情報[2ページ]のRFC4083 3GPP R5要件
4.14. Release of Sessions ......................................18
4.14.1. Ungraceful Session Release .......................19
4.14.2. Graceful Session Release .........................19
4.15. Routing of SIP Messages ..................................20
4.15.1. SIP Outbound Proxy ...............................20
4.15.2. SIP Serving Proxy in the Home Network ............20
4.15.3. INVITE Might Follow a Different Path than
REGISTER .........................................20
4.15.4. SIP Inbound Proxy ................................20
4.15.5. Distribution of the Source Routing Set of
Proxies ..........................................21
4.16. Emergency Sessions .......................................21
4.17. Identities Used for Session Establishment ................21
4.17.1. Remote Party Identification Presentatio ..........21
4.17.2. Remote Party Identification Privacy ..............21
4.17.3. Remote Party Identification Blocking .............21
4.17.4. Anonymity ........................................22
4.17.5. Anonymous Session Establishment ..................22
4.18. Charging .................................................22
4.18.1. Support of Both Prepaid and Postpaid Models ......22
4.18.2. Charging Correlation Levels ......................23
4.18.3. Charging Correlation Principles ..................23
4.18.4. Collection of Session Detailed Information .......24
4.19. General Support of Additional Capabilities ...............24
4.19.1. Additional Capabilities ..........................24
4.19.2. DTMF Signaling ...................................24
4.19.3. Early Media ......................................25
4.20. Exchange of Session Description ..........................25
4.21. Prohibition of Certain SDP Parameters ....................26
4.21.1. Prohibition of Codecs ............................26
4.21.2. Prohibition of Media Types .......................26
4.22. Network-initiated Re-authentication ......................26
4.23. Security Model ...........................................27
4.24. Access Domain Security ...................................28
4.24.1. General Requirements .............................28
4.24.2. Authentication ...................................29
4.24.3. Message Protection ...............................29
4.24.4. Negotiation of Mechanisms ........................31
4.24.5. Verification of Messages .........................31
4.25. Network Domain Security ..................................32
5. Security Considerations ........................................32
6. Contributors ...................................................32
7. References .....................................................32
7.1. Normative References ......................................32
7.2. Informative References ....................................33
4.14. セッションのリリース…18 4.14.1. 無様なセッションリリース…19 4.14.2. 優雅なセッションリリース…19 4.15. 一口メッセージのルート設定…20 4.15.1. 外国行きのプロキシをちびちび飲んでください…20 4.15.2. ホームネットワークにプロキシに役立って、ちびちび飲んでください…20 4.15.3. 招待は登録するより異なる道を歩むかもしれません…20 4.15.4. 本国行きのプロキシをちびちび飲んでください…20 4.15.5. プロキシのソースルート設定セットの分配…21 4.16. 非常時のセッション…21 4.17. アイデンティティはセッションに設立を使用しました…21 4.17.1. リモート政党帰属意識Presentatio…21 4.17.2. リモート政党帰属意識プライバシー…21 4.17.3. リモート政党帰属意識ブロッキング…21 4.17.4. 匿名…22 4.17.5. 匿名のセッション設立…22 4.18. 充電します…22 4.18.1. 前払いの、そして、郵便前払いの両方のモデルのサポート…22 4.18.2. 充電相関関係レベル…23 4.18.3. 相関関係プリンシプルズを請求します…23 4.18.4. セッションの収集は情報を詳しく述べました…24 4.19. 追加能力の一般サポート…24 4.19.1. 追加能力…24 4.19.2. DTMFシグナリング…24 4.19.3. 早めのメディア…25 4.20. セッション記述の交換…25 4.21. あるSDPパラメタの禁止…26 4.21.1. コーデックの禁止…26 4.21.2. メディアタイプの禁止…26 4.22. ネットワークによって開始された再認証…26 4.23. セキュリティはモデル化されます…27 4.24. ドメインセキュリティにアクセスしてください…28 4.24.1. 一般要件…28 4.24.2. 認証…29 4.24.3. メッセージ保護…29 4.24.4. メカニズムの交渉…31 4.24.5. メッセージの検証…31 4.25. ドメインセキュリティをネットワークでつないでください…32 5. セキュリティ問題…32 6. 貢献者…32 7. 参照…32 7.1. 標準の参照…32 7.2. 有益な参照…33
Garcia-Martin Informational [Page 3] RFC 4083 3GPP R5 Requirements on SIP May 2005
一口2005年5月に関するガルシア-マーチンの情報[3ページ]のRFC4083 3GPP R5要件
1. Introduction
1. 序論
3GPP has selected SIP [2] as the protocol to establish and tear down multimedia sessions in the IP Multimedia Subsystem (IMS). 3GPP Technical Specification 23.228 [28] describes the IMS. 3GPP Technical Specification 24.228 [29] contains a comprehensive set of session flows. 3GPP Technical Specification 24.229 [30] describes the usage of SIP by the various IMS nodes.
3GPPは、プロトコルとしてのSIP[2]がIP Multimedia Subsystem(IMS)でマルチメディアセッションを確立して、取りこわすのを選択しました。 3GPP仕様書23.228[28]はIMSについて説明します。3GPP仕様書24.228[29]は包括的なセッション流れを含んでいます。 3GPP仕様書24.229[30]は様々なIMSノードでSIPの使用法を説明します。
This document is an effort to define the requirements applicable to the usage of the SIP protocol suite in cellular networks, particularly in the 3GPP IMS for Release 5 of the 3GPP specifications. Further releases of the 3GPP specifications may contain additional SIP requirements. This document focuses on the requirements identified for the 3GPP Release 5 IMS.
このドキュメントはセルラー・ネットワークでSIPプロトコル群の使用法に適切な要件を定義する取り組みです、特に3GPP仕様のRelease5のための3GPP IMSで。 3GPP仕様のさらなるリリースは追加SIP要件を含むかもしれません。 このドキュメントは3GPP Release5IMSのために特定された要件に焦点を合わせます。
The rest of this document is structured as follows:
このドキュメントの残りは以下の通り構造化されます:
o Section 3 offers an overview of the 3GPP IMS. Readers who are not
familiar with it should carefully read this section.
o セクション3は3GPP IMSの概要を提供します。それに詳しくない読者はこのセクションを注意して読むべきです。
o Section 4 contains the 3GPP requirements to SIP. Requirements are
grouped by category. Some requirements include statements on
possible solutions that would be able to fulfill them. Note that,
as a particular requirement might be fulfilled by different
solutions, not all the solutions might have an impact on SIP.
o セクション4は3GPP要件をSIPに含みます。 要件はカテゴリによって分類されます。 いくつかの要件がそれらを実現させることができる可能なソリューションに関する声明を含んでいます。 特定の要件が異なったソリューションで実現するかもしれないときすべてのソリューションがSIPに影響を与えるかもしれないというわけではないことに注意してください。
This document is advisory in nature. Its primary purpose is to help the IETF understand the IMS environment. Given this better understanding, we expect that the IETF can more effectively evolve the SIP protocol. The IETF will not respond to the requirements given in this document on a point-for-point basis. Some requirements have been and/or will be met by extensions to the SIP protocol. Others may be addressed by effectively using existing capabilities in SIP or other protocols, and we expect that individual members of the SIP community will work with 3GPP to achieve a better understanding of these mechanisms. Some of the requirements in this document may not be addressed at all by the IETF, although we believe that the act of documenting and discussing them is in itself helpful in achieving a better all-around understanding of the task at hand.
このドキュメントは現実に顧問です。 プライマリ目的はIETFがIMS環境を理解しているのを助けることです。 このより良い理解を考えて、私たちは、IETFが、より効果的にSIPプロトコルを発展できると予想します。 IETFは本書ではポイントポイントベースで与えられた要件に応じないでしょう。 いくつかの必要条件が、あった、そして/または、SIPプロトコルへの拡大で満たされるでしょう。 他のものは事実上、SIPか他のプロトコルに既存の能力を使用することによって、宛てられるかもしれません、そして、私たちはSIP共同体の個人会員がこれらのメカニズムの、より良い理解を達成するために3GPPと共に働くと予想します。要件のいくつかがIETFによって本書では全く扱われないかもしれません、私たちは、それらについて記録して、議論する行為に本来手元のタスクの、より良い統合的な理解を達成する際に役立っていると信じていますが。
2. Conventions
2. コンベンション
This document does not specify any protocol of any kind. Therefore, the usage of the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document, as described in RFC 2119 [1], does not apply.
このドキュメントはどんな種類のどんなプロトコルも指定しません。 したがって、キーワードの用法“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「」 RFC2119[1]で「5月」、「推薦され」て、説明されるとしてのこのドキュメントで「任意」が適用しないNOTはそうするべきです。
Garcia-Martin Informational [Page 4] RFC 4083 3GPP R5 Requirements on SIP May 2005
一口2005年5月に関するガルシア-マーチンの情報[4ページ]のRFC4083 3GPP R5要件
3. Overview of the 3GPP IMS
3. 3GPP IMSの概要
This section gives the reader an overview of the 3GPP IM CN Subsystem (IMS). It is not intended to be comprehensive, but it provides enough information to understand the basis of the 3GPP IMS. Readers are encouraged to find a more detailed description in the 3GPP Technical Specifications 23.060 [27], 23.228 [28], and 24.228 [29].
このセクションは3GPP IM CN Subsystem(IMS)の概要を読者に与えます。 それが包括的であることを意図しませんが、それは3GPP IMSの基礎を理解できるくらいの情報を前提とします。読者が3GPP仕様書23.060[27]、23.228[28]、および24.228[29]における、より詳細な記述を見つけるよう奨励されます。
For a particular cellular device, the 3GPP IMS network is further decomposed in a home network and a visited network.
特定のセルデバイスに関しては、3GPP IMSネットワークはホームネットワークと訪問されたネットワークでさらに分解されます。
An IMS subscriber belongs to his or her home network. Services are triggered and may be executed in the home network. One or more SIP servers are deployed in the SIP home network to support the IP Multimedia Subsystem. Among those SIP servers, there is a SIP serving proxy, which is also acting as a SIP registrar. Authentication/Authorization servers may be part of the home network as well. Users are authenticated in the home network.
IMS加入者はその人のホームネットワークに属します。 サービスは、引き起こされて、ホームネットワークで実行されるかもしれません。 1つ以上のSIPサーバが、IP Multimedia SubsystemをサポートするためにSIPホームネットワークで配布されます。 それらのSIPサーバの中に、プロキシに役立つSIPがあります。(また、SIPはSIP記録係として務めています)。 認証/承認サーバはまた、ホームネットワークの一部であるかもしれません。 ユーザはホームネットワークで認証されます。
A SIP outbound proxy is provided to support the User Agent (UA). The SIP outbound proxy is typically located in the visited network, although it may be located in the home network as well. The SIP outbound proxy maintains security associations between itself and the terminals, and interworks with the resource management in the packet network.
Userがエージェント(UA)であるとサポートするためにSIPの外国行きのプロキシを提供します。 SIPの外国行きのプロキシは訪問されたネットワークで通常位置しています、それがまた、ホームネットワークで位置するかもしれませんが。 SIPの外国行きのプロキシは、それ自体と端末とのセキュリティ協会を維持して、中に資源管理があるパケット網を織り込みます。
The SIP outbound proxy is assigned after the mobile device has connected to the access network. Once this proxy is assigned, it does not change while the mobile remains connected to the access network. Thus the mobile can move freely within the access network without SIP outbound proxy reassignment.
モバイル機器がアクセスネットワークに接続した後にSIPの外国行きのプロキシは選任されます。 このプロキシがいったん選任されると、モバイルがアクセスネットワークに関連していたままで残っている間、それは変化しません。 したがって、モバイルはアクセスネットワークの中でSIPの外国行きのプロキシ再割当てなしで自由に移行できます。
The home network may also support one or more SIP edge proxies. These nodes may act as the first entry points for SIP signaling to the home network and may determine (with the help of location servers) which SIP registrar server to assign to a particular user. Typically the address of the home network SIP edge proxy is configured in DNS in the form of a DNS Naming Authority Pointer (NAPTR) and Service (SRV) records for SIP.
また、ホームネットワークは、1つ以上のSIP縁がプロキシであるとサポートするかもしれません。 これらのノードは、初記入がホームネットワークに合図するSIPのために指すとき行動して、どのSIP記録係サーバを特定のユーザに割り当てたらよいかを決定するかもしれません(位置のサーバの助けで)。 通常、ホームネットワークSIP縁のプロキシのアドレスはSIPのためのDNS Naming Authority Pointer(NAPTR)とService(SRV)記録の形でDNSで構成されます。
Additionally, home and visited networks may deploy, if required, a SIP-hiding proxy. The main purpose of the SIP-hiding proxy is to hide the network configuration.
さらに、ホームと訪問されたネットワークは必要なら、SIPを隠しているプロキシを配布するかもしれません。 SIP-隠れることプロキシの主な目的はネットワーク・コンフィギュレーションを隠すことです。
The 3GPP IM CN Subsystem is designed to be access independent. Access is granted from 3GPP cellular terminals or from other terminals that use other accesses out of the scope of 3GPP.
3GPP IM CN Subsystemは、アクセス独立者になるように設計されています。 アクセスは3GPPのセル端末、または、3GPPの範囲から他のアクセスを使用する他の端末から承諾されます。
Garcia-Martin Informational [Page 5] RFC 4083 3GPP R5 Requirements on SIP May 2005
一口2005年5月に関するガルシア-マーチンの情報[5ページ]のRFC4083 3GPP R5要件
3GPP cellular IP Multimedia terminals use the existing General Packet Radio Service (GPRS) [27] as a transport network for IP datagrams. The terminals first connect to the GPRS network to get an IPv6 prefix. In order to do this, the terminals must perform a GPRS Attach procedure followed by a GPRS PDP Context Activation procedure. These GPRS procedures are required to be completed before any IP Multimedia session can be established.
3GPPのセルIP Multimedia端末はIPデータグラムに転送ネットワークとして既存の汎用パケット無線システム(GPRS)[27]を使用します。端末は、最初に、IPv6接頭語を得るためにGPRSネットワークに接続します。 これをするために、端末はGPRS Attach手順を実行しなければなりません、続いて、GPRS PDP Context Activation手順を実行します。 これらのGPRS手順が、どんなIP Multimediaセッションも確立できる前に完成されるのに必要です。
As a result of the above-mentioned GPRS procedures, the terminal has built an IPv6 address. The IPv6 address belongs to the same network address space as does the SIP outbound proxy. The address does not change, as the mobile terminal moves while still attached to the same network address space.
上記のGPRS手順の結果、端末はIPv6アドレスを造りました。 IPv6アドレスはSIPの外国行きのプロキシのように同じネットワークアドレス空間に属します。 移動体端末がまだ同じネットワークアドレス空間に付けられている間移行するとき、アドレスは変化しません。
If the terminal moves from a GPRS access to another GPRS access, the above-mentioned GPRS procedures needs to start from the beginning to allocate an IPv6 address to the terminal.
端末がGPRSから移行するなら、IPv6アドレスを始めから端末に割り当て始める必要性に別のGPRSアクセス、上記のGPRS手順にアクセスしてください。
Figure 1 shows an overview of the 3GPP architecture for IM CN Subsystem.
図1はIM CN Subsystemのために3GPPアーキテクチャの概要を示しています。
+-------------+ +----------------+ +----------------+
| | | | | +------+ |
| | | | | | SIP | |
| | | | | |server| |
| | | | | | +------+ |
+-|+ | | | | | / |
| | | | | +------+ | | +------+ |
| | | | | | SIP | | | | SIP | |
| | ---|-------------|--|----|server|----|---|-|server| |
+--+ | | | +------+ | | +------+ |
| | | | | |
SIP | GPRS access | | Visited Network| | Home Network |
dev. +-------------+ +----------------+ +----------------+
+-------------+ +----------------+ +----------------+ | | | | | +------+ | | | | | | | 一口| | | | | | | |サーバ| | | | | | | | +------+ | +-|+ | | | | | / | | | | | | +------+ | | +------+ | | | | | | | 一口| | | | 一口| | | | ---|-------------|--|----|サーバ|----|---|-|サーバ| | +--+ | | | +------+ | | +------+ | | | | | | | 一口| GPRSアクセス| | 訪問されたネットワーク| | ホームネットワーク| dev。 +-------------+ +----------------+ +----------------+
Figure 1: Overview of the 3GPP IMS architecture
図1: 3GPP IMSアーキテクチャの概要
Another possible future configuration is depicted in Figure 2. In that case, a general-purpose computer (e.g., a laptop computer) is connected to a GPRS terminal. The computer hosts the Multimedia application (comprising SIP, SDP, RTP, etc.). The GPRS terminal handles the radio access and the GPRS connectivity. Note that, for the sake of clarity, in this example the home network has not been depicted in the figure.
別の可能な将来の構成は図2に表現されます。 その場合、汎用計算機(例えば、ラップトップコンピュータ)はGPRS端末に接続されます。 コンピュータはMultimediaアプリケーションを主催します(SIP、SDP、RTPなどを包括して)。 GPRS端末はラジオアクセスとGPRSの接続性を扱います。 ホームネットワークが明快のために図にこの例では、表現されていないことに注意してください。
Garcia-Martin Informational [Page 6] RFC 4083 3GPP R5 Requirements on SIP May 2005
一口2005年5月に関するガルシア-マーチンの情報[6ページ]のRFC4083 3GPP R5要件
+-------------+ +----------------+
+-------+ | | | | |
| | +-|+ | | | |
| | | | | | | +------+ |
+-------+ | | | | | | SIP | |
/ / --------| | ---|-------------|-------|server|------
/-------/ +--+ | | | +------+ |
| | | |
SIP GPRS | GPRS access | | Visited Network|
client terminal +-------------+ +----------------+
+-------------+ +----------------+ +-------+ | | | | | | | +-|+ | | | | | | | | | | | +------+ | +-------+ | | | | | | 一口| | / / --------| | ---|-------------|-------|サーバ|------ /-------/ +--+ | | | +------+ | | | | | 一口GPRS| GPRSアクセス| | 訪問されたネットワーク| クライアント端末+-------------+ +----------------+
Figure 2: A computer connected to a GPRS terminal
図2: GPRS端末に接続されたコンピュータ
Services are typically executed in an application server. The interface between the SIP server and the application server is based on SIP. However, certain operators may want to reuse the existing technology, and therefore, they may need to interoperate SIP with protocols such as CAMEL/Intelligent-Network or Open Services Architecture (OSA).
サービスはアプリケーション・サーバーで通常実行されます。SIPサーバとアプリケーション・サーバーとのインタフェースはSIPに基づいています。 しかしながら、確信しているオペレータは既存の技術を再利用したがっているかもしれません、そして、したがって、彼らは知的なCAMEL/ネットワークかオープンServices Architecture(OSA)などのプロトコルでSIPを共同利用する必要があるかもしれません。
4. 3GPP Requirements on SIP
4. 一口に関する3GPP要件
4.1. General Requirements
4.1. 一般要件
This section does not specify any particular requirement for SIP. However, it includes a list of general requirements that must be considered when developing solutions to particular requirements.
このセクションはSIPのためのどんな特定の要件も指定しません。 しかしながら、それは特定の要件に解決策を見いだすとき考えなければならない一般的な要件のリストを含んでいます。
4.1.1. Efficient Use of the Radio Interface
4.1.1. ラジオインタフェースの効率的な使用
The radio interface is a scarce resource. As such, the exchange of signaling messages between the mobile terminal and the network should be minimized. All the mechanisms developed should make an efficient use of the radio interface.
ラジオインタフェースは不十分なリソースです。 そういうものとして、移動体端末とネットワークの間のシグナリングメッセージの交換は最小にされるべきです。 メカニズムが開発したすべてがラジオインタフェースの効率的な使用をするべきです。
See also the related requirements in Section 4.4.
また、セクション4.4で関連する要件を見てください。
4.1.2. Minimum Session Setup Time
4.1.2. 最小のセッション準備時間
All the procedures and mechanisms should have a minimum impact on the session setup time as perceived by the user. When there is a choice between performing tasks at session establishment and prior to session establishment, then tasks should be performed prior to session establishment.
すべての手順とメカニズムには、セッション準備時間に、ユーザによって知覚されるように最小の影響力があるはずです。 セッション設立においてセッション設立の前に仕事するとき、選択があると、タスクはセッション設立の前に実行されるべきです。
See also the related requirements in Section 4.4.
また、セクション4.4で関連する要件を見てください。
Garcia-Martin Informational [Page 7] RFC 4083 3GPP R5 Requirements on SIP May 2005
一口2005年5月に関するガルシア-マーチンの情報[7ページ]のRFC4083 3GPP R5要件
4.1.3. Minimum Support Required in the Terminal
4.1.3. 最小のサポートが端末で必要です。
As terminals could be rather small devices, memory requirements, power consumption, processing power, etc., should be kept to a minimum. Mandating support for additional protocols in the terminal must meet this requirement.
端末がかなり小さいデバイスであるかもしれないので、メモリ要件、電力消費量、処理能力などは最小限に保たれるべきです。 端末の追加議定書のサポートを強制すると、この必要条件は満たされなければなりません。
4.1.4. Roaming and Non-roaming
4.1.4. ローミングと非ローミング
All the requirements must be met for both roaming and non-roaming scenarios. There should not be a significant change in the signaling procedures between roaming and non-roaming scenarios.
ローミングと非ローミングシナリオの両方のためにすべての必要条件を満たさなければなりません。 ローミングと非ローミングシナリオの間には、シグナリング手順における著しい変化があるはずがありません。
4.1.5. Terminal Mobility Management
4.1.5. 端末の移動性管理
As terminal mobility is managed by the access network, there is no need to support terminal mobility management in SIP.
端末の移動性がアクセスネットワークによって管理されるとき、端末の移動性が管理であるとサポートする必要は全くSIPにありません。
4.1.6. IP Version 6
4.1.6. IPバージョン6
3GPP IMS is solely designed to use IP version 6. As a consequence, all protocols must support IPv6 addresses.
3GPP IMSは、IPバージョン6を使用するように唯一設計されています。 結果として、すべてのプロトコルがIPv6にアドレスをサポートしなければなりません。
4.2. SIP Outbound Proxy
4.2. 外国行きのプロキシをちびちび飲んでください。
4.2.1. SIP Outbound Proxy
4.2.1. 外国行きのプロキシをちびちび飲んでください。
A SIP outbound proxy is provided to support both roaming and non-roaming scenarios. The SIP outbound proxy may be located either in the home network or in the visited network.
ローミングと非ローミングの両方にシナリオをサポートするためにSIPの外国行きのプロキシを提供します。 SIPの外国行きのプロキシはホームネットワークか訪問されたネットワークで位置するかもしれません。
4.2.2. Discovery of the SIP Outbound Proxy
4.2.2. 一口の外国行きのプロキシの発見
There must be a general mechanism whereby the mobile device (UA) learns the SIP outbound proxy address.
モバイル機器(UA)がSIPの外国行きのプロキシアドレスを学ぶ一般的機構があるに違いありません。
The DHCPv6 option for SIP servers in RFC 3319 [19] seems to fulfill the requirement.
RFC3319[19]のSIPサーバのためのDHCPv6オプションは要求にこたえるように思えます。
In addition to the above-expressed requirement, the 3GPP access network may provide the SIP outbound proxy address during access network bearer establishment. This is considered a less general mechanism, though.
上で言い表された要件に加えて、3GPPアクセスネットワークはアクセスネットワーク運搬人設立の間、SIPの外国行きのプロキシアドレスを提供するかもしれません。 もっとも、これはそれほど一般的でないメカニズムであると考えられます。
Garcia-Martin Informational [Page 8] RFC 4083 3GPP R5 Requirements on SIP May 2005
一口2005年5月に関するガルシア-マーチンの情報[8ページ]のRFC4083 3GPP R5要件
4.3. Registration
4.3. 登録
The home network must maintain one or more SIP registrars. The SIP registrar authenticates the user and registers the IP address where the user can be located.
ホームネットワークは1人以上のSIP記録係を維持しなければなりません。 SIP記録係は、ユーザを認証して、ユーザが位置できるIPアドレスを登録します。
Once the terminal is switched on, the mobile device UA reads its configuration data. This data may be stored in a SIM card or in any other memory device. The configuration data contains an identification of the home network. The device finds the SIP registrar address from the home network domain name. The terminal sends the registration through the SIP outbound proxy.
端末がいったんスイッチを入れられると、モバイル機器UAはコンフィギュレーション・データを読みます。 このデータはSIMカードかいかなる他のメモリ素子にも保存されるかもしれません。 コンフィギュレーション・データはホームネットワークの識別を含んでいます。 デバイスは、ホームネットワークドメイン名からSIPが記録係アドレスであることがわかります。 端末はSIPの外国行きのプロキシを通して登録を送ります。
In order to support the search of the registrar, the home network contains one or more SIP servers that may be configured in DNS with the NAPTR/SRV record of SIP. These are the home network edge proxies. Their mission is to serve as the first points of contact in the home network, and to decide (with the help of location servers) which SIP registrar server to assign to a particular user.
記録係の検索をサポートするために、ホームネットワークはDNSでSIPに関するNAPTR/SRV記録によって構成されるかもしれない1つ以上のSIPサーバを含んでいます。 これらはホームネットワーク縁のプロキシです。 彼らの任務は、ホームネットワークにおける最初の連絡先として機能して、どのSIP記録係サーバを特定のユーザに割り当てたらよいかを決めることになっています(位置のサーバの助けで)。
The procedures specified in RFC 3263 [10] applied to a REGISTER message seem to be sufficient to meet this requirement.
REGISTERメッセージに適用されたRFC3263[10]で指定された手順はこの必要条件を満たすために十分であるように思えます。
4.3.1. Registration Required
4.3.1. 登録が必要です。
A user must register to the IMS before he/she can receive any invitation to any sessions. In addition, it is desirable for the user to register before initiating any sessions. The following factors contribute to the rationale behind this:
その人がどんなセッションへのどんな招待も受けることができる前にユーザはIMSに登録しなければなりません。 さらに、どんなセッションも開始する前にユーザが登録するのは、望ましいです。 以下の要素はこれの後ろの原理に貢献します:
1. The SIP serving proxy in the home network needs to know when and
from which terminal the user is available, in order to route
received SIP requests for sessions and services.
1. ホームネットワークにプロキシに役立つSIPは、時であってユーザがどの端末から手があいているかを知る必要があります、セッションとサービスを求める受信されたSIP要求を発送するために。
2. The user can be pre-authenticated early so that authentication
does not contribute to post-dial delay. The procedure should not
have a penalty on the session setup time (see also the
requirement stated in Section 4.1.2).
2. 早くユーザをあらかじめ認証できるので、認証はポストダイヤル遅れに貢献しません。 手順に、セッション準備時間に、刑罰があるべきではありません(また、セクション4.1.2で述べられた要件を見てください)。
3. The user is assigned a particular serving proxy. The serving
proxy downloads the service profile for that user to trigger
services.
3. ユーザは特定の給仕プロキシに選任されます。 そのユーザがサービスの引き金となるように、給仕プロキシはサービスプロフィールをダウンロードします。
Therefore, 3GPP has mandated the mobile device UA to register before the mobile device UA initiates any session.
したがって、モバイル機器UAがどんなセッションも開始する前に3GPPは、登録するためにモバイル機器UAを強制しました。
Garcia-Martin Informational [Page 9] RFC 4083 3GPP R5 Requirements on SIP May 2005
一口2005年5月に関するガルシア-マーチンの情報[9ページ]のRFC4083 3GPP R5要件
4.3.2. Efficient Registration
4.3.2. 効率的な登録
Due to the scarce radio interface resource, a single registration must be sufficient to ensure that the mobile UA is reachable from both the home and the visited networks.
不十分なラジオインタフェースリソースのために、ただ一つの登録は、モバイルUAがホームと訪問されたネットワークの両方から届いているのを保証するために十分でなければなりません。
A single REGISTER message, addressed to the registrar, may traverse the SIP outbound proxy. This can install, if needed, soft registration states in the SIP outbound proxy.
記録係に扱われたただ一つのREGISTERメッセージはSIPの外国行きのプロキシを横断するかもしれません。 柔らかい登録は、SIPの外国行きのプロキシに必要であるならこれがインストールされることができると述べます。
4.3.3. Registration for Roaming and Non-roaming Cases
4.3.3. ローミングと非ローミングケースのための登録
Independent of whether the UA is roaming, it is desirable for the registration procedure to be the same.
UAが移動しているかどうかの如何にかかわらず、登録手順が同じであることは、望ましいです。
4.3.4. Visited Domain Name
4.3.4. 訪問されたドメイン名
The home network must be able to validate the existence of a roaming agreement between the home and the visited network. The home network needs to validate that the user is allowed to roam to such a visited network. Therefore, there must be a mechanism whereby the visited network identity is known at registration time at the home network.
ホームネットワークはホームと訪問されたネットワークとのローミング協定の存在を有効にすることができなければなりません。 ユーザがそのような訪問されたネットワークに移動できる有効にするホームネットワークの必要性。 したがって、訪問されたネットワークのアイデンティティが登録時にホームネットワークで知られているメカニズムがあるに違いありません。
It is acceptable to represent the visited network identity either as a visited network domain name or as a string.
訪問されたネットワークドメイン名として、または、ストリングとして訪問されたネットワークのアイデンティティを表すのは許容できます。
4.3.5. De-registration
4.3.5. 反-登録
4.3.5.1. De-registration of Users
4.3.5.1. ユーザの反-登録
There must be a procedure for a user to de-register from the network. This procedure may be used, for example, when the user deactivates the terminal.
ユーザが反-ネットワークから示す手順があるに違いありません。 例えば、ユーザが端末を非活性化すると、この手順は用いられるかもしれません。
We believe that a REGISTER with an expiration timer of 0 will meet the requirement.
私たちは、0の満了タイマがあるREGISTERが条件を満たすと信じています。
4.3.5.2. Network-initiated De-registration or Re-registration
4.3.5.2. ネットワークによって開始された反-登録か再登録
In a number of situations a network needs to de-register or trigger a re-registration of a previously registered UA. Examples of usage are described in sections 4.3.6.3, 4.3.6.4, and 4.3.6.5.
多くの状況で、ネットワークは、以前に登録されたUAの再登録の反-登録するか、または引き金となる必要があります。 そして、用法に関する例が説明される、セクション4.3 .6 .3 4.3 .6 .4、4.3 .6 .5。
This implies a need for a notification mechanism whereby the UA can be notified of the de-registration, or of a request for re-registration.
これは反-登録、または再登録を求める要求についてUAに通知できる通知メカニズムの必要性を含意します。
Garcia-Martin Informational [Page 10] RFC 4083 3GPP R5 Requirements on SIP May 2005
一口2005年5月に関するガルシア-マーチンの情報[10ページ]のRFC4083 3GPP R5要件
We believe that this requirement is met by the SIP-specific event notification [12] and a registration event package [14].
私たちは、この必要条件がSIP特有のイベント通知[12]と登録イベントパッケージ[14]によって満たされると信じています。
4.3.5.3. Network-initiated De-registration, Network Maintenance
4.3.5.3. ネットワークによって開始された反-登録、ネットワークメンテナンス
There might be cases in which the SIP serving proxy has to shutdown; e.g., due to maintenance operation. Although this situation is not likely to happen in everyday situations, it is desirable to have a mechanism to inform the UA that his current registration is being cancelled. The UA may initiate another registration process that will lead to the selection of a new SIP serving proxy.
プロキシに役立つSIPが閉鎖にそうした場合があるかもしれません。 例えば、メインテナンス操作のため。 この状況は日常の状況では起こりそうではありませんが、彼の現金書留が中止されていることをUAに知らせるメカニズムを持っているのは望ましいです。 UAはプロキシに役立つ新しいSIPの選択につながる別の登録手続に着手するかもしれません。
4.3.5.4. Network-initiated De-registration, Network/Traffic Determined
4.3.5.4. ネットワークによって開始された反-登録、決定するネットワーク/トラフィック
The system must support a mechanism to avoid inconsistent information storage and to remove any redundant registration information. This case will occur when a subscriber roams to a different network without a prior de-registration. This case occurs in normal mobility procedures when the user roams from one access network to another, or when new service conditions are imposed on roamers.
システムは、無節操な情報記憶を避けて、どんな余分なレジスト情報も取り除くためにメカニズムをサポートしなければなりません。 加入者が先の反-登録なしで異なったネットワークに歩き回るとき、本件は現れるでしょう。 ユーザが1つのアクセスネットワークから別のネットワークまで歩き回るか、または新しい運転条件が放浪者に課されるとき、本件は正常な移動性手順で現れます。
4.3.5.5. Network-initiated De-registration, Administrative
4.3.5.5. ネットワークによって開始された反-登録で、管理です。
For different reasons (e.g., subscription termination, stolen terminal, etc.) a home network administrative function may determine a need to clear a user's SIP registration. It is desirable to have a mechanism whereby the SIP serving proxy can inform the UA that its registration is being cancelled.
様々な理由で(例えば、購読終了、盗まれた端末など)ホームネットワーク行政機能はユーザのSIP登録をクリアする必要性を決定するかもしれません。 プロキシに役立つSIPが、登録が中止されていることをUAに知らせることができるメカニズムを持っているのは望ましいです。
There must be a procedure for the SIP serving proxy to de-register users. The de-registration information must be available at all the proxies that keep registration state and the UA.
SIPのための反-ユーザを登録するためにプロキシに役立つ手順があるに違いありません。 反-レジスト情報は登録状態とUAを維持するすべてのプロキシで利用可能であるに違いありません。
We believe that a procedure based on SIP-specific event notification [12] and a registration event package [14] will meet this requirement.
私たちは、SIP特有のイベント通知[12]と登録イベントパッケージ[14]に基づく手順がこの必要条件を満たすと信じています。
4.4. SIP Compression
4.4. 一口圧縮
The radio interface is a scarce resource, and typically the available bandwidth over the radio interface is limited. These two factors seem to limit the transport of possibly large SIP messages over the air interface. Particularly, the session setup time might be extended due to the time needed to transport SIP messages over a limited bandwidth channel.
ラジオインタフェースは不十分なリソースです、そして、ラジオインタフェースの上の利用可能な帯域幅は通常、限られています。 これらの2つの要素が空気インタフェースの上でことによると大きいSIPメッセージの輸送を制限するように思えます。 特に、セッション準備時間は限られた帯域幅チャンネルの上にSIPメッセージを輸送するのに時間まで必要である拡張支払われるべきものであるかもしれません。
Garcia-Martin Informational [Page 11] RFC 4083 3GPP R5 Requirements on SIP May 2005
一口2005年5月に関するガルシア-マーチンの情報[11ページ]のRFC4083 3GPP R5要件
On the other hand, the number and size of certain SIP header values, such as Via or Record-Route, seems not to be limited. A mobile device UA may present limitations in the available memory to store this kind of information.
他方では、ViaかRecord-ルートなどのあるSIPヘッダー値の数とサイズは制限されないように思えます。 UAがこの種類の情報を保存するために利用可能なメモリにおける制限を提示するかもしれないモバイル機器。
Therefore, there must be a mechanism to efficiently transport SIP signaling packets over the radio interface, by compressing the SIP messages between the mobile device UA and the SIP outbound proxy, and between the SIP outbound proxy and the mobile device UA. Note that compression of IP and transport layer protocol headers that carry these SIP messages is also a requirement, although we believe that this does not have an impact on SIP.
したがって、ラジオインタフェースの上で効率的にSIPシグナリングパケットを輸送するメカニズムがあるに違いありません、モバイル機器UAとSIPの外国行きのプロキシの間と、そして、SIPの外国行きのプロキシとモバイル機器UAの間でSIPメッセージを圧縮することによって。 また、IPとこれらのSIPメッセージを伝えるトランスポート層プロトコルヘッダーの圧縮が要件であることに注意してください、私たちは、これがSIPに影響を与えないと信じていますが。
4.4.1. Compression Algorithm Independence
4.4.1. 圧縮アルゴリズム独立
The chosen solution(s) must be able to allow the operation under several different compression algorithms.
選ばれたソリューションはいくつかの異なった圧縮アルゴリズムの下で操作を許すことができなければなりません。
4.4.2. Extensibility of the SIP Compression
4.4.2. 一口圧縮の伸展性
The chosen solution(s) must be extensible to facilitate the incorporation of new and improved compression algorithms in a backward-compatible way, as they become available.
選ばれたソリューションは後方コンパチブル道における、新しくて改良された圧縮アルゴリズムの編入を容易にするのにおいて広げることができるに違いありません、利用可能になるとき。
4.4.3. Minimal Impact of SIP Compression on the Network
4.4.3. ネットワークにおける一口圧縮の最小量の影響
Application-specific compression must minimize impacts on existing 3GPP access networks (such as base stations transceivers). On the other hand, the compression mechanism should be independent of the access; e.g., the compression must be defined between the mobile device UA and the outbound SIP proxy.
アプリケーション特有の圧縮は既存の3GPPアクセスネットワーク(基地局トランシーバーなどの)で影響を最小にしなければなりません。 他方では、圧縮機構はアクセスから独立しているべきです。 モバイル機器UAと外国行きのSIPプロキシの間で例えば圧縮を定義しなければなりません。
4.4.4. Optionality of SIP Compression
4.4.4. 一口圧縮のOptionality
It must be possible to leave the usage of compression for SIP signaling optional. To facilitate mobile terminal roaming between networks that are using compression, the mobile terminal should always support SIP signaling compression. If compression is not supported, communication may continue without compression, depending on the local policy of the visited network.
SIPシグナリングのための圧縮の用法を任意の状態でおくのは可能であるに違いありません。 圧縮を使用しているネットワークの間で移動体端末ローミングを容易にするために、移動体端末は、いつもSIPシグナリングが圧縮であるとサポートするはずです。 圧縮がサポートされないなら、訪問されたネットワークのローカルの方針によって、コミュニケーションは圧縮なしで続くかもしれません。
4.4.4.1. Compression Reliability
4.4.4.1. 圧縮の信頼性
The compression mechanism should be reliable and able to recover automatically from errors generated during the decompression.
圧縮機構は、信頼できて減圧の間に生成された誤りから自動的に克服するはずであることができます。
Garcia-Martin Informational [Page 12] RFC 4083 3GPP R5 Requirements on SIP May 2005
一口2005年5月に関するガルシア-マーチンの情報[12ページ]のRFC4083 3GPP R5要件
4.5. QoS Requirements Related to SIP
4.5. 一口に関連するQoS要件
4.5.1. Independence between QoS Signaling and SIP
4.5.1. QoSシグナリングと一口の間の独立
The selection of QoS signaling and resource allocation schemes must be independent of the selected session control protocols. This allows for independent evolution of QoS control and SIP.
QoSシグナリングと資源配分体系の品揃えは選択されたセッション制御プロトコルから独立しているに違いありません。 これはQoSコントロールとSIPの独立している発展を考慮します。
4.5.2. Coordination between SIP and QoS/Resource Allocation
4.5.2. 一口とQoS/資源配分の間のコーディネート
4.5.2.1. Allocation before Alerting
4.5.2.1. 警告の前の配分
In establishing a SIP session, it must be possible for an application to request that the resources needed for bearer establishment are successfully allocated before the destination user is alerted. Note, however, that it must be also possible for an SIP application in a terminal to alert the user before the radio resources are established (e.g., if the user wants to participate in the media negotiation).
SIPセッションを確立するのにおいて、アプリケーションが、目的地ユーザが警告される前に運搬人設立に必要であるリソースが首尾よく割り当てられるよう要求するのは、可能であるに違いありません。 しかしながら、ラジオリソースが確立される(例えば、ユーザがメディア交渉に参加したいなら)前にまた、端末のSIPアプリケーションがユーザを警告するのも、可能であるに違いないことに注意してください。
We believe that this requirement is met by Integration of Resource Management and SIP [15].
私たちは、この必要条件がResource ManagementとSIP[15]のIntegrationによって満たされると信じています。
4.5.2.2. Destination User Participates in the Bearer Negotiation
4.5.2.2. 目的地ユーザは運搬人交渉に参加します。
In establishing a SIP session, it must be possible for a terminating application to allow the destination user to participate in determining which bearers will be established. However, it must be possible to establish the SIP session without user intervention.
SIPセッションを確立するのにおいて、どの運搬人が設立されるかを決定するのに目的地ユーザが終わりアプリケーションで参加できるのは、可能であるに違いありません。 しかしながら、ユーザ介入なしでSIPセッションを確立するのは可能であるに違いありません。
We believe that this requirement is met by the standard SDP negotiation described in SIP [2], the SDP offer/answer model [11] and the extensions described in Integration of Resource Management and SIP
私たちは、この必要条件がSIP[2]で説明された標準のSDP交渉で満たされると信じています、とSDP申し出/答えモデル[11]と拡大はResource ManagementとSIPのIntegrationで説明しました。
4.5.2.3. Successful Bearer Establishment
4.5.2.3. うまくいっている運搬人設立
Successful bearer establishment must include the completion of any required end-to-end QoS signaling, negotiation, and resource allocation.
うまくいっている運搬人設立は終わりから終わりへのQoSどんな必要なシグナリング、交渉、および資源配分の完成も含まなければなりません。
We believe that this requirement is met by the procedures described in the Integration of Resource Management and SIP [15].
私たちは、この必要条件がResource ManagementとSIP[15]のIntegrationで説明された手順で満たされると信じています。
Garcia-Martin Informational [Page 13] RFC 4083 3GPP R5 Requirements on SIP May 2005
一口2005年5月に関するガルシア-マーチンの情報[13ページ]のRFC4083 3GPP R5要件
4.6. Prevention of Theft of Service
4.6. サービスの窃盗の防止
Typically, users are allocated QoS resources. There is an admission control mechanism that prevents users exceeding the limits negotiated with the network. The network must prevent unauthorized users to make use of non-authorized resources. For instance, the network must provide a mechanism to prevent a user from using the resources allocated to a second user, and for which this second user may be paying.
通常、QoSリソースをユーザに割り当てます。 ユーザがネットワークと交渉された限界を超えているのを防ぐ入場制御機構があります。 ネットワークは、非認可されたリソースを利用するために権限のないユーザを防がなければなりません。 例えば、ネットワークは、ユーザが2番目のユーザに割り当てられたリソースを使用して、この2番目のユーザがどれであるかもしれないかの対価を支払うのを防ぐためにメカニズムを提供しなければなりません。
We believe that this requirement may be met by the procedures described in the Private SIP extensions for Media Authorization [16].
私たちは、この必要条件がメディアAuthorization[16]のために兵士のSIP拡張子で説明された手順で満たされるかもしれないと信じています。
4.7. Radio Resource Authorization
4.7. ラジオリソース承認
As radio resources are very valuable, the network must be able to manage them in a controlled manner. The network must be able to identify who is using these resources and to authorize their usage. For example, a mobile device terminal could execute an unlimited and uncontrolled resource reservation procedure if the network does not supervise the usage of radio resources.
ラジオリソースが非常に貴重であるので、制御方法でネットワークはそれらに対処できなければなりません。 ネットワークは、だれがこれらのリソースを使用しているかを特定して、それらの用法を認可できなければなりません。 例えば、ネットワークがラジオリソースの用法を監督しないなら、モバイル機器端末は無制限で非制御の資源予約手順を実行するかもしれません。
We believe that this requirement is met by the procedures described in the Private SIP extensions for Media Authorization [16].
私たちは、この必要条件がメディアAuthorization[16]のために兵士のSIP拡張子で説明された手順で満たされると信じています。
4.8. Prevention of Malicious Usage
4.8. 悪意がある用法の防止
The 3GPP IMS must prevent mobile devices from making malicious use of the network. For instance, a malicious UA could not obey the procedures related to the Record-Route header field: when sending subsequent requests the UA could bypass proxies which inserted a Record-Route header during the initial transaction.
3GPP IMSは、モバイル機器がネットワークの悪意がある使用をするのを防がなければなりません。 例えば、悪意があるUAはRecord-ルートヘッダーフィールドに関連する手順に従うことができませんでした: UAがプロキシを迂回させることができたという(初期のトランザクションの間、Record-ルートヘッダーを挿入しました)その後の要求を送るとき。
4.9. Prevention of Denial of Service
4.9. サービス妨害の防止
The risk that a proxy will receive a denial of service attack should be minimized. For instance, a malicious mobile device could learn a SIP proxy IP address and port number (e.g., in a Record-Route header value) and establish an attack upon that proxy.
プロキシが断られるリスクは攻撃を修理します。最小にされるべきです。 例えば、悪意があるモバイル機器は、SIPプロキシIPアドレスとポートナンバー(例えば、Record-ルートヘッダー価値における)を学んで、そのプロキシに対する攻撃を確立するかもしれません。
Garcia-Martin Informational [Page 14] RFC 4083 3GPP R5 Requirements on SIP May 2005
一口2005年5月に関するガルシア-マーチンの情報[14ページ]のRFC4083 3GPP R5要件
4.10. Identification of Users
4.10. ユーザの識別
4.10.1. Private User Identity
4.10.1. 個人的なユーザのアイデンティティ
In order to use the 3GPP IMS, a user is assigned a private user identity. The home network operator assigns the private user identity, which is used to identify the user uniquely from a network perspective. The private user identity is used, for example, for authentication, authorization, administration, and, possibly, accounting purposes. Note that the private user identity is not used for routing of SIP messages.
3GPP IMSを使用するために、個人的なユーザアイデンティティはユーザに割り当てられます。 ホームネットワークオペレータは個人的なユーザアイデンティティを割り当てます。(それは、ネットワーク見解からユーザを唯一特定するのに使用されます)。 例えば、個人的なユーザアイデンティティは認証、承認、管理、およびことによると会計目的に使用されます。 個人的なユーザアイデンティティがSIPメッセージのルーティングに使用されないことに注意してください。
The private user identity is a unique global identity defined by the Home Network Operator. The identity takes the form of a Network Access Identifier (NAI) as defined in RFC 2486 [6].
個人的なユーザアイデンティティはホームNetwork Operatorによって定義されたユニークなグローバルなアイデンティティです。 アイデンティティはRFC2486[6]で定義されるようにNetwork Access Identifier(NAI)の形を取ります。
The end user does not have access to the private user identity. Typically the identity is stored in a Subscriber Identity Module card.
エンドユーザは個人的なユーザアイデンティティに近づく手段を持っていません。 通常、アイデンティティは加入者識別モジュールカードに保存されます。
The private user identity is permanently allocated to a user (it is not a dynamic identity), and is valid for the duration of the user's business subscription with the home network.
個人的なユーザアイデンティティは、永久にユーザ(それはダイナミックなアイデンティティでない)に割り当てられて、ユーザのビジネス購読の持続時間に、ホームネットワークによって有効です。
4.10.1.1. Private User ID in Registrations
4.10.1.1. 登録証明書における個人的なユーザID
The mobile UA must deliver the private user identity to the SIP outbound proxy and the registrar at registration time.
モバイルUAは登録時にSIPの外国行きのプロキシと記録係に個人的なユーザアイデンティティを提供しなければなりません。
The private user identity is used as the basis for authentication during registration of the mobile user. The term authentication is used in this document with the same meaning as it is defined in RFC 2828 [7].
個人的なユーザアイデンティティはモバイルユーザの登録の間、認証の基礎として使用されます。 用語認証は本書ではそれがRFC2828[7]で定義されるような同じ意味と共に使用されます。
We believe that this requirement is met by populating the username field of the Authorization: header value of the REGISTER request with the private user identity.
私たちは、この必要条件がAuthorizationのユーザ名分野に居住することによって満たされると信じています: 個人的なユーザアイデンティティがあるREGISTER要求のヘッダー値。
4.10.2. Public User Identities
4.10.2. 公共のユーザアイデンティティ
In order to use the 3GPP IMS, a user is assigned one or more public user identities. The user will make use of the public user identity/ identities when requesting communication to other users. For example, the public user identity might be included on a business card.
3GPP IMSを使用するために、1つ以上の公共のユーザアイデンティティがユーザに割り当てられます。 他のユーザにコミュニケーションを要求するとき、ユーザは公共のユーザアイデンティティ/アイデンティティを利用するでしょう。 例えば、公共のユーザアイデンティティは名刺の上に含まれるかもしれません。
Garcia-Martin Informational [Page 15] RFC 4083 3GPP R5 Requirements on SIP May 2005
一口2005年5月に関するガルシア-マーチンの情報[15ページ]のRFC4083 3GPP R5要件
Different public user identities may be grouped into a user profile. A user may have different profiles, each one containing different public user identities. A public user identity can be part of a single user profile.
異なった公共のユーザアイデンティティはユーザ・プロファイルに分類されるかもしれません。 ユーザには、異なったプロフィール、異なった公共のユーザアイデンティティを含む各々があるかもしれません。 公共のユーザアイデンティティはシングルユーザープロフィールの一部であるかもしれません。
The user may need to register one or more public user identities prior to receiving communications addressed to that public user identity.
ユーザは、その公共のユーザアイデンティティに扱われたコミュニケーションを受け取る前に1つ以上の公共のユーザアイデンティティを登録する必要があるかもしれません。
We believe that this requirement is met by populating the From: and To: header values of a REGISTER message with the public user identity.
私たちは、この必要条件がFrom:に居住することによって満たされると信じています。 そして、To: 公共のユーザアイデンティティがあるREGISTERメッセージのヘッダー値。
4.10.2.1. Format of the Public User Identities
4.10.2.1. 公共のユーザアイデンティティの形式
The public user identity must take the form of a SIP URI (as defined in RFC 3261 [2] and RFC 2396 [4]) or of a E.164 [34] number.
公共のユーザアイデンティティはSIP URIのフォームで取らなければなりません。(RFC3261[2]とRFC2396[4])で定義されるか、E.164[34]数について。
We believe that this requirement is met by using SIP URLs and telephone numbers represented in SIP URLs as described in SIP [3]. In addition, tel: URLs as specified in RFC 3966 [35] can be used to fulfill the requirement.
私たちは、この必要条件がSIP[3]で説明されるようにSIP URLに表されたSIP URLと電話番号を使用することによって満たされると信じています。 追加、tel:で 要求にこたえるのにRFC3966[35]の指定されるとしてのURLを使用できます。
4.10.2.2. Registration of Public User IDs
4.10.2.2. 公共のユーザIDの登録
It must be possible to register globally (i.e., through one single UA request) a user that has more than one public identity that belongs to the same user profile, via a mechanism within the IMS. In this case, the user will be registered with all the public identities associated to a user profile.
同じユーザ・プロファイルに属す1つ以上の公共のアイデンティティを持っているユーザをグローバル(すなわち、独身のUAが要求する1つを通して)に登録するのは可能であるに違いありません、IMSの中のメカニズムで。この場合、ユーザはユーザ・プロファイルに関連づけられるすべての公共のアイデンティティに登録されるでしょう。
We believe this requirement may be accomplished by external procedures. For example, the user's profile may contain a list of alias identities that the registrar considers active if the primary identity is registered. The user may get informed of the automatically registered public user IDs by subscribing to its own registration state.
私たちは、この要件が外部手続きで達成されるかもしれないと信じています。 例えば、プライマリアイデンティティが登録されているなら、ユーザのプロフィールは記録係がアクティブであると考える別名のアイデンティティのリストを含むかもしれません。 ユーザは、自動的に登録された公共のユーザIDにおいてそれ自身の登録状態に加入することによって、知識があるかもしれません。
4.10.2.3. Authentication of the public user ID
4.10.2.3. 公共のユーザIDの認証
Public user identities are not authenticated by the 3GPP IMS. However, the network authorizes that the public user identity is associated with the registered private user identity.
公共のユーザアイデンティティは3GPP IMSによって認証されません。しかしながら、ネットワークはそれを認可します。公共のユーザアイデンティティは登録された個人的なユーザアイデンティティに関連しています。
There is a list of public user identities associated with each private user ID within the IMS. IMS will reject attempts to use other public identities with this private user ID.
この個人的なユーザIDがある他の公共のアイデンティティを使用するために、IMS. IMSの中のIDが拒絶するそれぞれの個人的なユーザに関連しているアイデンティティが試みる公共のユーザのリストがあります。
Garcia-Martin Informational [Page 16] RFC 4083 3GPP R5 Requirements on SIP May 2005
一口2005年5月に関するガルシア-マーチンの情報[16ページ]のRFC4083 3GPP R5要件
4.10.3. Delivery of the Dialed Public User ID
4.10.3. ダイヤルされた公共のユーザIDの配送
Typically a UA will be registered under a set of different public user IDs. As such, sessions destined to the user can be placed with any of the registered public user IDs. The serving proxy and application server(s) in the termination network may apply certain filtering rules or services based on the public user ID contained in the Request-URI. The UA may also apply certain filtering rules or services based on the called public user ID.
通常、UAは異なった公共のユーザIDのセットの下で登録されるでしょう。 そういうものとして、登録された公共のユーザIDのいずれにもユーザに運命づけられたセッションは置くことができます。 終了ネットワークにおける給仕プロキシとアプリケーション・サーバーはあるフィルタリング規則かRequest-URIに含まれた公共のユーザIDに基づくサービスを当てはまるかもしれません。 また、UAはあるフィルタリング規則か呼ばれた公共のユーザIDに基づくサービスを適用するかもしれません。
Therefore, it must be possible for all sessions to deliver the dialed public user ID to the terminating entities, such as the serving proxy, application servers, and terminating UA.
したがって、それは、すべてのセッションがダイヤルされた公共のユーザIDを給仕プロキシなどの終わり実体に提供するのにおいて可能なアプリケーションサーバと、UAを終えることであるに違いありません。
4.11. Identifiers Used for Routing
4.11. ルート設定に使用される識別子
Routing of SIP signaling within IMS must use SIP URLs as defined in SIP [2]. E.164 [34] format public user identities must not be used for routing within IMS, and session requests based on E.164 format public user identities will require conversion into SIP URI format for internal IMS usage.
IMSの中で合図するSIPのルート設定はSIP[2]で定義されるようにSIP URLを使用しなければなりません。 IMS、およびセッション中に発送するのにおいて、公共のユーザアイデンティティが使用されているはずがないE.164[34]形式は、E.164形式に基づいて公共のユーザアイデンティティが内部のIMS用法のためにSIP URI形式への変換を必要とするよう要求します。
We believe that this requirement is achieved by translating E.164 numbers into SIP URIs. A database, such as ENUM [9], might do the job.
私たちは、この要件がE.164番号をSIP URIに翻訳することによって達成されると信じています。 ENUM[9]などのデータベースは仕事するかもしれません。
4.12. Hiding Requirements
4.12. 要件を隠します。
Although the requirements included in this section are not optional, the hiding feature is optional to use through configuration. This means that a network operator can, at his desire, switch the hiding functionality on or off.
このセクションに含まれていた要件は任意ではありませんが、隠れること機能は、構成を通して使用するために任意です。 これは、ネットワーク・オペレータが彼の願望でオンかオフに隠れることの機能性を切り換えることができることを意味します。
4.12.1. Hiding of the Network Structure
4.12.1. ネットワーク構造の隠れること
A network operator need not be required to reveal the internal network structure to another network (in Via, Route, or other headers) that may contain indication of the number of SIP proxies, domain name of the SIP proxies, capabilities of the SIP proxies, or capacity of the network.
ネットワーク・オペレータが、SIPプロキシの数のしるし、SIPプロキシのドメイン名、SIPプロキシの能力、またはネットワークの容量を含むかもしれない別のネットワーク(Via、Route、または他のヘッダーの)に内部のネットワーク構造を明らかにするのに必要である必要はありません。
4.12.2. Hiding of IP Addresses
4.12.2. IPアドレスの隠れること
A network need not be required to expose the explicit IP addresses of the nodes within the network (excluding firewalls and border gateways).
ネットワークが、ネットワーク(ファイアウォールと境界ゲートウェイを除いた)の中でノードの明白なIPアドレスを暴露するのに必要である必要はありません。
Garcia-Martin Informational [Page 17] RFC 4083 3GPP R5 Requirements on SIP May 2005
一口2005年5月に関するガルシア-マーチンの情報[17ページ]のRFC4083 3GPP R5要件
4.12.3. SIP Hiding Proxy
4.12.3. プロキシを隠す一口
In order to support the hiding requirements, a SIP hiding proxy may be included in the SIP signaling path. This additional proxy may be used to shield the internal structure of a network from other networks.
隠れることが要件であるとサポートするために、プロキシを隠すSIPはSIPシグナリング経路に含まれるかもしれません。 この追加プロキシは、他のネットワークからネットワークの内部の構造を保護するのに使用されるかもしれません。
4.13. Cell-ID
4.13. Cell ID
The identity of the cell through which the 3GPP UA is accessing the IMS (Cell-ID) may be used by the home network to provide localized services or information on the location of the terminal during an emergency call (when emergency calls are handled in IMS; see also the requirement stated in Section 4.16).
3GPP UAがIMS(Cell ID)にアクセスしているセルのアイデンティティはホームネットワークによって使用されて(非常時であるとき、呼び出しはIMSで扱われます; また、セクション4.16に述べられた要件を見てください)、緊急通報の間、端末の位置のローカライズしているサービスか情報を提供するかもしれません。
4.13.1. Cell-ID in Signaling from the UA to the Visited and Home
Networks
4.13.1. UAから訪問とホームネットワークまで合図することにおけるCell ID
Assuming that the Cell-ID is obtained by the UA by other mechanisms outside the scope of SIP, the Cell-ID must be transported at least in the following procedures:
Cell-IDがSIP、Cell-IDの範囲の外の他のメカニズムによってUAによって得られると仮定するのを少なくとも以下の手順で輸送しなければなりません:
o Registration o Session Establishment (Mobile Originated) o Session Establishment (Mobile Terminated) o Session Release
o 登録o Session特権階級(モバイルOriginated)o Session特権階級(モバイルTerminated)o Session Release
The Cell-ID is private information and only of interest in the UA home network. Therefore, the Cell-ID should be removed prior to sending the SIP signaling beyond the originating home network.
Cell-IDは個人情報とUAホームネットワークへの関心だけのものです。 したがって、SIPに起因するホームネットワークを超えて合図させる前に、Cell-IDを取り除くべきです。
4.13.2. Format of the Cell-ID
4.13.2. Cell IDの形式
The cell-ID must be sent in any of the formats described in the 3GPP Technical Specification 23.003 [26].
セルIDは形式の送られたどれかが3GPP仕様書で23.003[26]について説明したということであるに違いありません。
4.14. Release of Sessions
4.14. セッションのリリース
In addition to the normal mechanisms for releasing a SIP session (e.g., BYE), two cases are considered in this section: the ungraceful session release (e.g., the terminal moves to an out-of-coverage zone) and the graceful session release ordered by the network (e.g., prepaid caller runs out of credit).
SIPセッション(例えば、BYE)をリリースするための正常なメカニズムに加えて、2つのケースがこのセクションで考えられます: ネットワーク(例えば、クレジットからの前払いの訪問者走行)によって無様なセッションリリース(例えば端末は適用範囲で出ているゾーンに移行する)と優雅なセッションリリースは注文されました。
We believe that this requirement is met by a SIP entity acting as a so-called transparent back-to-back UA.
私たちは、この必要条件がいわゆる透明な背中合わせのUAとして機能するSIP実体によって満たされると信じています。
Garcia-Martin Informational [Page 18] RFC 4083 3GPP R5 Requirements on SIP May 2005
一口2005年5月に関するガルシア-マーチンの情報[18ページ]のRFC4083 3GPP R5要件
4.14.1. Ungraceful Session Release
4.14.1. 無様なセッションリリース
If an ungraceful session termination occurs (e.g., a flat battery or a mobile leaves coverage), when a call stateful SIP proxy server (such as the SIP serving proxy at home) is involved in a session, memory leaks and, eventually, server failure can occur due to hanging state machines. To ensure stable server operation and carrier grade service, a mechanism to handle the ungraceful session termination issue must be provided. We assume that there is a mechanism by which the SIP outbound proxy is notified, by a mechanism external to SIP, of the ungraceful session termination. This allows transforming the ungraceful session release into a graceful session release ordered by the network (see the next section). For example, upon reception of the notification of loss of mobile radio coverage, the SIP outbound proxy could send a BYE request on behalf of the terminal, although this BYE cannot be authenticated.
呼び出しstateful SIPプロキシサーバ(ホームでプロキシに役立つSIPなどの)がセッションにかかわるとき、掛かっている州のマシンのため、無様なセッション終了が起こるなら(例えば、平坦なバッテリーかモバイルが適用範囲を出ます)、メモリリークと結局サーバ失敗は起こることができます。 安定したサーバ操作とキャリヤーグレードサービス、扱うメカニズムを確実にするために、無様なセッション終了問題を提供しなければなりません。 私たちは、SIPの外国行きのプロキシが通知されるメカニズムがあると思います、無様なセッション終了のSIPへの外部のメカニズムで。 これで、無様なセッションリリースをネットワークによって注文された優雅なセッションリリースに変えます(次のセクションを見てください)。 例えば、移動無線適用範囲の損失の通知のレセプションに、SIPの外国行きのプロキシは端末を代表してBYE要求を送ることができました、このBYEを認証できませんが。
4.14.2. Graceful Session Release
4.14.2. 優雅なセッションリリース
There must be a mechanism whereby an entity in the network may order the release of resources to other entities. This may be used, for example, in prepaid calls when the user runs out of credit.
ネットワークにおける実体が他の実体にリソースのリリースを注文するかもしれないメカニズムがあるに違いありません。 ユーザがクレジットを使い果たすとき、例えば、これは前払いの呼び出しに使用されるかもしれません。
This release must not involve any request to the UA to send out a release request (BYE), as the UA might not follow this request. The receiving entity needs the guarantee that resources are released when requested by the ordering entity.
このリリースはリリース要求(BYE)を出すためにどんな要求にもUAにかかわってはいけません、UAがこの要求に続かないかもしれないとき。 受信実体は注文実体によって要求されるとリソースが発表されるという保証を必要とします。
The following objectives must be met:
以下の目的を満たさなければなりません:
o Accurately report the termination to the charging subsystem.
o 正確に充電サブシステムに終了を報告してください。
o Release the associated network resources: bearer resources and
signaling resources.
o 関連ネットワーク資源をリリースしてください: 運搬人リソースとシグナリングリソース。
o Notify other parties to the session, if any, of the session
termination.
o セッション終了についてセッションまでもしあれば相手に通知してください。
When feasible, this mechanism should be at the SIP protocol level in order to guarantee access independence for the system.
可能であるときに、このメカニズムが、システムのためにアクセス独立を保証するためにSIPプロトコルレベルにあるはずです。
Garcia-Martin Informational [Page 19] RFC 4083 3GPP R5 Requirements on SIP May 2005
一口2005年5月に関するガルシア-マーチンの情報[19ページ]のRFC4083 3GPP R5要件
4.15. Routing of SIP Messages
4.15. 一口メッセージのルート設定
4.15.1. SIP Outbound Proxy
4.15.1. 外国行きのプロキシをちびちび飲んでください。
The 3GPP architecture includes a SIP outbound proxy that is typically located in the visited network (although it may be located in the home network). This outbound proxy provides local services such as compression of SIP messages or security functions. In addition, the outbound proxy may interact with the media reservation mechanism to provide authentication and authorization support for media reservation.
3GPPアーキテクチャは訪問されたネットワークで通常位置しているSIPの外国行きのプロキシを含んでいます(それがホームネットワークで位置するかもしれませんが)。 この外国行きのプロキシはSIPメッセージかセキュリティ機能の圧縮などのローカル・サービスを提供します。 さらに、外国行きのプロキシは、メディアの予約の認証と承認サポートを提供するためにメディア予約メカニズムと対話するかもしれません。
All mobile terminal originated session setup attempts must transit the outbound proxy so that the services provided by the outbound proxy can be delivered to the mobile terminal.
すべての移動体端末の溯源されたセッションセットアップ試みが、外国行きのプロキシによって提供されたサービスは移動体端末に提供できるように外国行きのプロキシを通過しなければなりません。
4.15.2. SIP Serving Proxy in the Home Network
4.15.2. ホームネットワークにプロキシに役立つ一口
The serving proxy in the home network allows triggering of user- customized services that are typically executed in an application server.
ホームネットワークにおける給仕プロキシはアプリケーション・サーバーで通常実行されるカスタマイズされたサービスをユーザの引き金となるのに許します。
All mobile terminal originated session setup attempts must transit the serving proxy in the home network so that the proxy can properly trigger the SIP services allocated to the user (e.g., speed dial substitution). This implies a requirement for some sort of source- routing mechanism to ensure these proxies are transited correctly.
すべての移動体端末の溯源されたセッションセットアップ試みが、プロキシが適切にユーザ(例えば、短縮ダイヤル代替)に割り当てられたSIPサービスの引き金となることができるように、ホームネットワークで給仕プロキシを通過しなければなりません。 これは、これらのプロキシが正しく通過されるのを保証するためにある種のソースルーティングメカニズムのための要件を含意します。
4.15.3. INVITE Might Follow a Different Path than REGISTER
4.15.3. 招待は登録するより異なる道を歩むかもしれません。
The path taken by an INVITE request need not be restricted to the specific path taken by a mobile terminal originated REGISTER request; e.g., the INVITE may traverse just the SIP outbound proxy and the SIP serving proxy, without passing through any other proxies. However, the path taken by the INVITE may follow the same path taken by the REGISTER.
INVITE要求で取られた経路は溯源されたREGISTERが要求する移動体端末によって取られた特定の経路に制限される必要はありません。 例えば、INVITEはまさしくSIPの外国行きのプロキシとプロキシに勤めるSIPを横断するかもしれません、いかなる他のプロキシも通り抜けないで。 しかしながら、INVITEによって取られた経路はREGISTERによって取られた同じ経路に続くかもしれません。
4.15.4. SIP Inbound Proxy
4.15.4. 本国行きのプロキシをちびちび飲んでください。
The visited network may apply certain services and policies to incoming sessions (such as establishment of security services or interaction with the media reservation mechanism). Therefore, the visited network may contain a SIP inbound proxy for terminating sessions. In general, the SIP inbound proxy and the SIP outbound proxy are the same SIP proxy.
訪問されたネットワークは入って来るセッション(メディア予約メカニズムとのセキュリティー・サービスか相互作用の設立などの)に、あるサービスと方針を適用するかもしれません。 したがって、訪問されたネットワークは終わりセッションのためにSIPの本国行きのプロキシを含むかもしれません。 一般に、SIPの本国行きのプロキシとSIPの外国行きのプロキシは同じSIPプロキシです。
Garcia-Martin Informational [Page 20] RFC 4083 3GPP R5 Requirements on SIP May 2005
一口2005年5月に関するガルシア-マーチンの情報[20ページ]のRFC4083 3GPP R5要件
4.15.5. Distribution of the Source Routing Set of Proxies
4.15.5. プロキシのソースルート設定セットの分配
Sections 4.15.2 and 4.15.4 assume that a source-routing mechanism is used to effect traversal of the required SIP proxies during session setup.
ソースルーティングメカニズムが使用されているセクション4.15.2と.4が仮定する4.15はセッションセットアップの間、必要なSIPプロキシの縦断に作用します。
There must be some means of dynamically informing the node that adds the source-routing set of proxies that the INVITE has to traverse (e.g., the outbound proxy or serving proxy) of what that set of proxies should be.
INVITEがそのセットのプロキシが何であるべきであるかに関する(例えば、外国行きのプロキシか給仕プロキシ)を横断しなければならないことをダイナミックにソースルーティングがセットしたと言い足すプロキシのノードに知らせるいくつかの手段があるに違いありません。
The hiding requirements expressed in Section 4.12 also apply to the said set of proxies.
また、セクション4.12で言い表された隠れること要件は前述のプロキシに適用されます。
4.16. Emergency Sessions
4.16. 緊急集会
3GPP networks already contain alternative procedures for delivering emergency sessions. Release 5 of the 3GPP specifications does not add any requirement for SIP emergency sessions.
3GPPネットワークは既に緊急集会を提供するための交替手続きを含んでいます。 3GPP仕様のリリース5はSIP緊急集会のためのどんな要件も加えません。
4.17. Identities Used for Session Establishment
4.17. セッション設立に使用されるアイデンティティ
4.17.1. Remote Party Identification Presentation
4.17.1. リモート政党帰属意識プレゼンテーション
It must be possible to present to the caller the identity of the party to which he/she may dial back to return a call.
その人が後部にダイヤルするかもしれないパーティーは訪問を返すとは訪問者にアイデンティティを提示するのにおいて可能であるに違いありません。
We believe that this requirement is met by the procedures described in RFC 3325 [17].
私たちは、この必要条件がRFC3325[17]で説明された手順で満たされると信じています。
4.17.2. Remote Party Identification Privacy
4.17.2. リモート政党帰属意識プライバシー
In addition to the previous requirement, the called party must be able to request that his/her identity not be revealed to the caller.
前の要件に加えて、被呼者は、その人のアイデンティティが訪問者に明らかにされないよう要求できなければなりません。
We believe that this requirement is met by the procedures described in RFC 3323 [18].
私たちは、この必要条件がRFC3323[18]で説明された手順で満たされると信じています。
4.17.3. Remote Party Identification Blocking
4.17.3. リモート政党帰属意識ブロッキング
Regulatory agencies, as well as subscribers, may require the ability of callers to block the display of their caller identification. The destination subscriber's SIP serving proxy may be perform this function. In this way, the destination subscriber is still able to do a session-return, session-trace, transfer, or any other supplementary service.
監督官庁、および加入者は訪問者が彼らの訪問者識別のディスプレイを妨げる能力を必要とするかもしれません。 プロキシに役立つ目的地加入者のSIPはこの機能を実行することであるかもしれません。 このように、目的地加入者はまだセッションリターン、セッション跡、転送、またはいかなる他の補っているサービスもできています。
Garcia-Martin Informational [Page 21] RFC 4083 3GPP R5 Requirements on SIP May 2005
一口2005年5月に関するガルシア-マーチンの情報[21ページ]のRFC4083 3GPP R5要件
Therefore, it must be possible that the caller request to block the display of his/her identity on the callee's display.
したがって、訪問者が訪問される人のディスプレイのその人のアイデンティティのディスプレイをブロックまで要求するのは、可能であるに違いありません。
We believe that this requirement is met by the procedures described in RFC 3323 [18].
私たちは、この必要条件がRFC3323[18]で説明された手順で満たされると信じています。
4.17.4. Anonymity
4.17.4. 匿名
Procedures are required for anonymous session establishment. However, sessions are not intended to be anonymous to the originating or terminating network operators.
手順が匿名のセッション設立に必要です。 しかしながら、セッションは、起因することへの匿名かネットワーク・オペレータを終えることを意図しません。
We believe that this requirement is met by the procedures described in RFC 3323 [18] and RFC 3325 [17].
私たちは、この必要条件がRFC3323[18]とRFC3325[17]で説明された手順で満たされると信じています。
4.17.5. Anonymous Session Establishment
4.17.5. 匿名のセッション設立
If the caller requests that the session be anonymous, the User Agent Client (UAC) must not reveal any identity information to the User Agent Server (UAS).
訪問者が、セッションが匿名であるよう要求するなら、UserエージェントClient(UAC)はUserエージェントServer(UAS)に少しのアイデンティティ情報も明らかにしてはいけません。
If the caller requests that the session be anonymous, the terminating network must not reveal any identity or signaling routing information to the destination endpoint. The terminating network should distinguish at least two cases: first, whether the caller intended the session to be anonymous, and second, whether the caller's identity was deleted by a transit network.
訪問者が、セッションが匿名であるよう要求するなら、終わりネットワークは少しのアイデンティティやシグナリングルーティング情報も目的地終点に明らかにしてはいけません。 終わりネットワークは少なくとも2つのケースを区別するべきです: 訪問者のアイデンティティがトランジットネットワークによって削除されたか否かに関係なく、訪問者が最初に、匿名であるセッション、および2番目を意図したか否かに関係なく。
We believe that this requirement is met by the procedures described in RFC 3323 [18] and RFC 3325 [17].
私たちは、この必要条件がRFC3323[18]とRFC3325[17]で説明された手順で満たされると信じています。
4.18. Charging
4.18. 充電
The 3GPP charging implications are described in the 3GPP Technical Specification 32.225 [31].
3GPP充電含意は3GPP仕様書32.225[31]で説明されます。
4.18.1. Support of Both Prepaid and Postpaid Models
4.18.1. 前払いの、そして、郵便前払いの両方のモデルのサポート
Operators may choose to offer prepaid and/or postpaid services. The prepaid model is accomplished with the support of the online charging model. The postpaid model is accomplished with the support of the offline charging model.
オペレータは、前払いの、そして/または、郵便前払いのサービスを提供するのを選ぶかもしれません。 前払いのモデルはオンライン充電モデルのサポートで達成されます。 郵便前払いのモデルはオフライン充電モデルのサポートで達成されます。
Online charging is the process whereby charging information can affect, in real-time, the service rendered to the user, such as a request for a graceful release of an existing session. Online charging interacts with the SIP signaling.
オンライン充電は充電情報がリアルタイムででユーザに提供されたサービスに影響できるプロセスです、既存のセッションの優雅なリリースを求める要求のように。 オンライン充電はSIPシグナリングと対話します。
Garcia-Martin Informational [Page 22] RFC 4083 3GPP R5 Requirements on SIP May 2005
一口2005年5月に関するガルシア-マーチンの情報[22ページ]のRFC4083 3GPP R5要件
Offline charging is the process whereby charging information does not affect, in real-time, the service rendered to the user.
充電はオフライン、充電情報がリアルタイムででユーザに提供されたサービスに影響しないプロセスです。
4.18.2. Charging Correlation Levels
4.18.2. 充電相関関係レベル
The following levels of correlation for IMS charging are considered:
IMS充電のための以下のレベルの相関関係は考えられます:
o Correlation within a session. A session may comprise a number of
media components. It must be possible to correlate the charging
data of the different media components belonging to a session.
o セッション以内の相関関係。 セッションは多くのメディアコンポーネントを包括するかもしれません。 セッションに属する異なったメディアコンポーネントに関する課金データを関連させるのは可能であるに違いありません。
o Correlation at media-component level. For a session comprising
several media types (such as audio and video), charging data is
generated for each media type and needs to be correlated between
network elements. For this, a media identifier will be unique and
will clearly identify which media type of a session this charging
information belongs to. This component identifier is not
exchanged between network elements and is based on the ordering of
media flows in the SDP. This ordering is the same as that used in
the binding information passed to the GPRS network.
o メディアコンポーネントレベルにおける相関関係。 いくつかのメディアタイプ(オーディオやビデオなどの)を包括するセッションのために、課金データは、それぞれのメディアタイプのために生成されて、ネットワーク要素の間で関連する必要があります。 これに関しては、メディア識別子は、ユニークであり、この充電情報がセッションのどのメディアタイプのものであるかを明確に特定するでしょう。 このコンポーネント識別子は、ネットワーク要素の間で交換されないで、SDPでメディア流れの注文に基づいています。 この注文はGPRSネットワークに通過された拘束力がある情報で使用されるそれと同じです。
4.18.3. Charging Correlation Principles
4.18.3. 充電相関関係プリンシプルズ
To support the correlation of charging information, the following principles apply to both offline and online charging:
充電情報の相関関係をサポートするために、以下の原則はオフラインの、そして、オンラインの両方の充電に申し込まれます:
o The correlation of charging information for an IMS session is
based on the use of IMS Charging Identifiers (ICID).
o IMSセッションのための充電情報の相関関係はIMS Charging Identifiers(ICID)の使用に基づいています。
o The first IMS network entity within the SIP signaling path is
responsible for assigning an ICID. This ICID will then be passed
along the whole session path in an end-to-end manner. However,
this will not preclude further elements (other SIP proxies) along
the session path from generating additional identifiers to be
passed along.
o SIPシグナリング経路の中の最初のIMSネットワーク実体はICIDを割り当てるのに原因となります。 そして、このICIDは全体のセッション経路に沿って終わりから終わりへの方法で渡されるでしょう。 しかしながら、これは、回されるために追加識別子を生成するので、セッション経路に沿ってさらなる要素(他のSIPプロキシ)を排除しないでしょう。
o The ICID is passed to all IMS network entities in the session
signaling path. This is performed using SIP signaling.
o ICIDはセッションシグナリング経路のすべてのIMSネットワーク実体に渡されます。 これは、SIPシグナリングを使用することで実行されます。
o The addresses of the charging functions are passed by the serving
SIP proxy to all IMS network entities in the session signaling
path. This is to provide a common destination for all the
charging records generated by each IMS network entity with the
same ICID.
o 充電機能のアドレスは給仕SIPプロキシによってセッションシグナリング経路のすべてのIMSネットワーク実体に通過されます。 これは、同じICIDと共にそれぞれのIMSネットワーク実体によって生成されたすべての充電記録に一般的な目的地を提供するためのものです。
o For the charging correlation between the GPRS network and the IMS,
one or more GPRS Charging IDs, which identify the PDP contexts of
the session, are passed from the GPRS network to the IMS.
o GPRSネットワークとIMS、1以上の間の充電相関関係において、GPRS Charging ID(セッションのPDP文脈を特定する)はGPRSネットワークからIMSまで通過されます。
Garcia-Martin Informational [Page 23] RFC 4083 3GPP R5 Requirements on SIP May 2005
一口2005年5月に関するガルシア-マーチンの情報[23ページ]のRFC4083 3GPP R5要件
o The GPRS Charging IDs are passed by the outbound SIP proxy to the
serving SIP proxy and the Application Servers using SIP signaling.
They are not transferred from one home IMS (e.g., caller's home)
to another (e.g., callee's home).
o GPRS Charging IDは、外国行きのSIPプロキシによってSIPシグナリングを使用することで給仕SIPプロキシとApplication Serversに渡されます。 それらは1ホームIMS(例えば、訪問者のホーム)から別のもの(例えば、訪問される人のホーム)まで移されません。
o Inter Operator Identifiers (IOI) are shared between the caller's
home IMS and the callee's home IMS to provide identifiers of the
home originating and home terminating networks.
o 間のOperator Identifiers(IOI)は、ホームの起因するのとホームに関する識別子を提供するためにネットワークを終えながら、訪問者のホームIMSと訪問される人のホームIMSの間で共有されます。
4.18.4. Collection of Session Detailed Information
4.18.4. セッションの詳細な情報の収集
The SIP serving proxy or another SIP server in the home network must be able to log details of all sessions, such as the duration, source, and destination of a session, to provide to the charging subsystem.
プロキシに役立つSIPかホームネットワークにおける別のSIPサーバが、セッションの持続時間や、ソースや、目的地などのすべてのセッションの詳細を登録して、充電サブシステムに提供できなければなりません。
4.19. General Support of Additional Capabilities
4.19. 追加能力の一般サポート
4.19.1. Additional Capabilities
4.19.1. 追加能力
3GPP is interested in applying and using additional services, such as those described in SIP Call Control - Transfer [20], SIP Basic Call Flow Examples [21], SIP Public Switched Telephone Network (PSTN) Call Flows [22], and SIP service examples [23]. Although 3GPP is not going to standardize additional services, 3GPP may make sure that the capabilities that enable those services are granted in the network.
SIP Call Controlで説明されたものなどの追加サービスを適用して、3GPPは利用したがっています--転送[20]、SIP Basic Call Flow Examples[21]、SIP Public Switched Telephone Network(PSTN)はFlows[22]、およびSIPをサービスの例[23]と呼びます。 3GPPは追加サービスを標準化しないでしょうが、3GPPは、それらのサービスを可能にする能力がネットワークで与えられるのを確実にするかもしれません。
Therefore, we believe that the SIP REFER method [24] and the Replaces header [25] constitute a complement to be used as an enabler in order to meet the above requirement.
したがって、私たちは、SIP REFERメソッド[24]とReplacesヘッダー[25]が上記の必要条件を満たすのにイネーブラとして使用されるために補数を構成すると信じています。
4.19.2. DTMF Signaling
4.19.2. DTMFシグナリング
Support for voice calls must provide a level of service similar to that of the existing circuit-based voice service. This includes the ability to use DTMF signaling, for example, for control of interactive voice response systems such as ticket sales lines and timetable information.
音声通話のサポートは既存の回路ベースのボイスサービスのものと同様にサービスのレベルを提供しなければなりません。 これは例えば切符の売上回線やタイムテーブル情報などの音声自動応答システムのコントロールにDTMFシグナリングを使用する能力を含んでいます。
The transport of DTMF tones from the mobile terminal to target systems that may be in the PSTN, or to SIP-based solutions (i.e., no PSTN connection), must be supported.
移動体端末からPSTNにあるかもしれない目標システムまでSIPベースのソリューション(すなわち、PSTN接続がない)へのDTMFトーンの輸送をサポートしなければなりません。
The transport of DTMF signals may be required for the whole call, just for the first part, or from some later point in the call. The start time and duration of such signaling is therefore unpredictable.
DTMF信号の輸送がまさしく最初の部分、または、全体の呼び出しか、呼び出しにおける何らかの後のポイントから必要であるかもしれません。 したがって、そのようなシグナリングの開始時刻と持続時間は予測できません。
We believe that the mechanisms specified in RFC 2833 [8] meet the requirement without impacting SIP.
私たちは、RFC2833[8]で指定されたメカニズムがSIPに影響を与えないで条件を満たすと信じています。
Garcia-Martin Informational [Page 24] RFC 4083 3GPP R5 Requirements on SIP May 2005
一口2005年5月に関するガルシア-マーチンの情報[24ページ]のRFC4083 3GPP R5要件
4.19.3. Early Media
4.19.3. 早めのメディア
As mobile terminals will frequently interoperate with the PSTN, support for early media is required.
移動体端末がPSTNと共に頻繁に共同利用するように、早めのメディアのサポートが必要です。
4.20. Exchange of Session Description
4.20. セッション記述の交換
Typically a session description protocol such as SDP is used in SIP to describe the media streams and codecs needed to establish the session. SIP uses an offer/answer model of the session description, as described in RFC 3264 [11], in which one of the parties offers his session description and the other answers that offer.
通常、SDPなどのセッション記述プロトコルはメディアストリームについて説明するのにSIPで使用されました、そして、コーデックはセッションを確立する必要がありました。 SIPはセッション記述の申し出/答えモデルを使用します、RFC3264[11](パーティーのひとりは彼のセッション記述を提供します、そして、もう片方がその申し出に答える)で説明されるように。
In the 3GPP IMS, the mobile terminals might have restrictions with the memory, DSP capacity, etc. As such, a mechanism is required by which the Session Description negotiation may conclude with one out of many codecs per media stream. Both UAC and UAS must know, prior to any media being sent or received, which codec is used for each media stream.
3GPP IMSでは、移動体端末はメモリ、DSP容量などがある制限を持っているかもしれません。 そういうものとして、Session記述交渉が多くのメディアストリームあたりのコーデックから1つで締めくくるかもしれないメカニズムが必要です。 UACとUASの両方が、何か送るか、または受け取るメディアの前でどのコーデックがそれぞれのメディアストリームに使用されるかを知らなければなりません。
In the 3GPP IMS, efficient use of the network and radio resources is an important requirement. As such, the network should know in advance which codec is used for a particular media stream. The network access control may use this information to grant access to the network and to control the resource utilization.
3GPP IMSでは、ネットワークとラジオリソースの効率的な使用は重要な要件です。 そういうものとして、ネットワークは、あらかじめ、どのコーデックが特定のメディアストリームに使用されるかを知るべきです。 ネットワークアクセス制御は、ネットワークへのアクセスを承諾して、リソース利用を制御するのにこの情報を使用するかもしれません。
Additionally, it is required that the party who pays for the resource utilization have the opportunity to decide which codecs to use, once both end parties are aware of the capabilities supported at the remote UA.
さらに、リソース利用の代価を払うパーティーがどのコーデックを使用したらよいかを決める機会を持つのが必要です、両方の終わりのパーティーがいったんリモートUAでサポートされた能力を意識するようになると。
Therefore, a mechanism is required by which both UAC and UAS have the ability to negotiate and trim down the number of codecs used per media stream, so that at the end of the negotiation there can be a reduced set of agreed codecs per media stream.
したがって、UACとUASがメディア単位で使用されるコーデックの数を交渉して、減らす能力を1メディアあたりそこの交渉の終わりのそれが減少しているセットの同意されたコーデックであることができるために流させる両方が流れるメカニズムが必要です。
We believe that the mechanism specified in RFC 3264 [11] meets the requirement.
私たちは、RFC3264[11]で指定されたメカニズムが条件を満たすと信じています。
Garcia-Martin Informational [Page 25] RFC 4083 3GPP R5 Requirements on SIP May 2005
一口2005年5月に関するガルシア-マーチンの情報[25ページ]のRFC4083 3GPP R5要件
4.21. Prohibition of Certain SDP Parameters
4.21. あるSDPパラメタの禁止
4.21.1. Prohibition of Codecs
4.21.1. コーデックの禁止
The SIP outbound proxy may contain local policy rules with respect the codecs allowed in the network. For instance, certain networks may disallow high-bandwidth-consuming audio codecs. There has to be a mechanism whereby the SIP outbound proxy can reject a session establishment attempt when a codec is prohibited in the network due to local policy.
SIPの外国行きのプロキシはコーデックがネットワークで許容した敬意を伴うローカルの政策ルールを含むかもしれません。 例えば、あるネットワークは高帯域幅消費オーディオコーデックを禁じるかもしれません。 ローカルの方針のため、コーデックがネットワークで禁止されているときSIPの外国行きのプロキシがセッション設立試みを拒絶できるメカニズムがなければなりません。
4.21.2. Prohibition of Media Types
4.21.2. メディアタイプの禁止
Certain users' subscriptions may include restrictions on certain media types. For instance, a user may not be allowed to establish a video session. The SIP serving proxy in the home network downloads the user profile, which contains the rules for these kinds of restrictions.
確信しているユーザの購読はあるメディアタイプにおける制限を含むかもしれません。 例えば、ユーザはビデオセッションを確立できないかもしれません。 ホームネットワークにプロキシに役立つSIPはユーザ・プロファイルをダウンロードします。(それは、これらの種類の制限のための規則を含みます)。
As the establishment of sessions traverse the SIP serving proxy in the home network, the proxy can prohibit an attempt to establish a session that includes a non-allowed media type for the user. Therefore, there has to be a mechanism whereby the SIP serving proxy can reject a session establishment attempt when the session includes a forbidden media type.
セッションの設立がホームネットワークにプロキシに役立つSIPを横断するとき、プロキシはユーザのための非許容されたメディアタイプを含んでいるセッションを確立する試みを禁止できます。 したがって、セッションが禁制のメディアタイプを含んでいるとプロキシに役立つSIPがセッション設立試みを拒絶できるメカニズムがなければなりません。
4.22. Network-initiated Re-authentication
4.22. ネットワークによって開始された再認証
Network operators need to authenticate users to ensure that they are charged appropriately for the services they use. The re-authentication done when the user initiates a message will not suffice for this purpose, as described below.
ネットワーク・オペレータは、自分達がそれらが利用するサービスのために適切に請求されるのを保証するためにユーザを認証する必要があります。 ユーザがメッセージを開始するとき行われた再認証は以下で説明されるようにこのために十分でないでしょう。
If the duration of the authentication period is set to a relatively low value to ensure that the user cannot incur a high amount of charges between two authentications, it may create a lot of unnecessary authentications of users that have remained largely inactive, and therefore it may use unnecessary air interface resources.
比較的低い値に認証の期間の持続時間が、ユーザが2つの認証の間の充電の多量を被ることができないのを保証するように設定されるなら、主に不活発なままでいたユーザの多くの不要な認証を作成するかもしれません、そして、したがって、不要な空気インタフェースリソースを使用するかもしれません。
If the duration of the authentication period is set to a relatively high value to avoid these unnecessary authentications, the risk is then that some users may incur high charges between authentications.
比較的高い値に認証の期間の持続時間がこれらの不要な認証を避けるように設定されるなら、リスクはその時何人かのユーザが認証の間の高い充電を被るかもしれないということです。
Garcia-Martin Informational [Page 26] RFC 4083 3GPP R5 Requirements on SIP May 2005
一口2005年5月に関するガルシア-マーチンの情報[26ページ]のRFC4083 3GPP R5要件
A user's authentication is automatically invalidated when a certain threshold for charges (or number, or duration of sessions) is reached without giving the user a chance to re-authenticate, even if a valid registration exists. This would not provide an adequate level of service.
充電(または、数、またはセッションの持続時間)のためのある敷居に再認証する機会をユーザに与えないで達しているとき、ユーザの認証は自動的に無効にされます、有効な登録が存在していても。 これは適切なレベルのサービスを提供しないでしょう。
Consequently, it must be possible for the network to initiate a re-authentication process at any time. The triggers must be set within the network and may include charging thresholds, number of events, session duration, etc.
その結果、ネットワークがいつでも再認証過程を開始するのは、可能でなければなりません。 引き金は、ネットワークの中に設定しなければならなくて、敷居、イベントの数、セッション持続時間などを請求するのを含むかもしれません。
4.23. Security Model
4.23. 機密保護モデル
Sections 4.23, 4.24, and 4.25 have been based on the 3GPP Technical Specifications 33.203 [32], 23.228 [28], and 33.210 [33].
セクション4.23、4.24、および4.25 3GPP仕様書33.203[32]、23.228[28]、および33.210[33]に基づいてください、そうした。
The scope for security of the 3GPP IMS is the SIP signaling between the various SIP entities. Protecting the end-to-end media streams may be a future extension, but it is not considered in the Release 5 version of the IMS specifications.
3GPP IMSのセキュリティのための範囲は様々なSIP実体の間で合図するSIPです。 終わりから終わりへのメディアストリームを保護するのは、今後の拡大であるかもしれませんが、それはIMS仕様のRelease5バージョンで考えられません。
Each operator providing IMS services acts as its own domain of trust and shares a long-term security association with its subscribers (e.g., pre-shared keys). Operators may enter into roaming agreements with other operators, in which case a certain level of trust exists between their respective domains.
サービスをIMSに供給する各オペレータがそれ自身の信頼とシェアのドメインとして加入者(例えば、あらかじめ共有されたキー)との長期のセキュリティ仲間を務めます。 オペレータは他のオペレータとのローミング協定に入るかもしれません、その場合、あるレベルの信頼が彼らのそれぞれのドメインの間に存在しています。
SIP UAs must authenticate to their home network before the use of IMS resources is authorized. In Release 5 of the 3GPP IMS specifications, authentication is performed during registration and re-registrations.
SIP UAsはIMSの使用の前に彼らのホームネットワークに認可されたリソースを認証しなければなりません。 3GPP IMS仕様のRelease5では、認証は登録と再登録証明書の間、実行されます。
Portions of the SIP signaling must be protected hop by hop. Looking at Figure 1 in Section 3, we can distinguish two distinct zones where the required security is unique:
SIPシグナリングの部分はホップであるに違いありませんごとに保護される。 セクション3の図1を見て、私たちは必要なセキュリティがユニークである2つの異なったゾーンを区別できます:
o Access Domain: Between the SIP user device and the visited
network.
o ドメインにアクセスしてください: SIPユーザデバイスと訪問されたネットワークの間で。
o Network Domain: Between the visited and home networks, or inside
the home network.
o ドメインをネットワークでつないでください: 訪問とホームネットワークの間、または、ホームネットワークの中において。
Characteristics needed in the Access Domain are quite different from those of the Network Domain because of the terminal's requirements for mobility, computation restriction, battery limit, bandwidth conservation, and radio interface. SIP entities in the access domain should be able to maintain security contexts with a large group of users in parallel. Furthermore, Access Domain provides user-specific
Access Domainで必要である特性は移動性、計算制限、バッテリー限界、帯域幅保護、およびラジオインタフェースのための端末の要件でNetwork Domainのものと全く異なっています。 大きいユーザー層が平行な状態でアクセスドメインのSIP実体はセキュリティ文脈を維持できるべきです。 その上、Access Domainはユーザ特有の状態で提供します。
Garcia-Martin Informational [Page 27] RFC 4083 3GPP R5 Requirements on SIP May 2005
一口2005年5月に関するガルシア-マーチンの情報[27ページ]のRFC4083 3GPP R5要件
security associations, whereas Network Domain provides security associations between network nodes. Therefore, the weight of protocols and algorithms and their compliance with compression mechanisms are very important to Access Domain Security. It is therefore required that the security solutions allow different mechanisms in these two domains.
Network Domainはネットワーク・ノードの間のセキュリティ協会を提供しますが、セキュリティ協会。 したがって、プロトコルとアルゴリズムの重さと圧縮機構への彼らのコンプライアンスはAccess Domain Securityに非常に重要です。 したがって、セキュリティソリューションがこれらの2つのドメインに異なったメカニズムを許容するのが必要です。
4.24. Access Domain Security
4.24. アクセスドメインセキュリティ
4.24.1. General Requirements
4.24.1. 一般要件
4.24.1.1. Scalability and Efficiency
4.24.1.1. スケーラビリティと効率
3GPP IMS is characterized by a large subscriber base of up to a billion users, all of which must be treated in a secure manner.
3GPP IMSは最大10億人のユーザの大きい加入者ベースによって特徴付けられます。安全な方法でそのすべてを扱わなければなりません。
The security solutions must allow global roaming among a large number of administrative domains.
セキュリティソリューションは多くの管理ドメインの中に国際ローミングを許容しなければなりません。
4.24.1.2. Bandwidth and Round-trips
4.24.1.2. 帯域幅と周遊旅行
The wireless interface in 3GPP terminals is an expensive resource both in terms of power consumption and maximum use of scarce spectrum. Furthermore, cellular networks typically have long round-trip time delays, which must be taken in account in the design of the security solutions.
不十分なスペクトルの電力消費量と最大の使用で3GPP端末のワイヤレスインターフェースは高価なリソースです。 その上、セルラー・ネットワークには、長い往復の時間遅れが通常あります。(セキュリティソリューションのデザインで遅れを考慮に入れなければなりません)。
Any security mechanism that involves 3GPP terminals should not unnecessarily increase the bandwidth needs.
3GPP端末にかかわるどんなセキュリティー対策も不必要に帯域幅の必要性を増強するはずがありません。
All security mechanisms that involve 3GPP terminals should minimize the number of necessary extra round-trips. In particular, during normal call signaling there should not be any additional security- related messages.
3GPP端末にかかわるすべてのセキュリティー対策が必要な付加的な周遊旅行の数を最小にするはずです。 あるべきでない正常な呼び出しシグナリングの間、特に、どんな追加セキュリティもメッセージについて話しました。
4.24.1.3. Computation
4.24.1.3. 計算
It must be possible for mobile device terminals to provide security without requiring public key cryptography and/or certificates. 3GPP IMS may, however, include optional security schemes that employ these techniques.
モバイル機器端末が公開鍵暗号、そして/または、証明書を必要としないでセキュリティを提供するのは、可能であるに違いありません。 しかしながら、3GPP IMSはこれらのテクニックを使う任意のセキュリティ体系を含むかもしれません。
Current HTTP authentication methods use only symmetric cryptography, as required here. Lower-layer mechanisms (IKE, TLS) require implementation of public-key cryptography e.g., Diffie-Hellman. If these lower-layer mechanisms were used, the mobile terminal would authenticate and negotiate session keys with the visited network using only symmetric methods.
現在のHTTP認証方法は必要に応じてここで左右対称の暗号だけを使用します。 下層メカニズム(IKE、TLS)は例えば、公開鍵暗号ディフィーヘルマンの実装を必要とします。 これらの下層メカニズムが使用されるなら、移動体端末は、左右対称のメソッドだけを使用する訪問されたネットワークと、セッションキーを認証して、交渉するでしょうに。
Garcia-Martin Informational [Page 28] RFC 4083 3GPP R5 Requirements on SIP May 2005
一口2005年5月に関するガルシア-マーチンの情報[28ページ]のRFC4083 3GPP R5要件
4.24.1.4. Independence of the Transport Protocol
4.24.1.4. トランスポート・プロトコルからの独立
The selected security mechanism should work with any transport protocol allowed by SIP (e.g., TCP, UDP).
どんなトランスポート・プロトコルもSIP(例えば、TCP、UDP)によって許容されている状態で、選択されたセキュリティー対策は動作するはずです。
4.24.2. Authentication
4.24.2. 認証
Authentication, as used in this context, means entity authentication that enables two entities to verify the identity of the respective peer.
このような関係においては使用される認証は2つの実体がそれぞれの同輩のアイデンティティについて確かめるのを可能にする実体認証を意味します。
4.24.2.1. Authentication Method
4.24.2.1. 認証方法
A strong, mutual authentication must be provided.
強くて、互いの認証を提供しなければなりません。
The authentication method must be able to work when there are zero or more SIP proxies in the SIP path between the authenticator and the authenticated user.
ゼロか、より多くのSIPプロキシが固有識別文字と認証されたユーザの間のSIP経路にあるとき、認証方法は働くことができなければなりません。
It must be possible to support extensible authentication methods. Therefore, authentication using an extensible authentication framework is strongly recommended.
広げることができる認証がメソッドであるとサポートするのは可能であるに違いありません。 したがって、広げることができる認証フレームワークを使用する認証が強く推薦されます。
Authentication methods based on the secure storage of long-term keys used for authentication and the secure execution of authentication algorithms must be supported.
認証に使用される長期のキーの安全なストレージと認証アルゴリズムの安全な実行に基づく認証方法をサポートしなければなりません。
The SIP client's credentials must not be transferred as plain text.
プレーンテキストとしてSIPクライアントの資格証明書を移してはいけません。
3GPP intends to reuse UMTS AKA [13]. UMTS AKA applies a symmetric cryptographic scheme, provides mutual authentication, and is typically implemented on a so-called SIM card that provides secure storage on the user's side.
3GPPはUMTS AKA[13]を再利用するつもりです。 UMTS AKAは左右対称の暗合方式を適用して、互いの認証を提供して、ユーザの側で安全なストレージを提供するいわゆるSIMカードで通常実装されます。
Additional requirements related to message protection that apply to the authentication method are stated in Section 4.24.3.
認証方法に適用されるメッセージ保護に関連する追加要件はセクション4.24.3で述べられています。
4.24.3. Message Protection
4.24.3. メッセージ保護
4.24.3.1. Message Protection Mechanisms
4.24.3.1. メッセージ保護メカニズム
SIP entities (typically a SIP client and a SIP proxy) must be able to communicate using integrity. By integrity, we mean the ability for the receiver of a message to verify that the message has not been modified in transit. SIP entities should be able to communicate confidentially. In 3GPP IMS, these protection modes must be based on initial authentication. Integrity protection and confidentiality must be possible using symmetric cryptographic keys.
SIP実体(通常SIPクライアントとSIPプロキシ)は、保全を使用することで交信できなければなりません。 保全で、私たちはメッセージがトランジットで変更されていないことを確かめるメッセージの受信機のために能力を言っています。 SIP実体は秘密に交信できるべきです。 3GPP IMSでは、これらの保護モードを初期の認証に基礎づけなければなりません。 保全保護と秘密性は、左右対称の暗号化キーを使用することで可能であるに違いありません。
Garcia-Martin Informational [Page 29] RFC 4083 3GPP R5 Requirements on SIP May 2005
一口2005年5月に関するガルシア-マーチンの情報[29ページ]のRFC4083 3GPP R5要件
It must also be possible to handle error conditions in a satisfactory manner as to allow recovery (see also sections 4.3.6.3 and 4.14).
また、満足のできるようにエラー条件を扱うのも回復を許すほど可能でなければならない、(また、セクション4.3.6を見てください、.3と4.14)
It must be possible to provide this protection between two adjacent SIP entities. In future network scenarios, it may also be necessary to provide this protection through proxies, though the 3GPP Release 5 IMS does not require this.
2つの隣接しているSIP実体の間にこの保護を提供するのは可能であるに違いありません。 また、将来のネットワークシナリオでは、プロキシを通してこの保護を提供するのも必要であるかもしれません、5IMSがする3GPP Releaseはこれを必要としませんが。
The security mechanism must be able to protect a complete SIP message.
セキュリティー対策は完全なSIPメッセージを保護できなければなりません。
If header compression/removal or SIP compression is applied to SIP messages, it must be compatible with message protection.
ヘッダー圧縮/除去かSIP圧縮がSIPメッセージに適用されるなら、メッセージ保護と互換性があるに違いありません。
4.24.3.2. Delegation
4.24.3.2. 委譲
3GPP IMS implements distributed security functions responsible for authentication and message protection.
3GPP IMSは、分配されたセキュリティが認証とメッセージ保護に原因となる機能であると実装します。
It must be possible to perform an initial authentication based on long-term authentication credentials, followed by subsequent protected signaling that uses short-term authentication credentials, such as session keys created during initial authentication. The authentication mechanism used is able to provide such session keys. It must be possible to apply subsequent message protection as soon as possible, even during the initial authentication period.
短期的な認証資格証明書を使用するその後の保護されたシグナリングがあとに続いた長期の認証資格証明書に基づく初期の認証を実行するのは可能であるに違いありません、初期の認証の間に作成されたセッションキーなどのように。 使用される認証機構はそのようなセッションキーを提供できます。 できるだけ早く初期の認証の期間さえ、その後のメッセージ保護を適用するのは可能であるに違いありません。
Initial authentication is performed between the SIP UA and the authenticating SIP serving proxy in the home network. However, the authentication mechanism must not require access to the long-term authentication credentials in these nodes. In the home network, the authenticating SIP serving proxy must support interaction with a dedicated authentication server in order to accomplish the authentication task. At the client side, a secured (tamper-resistant) device storing the long-term credentials of the user must perform the authentication.
初期の認証は、ホームネットワークにプロキシに役立ちながら、SIP UAと認証しているSIPの間で実行されます。 しかしながら、認証機構はこれらのノードの長期の認証資格証明書へのアクセスを必要としてはいけません。 ホームネットワーク、プロキシに役立つSIPがそうしなければならない認証では、認証タスクを達成するためにひたむきな認証サーバとの相互作用をサポートしてください。 クライアント側では、ユーザの長期の資格証明書を保存する機密保護している(耐タンパー性)デバイスが認証を実行しなければなりません。
Additionally, the SIP serving proxy that performed the initial authentication must be able to delegate subsequent SIP signaling protection (e.g., session keys for integrity or encryption) securely to an authorized SIP proxy further downstream. The tamper-resistant device at the client side must be able to delegate the session keys securely to the SIP UA.
さらに、初期の認証を実行したプロキシに役立つSIPは川下でしっかりと、さらに、その後のSIPシグナリング保護(例えば、保全か暗号化のためのセッションキー)を認可されたSIPプロキシへ代表として派遣することができなければなりません。 クライアント側の耐タンパー性デバイスはしっかりとセッションキーをSIP UAへ代表として派遣することができなければなりません。
Garcia-Martin Informational [Page 30] RFC 4083 3GPP R5 Requirements on SIP May 2005
一口2005年5月に関するガルシア-マーチンの情報[30ページ]のRFC4083 3GPP R5要件
4.24.4. Negotiation of Mechanisms
4.24.4. メカニズムの交渉
A method must be provided to negotiate the security mechanisms to be used in the access domain securely.
アクセスドメインでしっかりと使用されるためにセキュリティー対策を交渉するためにメソッドを提供しなければなりません。
This method must at least support the negotiation of different security mechanisms providing integrity protection and encryption, algorithms used within these mechanisms, and additional parameters that they require in order to be exchanged.
このメソッドは保全保護と暗号化を提供する異なったセキュリティー対策、これらのメカニズムの中で使用されたアルゴリズム、および彼らが交換するために必要とする追加パラメタの交渉を少なくともサポートしなければなりません。
The negotiation mechanism must protect against attackers who do not have access to authentication credentials. In particular, the negotiation mechanism must be able to detect a possible man-in-the-middle attacker who could influence the negotiation result so that services with weaker security or with none are negotiated.
交渉メカニズムは認証資格証明書に近づく手段を持っていない攻撃者から守らなければなりません。 特に、交渉メカニズムが交渉結果に影響を及ぼすことができた可能な中央の男性攻撃者を検出できなければならないので、より弱いセキュリティかなにもがあるサービスは交渉されます。
A negotiation mechanism is generally required in all secure protocols to decide which security services to use and when they should be started. This security mechanism serves algorithm and protocol development as well as interoperability. Often, the negotiation is handled within a security service. For example, the HTTP authentication scheme includes a selection mechanism for choosing among appropriate algorithms. Note that when referring to negotiation we mean just the negotiation, not all functions in protocols such as IKE. For instance, we expect that the session key generation is to be a part of the initial authentication.
一般に、交渉メカニズムが、どのセキュリティー・サービスを使用するか、そして、それらがいつ出発するべきであるかを決めるのにすべての安全なプロトコルで必要です。 このセキュリティー対策は相互運用性と同様にアルゴリズムとプロトコル開発に役立ちます。 しばしば、交渉はセキュリティー・サービスの中で扱われます。 例えば、HTTP認証体系は適切なアルゴリズムの中で選ぶための選択メカニズムを含んでいます。交渉について言及するとき、私たちがIKEなどのプロトコルですべての機能ではなく、まさしく交渉を言っていることに注意してください。 例えば、私たちは、セッションキー生成による初期の認証の一部であることになっていると予想します。
SIP entities must be able to use the same security mode parameters to protect several SIP sessions without re-negotiation. For example, security mode parameters may be assumed to be valid within the lifetime of a registration. Note that it is necessary to amortize the cost of security association setup and parameter negotiation over several INVITEs.
SIP実体は、再交渉なしでいくつかのSIPセッションに保護するのに同じセキュリティモードパラメタを使用できなければなりません。 例えば、セキュリティモードパラメタが登録の生涯中に有効であると思われるかもしれません。 数個のINVITEsの上のセキュリティ協会セットアップとパラメタ交渉の費用を清算するのが必要であることに注意してください。
4.24.5. Verification of Messages
4.24.5. メッセージの検証
4.24.5.1. Verification at the SIP Outbound Proxy
4.24.5.1. 一口の外国行きのプロキシでの検証
The SIP outbound proxy must be able to guarantee the message origin and to verify that the message has not been changed (e.g., it is integrity protected).
SIPの外国行きのプロキシは、メッセージ発生源を保証して、メッセージが変えられていないことを確かめることができなければなりません(例えば、それは保護された保全です)。
4.24.5.2. Verification at the SIP Serving Proxy
4.24.5.2. プロキシに役立つ一口での検証
The serving SIP proxy needs to receive an indication if the outbound proxy was able to verify the message origin and, in the case of a REGISTER request, whether or not it was integrity protected.
外国行きのプロキシがメッセージ発生源について確かめることができて、REGISTER要求の場合では、それが保全であったかどうかが保護されたなら、給仕SIPプロキシは、指示を受ける必要があります。
Garcia-Martin Informational [Page 31] RFC 4083 3GPP R5 Requirements on SIP May 2005
一口2005年5月に関するガルシア-マーチンの情報[31ページ]のRFC4083 3GPP R5要件
4.25. Network Domain Security
4.25. ネットワークドメインセキュリティ
Message authentication, key agreement, integrity and replay protection, and confidentiality must be provided for communications between SIP network entities such as proxy servers.
通報認証、主要な協定、保全、反復操作による保護、および秘密性をプロキシサーバなどのSIPネットワーク実体のコミュニケーションに提供しなければなりません。
Network domain security mechanisms must be scalable up to a large number of network elements.
ネットワークドメインセキュリティー対策は多くのネットワーク要素までスケーラブルであるに違いありません。
3GPP intends to make having the protection discussed above mandatory at least between two operators, and optional within an operator's own network. Security gateways exist between operator's networks.
3GPPは保護を持っているのを少なくとも2人のオペレータの間で義務的な上で議論して、オペレータの自身のネットワークの中で任意にするつもりです。 セキュリティゲートウェイはオペレータのネットワークの間に存在しています。
We believe that the above requirements are fulfilled by applying security mechanisms as specified in the current IP Security standards in RFC 2401 [5].
私たちは、上記の要件がRFC2401[5]の現在のIP Security規格における指定されるとしてのセキュリティー対策を適用することによって実現すると信じています。
5. Security Considerations
5. セキュリティ問題
This document does not define a protocol, but still presents some security requirements to protocols. The main security requirements are stated in sections 4.23, 4.24, and 4.25. Additional security-related issues are discussed under sections 4.6, 4.7, 4.8, 4.9, 4.10, and 4.12.
このドキュメントは、プロトコルを定義しませんが、まだいくつかのセキュリティ要件をプロトコルに提示しています。 主なセキュリティ要件はセクション4.23、4.24、および4.25で述べられています。 セクション4.6、4.7、4.8、4.9、4.10、および4.12の下で追加セキュリティ関連の問題について議論します。
6. Contributors
6. 貢献者
The following people contributed to this document:
以下の人々はこのドキュメントに貢献しました:
Duncan Mills (Vodafone), Gabor Bajko (Nokia), Georg Mayer (Siemens), Francois-Xerome Derome (Alcatel), Hugh Shieh (AWS), Andrew Allen (dynamicsoft), Sunil Chotai (mmO2), Keith Drage (Lucent), Jayshree Bharatia (Nortel), Kevan Hobbis (Huthison 3G UK), Dean Willis (dynamicsoft), Krisztian Kiss (Nokia), Vesa Torvinen (Ericsson), Jari Arkko (Ericsson), and Sonia Garapaty (Nortel).
ダンカン工場(ボーダフォン)、ガボールBajko(ノキア)、ゲオルク・マイヤー(シーメンス)、フランソア-Xerome Derome(アルカテル)、ヒューShieh(AWS)、アンドリュー・アレン(dynamicsoft)、Sunil Chotai(mmO2)、キースDrage(透明な)、Jayshree Bharatia(ノーテル)キーヴァンHobbis(Huthison 3Gイギリス)、ディーン・ウィリス(dynamicsoft)、Krisztianは(ノキア)、Vesa Torvinen(エリクソン)、ヤリArkko(エリクソン)、およびソニアGarapaty(ノーテル)にキスします。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[2] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
Garcia-Martin Informational [Page 32] RFC 4083 3GPP R5 Requirements on SIP May 2005
一口2005年5月に関するガルシア-マーチンの情報[32ページ]のRFC4083 3GPP R5要件
7.2. Informative References
7.2. 有益な参照
[3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[3] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[4] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[4]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、1998年8月。
[5] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[5] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[6] Aboba, B. and M. Beadles, "The Network Access Identifier",
RFC 2486, January 1999.
[6]AbobaとB.とM.用務員、「ネットワークアクセス識別子」、RFC2486、1999年1月。
[7] Shirey, R., "Internet Security Glossary", RFC 2828, May 2000.
[7] Shirey(R.、「インターネットセキュリティ用語集」、RFC2828)は2000がそうするかもしれません。
[8] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[8] Schulzrinne、H.、およびS.Petrack(「DTMFケタ、電話トーン、および電話信号のためのRTP有効搭載量」、RFC2833)は2000がそうするかもしれません。
[9] Faltstrom, P., "E.164 number and DNS", RFC 2916, September
2000.
[9]Faltstromと、P.と、「E.164番号とDNS」、RFC2916、9月2000日
[10] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[10] ローゼンバーグ、J.、およびH.Schulzrinne、「セッション開始は(一口)について議定書の中で述べます」。 「一口サーバの場所を見つけます」、RFC3263、2002年6月。
[11] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[11] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
[12] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[12] ローチ、A.、「セッション開始プロトコル(一口)特定のイベント通知」、RFC3265、2002年6月。
[13] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer
Protocol (HTTP) Digest Authentication Using Authentication and
Key Agreement (AKA)", RFC 3310, September 2002.
Torvinenと、[13]Niemi、A.、Arkko、J.、およびRFC3310、2002年9月対「認証を使用するハイパーテキスト転送プロトコル(HTTP)ダイジェスト認証と主要な協定(別名)」
[14] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680, March 2004.
[14] ローゼンバーグ、J.、「登録証明書のためのセッション開始プロトコル(一口)イベントパッケージ」、RFC3680、2004年3月。
[15] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of
Resource Management and Session Initiation Protocol (SIP)", RFC
3312, October 2002.
[15] キャマリロ、G.、マーシャル、W.、およびJ.ローゼンバーグ、「資源管理とセッション開始プロトコル(一口)の統合」、RFC3312(2002年10月)。
[16] Marshall, W., "Private Session Initiation Protocol (SIP)
Extensions for Media Authorization", RFC 3313, January 2003.
[16] マーシャル、W.、「メディア承認のための個人的なセッション開始プロトコル(一口)拡大」、RFC3313、2003年1月。
Garcia-Martin Informational [Page 33] RFC 4083 3GPP R5 Requirements on SIP May 2005
一口2005年5月に関するガルシア-マーチンの情報[33ページ]のRFC4083 3GPP R5要件
[17] Jennings, C., Peterson, J., and M. Watson, "Private Extensions
to the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks", RFC 3325, November 2002.
[17] ジョニングス、C.、ピーターソン、J.、およびM.ワトソン、「セッション開始への個人的な拡大は断言されたアイデンティティのために信じられたネットワークの中で(一口)について議定書の中で述べます」、RFC3325、2002年11月。
[18] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002.
[18] ピーターソン、J.、「セッション開始プロトコル(一口)のためのプライバシーメカニズム」、RFC3323、2002年11月。
[19] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration
Protocol (DHCPv6) Options for Session Initiation Protocol (SIP)
Servers", RFC 3319, July 2003.
[19] Schulzrinne、H.、およびB.フォルツ、「セッション開始のためのDynamic Host Configuration Protocol(DHCPv6)オプションは(一口)サーバについて議定書の中で述べます」、RFC3319、2003年7月。
[20] Sparks, R., "Session Initiation Protocol Call Control -
Transfer", Work in Progress, February 2005.
[20] R.、「セッション開始プロトコル呼び出しコントロール--移す」というスパークは進歩、2005年2月に働いています。
[21] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K.
Summers, "Session Initiation Protocol (SIP) Basic Call Flow
Examples", BCP 75, RFC 3665, December 2003.
[21] ジョンストン、A.、ドノヴァン、S.、スパークス、R.、カニンハム、C.、およびK.夏、「セッション開始プロトコル(一口)基本的な呼び出し流れの例」、BCP75、RFC3665、2003年12月。
[22] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K.
Summers, "Session Initiation Protocol (SIP) Public Switched
Telephone Network (PSTN) Call Flows", BCP 76, RFC 3666,
December 2003.
[22] ジョンストン、A.、ドノヴァン、S.、スパークス、R.、カニンハム、C.、およびK.サマーズ、「セッション開始プロトコル(一口)公衆電話交換網(PSTN)呼び出しは流れます」、BCP76、RFC3666、2003年12月。
[23] Johnston, A. and R. Sparks, "Session Initiation Protocol
Service Examples", Work in Progress, February 2005.
[23] 「セッション開始プロトコルサービスの例」というジョンストン、A.、およびR.スパークスは進歩、2005年2月に働いています。
[24] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[24] スパークス、R.、「セッション開始プロトコル(一口)はメソッドを参照する」RFC3515、2003年4月。
[25] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) 'Replaces' Header", RFC 3891, September 2004.
[25] マーイ、R.、ビッグズ、B.、およびR.ディーン、「セッション開始プロトコル(一口)'は2004年9月に'ヘッダー」、RFC3891を取り替えます。
[26] 3GPP, "TS 23.003 Numbering, addressing and identification
(Release 5)", September 2002,
<ftp://ftp.3gpp.org/Specs/archive/23_series/23.003/>.
[26] 3GPPと、「TS23.003Numbering、アドレシング、および識別(リリース5)」2002年9月<ftpな://ftp.3gpp.org/仕様/アーカイブ/23_series/23.003/>。
[27] 3GPP, "TS 23.060:General Packet Radio Service (GRPS); Service
Description; Stage 2", September 2002,
<ftp://ftp.3gpp.org/Specs/archive/23_series/23.060/>.
[27] 3GPP、「t23.060: 汎用パケット無線システム(GRPS)」。 記述を修理してください。 2インチに、2002年9月、<ftp://ftp.3gpp.org/仕様/アーカイブ/23に_series/23.060/>を上演してください。
[28] 3GPP, "TS 23.228: IP Multimedia Subsystem (IMS) (Stage 2) -
Release 5", September 2002,
<ftp://ftp.3gpp.org/Specs/archive/23_series/23.228/>.
[28] 3GPP、「t23.228:」 IPマルチメディアサブシステム(IMS)(ステージ2)--5インチに、2002年9月、<ftp://ftp.3gpp.org/仕様/アーカイブ/23に_series/23.228/>をリリースしてください。
[29] 3GPP, "TS 24.228: Signaling flows for the IP Multimedia call
control based on SIP and SDP", September 2002,
<ftp://ftp.3gpp.org/Specs/archive/24_series/24.228/>.
[29] 3GPP、「t24.228:」 「シグナリングはSIPとSDPに基づくIP Multimedia呼び出しコントロールのために流れる」2002年9月、<ftp://ftp.3gpp.org/仕様/アーカイブ/24_series/24.228/>。
Garcia-Martin Informational [Page 34] RFC 4083 3GPP R5 Requirements on SIP May 2005
一口2005年5月に関するガルシア-マーチンの情報[34ページ]のRFC4083 3GPP R5要件
[30] 3GPP, "TS 24.229: IP Multimedia Subsystem (IMS) (Stage 3) -
Release 5", September 2002,
<ftp://ftp.3gpp.org/Specs/archive/24_series/24.229/>.
[30] 3GPP、「t24.229:」 IPマルチメディアサブシステム(IMS)(ステージ3)--5インチに、2002年9月、<ftp://ftp.3gpp.org/仕様/アーカイブ/24に_series/24.229/>をリリースしてください。
[31] 3GPP, "TS 32.225: Telecommunication Management; Charging
Management; Charging Data Description for IP Multimedia
Subsystem; (Release 5)", September 2002,
<ftp://ftp.3gpp.org/Specs/archive/32_series/32.225/>.
[31] 3GPP、「t32.225:」 電気通信管理。 管理を請求します。 IPマルチメディアサブシステムのための課金データ記述。 (リリース5)「2002年9月に、<ftp://ftp.3gpp.org/仕様/は/32_series/32.225/>を格納します。」
[32] 3GPP, "TS 32.203: 3G Security; Access security for IP based
services; (Release 5)", September 2002,
<ftp://ftp.3gpp.org/Specs/archive/33_series/33.203/>.
[32] 3GPP、「t32.203:」 3Gセキュリティ。 IPのためのアクセス保護はサービスを基礎づけました。 (リリース5)「2002年9月に、<ftp://ftp.3gpp.org/仕様/は/33_series/33.203/>を格納します。」
[33] 3GPP, "TS 32.210: 3G Security; Network Domain Security; IP
network layer security (Release 5)", September 2002,
<ftp://ftp.3gpp.org/Specs/archive/33_series/33.210/>.
[33] 3GPP、「t32.210:」 3Gセキュリティ。 ドメインセキュリティをネットワークでつないでください。 「IPネットワーク層セキュリティ(リリース5)」、2002年9月、<ftp://ftp.3gpp.org/仕様/アーカイブ/33_series/33.210/>。
[34] ITU-T, "Recommendation E.164 (05/97): The international public
telecommunication numbering plan", May 1997,
<http://www.itu.int/rec/recommendation.asp?
type=folders&lang=e&parent=T-REC-E.164>.
[34] ITU-T、「推薦E.164(05/97):」 「国際的な公共の電気通信付番プラン」、1997年5月、<http://www.itu.int/rec/recommendation.asp--=フォルダー、lang=e、および親=T-REC-E.164>をタイプしてください。
[35] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004.
[35]Schulzrinne、2004年12月のH.、「Telephone民数記のためのtel URI」RFC3966。
Author's Address
作者のアドレス
Miguel A. Garcia-Martin Nokia P.O. Box 407 NOKIA GROUP, FIN 00045 Finland
ミゲルA.ガルシア-マーチンノキア私書箱407Nokia Group、FIN00045フィンランド
EMail: miguel.an.garcia@nokia.com
メール: miguel.an.garcia@nokia.com
Garcia-Martin Informational [Page 35] RFC 4083 3GPP R5 Requirements on SIP May 2005
一口2005年5月に関するガルシア-マーチンの情報[35ページ]のRFC4083 3GPP R5要件
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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 Informational [Page 36]
ガルシア-マーチンInformationalです。[36ページ]
一覧
スポンサーリンク
