Network Working Group M. Garcia-Martin
Request for Comments: 4083 Nokia
Category: Informational May 2005
Input 3rd-Generation Partnership Project (3GPP)
Release 5 Requirements on the Session Initiation Protocol (SIP)
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).
著作権（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）は、3GPP IPマルチメディアコアネットワークサブシステム（IMS）のためのセッション確立プロトコルとしてSIP（Session Initiation Protocol）を選択しています。 IMSは、3GPP仕様のリリース5の一部です。 SIPは、IPネットワークでセッションを確立するための要件のほとんどを満たしたプロトコルですが、SIPは、セルラーネットワークにおける動作のための特定の3GPP要件に照らして評価されていません。この文書では、我々は携帯電話ネットワークでは、3GPP IMSのリリース5のためのSIPをサポートするために3GPPによって特定された要件を表現します。
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
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
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は、[2] IPマルチメディアサブシステム（IMS）内のマルチメディアセッションを確立し、取り壊すするプロトコルとしてSIPを選択しました。 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.
この文書は、3GPP仕様のリリース5のために特に3GPP IMSにおいて、セルラネットワークにおけるSIPプロトコルスイートの使用に適用可能な要件を定義するための努力です。 3GPP仕様のさらなるリリースでは、追加のSIPの要件が含まれていてもよいです。このドキュメントは、3GPPリリース5 IMSのために特定された要件に焦点を当てています。
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は、SIPに、3GPPの要件が含まれています。要件は、カテゴリ別にグループ化されています。いくつかの要件がそれらを満たすことができるであろう可能な解決策の文が含まれています。特定の要件が異なるソリューションによって達成されるかもしれないように、すべてのソリューションは、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によって対処することはできません。
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"、 "MUST NOT"、 "REQUIRED" の用法は、 "NOT SHALL"、 "べきではない" "べきである" "ないものと" "MAY" は、 "推奨"、および「オプションRFC 2119に記載されているように「この文書では、[1]、適用されません。
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サブシステム（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加入者は、自分のホームネットワークに属しています。サービスがトリガされ、ホームネットワーク内で実行することができます。一つ以上のSIPサーバは、IPマルチメディアサブシステムをサポートするために、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.
SIPアウトバウンドプロキシは、ユーザエージェント（UA）をサポートするために提供されます。それは同様に、ホームネットワーク内に位置することができるが、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のための権限ポインタ（NAPTR）とサービス（SRV）レコードをDNSネーミングの形で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サブシステムは、アクセスに依存しないように設計されています。アクセスは、3GPPセルラ端末または3GPPの範囲外の他のアクセスを使用する他の端末から付与されます。
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マルチメディア端末は、IPデータグラムのためのトランスポートネットワークとして既存の汎用パケット無線サービス（GPRS）[27]を使用します。端末は、最初のIPv6プレフィックスを取得するために、GPRSネットワークに接続します。これを行うためには、端末は、GPRS PDPコンテキスト起動手順が続くGPRSアタッチ手順を実行する必要があります。これらのGPRS手順は任意のIPマルチメディアセッションを確立することができる前に完了することが要求されます。
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アドレスを構築しました。 SIPアウトバウンドプロキシがそうであるように、IPv6アドレスは、同じネットワークアドレス空間に属します。まだ同じネットワークアドレス空間に接続しながら、アドレスは携帯端末が移動すると、変更されません。
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アクセスへのGPRSアクセスから端末が移動した場合、上記のGPRS手順は端末にIPv6アドレスを割り当てるために最初から開始する必要があります。
Figure 1 shows an overview of the 3GPP architecture for IM CN Subsystem.
図1は、IM CNサブシステムのための3GPPアーキテクチャの概要を示しています。
+-------------+ +----------------+ +----------------+
| | | | | +------+ |
| | | | | | SIP | |
| | | | | |server| |
| | | | | | +------+ |
+-|+ | | | | | / |
| | | | | +------+ | | +------+ |
| | | | | | SIP | | | | SIP | |
| | ---|-------------|--|----|server|----|---|-|server| |
+--+ | | | +------+ | | +------+ |
| | | | | |
SIP | GPRS access | | Visited Network| | Home Network |
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端子に接続されています。コンピュータは、（SIP、SDP、RTP、等を含む）マルチメディアアプリケーションをホストします。 GPRS端末は、無線アクセスとGPRS接続を処理します。明確化のために、この例では、ホームネットワークは、図に描かれていない、ということに注意してください。
+-------------+ +----------------+
+-------+ | | | | |
| | +-|+ | | | |
| | | | | | | +------+ |
+-------+ | | | | | | SIP | |
/ / --------| | ---|-------------|-------|server|------
/-------/ +--+ | | | +------+ |
| | | |
SIP GPRS | GPRS access | | Visited Network|
client terminal +-------------+ +----------------+
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 /インテリジェント・ネットワークまたはOpenサービス・アーキテクチャ（OSA）などのプロトコルにSIPを相互運用する必要があるかもしれません。
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のための特定の要件を指定していません。しかし、それは特定の要件へのソリューションを開発する際に考慮しなければならない一般的な要件のリストを含んでいます。
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節で関連する要件を参照してください。
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節で関連する要件を参照してください。
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.
端末はかなり小さいデバイス、メモリ要件、消費電力、処理能力、等とすることができるように、最小限に保たれるべきです。端末内に追加のプロトコルのサポートを義務付けることは、この要件を満たす必要があります。
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.
すべての要件は、両方のローミングと非ローミングシナリオのために満たされなければなりません。ローミングと非ローミングのシナリオ間のシグナリング手順に大きな変化があってはなりません。
As terminal mobility is managed by the access network, there is no need to support terminal mobility management in SIP.
ターミナルモビリティがアクセスネットワークによって管理されているように、SIP端末のモビリティ管理をサポートする必要はありません。
3GPP IMS is solely designed to use IP version 6. As a consequence, all protocols must support IPv6 addresses.
3GPP IMSは、単にすべてのプロトコルがIPv6アドレスをサポートしている必要があり、結果として、IPバージョン6を使用するように設計されています。
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アウトバウンドプロキシは、ホームネットワークまたは訪問先ネットワークのいずれかに配置することができます。
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.
RFC 3319 [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アウトバウンドプロキシアドレスを提供することができます。これは、しかし、あまり一般的な機構と考えられています。
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.
レジストラの検索をサポートするために、ホームネットワークは、SIPのNAPTR / SRVレコードをDNSで構成されていてもよい1台の以上のSIPサーバが含まれています。これらは、ホームネットワークのエッジプロキシです。彼らの使命は、ホームネットワーク内の連絡先の最初のポイントとして機能し、特定のユーザに割り当てるレジストラサーバーをSIP（ロケーションサーバの助けを借りて）を決定することです。
The procedures specified in RFC 3263 [10] applied to a REGISTER message seem to be sufficient to meet this requirement.
[10] RFC 3263で指定された手順は、REGISTERメッセージに適用されるが、この要件を満たすのに十分であると思われます。
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.
そのため、3GPPは、モバイルデバイスUAは、任意のセッションを開始する前に登録するモバイル機器UAを義務付けています。
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アウトバウンドプロキシでは、必要に応じて、ソフトの登録状態をインストールすることができます。
Independent of whether the UA is roaming, it is desirable for the registration procedure to be the same.
登録手順は同じであるためにUAがローミングしているかどうかとは無関係に、それが望ましいです。
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.
訪問先ネットワークのドメイン名または文字列のいずれかとして訪問したネットワークアイデンティティを表現するために許容可能です。
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の期限タイマーに登録が要件を満たしていると確信しています。
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が登録解除を通知することができる通知機構のため、または再登録のための要求の必要性を暗示します。
We believe that this requirement is met by the SIP-specific event notification [12] and a registration event package [14].
私たちは、この要件はSIP固有のイベント通知[12]と登録イベントパッケージ[14]によって満たされると信じています。
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配信プロキシの選択につながる別の登録プロセスを開始することができます。
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.
システムは、一貫性のない情報の記憶を回避するために、任意の冗長な登録情報を削除するメカニズムをサポートしなければなりません。加入者が事前登録解除することなく、異なるネットワークにローミングする場合、このケースが発生します。ユーザーが別のアクセスネットワークからローミングするとき、または新しいサービス条件がローミングに課せられている場合は、このケースでは、通常のモビリティ手順で発生します。
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]に基づく手続きがこの要件を満たしていると確信しています。
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.
無線インターフェイスは、希少資源であり、一般的に無線インタフェースを介して利用可能な帯域幅が制限されています。これら二つの要因は、エアインタフェースを介して、おそらく大SIPメッセージの輸送を制限するように見えます。特に、セッションセットアップ時間が原因限られた帯域幅のチャネルを介してSIPメッセージを転送するために必要な時間に延長される可能性があります。
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.
一方、ビアまたはレコードルートのような特定の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.
したがって、効率的にモバイルデバイスUAとSIPアウトバウンドプロキシとの間、およびSIPアウトバウンドプロキシモバイルデバイスUA間のSIPメッセージを圧縮することにより、無線インタフェースを介してパケットをSIPシグナリングを搬送するメカニズムが存在しなければなりません。私たちは、これはSIPに影響を与えていないと信じているが、また要件であるこれらのSIPメッセージを運ぶIPおよびトランスポート層プロトコルヘッダの圧縮に注意してください。
The chosen solution(s) must be able to allow the operation under several different compression algorithms.
選択された溶液（S）は、いくつかの異なる圧縮アルゴリズムの下で操作を許可することができなければなりません。
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.
それらが利用可能になるように選択された溶液（S）は、下位互換性のある方法で、新規かつ改良された圧縮アルゴリズムの組み込みを容易にするために拡張可能でなければなりません。
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プロキシとの間に定義されなければなりません。
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シグナリング圧縮をサポートしなければなりません。圧縮がサポートされていない場合、通信は、訪問先ネットワークのローカルポリシーに応じて、圧縮せずに継続することができます。
The compression mechanism should be reliable and able to recover automatically from errors generated during the decompression.
圧縮機構は、信頼性と解凍の際に発生したエラーから自動的に回復することができるはずです。
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とは独立して進化することができます。
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].
私たちは、この要件は、リソース管理の統合およびSIP [15]によって満たされると信じています。
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に記載された標準的なSDP交渉によって満たされていることを信じている[2]、リソース管理およびSIPの統合で説明したSDPオファー/アンサーモデル[11]と拡張
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].
私たちは、この要件は、リソース管理およびSIP [15]の統合に記載の方法により満たされると信じています。
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].
私たちは、この要件は、メディアの認可[16]のためのプライベートSIP拡張に記載の方法により満たすことができると信じています。
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].
私たちは、この要件は、メディアの認可[16]のためのプライベートSIP拡張に記載の方法により満たされると信じています。
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-Routeヘッダフィールドに関連する手順に従うことができませんでした：後続のリクエストを送信するとき、UAは、最初のトランザクション中にRecord-Routeヘッダを挿入プロキシをバイパスする可能性があります。
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.
プロキシがサービス拒否攻撃を受けるリスクは最小限にすべきです。例えば、悪意のモバイルデバイスは、（Record-Routeヘッダの値で、例えば）SIPプロキシのIPアドレスとポート番号を学習し、そのプロキシ時攻撃を確立することができます。
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を使用するためには、ユーザーは、プライベートユーザIDを割り当てられています。ホームネットワークオペレータは、ネットワークの観点からユーザを一意に識別するために使用されるプライベートユーザIDを割り当てます。プライベートユーザアイデンティティは、例えば、認証、承認、管理、および、おそらく、会計目的のために、使用されています。プライベートユーザアイデンティティは、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].
プライベートユーザアイデンティティは、ホームネットワークオペレータによって定義されたユニークなグローバルIDです。同一性は、RFC 2486で定義されるようにネットワークアクセス識別子（NAI）の形をとる[6]。
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.
プライベートユーザアイデンティティは、永久に（それが動的なアイデンティティではない）がユーザに割り当てられ、ホームネットワークでユーザーのビジネスサブスクリプションの期間中有効です。
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].
プライベートユーザアイデンティティは、モバイルユーザの登録時に認証のための基礎として使用されます。それはRFC 2828で定義されているように、用語認証は同じ意味を持つ本書で使用されている[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.
プライベートユーザアイデンティティを持つREGISTERリクエストのヘッダー値：私たちは、この要件は、認証のユーザ名フィールドを取り込むことによって満たされると信じています。
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つのまたは複数の公開ユーザ識別が割り当てられます。他のユーザーへの通信を要求する際、ユーザーは、パブリックユーザアイデンティティ/アイデンティティを利用します。たとえば、パブリックユーザアイデンティティは、名刺に含まれている場合があります。
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.
別の公開ユーザ識別は、ユーザプロファイルにグループ化することができます。ユーザーが別のプロファイル、異なる公開ユーザ識別を含む各1を有することができます。パブリックユーザアイデンティティは、単一のユーザー・プロファイルの一部にすることができます。
The user may need to register one or more public user identities prior to receiving communications addressed to that public user identity.
利用者は、通信を受信する前には、そのパブリックユーザアイデンティティに宛てた一個の以上のパブリックユーザIDを登録する必要があります。
We believe that this requirement is met by populating the From: and To: header values of a REGISTER message with the public user identity.
パブリックユーザアイデンティティとREGISTERメッセージのヘッダ値：およびTo：私たちは、この要件からの移入によって満たされると信じています。
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.
公開ユーザアイデンティティは、（RFC 3261で定義されている[2]及びRFC 2396 [4]）SIP URIの形をとるか、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で説明したように、この要件は、SIP URLで表されるSIP URLと電話番号を使用して満たされると信じている[3]。また、TEL：RFC 3966 [35]で指定されたURLは、要件を満たすために使用することができます。
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.
グローバルに登録することが可能でなければならない（すなわち、単一のUA要求を介して）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が登録されている場合、レジストラはアクティブ考慮エイリアスIDのリストが含まれていてもよいです。ユーザーは、自身の登録状態に加入することにより、自動的に登録されたパブリックユーザ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.
IMS内の各プライベートユーザIDに関連付けられた公開ユーザ識別のリストがあります。 IMSは、このプライベートユーザ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.
すべてのセッションは、このようなサービス提供、プロキシ、アプリケーションサーバー、および終了UAとして、終端エンティティにダイヤルしたパブリックユーザIDをお届けするためにしたがって、それは可能でなければなりません。
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.
SIP [2]で定義されるように、IMS内のSIPシグナリングのルーティングは、SIP URLを使用しなければなりません。 E.164 [34]の形式の公開ユーザ識別は、IMS内のルーティングのために使用されてはならず、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.
私たちは、この要件は、SIP URIのにE.164番号を変換することによって達成されると信じています。このようENUMなどのデータベースには、[9]、仕事をするかもしれません。
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.
このセクションに含ま要件はオプションではありませんが、隠し機能が設定を通して使用するオプションです。これは、ネットワークオペレータは、自分の欲望で、オンまたはオフに隠れ機能を切り替えることができます。
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、ルート、または他のヘッダーの）別のネットワークに内部ネットワーク構造を明らかにするために必要とされる必要はありませんまたはネットワークの容量。
A network need not be required to expose the explicit IP addresses of the nodes within the network (excluding firewalls and border gateways).
ネットワークは、（ファイアウォールやボーダーゲートウェイを除く）は、ネットワーク内のノードの明示的なIPアドレスを公開するために必要とする必要はありません。
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シグナリングパスに含まれていてもよいです。この追加のプロキシは、他のネットワークからのネットワークの内部構造を保護するために使用することができます。
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).
緊急コールは、IMSで処理されたときに、3GPP UAは、IMS（セルID）にアクセスして、それを通してセルのアイデンティティは、（緊急呼の間に端末の位置に局在サービスまたは情報を提供するために、ホーム・ネットワークによって使用されてもよいです;）また、セクション4.16に記載された要件を参照してください。
4.13.1. Cell-ID in Signaling from the UA to the Visited and Home Networks
4.13.1. UAからの訪問やホームネットワークへのシグナリングにおける細胞-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:
セルIDは、SIPの範囲外の他のメカニズムによってUAによって得られると仮定すると、セルIDは、少なくとも以下の手順で輸送されなければなりません。
o Registration o Session Establishment (Mobile Originated) o Session Establishment (Mobile Terminated) o Session Release
セッションのリリースOセッション確立Oセッション確立〇〇登録（モバイル起源）（モバイルは終了）
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.
セルIDは、個人情報やUAのホームネットワークへの関心の唯一のです。そのため、セルIDは、元のホームネットワークを超えてSIPシグナリングを送信する前に除去しなければなりません。
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]に記載のいずれかの形式で送信されなければなりません。
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エンティティ作用によって満たされると信じています。
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.
無様なセッション終了が発生した場合（例えば、フラットバッテリーやモバイルカバレッジを離れる）、（例えばSIP自宅でプロキシを提供するなど）、コールステートフルSIPプロキシサーバがセッションに関与しているとき、メモリリークと、最終的には、サーバの障害原因ぶら下げステートマシンに発生する可能性があります。安定したサーバー運用とキャリアグレードのサービスを確保するために、無様なセッション終了の問題を処理するためのメカニズムが提供されなければなりません。私たちは、無様なセッション終了のため、SIPへの外部機構により、SIPアウトバウンドプロキシが通知されるメカニズムがあることを前提としています。これは、ネットワークによって順序付け優雅なセッション解放に無様なセッションリリース（次のセクションを参照）を形質転換することができます。このBYEを認証することはできないが、例えば、移動無線カバレージの喪失の通知を受信すると、SIPアウトバウンドプロキシは、端末の代わりにBYE要求を送ることができます。
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.
UAがこの要求に従わない場合がありますので、このリリースでは、解放要求（BYE）を送信するために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プロトコルレベルでなければなりません。
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.
アウトバウンドプロキシが提供するサービスは、携帯端末に配信できるように、すべてのモバイル端末は、セッションセットアップ試行しなければならないトランジットアウトバウンドプロキシを発しました。
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サービスをトリガすることができるようにすべてのモバイル端末は、トランジットホームネットワークにおけるサービス提供のプロキシをしなければならないセッションセットアップ試行を開始しました。これは、これらのプロキシが正しく遷移していることを確認するために、ソース・ルーティング・メカニズムのいくつかの並べ替えのための要件を意味します。
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要求によって撮影されたパスは、リクエストを登録する発信移動体端末で撮影した特定の経路に限定する必要はありません。例えば、INVITEは、任意の他のプロキシを経由せずに、単にSIPアウトバウンドプロキシ及びSIPなるプロキシを横断することができます。しかし、INVITEによって取られる経路は、REGISTERによって取ら同じ経路を辿ることができます。
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プロキシです。
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.15.4ソースルーティングメカニズムは、セッションセットアップ時に必要な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で表され、隠蔽要件もプロキシの言っセットに適用されます。
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ネットワークはすでに緊急セッションを提供するための代替手順が含まれています。 SIP緊急セッションのいずれかの要件を追加しません3GPP仕様のリリース5。
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].
私たちは、この要件は、RFC 3325 [17]に記載の方法により満たされると信じています。
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].
我々は、この要件は、RFC 3323 [18]に記載の手順によって満たされると信じています。
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.
規制機関だけでなく、加入者は、自分の発信者IDの表示をブロックするために発信者の能力を必要とするかもしれません。先の加入者のSIPサービス提供プロキシは、この機能を実行することができます。このように、宛先加入者は、まだセッション・リターン、セッショントレース、転送、または任意の他の付加サービスを行うことができます。
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].
我々は、この要件は、RFC 3323 [18]に記載の手順によって満たされると信じています。
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].
我々は、この要件は、RFC 3323 [18]およびRFC 3325 [17]に記載の手順によって満たされると信じています。
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).
呼び出し側は、セッションが匿名であることを要求した場合、ユーザエージェントクライアント（UAC）は、ユーザエージェントサーバ（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.
呼び出し側は、セッションが匿名であることを要求した場合、終端ネットワークは、宛先エンドポイントにルーティング情報を任意のアイデンティティやシグナリングを明らかにしてはなりません。終端ネットワークは、少なくとも二つのケースを区別する必要があります：最初、呼び出し側が匿名でするセッション、および第二の意図したかどうか、呼び出し元のIDは、トランジットネットワークによって削除されたかどうか。
We believe that this requirement is met by the procedures described in RFC 3323 [18] and RFC 3325 [17].
我々は、この要件は、RFC 3323 [18]およびRFC 3325 [17]に記載の手順によって満たされると信じています。
The 3GPP charging implications are described in the 3GPP Technical Specification 32.225 [31].
3GPP充電意味は、3GPP技術仕様32.225 [31]に記載されています。
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シグナリングと対話します。
Offline charging is the process whereby charging information does not affect, in real-time, the service rendered to the user.
課金情報は影響しません。これにより、オフライン充電はリアルタイムで、サービスがユーザにレンダリング、プロセスです。
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ネットワークに渡されたバインディング情報で使用されているものと同じです。
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セッションのための課金情報を相関は識別子（ICID）を充電IMSの使用に基づいています。
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を充電関数のアドレスは、セッションシグナリングパス内のすべてのIMSネットワークエンティティに配信SIPプロキシによって渡されます。これは、同じ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との間の充電相関のため、セッションのPDPコンテキストを識別するIDを、充電一つ以上のGPRSは、IMSにGPRSネットワークから渡されます。
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 IDを充電GPRSを提供するSIPプロキシおよびSIPシグナリングを使用してアプリケーション・サーバーへのアウトバウンドSIPプロキシによって渡されます。彼らは別のホーム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インターオペレータ識別子（IOI）は、発信者のホームIMSおよびホーム起点と家庭の終端ネットワークの識別子を提供するために、呼び出し先のホームIMSの間で共有されています。
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サーバは、課金サブシステムに提供するために、セッションの継続時間、送信元、宛先など、すべてのセッションの詳細をログに記録することができなければなりません。
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.
3GPPに適用し、そのようなSIP呼制御に記載されているものなどの追加のサービスを使用することに興味があります - 、SIPの基本的なコールフロー例[21] [20]を転送し、SIP公衆交換電話網（PSTN）コール[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法[24]とReplacesヘッダー[25] REFER上記の要件を満たすために、イネーブラとして使用する補体を構成すると考えています。
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.
私たちは、RFC 2833で指定されたメカニズムは、[8] SIPに影響を与えることなく、要件を満たしていることを信じています。
As mobile terminals will frequently interoperate with the PSTN, support for early media is required.
モバイル端末が頻繁にPSTNと相互運用するように、初期メディアのサポートが必要です。
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で使用されています。 RFC 3264で説明したようにSIPは、当事者の一方が彼のセッション記述と提供する他の答えを提供している中で、[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容量このように、機構は、セッション記述交渉は、メディアストリームあたり多くのコーデックのうちの一つと結論付けることができることにより、必要とされます。 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の両方が、メディア・ストリームごとに使用されるコーデックの数をネゴシエートし、ダウントリムする能力を有することにより、必要とされます。
We believe that the mechanism specified in RFC 3264 [11] meets the requirement.
私たちは、RFC 3264 [11]で指定されたメカニズムが要件を満たしていることを信じています。
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アウトバウンドプロキシがセッション確立の試行を拒否することができるメカニズムが存在しなければなりません。
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プロキシサービスを提供する機構が存在しなければならないことは、セッションが禁止メディアタイプを含むセッション確立の試行を拒否することができます。
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.
認証期間の持続時間は、これらの不要な認証を避けるために、比較的高い値に設定されている場合は、リスクが一部のユーザーは認証の間に高い費用が発生する可能性があること、その後です。
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.
ネットワークは、いつでも再認証プロセスを開始するため、結果として、それが可能でなければなりません。トリガは、ネットワーク内に設定されなければならない等充電閾値、イベントの数、セッションの時間を含むことができます
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仕様のリリース5バージョンでは考慮されていません。
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.
IMSリソースの使用が許可される前に、SIP UAは、自分のホームネットワークに認証しなければなりません。 3GPP IMS仕様のリリース5では、認証、登録、再登録の際に行われます。
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を見ると、私たちは、必要なセキュリティが一意である二つの異なるゾーンを区別することができます。
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 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.
アクセスドメインに必要な特性があるため、モビリティ、計算制限、バッテリーの制限、帯域幅の節約、および無線インターフェイスのための端末の要件のネットワークドメインのものとは全く異なっています。アクセスドメインのSIPエンティティは、並行して、ユーザーの大規模なグループでのセキュリティコンテキストを維持することができるはずです。ネットワークドメインは、ネットワークノード間のセキュリティアソシエーションを提供する一方でまた、アクセスドメインは、ユーザ固有のセキュリティアソシエーションを提供します。そのため、プロトコルとアルゴリズムと圧縮機構の遵守の重量は、アクセスドメインセキュリティにとって非常に重要です。したがって、セキュリティソリューションは、これら2つのドメインの異なるメカニズムを許可することが必要とされます。
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は、安全な方法で処理されなければならないすべては、最大億ユーザーの大きな加入者ベースを特徴とします。
The security solutions must allow global roaming among a large number of administrative domains.
セキュリティソリューションは、管理ドメインの多数の間でグローバルローミングを許可する必要があります。
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端末を伴うすべてのセキュリティ・メカニズムは、必要に応じて追加のラウンドトリップの数を最小限に抑える必要があります。具体的には、シグナリング・通常の通話中に任意の追加のセキュリティ関連のメッセージがあってはなりません。
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）は、例えば公開鍵暗号方式、ディフィー・ヘルマンの実装を必要とします。これら下層メカニズムが使用された場合、移動端末は、対称的な方法を使用して、訪問先ネットワークとのセッションキーを認証して交渉することになります。
The selected security mechanism should work with any transport protocol allowed by SIP (e.g., TCP, UDP).
選択されたセキュリティメカニズムは、SIP（例えば、TCP、UDP）によって許容される任意のトランスポートプロトコルで動作する必要があります。
Authentication, as used in this context, means entity authentication that enables two entities to verify the identity of the respective peer.
認証は、この文脈で使用されるように、それぞれのピアのアイデンティティを確認するために2つのエンティティを可能エンティティ認証を意味します。
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に記載されています。
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では、これらの保護モードは、初期認証に基づいていなければなりません。完全性保護と機密性は、対称暗号化キーを使用して可能でなければなりません。
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エンティティ間のこのような保護を提供することが可能でなければなりません。将来のネットワークのシナリオでは、また、3GPPリリース5 IMSがこれを必要としませんが、プロキシを通してこの保護を提供する必要があるかもしれません。
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に適用される場合は、メッセージ保護と互換性がなければなりません。
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にしっかりセッションキーを委任することができなければなりません。
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.
交渉メカニズムは、認証資格情報へのアクセスを持っていない攻撃者から保護しなければなりません。特に、交渉メカニズムは、弱いセキュリティとまたはなしでサービスが交渉されるように、交渉結果に影響を与える可能性が可能なman-in-the-middle攻撃を検出することができなければなりません。
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セッションを保護するために同じセキュリティモードパラメータを使用することができなければなりません。例えば、セキュリティ・モード・パラメータは、登録の有効期間内で有効であると仮定することができます。いくつかのINVITEの上にセキュリティアソシエーションの設定とパラメータの交渉のコストを償却する必要があることに注意してください。
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アウトバウンドプロキシは、メッセージの発信元を保証するとメッセージが（例えば、完全性保護されている）に変更されていないことを確認することができなければなりません。
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.
サービングSIPプロキシは、アウトバウンドプロキシは、それが完全性が保護されたか否か、REGISTERリクエストの場合には、メッセージの発信元を確認し、することができた場合に通知を受信する必要があります。
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は、オペレータ自身のネットワーク内の少なくとも二つのオペレータ間の必須の上述の保護、およびオプションを有する作ることを意図しています。セキュリティゲートウェイは、オペレータのネットワークの間に存在します。
We believe that the above requirements are fulfilled by applying security mechanisms as specified in the current IP Security standards in RFC 2401 [5].
私たちは、上記の要件は、[5] RFC 2401で、現在のIPセキュリティ規格で指定されたセキュリティメカニズムを適用することで満たされていることを信じています。
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の下で議論されています。
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）、スニルChotai（mmO2）、キース・糖剤（ルーセント）、 Jayshree Bharatia（ノーテル）、Kevan Hobbis（Huthison 3G UK）、ディーン・ウィリス（dynamicsoft）、Krisztianキス（ノキア）、のVesa Torvinen（エリクソン）、ヤリArkko（エリクソン）、およびソニアGarapaty（ノーテル）。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[3]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[4] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[4]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、RFC 2396、1998年8月。
[5] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[5]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[6] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[6] Aboba、B.及びM. Beadles、 "ネットワークアクセス識別子"、RFC 2486、1999年1月。
[7] Shirey, R., "Internet Security Glossary", RFC 2828, May 2000.
[7] Shirey、R.、 "インターネットセキュリティ用語集"、RFC 2828、2000年5月。
[8] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[8] Schulzrinneと、H.とS. 2000 Petrackとし、 "DTMFケタ、電話トーン、および電話信号のためのRTPペイロード"、RFC 2833、2000年5月。
[9] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
[9] Faltstrom、P.、 "E.164番号とDNS"、RFC 2916、2000年9月。
[10] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[10]ローゼンバーグ、J.、およびH. Schulzrinneと、 "セッション開始プロトコル（SIP）：SIPサーバの検索"、RFC 3263、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と、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[12] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[12]ローチ、A.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、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.
[13]ニエミ、A.、Arkko、J.、およびV. Torvinen、RFC 3310、2002年9月 "認証および鍵合意（AKA）を使用してハイパーテキスト転送プロトコル（HTTP）ダイジェスト認証"。
[14] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004.
[14]ローゼンバーグ、J.、 "Aセッション開始プロトコル（SIP）登録のためのイベントパッケージ"、RFC 3680、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.ローゼンバーグ、RFC 3312、2002年10月 "資源管理とセッション開始プロトコル（SIP）の統合"。
[16] Marshall, W., "Private Session Initiation Protocol (SIP) Extensions for Media Authorization", RFC 3313, January 2003.
[16]マーシャル、W.、 "メディア認証のためのプライベート・セッション開始プロトコル（SIP）の拡張"、RFC 3313、2003年1月。
[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.ワトソン、 "信頼できるネットワーク内のアサート・アイデンティティのためのセッション開始プロトコル（SIP）のプライベート拡張"、RFC 3325、2002年11月。
[18] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[18]ピーターソン、J.、RFC 3323、2002年11月 "セッション開始プロトコル（SIP）のためのプライバシーメカニズム"。
[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.フォルツ、RFC 3319、2003年7月 "セッション開始プロトコル（SIP）サーバーの動的ホスト構成プロトコル（DHCPv6）オプション"。
[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.サマーズ、 "セッション開始プロトコル（SIP）の基本的なコールフローの例"、BCP 75、RFC 3665、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.サマーズ、 "セッション開始プロトコル（SIP）、公衆交換電話網（PSTN）コールフロースイッチ" RFC、BCP 76 3666、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.、 "セッション開始プロトコル（SIP）メソッドを参照してください"、RFC 3515、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.ディーン、 "ザ・セッション開始プロトコル（SIP） 'はReplaces' ヘッダー"、RFC 3891、2004年9月。
[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、 "TS 23.003番号、アドレス指定および識別（リリース5）"、2002年9月、<ftp://ftp.3gpp.org/Specs/archive/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、 "TS 23.060：汎用パケット無線サービス（GRPS）;サービスの説明;ステージ2"、2002年9月、<ftp://ftp.3gpp.org/Specs/archive/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、 "TS 23.228：IPマルチメディアサブシステム（IMS）（ステージ2） - リリース5"、2002年9月、<ftp://ftp.3gpp.org/Specs/archive/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、 "TS 24.228：SIPとSDPに基づくIPマルチメディア呼制御のためのシグナリングフロー"、2002年9月、<ftp://ftp.3gpp.org/Specs/archive/24_series/24.228/>。
[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、 "TS 24.229：IPマルチメディアサブシステム（IMS）（ステージ3） - リリース5"、2002年9月、<ftp://ftp.3gpp.org/Specs/archive/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、 "TS 32.225：電気通信管理、課金管理を、IPマルチメディア・サブシステムのデータ記述を充電;（リリース5）"、2002年9月、<ftp://ftp.3gpp.org/Specs/archive/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、 "TS 32.203：3Gセキュリティ; IPベースのサービスのためのAccessのセキュリティ;（リリース5）"、2002年9月、<ftp://ftp.3gpp.org/Specs/archive/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、 "TS 32.210：3Gセキュリティ;ネットワークドメインセキュリティ、IPネットワーク層セキュリティ（リリース5）"、2002年9月、<ftp://ftp.3gpp.org/Specs/archive/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と、H.、 "電話番号については、TEL URI"、RFC 3966、2004年12月。
Author's Address
著者のアドレス
Miguel A. Garcia-Martin Nokia P.O. Box 407 NOKIA GROUP, FIN 00045 Finland
みぐえｌ あ。 がｒしあーまｒちん のきあ Ｐ。お。 ぼｘ ４０７ のきあ ＧろうＰ、 ふぃん ０００４５ ふぃんぁんｄ
EMail: miguel.an.garcia@nokia.com
メールアドレス：miguel.an.garcia@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。