[要約] 要約：RFC 4083は、3GPPリリース5の要件に関するSIPの入力を提供します。 目的：3GPPネットワークでのSIPの使用に関する要件を明確にし、相互運用性を向上させるためのガイドラインを提供します。
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)
入力第3世代パートナーシッププロジェクト（3GPP）セッション開始プロトコル（SIP）に5リリース5要件
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
第3世代パートナーシッププロジェクト（3GPP）は、3GPP IPマルチメディアコアネットワークサブシステム（IMS）のセッション確立プロトコルとしてセッション開始プロトコル（SIP）を選択しました。IMSは、3GPP仕様のリリース5の一部です。SIPは、IPネットワークでセッションを確立するためのほとんどの要件を満たすプロトコルですが、SIPはセルラーネットワークでの動作の特定の3GPP要件に対して評価されたことはありません。このドキュメントでは、3GPPで特定された要件を表明し、セルラーネットワークの3GPPIMSのリリース5のSIPをサポートします。
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は、IPマルチメディアサブシステム（IMS）でマルチメディアセッションを確立および取り壊すためのプロトコルとしてSIP [2]を選択しました。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.
このドキュメントでは、いかなる種類のプロトコルも指定していません。したがって、キーワードの使用は、「必須」、「必須」、「必須」、「「shall」、「shill "、" sulld "、" buld "、" becommended "、" may "、" optional）の使用「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）の概要を読者に提供します。それは包括的であることを意図したものではありませんが、3GPPIMSの基礎を理解するのに十分な情報を提供します。読者は、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サブスクライバーは、彼または彼女のホームネットワークに属します。サービスはトリガーされ、ホームネットワークで実行される場合があります。IPマルチメディアサブシステムをサポートするために、SIPホームネットワークに1つ以上の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.
ユーザーエージェント（UA）をサポートするために、SIPアウトバウンドプロキシが提供されます。SIPアウトバウンドプロキシは通常、訪問されたネットワークにありますが、ホームネットワークにも配置される場合があります。SIPアウトバウンドプロキシは、それ自体と端末との間のセキュリティ関連、およびパケットネットワーク内のリソース管理とのインターワークを維持しています。
The SIP outbound proxy is assigned after the mobile device has connected to the access network. Once this proxy is assigned, it does not change while the mobile remains connected to the access network. Thus the mobile can move freely within the access network without SIP outbound proxy reassignment.
SIPアウトバウンドプロキシは、モバイルデバイスがアクセスネットワークに接続された後に割り当てられます。このプロキシが割り当てられると、モバイルがアクセスネットワークに接続されたままになっている間は、変更されません。したがって、モバイルは、SIPアウトバウンドプロキシの再割り当てなしで、アクセスネットワーク内で自由に移動できます。
The home network may also support one or more SIP edge proxies. These nodes may act as the first entry points for SIP signaling to the home network and may determine (with the help of location servers) which SIP registrar server to assign to a particular user. Typically the address of the home network SIP edge proxy is configured in DNS in the form of a DNS Naming Authority Pointer (NAPTR) and Service (SRV) records for SIP.
ホームネットワークは、1つ以上のSIPエッジプロキシをサポートする場合があります。これらのノードは、ホームネットワークへのSIP信号の最初のエントリポイントとして機能し、特定のユーザーに割り当てるレジストラサーバーをSIPする（ロケーションサーバーの助けを借りて）決定する場合があります。通常、Home Network SIP Edgeプロキシのアドレスは、SIP用のDNSネーミングオーソリティポインター（NAPTR）およびService（SRV）レコードの形式でDNSで構成されます。
Additionally, home and visited networks may deploy, if required, a SIP-hiding proxy. The main purpose of the SIP-hiding proxy is to hide the network configuration.
さらに、ホームおよび訪問したネットワークは、必要に応じて、SIPハイディングプロキシを展開する場合があります。SIPハイディングプロキシの主な目的は、ネットワーク構成を非表示にすることです。
The 3GPP IM CN Subsystem is designed to be access independent. Access is granted from 3GPP cellular terminals or from other terminals that use other accesses out of the scope of 3GPP.
3GPP IM CNサブシステムは、独立にアクセスできるように設計されています。アクセスは、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]を使用します。端子は最初にGPRSネットワークに接続して、IPv6プレフィックスを取得します。これを行うには、端子はGPRSアタッチプロシージャを実行し、その後GPRS PDPコンテキストアクティベーション手順を実行する必要があります。これらの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アドレスを構築しました。IPv6アドレスは、SIPアウトバウンドプロキシと同じネットワークアドレス空間に属します。モバイル端子は同じネットワークアドレス空間に接続されている間に移動するため、アドレスは変更されません。
If the terminal moves from a GPRS access to another GPRS access, the above-mentioned GPRS procedures needs to start from the beginning to allocate an IPv6 address to the terminal.
端子がGPRSアクセスから別の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/Intelligent-NetworkやOpen Services Architecture（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は、IPバージョン6を使用するように設計されています。結果として、すべてのプロトコルはIPv6アドレスをサポートする必要があります。
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.
RFC 3263 [10]で指定された手順は、登録メッセージに適用された手順では、この要件を満たすのに十分であると思われます。
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.
レジストラに宛てられた単一のレジスタメッセージは、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.
ホームネットワークは、家庭と訪問されたネットワーク間のローミング契約の存在を検証できる必要があります。ホームネットワークは、ユーザーがそのような訪問されたネットワークへのローミングを許可されていることを検証する必要があります。したがって、訪問されたネットワークIDがホームネットワークでの登録時に知られるメカニズムが必要です。
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.
無線インターフェイスは希少なリソースであり、通常、無線インターフェイス上で利用可能な帯域幅は制限されています。これらの2つの要因は、エアインターフェイス上の大きな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.
一方、ViaやRecord-routeなどの特定の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メッセージを運ぶIPおよびトランスポート層プロトコルヘッダーの圧縮も要件であることに注意してください。ただし、これはSIPに影響を与えないと考えています。
The chosen solution(s) must be able to allow the operation under several different compression algorithms.
選択したソリューションは、いくつかの異なる圧縮アルゴリズムの下で操作を許可できる必要があります。
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.
選択されたソリューションは、利用可能になるにつれて、下向きの互換性のある方法で新しい改良された圧縮アルゴリズムの組み込みを促進するために拡張可能でなければなりません。
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 [2]、SDPオファー/回答モデル[11]、およびリソース管理とSIPの統合で説明されている拡張に記載されている標準的なSDP交渉によって満たされると考えています。
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].
この要件は、メディア許可のためのプライベートSIP拡張に記載されている手順によって満たされる可能性があると考えています[16]。
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].
この要件は、メディア許可のためのプライベートSIP拡張機能に記載されている手順によって満たされると考えています[16]。
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は、レコードルートヘッダーフィールドに関連する手順に従うことができませんでした。後続の要求を送信すると、UAは最初のトランザクション中にレコードルートヘッダーを挿入するプロキシをバイパスできます。
The risk that a proxy will receive a denial of service attack should be minimized. For instance, a malicious mobile device could learn a SIP proxy IP address and port number (e.g., in a Record-Route header value) and establish an attack upon that proxy.
プロキシがサービス拒否攻撃を受けるリスクを最小限に抑える必要があります。たとえば、悪意のあるモバイルデバイスは、SIPプロキシIPアドレスとポート番号（たとえば、記録的なヘッダー値）を学習し、そのプロキシへの攻撃を確立することができます。
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.
3GPPIMSを使用するために、ユーザーにプライベートユーザーIDが割り当てられます。ホームネットワークオペレーターは、ネットワークの観点からユーザーを一意に識別するために使用されるプライベートユーザーIDを割り当てます。プライベートユーザーの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は、ホームネットワークオペレーターによって定義された一意のグローバルアイデンティティです。IDは、RFC 2486 [6]で定義されているように、ネットワークアクセス識別子（NAI）の形式を取得します。
The end user does not have access to the private user identity. Typically the identity is stored in a Subscriber Identity Module card.
エンドユーザーは、プライベートユーザーのIDにアクセスできません。通常、IDはサブスクライバーIDモジュールカードに保存されます。
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アウトバウンドプロキシとレジストラにプライベートユーザーのIDを配信する必要があります。
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].
プライベートユーザーのIDは、モバイルユーザーの登録中の認証の基礎として使用されます。認証という用語は、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.
この要件は、承認のユーザー名フィールド、つまりレジスタリクエストのヘッダー値をプライベートユーザーIDとの承認によって満たすことによって満たされると考えています。
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.
3GPPIMSを使用するために、ユーザーに1つ以上のパブリックユーザーIDが割り当てられます。ユーザーは、他のユーザーへの通信を要求するときに、パブリックユーザーのID/ IDを使用します。たとえば、パブリックユーザーのIDは名刺に含まれる場合があります。
Different public user identities may be grouped into a user profile. A user may have different profiles, each one containing different public user identities. A public user identity can be part of a single user profile.
さまざまなパブリックユーザーのアイデンティティをユーザープロファイルにグループ化できます。ユーザーには異なるプロファイルがあり、それぞれが異なるパブリックユーザーのアイデンティティを含む場合があります。パブリックユーザーのアイデンティティは、単一のユーザープロファイルの一部にすることができます。
The user may need to register one or more public user identities prior to receiving communications addressed to that public user identity.
ユーザーは、そのパブリックユーザーIDに宛てられた通信を受信する前に、1つ以上のパブリックユーザー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.
この要件は、from：and：to：registerメッセージのヘッダー値をパブリックユーザーのIDに入力することによって満たされると考えています。
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.
パブリックユーザーのIDは、SIP URI（RFC 3261 [2]およびRFC 2396 [4]で定義されている）またはE.164 [34]の形式を取得する必要があります。
We believe that this requirement is met by using SIP URLs and telephone numbers represented in SIP URLs as described in SIP [3]. In addition, tel: URLs as specified in RFC 3966 [35] can be used to fulfill the requirement.
SIP URLとSIP URLで表されるSIP [3]で表される電話番号を使用することにより、この要件は満たされると考えています[3]。さらに、RFC 3966 [35]で指定されているTel：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.
IMS内のメカニズムを介して、同じユーザープロファイルに属する複数のパブリックアイデンティティを持つユーザーをグローバルに（つまり、1つのUAリクエストを介して）登録することが可能である必要があります。この場合、ユーザーはユーザープロファイルに関連付けられたすべての公開アイデンティティに登録されます。
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.
パブリックユーザーのアイデンティティは、3GPPIMSによって認証されません。ただし、ネットワークは、パブリックユーザーのアイデンティティが登録されたプライベートユーザーIDに関連付けられていることを承認しています。
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に関連付けられたパブリックユーザー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のいずれかに配置できます。終了ネットワークのサービングプロキシおよびアプリケーションサーバーは、リクエスト-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.
IMS内のSIP信号のルーティングは、SIPで定義されているSIP URLを使用する必要があります[2]。E.164 [34]フォーマットパブリックユーザーIDは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.
この要件は、E.164の数値をSIP URIに翻訳することで達成されると考えています。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プロキシの機能、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).
3GPP UAがIMS（Cell-ID）にアクセスしているセルの身元をホームネットワークで使用して、緊急コール中にターミナルの場所に関するローカライズされたサービスまたは情報を提供することができます（IMSで緊急コールが処理された場合;セクション4.16に記載されている要件も参照してください。
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:
SIPの範囲外の他のメカニズムによってCell-IDがUAによって取得されると仮定すると、少なくとも次の手順でCell-IDを輸送する必要があります。
o Registration o Session Establishment (Mobile Originated) o Session Establishment (Mobile Terminated) o Session Release
o 登録oセッション設立（モバイル起源）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.
Cell-IDは個人情報であり、UA Home Networkに関心のあるものです。したがって、SIP信号を発信するホームネットワークを超えて送信する前に、Cell-IDを削除する必要があります。
The cell-ID must be sent in any of the formats described in the 3GPP Technical Specification 23.003 [26].
Cell-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.
不名誉なセッション終了が発生した場合（たとえば、フラットバッテリーやモバイルの葉のカバレッジなど）、Stateful SIPプロキシサーバー（自宅でのSIPサービスプロキシなど）がセッション、メモリリーク、そして最終的にはサーバーの障害に関与している場合状態マシンの吊り下げのために発生する可能性があります。安定したサーバーの操作とキャリアグレードのサービスを確保するには、不名誉なセッション終了問題を処理するメカニズムを提供する必要があります。SIPアウトバウンドプロキシに、SIPの外部のメカニズムによって、不名誉なセッション終了のメカニズムが通知されるメカニズムがあると仮定します。これにより、不grace的なセッションリリースをネットワークが注文した優雅なセッションリリースに変換することができます（次のセクションを参照）。たとえば、モバイル無線のカバレッジの喪失の通知を受信すると、SIPアウトバウンドプロキシはターミナルに代わってByeリクエストを送信できますが、この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 関連するネットワークリソースをリリースします：BEARERリソースとシグナリングリソース。
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.
Home Networkでの配信プロキシにより、通常、アプリケーションサーバーで実行されるユーザー顧客サービスのトリガーが可能になります。
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.
招待リクエストによって行われるパスは、モバイル端末起源のレジスタリクエストによって取られた特定のパスに制限される必要はありません。たとえば、招待は、他のプロキシを通過することなく、SIPアウトバウンドプロキシとSIPサービングプロキシだけを横断することができます。ただし、招待者がとるパスは、レジスタが取った同じパスをたどることができます。
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.
招待状が通過する必要があるプロキシのソースルーティングセットを追加するノードを動的に通知する手段がなければなりません（たとえば、アウトバウンドプロキシまたはプロキシの提供）。
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ネットワークには、緊急セッションを提供するための代替手順が既に含まれています。3GPP仕様のリリース5では、SIP緊急セッションの要件は追加されません。
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.
規制機関と加入者は、発信者が発信者の識別の表示をブロックする能力を要求する場合があります。宛先サブスクライバーのSIPサービングプロキシは、この機能を実行できます。このようにして、宛先サブスクライバーは、セッションリターン、セッショントレース、転送、またはその他の補足サービスを実行することができます。
Therefore, it must be possible that the caller request to block the display of his/her identity on the callee's display.
したがって、発信者がCalleeのディスプレイ上のアイデンティティの表示をブロックするように要求する可能性がある必要があります。
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または信号ルーティング情報を表示してはなりません。終了ネットワークは、少なくとも2つのケースを区別する必要があります。1つ目は、発信者がセッションを匿名であることを意図したかどうか、次に、発信者の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セッションの充電情報の相関は、IMS充電識別子（ICID）の使用に基づいています。
o The first IMS network entity within the SIP signaling path is responsible for assigning an ICID. This ICID will then be passed along the whole session path in an end-to-end manner. However, this will not preclude further elements (other SIP proxies) along the session path from generating additional identifiers to be passed along.
o SIPシグナリングパス内の最初のIMSネットワークエンティティは、ICIDの割り当てを担当します。このICIDは、エンドツーエンドの方法でセッションパス全体に沿って渡されます。ただし、これは、セッションパスに沿って追加の要素（他のSIPプロキシ）を、追加の識別子を生成することを妨げるものではありません。
o The ICID is passed to all IMS network entities in the session signaling path. This is performed using SIP signaling.
o ICIDは、セッションシグナリングパスのすべてのIMSネットワークエンティティに渡されます。これは、SIPシグナル伝達を使用して実行されます。
o The addresses of the charging functions are passed by the serving SIP proxy to all IMS network entities in the session signaling path. This is to provide a common destination for all the charging records generated by each IMS network entity with the same ICID.
o 充電関数のアドレスは、セッションシグナリングパス内のすべての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コンテキストを識別する1つ以上のGPRS充電IDがGPRSネットワークからIMSに渡されます。
o The GPRS Charging IDs are passed by the outbound SIP proxy to the serving SIP proxy and the Application Servers using SIP signaling. They are not transferred from one home IMS (e.g., caller's home) to another (e.g., callee's home).
o GPRS充電IDは、SIPシグナリングを使用して、サービングSIPプロキシとアプリケーションサーバーにアウトバウンドSIPプロキシによって渡されます。彼らは、ある家のIM（例えば、発信者の家）から別の家（例えば、Calleeの家）に移されません。
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とCalleeの自宅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コールコントロール[20]、SIP Basic Call Flowの例[21]、SIP Public Switched Telephone Network（PSTN）Call Flows [22]、SIPサービスなど、SIPコールコントロール[20]、SIP Basic Call Flowの例[21]、および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]と交換ヘッダー[25]は、上記の要件を満たすためにイネーブラーとして使用する補完を構成すると考えています。
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にある可能性のあるモバイル端子からターゲットシステムへのDTMFトーンの輸送、またはSIPベースのソリューション（つまり、PSTN接続なし）をサポートする必要があります。
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で使用され、セッションを確立するために必要なメディアストリームとコーデックを説明します。SIPは、RFC 3264 [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容量などに制限がある場合があります。そのため、メディアストリームごとの多くのコーデックの1つでセッションの説明交渉が終了するメカニズムが必要です。UACとUASの両方が、メディアが送信または受信される前に、各メディアストリームに使用されるコーデックを知っている必要があります。
In the 3GPP IMS, efficient use of the network and radio resources is an important requirement. As such, the network should know in advance which codec is used for a particular media stream. The network access control may use this information to grant access to the network and to control the resource utilization.
3GPP IMSでは、ネットワークと無線リソースの効率的な使用が重要な要件です。そのため、ネットワークは、特定のメディアストリームに使用されるコーデックを事前に知る必要があります。ネットワークアクセス制御は、この情報を使用して、ネットワークへのアクセスを許可し、リソース利用を制御する場合があります。
Additionally, it is required that the party who pays for the resource utilization have the opportunity to decide which codecs to use, once both end parties are aware of the capabilities supported at the remote UA.
さらに、リソースの利用を支払う当事者は、両方のエンドパーティがリモートUAでサポートされている機能を認識したら、どのコーデックを使用するかを決定する機会があることが必要です。
Therefore, a mechanism is required by which both UAC and UAS have the ability to negotiate and trim down the number of codecs used per media stream, so that at the end of the negotiation there can be a reduced set of agreed codecs per media stream.
したがって、UACとUASの両方がメディアストリームごとに使用されるコーデックの数を交渉してトリミングする能力を持つメカニズムが必要であるため、交渉の終わりにメディアストリームごとに合意されたコーデックのセットが削減される可能性があります。
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.
特定のユーザーのサブスクリプションには、特定のメディアタイプの制限が含まれる場合があります。たとえば、ユーザーはビデオセッションを確立することを許可されない場合があります。Home Networkでの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.
セッションの確立がHome Networkで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は、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.
SIP UAは、IMSリソースの使用が許可される前に、ホームネットワークに認証する必要があります。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を見ると、必要なセキュリティが一意である2つの異なるゾーンを区別できます。
o Access Domain: Between the SIP user device and the visited network.
o アクセスドメイン：SIPユーザーデバイスと訪問されたネットワークの間。
o Network Domain: Between the visited and home networks, or inside the home network.
o ネットワークドメイン：訪問ネットワークとホームネットワークの間、またはホームネットワーク内。
Characteristics needed in the Access Domain are quite different from those of the Network Domain because of the terminal's requirements for mobility, computation restriction, battery limit, bandwidth conservation, and radio interface. SIP entities in the access domain should be able to maintain security contexts with a large group of users in parallel. Furthermore, Access Domain provides user-specific 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エンティティは、大規模なユーザーグループと並行してセキュリティコンテキストを維持できる必要があります。さらに、Accessドメインはユーザー固有のセキュリティアソシエーションを提供しますが、ネットワークドメインはネットワークノード間のセキュリティ関連を提供します。したがって、プロトコルとアルゴリズムの重み、および圧縮メカニズムへのコンプライアンスは、ドメインセキュリティにアクセスするために非常に重要です。したがって、セキュリティソリューションがこれら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は、最大10億人のユーザーの大規模な加入者ベースによって特徴付けられます。これらはすべて、安全な方法で扱わなければなりません。
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つのエンティティがそれぞれのピアのIDを検証できるようにするエンティティ認証を意味します。
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.
認証方法は、Authenticatorと認証されたユーザーの間に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は、UMTSAKA [13]を再利用する予定です。UMTS別名は、対称的な暗号化スキームを適用し、相互認証を提供し、通常、ユーザー側に安全なストレージを提供するいわゆる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.
交渉メカニズムは、認証資格情報にアクセスできない攻撃者から保護する必要があります。特に、交渉メカニズムは、セキュリティが弱い、または誰も交渉されないように、交渉結果に影響を与える可能性のある中間の攻撃者を検出できる必要があります。
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セッションを保護できる必要があります。たとえば、セキュリティモードのパラメーターは、登録の寿命内に有効であると想定される場合があります。セキュリティ協会のセットアップのコストと、いくつかの招待状を介してパラメーターのネゴシエーションを償却する必要があることに注意してください。
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プロキシは、アウトバウンドプロキシがメッセージの原点を検証できた場合、およびレジスタリクエストの場合、それが整合性保護されているかどうかにかかわらず、兆候を受信する必要があります。
Message authentication, key agreement, integrity and replay protection, and confidentiality must be provided for communications between SIP network entities such as proxy servers.
メッセージ認証、主要な合意、整合性、リプレイ保護、および機密性は、プロキシサーバーなどのSIPネットワークエンティティ間の通信に提供する必要があります。
Network domain security mechanisms must be scalable up to a large number of network elements.
ネットワークドメインセキュリティメカニズムは、多数のネットワーク要素までスケーラブルでなければなりません。
3GPP intends to make having the protection discussed above mandatory at least between two operators, and optional within an operator's own network. Security gateways exist between operator's networks.
3GPPは、少なくとも2つのオペレーターの間で上記で議論された保護を義務付け、オプションのオプションでオプションを作成することを目的としています。オペレーターのネットワーク間にセキュリティゲートウェイが存在します。
We believe that the above requirements are fulfilled by applying security mechanisms as specified in the current IP Security standards in RFC 2401 [5].
上記の要件は、RFC 2401の現在のIPセキュリティ基準で指定されているように、セキュリティメカニズムを適用することにより満たされると考えています[5]。
This document does not define a protocol, but still presents some security requirements to protocols. The main security requirements are stated in sections 4.23, 4.24, and 4.25. Additional security-related issues are discussed under sections 4.6, 4.7, 4.8, 4.9, 4.10, and 4.12.
このドキュメントはプロトコルを定義するものではありませんが、プロトコルにいくつかのセキュリティ要件を提示します。主なセキュリティ要件は、セクション4.23、4.24、および4.25に記載されています。セキュリティ関連の追加の問題については、セクション4.6、4.7、4.8、4.9、4.10、および4.12で説明します。
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).
ダンカン・ミルズ（ボーダフォン）、ガボール・バジコ（ノキア）、ジョージ・メイヤー（シーメンス）、フランソワ・セローム・デローム（アルカテル）、ヒュー・シー（AWS）、アンドリュー・アレン（ダイナミクスまたはスニル・チョタイ（MMO2）、キース・ドレイジ（ルーシェント）、Jayshree Bharatia（Nortel）、Kevan Hobbis（Huthison 3G UK）、Dean Willis（Dynamicsoft）、Krisztian Kiss（Nokia）、Vesa Torvinen（Ericsson）、Jari Arkko（Ericsson）、Sonia Garapaty（Nortel）。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[2] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[3] Dierks、T。およびC. Allen、「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] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、RFC 2396、1998年8月。
[5] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[5] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、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. 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] Rosenberg、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] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）を備えたオファー/回答モデル」、RFC 3264、2002年6月。
[12] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[12] Roach、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] Niemi、A.、Arkko、J。、およびV. Torvinen、「HyperText Transfer Protocol（HTTP）認証とキー契約（AKA）を使用した消化認証」、RFC 3310、2002年9月。
[14] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004.
[14] Rosenberg、J。、「登録のためのセッション開始プロトコル（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] Camarillo、G.、Marshall、W。、およびJ. Rosenberg、「リソース管理とセッション開始プロトコルの統合（SIP）」、RFC 3312、2002年10月。
[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] Jennings、C.、Peterson、J。、およびM. Watson、「信頼できるネットワーク内での主張されたアイデンティティのセッション開始プロトコル（SIP）へのプライベートエクステンション」、RFC 3325、2002年11月。
[18] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[18] ピーターソン、J。、「セッション開始プロトコル（SIP）のプライバシーメカニズム」、RFC 3323、2002年11月。
[19] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers", RFC 3319, July 2003.
[19] Schulzrinne、H。およびB. Volz、「セッション開始プロトコル（SIP）サーバーの動的ホスト構成プロトコル（DHCPV6）オプション」、RFC 3319、2003年7月。
[20] Sparks, R., "Session Initiation Protocol Call Control - Transfer", Work in Progress, February 2005.
[20] Sparks、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] Johnston、A.、Donovan、S.、Sparks、R.、Cunningham、C。、およびK. Summers、「セッション開始プロトコル（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] Johnston、A.、Donovan、S.、Sparks、R.、Cunningham、C。、およびK. Summers、「セッション開始プロトコル（SIP）公開電話ネットワーク（PSTN）コールフロー」、BCP 76、RFC 3666、12月2003年。
[23] Johnston, A. and R. Sparks, "Session Initiation Protocol Service Examples", Work in Progress, February 2005.
[23] Johnston、A。、およびR. Sparks、「セッション開始プロトコルサービスの例」、2005年2月の作業。
[24] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[24] Sparks、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] Mahy、R.、Biggs、B。、およびR. Dean、「セッション開始プロトコル（SIP）「ヘッダーを置き換える」、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ベースのサービスのセキュリティにアクセス;（リリース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？type = folders＆lang = e＆parent = 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
ミゲルA.ガルシアマルティンノキアP.O.Box 407 Nokia Group、Fin 00045 Finland
EMail: miguel.an.garcia@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。