[要約] RFC 3261はSIP（Session Initiation Protocol）の仕様を定義しており、インターネット上でのリアルタイム通信セッションの確立と管理を可能にする。このRFCの目的は、SIPの標準化と相互運用性の向上を促進することである。
Network Working Group J. Rosenberg
Request for Comments: 3261 dynamicsoft
Obsoletes: 2543 H. Schulzrinne
Category: Standards Track Columbia U.
G. Camarillo
Ericsson
A. Johnston
WorldCom
J. Peterson
Neustar
R. Sparks
dynamicsoft
M. Handley
ICIR
E. Schooler
AT&T
June 2002
SIP: Session Initiation Protocol
SIP：セッション開始プロトコル
Status of this Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（C）The Internet Society（2002）。全著作権所有。
Abstract
概要
This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences.
このドキュメントでは、1人以上の参加者とのセッションを作成、変更、および終了するためのアプリケーション層制御（シグナリング）プロトコルであるセッション開始プロトコル（SIP）について説明します。これらのセッションには、インターネット電話、マルチメディア配布、およびマルチメディア会議が含まれます。
SIP invitations used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types. SIP makes use of elements called proxy servers to help route requests to the user's current location, authenticate and authorize users for services, implement provider call-routing policies, and provide features to users. SIP also provides a registration function that allows users to upload their current locations for use by proxy servers. SIP runs on top of several different transport protocols.
セッションの作成に使用されるSIP招待には、参加者が一連の互換性のあるメディアタイプについて合意できるようにするセッションの説明が含まれています。 SIPは、プロキシサーバーと呼ばれる要素を利用して、ユーザーの現在の場所への要求のルーティング、サービスに対するユーザーの認証と承認、プロバイダーのコールルーティングポリシーの実装、およびユーザーへの機能の提供を支援します。 SIPには、ユーザーが現在の場所をアップロードしてプロキシサーバーで使用できるようにする登録機能も用意されています。 SIPは、いくつかの異なるトランスポートプロトコルの上で実行されます。
Table of Contents
目次
1 Introduction ........................................ 8
2 Overview of SIP Functionality ....................... 9
3 Terminology ......................................... 10
4 Overview of Operation ............................... 10
5 Structure of the Protocol ........................... 18
6 Definitions ......................................... 20
7 SIP Messages ........................................ 26
7.1 Requests ............................................ 27
7.2 Responses ........................................... 28
7.3 Header Fields ....................................... 29
7.3.1 Header Field Format ................................. 30
7.3.2 Header Field Classification ......................... 32
7.3.3 Compact Form ........................................ 32
7.4 Bodies .............................................. 33
7.4.1 Message Body Type ................................... 33
7.4.2 Message Body Length ................................. 33
7.5 Framing SIP Messages ................................ 34
8 General User Agent Behavior ......................... 34
8.1 UAC Behavior ........................................ 35
8.1.1 Generating the Request .............................. 35
8.1.1.1 Request-URI ......................................... 35
8.1.1.2 To .................................................. 36
8.1.1.3 From ................................................ 37
8.1.1.4 Call-ID ............................................. 37
8.1.1.5 CSeq ................................................ 38
8.1.1.6 Max-Forwards ........................................ 38
8.1.1.7 Via ................................................. 39
8.1.1.8 Contact ............................................. 40
8.1.1.9 Supported and Require ............................... 40
8.1.1.10 Additional Message Components ....................... 41
8.1.2 Sending the Request ................................. 41
8.1.3 Processing Responses ................................ 42
8.1.3.1 Transaction Layer Errors ............................ 42
8.1.3.2 Unrecognized Responses .............................. 42
8.1.3.3 Vias ................................................ 43
8.1.3.4 Processing 3xx Responses ............................ 43
8.1.3.5 Processing 4xx Responses ............................ 45
8.2 UAS Behavior ........................................ 46
8.2.1 Method Inspection ................................... 46
8.2.2 Header Inspection ................................... 46
8.2.2.1 To and Request-URI .................................. 46
8.2.2.2 Merged Requests ..................................... 47
8.2.2.3 Require ............................................. 47
8.2.3 Content Processing .................................. 48
8.2.4 Applying Extensions ................................. 49
8.2.5 Processing the Request .............................. 49
8.2.6 Generating the Response ............................. 49
8.2.6.1 Sending a Provisional Response ...................... 49
8.2.6.2 Headers and Tags .................................... 50
8.2.7 Stateless UAS Behavior .............................. 50
8.3 Redirect Servers .................................... 51
9 Canceling a Request ................................. 53
9.1 Client Behavior ..................................... 53
9.2 Server Behavior ..................................... 55
10 Registrations ....................................... 56
10.1 Overview ............................................ 56
10.2 Constructing the REGISTER Request ................... 57
10.2.1 Adding Bindings ..................................... 59
10.2.1.1 Setting the Expiration Interval of Contact Addresses 60
10.2.1.2 Preferences among Contact Addresses ................. 61
10.2.2 Removing Bindings ................................... 61
10.2.3 Fetching Bindings ................................... 61
10.2.4 Refreshing Bindings ................................. 61
10.2.5 Setting the Internal Clock .......................... 62
10.2.6 Discovering a Registrar ............................. 62
10.2.7 Transmitting a Request .............................. 62
10.2.8 Error Responses ..................................... 63
10.3 Processing REGISTER Requests ........................ 63
11 Querying for Capabilities ........................... 66
11.1 Construction of OPTIONS Request ..................... 67
11.2 Processing of OPTIONS Request ....................... 68
12 Dialogs ............................................. 69
12.1 Creation of a Dialog ................................ 70
12.1.1 UAS behavior ........................................ 70
12.1.2 UAC Behavior ........................................ 71
12.2 Requests within a Dialog ............................ 72
12.2.1 UAC Behavior ........................................ 73
12.2.1.1 Generating the Request .............................. 73
12.2.1.2 Processing the Responses ............................ 75
12.2.2 UAS Behavior ........................................ 76
12.3 Termination of a Dialog ............................. 77
13 Initiating a Session ................................ 77
13.1 Overview ............................................ 77
13.2 UAC Processing ...................................... 78
13.2.1 Creating the Initial INVITE ......................... 78
13.2.2 Processing INVITE Responses ......................... 81
13.2.2.1 1xx Responses ....................................... 81
13.2.2.2 3xx Responses ....................................... 81
13.2.2.3 4xx, 5xx and 6xx Responses .......................... 81
13.2.2.4 2xx Responses ....................................... 82
13.3 UAS Processing ...................................... 83
13.3.1 Processing of the INVITE ............................ 83
13.3.1.1 Progress ............................................ 84
13.3.1.2 The INVITE is Redirected ............................ 84
13.3.1.3 The INVITE is Rejected .............................. 85
13.3.1.4 The INVITE is Accepted .............................. 85
14 Modifying an Existing Session ....................... 86
14.1 UAC Behavior ........................................ 86
14.2 UAS Behavior ........................................ 88
15 Terminating a Session ............................... 89
15.1 Terminating a Session with a BYE Request ............ 90
15.1.1 UAC Behavior ........................................ 90
15.1.2 UAS Behavior ........................................ 91
16 Proxy Behavior ...................................... 91
16.1 Overview ............................................ 91
16.2 Stateful Proxy ...................................... 92
16.3 Request Validation .................................. 94
16.4 Route Information Preprocessing ..................... 96
16.5 Determining Request Targets ......................... 97
16.6 Request Forwarding .................................. 99
16.7 Response Processing ................................. 107
16.8 Processing Timer C .................................. 114
16.9 Handling Transport Errors ........................... 115
16.10 CANCEL Processing ................................... 115
16.11 Stateless Proxy ..................................... 116
16.12 Summary of Proxy Route Processing ................... 118
16.12.1 Examples ............................................ 118
16.12.1.1 Basic SIP Trapezoid ................................. 118
16.12.1.2 Traversing a Strict-Routing Proxy ................... 120
16.12.1.3 Rewriting Record-Route Header Field Values .......... 121
17 Transactions ........................................ 122
17.1 Client Transaction .................................. 124
17.1.1 INVITE Client Transaction ........................... 125
17.1.1.1 Overview of INVITE Transaction ...................... 125
17.1.1.2 Formal Description .................................. 125
17.1.1.3 Construction of the ACK Request ..................... 129
17.1.2 Non-INVITE Client Transaction ....................... 130
17.1.2.1 Overview of the non-INVITE Transaction .............. 130
17.1.2.2 Formal Description .................................. 131
17.1.3 Matching Responses to Client Transactions ........... 132
17.1.4 Handling Transport Errors ........................... 133
17.2 Server Transaction .................................. 134
17.2.1 INVITE Server Transaction ........................... 134
17.2.2 Non-INVITE Server Transaction ....................... 137
17.2.3 Matching Requests to Server Transactions ............ 138
17.2.4 Handling Transport Errors ........................... 141
18 Transport ........................................... 141
18.1 Clients ............................................. 142
18.1.1 Sending Requests .................................... 142
18.1.2 Receiving Responses ................................. 144
18.2 Servers ............................................. 145
18.2.1 Receiving Requests .................................. 145
18.2.2 Sending Responses ................................... 146
18.3 Framing ............................................. 147
18.4 Error Handling ...................................... 147
19 Common Message Components ........................... 147
19.1 SIP and SIPS Uniform Resource Indicators ............ 148
19.1.1 SIP and SIPS URI Components ......................... 148
19.1.2 Character Escaping Requirements ..................... 152
19.1.3 Example SIP and SIPS URIs ........................... 153
19.1.4 URI Comparison ...................................... 153
19.1.5 Forming Requests from a URI ......................... 156
19.1.6 Relating SIP URIs and tel URLs ...................... 157
19.2 Option Tags ......................................... 158
19.3 Tags ................................................ 159
20 Header Fields ....................................... 159
20.1 Accept .............................................. 161
20.2 Accept-Encoding ..................................... 163
20.3 Accept-Language ..................................... 164
20.4 Alert-Info .......................................... 164
20.5 Allow ............................................... 165
20.6 Authentication-Info ................................. 165
20.7 Authorization ....................................... 165
20.8 Call-ID ............................................. 166
20.9 Call-Info ........................................... 166
20.10 Contact ............................................. 167
20.11 Content-Disposition ................................. 168
20.12 Content-Encoding .................................... 169
20.13 Content-Language .................................... 169
20.14 Content-Length ...................................... 169
20.15 Content-Type ........................................ 170
20.16 CSeq ................................................ 170
20.17 Date ................................................ 170
20.18 Error-Info .......................................... 171
20.19 Expires ............................................. 171
20.20 From ................................................ 172
20.21 In-Reply-To ......................................... 172
20.22 Max-Forwards ........................................ 173
20.23 Min-Expires ......................................... 173
20.24 MIME-Version ........................................ 173
20.25 Organization ........................................ 174
20.26 Priority ............................................ 174
20.27 Proxy-Authenticate .................................. 174
20.28 Proxy-Authorization ................................. 175
20.29 Proxy-Require ....................................... 175
20.30 Record-Route ........................................ 175
20.31 Reply-To ............................................ 176
20.32 Require ............................................. 176
20.33 Retry-After ......................................... 176
20.34 Route ............................................... 177
20.35 Server .............................................. 177
20.36 Subject ............................................. 177
20.37 Supported ........................................... 178
20.38 Timestamp ........................................... 178
20.39 To .................................................. 178
20.40 Unsupported ......................................... 179
20.41 User-Agent .......................................... 179
20.42 Via ................................................. 179
20.43 Warning ............................................. 180
20.44 WWW-Authenticate .................................... 182
21 Response Codes ...................................... 182
21.1 Provisional 1xx ..................................... 182
21.1.1 100 Trying .......................................... 183
21.1.2 180 Ringing ......................................... 183
21.1.3 181 Call Is Being Forwarded ......................... 183
21.1.4 182 Queued .......................................... 183
21.1.5 183 Session Progress ................................ 183
21.2 Successful 2xx ...................................... 183
21.2.1 200 OK .............................................. 183
21.3 Redirection 3xx ..................................... 184
21.3.1 300 Multiple Choices ................................ 184
21.3.2 301 Moved Permanently ............................... 184
21.3.3 302 Moved Temporarily ............................... 184
21.3.4 305 Use Proxy ....................................... 185
21.3.5 380 Alternative Service ............................. 185
21.4 Request Failure 4xx ................................. 185
21.4.1 400 Bad Request ..................................... 185
21.4.2 401 Unauthorized .................................... 185
21.4.3 402 Payment Required ................................ 186
21.4.4 403 Forbidden ....................................... 186
21.4.5 404 Not Found ....................................... 186
21.4.6 405 Method Not Allowed .............................. 186
21.4.7 406 Not Acceptable .................................. 186
21.4.8 407 Proxy Authentication Required ................... 186
21.4.9 408 Request Timeout ................................. 186
21.4.10 410 Gone ............................................ 187
21.4.11 413 Request Entity Too Large ........................ 187
21.4.12 414 Request-URI Too Long ............................ 187
21.4.13 415 Unsupported Media Type .......................... 187
21.4.14 416 Unsupported URI Scheme .......................... 187
21.4.15 420 Bad Extension ................................... 187
21.4.16 421 Extension Required .............................. 188
21.4.17 423 Interval Too Brief .............................. 188
21.4.18 480 Temporarily Unavailable ......................... 188
21.4.19 481 Call/Transaction Does Not Exist ................. 188
21.4.20 482 Loop Detected ................................... 188
21.4.21 483 Too Many Hops ................................... 189
21.4.22 484 Address Incomplete .............................. 189
21.4.23 485 Ambiguous ....................................... 189
21.4.24 486 Busy Here ....................................... 189
21.4.25 487 Request Terminated .............................. 190
21.4.26 488 Not Acceptable Here ............................. 190
21.4.27 491 Request Pending ................................. 190
21.4.28 493 Undecipherable .................................. 190
21.5 Server Failure 5xx .................................. 190
21.5.1 500 Server Internal Error ........................... 190
21.5.2 501 Not Implemented ................................. 191
21.5.3 502 Bad Gateway ..................................... 191
21.5.4 503 Service Unavailable ............................. 191
21.5.5 504 Server Time-out ................................. 191
21.5.6 505 Version Not Supported ........................... 192
21.5.7 513 Message Too Large ............................... 192
21.6 Global Failures 6xx ................................. 192
21.6.1 600 Busy Everywhere ................................. 192
21.6.2 603 Decline ......................................... 192
21.6.3 604 Does Not Exist Anywhere ......................... 192
21.6.4 606 Not Acceptable .................................. 192
22 Usage of HTTP Authentication ........................ 193
22.1 Framework ........................................... 193
22.2 User-to-User Authentication ......................... 195
22.3 Proxy-to-User Authentication ........................ 197
22.4 The Digest Authentication Scheme .................... 199
23 S/MIME .............................................. 201
23.1 S/MIME Certificates ................................. 201
23.2 S/MIME Key Exchange ................................. 202
23.3 Securing MIME bodies ................................ 205
23.4 SIP Header Privacy and Integrity using S/MIME:
Tunneling SIP ....................................... 207
23.4.1 Integrity and Confidentiality Properties of SIP
Headers ............................................. 207
23.4.1.1 Integrity ........................................... 207
23.4.1.2 Confidentiality ..................................... 208
23.4.2 Tunneling Integrity and Authentication .............. 209
23.4.3 Tunneling Encryption ................................ 211
24 Examples ............................................ 213
24.1 Registration ........................................ 213
24.2 Session Setup ....................................... 214
25 Augmented BNF for the SIP Protocol .................. 219
25.1 Basic Rules ......................................... 219
26 Security Considerations: Threat Model and Security
Usage Recommendations ............................... 232
26.1 Attacks and Threat Models ........................... 233
26.1.1 Registration Hijacking .............................. 233
26.1.2 Impersonating a Server .............................. 234
26.1.3 Tampering with Message Bodies ....................... 235
26.1.4 Tearing Down Sessions ............................... 235
26.1.5 Denial of Service and Amplification ................. 236
26.2 Security Mechanisms ................................. 237
26.2.1 Transport and Network Layer Security ................ 238
26.2.2 SIPS URI Scheme ..................................... 239
26.2.3 HTTP Authentication ................................. 240
26.2.4 S/MIME .............................................. 240
26.3 Implementing Security Mechanisms .................... 241
26.3.1 Requirements for Implementers of SIP ................ 241
26.3.2 Security Solutions .................................. 242
26.3.2.1 Registration ........................................ 242
26.3.2.2 Interdomain Requests ................................ 243
26.3.2.3 Peer-to-Peer Requests ............................... 245
26.3.2.4 DoS Protection ...................................... 246
26.4 Limitations ......................................... 247
26.4.1 HTTP Digest ......................................... 247
26.4.2 S/MIME .............................................. 248
26.4.3 TLS ................................................. 249
26.4.4 SIPS URIs ........................................... 249
26.5 Privacy ............................................. 251
27 IANA Considerations ................................. 252
27.1 Option Tags ......................................... 252
27.2 Warn-Codes .......................................... 252
27.3 Header Field Names .................................. 253
27.4 Method and Response Codes ........................... 253
27.5 The "message/sip" MIME type. ....................... 254
27.6 New Content-Disposition Parameter Registrations ..... 255
28 Changes From RFC 2543 ............................... 255
28.1 Major Functional Changes ............................ 255
28.2 Minor Functional Changes ............................ 260
29 Normative References ................................ 261
30 Informative References .............................. 262
A Table of Timer Values ............................... 265
Acknowledgments ................................................ 266
Authors' Addresses ............................................. 267
Full Copyright Statement ....................................... 269
1 Introduction
1はじめに
There are many applications of the Internet that require the creation and management of a session, where a session is considered an exchange of data between an association of participants. The implementation of these applications is complicated by the practices of participants: users may move between endpoints, they may be addressable by multiple names, and they may communicate in several different media - sometimes simultaneously. Numerous protocols have been authored that carry various forms of real-time multimedia session data such as voice, video, or text messages. The Session Initiation Protocol (SIP) works in concert with these protocols by enabling Internet endpoints (called user agents) to discover one another and to agree on a characterization of a session they would like to share. For locating prospective session participants, and for other functions, SIP enables the creation of an infrastructure of network hosts (called proxy servers) to which user agents can send registrations, invitations to sessions, and other requests. SIP is an agile, general-purpose tool for creating, modifying, and terminating sessions that works independently of underlying transport protocols and without dependency on the type of session that is being established.
セッションの作成と管理を必要とするインターネットの多くのアプリケーションがあり、セッションは参加者の団体間のデータ交換と見なされます。これらのアプリケーションの実装は、参加者の慣行によって複雑になっています。ユーザーはエンドポイント間を移動したり、複数の名前でアドレス指定したり、同時に複数の異なるメディアで通信したりする場合があります。音声、ビデオ、テキストメッセージなど、さまざまな形式のリアルタイムマルチメディアセッションデータを伝送する多数のプロトコルが作成されています。セッション開始プロトコル（SIP）は、これらのプロトコルと連携して、インターネットエンドポイント（ユーザーエージェントと呼ばれます）が互いを発見し、共有したいセッションの特性に同意できるようにします。 SIPは、予想されるセッション参加者を見つけるため、およびその他の機能のために、ユーザーエージェントが登録、セッションへの招待、およびその他の要求を送信できるネットワークホストのインフラストラクチャ（プロキシサーバーと呼ばれる）の作成を可能にします。 SIPは、基になるトランスポートプロトコルとは独立して機能し、確立されているセッションの種類に依存せずに機能する、セッションを作成、変更、および終了するための俊敏な汎用ツールです。
2 Overview of SIP Functionality
2 SIP機能の概要
SIP is an application-layer control protocol that can establish, modify, and terminate multimedia sessions (conferences) such as Internet telephony calls. SIP can also invite participants to already existing sessions, such as multicast conferences. Media can be added to (and removed from) an existing session. SIP transparently supports name mapping and redirection services, which supports personal mobility [27] - users can maintain a single externally visible identifier regardless of their network location.
SIPは、インターネットテレフォニーコールなどのマルチメディアセッション（会議）を確立、変更、および終了できるアプリケーション層制御プロトコルです。 SIPは、マルチキャスト会議などの既存のセッションに参加者を招待することもできます。メディアは、既存のセッションに追加（および既存のセッションから削除）できます。 SIPは、名前のマッピングとリダイレクトサービスを透過的にサポートし、パーソナルモビリティをサポートします[27]-ユーザーは、ネットワークの場所に関係なく、外部から見える単一の識別子を維持できます。
SIP supports five facets of establishing and terminating multimedia communications:
SIPは、マルチメディア通信の確立と終了の5つの側面をサポートしています。
User location: determination of the end system to be used for communication;
ユーザーの場所：通信に使用するエンドシステムの決定。
User availability: determination of the willingness of the called party to engage in communications;
ユーザーの可用性：通信に従事するための被呼者の意欲の決定。
User capabilities: determination of the media and media parameters to be used;
ユーザー機能：使用するメディアとメディアパラメータの決定。
Session setup: "ringing", establishment of session parameters at both called and calling party;
セッションのセットアップ：「呼び出し」、着信側と発信側の両方でのセッションパラメータの確立。
Session management: including transfer and termination of sessions, modifying session parameters, and invoking services.
セッション管理：セッションの転送と終了、セッションパラメータの変更、サービスの呼び出しなど。
SIP is not a vertically integrated communications system. SIP is rather a component that can be used with other IETF protocols to build a complete multimedia architecture. Typically, these architectures will include protocols such as the Real-time Transport Protocol (RTP) (RFC 1889 [28]) for transporting real-time data and providing QoS feedback, the Real-Time streaming protocol (RTSP) (RFC 2326 [29]) for controlling delivery of streaming media, the Media
SIPは垂直統合型の通信システムではありません。 SIPは、他のIETFプロトコルとともに使用して完全なマルチメディアアーキテクチャを構築できるコンポーネントです。通常、これらのアーキテクチャには、リアルタイムデータを転送してQoSフィードバックを提供するReal-time Transport Protocol（RTP）（RFC 1889 [28]）、Real-Time Streaming Protocol（RTSP）（RFC 2326 [29 ]）ストリーミングメディアの配信を制御するためのメディア
Gateway Control Protocol (MEGACO) (RFC 3015 [30]) for controlling gateways to the Public Switched Telephone Network (PSTN), and the Session Description Protocol (SDP) (RFC 2327 [1]) for describing multimedia sessions. Therefore, SIP should be used in conjunction with other protocols in order to provide complete services to the users. However, the basic functionality and operation of SIP does not depend on any of these protocols.
公衆交換電話網（PSTN）へのゲートウェイを制御するためのゲートウェイ制御プロトコル（MEGACO）（RFC 3015 [30]）、およびマルチメディアセッションを説明するためのセッション記述プロトコル（SDP）（RFC 2327 [1]）。したがって、ユーザーに完全なサービスを提供するには、SIPを他のプロトコルと組み合わせて使用する必要があります。ただし、SIPの基本的な機能と操作は、これらのプロトコルのいずれにも依存しません。
SIP does not provide services. Rather, SIP provides primitives that can be used to implement different services. For example, SIP can locate a user and deliver an opaque object to his current location. If this primitive is used to deliver a session description written in SDP, for instance, the endpoints can agree on the parameters of a session. If the same primitive is used to deliver a photo of the caller as well as the session description, a "caller ID" service can be easily implemented. As this example shows, a single primitive is typically used to provide several different services.
SIPはサービスを提供しません。むしろ、SIPは、さまざまなサービスを実装するために使用できるプリミティブを提供します。たとえば、SIPはユーザーを特定し、不透明なオブジェクトを現在の場所に配信できます。たとえば、このプリミティブを使用してSDPで記述されたセッション記述を配信する場合、エンドポイントはセッションのパラメーターについて合意できます。同じプリミティブを使用して発信者の写真とセッションの説明を配信すると、「発信者ID」サービスを簡単に実装できます。この例が示すように、単一のプリミティブは通常、いくつかの異なるサービスを提供するために使用されます。
SIP does not offer conference control services such as floor control or voting and does not prescribe how a conference is to be managed. SIP can be used to initiate a session that uses some other conference control protocol. Since SIP messages and the sessions they establish can pass through entirely different networks, SIP cannot, and does not, provide any kind of network resource reservation capabilities.
SIPは、フロア制御や投票などの会議制御サービスを提供せず、会議の管理方法を規定していません。 SIPを使用して、他の会議制御プロトコルを使用するセッションを開始できます。 SIPメッセージとそれらが確立するセッションは完全に異なるネットワークを通過できるため、SIPはあらゆる種類のネットワークリソース予約機能を提供できず、提供しません。
The nature of the services provided make security particularly important. To that end, SIP provides a suite of security services, which include denial-of-service prevention, authentication (both user to user and proxy to user), integrity protection, and encryption and privacy services.
提供されるサービスの性質により、セキュリティが特に重要になります。そのために、SIPは一連のセキュリティサービスを提供します。これには、サービス拒否防止、認証（ユーザーからユーザー、プロキシからユーザーの両方）、整合性保護、暗号化およびプライバシーサービスが含まれます。
SIP works with both IPv4 and IPv6.
SIPはIPv4とIPv6の両方で動作します。
3 Terminology
3用語
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [2] and indicate requirement levels for compliant SIP implementations.
このドキュメントでは、キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」 、および「OPTIONAL」は、BCP 14、RFC 2119 [2]で説明されているように解釈され、準拠するSIP実装の要件レベルを示します。
4 Overview of Operation
4運用の概要
This section introduces the basic operations of SIP using simple examples. This section is tutorial in nature and does not contain any normative statements.
このセクションでは、簡単な例を使用してSIPの基本的な操作を紹介します。このセクションは本来チュートリアルであり、規範的な記述は含まれていません。
The first example shows the basic functions of SIP: location of an end point, signal of a desire to communicate, negotiation of session parameters to establish the session, and teardown of the session once established.
最初の例は、SIPの基本的な機能を示しています。エンドポイントの場所、通信したいという希望の信号、セッションを確立するためのセッションパラメータのネゴシエーション、確立されたセッションの破棄です。
Figure 1 shows a typical example of a SIP message exchange between two users, Alice and Bob. (Each message is labeled with the letter "F" and a number for reference by the text.) In this example, Alice uses a SIP application on her PC (referred to as a softphone) to call Bob on his SIP phone over the Internet. Also shown are two SIP proxy servers that act on behalf of Alice and Bob to facilitate the session establishment. This typical arrangement is often referred to as the "SIP trapezoid" as shown by the geometric shape of the dotted lines in Figure 1.
図1は、2人のユーザー、アリスとボブの間のSIPメッセージ交換の典型的な例を示しています。 （各メッセージには、文字「F」とテキストによる参照用の番号が付いています。）この例では、アリスは自分のPCのSIPアプリケーション（ソフトフォンと呼ばれます）を使用して、インターネット経由でSIP電話でボブに電話をかけます。 。また、セッションの確立を容易にするために、アリスとボブに代わって動作する2つのSIPプロキシサーバーも示しています。この典型的な配置は、図1の点線の幾何学的形状によって示されるように、「SIP台形」と呼ばれることがよくあります。
Alice "calls" Bob using his SIP identity, a type of Uniform Resource Identifier (URI) called a SIP URI. SIP URIs are defined in Section 19.1. It has a similar form to an email address, typically containing a username and a host name. In this case, it is sip:bob@biloxi.com, where biloxi.com is the domain of Bob's SIP service provider. Alice has a SIP URI of sip:alice@atlanta.com. Alice might have typed in Bob's URI or perhaps clicked on a hyperlink or an entry in an address book. SIP also provides a secure URI, called a SIPS URI. An example would be sips:bob@biloxi.com. A call made to a SIPS URI guarantees that secure, encrypted transport (namely TLS) is used to carry all SIP messages from the caller to the domain of the callee. From there, the request is sent securely to the callee, but with security mechanisms that depend on the policy of the domain of the callee.
アリスは、SIP URIと呼ばれるUniform Resource Identifier（URI）の一種であるSIP IDを使用してボブを「呼び出し」ます。 SIP URIはセクション19.1で定義されています。これは電子メールアドレスに似た形式で、通常はユーザー名とホスト名が含まれています。この場合、それはsip：bob@biloxi.comで、biloxi.comはボブのSIPサービスプロバイダーのドメインです。アリスは、sip：alice@atlanta.comのSIP URIを持っています。アリスはボブのURIを入力したか、ハイパーリンクまたはアドレス帳のエントリをクリックした可能性があります。 SIPは、SIPS URIと呼ばれる安全なURIも提供します。たとえば、sips：bob@biloxi.comです。 SIPS URIへの呼び出しは、安全で暗号化されたトランスポート（つまりTLS）を使用して、すべてのSIPメッセージを呼び出し元から呼び出し先のドメインに運ぶことを保証します。そこから、リクエストは安全に呼び出し先に送信されますが、セキュリティメカニズムは呼び出し先のドメインのポリシーに依存します。
SIP is based on an HTTP-like request/response transaction model. Each transaction consists of a request that invokes a particular method, or function, on the server and at least one response. In this example, the transaction begins with Alice's softphone sending an INVITE request addressed to Bob's SIP URI. INVITE is an example of a SIP method that specifies the action that the requestor (Alice) wants the server (Bob) to take. The INVITE request contains a number of header fields. Header fields are named attributes that provide additional information about a message. The ones present in an INVITE include a unique identifier for the call, the destination address, Alice's address, and information about the type of session that Alice wishes to establish with Bob. The INVITE (message F1 in Figure 1) might look like this:
SIPは、HTTPのような要求/応答トランザクションモデルに基づいています。各トランザクションは、サーバー上の特定のメソッドまたは関数を呼び出す要求と、少なくとも1つの応答で構成されます。この例では、トランザクションは、アリスのソフトフォンがボブのSIP URI宛てのINVITEリクエストを送信することから始まります。 INVITEは、リクエスター（Alice）がサーバー（Bob）に実行させたいアクションを指定するSIPメソッドの例です。 INVITEリクエストには、いくつかのヘッダーフィールドが含まれています。ヘッダーフィールドは、メッセージに関する追加情報を提供する名前付き属性です。 INVITEに含まれるものには、通話の一意の識別子、宛先アドレス、アリスのアドレス、およびアリスがボブとの確立を希望するセッションのタイプに関する情報が含まれます。 INVITE（図1のメッセージF1）は次のようになります。
atlanta.com . . . biloxi.com
. proxy proxy .
. .
Alice's . . . . . . . . . . . . . . . . . . . . Bob's
softphone SIP Phone
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| 100 Trying F3 |--------------->| INVITE F4 |
|<---------------| 100 Trying F5 |--------------->|
| |<-------------- | 180 Ringing F6 |
| | 180 Ringing F7 |<---------------|
| 180 Ringing F8 |<---------------| 200 OK F9 |
|<---------------| 200 OK F10 |<---------------|
| 200 OK F11 |<---------------| |
|<---------------| | |
| ACK F12 |
|------------------------------------------------->|
| Media Session |
|<================================================>|
| BYE F13 |
|<-------------------------------------------------|
| 200 OK F14 |
|------------------------------------------------->|
| |
Figure 1: SIP session setup example with SIP trapezoid
図1：SIP台形を使用したSIPセッションのセットアップ例
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)
（アリスのSDPは表示されていません）
The first line of the text-encoded message contains the method name (INVITE). The lines that follow are a list of header fields. This example contains a minimum required set. The header fields are briefly described below: Via contains the address (pc33.atlanta.com) at which Alice is expecting to receive responses to this request. It also contains a branch parameter that identifies this transaction.
テキストエンコードされたメッセージの最初の行には、メソッド名（INVITE）が含まれています。次の行は、ヘッダーフィールドのリストです。この例には、最低限必要なセットが含まれています。ヘッダーフィールドについて簡単に説明します。Viaには、アリスがこの要求に対する応答を受信することを期待しているアドレス（pc33.atlanta.com）が含まれています。また、このトランザクションを識別するブランチパラメータも含まれています。
To contains a display name (Bob) and a SIP or SIPS URI (sip:bob@biloxi.com) towards which the request was originally directed. Display names are described in RFC 2822 [3].
表示名（Bob）と、リクエストが最初に送信されたSIPまたはSIPS URI（sip：bob@biloxi.com）が含まれます。表示名はRFC 2822 [3]で説明されています。
From also contains a display name (Alice) and a SIP or SIPS URI (sip:alice@atlanta.com) that indicate the originator of the request. This header field also has a tag parameter containing a random string (1928301774) that was added to the URI by the softphone. It is used for identification purposes.
Fromには、要求の発信者を示す表示名（Alice）とSIPまたはSIPS URI（sip：alice@atlanta.com）も含まれています。このヘッダーフィールドには、ソフトフォンによってURIに追加されたランダム文字列（1928301774）を含むタグパラメータもあります。識別目的で使用されます。
Call-ID contains a globally unique identifier for this call, generated by the combination of a random string and the softphone's host name or IP address. The combination of the To tag, From tag, and Call-ID completely defines a peer-to-peer SIP relationship between Alice and Bob and is referred to as a dialog.
Call-IDには、ランダムな文字列とソフトフォンのホスト名またはIPアドレスの組み合わせによって生成された、この呼び出しのグローバルに一意の識別子が含まれています。 Toタグ、Fromタグ、およびCall-IDの組み合わせは、AliceとBob間のピアツーピアSIP関係を完全に定義し、ダイアログと呼ばれます。
CSeq or Command Sequence contains an integer and a method name. The CSeq number is incremented for each new request within a dialog and is a traditional sequence number.
CSeqまたはコマンドシーケンスには、整数とメソッド名が含まれています。 CSeq番号は、ダイアログ内の新しいリクエストごとに増分され、従来のシーケンス番号です。
Contact contains a SIP or SIPS URI that represents a direct route to contact Alice, usually composed of a username at a fully qualified domain name (FQDN). While an FQDN is preferred, many end systems do not have registered domain names, so IP addresses are permitted. While the Via header field tells other elements where to send the response, the Contact header field tells other elements where to send future requests.
連絡先には、通常は完全修飾ドメイン名（FQDN）のユーザー名で構成される、アリスに連絡するための直接ルートを表すSIPまたはSIPS URIが含まれています。 FQDNが推奨されますが、多くのエンドシステムにはドメイン名が登録されていないため、IPアドレスが許可されます。 Viaヘッダーフィールドは他の要素に応答の送信先を通知しますが、Contactヘッダーフィールドは他の要素に将来のリクエストの送信先を通知します。
Max-Forwards serves to limit the number of hops a request can make on the way to its destination. It consists of an integer that is decremented by one at each hop.
Max-Forwardsは、宛先への途中で要求が行えるホップ数を制限する働きをします。これは、各ホップで1ずつ減分される整数で構成されます。
Content-Type contains a description of the message body (not shown).
Content-Typeには、メッセージ本文の説明が含まれています（図には示されていません）。
Content-Length contains an octet (byte) count of the message body.
Content-Lengthには、メッセージ本文のオクテット（バイト）カウントが含まれます。
The complete set of SIP header fields is defined in Section 20.
SIPヘッダーフィールドの完全なセットは、セクション20で定義されています。
The details of the session, such as the type of media, codec, or sampling rate, are not described using SIP. Rather, the body of a SIP message contains a description of the session, encoded in some other protocol format. One such format is the Session Description Protocol (SDP) (RFC 2327 [1]). This SDP message (not shown in the
メディアのタイプ、コーデック、サンプリングレートなどのセッションの詳細は、SIPを使用して記述されていません。むしろ、SIPメッセージの本文には、他のプロトコル形式でエンコードされたセッションの説明が含まれています。そのような形式の1つは、Session Description Protocol（SDP）（RFC 2327 [1]）です。このSDPメッセージ（には表示されません）
example) is carried by the SIP message in a way that is analogous to a document attachment being carried by an email message, or a web page being carried in an HTTP message.
例）は、電子メールメッセージで運ばれるドキュメントの添付ファイル、またはHTTPメッセージで運ばれるWebページに類似した方法でSIPメッセージによって運ばれます。
Since the softphone does not know the location of Bob or the SIP server in the biloxi.com domain, the softphone sends the INVITE to the SIP server that serves Alice's domain, atlanta.com. The address of the atlanta.com SIP server could have been configured in Alice's softphone, or it could have been discovered by DHCP, for example.
ソフトフォンは、biloxi.comドメイン内のボブまたはSIPサーバーの場所を認識していないため、アリスのドメインatlanta.comにサービスを提供するSIPサーバーにINVITEを送信します。 atlanta.com SIPサーバーのアドレスは、Aliceのソフトフォンで構成されているか、またはDHCPによって検出されている可能性があります。
The atlanta.com SIP server is a type of SIP server known as a proxy server. A proxy server receives SIP requests and forwards them on behalf of the requestor. In this example, the proxy server receives the INVITE request and sends a 100 (Trying) response back to Alice's softphone. The 100 (Trying) response indicates that the INVITE has been received and that the proxy is working on her behalf to route the INVITE to the destination. Responses in SIP use a three-digit code followed by a descriptive phrase. This response contains the same To, From, Call-ID, CSeq and branch parameter in the Via as the INVITE, which allows Alice's softphone to correlate this response to the sent INVITE. The atlanta.com proxy server locates the proxy server at biloxi.com, possibly by performing a particular type of DNS (Domain Name Service) lookup to find the SIP server that serves the biloxi.com domain. This is described in [4]. As a result, it obtains the IP address of the biloxi.com proxy server and forwards, or proxies, the INVITE request there. Before forwarding the request, the atlanta.com proxy server adds an additional Via header field value that contains its own address (the INVITE already contains Alice's address in the first Via). The biloxi.com proxy server receives the INVITE and responds with a 100 (Trying) response back to the atlanta.com proxy server to indicate that it has received the INVITE and is processing the request. The proxy server consults a database, generically called a location service, that contains the current IP address of Bob. (We shall see in the next section how this database can be populated.) The biloxi.com proxy server adds another Via header field value with its own address to the INVITE and proxies it to Bob's SIP phone.
atlanta.com SIPサーバーは、プロキシサーバーと呼ばれるSIPサーバーの一種です。プロキシサーバーはSIP要求を受信し、要求者に代わってそれらを転送します。この例では、プロキシサーバーはINVITE要求を受信し、100（Trying）応答をAliceのソフトフォンに送信します。 100（試行中）応答は、INVITEが受信され、プロキシが代わりにINVITEを宛先にルーティングするように機能していることを示します。 SIPでの応答では、3桁のコードの後に説明文が続きます。この応答には、INVITEと同じVia、From、Call-ID、CSeq、およびブランチパラメーターが含まれています。これにより、アリスのソフトフォンがこの応答を送信されたINVITEに関連付けることができます。 atlanta.comプロキシサーバーは、biloxi.comにプロキシサーバーを配置します。おそらく、特定のタイプのDNS（ドメインネームサービス）ルックアップを実行して、biloxi.comドメインにサービスを提供するSIPサーバーを見つけます。これは[4]で説明されています。その結果、biloxi.comプロキシサーバーのIPアドレスを取得し、INVITE要求をそこに転送またはプロキシします。要求を転送する前に、atlanta.comプロキシサーバーは、独自のアドレスを含む追加のViaヘッダーフィールド値を追加します（INVITEには、最初のViaにすでにアリスのアドレスが含まれています）。 biloxi.comプロキシサーバーは、INVITEを受信し、100（Trying）応答でatlanta.comプロキシサーバーに返信して、INVITEを受信し、要求を処理していることを示します。プロキシー・サーバーは、Bobの現在のIPアドレスを含む、一般的にロケーション・サービスと呼ばれるデータベースを調べます。 （次のセクションで、このデータベースにデータを入力する方法を説明します。）biloxi.comプロキシサーバーは、独自のアドレスを持つ別のViaヘッダーフィールド値をINVITEに追加し、ボブのSIP電話にプロキシします。
Bob's SIP phone receives the INVITE and alerts Bob to the incoming call from Alice so that Bob can decide whether to answer the call, that is, Bob's phone rings. Bob's SIP phone indicates this in a 180 (Ringing) response, which is routed back through the two proxies in the reverse direction. Each proxy uses the Via header field to determine where to send the response and removes its own address from the top. As a result, although DNS and location service lookups were required to route the initial INVITE, the 180 (Ringing) response can be returned to the caller without lookups or without state being maintained in the proxies. This also has the desirable property that each proxy that sees the INVITE will also see all responses to the INVITE.
ボブのSIP電話機はINVITEを受信し、アリスからの着信コールをボブに警告します。これにより、ボブはコールに応答するかどうか、つまりボブの電話が鳴るかどうかを決定できます。 BobのSIP電話は、180（Ringing）応答でこれを示し、2つのプロキシを介して逆方向にルーティングされます。各プロキシは、Viaヘッダーフィールドを使用して応答の送信先を決定し、独自のアドレスを先頭から削除します。その結果、最初のINVITEをルーティングするためにDNSおよびロケーションサービスルックアップが必要でしたが、ルックアップなしで、またはプロキシで状態が維持されずに、180（Ringing）応答を呼び出し元に返すことができます。これには、INVITEを参照する各プロキシがINVITEへのすべての応答も参照するという望ましい特性もあります。
When Alice's softphone receives the 180 (Ringing) response, it passes this information to Alice, perhaps using an audio ringback tone or by displaying a message on Alice's screen.
Aliceのソフトフォンが180（Ringing）応答を受信すると、おそらく音声リングバックトーンを使用するか、Aliceの画面にメッセージを表示することによって、この情報をAliceに渡します。
In this example, Bob decides to answer the call. When he picks up the handset, his SIP phone sends a 200 (OK) response to indicate that the call has been answered. The 200 (OK) contains a message body with the SDP media description of the type of session that Bob is willing to establish with Alice. As a result, there is a two-phase exchange of SDP messages: Alice sent one to Bob, and Bob sent one back to Alice. This two-phase exchange provides basic negotiation capabilities and is based on a simple offer/answer model of SDP exchange. If Bob did not wish to answer the call or was busy on another call, an error response would have been sent instead of the 200 (OK), which would have resulted in no media session being established. The complete list of SIP response codes is in Section 21. The 200 (OK) (message F9 in Figure 1) might look like this as Bob sends it out:
この例では、ボブは通話に応答することにします。彼が受話器を取り上げると、彼のSIP電話機は200（OK）応答を送信して、コールが応答されたことを示します。 200（OK）には、ボブがアリスと確立しようとしているセッションのタイプのSDPメディア記述を含むメッセージ本文が含まれています。その結果、SDPメッセージは2フェーズで交換されます。アリスは1つをボブに送信し、ボブは1つをアリスに送り返しました。この2フェーズの交換は、基本的なネゴシエーション機能を提供し、SDP交換の単純なオファー/アンサーモデルに基づいています。ボブがコールに応答したくないか、別のコールでビジーだった場合、200（OK）の代わりにエラー応答が送信され、メディアセッションが確立されませんでした。 SIP応答コードの完全なリストはセクション21にあります。ボブが送信すると、200（OK）（図1のメッセージF9）は次のようになります。
SIP/2.0 200 OK
Via: SIP/2.0/UDP server10.biloxi.com
;branch=z9hG4bKnashds8;received=192.0.2.3
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com
;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com
;branch=z9hG4bK776asdhds ;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:bob@192.0.2.4>
Content-Type: application/sdp
Content-Length: 131
(Bob's SDP not shown)
（ボブのSDPは表示されていません）
The first line of the response contains the response code (200) and the reason phrase (OK). The remaining lines contain header fields. The Via, To, From, Call-ID, and CSeq header fields are copied from the INVITE request. (There are three Via header field values - one added by Alice's SIP phone, one added by the atlanta.com proxy, and one added by the biloxi.com proxy.) Bob's SIP phone has added a tag parameter to the To header field. This tag will be incorporated by both endpoints into the dialog and will be included in all future requests and responses in this call. The Contact header field contains a URI at which Bob can be directly reached at his SIP phone. The Content-Type and Content-Length refer to the message body (not shown) that contains Bob's SDP media information.
応答の最初の行には、応答コード（200）と理由句（OK）が含まれています。残りの行にはヘッダーフィールドが含まれています。 Via、To、From、Call-ID、およびCSeqヘッダーフィールドは、INVITE要求からコピーされます。 （3つのViaヘッダーフィールド値があります。1つはAliceのSIP電話によって追加され、1つはatlanta.comプロキシによって追加され、もう1つはbiloxi.comプロキシによって追加されます。）BobのSIP電話は、タグパラメーターをToヘッダーフィールドに追加しました。このタグは両方のエンドポイントによってダイアログに組み込まれ、この呼び出しの今後のすべての要求と応答に含まれます。 Contactヘッダーフィールドには、ボブがSIP電話で直接到達できるURIが含まれています。 Content-TypeおよびContent-Lengthは、BobのSDPメディア情報を含むメッセージ本文（図示せず）を参照します。
In addition to DNS and location service lookups shown in this example, proxy servers can make flexible "routing decisions" to decide where to send a request. For example, if Bob's SIP phone returned a 486 (Busy Here) response, the biloxi.com proxy server could proxy the INVITE to Bob's voicemail server. A proxy server can also send an INVITE to a number of locations at the same time. This type of parallel search is known as forking.
この例に示されているDNSおよびロケーションサービスの検索に加えて、プロキシサーバーは柔軟な「ルーティングの決定」を行って、要求の送信先を決定できます。たとえば、BobのSIP電話が486（Busy Here）応答を返した場合、biloxi.comプロキシサーバーは、INVITEをBobのボイスメールサーバーにプロキシできます。プロキシサーバーは、INVITEを複数の場所に同時に送信することもできます。このタイプの並列検索は、フォークと呼ばれます。
In this case, the 200 (OK) is routed back through the two proxies and is received by Alice's softphone, which then stops the ringback tone and indicates that the call has been answered. Finally, Alice's softphone sends an acknowledgement message, ACK, to Bob's SIP phone to confirm the reception of the final response (200 (OK)). In this example, the ACK is sent directly from Alice's softphone to Bob's SIP phone, bypassing the two proxies. This occurs because the endpoints have learned each other's address from the Contact header fields through the INVITE/200 (OK) exchange, which was not known when the initial INVITE was sent. The lookups performed by the two proxies are no longer needed, so the proxies drop out of the call flow. This completes the INVITE/200/ACK three-way handshake used to establish SIP sessions. Full details on session setup are in Section 13.
この場合、200（OK）は2つのプロキシを経由してルーティングされ、Aliceのソフトフォンによって受信されます。これは、リングバックトーンを停止し、コールが応答されたことを示します。最後に、アリスのソフトフォンが確認メッセージACKをボブのSIP電話に送信して、最終応答の受信を確認します（200（OK））。この例では、ACKは2つのプロキシをバイパスして、AliceのソフトフォンからBobのSIP電話に直接送信されます。これは、エンドポイントがINVITE / 200（OK）交換を介して連絡先ヘッダーフィールドから互いのアドレスを学習したために発生します。 2つのプロキシによって実行されるルックアップは不要になったため、プロキシはコールフローから削除されます。これで、SIPセッションの確立に使用されるINVITE / 200 / ACKスリーウェイハンドシェイクが完了しました。セッション設定の詳細については、セクション13を参照してください。
Alice and Bob's media session has now begun, and they send media packets using the format to which they agreed in the exchange of SDP. In general, the end-to-end media packets take a different path from the SIP signaling messages.
アリスとボブのメディアセッションが開始され、SDPの交換で合意した形式を使用してメディアパケットを送信します。一般に、エンドツーエンドのメディアパケットは、SIPシグナリングメッセージとは異なるパスを使用します。
During the session, either Alice or Bob may decide to change the characteristics of the media session. This is accomplished by sending a re-INVITE containing a new media description. This re-INVITE references the existing dialog so that the other party knows that it is to modify an existing session instead of establishing a new session. The other party sends a 200 (OK) to accept the change. The requestor responds to the 200 (OK) with an ACK. If the other party does not accept the change, he sends an error response such as 488 (Not Acceptable Here), which also receives an ACK. However, the failure of the re-INVITE does not cause the existing call to fail - the session continues using the previously negotiated characteristics. Full details on session modification are in Section 14.
セッション中に、アリスまたはボブのどちらかがメディアセッションの特性を変更することを決定できます。これは、新しいメディアの説明を含むre-INVITEを送信することで実現されます。このre-INVITEは既存のダイアログを参照するため、新しいセッションを確立するのではなく、既存のセッションを変更する必要があることを相手は認識できます。相手は200（OK）を送信して変更を受け入れます。リクエスタは200（OK）にACKで応答します。相手が変更を受け入れない場合、相手は488（Not Acceptable Here）などのエラー応答を送信し、ACKも受信します。ただし、re-INVITEが失敗しても、既存のコールは失敗しません。セッションは、以前にネゴシエートされた特性を使用して続行されます。セッション変更の詳細については、セクション14を参照してください。
At the end of the call, Bob disconnects (hangs up) first and generates a BYE message. This BYE is routed directly to Alice's softphone, again bypassing the proxies. Alice confirms receipt of the BYE with a 200 (OK) response, which terminates the session and the BYE transaction. No ACK is sent - an ACK is only sent in response to a response to an INVITE request. The reasons for this special handling for INVITE will be discussed later, but relate to the reliability mechanisms in SIP, the length of time it can take for a ringing phone to be answered, and forking. For this reason, request handling in SIP is often classified as either INVITE or non-INVITE, referring to all other methods besides INVITE. Full details on session termination are in Section 15.
コールの終わりに、ボブは最初に切断（ハングアップ）し、BYEメッセージを生成します。このBYEは、プロキシをバイパスして、アリスのソフトフォンに直接ルーティングされます。 AliceはBYEの受信を200（OK）応答で確認します。これにより、セッションとBYEトランザクションが終了します。 ACKは送信されません-ACKは、INVITE要求への応答に応答してのみ送信されます。 INVITEのこの特別な処理の理由については後で説明しますが、SIPの信頼性メカニズム、呼び出し中の電話が応答されるまでにかかる時間、および分岐に関連しています。このため、SIPでの要求処理は、INVITE以外のすべての方法を参照して、INVITEまたは非INVITEに分類されることがよくあります。セッション終了の詳細については、セクション15を参照してください。
Section 24.2 describes the messages shown in Figure 1 in full.
セクション24.2は、図1に示されているメッセージを完全に説明しています。
In some cases, it may be useful for proxies in the SIP signaling path to see all the messaging between the endpoints for the duration of the session. For example, if the biloxi.com proxy server wished to remain in the SIP messaging path beyond the initial INVITE, it would add to the INVITE a required routing header field known as Record-Route that contained a URI resolving to the hostname or IP address of the proxy. This information would be received by both Bob's SIP phone and (due to the Record-Route header field being passed back in the 200 (OK)) Alice's softphone and stored for the duration of the dialog. The biloxi.com proxy server would then receive and proxy the ACK, BYE, and 200 (OK) to the BYE. Each proxy can independently decide to receive subsequent messages, and those messages will pass through all proxies that elect to receive it. This capability is frequently used for proxies that are providing mid-call features.
場合によっては、セッション中にエンドポイント間のすべてのメッセージングを確認すると、SIPシグナリングパスのプロキシに役立つことがあります。たとえば、biloxi.comプロキシサーバーが最初のINVITEを超えてSIPメッセージングパスに留まることを望む場合、ホスト名またはIPアドレスに解決するURIを含むRecord-Routeと呼ばれる必須のルーティングヘッダーフィールドをINVITEに追加しますプロキシの。この情報は、BobのSIP電話と、（Record-Routeヘッダーフィールドが200（OK）で返されるため）アリスのソフトフォンの両方で受信され、ダイアログの期間中保存されます。 biloxi.comプロキシサーバーは、ACK、BYE、および200（OK）を受信してBYEにプロキシします。各プロキシは独立して後続のメッセージを受信することを決定でき、それらのメッセージは受信を選択したすべてのプロキシを通過します。この機能は、通話中機能を提供しているプロキシでよく使用されます。
Registration is another common operation in SIP. Registration is one way that the biloxi.com server can learn the current location of Bob. Upon initialization, and at periodic intervals, Bob's SIP phone sends REGISTER messages to a server in the biloxi.com domain known as a SIP registrar. The REGISTER messages associate Bob's SIP or SIPS URI (sip:bob@biloxi.com) with the machine into which he is currently logged (conveyed as a SIP or SIPS URI in the Contact header field). The registrar writes this association, also called a binding, to a database, called the location service, where it can be used by the proxy in the biloxi.com domain. Often, a registrar server for a domain is co-located with the proxy for that domain. It is an important concept that the distinction between types of SIP servers is logical, not physical.
登録は、SIPのもう1つの一般的な操作です。登録は、biloxi.comサーバーがボブの現在の場所を知ることができる1つの方法です。初期化時および定期的な間隔で、BobのSIP電話機は、REGISTERメッセージをSIPレジストラと呼ばれるbiloxi.comドメインのサーバーに送信します。 REGISTERメッセージは、BobのSIPまたはSIPS URI（sip：bob@biloxi.com）を現在ログインしているマシンに関連付けます（ContactヘッダーフィールドでSIPまたはSIPS URIとして伝達されます）。レジストラはこの関連付け（バインディングとも呼ばれます）を、位置サービスと呼ばれるデータベースに書き込みます。このサービスは、biloxi.comドメインのプロキシで使用できます。多くの場合、ドメインのレジストラサーバーは、そのドメインのプロキシと同じ場所に配置されます。 SIPサーバーのタイプの違いは、物理的ではなく論理的であることが重要な概念です。
Bob is not limited to registering from a single device. For example, both his SIP phone at home and the one in the office could send registrations. This information is stored together in the location service and allows a proxy to perform various types of searches to locate Bob. Similarly, more than one user can be registered on a single device at the same time.
ボブは単一のデバイスからの登録に限定されていません。たとえば、自宅のSIP電話機とオフィスのSIP電話機の両方が登録を送信できます。この情報はロケーションサービスに一緒に保存され、プロキシがボブを見つけるためにさまざまなタイプの検索を実行できるようにします。同様に、複数のユーザーを1つのデバイスに同時に登録できます。
The location service is just an abstract concept. It generally contains information that allows a proxy to input a URI and receive a set of zero or more URIs that tell the proxy where to send the request. Registrations are one way to create this information, but not the only way. Arbitrary mapping functions can be configured at the discretion of the administrator.
位置情報サービスは抽象的な概念にすぎません。通常、プロキシがURIを入力し、リクエストを送信する場所をプロキシに通知する一連の0個以上のURIを受信できるようにする情報が含まれています。登録は、この情報を作成する1つの方法ですが、唯一の方法ではありません。管理者の裁量で任意のマッピング機能を設定できます。
Finally, it is important to note that in SIP, registration is used for routing incoming SIP requests and has no role in authorizing outgoing requests. Authorization and authentication are handled in SIP either on a request-by-request basis with a challenge/response mechanism, or by using a lower layer scheme as discussed in Section 26.
最後に、SIPでは、登録は着信SIPリクエストのルーティングに使用され、発信リクエストの承認には関与しないことに注意することが重要です。承認と認証は、チャレンジ/レスポンスメカニズムを使用してリクエストごとに、またはセクション26で説明する下位層スキームを使用することにより、SIPで処理されます。
The complete set of SIP message details for this registration example is in Section 24.1.
この登録例のSIPメッセージ詳細の完全なセットは、セクション24.1にあります。
Additional operations in SIP, such as querying for the capabilities of a SIP server or client using OPTIONS, or canceling a pending request using CANCEL, will be introduced in later sections.
OPTIONSを使用したSIPサーバーまたはクライアントの機能のクエリや、CANCELを使用した保留中の要求のキャンセルなど、SIPの追加操作については、後のセクションで紹介します。
5 Structure of the Protocol
5プロトコルの構造
SIP is structured as a layered protocol, which means that its behavior is described in terms of a set of fairly independent processing stages with only a loose coupling between each stage. The protocol behavior is described as layers for the purpose of presentation, allowing the description of functions common across elements in a single section. It does not dictate an implementation in any way. When we say that an element "contains" a layer, we mean it is compliant to the set of rules defined by that layer.
SIPは階層化プロトコルとして構造化されています。つまり、その動作は、各ステージ間の疎結合のみを備えた、かなり独立した一連の処理ステージの観点から説明されています。プロトコルの振る舞いは、プレゼンテーションの目的でレイヤーとして記述されており、単一のセクションで要素全体に共通の機能を記述できます。いかなる方法でも実装を指示するものではありません。要素が層を「含む」と言うとき、それはその層によって定義された一連の規則に準拠していることを意味します。
Not every element specified by the protocol contains every layer. Furthermore, the elements specified by SIP are logical elements, not physical ones. A physical realization can choose to act as different logical elements, perhaps even on a transaction-by-transaction basis.
プロトコルで指定されたすべての要素にすべてのレイヤーが含まれているわけではありません。さらに、SIPで指定された要素は論理要素であり、物理要素ではありません。物理的な実現は、おそらくトランザクションごとにも、異なる論理要素として機能することを選択できます。
The lowest layer of SIP is its syntax and encoding. Its encoding is specified using an augmented Backus-Naur Form grammar (BNF). The complete BNF is specified in Section 25; an overview of a SIP message's structure can be found in Section 7.
SIPの最下層は、その構文とエンコーディングです。そのエンコードは、拡張されたバッカスナウルフォーム文法（BNF）を使用して指定されます。完全なBNFはセクション25で指定されています。 SIPメッセージの構造の概要については、セクション7を参照してください。
The second layer is the transport layer. It defines how a client sends requests and receives responses and how a server receives requests and sends responses over the network. All SIP elements contain a transport layer. The transport layer is described in Section 18.
2番目の層はトランスポート層です。クライアントが要求を送信して応答を受信する方法と、サーバーが要求を受信してネットワーク経由で応答を送信する方法を定義します。すべてのSIPエレメントにはトランスポート層が含まれています。トランスポート層については、セクション18で説明します。
The third layer is the transaction layer. Transactions are a fundamental component of SIP. A transaction is a request sent by a client transaction (using the transport layer) to a server transaction, along with all responses to that request sent from the server transaction back to the client. The transaction layer handles application-layer retransmissions, matching of responses to requests, and application-layer timeouts. Any task that a user agent client (UAC) accomplishes takes place using a series of transactions. Discussion of transactions can be found in Section 17. User agents contain a transaction layer, as do stateful proxies. Stateless proxies do not contain a transaction layer. The transaction layer has a client component (referred to as a client transaction) and a server component (referred to as a server transaction), each of which are represented by a finite state machine that is constructed to process a particular request.
3番目の層はトランザクション層です。トランザクションはSIPの基本的なコンポーネントです。トランザクションは、クライアントトランザクション（トランスポート層を使用）からサーバートランザクションに送信される要求と、サーバートランザクションからクライアントに送信されるその要求に対するすべての応答です。トランザクション層は、アプリケーション層の再送信、要求への応答のマッチング、およびアプリケーション層のタイムアウトを処理します。ユーザーエージェントクライアント（UAC）が実行するタスクは、一連のトランザクションを使用して実行されます。トランザクションの説明はセクション17にあります。ユーザーエージェントは、ステートフルプロキシと同様にトランザクションレイヤーを含みます。ステートレスプロキシにはトランザクションレイヤーが含まれていません。トランザクション層には、クライアントコンポーネント（クライアントトランザクションと呼ばれる）とサーバーコンポーネント（サーバートランザクションと呼ばれる）があり、それぞれが特定の要求を処理するように構築された有限状態マシンによって表されます。
The layer above the transaction layer is called the transaction user (TU). Each of the SIP entities, except the stateless proxy, is a transaction user. When a TU wishes to send a request, it creates a client transaction instance and passes it the request along with the destination IP address, port, and transport to which to send the request. A TU that creates a client transaction can also cancel it. When a client cancels a transaction, it requests that the server stop further processing, revert to the state that existed before the transaction was initiated, and generate a specific error response to that transaction. This is done with a CANCEL request, which constitutes its own transaction, but references the transaction to be cancelled (Section 9).
トランザクション層の上の層は、トランザクションユーザー（TU）と呼ばれます。ステートレスプロキシを除く各SIPエンティティは、トランザクションユーザーです。 TUが要求を送信する場合、クライアントトランザクションインスタンスを作成し、宛先IPアドレス、ポート、および要求の送信先のトランスポートと共に要求を渡します。クライアントトランザクションを作成するTUもキャンセルできます。クライアントがトランザクションをキャンセルすると、サーバーはそれ以上の処理を停止し、トランザクションが開始される前の状態に戻り、そのトランザクションに対する特定のエラー応答を生成するように要求します。これは、独自のトランザクションを構成するCANCELリクエストで行われますが、キャンセルされるトランザクションを参照します（セクション9）。
The SIP elements, that is, user agent clients and servers, stateless and stateful proxies and registrars, contain a core that distinguishes them from each other. Cores, except for the stateless proxy, are transaction users. While the behavior of the UAC and UAS cores depends on the method, there are some common rules for all methods (Section 8). For a UAC, these rules govern the construction of a request; for a UAS, they govern the processing of a request and generating a response. Since registrations play an important role in SIP, a UAS that handles a REGISTER is given the special name registrar. Section 10 describes UAC and UAS core behavior for the REGISTER method. Section 11 describes UAC and UAS core behavior for the OPTIONS method, used for determining the capabilities of a UA.
SIP要素、つまりユーザーエージェントのクライアントとサーバー、ステートレスおよびステートフルのプロキシとレジストラには、それらを相互に区別するコアが含まれています。ステートレスプロキシを除くコアはトランザクションユーザーです。 UACおよびUASコアの動作はメソッドに依存しますが、すべてのメソッドに共通のルールがいくつかあります（セクション8）。 UACの場合、これらのルールはリクエストの構成を管理します。 UASの場合、要求の処理と応答の生成を管理します。登録はSIPで重要な役割を果たすため、REGISTERを処理するUASには、特別な名前のレジストラが与えられます。セクション10では、REGISTERメソッドのUACおよびUASコアの動作について説明します。セクション11では、UAの機能を決定するために使用される、OPTIONSメソッドのUACおよびUASコアの動作について説明します。
Certain other requests are sent within a dialog. A dialog is a peer-to-peer SIP relationship between two user agents that persists for some time. The dialog facilitates sequencing of messages and proper routing of requests between the user agents. The INVITE method is the only way defined in this specification to establish a dialog. When a UAC sends a request that is within the context of a dialog, it follows the common UAC rules as discussed in Section 8 but also the rules for mid-dialog requests. Section 12 discusses dialogs and presents the procedures for their construction and maintenance, in addition to construction of requests within a dialog.
他の特定のリクエストはダイアログ内で送信されます。ダイアログは、2つのユーザーエージェント間のピアツーピアSIP関係であり、しばらくの間持続します。ダイアログは、メッセージのシーケンスとユーザーエージェント間の要求の適切なルーティングを容易にします。 INVITEメソッドは、ダイアログを確立するためにこの仕様で定義されている唯一の方法です。 UACがダイアログのコンテキスト内にある要求を送信する場合、UACはセクション8で説明した一般的なUACルールに従うだけでなく、ダイアログ中の要求のルールにも従います。セクション12では、ダイアログについて説明し、ダイアログ内でのリクエストの構築に加えて、ダイアログの構築と保守の手順を示します。
The most important method in SIP is the INVITE method, which is used to establish a session between participants. A session is a collection of participants, and streams of media between them, for the purposes of communication. Section 13 discusses how sessions are initiated, resulting in one or more SIP dialogs. Section 14 discusses how characteristics of that session are modified through the use of an INVITE request within a dialog. Finally, section 15 discusses how a session is terminated.
SIPで最も重要な方法はINVITEメソッドです。これは、参加者間のセッションを確立するために使用されます。セッションとは、コミュニケーションの目的で、参加者の集まり、およびそれらの間のメディアのストリームです。セクション13では、セッションがどのように開始され、1つ以上のSIPダイアログが表示されるかについて説明します。セクション14では、ダイアログ内のINVITEリクエストを使用して、そのセッションの特性がどのように変更されるかについて説明します。最後に、セクション15では、セッションの終了方法について説明します。
The procedures of Sections 8, 10, 11, 12, 13, 14, and 15 deal entirely with the UA core (Section 9 describes cancellation, which applies to both UA core and proxy core). Section 16 discusses the proxy element, which facilitates routing of messages between user agents.
セクション8、10、11、12、13、14、および15の手順は、UAコアを完全に扱います（セクション9は、UAコアとプロキシコアの両方に適用されるキャンセルについて説明しています）。セクション16では、ユーザーエージェント間のメッセージのルーティングを容易にするプロキシ要素について説明します。
6 Definitions
6定義
The following terms have special significance for SIP.
次の用語は、SIPにとって特別な意味を持っています。
Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI that points to a domain with a location service that can map the URI to another URI where the user might be available. Typically, the location service is populated through registrations. An AOR is frequently thought of as the "public address" of the user.
レコードのアドレス：レコードのアドレス（AOR）は、ユーザーが利用可能な別のURIにURIをマップできるロケーションサービスのあるドメインを指すSIPまたはSIPS URIです。通常、位置情報サービスは登録を通じて入力されます。 AORは、ユーザーの「パブリックアドレス」と見なされることがよくあります。
Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a logical entity that receives a request and processes it as a user agent server (UAS). In order to determine how the request should be answered, it acts as a user agent client (UAC) and generates requests. Unlike a proxy server, it maintains dialog state and must participate in all requests sent on the dialogs it has established. Since it is a concatenation of a UAC and UAS, no explicit definitions are needed for its behavior.
バックツーバックユーザーエージェント：バックツーバックユーザーエージェント（B2BUA）は、要求を受信してユーザーエージェントサーバー（UAS）として処理する論理エンティティです。要求への応答方法を決定するために、ユーザーエージェントクライアント（UAC）として機能し、要求を生成します。プロキシサーバーとは異なり、ダイアログサーバーの状態を維持し、確立したダイアログで送信されるすべての要求に参加する必要があります。 UACとUASを連結したものであるため、その動作に明示的な定義は必要ありません。
Call: A call is an informal term that refers to some communication between peers, generally set up for the purposes of a multimedia conversation.
通話：通話は、ピア間の何らかの通信を指す非公式な用語であり、通常はマルチメディア会話の目的で設定されます。
Call Leg: Another name for a dialog [31]; no longer used in this specification.
Call Leg：ダイアログの別名[31];この仕様では使用されなくなりました。
Call Stateful: A proxy is call stateful if it retains state for a dialog from the initiating INVITE to the terminating BYE request. A call stateful proxy is always transaction stateful, but the converse is not necessarily true.
Call Stateful：プロキシは、開始INVITEから終了BYE要求までのダイアログの状態を保持している場合、コールステートフルです。コールステートフルプロキシは常にトランザクションステートフルですが、その逆は必ずしも当てはまりません。
Client: A client is any network element that sends SIP requests and receives SIP responses. Clients may or may not interact directly with a human user. User agent clients and proxies are clients.
クライアント：クライアントは、SIP要求を送信し、SIP応答を受信するネットワーク要素です。クライアントは、人間のユーザーと直接対話する場合と対話しない場合があります。ユーザーエージェントクライアントとプロキシはクライアントです。
Conference: A multimedia session (see below) that contains multiple participants.
会議：複数の参加者を含むマルチメディアセッション（下記参照）。
Core: Core designates the functions specific to a particular type of SIP entity, i.e., specific to either a stateful or stateless proxy, a user agent or registrar. All cores, except those for the stateless proxy, are transaction users.
コア：コアは、特定のタイプのSIPエンティティに固有の機能、つまりステートフルまたはステートレスプロキシ、ユーザーエージェント、またはレジストラに固有の機能を指定します。ステートレスプロキシを除くすべてのコアはトランザクションユーザーです。
Dialog: A dialog is a peer-to-peer SIP relationship between two UAs that persists for some time. A dialog is established by SIP messages, such as a 2xx response to an INVITE request. A dialog is identified by a call identifier, local tag, and a remote tag. A dialog was formerly known as a call leg in RFC 2543.
ダイアログ：ダイアログは、しばらくの間持続する2つのUA間のピアツーピアSIP関係です。ダイアログは、INVITE要求に対する2xx応答などのSIPメッセージによって確立されます。ダイアログは、呼び出し識別子、ローカルタグ、およびリモートタグによって識別されます。ダイアログは、以前はRFC 2543ではコールレッグと呼ばれていました。
Downstream: A direction of message forwarding within a transaction that refers to the direction that requests flow from the user agent client to user agent server.
ダウンストリーム：トランザクション内のメッセージ転送の方向。ユーザーエージェントクライアントからユーザーエージェントサーバーへの要求フローの方向を指します。
Final Response: A response that terminates a SIP transaction, as opposed to a provisional response that does not. All 2xx, 3xx, 4xx, 5xx and 6xx responses are final.
最終応答：SIPトランザクションを終了する応答であり、暫定応答は終了しません。 2xx、3xx、4xx、5xx、6xxの応答はすべて最終的なものです。
Header: A header is a component of a SIP message that conveys information about the message. It is structured as a sequence of header fields.
ヘッダー：ヘッダーは、メッセージに関する情報を伝えるSIPメッセージのコンポーネントです。ヘッダーフィールドのシーケンスとして構成されます。
Header Field: A header field is a component of the SIP message header. A header field can appear as one or more header field rows. Header field rows consist of a header field name and zero or more header field values. Multiple header field values on a given header field row are separated by commas. Some header fields can only have a single header field value, and as a result, always appear as a single header field row.
ヘッダーフィールド：ヘッダーフィールドは、SIPメッセージヘッダーのコンポーネントです。ヘッダーフィールドは、1つ以上のヘッダーフィールド行として表示できます。ヘッダーフィールド行は、ヘッダーフィールド名と0個以上のヘッダーフィールド値で構成されます。特定のヘッダーフィールド行の複数のヘッダーフィールド値は、コンマで区切られます。一部のヘッダーフィールドは、単一のヘッダーフィールド値しか持てないため、常に単一のヘッダーフィールド行として表示されます。
Header Field Value: A header field value is a single value; a header field consists of zero or more header field values.
ヘッダーフィールド値：ヘッダーフィールド値は単一の値です。ヘッダーフィールドは、0個以上のヘッダーフィールド値で構成されます。
Home Domain: The domain providing service to a SIP user. Typically, this is the domain present in the URI in the address-of-record of a registration.
ホームドメイン：SIPユーザーにサービスを提供するドメイン。通常、これは、登録のレコードのアドレスのURIに存在するドメインです。
Informational Response: Same as a provisional response.
情報応答：暫定応答と同じです。
Initiator, Calling Party, Caller: The party initiating a session (and dialog) with an INVITE request. A caller retains this role from the time it sends the initial INVITE that established a dialog until the termination of that dialog.
開始者、発呼者、発呼者：INVITE要求でセッション（およびダイアログ）を開始する者。呼び出し元は、ダイアログを確立した最初のINVITEを送信してから、そのダイアログが終了するまで、この役割を保持します。
Invitation: An INVITE request.
招待：INVITEリクエスト。
Invitee, Invited User, Called Party, Callee: The party that receives an INVITE request for the purpose of establishing a new session. A callee retains this role from the time it receives the INVITE until the termination of the dialog established by that INVITE.
招待者、招待されたユーザー、着信者、着信者：新しいセッションを確立する目的でINVITE要求を受信する者。呼び出し先は、INVITEを受け取ったときから、そのINVITEによって確立されたダイアログが終了するまで、この役割を保持します。
Location Service: A location service is used by a SIP redirect or proxy server to obtain information about a callee's possible location(s). It contains a list of bindings of address-of-record keys to zero or more contact addresses. The bindings can be created and removed in many ways; this specification defines a REGISTER method that updates the bindings.
位置情報サービス：位置情報サービスは、SIPリダイレクトまたはプロキシサーバーによって使用され、呼び出し先の可能な位置に関する情報を取得します。これには、ゼロ以上の連絡先アドレスへのレコードのアドレスキーのバインディングのリストが含まれています。バインディングはさまざまな方法で作成および削除できます。この仕様では、バインディングを更新するREGISTERメソッドを定義しています。
Loop: A request that arrives at a proxy, is forwarded, and later arrives back at the same proxy. When it arrives the second time, its Request-URI is identical to the first time, and other header fields that affect proxy operation are unchanged, so that the proxy would make the same processing decision on the request it made the first time. Looped requests are errors, and the procedures for detecting them and handling them are described by the protocol.
ループ：プロキシに到着し、転送されて、後で同じプロキシに戻ってくる要求。 2回目に到着したとき、そのRequest-URIは1回目と同じであり、プロキシ操作に影響を与える他のヘッダーフィールドは変更されていないため、プロキシは最初に作成したリクエストに対して同じ処理決定を行います。ループした要求はエラーであり、それらを検出して処理する手順はプロトコルで説明されています。
Loose Routing: A proxy is said to be loose routing if it follows the procedures defined in this specification for processing of the Route header field. These procedures separate the destination of the request (present in the Request-URI) from the set of proxies that need to be visited along the way (present in the Route header field). A proxy compliant to these mechanisms is also known as a loose router.
ルーズルーティング：この仕様で定義されているルートヘッダーフィールドの処理手順に従うプロキシは、ルーズルーティングと呼ばれます。これらの手順は、要求の宛先（Request-URIに存在）を途中で訪問する必要がある一連のプロキシ（Routeヘッダーフィールドに存在）から分離します。これらのメカニズムに準拠したプロキシは、ルーズルーターとも呼ばれます。
Message: Data sent between SIP elements as part of the protocol. SIP messages are either requests or responses.
メッセージ：プロトコルの一部としてSIPエレメント間で送信されるデータ。 SIPメッセージは要求または応答のいずれかです。
Method: The method is the primary function that a request is meant to invoke on a server. The method is carried in the request message itself. Example methods are INVITE and BYE.
メソッド：メソッドは、リクエストがサーバー上で呼び出すことを目的とする主要な機能です。このメソッドは、リクエストメッセージ自体に含まれています。メソッドの例は、INVITEとBYEです。
Outbound Proxy: A proxy that receives requests from a client, even though it may not be the server resolved by the Request-URI. Typically, a UA is manually configured with an outbound proxy, or can learn about one through auto-configuration protocols.
Outbound Proxy：Request-URIによって解決されたサーバーではない場合でも、クライアントから要求を受信するプロキシ。通常、UAはアウトバウンドプロキシを使用して手動で構成するか、自動構成プロトコルを通じてUAについて学習できます。
Parallel Search: In a parallel search, a proxy issues several requests to possible user locations upon receiving an incoming request. Rather than issuing one request and then waiting for the final response before issuing the next request as in a sequential search, a parallel search issues requests without waiting for the result of previous requests.
並列検索：並列検索では、プロキシは、着信要求を受信すると、可能なユーザーの場所にいくつかの要求を発行します。順次検索のように、1つの要求を発行してから次の要求を発行する前に最終応答を待つのではなく、並列検索は、前の要求の結果を待たずに要求を発行します。
Provisional Response: A response used by the server to indicate progress, but that does not terminate a SIP transaction. 1xx responses are provisional, other responses are considered final.
暫定応答：サーバーが進行状況を示すために使用する応答ですが、SIPトランザクションは終了しません。 1xx応答は暫定的なものであり、他の応答は最終的なものと見なされます。
Proxy, Proxy Server: An intermediary entity that acts as both a server and a client for the purpose of making requests on behalf of other clients. A proxy server primarily plays the role of routing, which means its job is to ensure that a request is sent to another entity "closer" to the targeted user. Proxies are also useful for enforcing policy (for example, making sure a user is allowed to make a call). A proxy interprets, and, if necessary, rewrites specific parts of a request message before forwarding it.
プロキシ、プロキシサーバー：他のクライアントに代わってリクエストを行う目的でサーバーとクライアントの両方として機能する中間エンティティ。プロキシサーバーは主にルーティングの役割を果たします。つまり、その役割は、ターゲットユーザーに「より近い」別のエンティティにリクエストが送信されるようにすることです。プロキシは、ポリシーを適用する場合にも役立ちます（たとえば、ユーザーが電話をかけることができるようにするなど）。プロキシは、要求メッセージを解釈して、必要に応じて、転送する前に要求メッセージの特定の部分を書き換えます。
Recursion: A client recurses on a 3xx response when it generates a new request to one or more of the URIs in the Contact header field in the response.
再帰：クライアントは、応答のContactヘッダーフィールドにある1つ以上のURIへの新しい要求を生成すると、3xx応答で再帰します。
Redirect Server: A redirect server is a user agent server that generates 3xx responses to requests it receives, directing the client to contact an alternate set of URIs.
リダイレクトサーバー：リダイレクトサーバーはユーザーエージェントサーバーであり、受信した要求に対して3xx応答を生成し、代替のURIセットに接続するようクライアントに指示します。
Registrar: A registrar is a server that accepts REGISTER requests and places the information it receives in those requests into the location service for the domain it handles.
レジストラ：レジストラは、REGISTER要求を受け入れ、それらの要求で受け取った情報を、処理するドメインのロケーションサービスに配置するサーバーです。
Regular Transaction: A regular transaction is any transaction with a method other than INVITE, ACK, or CANCEL.
通常のトランザクション：通常のトランザクションは、INVITE、ACK、またはCANCEL以外の方法によるトランザクションです。
Request: A SIP message sent from a client to a server, for the purpose of invoking a particular operation.
要求：特定の操作を呼び出す目的で、クライアントからサーバーに送信されるSIPメッセージ。
Response: A SIP message sent from a server to a client, for indicating the status of a request sent from the client to the server.
応答：クライアントからサーバーに送信されたリクエストのステータスを示す、サーバーからクライアントに送信されたSIPメッセージ。
Ringback: Ringback is the signaling tone produced by the calling party's application indicating that a called party is being alerted (ringing).
リングバック：リングバックは、発呼者のアプリケーションによって生成されるシグナリングトーンであり、着呼側に警告（呼び出し）が行われていることを示します。
Route Set: A route set is a collection of ordered SIP or SIPS URI which represent a list of proxies that must be traversed when sending a particular request. A route set can be learned, through headers like Record-Route, or it can be configured.
ルートセット：ルートセットは、特定のリクエストを送信するときに通過する必要があるプロキシのリストを表す、順序付けられたSIPまたはSIPS URIのコレクションです。ルートセットはRecord-Routeなどのヘッダーを介して学習することも、構成することもできます。
Server: A server is a network element that receives requests in order to service them and sends back responses to those requests. Examples of servers are proxies, user agent servers, redirect servers, and registrars.
サーバー：サーバーは、サービスを提供するために要求を受信し、それらの要求に応答を返すネットワーク要素です。サーバーの例は、プロキシ、ユーザーエージェントサーバー、リダイレクトサーバー、およびレジストラです。
Sequential Search: In a sequential search, a proxy server attempts each contact address in sequence, proceeding to the next one only after the previous has generated a final response. A 2xx or 6xx class final response always terminates a sequential search.
順次検索：順次検索では、プロキシサーバーは各連絡先アドレスを順番に試行し、前の連絡先が最終応答を生成した後でのみ次の連絡先に進みます。 2xxまたは6xxクラスの最終応答は、常に順次検索を終了します。
Session: From the SDP specification: "A multimedia session is a set of multimedia senders and receivers and the data streams flowing from senders to receivers. A multimedia conference is an example of a multimedia session." (RFC 2327 [1]) (A session as defined for SDP can comprise one or more RTP sessions.) As defined, a callee can be invited several times, by different calls, to the same session. If SDP is used, a session is defined by the concatenation of the SDP user name, session id, network type, address type, and address elements in the origin field.
セッション：SDP仕様から：「マルチメディアセッションは、マルチメディアの送信者と受信者のセット、および送信者から受信者に流れるデータストリームです。マルチメディア会議は、マルチメディアセッションの例です。」 （RFC 2327 [1]）（SDPに定義されているセッションは、1つ以上のRTPセッションで構成できます。）定義されているように、呼び出し先は、異なる呼び出しによって、同じセッションに何度も招待できます。 SDPを使用する場合、セッションは、SDPユーザー名、セッションID、ネットワークタイプ、アドレスタイプ、およびoriginフィールドのアドレス要素の連結によって定義されます。
SIP Transaction: A SIP transaction occurs between a client and a server and comprises all messages from the first request sent from the client to the server up to a final (non-1xx) response sent from the server to the client. If the request is INVITE and the final response is a non-2xx, the transaction also includes an ACK to the response. The ACK for a 2xx response to an INVITE request is a separate transaction.
SIPトランザクション：SIPトランザクションはクライアントとサーバー間で発生し、クライアントからサーバーに送信された最初の要求から、サーバーからクライアントに送信された最後の（非1xx）応答までのすべてのメッセージで構成されます。要求がINVITEで、最終応答が2xx以外の場合、トランザクションには応答へのACKも含まれます。 INVITE要求に対する2xx応答のACKは、別のトランザクションです。
Spiral: A spiral is a SIP request that is routed to a proxy, forwarded onwards, and arrives once again at that proxy, but this time differs in a way that will result in a different processing decision than the original request. Typically, this means that the request's Request-URI differs from its previous arrival. A spiral is not an error condition, unlike a loop. A typical cause for this is call forwarding. A user calls joe@example.com. The example.com proxy forwards it to Joe's PC, which in turn, forwards it to bob@example.com. This request is proxied back to the example.com proxy. However, this is not a loop. Since the request is targeted at a different user, it is considered a spiral, and is a valid condition.
スパイラル：スパイラルは、プロキシにルーティングされて転送され、再びそのプロキシに到着するSIPリクエストですが、今回は、元のリクエストとは異なる処理の決定が行われるという点で異なります。通常、これはリクエストのRequest-URIが以前の到着と異なることを意味します。ループとは異なり、スパイラルはエラー状態ではありません。これの典型的な原因は自動転送です。ユーザーがjoe@example.comに電話をかけます。 example.comプロキシはそれをJoeのPCに転送し、次にそれがbob@example.comに転送されます。このリクエストはexample.comプロキシにプロキシされます。ただし、これはループではありません。リクエストは別のユーザーを対象としているため、スパイラルと見なされ、有効な条件です。
Stateful Proxy: A logical entity that maintains the client and server transaction state machines defined by this specification during the processing of a request, also known as a transaction stateful proxy. The behavior of a stateful proxy is further defined in Section 16. A (transaction) stateful proxy is not the same as a call stateful proxy.
ステートフルプロキシ：要求の処理中に、この仕様で定義されたクライアントおよびサーバーのトランザクションステートマシンを維持する論理エンティティ。トランザクションステートフルプロキシとも呼ばれます。ステートフルプロキシの動作は、セクション16でさらに定義されます。（トランザクション）ステートフルプロキシは、コールステートフルプロキシと同じではありません。
Stateless Proxy: A logical entity that does not maintain the client or server transaction state machines defined in this specification when it processes requests. A stateless proxy forwards every request it receives downstream and every response it receives upstream.
ステートレスプロキシ：要求を処理するときに、この仕様で定義されているクライアントまたはサーバーのトランザクションステートマシンを維持しない論理エンティティ。ステートレスプロキシは、ダウンストリームで受信したすべての要求と、アップストリームで受信したすべての応答を転送します。
Strict Routing: A proxy is said to be strict routing if it follows the Route processing rules of RFC 2543 and many prior work in progress versions of this RFC. That rule caused proxies to destroy the contents of the Request-URI when a Route header field was present. Strict routing behavior is not used in this specification, in favor of a loose routing behavior. Proxies that perform strict routing are also known as strict routers.
厳密なルーティング：RFC 2543のルート処理ルールとこのRFCの以前の多くの作業中のバージョンに準拠しているプロキシは、厳密なルーティングと呼ばれます。そのルールにより、Routeヘッダーフィールドが存在する場合に、プロキシがRequest-URIのコンテンツを破棄していました。厳密なルーティング動作はこの仕様では使用されず、ルーズなルーティング動作が優先されます。厳密なルーティングを実行するプロキシは、厳密なルーターとも呼ばれます。
Target Refresh Request: A target refresh request sent within a dialog is defined as a request that can modify the remote target of the dialog.
ターゲット更新要求：ダイアログ内で送信されるターゲット更新要求は、ダイアログのリモートターゲットを変更できる要求として定義されます。
Transaction User (TU): The layer of protocol processing that resides above the transaction layer. Transaction users include the UAC core, UAS core, and proxy core.
トランザクションユーザー（TU）：トランザクション層の上にあるプロトコル処理の層。トランザクションユーザーには、UACコア、UASコア、およびプロキシコアが含まれます。
Upstream: A direction of message forwarding within a transaction that refers to the direction that responses flow from the user agent server back to the user agent client.
アップストリーム：トランザクション内のメッセージ転送の方向。ユーザーエージェントサーバーからユーザーエージェントクライアントに応答が流れる方向を指します。
URL-encoded: A character string encoded according to RFC 2396, Section 2.4 [5].
URLエンコード：RFC 2396、セクション2.4 [5]に従ってエンコードされた文字列。
User Agent Client (UAC): A user agent client is a logical entity that creates a new request, and then uses the client transaction state machinery to send it. The role of UAC lasts only for the duration of that transaction. In other words, if a piece of software initiates a request, it acts as a UAC for the duration of that transaction. If it receives a request later, it assumes the role of a user agent server for the processing of that transaction.
ユーザーエージェントクライアント（UAC）：ユーザーエージェントクライアントは、新しい要求を作成し、クライアントトランザクション状態機構を使用してそれを送信する論理エンティティです。 UACの役割は、そのトランザクションの間だけ続きます。つまり、ソフトウェアがリクエストを開始した場合、そのトランザクションの間、ソフトウェアはUACとして機能します。後で要求を受信した場合は、そのトランザクションを処理するためのユーザーエージェントサーバーの役割を担います。
UAC Core: The set of processing functions required of a UAC that reside above the transaction and transport layers.
UACコア：トランザクション層とトランスポート層の上にあるUACに必要な一連の処理機能。
User Agent Server (UAS): A user agent server is a logical entity that generates a response to a SIP request. The response accepts, rejects, or redirects the request. This role lasts only for the duration of that transaction. In other words, if a piece of software responds to a request, it acts as a UAS for the duration of that transaction. If it generates a request later, it assumes the role of a user agent client for the processing of that transaction.
ユーザーエージェントサーバー（UAS）：ユーザーエージェントサーバーは、SIP要求に対する応答を生成する論理エンティティです。応答は、要求を受け入れる、拒否する、またはリダイレクトします。この役割は、そのトランザクションの間だけ持続します。つまり、ソフトウェアが要求に応答した場合、そのトランザクションの間、そのソフトウェアはUASとして機能します。後で要求を生成する場合、そのトランザクションの処理のためのユーザーエージェントクライアントの役割を担います。
UAS Core: The set of processing functions required at a UAS that resides above the transaction and transport layers.
UASコア：トランザクション層とトランスポート層の上にあるUASで必要な一連の処理機能。
User Agent (UA): A logical entity that can act as both a user agent client and user agent server.
ユーザーエージェント（UA）：ユーザーエージェントクライアントとユーザーエージェントサーバーの両方として機能できる論理エンティティ。
The role of UAC and UAS, as well as proxy and redirect servers, are defined on a transaction-by-transaction basis. For example, the user agent initiating a call acts as a UAC when sending the initial INVITE request and as a UAS when receiving a BYE request from the callee. Similarly, the same software can act as a proxy server for one request and as a redirect server for the next request.
UACとUAS、およびプロキシサーバーとリダイレクトサーバーの役割は、トランザクションごとに定義されます。たとえば、呼び出しを開始するユーザーエージェントは、最初のINVITE要求を送信するときはUACとして機能し、呼び出し先からBYE要求を受信するときはUASとして機能します。同様に、同じソフトウェアが1つの要求のプロキシサーバーとして機能し、次の要求のリダイレクトサーバーとして機能します。
Proxy, location, and registrar servers defined above are logical entities; implementations MAY combine them into a single application.
上記で定義されたプロキシ、ロケーション、およびレジストラサーバーは論理エンティティです。実装はそれらを単一のアプリケーションに結合してもよい（MAY）。
7 SIP Messages
7 SIPメッセージ
SIP is a text-based protocol and uses the UTF-8 charset (RFC 2279 [7]).
SIPはテキストベースのプロトコルであり、UTF-8文字セット（RFC 2279 [7]）を使用します。
A SIP message is either a request from a client to a server, or a response from a server to a client.
SIPメッセージは、クライアントからサーバーへの要求、またはサーバーからクライアントへの応答です。
Both Request (section 7.1) and Response (section 7.2) messages use the basic format of RFC 2822 [3], even though the syntax differs in character set and syntax specifics. (SIP allows header fields that would not be valid RFC 2822 header fields, for example.) Both types of messages consist of a start-line, one or more header fields, an empty line indicating the end of the header fields, and an optional message-body.
要求（セクション7.1）と応答（セクション7.2）の両方のメッセージは、RFC 2822 [3]の基本形式を使用しますが、構文は文字セットと構文の詳細が異なります。 （たとえば、SIPは、有効なRFC 2822ヘッダーフィールドではないヘッダーフィールドを許可します。）両方のタイプのメッセージは、開始行、1つ以上のヘッダーフィールド、ヘッダーフィールドの終わりを示す空の行、およびオプションのオプションで構成されます。メッセージ本文。
generic-message = start-line *message-header CRLF [ message-body ] start-line = Request-Line / Status-Line
generic-message = start-line * message-header CRLF [message-body] start-line = Request-Line / Status-Line
The start-line, each message-header line, and the empty line MUST be terminated by a carriage-return line-feed sequence (CRLF). Note that the empty line MUST be present even if the message-body is not.
開始行、各メッセージヘッダー行、および空の行は、復帰改行シーケンス（CRLF）で終了する必要があります。メッセージ本文がない場合でも、空の行が存在する必要があることに注意してください。
Except for the above difference in character sets, much of SIP's message and header field syntax is identical to HTTP/1.1. Rather than repeating the syntax and semantics here, we use [HX.Y] to refer to Section X.Y of the current HTTP/1.1 specification (RFC 2616 [8]).
上記の文字セットの違いを除いて、SIPのメッセージとヘッダーフィールドの構文の多くはHTTP / 1.1と同じです。ここでは構文とセマンティクスを繰り返すのではなく、[HX.Y]を使用して、現在のHTTP / 1.1仕様（RFC 2616 [8]）のセクションX.Yを参照しています。
However, SIP is not an extension of HTTP.
ただし、SIPはHTTPの拡張ではありません。
SIP requests are distinguished by having a Request-Line for a start-line. A Request-Line contains a method name, a Request-URI, and the protocol version separated by a single space (SP) character.
SIPリクエストは、スタートライン用のリクエストラインを持つことで区別されます。 Request-Lineには、単一のスペース（SP）文字で区切られたメソッド名、Request-URI、およびプロトコルバージョンが含まれています。
The Request-Line ends with CRLF. No CR or LF are allowed except in the end-of-line CRLF sequence. No linear whitespace (LWS) is allowed in any of the elements.
Request-LineはCRLFで終わります。行末CRLFシーケンスを除いて、CRまたはLFは許可されません。どの要素でも線形空白（LWS）は許可されていません。
Request-Line = Method SP Request-URI SP SIP-Version CRLF
Request-Line =メソッドSP Request-URI SP SIP-Version CRLF
Method: This specification defines six methods: REGISTER for registering contact information, INVITE, ACK, and CANCEL for setting up sessions, BYE for terminating sessions, and OPTIONS for querying servers about their capabilities. SIP extensions, documented in standards track RFCs, may define additional methods.
メソッド：この仕様では、連絡先情報を登録するためのREGISTER、セッションをセットアップするためのINVITE、ACK、およびCANCEL、セッションを終了するためのBYE、およびそれらの機能についてサーバーに照会するためのOPTIONSの6つのメソッドを定義しています。標準追跡RFCに文書化されたSIP拡張は、追加のメソッドを定義する場合があります。
Request-URI: The Request-URI is a SIP or SIPS URI as described in Section 19.1 or a general URI (RFC 2396 [5]). It indicates the user or service to which this request is being addressed. The Request-URI MUST NOT contain unescaped spaces or control characters and MUST NOT be enclosed in "<>".
リクエストURI：リクエストURIは、セクション19.1で説明されているSIPまたはSIPS URIまたは一般的なURI（RFC 2396 [5]）です。これは、この要求の宛先であるユーザーまたはサービスを示します。 Request-URIには、エスケープされていないスペースや制御文字を含めることはできません。また、「<>」で囲むことはできません。
SIP elements MAY support Request-URIs with schemes other than "sip" and "sips", for example the "tel" URI scheme of RFC 2806 [9]. SIP elements MAY translate non-SIP URIs using any mechanism at their disposal, resulting in SIP URI, SIPS URI, or some other scheme.
SIP要素は、RFC 2806の「tel」URIスキームなど、「sip」および「sips」以外のスキームを使用したRequest-URIをサポートする場合があります[9]。 SIP要素は、任意のメカニズムを使用して非SIP URIを変換できます（MAY）。その結果、SIP URI、SIPS URI、またはその他のスキームが生成されます。
SIP-Version: Both request and response messages include the version of SIP in use, and follow [H3.1] (with HTTP replaced by SIP, and HTTP/1.1 replaced by SIP/2.0) regarding version ordering, compliance requirements, and upgrading of version numbers. To be compliant with this specification, applications sending SIP messages MUST include a SIP-Version of "SIP/2.0". The SIP-Version string is case-insensitive, but implementations MUST send upper-case.
SIPバージョン：要求メッセージと応答メッセージの両方に、使用中のSIPのバージョンが含まれており、バージョンの順序、コンプライアンス要件、およびアップグレードに関して[H3.1]（HTTPがSIPに、HTTP / 1.1がSIP / 2.0に置き換えられています）に従います。バージョン番号の。この仕様に準拠するには、SIPメッセージを送信するアプリケーションに「SIP / 2.0」のSIPバージョンを含める必要があります。 SIP-Version文字列は大文字と小文字を区別しませんが、実装は大文字を送信する必要があります。
Unlike HTTP/1.1, SIP treats the version number as a literal string. In practice, this should make no difference.
HTTP / 1.1とは異なり、SIPはバージョン番号をリテラル文字列として扱います。実際には、これで違いはありません。
SIP responses are distinguished from requests by having a Status-Line as their start-line. A Status-Line consists of the protocol version followed by a numeric Status-Code and its associated textual phrase, with each element separated by a single SP character.
SIP応答は、ステータス行を開始行として持つことにより、要求と区別されます。 Status-Lineは、プロトコルバージョンと、それに続く数値のStatus-Codeおよび関連するテキストフレーズで構成され、各要素は単一のSP文字で区切られています。
No CR or LF is allowed except in the final CRLF sequence.
最後のCRLFシーケンスを除いて、CRまたはLFは許可されません。
Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF
ステータス行= SIPバージョンSPステータスコードSP理由フレーズCRLF
The Status-Code is a 3-digit integer result code that indicates the outcome of an attempt to understand and satisfy a request. The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use by automata, whereas the Reason-Phrase is intended for the human user. A client is not required to examine or display the Reason-Phrase.
Status-Codeは3桁の整数の結果コードであり、要求を理解して満足する試みの結果を示します。 Reason-Phraseは、Status-Codeの短いテキストによる説明を提供することを目的としています。 Status-Codeはオートマトンによる使用を目的としていますが、Reason-Phraseは人間のユーザーを対象としています。クライアントは、Reason-Phraseを調べたり表示したりする必要はありません。
While this specification suggests specific wording for the reason phrase, implementations MAY choose other text, for example, in the language indicated in the Accept-Language header field of the request.
この仕様は理由句の特定の表現を提案していますが、実装は、たとえば、リクエストのAccept-Languageヘッダーフィールドに示されている言語で、他のテキストを選択する場合があります。
The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. For this reason, any response with a status code between 100 and 199 is referred to as a "1xx response", any response with a status code between 200 and 299 as a "2xx response", and so on. SIP/2.0 allows six values for the first digit:
ステータスコードの最初の桁は、応答のクラスを定義します。下2桁には、分類の役割はありません。このため、ステータスコードが100から199のレスポンスは「1xxレスポンス」、ステータスコードが200から299のレスポンスは「2xxレスポンス」と呼ばれます。 SIP / 2.0では、最初の桁に6つの値を使用できます。
1xx: Provisional -- request received, continuing to process the request;
1xx：暫定-要求を受け取り、要求の処理を続行します。
2xx: Success -- the action was successfully received, understood, and accepted;
2xx：成功-アクションは正常に受け取られ、理解され、受け入れられました。
3xx: Redirection -- further action needs to be taken in order to complete the request;
3xx：リダイレクト-リクエストを完了するには、さらにアクションを実行する必要があります。
4xx: Client Error -- the request contains bad syntax or cannot be fulfilled at this server;
4xx：クライアントエラー-リクエストに不正な構文が含まれているか、このサーバーで実行できません。
5xx: Server Error -- the server failed to fulfill an apparently valid request;
5xx：サーバーエラー-サーバーは明らかに有効な要求を実行できませんでした。
6xx: Global Failure -- the request cannot be fulfilled at any server.
6xx：グローバルエラー-リクエストはどのサーバーでも実行できません。
Section 21 defines these classes and describes the individual codes.
セクション21では、これらのクラスを定義し、個々のコードについて説明します。
SIP header fields are similar to HTTP header fields in both syntax and semantics. In particular, SIP header fields follow the [H4.2] definitions of syntax for the message-header and the rules for extending header fields over multiple lines. However, the latter is specified in HTTP with implicit whitespace and folding. This specification conforms to RFC 2234 [10] and uses only explicit whitespace and folding as an integral part of the grammar.
SIPヘッダーフィールドは、構文とセマンティクスの両方でHTTPヘッダーフィールドに似ています。特に、SIPヘッダーフィールドは、メッセージヘッダーの構文の[H4.2]定義と、ヘッダーフィールドを複数行に拡張するためのルールに従います。ただし、後者は暗黙の空白と折りたたみを使用してHTTPで指定されます。この仕様はRFC 2234 [10]に準拠し、文法の不可欠な部分として明示的な空白と折りたたみのみを使用します。
[H4.2] also specifies that multiple header fields of the same field name whose value is a comma-separated list can be combined into one header field. That applies to SIP as well, but the specific rule is different because of the different grammars. Specifically, any SIP header whose grammar is of the form
[H4.2]は、値がコンマ区切りのリストである同じフィールド名の複数のヘッダーフィールドを1つのヘッダーフィールドに結合できることも指定しています。これはSIPにも適用されますが、文法が異なるため、特定のルールは異なります。具体的には、文法が次の形式のSIPヘッダー
header = "header-name" HCOLON header-value *(COMMA header-value)
header = "header-name" HCOLON header-value *（COMMA header-value）
allows for combining header fields of the same name into a comma-separated list. The Contact header field allows a comma-separated list unless the header field value is "*".
同じ名前のヘッダーフィールドをカンマ区切りのリストに組み合わせることができます。 Contactヘッダーフィールドでは、ヘッダーフィールドの値が "*"でない限り、コンマ区切りのリストを使用できます。
Header fields follow the same generic header format as that given in Section 2.2 of RFC 2822 [3]. Each header field consists of a field name followed by a colon (":") and the field value.
ヘッダーフィールドは、RFC 2822 [3]のセクション2.2で指定されているものと同じ一般的なヘッダー形式に従います。各ヘッダーフィールドは、フィールド名とそれに続くコロン（ "："）およびフィールド値で構成されます。
field-name: field-value
フィールド名：フィールド値
The formal grammar for a message-header specified in Section 25 allows for an arbitrary amount of whitespace on either side of the colon; however, implementations should avoid spaces between the field name and the colon and use a single space (SP) between the colon and the field-value.
セクション25で指定されたメッセージヘッダーの正式な文法では、コロンの両側に任意の量の空白を含めることができます。ただし、実装では、フィールド名とコロンの間のスペースを避け、コロンとフィールド値の間に単一のスペース（SP）を使用する必要があります。
Subject: lunch Subject : lunch Subject :lunch Subject: lunch
件名：ランチ件名：ランチ件名：ランチ件名：ランチ
Thus, the above are all valid and equivalent, but the last is the preferred form.
したがって、上記はすべて有効かつ同等ですが、最後の形式が推奨されます。
Header fields can be extended over multiple lines by preceding each extra line with at least one SP or horizontal tab (HT). The line break and the whitespace at the beginning of the next line are treated as a single SP character. Thus, the following are equivalent:
ヘッダーフィールドは、追加の各行の前に少なくとも1つのSPまたは水平タブ（HT）を付けることにより、複数行に拡張できます。改行と次の行の先頭の空白は、単一のSP文字として扱われます。したがって、以下は同等です。
Subject: I know you're there, pick up the phone and talk to me! Subject: I know you're there, pick up the phone and talk to me!
件名：私はあなたがそこにいることを知っています。電話を取り、私に話しかけてください！件名：私はあなたがそこにいることを知っています。電話を取り、私に話しかけてください！
The relative order of header fields with different field names is not significant. However, it is RECOMMENDED that header fields which are needed for proxy processing (Via, Route, Record-Route, Proxy-Require, Max-Forwards, and Proxy-Authorization, for example) appear towards the top of the message to facilitate rapid parsing. The relative order of header field rows with the same field name is important. Multiple header field rows with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list (that is, if follows the grammar defined in Section 7.3). It MUST be possible to combine the multiple header field rows into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The exceptions to this rule are the WWW-Authenticate, Authorization, Proxy-Authenticate, and Proxy-Authorization header fields. Multiple header field rows with these names MAY be present in a message, but since their grammar does not follow the general form listed in Section 7.3, they MUST NOT be combined into a single header field row.
異なるフィールド名を持つヘッダーフィールドの相対的な順序は重要ではありません。ただし、迅速な解析を容易にするために、プロキシ処理に必要なヘッダーフィールド（Via、Route、Record-Route、Proxy-Require、Max-Forwards、およびProxy-Authorizationなど）をメッセージの上部に表示することをお勧めします。同じフィールド名を持つヘッダーフィールド行の相対的な順序は重要です。同じフィールド名を持つ複数のヘッダーフィールド行は、そのヘッダーフィールドのフィールド値全体がコンマ区切りのリストとして定義されている場合（つまり、セクション7.3で定義されている文法に従う場合）にのみメッセージに存在する可能性があります。 。メッセージのセマンティクスを変更せずに、複数のヘッダーフィールド行を1つの「フィールド名：フィールド値」ペアに結合することが可能でなければなりません。後続の各フィールド値を最初のフィールド値にカンマで区切って追加します。このルールの例外は、WWW-Authenticate、Authorization、Proxy-Authenticate、およびProxy-Authorizationヘッダーフィールドです。これらの名前を持つ複数のヘッダーフィールド行がメッセージに存在してもかまいませんが、それらの文法は7.3節にリストされている一般的な形式に従っていないため、それらを単一のヘッダーフィールド行に結合してはなりません。
Implementations MUST be able to process multiple header field rows with the same name in any combination of the single-value-per-line or comma-separated value forms.
実装は、1行あたり1つの値の形式またはコンマ区切りの値の形式の任意の組み合わせで、同じ名前の複数のヘッダーフィールド行を処理できる必要があります。
The following groups of header field rows are valid and equivalent:
次のヘッダーフィールド行のグループは有効であり、同等です。
Route: <sip:alice@atlanta.com>
Subject: Lunch
Route: <sip:bob@biloxi.com>
Route: <sip:carol@chicago.com>
Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>
Route: <sip:carol@chicago.com>
Subject: Lunch
Subject: Lunch
Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>,
<sip:carol@chicago.com>
Each of the following blocks is valid but not equivalent to the others:
次の各ブロックは有効ですが、他のものと同等ではありません。
Route: <sip:alice@atlanta.com>
Route: <sip:bob@biloxi.com>
Route: <sip:carol@chicago.com>
Route: <sip:bob@biloxi.com>
Route: <sip:alice@atlanta.com>
Route: <sip:carol@chicago.com>
Route: <sip:alice@atlanta.com>,<sip:carol@chicago.com>,
<sip:bob@biloxi.com>
The format of a header field-value is defined per header-name. It will always be either an opaque sequence of TEXT-UTF8 octets, or a combination of whitespace, tokens, separators, and quoted strings. Many existing header fields will adhere to the general form of a value followed by a semi-colon separated sequence of parameter-name, parameter-value pairs:
ヘッダーフィールド値の形式は、ヘッダー名ごとに定義されます。常に、TEXT-UTF8オクテットの不透明なシーケンス、または空白、トークン、セパレータ、引用符付き文字列の組み合わせのいずれかになります。多くの既存のヘッダーフィールドは、値の一般的な形式に従い、セミコロンで区切られたパラメーター名とパラメーター値のペアのシーケンスが続きます。
field-name: field-value *(;parameter-name=parameter-value)
Even though an arbitrary number of parameter pairs may be attached to a header field value, any given parameter-name MUST NOT appear more than once.
ヘッダーフィールド値に任意の数のパラメーターペアをアタッチできる場合でも、特定のパラメーター名は2回以上指定してはなりません（MUST NOT）。
When comparing header fields, field names are always case-insensitive. Unless otherwise stated in the definition of a particular header field, field values, parameter names, and parameter values are case-insensitive. Tokens are always case-insensitive. Unless specified otherwise, values expressed as quoted strings are case-sensitive. For example,
ヘッダーフィールドを比較する場合、フィールド名では常に大文字と小文字が区別されません。特定のヘッダーフィールドの定義で特に明記されていない限り、フィールド値、パラメーター名、およびパラメーター値は大文字と小文字が区別されません。トークンは常に大文字と小文字を区別しません。特に明記されていない限り、引用符で囲まれた文字列として表される値は大文字と小文字が区別されます。例えば、
Contact: <sip:alice@atlanta.com>;expires=3600
is equivalent to
に相当
CONTACT: <sip:alice@atlanta.com>;ExPiReS=3600
and
そして
Content-Disposition: session;handling=optional
is equivalent to
に相当
content-disposition: Session;HANDLING=OPTIONAL
The following two header fields are not equivalent:
次の2つのヘッダーフィールドは同等ではありません。
Warning: 370 devnull "Choose a bigger pipe" Warning: 370 devnull "CHOOSE A BIGGER PIPE"
警告：370 devnull "大きいパイプを選択してください"警告：370 devnull "大きいパイプを選択してください"
Some header fields only make sense in requests or responses. These are called request header fields and response header fields, respectively. If a header field appears in a message not matching its category (such as a request header field in a response), it MUST be ignored. Section 20 defines the classification of each header field.
一部のヘッダーフィールドは、リクエストまたはレスポンスでのみ意味があります。これらは、それぞれ要求ヘッダーフィールドと応答ヘッダーフィールドと呼ばれます。ヘッダーフィールドがそのカテゴリに一致しないメッセージに表示される場合（応答の要求ヘッダーフィールドなど）、それは無視されなければなりません（MUST）。セクション20では、各ヘッダーフィールドの分類を定義しています。
SIP provides a mechanism to represent common header field names in an abbreviated form. This may be useful when messages would otherwise become too large to be carried on the transport available to it (exceeding the maximum transmission unit (MTU) when using UDP, for example). These compact forms are defined in Section 20. A compact form MAY be substituted for the longer form of a header field name at any time without changing the semantics of the message. A header field name MAY appear in both long and short forms within the same message. Implementations MUST accept both the long and short forms of each header name.
SIPは、一般的なヘッダーフィールド名を省略形で表すメカニズムを提供します。これは、メッセージが大きくなりすぎて、利用可能なトランスポートで運ぶことができない場合に役立ちます（たとえば、UDPを使用する場合の最大転送単位（MTU）を超えます）。これらのコンパクトフォームはセクション20で定義されています。コンパクトフォームは、メッセージのセマンティクスを変更することなく、いつでもヘッダーフィールド名の長いフォームに置き換えることができます（MAY）。ヘッダーフィールド名は、同じメッセージ内で長い形式と短い形式の両方で表示される場合があります。実装は、各ヘッダー名の長い形式と短い形式の両方を受け入れる必要があります。
Requests, including new requests defined in extensions to this specification, MAY contain message bodies unless otherwise noted. The interpretation of the body depends on the request method.
この仕様の拡張で定義された新しいリクエストを含むリクエストには、特に明記されていない限り、メッセージ本文を含めることができます。本文の解釈は、リクエストメソッドによって異なります。
For response messages, the request method and the response status code determine the type and interpretation of any message body. All responses MAY include a body.
応答メッセージの場合、要求メソッドと応答ステータスコードによって、メッセージ本文のタイプと解釈が決まります。すべての応答に本文が含まれる場合があります。
The Internet media type of the message body MUST be given by the Content-Type header field. If the body has undergone any encoding such as compression, then this MUST be indicated by the Content-Encoding header field; otherwise, Content-Encoding MUST be omitted. If applicable, the character set of the message body is indicated as part of the Content-Type header-field value.
メッセージ本文のインターネットメディアタイプは、Content-Typeヘッダーフィールドで指定する必要があります。ボディが圧縮などのエンコーディングを受けている場合、これはContent-Encodingヘッダーフィールドで示される必要があります。それ以外の場合、Content-Encodingは省略しなければなりません。該当する場合、メッセージ本文の文字セットは、Content-Typeヘッダーフィールド値の一部として示されます。
The "multipart" MIME type defined in RFC 2046 [11] MAY be used within the body of the message. Implementations that send requests containing multipart message bodies MUST send a session description as a non-multipart message body if the remote implementation requests this through an Accept header field that does not contain multipart.
RFC 2046 [11]で定義されている「マルチパート」MIMEタイプは、メッセージの本文内で使用できます。マルチパートメッセージ本文を含む要求を送信する実装は、リモート実装がマルチパートを含まないAcceptヘッダーフィールドを通じてこれを要求する場合、非マルチパートメッセージ本文としてセッションの説明を送信する必要があります。
SIP messages MAY contain binary bodies or body parts. When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined to have a default charset value of "UTF-8".
SIPメッセージには、バイナリボディまたはボディパーツが含まれる場合があります。送信者によって明示的な文字セットパラメータが提供されない場合、「テキスト」タイプのメディアサブタイプは、デフォルトの文字セット値「UTF-8」を持つように定義されます。
The body length in bytes is provided by the Content-Length header field. Section 20.14 describes the necessary contents of this header field in detail.
バイト単位の本文の長さは、Content-Lengthヘッダーフィールドによって提供されます。セクション20.14では、このヘッダーフィールドに必要な内容について詳しく説明しています。
The "chunked" transfer encoding of HTTP/1.1 MUST NOT be used for SIP. (Note: The chunked encoding modifies the body of a message in order to transfer it as a series of chunks, each with its own size indicator.)
HTTP / 1.1の「チャンク」転送エンコーディングは、SIPに使用してはなりません（MUST NOT）。 （注：チャンクエンコーディングは、メッセージの本文を変更して、それぞれが独自のサイズインジケーターを持つ一連のチャンクとして転送します。）
Unlike HTTP, SIP implementations can use UDP or other unreliable datagram protocols. Each such datagram carries one request or response. See Section 18 on constraints on usage of unreliable transports.
HTTPとは異なり、SIP実装はUDPまたはその他の信頼性の低いデータグラムプロトコルを使用できます。このような各データグラムは、1つの要求または応答を伝送します。信頼できないトランスポートの使用に関する制約については、セクション18を参照してください。
Implementations processing SIP messages over stream-oriented transports MUST ignore any CRLF appearing before the start-line [H4.1].
ストリーム指向のトランスポートを介してSIPメッセージを処理する実装は、開始行の前に現れるCRLFをすべて無視する必要があります[H4.1]。
The Content-Length header field value is used to locate the end of each SIP message in a stream. It will always be present when SIP messages are sent over stream-oriented transports.
Content-Lengthヘッダーフィールド値は、ストリーム内の各SIPメッセージの終わりを見つけるために使用されます。 SIPメッセージがストリーム指向のトランスポートを介して送信される場合、常に存在します。
8 General User Agent Behavior
8一般的なユーザーエージェントの動作
A user agent represents an end system. It contains a user agent client (UAC), which generates requests, and a user agent server (UAS), which responds to them. A UAC is capable of generating a request based on some external stimulus (the user clicking a button, or a signal on a PSTN line) and processing a response. A UAS is capable of receiving a request and generating a response based on user input, external stimulus, the result of a program execution, or some other mechanism.
ユーザーエージェントはエンドシステムを表します。要求を生成するユーザーエージェントクライアント（UAC）と、要求に応答するユーザーエージェントサーバー（UAS）が含まれています。 UACは、何らかの外部刺激（ユーザーがボタンをクリックするか、PSTN回線上の信号）に基づいて要求を生成し、応答を処理することができます。 UASは、ユーザー入力、外部刺激、プログラム実行の結果、またはその他のメカニズムに基づいて、要求を受信して応答を生成できます。
When a UAC sends a request, the request passes through some number of proxy servers, which forward the request towards the UAS. When the UAS generates a response, the response is forwarded towards the UAC.
UACが要求を送信すると、要求はいくつかのプロキシサーバーを通過し、UASに向けて要求が転送されます。 UASが応答を生成すると、応答はUACに転送されます。
UAC and UAS procedures depend strongly on two factors. First, based on whether the request or response is inside or outside of a dialog, and second, based on the method of a request. Dialogs are discussed thoroughly in Section 12; they represent a peer-to-peer relationship between user agents and are established by specific SIP methods, such as INVITE.
UACおよびUASの手順は、2つの要因に強く依存します。 1つ目は、要求または応答がダイアログの内部か外部かに基づいて、2つ目は、要求のメソッドに基づいています。ダイアログについては、セクション12で詳しく説明しています。これらはユーザーエージェント間のピアツーピア関係を表し、INVITEなどの特定のSIPメソッドによって確立されます。
In this section, we discuss the method-independent rules for UAC and UAS behavior when processing requests that are outside of a dialog. This includes, of course, the requests which themselves establish a dialog.
このセクションでは、ダイアログの外部にある要求を処理するときのUACおよびUASの動作に関するメソッドに依存しないルールについて説明します。もちろん、これにはダイアログ自体を確立する要求も含まれます。
Security procedures for requests and responses outside of a dialog are described in Section 26. Specifically, mechanisms exist for the UAS and UAC to mutually authenticate. A limited set of privacy features are also supported through encryption of bodies using S/MIME.
ダイアログ外の要求と応答のセキュリティ手順については、セクション26で説明します。具体的には、UASとUACが相互に認証するためのメカニズムが存在します。 S / MIMEを使用した本文の暗号化により、限定されたプライバシー機能セットもサポートされます。
This section covers UAC behavior outside of a dialog.
このセクションでは、ダイアログ外でのUACの動作について説明します。
A valid SIP request formulated by a UAC MUST, at a minimum, contain the following header fields: To, From, CSeq, Call-ID, Max-Forwards, and Via; all of these header fields are mandatory in all SIP requests. These six header fields are the fundamental building blocks of a SIP message, as they jointly provide for most of the critical message routing services including the addressing of messages, the routing of responses, limiting message propagation, ordering of messages, and the unique identification of transactions. These header fields are in addition to the mandatory request line, which contains the method, Request-URI, and SIP version.
UACによって作成された有効なSIP要求には、少なくとも、次のヘッダーフィールドが含まれている必要があります。To、From、CSeq、Call-ID、Max-Forwards、およびVia。これらのヘッダーフィールドはすべて、すべてのSIPリクエストで必須です。これらの6つのヘッダーフィールドは、メッセージのアドレス指定、応答のルーティング、メッセージの伝播の制限、メッセージの順序付け、およびメッセージの一意の識別を含む、ほとんどの重要なメッセージルーティングサービスを共同で提供するため、SIPメッセージの基本的なビルディングブロックです。トランザクション。これらのヘッダーフィールドは、メソッド、Request-URI、およびSIPバージョンを含む必須の要求行に追加されます。
Examples of requests sent outside of a dialog include an INVITE to establish a session (Section 13) and an OPTIONS to query for capabilities (Section 11).
ダイアログの外部に送信される要求の例には、セッションを確立するためのINVITE（セクション13）および機能を照会するためのOPTIONS（セクション11）が含まれます。
The initial Request-URI of the message SHOULD be set to the value of the URI in the To field. One notable exception is the REGISTER method; behavior for setting the Request-URI of REGISTER is given in Section 10. It may also be undesirable for privacy reasons or convenience to set these fields to the same value (especially if the originating UA expects that the Request-URI will be changed during transit).
メッセージの最初のRequest-URIは、ToフィールドのURIの値に設定する必要があります（SHOULD）。 1つの注目すべき例外は、REGISTERメソッドです。 REGISTERのRequest-URIを設定するための動作は、セクション10に記載されています。これらのフィールドを同じ値に設定することは、プライバシー上の理由や利便性から望ましくない場合があります（特に、送信元UAが転送中にRequest-URIが変更されることを予期している場合） ）。
In some special circumstances, the presence of a pre-existing route set can affect the Request-URI of the message. A pre-existing route set is an ordered set of URIs that identify a chain of servers, to which a UAC will send outgoing requests that are outside of a dialog. Commonly, they are configured on the UA by a user or service provider manually, or through some other non-SIP mechanism. When a provider wishes to configure a UA with an outbound proxy, it is RECOMMENDED that this be done by providing it with a pre-existing route set with a single URI, that of the outbound proxy.
一部の特殊な状況では、既存のルートセットの存在がメッセージのRequest-URIに影響を与える可能性があります。既存のルートセットは、UACがダイアログの外部にある発信要求を送信するサーバーのチェーンを識別する、順序付けられたURIのセットです。一般に、ユーザーまたはサービスプロバイダーが手動で、またはその他の非SIPメカニズムを使用して、UAで構成します。プロバイダーがアウトバウンドプロキシでUAを構成する場合は、アウトバウンドプロキシの単一のURIが設定された既存のルートをプロバイダーに提供することでこれを行うことをお勧めします。
When a pre-existing route set is present, the procedures for populating the Request-URI and Route header field detailed in Section 12.2.1.1 MUST be followed (even though there is no dialog), using the desired Request-URI as the remote target URI.
既存のルートセットが存在する場合は、セクション12.2.1.1で説明されているRequest-URIおよびRouteヘッダーフィールドにデータを入力する手順を（ダイアログがない場合でも）必要なRequest-URIをリモートターゲットとして使用して実行する必要があります。 URI。
The To header field first and foremost specifies the desired "logical" recipient of the request, or the address-of-record of the user or resource that is the target of this request. This may or may not be the ultimate recipient of the request. The To header field MAY contain a SIP or SIPS URI, but it may also make use of other URI schemes (the tel URL (RFC 2806 [9]), for example) when appropriate. All SIP implementations MUST support the SIP URI scheme. Any implementation that supports TLS MUST support the SIPS URI scheme. The To header field allows for a display name.
Toヘッダーフィールドは何よりもまず、要求の目的の「論理」受信者、またはこの要求のターゲットであるユーザーまたはリソースのレコードのアドレスを指定します。これは、リクエストの最終的な受信者である場合とそうでない場合があります。 ToヘッダーフィールドにはSIPまたはSIPS URIが含まれる場合がありますが、必要に応じて他のURIスキーム（たとえば、tel URL（RFC 2806 [9]））を利用することもできます。すべてのSIP実装はSIP URIスキームをサポートする必要があります。 TLSをサポートする実装はSIPS URIスキームをサポートする必要があります。 Toヘッダーフィールドでは、表示名を使用できます。
A UAC may learn how to populate the To header field for a particular request in a number of ways. Usually the user will suggest the To header field through a human interface, perhaps inputting the URI manually or selecting it from some sort of address book. Frequently, the user will not enter a complete URI, but rather a string of digits or letters (for example, "bob"). It is at the discretion of the UA to choose how to interpret this input. Using the string to form the user part of a SIP URI implies that the UA wishes the name to be resolved in the domain to the right-hand side (RHS) of the at-sign in the SIP URI (for instance, sip:bob@example.com). Using the string to form the user part of a SIPS URI implies that the UA wishes to communicate securely, and that the name is to be resolved in the domain to the RHS of the at-sign. The RHS will frequently be the home domain of the requestor, which allows for the home domain to process the outgoing request. This is useful for features like "speed dial" that require interpretation of the user part in the home domain. The tel URL may be used when the UA does not wish to specify the domain that should interpret a telephone number that has been input by the user. Rather, each domain through which the request passes would be given that opportunity. As an example, a user in an airport might log in and send requests through an outbound proxy in the airport. If they enter "411" (this is the phone number for local directory assistance in the United States), that needs to be interpreted and processed by the outbound proxy in the airport, not the user's home domain. In this case, tel:411 would be the right choice.
UACは、特定のリクエストのToヘッダーフィールドにさまざまな方法でデータを入力する方法を学習できます。通常、ユーザーはヒューマンインターフェイスを介してToヘッダーフィールドを提案します。おそらく、URIを手動で入力するか、なんらかのアドレス帳から選択します。多くの場合、ユーザーは完全なURIではなく、数字または文字の文字列（たとえば、「bob」）を入力します。この入力の解釈方法を選択するのは、UAの裁量です。文字列を使用してSIP URIのユーザー部分を形成することは、UAがドメイン内の名前をSIP URIのアットマークの右側（RHS）に解決することを望んでいることを意味します（たとえば、sip：bob）。 @ example.com）。文字列を使用してSIPS URIのユーザー部分を形成することは、UAが安全に通信することを望み、名前がドメイン内でアットマークのRHSに解決されることを意味します。 RHSはリクエスタのホームドメインになることがよくあり、ホームドメインが発信要求を処理できるようになります。これは、ホームドメインのユーザー部分の解釈を必要とする「スピードダイヤル」などの機能に役立ちます。 tel URLは、ユーザーが入力した電話番号を解釈するドメインをUAが指定したくない場合に使用できます。むしろ、要求が通過する各ドメインにその機会が与えられます。例として、空港のユーザーがログインし、空港のアウトバウンドプロキシを介してリクエストを送信する場合があります。ユーザーが「411」（これは米国のローカルディレクトリアシスタンスの電話番号です）と入力した場合、ユーザーのホームドメインではなく、空港のアウトバウンドプロキシによって解釈および処理される必要があります。この場合、tel：411が正しい選択です。
A request outside of a dialog MUST NOT contain a To tag; the tag in the To field of a request identifies the peer of the dialog. Since no dialog is established, no tag is present.
ダイアログ外のリクエストにはToタグを含めてはいけません。リクエストのToフィールドのタグは、ダイアログのピアを識別します。ダイアログが確立されていないため、タグはありません。
For further information on the To header field, see Section 20.39. The following is an example of a valid To header field:
Toヘッダーフィールドの詳細については、セクション20.39を参照してください。以下は、有効なToヘッダーフィールドの例です。
To: Carol <sip:carol@chicago.com>
The From header field indicates the logical identity of the initiator of the request, possibly the user's address-of-record. Like the To header field, it contains a URI and optionally a display name. It is used by SIP elements to determine which processing rules to apply to a request (for example, automatic call rejection). As such, it is very important that the From URI not contain IP addresses or the FQDN of the host on which the UA is running, since these are not logical names.
Fromヘッダーフィールドは、要求のイニシエーターの論理ID、おそらくユーザーのレコードのアドレスを示します。 Toヘッダーフィールドと同様に、URIとオプションで表示名が含まれます。これは、SIP要素が要求に適用する処理ルールを決定するために使用されます（たとえば、自動呼び出し拒否）。そのため、From URIには、UAが実行されているホストのIPアドレスまたはFQDNが含まれていないことが非常に重要です。これらは論理名ではないためです。
The From header field allows for a display name. A UAC SHOULD use the display name "Anonymous", along with a syntactically correct, but otherwise meaningless URI (like sip:thisis@anonymous.invalid), if the identity of the client is to remain hidden.
Fromヘッダーフィールドでは、表示名を使用できます。 UACは、クライアントのIDを非表示のままにする場合は、表示名「匿名」と構文的に正しいが意味のないURI（sip：thisis@anonymous.invalidなど）を使用する必要があります（SHOULD）。
Usually, the value that populates the From header field in requests generated by a particular UA is pre-provisioned by the user or by the administrators of the user's local domain. If a particular UA is used by multiple users, it might have switchable profiles that include a URI corresponding to the identity of the profiled user. Recipients of requests can authenticate the originator of a request in order to ascertain that they are who their From header field claims they are (see Section 22 for more on authentication).
通常、特定のUAによって生成されたリクエストのFromヘッダーフィールドに入力される値は、ユーザーまたはユーザーのローカルドメインの管理者によって事前にプロビジョニングされます。特定のUAが複数のユーザーによって使用されている場合、プロファイリングされたユーザーのIDに対応するURIを含む切り替え可能なプロファイルがある場合があります。要求の受信者は、Fromヘッダーフィールドで要求されている人物であることを確認するために、要求の発信者を認証できます（認証の詳細については、セクション22を参照してください）。
The From field MUST contain a new "tag" parameter, chosen by the UAC. See Section 19.3 for details on choosing a tag.
Fromフィールドには、UACによって選択された新しい「タグ」パラメータを含める必要があります。タグの選択の詳細については、セクション19.3を参照してください。
For further information on the From header field, see Section 20.20. Examples:
Fromヘッダーフィールドの詳細については、セクション20.20を参照してください。例：
From: "Bob" <sips:bob@biloxi.com> ;tag=a48s
From: sip:+12125551212@phone2net.com;tag=887s
From: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8
The Call-ID header field acts as a unique identifier to group together a series of messages. It MUST be the same for all requests and responses sent by either UA in a dialog. It SHOULD be the same in each registration from a UA.
Call-IDヘッダーフィールドは、一連のメッセージをグループ化する一意の識別子として機能します。ダイアログ内のいずれかのUAから送信されるすべての要求と応答で同じでなければなりません。 UAからの各登録で同じである必要があります。
In a new request created by a UAC outside of any dialog, the Call-ID header field MUST be selected by the UAC as a globally unique identifier over space and time unless overridden by method-specific behavior. All SIP UAs must have a means to guarantee that the Call-ID header fields they produce will not be inadvertently generated by any other UA. Note that when requests are retried after certain failure responses that solicit an amendment to a request (for example, a challenge for authentication), these retried requests are not considered new requests, and therefore do not need new Call-ID header fields; see Section 8.1.3.5.
UACがダイアログの外で作成した新しいリクエストでは、メソッド固有の動作でオーバーライドされない限り、Call-IDヘッダーフィールドは、空間と時間でグローバルに一意の識別子としてUACによって選択される必要があります。すべてのSIP UAには、それらが生成するCall-IDヘッダーフィールドが他のUAによって誤って生成されないことを保証する手段が必要です。要求の修正を求める特定の失敗応答（認証のチャレンジなど）の後で要求が再試行される場合、これらの再試行された要求は新しい要求とは見なされないため、新しいCall-IDヘッダーフィールドは必要ありません。セクション8.1.3.5を参照してください。
Use of cryptographically random identifiers (RFC 1750 [12]) in the generation of Call-IDs is RECOMMENDED. Implementations MAY use the form "localid@host". Call-IDs are case-sensitive and are simply compared byte-by-byte.
Call-IDの生成における暗号化ランダム識別子（RFC 1750 [12]）の使用が推奨されます。実装では、「localid @ host」の形式を使用できます。 Call-IDは大文字と小文字が区別され、単純にバイトごとに比較されます。
Using cryptographically random identifiers provides some protection against session hijacking and reduces the likelihood of unintentional Call-ID collisions.
暗号的にランダムな識別子を使用すると、セッションの乗っ取りに対する保護が提供され、意図しないCall-ID衝突の可能性が減少します。
No provisioning or human interface is required for the selection of the Call-ID header field value for a request.
要求のCall-IDヘッダーフィールド値を選択するために、プロビジョニングやヒューマンインターフェイスは必要ありません。
For further information on the Call-ID header field, see Section 20.8.
Call-IDヘッダーフィールドの詳細については、セクション20.8を参照してください。
Example:
例：
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com
コールID：f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com
The CSeq header field serves as a way to identify and order transactions. It consists of a sequence number and a method. The method MUST match that of the request. For non-REGISTER requests outside of a dialog, the sequence number value is arbitrary. The sequence number value MUST be expressible as a 32-bit unsigned integer and MUST be less than 2**31. As long as it follows the above guidelines, a client may use any mechanism it would like to select CSeq header field values.
CSeqヘッダーフィールドは、トランザクションを識別して注文する方法として機能します。シーケンス番号とメソッドで構成されます。メソッドはリクエストのメソッドと一致する必要があります。ダイアログ外の非REGISTERリクエストの場合、シーケンス番号の値は任意です。シーケンス番号の値は、32ビットの符号なし整数として表現可能でなければならず、2 ** 31未満でなければなりません（MUST）。上記のガイドラインに従っている限り、クライアントはCSeqヘッダーフィールドの値を選択するメカニズムを使用できます。
Section 12.2.1.1 discusses construction of the CSeq for requests within a dialog.
セクション12.2.1.1では、ダイアログ内のリクエストに対するCSeqの構築について説明します。
Example:
例：
CSeq: 4711 INVITE
CSeq：4711 INVITE
The Max-Forwards header field serves to limit the number of hops a request can transit on the way to its destination. It consists of an integer that is decremented by one at each hop. If the Max-Forwards value reaches 0 before the request reaches its destination, it will be rejected with a 483(Too Many Hops) error response.
Max-Forwardsヘッダーフィールドは、要求が宛先に向かう途中で通過できるホップの数を制限するのに役立ちます。これは、各ホップで1ずつ減分される整数で構成されます。リクエストが宛先に到達する前にMax-Forwards値が0に到達すると、483（Too Many Hops）エラー応答で拒否されます。
A UAC MUST insert a Max-Forwards header field into each request it originates with a value that SHOULD be 70. This number was chosen to be sufficiently large to guarantee that a request would not be dropped in any SIP network when there were no loops, but not so large as to consume proxy resources when a loop does occur. Lower values should be used with caution and only in networks where topologies are known by the UA.
UACは、発信する各要求にMax-Forwardsヘッダーフィールドを挿入する必要があります（SHOULDの値は70です）。この数は、ループがない場合にSIPネットワークで要求がドロップされないことを保証するのに十分な大きさに選択されています。ただし、ループが発生したときにプロキシリソースを消費するほど大きくはありません。低い値は、トポロジーがUAによって認識されているネットワークでのみ、注意して使用する必要があります。
The Via header field indicates the transport used for the transaction and identifies the location where the response is to be sent. A Via header field value is added only after the transport that will be used to reach the next hop has been selected (which may involve the usage of the procedures in [4]).
Viaヘッダーフィールドは、トランザクションに使用されるトランスポートを示し、応答が送信される場所を識別します。 Viaヘッダーフィールド値は、次のホップに到達するために使用されるトランスポートが選択された後にのみ追加されます（[4]の手順の使用が含まれる場合があります）。
When the UAC creates a request, it MUST insert a Via into that request. The protocol name and protocol version in the header field MUST be SIP and 2.0, respectively. The Via header field value MUST contain a branch parameter. This parameter is used to identify the transaction created by that request. This parameter is used by both the client and the server.
UACがリクエストを作成するとき、そのリクエストにViaを挿入する必要があります。ヘッダーフィールドのプロトコル名とプロトコルバージョンは、それぞれSIPと2.0でなければなりません。 Viaヘッダーフィールドの値には、ブランチパラメータを含める必要があります。このパラメーターは、その要求によって作成されたトランザクションを識別するために使用されます。このパラメーターは、クライアントとサーバーの両方で使用されます。
The branch parameter value MUST be unique across space and time for all requests sent by the UA. The exceptions to this rule are CANCEL and ACK for non-2xx responses. As discussed below, a CANCEL request will have the same value of the branch parameter as the request it cancels. As discussed in Section 17.1.1.3, an ACK for a non-2xx response will also have the same branch ID as the INVITE whose response it acknowledges.
ブランチパラメータの値は、UAから送信されるすべての要求に対して、空間と時間全体で一意である必要があります。この規則の例外は、2xx以外の応答に対するCANCELおよびACKです。以下で説明するように、CANCELリクエストには、キャンセルするリクエストと同じ値のブランチパラメータがあります。セクション17.1.1.3で説明したように、2xx以外の応答のACKも、応答を確認するINVITEと同じブランチIDを持ちます。
The uniqueness property of the branch ID parameter, to facilitate its use as a transaction ID, was not part of RFC 2543.
ブランチIDパラメータの一意性プロパティは、トランザクションIDとしての使用を容易にするために、RFC 2543の一部ではありませんでした。
The branch ID inserted by an element compliant with this specification MUST always begin with the characters "z9hG4bK". These 7 characters are used as a magic cookie (7 is deemed sufficient to ensure that an older RFC 2543 implementation would not pick such a value), so that servers receiving the request can determine that the branch ID was constructed in the fashion described by this specification (that is, globally unique). Beyond this requirement, the precise format of the branch token is implementation-defined.
この仕様に準拠する要素によって挿入されるブランチIDは、常に「z9hG4bK」という文字で始まる必要があります。これらの7文字はマジックCookieとして使用されます（7は、古いRFC 2543実装がそのような値を選択しないことを保証するのに十分であると見なされます）。これにより、要求を受信するサーバーは、ブランチIDがこの方法で構築されたと判断できます。仕様（つまり、グローバルに一意）。この要件を超えて、ブランチトークンの正確な形式は実装定義です。
The Via header maddr, ttl, and sent-by components will be set when the request is processed by the transport layer (Section 18).
Viaヘッダーのmaddr、ttl、およびsent-byコンポーネントは、リクエストがトランスポート層によって処理されるときに設定されます（セクション18）。
Via processing for proxies is described in Section 16.6 Item 8 and Section 16.7 Item 3.
プロキシのvia処理については、セクション16.6の項目8とセクション16.7の項目3で説明しています。
The Contact header field provides a SIP or SIPS URI that can be used to contact that specific instance of the UA for subsequent requests. The Contact header field MUST be present and contain exactly one SIP or SIPS URI in any request that can result in the establishment of a dialog. For the methods defined in this specification, that includes only the INVITE request. For these requests, the scope of the Contact is global. That is, the Contact header field value contains the URI at which the UA would like to receive requests, and this URI MUST be valid even if used in subsequent requests outside of any dialogs.
Contactヘッダーフィールドは、後続の要求のためにUAの特定のインスタンスに接続するために使用できるSIPまたはSIPS URIを提供します。 Contactヘッダーフィールドが存在しなければならず、ダイアログの確立をもたらす可能性のあるすべてのリクエストにSIPまたはSIPS URIが1つだけ含まれている必要があります。この仕様で定義されているメソッドの場合、INVITEリクエストのみが含まれます。これらのリクエストの場合、連絡先のスコープはグローバルです。つまり、Contactヘッダーフィールドの値には、UAがリクエストを受信するURIが含まれます。このURIは、ダイアログ以外の後続のリクエストで使用される場合でも有効でなければなりません。
If the Request-URI or top Route header field value contains a SIPS URI, the Contact header field MUST contain a SIPS URI as well.
Request-URIまたはトップRouteヘッダーフィールドの値にSIPS URIが含まれている場合、ContactヘッダーフィールドにもSIPS URIが含まれている必要があります。
For further information on the Contact header field, see Section 20.10.
Contactヘッダーフィールドの詳細については、セクション20.10を参照してください。
If the UAC supports extensions to SIP that can be applied by the server to the response, the UAC SHOULD include a Supported header field in the request listing the option tags (Section 19.2) for those extensions.
UACが、サーバーが応答に適用できるSIPの拡張機能をサポートしている場合、UACは、それらの拡張機能のオプションタグ（セクション19.2）をリストするリクエストに、サポートされるヘッダーフィールドを含める必要があります（SHOULD）。
The option tags listed MUST only refer to extensions defined in standards-track RFCs. This is to prevent servers from insisting that clients implement non-standard, vendor-defined features in order to receive service. Extensions defined by experimental and informational RFCs are explicitly excluded from usage with the Supported header field in a request, since they too are often used to document vendor-defined extensions.
リストされているオプションタグは、標準化過程のRFCで定義されている拡張機能のみを参照する必要があります。これは、サービスを受けるためにクライアントが非標準のベンダー定義の機能を実装することをサーバーが要求しないようにするためです。実験的RFCと情報提供RFCによって定義された拡張機能は、ベンダー定義の拡張機能を文書化するためによく使用されるため、リクエスト内のサポートヘッダーフィールドでの使用から明示的に除外されます。
If the UAC wishes to insist that a UAS understand an extension that the UAC will apply to the request in order to process the request, it MUST insert a Require header field into the request listing the option tag for that extension. If the UAC wishes to apply an extension to the request and insist that any proxies that are traversed understand that extension, it MUST insert a Proxy-Require header field into the request listing the option tag for that extension.
UACがUASがリクエストを処理するためにリクエストに適用する拡張を理解することを主張したい場合、UACは、その拡張のオプションタグをリストする要求ヘッダーフィールドを要求に挿入する必要があります。 UACがリクエストに拡張機能を適用することを希望し、通過するすべてのプロキシがその拡張機能を理解することを要求する場合、その拡張機能のオプションタグをリストするリクエストにProxy-Requireヘッダーフィールドを挿入する必要があります。
As with the Supported header field, the option tags in the Require and Proxy-Require header fields MUST only refer to extensions defined in standards-track RFCs.
サポートされるヘッダーフィールドと同様に、RequireおよびProxy-Requireヘッダーフィールドのオプションタグは、標準化過程のRFCで定義された拡張のみを参照する必要があります。
After a new request has been created, and the header fields described above have been properly constructed, any additional optional header fields are added, as are any header fields specific to the method.
新しいリクエストが作成され、上記のヘッダーフィールドが適切に構築されたら、オプションのヘッダーフィールドが追加され、メソッドに固有のヘッダーフィールドも追加されます。
SIP requests MAY contain a MIME-encoded message-body. Regardless of the type of body that a request contains, certain header fields must be formulated to characterize the contents of the body. For further information on these header fields, see Sections 20.11 through 20.15.
SIPリクエストには、MIMEでエンコードされたメッセージ本文が含まれる場合があります。リクエストに含まれるボディのタイプに関係なく、ボディのコンテンツを特徴付けるために特定のヘッダーフィールドを作成する必要があります。これらのヘッダーフィールドの詳細については、セクション20.11〜20.15を参照してください。
The destination for the request is then computed. Unless there is local policy specifying otherwise, the destination MUST be determined by applying the DNS procedures described in [4] as follows. If the first element in the route set indicated a strict router (resulting in forming the request as described in Section 12.2.1.1), the procedures MUST be applied to the Request-URI of the request. Otherwise, the procedures are applied to the first Route header field value in the request (if one exists), or to the request's Request-URI if there is no Route header field present. These procedures yield an ordered set of address, port, and transports to attempt. Independent of which URI is used as input to the procedures of [4], if the Request-URI specifies a SIPS resource, the UAC MUST follow the procedures of [4] as if the input URI were a SIPS URI.
次に、要求の宛先が計算されます。特に指定されていないローカルポリシーがない限り、[4]で説明されているDNS手順を次のように適用して宛先を決定する必要があります。ルートセットの最初の要素が厳密なルーターを示している場合（セクション12.2.1.1で説明されているように要求を形成することになります）、手順を要求のRequest-URIに適用する必要があります。それ以外の場合、手順は、要求の最初のルートヘッダーフィールド値（存在する場合）、またはルートヘッダーフィールドが存在しない場合は要求のRequest-URIに適用されます。これらの手順により、試行するアドレス、ポート、トランスポートの順序付けされたセットが生成されます。 [4]の手順への入力として使用されるURIとは無関係に、Request-URIがSIPSリソースを指定する場合、UACは入力URIがSIPS URIであるかのように[4]の手順に従う必要があります。
Local policy MAY specify an alternate set of destinations to attempt. If the Request-URI contains a SIPS URI, any alternate destinations MUST be contacted with TLS. Beyond that, there are no restrictions on the alternate destinations if the request contains no Route header field. This provides a simple alternative to a pre-existing route set as a way to specify an outbound proxy. However, that approach for configuring an outbound proxy is NOT RECOMMENDED; a pre-existing route set with a single URI SHOULD be used instead. If the request contains a Route header field, the request SHOULD be sent to the locations derived from its topmost value, but MAY be sent to any server that the UA is certain will honor the Route and Request-URI policies specified in this document (as opposed to those in RFC 2543). In particular, a UAC configured with an outbound proxy SHOULD
ローカルポリシーは、試行する宛先の代替セットを指定してもよい（MAY）。 Request-URIにSIPS URIが含まれている場合、代替の宛先はすべてTLSで接続する必要があります。それ以外に、リクエストにルートヘッダーフィールドが含まれていない場合、代替宛先に制限はありません。これにより、アウトバウンドプロキシを指定する方法として、既存のルートセットの簡単な代替手段が提供されます。ただし、送信プロキシを構成するためのそのアプローチは推奨されません。代わりに、単一のURIが設定された既存のルートセットを使用する必要があります。リクエストにルートヘッダーフィールドが含まれている場合、リクエストは最上位の値から派生した場所に送信する必要がありますが、UAがこのドキュメントで指定されているルートポリシーとリクエストURIポリシーを順守することが確実であるすべてのサーバーに送信できます（ RFC 2543のものとは対照的です）。特に、送信プロキシで構成されたUACは
attempt to send the request to the location indicated in the first Route header field value instead of adopting the policy of sending all messages to the outbound proxy.
すべてのメッセージを送信プロキシに送信するポリシーを採用する代わりに、最初のルートヘッダーフィールド値で示される場所にリクエストを送信しようとします。
This ensures that outbound proxies that do not add Record-Route header field values will drop out of the path of subsequent requests. It allows endpoints that cannot resolve the first Route URI to delegate that task to an outbound proxy.
これにより、Record-Routeヘッダーフィールド値を追加しないアウトバウンドプロキシが後続のリクエストのパスから確実にドロップされます。最初のルートURIを解決できないエンドポイントがそのタスクを送信プロキシに委任できるようにします。
The UAC SHOULD follow the procedures defined in [4] for stateful elements, trying each address until a server is contacted. Each try constitutes a new transaction, and therefore each carries a different topmost Via header field value with a new branch parameter. Furthermore, the transport value in the Via header field is set to whatever transport was determined for the target server.
UACは、サーバーに接続するまで各アドレスを試行して、ステートフル要素について[4]で定義された手順に従う必要があります（SHOULD）。それぞれの試行は新しいトランザクションを構成するため、それぞれが新しいブランチパラメータを持つ異なる最上位のViaヘッダーフィールド値を伝達します。さらに、Viaヘッダーフィールドのトランスポート値は、ターゲットサーバーに対して決定されたトランスポートに設定されます。
Responses are first processed by the transport layer and then passed up to the transaction layer. The transaction layer performs its processing and then passes the response up to the TU. The majority of response processing in the TU is method specific. However, there are some general behaviors independent of the method.
応答は最初にトランスポート層によって処理され、次にトランザクション層に渡されます。トランザクション層はその処理を実行してから、応答をTUに渡します。 TUの応答処理の大部分はメソッド固有です。ただし、メソッドに依存しないいくつかの一般的な動作があります。
In some cases, the response returned by the transaction layer will not be a SIP message, but rather a transaction layer error. When a timeout error is received from the transaction layer, it MUST be treated as if a 408 (Request Timeout) status code has been received. If a fatal transport error is reported by the transport layer (generally, due to fatal ICMP errors in UDP or connection failures in TCP), the condition MUST be treated as a 503 (Service Unavailable) status code.
場合によっては、トランザクション層によって返される応答はSIPメッセージではなく、トランザクション層エラーになります。トランザクション層からタイムアウトエラーを受け取った場合、408（Request Timeout）ステータスコードを受け取ったかのように処理する必要があります。トランスポート層によって致命的なトランスポートエラーが報告された場合（通常、UDPでの致命的なICMPエラーまたはTCPでの接続エラーが原因）、条件は503（サービス利用不可）ステータスコードとして扱われる必要があります。
A UAC MUST treat any final response it does not recognize as being equivalent to the x00 response code of that class, and MUST be able to process the x00 response code for all classes. For example, if a UAC receives an unrecognized response code of 431, it can safely assume that there was something wrong with its request and treat the response as if it had received a 400 (Bad Request) response code. A UAC MUST treat any provisional response different than 100 that it does not recognize as 183 (Session Progress). A UAC MUST be able to process 100 and 183 responses.
UACは、認識しないすべての最終応答をそのクラスのx00応答コードと同等であると見なし、すべてのクラスのx00応答コードを処理できる必要があります。たとえば、UACが認識されない応答コード431を受信した場合、要求に問題があると安全に想定し、応答を400（不正な要求）応答コードを受信したかのように処理できます。 UACは、それが認識しない100以外の暫定応答を183（Session Progress）として処理する必要があります。 UACは、100および183応答を処理できなければなりません（MUST）。
If more than one Via header field value is present in a response, the UAC SHOULD discard the message.
応答に複数のViaヘッダーフィールド値が存在する場合、UACはメッセージを破棄する必要があります（SHOULD）。
The presence of additional Via header field values that precede the originator of the request suggests that the message was misrouted or possibly corrupted.
リクエストの発信者の前に追加のViaヘッダーフィールド値が存在する場合は、メッセージが誤ってルーティングされたか、破損している可能性があります。
Upon receipt of a redirection response (for example, a 301 response status code), clients SHOULD use the URI(s) in the Contact header field to formulate one or more new requests based on the redirected request. This process is similar to that of a proxy recursing on a 3xx class response as detailed in Sections 16.5 and 16.6. A client starts with an initial target set containing exactly one URI, the Request-URI of the original request. If a client wishes to formulate new requests based on a 3xx class response to that request, it places the URIs to try into the target set. Subject to the restrictions in this specification, a client can choose which Contact URIs it places into the target set. As with proxy recursion, a client processing 3xx class responses MUST NOT add any given URI to the target set more than once. If the original request had a SIPS URI in the Request-URI, the client MAY choose to recurse to a non-SIPS URI, but SHOULD inform the user of the redirection to an insecure URI.
リダイレクト応答（301応答ステータスコードなど）を受信すると、クライアントは、ContactヘッダーフィールドのURIを使用して、リダイレクトされた要求に基づいて1つ以上の新しい要求を作成する必要があります（SHOULD）。このプロセスは、セクション16.5および16.6で詳細に説明されているように、3xxクラス応答で再帰するプロキシのプロセスに似ています。クライアントは、最初のターゲットセット（元の要求のRequest-URI）を1つだけ含むことから始まります。クライアントがそのリクエストに対する3xxクラスの応答に基づいて新しいリクエストを作成したい場合は、URIをターゲットセットに配置します。この仕様の制限に従い、クライアントはターゲットセットに配置する連絡先URIを選択できます。プロキシ再帰と同様に、3xxクラス応答を処理するクライアントは、ターゲットセットに特定のURIを複数回追加してはなりません（MUST NOT）。元のリクエストのRequest-URIにSIPS URIが含まれていた場合、クライアントは非SIPのURIに再帰することを選択できますが、安全でないURIへのリダイレクトをユーザーに通知する必要があります（SHOULD）。
Any new request may receive 3xx responses themselves containing the original URI as a contact. Two locations can be configured to redirect to each other. Placing any given URI in the target set only once prevents infinite redirection loops.
新しいリクエストは、連絡先として元のURIを含む3xx応答自体を受信する場合があります。 2つの場所を互いにリダイレクトするように構成できます。特定のURIをターゲットセットに1回だけ配置すると、無限のリダイレクトループが防止されます。
As the target set grows, the client MAY generate new requests to the URIs in any order. A common mechanism is to order the set by the "q" parameter value from the Contact header field value. Requests to the URIs MAY be generated serially or in parallel. One approach is to process groups of decreasing q-values serially and process the URIs in each q-value group in parallel. Another is to perform only serial processing in decreasing q-value order, arbitrarily choosing between contacts of equal q-value.
ターゲットセットが大きくなると、クライアントはURIへの新しいリクエストを任意の順序で生成できます（MAY）。一般的なメカニズムは、「q」パラメーター値によってセットをContactヘッダーフィールド値から注文することです。 URIへのリクエストは、シリアルまたはパラレルで生成される場合があります。 1つのアプローチは、減少するq値のグループを順次処理し、各q値グループのURIを並行して処理することです。もう1つは、q値の小さい順にシリアル処理のみを実行し、q値が等しい接点間を任意に選択することです。
If contacting an address in the list results in a failure, as defined in the next paragraph, the element moves to the next address in the list, until the list is exhausted. If the list is exhausted, then the request has failed.
次の段落で定義されているように、リスト内のアドレスへの接続が失敗した場合、リストの最後まで、要素はリスト内の次のアドレスに移動します。リストがすべて使用されている場合、要求は失敗しています。
Failures SHOULD be detected through failure response codes (codes greater than 399); for network errors the client transaction will report any transport layer failures to the transaction user. Note that some response codes (detailed in 8.1.3.5) indicate that the request can be retried; requests that are reattempted should not be considered failures.
失敗は、失敗応答コード（399より大きいコード）によって検出する必要があります（SHOULD）。ネットワークエラーの場合、クライアントトランザクションはトランスポート層の障害をトランザクションユーザーに報告します。一部の応答コード（8.1.3.5で詳述）は、要求を再試行できることを示していることに注意してください。再試行される要求は、失敗とは見なされません。
When a failure for a particular contact address is received, the client SHOULD try the next contact address. This will involve creating a new client transaction to deliver a new request.
特定の連絡先アドレスの失敗を受信すると、クライアントは次の連絡先アドレスを試行する必要があります（SHOULD）。これには、新しい要求を配信するための新しいクライアントトランザクションの作成が含まれます。
In order to create a request based on a contact address in a 3xx response, a UAC MUST copy the entire URI from the target set into the Request-URI, except for the "method-param" and "header" URI parameters (see Section 19.1.1 for a definition of these parameters). It uses the "header" parameters to create header field values for the new request, overwriting header field values associated with the redirected request in accordance with the guidelines in Section 19.1.5.
3xx応答の連絡先アドレスに基づいて要求を作成するために、UACは、 "method-param"および "header" URIパラメーターを除いて、ターゲットセットからURI全体をRequest-URIにコピーする必要があります（セクションを参照）。これらのパラメータの定義については、19.1.1）。 「ヘッダー」パラメーターを使用して新しいリクエストのヘッダーフィールド値を作成し、セクション19.1.5のガイドラインに従ってリダイレクトされたリクエストに関連付けられたヘッダーフィールド値を上書きします。
Note that in some instances, header fields that have been communicated in the contact address may instead append to existing request header fields in the original redirected request. As a general rule, if the header field can accept a comma-separated list of values, then the new header field value MAY be appended to any existing values in the original redirected request. If the header field does not accept multiple values, the value in the original redirected request MAY be overwritten by the header field value communicated in the contact address. For example, if a contact address is returned with the following value:
場合によっては、連絡先アドレスで通信されたヘッダーフィールドが、元のリダイレクトされたリクエストの既存のリクエストヘッダーフィールドに追加されることがあります。一般的なルールとして、ヘッダーフィールドが値のコンマ区切りリストを受け入れることができる場合、新しいヘッダーフィールドの値は、元のリダイレクトされたリクエストの既存の値に追加される場合があります。ヘッダーフィールドが複数の値を受け入れない場合、元のリダイレクトされたリクエストの値は、連絡先アドレスで通知されたヘッダーフィールドの値によって上書きされる場合があります。たとえば、連絡先住所が次の値で返された場合：
sip:user@host?Subject=foo&Call-Info=<http://www.foo.com>
Then any Subject header field in the original redirected request is overwritten, but the HTTP URL is merely appended to any existing Call-Info header field values.
その後、リダイレクトされた元のリクエストのSubjectヘッダーフィールドは上書きされますが、HTTP URLは既存のCall-Infoヘッダーフィールド値に追加されるだけです。
It is RECOMMENDED that the UAC reuse the same To, From, and Call-ID used in the original redirected request, but the UAC MAY also choose to update the Call-ID header field value for new requests, for example.
UACが元のリダイレクトされた要求で使用されたのと同じTo、From、およびCall-IDを再利用することをお勧めしますが、UACは、たとえば新しい要求のCall-IDヘッダーフィールド値を更新することも選択できます（MAY）。
Finally, once the new request has been constructed, it is sent using a new client transaction, and therefore MUST have a new branch ID in the top Via field as discussed in Section 8.1.1.7.
最後に、新しいリクエストが作成されると、新しいクライアントトランザクションを使用して送信されるため、セクション8.1.1.7で説明するように、上部のViaフィールドに新しいブランチIDが必要です。
In all other respects, requests sent upon receipt of a redirect response SHOULD re-use the header fields and bodies of the original request.
他のすべての点で、リダイレクト応答の受信時に送信された要求は、元の要求のヘッダーフィールドと本文を再利用する必要があります（SHOULD）。
In some instances, Contact header field values may be cached at UAC temporarily or permanently depending on the status code received and the presence of an expiration interval; see Sections 21.3.2 and 21.3.3.
場合によっては、Contactヘッダーフィールドの値は、受信したステータスコードと有効期限の有無に応じて、UACで一時的または永続的にキャッシュされることがあります。セクション21.3.2および21.3.3を参照してください。
Certain 4xx response codes require specific UA processing, independent of the method.
特定の4xx応答コードは、メソッドに関係なく、特定のUA処理を必要とします。
If a 401 (Unauthorized) or 407 (Proxy Authentication Required) response is received, the UAC SHOULD follow the authorization procedures of Section 22.2 and Section 22.3 to retry the request with credentials.
401（無許可）または407（プロキシ認証が必要）応答を受信した場合、UACはセクション22.2およびセクション22.3の承認手順に従って、資格情報を使用して要求を再試行する必要があります（SHOULD）。
If a 413 (Request Entity Too Large) response is received (Section 21.4.11), the request contained a body that was longer than the UAS was willing to accept. If possible, the UAC SHOULD retry the request, either omitting the body or using one of a smaller length.
413（Request Entity Too Large）応答が受信された場合（セクション21.4.11）、要求には、UASが許容できるよりも長い本文が含まれていました。可能であれば、UAC SHOULDは、本文を省略するか、より短い長さの1つを使用して、要求を再試行する必要があります。
If a 415 (Unsupported Media Type) response is received (Section 21.4.13), the request contained media types not supported by the UAS. The UAC SHOULD retry sending the request, this time only using content with types listed in the Accept header field in the response, with encodings listed in the Accept-Encoding header field in the response, and with languages listed in the Accept-Language in the response.
415（サポートされていないメディアタイプ）応答が受信された場合（セクション21.4.13）、リクエストにはUASでサポートされていないメディアタイプが含まれていました。 UACはリクエストの送信を再試行する必要があります（今回は、応答のAcceptヘッダーフィールドにリストされているタイプ、応答のAccept-Encodingヘッダーフィールドにリストされているエンコーディング、およびのAccept-Languageにリストされている言語のコンテンツのみを使用します。応答。
If a 416 (Unsupported URI Scheme) response is received (Section 21.4.14), the Request-URI used a URI scheme not supported by the server. The client SHOULD retry the request, this time, using a SIP URI.
416（サポートされていないURIスキーム）応答が受信された場合（セクション21.4.14）、Request-URIはサーバーでサポートされていないURIスキームを使用しました。クライアントは、今回はSIP URIを使用してリクエストを再試行する必要があります（SHOULD）。
If a 420 (Bad Extension) response is received (Section 21.4.15), the request contained a Require or Proxy-Require header field listing an option-tag for a feature not supported by a proxy or UAS. The UAC SHOULD retry the request, this time omitting any extensions listed in the Unsupported header field in the response.
420（Bad Extension）応答を受信した場合（セクション21.4.15）、要求には、プロキシまたはUASでサポートされていない機能のオプションタグをリストするRequireまたはProxy-Requireヘッダーフィールドが含まれていました。 UACはリクエストを再試行する必要があります（SHOULD）、今度はレスポンスのUnsupportedヘッダーフィールドにリストされている拡張をすべて省略します。
In all of the above cases, the request is retried by creating a new request with the appropriate modifications. This new request constitutes a new transaction and SHOULD have the same value of the Call-ID, To, and From of the previous request, but the CSeq should contain a new sequence number that is one higher than the previous.
上記のすべてのケースで、適切な変更を加えた新しい要求を作成することにより、要求が再試行されます。この新しい要求は新しいトランザクションを構成し、以前の要求のCall-ID、To、およびFromの値は同じである必要がありますが、CSeqには前の要求よりも1つ大きい新しいシーケンス番号が含まれている必要があります。
With other 4xx responses, including those yet to be defined, a retry may or may not be possible depending on the method and the use case.
まだ定義されていないものを含む他の4xx応答では、方法とユースケースに応じて、再試行が可能な場合と不可能な場合があります。
When a request outside of a dialog is processed by a UAS, there is a set of processing rules that are followed, independent of the method. Section 12 gives guidance on how a UAS can tell whether a request is inside or outside of a dialog.
ダイアログ外のリクエストがUASによって処理される場合、メソッドとは無関係に、一連の処理ルールが適用されます。セクション12は、UASが要求がダイアログの内部にあるか外部にあるかをどのようにして知ることができるかについてのガイダンスを提供します。
Note that request processing is atomic. If a request is accepted, all state changes associated with it MUST be performed. If it is rejected, all state changes MUST NOT be performed.
リクエスト処理はアトミックであることに注意してください。リクエストが受け入れられる場合、それに関連するすべての状態変更を実行する必要があります。拒否された場合、すべての状態変更を実行してはなりません（MUST NOT）。
UASs SHOULD process the requests in the order of the steps that follow in this section (that is, starting with authentication, then inspecting the method, the header fields, and so on throughout the remainder of this section).
UASは、このセクションに続くステップの順序で要求を処理する必要があります（つまり、認証から開始し、このセクションの残りの部分全体でメソッド、ヘッダーフィールドなどを検査します）。
Once a request is authenticated (or authentication is skipped), the UAS MUST inspect the method of the request. If the UAS recognizes but does not support the method of a request, it MUST generate a 405 (Method Not Allowed) response. Procedures for generating responses are described in Section 8.2.6. The UAS MUST also add an Allow header field to the 405 (Method Not Allowed) response. The Allow header field MUST list the set of methods supported by the UAS generating the message. The Allow header field is presented in Section 20.5.
リクエストが認証されると（または認証がスキップされると）、UASはリクエストのメソッドを検査しなければなりません（MUST）。 UASがリクエストのメソッドを認識してもサポートしない場合は、405（Method Not Allowed）応答を生成する必要があります。応答を生成する手順については、セクション8.2.6で説明します。 UASは、405（Method Not Allowed）応答にAllowヘッダーフィールドも追加する必要があります。 Allowヘッダーフィールドは、メッセージを生成するUASによってサポートされる一連のメソッドをリストする必要があります。 Allowヘッダーフィールドについては、セクション20.5を参照してください。
If the method is one supported by the server, processing continues.
メソッドがサーバーでサポートされているメソッドである場合、処理は続行されます。
If a UAS does not understand a header field in a request (that is, the header field is not defined in this specification or in any supported extension), the server MUST ignore that header field and continue processing the message. A UAS SHOULD ignore any malformed header fields that are not necessary for processing requests.
UASがリクエストのヘッダーフィールドを理解しない場合（つまり、ヘッダーフィールドがこの仕様またはサポートされている拡張機能で定義されていない場合）、サーバーはそのヘッダーフィールドを無視してメッセージの処理を続行する必要があります。 UASは、リクエストの処理に不要な不正なヘッダーフィールドを無視する必要があります（SHOULD）。
The To header field identifies the original recipient of the request designated by the user identified in the From field. The original recipient may or may not be the UAS processing the request, due to call forwarding or other proxy operations. A UAS MAY apply any policy it wishes to determine whether to accept requests when the To header field is not the identity of the UAS. However, it is RECOMMENDED that a UAS accept requests even if they do not recognize the URI scheme (for example, a tel: URI) in the To header field, or if the To header field does not address a known or current user of this UAS. If, on the other hand, the UAS decides to reject the request, it SHOULD generate a response with a 403 (Forbidden) status code and pass it to the server transaction for transmission.
Toヘッダーフィールドは、Fromフィールドで識別されたユーザーによって指定されたリクエストの元の受信者を識別します。コール転送または他のプロキシ操作が原因で、元の受信者が要求を処理するUASである場合とそうでない場合があります。 UASは、ToヘッダーフィールドがUASのIDでない場合に要求を受け入れるかどうかを決定する必要があるポリシーを適用する場合があります。ただし、ToヘッダーフィールドのURIスキーム（たとえば、tel：URI）を認識しない場合、またはToヘッダーフィールドがこの既知または現在のユーザーをアドレス指定していない場合でも、UASが要求を受け入れることをお勧めします。 UAS。一方、UASが要求を拒否することを決定した場合は、403（禁止）ステータスコードを含む応答を生成して、送信のためにサーバートランザクションに渡す必要があります（SHOULD）。
However, the Request-URI identifies the UAS that is to process the request. If the Request-URI uses a scheme not supported by the UAS, it SHOULD reject the request with a 416 (Unsupported URI Scheme) response. If the Request-URI does not identify an address that the UAS is willing to accept requests for, it SHOULD reject the request with a 404 (Not Found) response. Typically, a UA that uses the REGISTER method to bind its address-of-record to a specific contact address will see requests whose Request-URI equals that contact address. Other potential sources of received Request-URIs include the Contact header fields of requests and responses sent by the UA that establish or refresh dialogs.
ただし、Request-URIは、要求を処理するUASを識別します。 Request-URIがUASでサポートされていないスキームを使用する場合、416（サポートされていないURIスキーム）応答でリクエストを拒否する必要があります（SHOULD）。 Request-URIが、UASが要求を受け入れる用意があるアドレスを識別しない場合、404（Not Found）応答で要求を拒否する必要があります（SHOULD）。通常、REGISTERメソッドを使用してレコードのアドレスを特定の連絡先アドレスにバインドするUAは、Request-URIがその連絡先アドレスと等しいリクエストを参照します。受信したRequest-URIの他の潜在的なソースには、ダイアログを確立または更新するUAから送信された要求と応答のContactヘッダーフィールドが含まれます。
If the request has no tag in the To header field, the UAS core MUST check the request against ongoing transactions. If the From tag, Call-ID, and CSeq exactly match those associated with an ongoing transaction, but the request does not match that transaction (based on the matching rules in Section 17.2.3), the UAS core SHOULD generate a 482 (Loop Detected) response and pass it to the server transaction.
リクエストのToヘッダーフィールドにタグがない場合、UASコアは進行中のトランザクションに対してリクエストをチェックする必要があります。 Fromタグ、Call-ID、CSeqが進行中のトランザクションに関連付けられたものと完全に一致するが、リクエストがそのトランザクションと一致しない場合（セクション17.2.3の一致ルールに基づく）、UASコアは482（ループ検出された）応答をサーバートランザクションに渡します。
The same request has arrived at the UAS more than once, following different paths, most likely due to forking. The UAS processes the first such request received and responds with a 482 (Loop Detected) to the rest of them.
同じリクエストが異なる経路をたどってUASに複数回到着しましたが、おそらくフォークが原因です。 UASは最初に受信したこのような要求を処理し、残りの要求に対して482（ループ検出）で応答します。
Assuming the UAS decides that it is the proper element to process the request, it examines the Require header field, if present.
UASが要求の処理に適切な要素であると判断した場合、要求ヘッダーフィールドが存在する場合は、それを調べます。
The Require header field is used by a UAC to tell a UAS about SIP extensions that the UAC expects the UAS to support in order to process the request properly. Its format is described in Section 20.32. If a UAS does not understand an option-tag listed in a Require header field, it MUST respond by generating a response with status code 420 (Bad Extension). The UAS MUST add an Unsupported header field, and list in it those options it does not understand amongst those in the Require header field of the request.
要求ヘッダーフィールドは、UACが要求を適切に処理するためにUASがサポートすることをUACが期待しているSIP拡張についてUASに通知するために使用されます。そのフォーマットについては項20.32で説明されています。 UASがRequireヘッダーフィールドにリストされているオプションタグを理解できない場合は、ステータスコード420（Bad Extension）の応答を生成して応答する必要があります。 UASは、サポートされていないヘッダーフィールドを追加する必要があり、リクエストのRequireヘッダーフィールドにあるオプションの中から、理解できないオプションをリストに含める必要があります。
Note that Require and Proxy-Require MUST NOT be used in a SIP CANCEL request, or in an ACK request sent for a non-2xx response. These header fields MUST be ignored if they are present in these requests.
RequireおよびProxy-Requireは、SIP CANCEL要求、または非2xx応答に対して送信されるACK要求で使用してはならないことに注意してください。これらのヘッダーフィールドは、これらのリクエストに存在する場合は無視する必要があります。
An ACK request for a 2xx response MUST contain only those Require and Proxy-Require values that were present in the initial request.
2xx応答のACK要求には、最初の要求に存在したRequire値とProxy-Require値のみが含まれている必要があります。
Example:
例：
UAC->UAS: INVITE sip:watson@bell-telephone.com SIP/2.0
Require: 100rel
UAS->UAC: SIP/2.0 420 Bad Extension
Unsupported: 100rel
This behavior ensures that the client-server interaction will proceed without delay when all options are understood by both sides, and only slow down if options are not understood (as in the example above). For a well-matched client-server pair, the interaction proceeds quickly, saving a round-trip often required by negotiation mechanisms. In addition, it also removes ambiguity when the client requires features that the server does not understand. Some features, such as call handling fields, are only of interest to end systems.
この動作により、すべてのオプションが両側で理解されている場合はクライアントサーバーの相互作用が遅延なく進行し、オプションが理解されていない場合にのみ速度が低下します（上記の例のように）。完全に一致したクライアント/サーバーのペアの場合、対話は迅速に進行し、ネゴシエーションメカニズムでしばしば必要とされる往復を節約します。さらに、クライアントがサーバーが理解できない機能を必要とする場合のあいまいさも取り除きます。コール処理フィールドなどの一部の機能は、エンドシステムのみが対象です。
Assuming the UAS understands any extensions required by the client, the UAS examines the body of the message, and the header fields that describe it. If there are any bodies whose type (indicated by the Content-Type), language (indicated by the Content-Language) or encoding (indicated by the Content-Encoding) are not understood, and that body part is not optional (as indicated by the Content-Disposition header field), the UAS MUST reject the request with a 415 (Unsupported Media Type) response. The response MUST contain an Accept header field listing the types of all bodies it understands, in the event the request contained bodies of types not supported by the UAS. If the request contained content encodings not understood by the UAS, the response MUST contain an Accept-Encoding header field listing the encodings understood by the UAS. If the request contained content with languages not understood by the UAS, the response MUST contain an Accept-Language header field indicating the languages understood by the UAS. Beyond these checks, body handling depends on the method and type. For further information on the processing of content-specific header fields, see Section 7.4 as well as Section 20.11 through 20.15.
UASがクライアントに必要な拡張機能を理解していると仮定すると、UASはメッセージの本文と、それを説明するヘッダーフィールドを調べます。タイプ（Content-Typeで示される）、言語（Content-Languageで示される）、またはエンコード（Content-Encodingで示される）が理解されていないボディがあり、そのボディパーツがオプションではない場合（ Content-Dispositionヘッダーフィールド）、UASは415（Unsupported Media Type）応答で要求を拒否する必要があります。 UASでサポートされていないタイプのボディがリクエストに含まれている場合、応答には、それが理解するすべてのボディのタイプをリストするAcceptヘッダーフィールドが含まれている必要があります。リクエストにUASで理解されないコンテンツエンコーディングが含まれている場合、応答には、UASで理解されるエンコーディングをリストするAccept-Encodingヘッダーフィールドを含める必要があります。リクエストにUASが理解できない言語のコンテンツが含まれている場合、応答には、UASが理解する言語を示すAccept-Languageヘッダーフィールドを含める必要があります。これらのチェックの他に、ボディの処理はメソッドとタイプに依存します。コンテンツ固有のヘッダーフィールドの処理の詳細については、セクション7.4およびセクション20.11から20.15を参照してください。
A UAS that wishes to apply some extension when generating the response MUST NOT do so unless support for that extension is indicated in the Supported header field in the request. If the desired extension is not supported, the server SHOULD rely only on baseline SIP and any other extensions supported by the client. In rare circumstances, where the server cannot process the request without the extension, the server MAY send a 421 (Extension Required) response. This response indicates that the proper response cannot be generated without support of a specific extension. The needed extension(s) MUST be included in a Require header field in the response. This behavior is NOT RECOMMENDED, as it will generally break interoperability.
応答の生成時に拡張機能を適用したいUASは、その拡張機能のサポートがリクエストのサポートされているヘッダーフィールドで指定されていない限り、そうしてはなりません。必要な拡張機能がサポートされていない場合、サーバーはベースラインSIPとクライアントがサポートするその他の拡張機能のみに依存する必要があります（SHOULD）。まれな状況では、サーバーが拡張なしで要求を処理できない場合、サーバーは421（Extension Required）応答を送信できます（MAY）。この応答は、特定の拡張機能のサポートなしでは適切な応答を生成できないことを示しています。必要な拡張子は、応答のRequireヘッダーフィールドに含める必要があります。通常、相互運用性が損なわれるため、この動作は推奨されません。
Any extensions applied to a non-421 response MUST be listed in a Require header field included in the response. Of course, the server MUST NOT apply extensions not listed in the Supported header field in the request. As a result of this, the Require header field in a response will only ever contain option tags defined in standards-track RFCs.
非421応答に適用される拡張機能は、応答に含まれるRequireヘッダーフィールドにリストする必要があります。もちろん、サーバーはリクエストのSupportedヘッダーフィールドにリストされていない拡張機能を適用してはいけません。この結果、応答のRequireヘッダーフィールドには、標準化過程のRFCで定義されたオプションタグのみが含まれます。
Assuming all of the checks in the previous subsections are passed, the UAS processing becomes method-specific. Section 10 covers the REGISTER request, Section 11 covers the OPTIONS request, Section 13 covers the INVITE request, and Section 15 covers the BYE request.
前のサブセクションのすべてのチェックに合格すると、UAS処理はメソッド固有になります。セクション10はREGISTERリクエストをカバーし、セクション11はOPTIONSリクエストをカバーし、セクション13はINVITEリクエストをカバーし、セクション15はBYEリクエストをカバーします。
When a UAS wishes to construct a response to a request, it follows the general procedures detailed in the following subsections. Additional behaviors specific to the response code in question, which are not detailed in this section, may also be required.
UASが要求への応答を作成する場合、以下のサブセクションで説明する一般的な手順に従います。このセクションで詳しく説明されていない、問題の応答コードに固有の追加の動作も必要になる場合があります。
Once all procedures associated with the creation of a response have been completed, the UAS hands the response back to the server transaction from which it received the request.
応答の作成に関連するすべての手順が完了すると、UASは要求を受信したサーバートランザクションに応答を返します。
One largely non-method-specific guideline for the generation of responses is that UASs SHOULD NOT issue a provisional response for a non-INVITE request. Rather, UASs SHOULD generate a final response to a non-INVITE request as soon as possible.
応答を生成するためのメソッド固有ではないガイドラインの1つは、UASが非INVITE要求に対して暫定応答を発行してはならないことです。むしろ、UASは、INVITE以外の要求に対する最終応答をできるだけ早く生成する必要があります（SHOULD）。
When a 100 (Trying) response is generated, any Timestamp header field present in the request MUST be copied into this 100 (Trying) response. If there is a delay in generating the response, the UAS SHOULD add a delay value into the Timestamp value in the response. This value MUST contain the difference between the time of sending of the response and receipt of the request, measured in seconds.
100（Trying）応答が生成されると、リクエストに存在するすべてのTimestampヘッダーフィールドがこの100（Trying）応答にコピーされる必要があります。応答の生成に遅延がある場合、UASは応答のタイムスタンプ値に遅延値を追加する必要があります（SHOULD）。この値には、秒単位で測定された、応答の送信時間と要求の受信時間の差が含まれている必要があります。
The From field of the response MUST equal the From header field of the request. The Call-ID header field of the response MUST equal the Call-ID header field of the request. The CSeq header field of the response MUST equal the CSeq field of the request. The Via header field values in the response MUST equal the Via header field values in the request and MUST maintain the same ordering.
応答のFromフィールドは、要求のFromヘッダーフィールドと等しい必要があります。応答のCall-IDヘッダーフィールドは、要求のCall-IDヘッダーフィールドと等しい必要があります。応答のCSeqヘッダーフィールドは、要求のCSeqフィールドと等しい必要があります。応答のViaヘッダーフィールド値は、要求のViaヘッダーフィールド値と等しくなければならず、同じ順序を維持する必要があります。
If a request contained a To tag in the request, the To header field in the response MUST equal that of the request. However, if the To header field in the request did not contain a tag, the URI in the To header field in the response MUST equal the URI in the To header field; additionally, the UAS MUST add a tag to the To header field in the response (with the exception of the 100 (Trying) response, in which a tag MAY be present). This serves to identify the UAS that is responding, possibly resulting in a component of a dialog ID. The same tag MUST be used for all responses to that request, both final and provisional (again excepting the 100 (Trying)). Procedures for the generation of tags are defined in Section 19.3.
リクエストにリクエストにToタグが含まれている場合、レスポンスのToヘッダーフィールドはリクエストのToヘッダーフィールドと同じである必要があります。ただし、リクエストのToヘッダーフィールドにタグが含まれていない場合、応答のToヘッダーフィールドのURIは、ToヘッダーフィールドのURIと等しくなければなりません。さらに、UASは、応答のToヘッダーフィールドにタグを追加する必要があります（タグが存在する可能性がある100（Trying）応答を除く）。これは、応答しているUASを識別するのに役立ち、ダイアログIDのコンポーネントになる可能性があります。最終および暫定の両方で、その要求に対するすべての応答に同じタグを使用する必要があります（これも100（試行中）を除く）。タグの生成手順はセクション19.3で定義されています。
A stateless UAS is a UAS that does not maintain transaction state. It replies to requests normally, but discards any state that would ordinarily be retained by a UAS after a response has been sent. If a stateless UAS receives a retransmission of a request, it regenerates the response and resends it, just as if it were replying to the first instance of the request. A UAS cannot be stateless unless the request processing for that method would always result in the same response if the requests are identical. This rules out stateless registrars, for example. Stateless UASs do not use a transaction layer; they receive requests directly from the transport layer and send responses directly to the transport layer.
ステートレスUASは、トランザクション状態を維持しないUASです。通常は要求に応答しますが、応答が送信された後にUASが通常保持するすべての状態を破棄します。ステートレスUASが要求の再送信を受信すると、まるで要求の最初のインスタンスに応答しているかのように、応答を再生成して再送信します。要求が同一である場合、そのメソッドの要求処理が常に同じ応答になる場合を除いて、UASをステートレスにすることはできません。これにより、たとえば、ステートレスレジストラが除外されます。ステートレスUASはトランザクションレイヤーを使用しません。トランスポート層から直接要求を受け取り、トランスポート層に直接応答を送信します。
The stateless UAS role is needed primarily to handle unauthenticated requests for which a challenge response is issued. If unauthenticated requests were handled statefully, then malicious floods of unauthenticated requests could create massive amounts of transaction state that might slow or completely halt call processing in a UAS, effectively creating a denial of service condition; for more information see Section 26.1.5.
ステートレスUASロールは、チャレンジ応答が発行される認証されていないリクエストを処理するために主に必要です。認証されていない要求がステートフルに処理された場合、認証されていない要求の悪意のあるフラッドにより大量のトランザクション状態が発生し、UASでのコール処理が遅くなったり完全に停止したりして、事実上サービス拒否状態が発生します。詳細は項26.1.5を参照してください。
The most important behaviors of a stateless UAS are the following:
ステートレスUASの最も重要な動作は次のとおりです。
o A stateless UAS MUST NOT send provisional (1xx) responses.
o ステートレスUASは暫定（1xx）応答を送信してはならない（MUST NOT）。
o A stateless UAS MUST NOT retransmit responses.
o ステートレスUASは応答を再送信してはなりません。
o A stateless UAS MUST ignore ACK requests.
o ステートレスUASは、ACK要求を無視する必要があります。
o A stateless UAS MUST ignore CANCEL requests.
o ステートレスUASはCANCEL要求を無視する必要があります。
o To header tags MUST be generated for responses in a stateless manner - in a manner that will generate the same tag for the same request consistently. For information on tag construction see Section 19.3.
o ヘッダーに対して、ステートレスな方法でタグを生成する必要があります-同じリクエストに対して同じタグを一貫して生成する方法で。タグの構成については、セクション19.3を参照してください。
In all other respects, a stateless UAS behaves in the same manner as a stateful UAS. A UAS can operate in either a stateful or stateless mode for each new request.
他のすべての点で、ステートレスUASはステートフルUASと同じように動作します。 UASは、新しい要求ごとにステートフルモードまたはステートレスモードで動作できます。
In some architectures it may be desirable to reduce the processing load on proxy servers that are responsible for routing requests, and improve signaling path robustness, by relying on redirection.
一部のアーキテクチャでは、リダイレクトに依存することにより、ルーティング要求を担当するプロキシサーバーの処理負荷を軽減し、シグナリングパスの堅牢性を向上させることが望ましい場合があります。
Redirection allows servers to push routing information for a request back in a response to the client, thereby taking themselves out of the loop of further messaging for this transaction while still aiding in locating the target of the request. When the originator of the request receives the redirection, it will send a new request based on the URI(s) it has received. By propagating URIs from the core of the network to its edges, redirection allows for considerable network scalability.
リダイレクションにより、サーバーはクライアントへの応答で要求のルーティング情報をプッシュバックできるため、要求のターゲットの特定を支援しながら、このトランザクションのさらなるメッセージングのループから抜け出すことができます。要求の発信者がリダイレクトを受信すると、受信したURIに基づいて新しい要求を送信します。 URIをネットワークのコアからエッジに伝播することにより、リダイレクトにより、かなりのネットワークスケーラビリティが可能になります。
A redirect server is logically constituted of a server transaction layer and a transaction user that has access to a location service of some kind (see Section 10 for more on registrars and location services). This location service is effectively a database containing mappings between a single URI and a set of one or more alternative locations at which the target of that URI can be found.
リダイレクトサーバーは、論理的にはサーバートランザクションレイヤーと、ある種のロケーションサービスにアクセスできるトランザクションユーザーで構成されます（レジストラーとロケーションサービスの詳細については、セクション10を参照してください）。このロケーションサービスは、単一のURIと、そのURIのターゲットを見つけることができる1つ以上の代替ロケーションのセットとの間のマッピングを含むデータベースです。
A redirect server does not issue any SIP requests of its own. After receiving a request other than CANCEL, the server either refuses the request or gathers the list of alternative locations from the location service and returns a final response of class 3xx. For well-formed CANCEL requests, it SHOULD return a 2xx response. This response ends the SIP transaction. The redirect server maintains transaction state for an entire SIP transaction. It is the responsibility of clients to detect forwarding loops between redirect servers.
リダイレクトサーバーは、独自のSIP要求を発行しません。 CANCEL以外のリクエストを受信した後、サーバーはリクエストを拒否するか、ロケーションサービスから代替ロケーションのリストを収集し、クラス3xxの最終応答を返します。整形式のCANCELリクエストの場合、2xx応答を返す必要があります。この応答はSIPトランザクションを終了します。リダイレクトサーバーは、SIPトランザクション全体のトランザクション状態を維持します。リダイレクトサーバー間の転送ループを検出するのはクライアントの責任です。
When a redirect server returns a 3xx response to a request, it populates the list of (one or more) alternative locations into the Contact header field. An "expires" parameter to the Contact header field values may also be supplied to indicate the lifetime of the Contact data.
リダイレクトサーバーが要求に対して3xx応答を返すと、（1つ以上の）代替場所のリストがContactヘッダーフィールドに入力されます。 Contactヘッダーフィールド値の「expires」パラメーターを指定して、Contactデータの存続期間を示すこともできます。
The Contact header field contains URIs giving the new locations or user names to try, or may simply specify additional transport parameters. A 301 (Moved Permanently) or 302 (Moved Temporarily) response may also give the same location and username that was targeted by the initial request but specify additional transport parameters such as a different server or multicast address to try, or a change of SIP transport from UDP to TCP or vice versa.
Contactヘッダーフィールドには、試行する新しい場所またはユーザー名を指定するURIが含まれるか、単に追加のトランスポートパラメーターを指定することもできます。 301（永久に移動）または302（一時的に移動）の応答では、最初のリクエストでターゲットにされたのと同じ場所とユーザー名が返される場合がありますが、試行する別のサーバーやマルチキャストアドレスなどの追加のトランスポートパラメーター、またはSIPトランスポートの変更が指定されますUDPからTCPへ、またはその逆。
However, redirect servers MUST NOT redirect a request to a URI equal to the one in the Request-URI; instead, provided that the URI does not point to itself, the server MAY proxy the request to the destination URI, or MAY reject it with a 404.
ただし、リダイレクトサーバーは、リクエストをRequest-URIのURIと等しいURIにリダイレクトしてはなりません（MUST NOT）。代わりに、URIがそれ自体を指していなければ、サーバーはリクエストを宛先URIにプロキシするか、404でリクエストを拒否してもよい（MAY）。
If a client is using an outbound proxy, and that proxy actually redirects requests, a potential arises for infinite redirection loops.
クライアントが送信プロキシを使用していて、そのプロキシが実際にリクエストをリダイレクトする場合、無限のリダイレクトループが発生する可能性があります。
Note that a Contact header field value MAY also refer to a different resource than the one originally called. For example, a SIP call connected to PSTN gateway may need to deliver a special informational announcement such as "The number you have dialed has been changed."
Contactヘッダーフィールドの値は、最初に呼び出されたリソースとは異なるリソースを参照する場合もあります。たとえば、PSTNゲートウェイに接続されたSIPコールは、「ダイヤルした番号が変更されました」などの特別な情報アナウンスを配信する必要がある場合があります。
A Contact response header field can contain any suitable URI indicating where the called party can be reached, not limited to SIP URIs. For example, it could contain URIs for phones, fax, or irc (if they were defined) or a mailto: (RFC 2368 [32]) URL. Section 26.4.4 discusses implications and limitations of redirecting a SIPS URI to a non-SIPS URI.
Contact応答ヘッダーフィールドには、SIP URIに限らず、着信側に到達できる場所を示す適切なURIを含めることができます。たとえば、電話、ファックス、またはirc（定義されている場合）、またはmailto：（RFC 2368 [32]）URLのURIを含めることができます。セクション26.4.4では、SIPS URIを非SIP URIにリダイレクトすることの影響と制限について説明します。
The "expires" parameter of a Contact header field value indicates how long the URI is valid. The value of the parameter is a number indicating seconds. If this parameter is not provided, the value of the Expires header field determines how long the URI is valid. Malformed values SHOULD be treated as equivalent to 3600.
Contactヘッダーフィールド値の「expires」パラメーターは、URIが有効な期間を示します。パラメータの値は秒を示す数値です。このパラメーターを指定しない場合、Expiresヘッダーフィールドの値によって、URIの有効期間が決まります。不正な形式の値は3600と同等として扱われる必要があります（SHOULD）。
This provides a modest level of backwards compatibility with RFC 2543, which allowed absolute times in this header field. If an absolute time is received, it will be treated as malformed, and then default to 3600.
これにより、RFC 2543との後方互換性が適度なレベルになり、このヘッダーフィールドで絶対時間が許可されました。絶対時刻が受信されると、形式が正しくないものとして扱われ、デフォルトで3600になります。
Redirect servers MUST ignore features that are not understood (including unrecognized header fields, any unknown option tags in Require, or even method names) and proceed with the redirection of the request in question.
リダイレクトサーバーは、認識されない機能（認識されないヘッダーフィールド、必須の不明なオプションタグ、メソッド名さえも含む）を無視し、問題の要求のリダイレクトを続行する必要があります。
9 Canceling a Request
9リクエストのキャンセル
The previous section has discussed general UA behavior for generating requests and processing responses for requests of all methods. In this section, we discuss a general purpose method, called CANCEL.
前のセクションでは、リクエストを生成し、すべてのメソッドのリクエストに対する応答を処理するための一般的なUAの動作について説明しました。このセクションでは、CANCELと呼ばれる汎用メソッドについて説明します。
The CANCEL request, as the name implies, is used to cancel a previous request sent by a client. Specifically, it asks the UAS to cease processing the request and to generate an error response to that request. CANCEL has no effect on a request to which a UAS has already given a final response. Because of this, it is most useful to CANCEL requests to which it can take a server long time to respond. For this reason, CANCEL is best for INVITE requests, which can take a long time to generate a response. In that usage, a UAS that receives a CANCEL request for an INVITE, but has not yet sent a final response, would "stop ringing", and then respond to the INVITE with a specific error response (a 487).
CANCELリクエストは、その名前が示すように、クライアントから送信された前のリクエストをキャンセルするために使用されます。具体的には、UASに要求の処理を中止し、その要求に対するエラー応答を生成するように要求します。 CANCELは、UASがすでに最終応答を出した要求には影響を与えません。このため、サーバーが応答するのに長時間かかる可能性のあるリクエストをキャンセルするのが最も便利です。このため、CANCELは、応答の生成に長時間かかる可能性があるINVITEリクエストに最適です。その使用法では、INVITEのCANCEL要求を受信したが、まだ最終応答を送信していないUASは、「呼び出しを停止」し、特定のエラー応答（a 487）でINVITEに応答します。
CANCEL requests can be constructed and sent by both proxies and user agent clients. Section 15 discusses under what conditions a UAC would CANCEL an INVITE request, and Section 16.10 discusses proxy usage of CANCEL.
CANCELリクエストは、プロキシとユーザーエージェントクライアントの両方で作成および送信できます。セクション15では、UACがINVITEリクエストをキャンセルする条件について説明し、セクション16.10では、CANCELのプロキシの使用について説明します。
A stateful proxy responds to a CANCEL, rather than simply forwarding a response it would receive from a downstream element. For that reason, CANCEL is referred to as a "hop-by-hop" request, since it is responded to at each stateful proxy hop.
ステートフルプロキシは、ダウンストリーム要素から受信する応答を単に転送するのではなく、CANCELに応答します。そのため、CANCELは各ステートフルプロキシホップで応答されるため、CANCELは「ホップバイホップ」要求と呼ばれます。
A CANCEL request SHOULD NOT be sent to cancel a request other than INVITE.
INVITE以外のリクエストをキャンセルするためにCANCELリクエストを送信してはなりません。
Since requests other than INVITE are responded to immediately, sending a CANCEL for a non-INVITE request would always create a race condition.
INVITE以外のリクエストはすぐに応答されるため、INVITE以外のリクエストに対してCANCELを送信すると、常に競合状態が発生します。
The following procedures are used to construct a CANCEL request. The Request-URI, Call-ID, To, the numeric part of CSeq, and From header fields in the CANCEL request MUST be identical to those in the request being cancelled, including tags. A CANCEL constructed by a client MUST have only a single Via header field value matching the top Via value in the request being cancelled. Using the same values for these header fields allows the CANCEL to be matched with the request it cancels (Section 9.2 indicates how such matching occurs). However, the method part of the CSeq header field MUST have a value of CANCEL. This allows it to be identified and processed as a transaction in its own right (See Section 17).
次の手順は、CANCEL要求を作成するために使用されます。 CANCELリクエストのRequest-URI、Call-ID、To、CSeqの数値部分、およびFromヘッダーフィールドは、タグを含め、キャンセルされるリクエストのフィールドと同じでなければなりません。クライアントによって構築されたCANCELは、キャンセルされるリクエストの最上位のVia値と一致する単一のViaヘッダーフィールド値のみを持っている必要があります。これらのヘッダーフィールドに同じ値を使用すると、CANCELをキャンセルするリクエストと一致させることができます（9.2節は、そのような一致がどのように発生するかを示しています）。ただし、CSeqヘッダーフィールドのメソッド部分にはCANCELの値が必要です。これにより、それ自体をトランザクションとして識別および処理できます（セクション17を参照）。
If the request being cancelled contains a Route header field, the CANCEL request MUST include that Route header field's values.
キャンセルされるリクエストにルートヘッダーフィールドが含まれている場合、キャンセルリクエストにはそのルートヘッダーフィールドの値を含める必要があります。
This is needed so that stateless proxies are able to route CANCEL requests properly.
これは、ステートレスプロキシがCANCELリクエストを適切にルーティングできるようにするために必要です。
The CANCEL request MUST NOT contain any Require or Proxy-Require header fields.
CANCELリクエストには、RequireまたはProxy-Requireヘッダーフィールドを含めることはできません。
Once the CANCEL is constructed, the client SHOULD check whether it has received any response (provisional or final) for the request being cancelled (herein referred to as the "original request").
CANCELが構築されると、クライアントは、キャンセルされる要求（以下、「元の要求」と呼ばれます）に対する応答（仮または最終）を受け取ったかどうかを確認する必要があります（SHOULD）。
If no provisional response has been received, the CANCEL request MUST NOT be sent; rather, the client MUST wait for the arrival of a provisional response before sending the request. If the original request has generated a final response, the CANCEL SHOULD NOT be sent, as it is an effective no-op, since CANCEL has no effect on requests that have already generated a final response. When the client decides to send the CANCEL, it creates a client transaction for the CANCEL and passes it the CANCEL request along with the destination address, port, and transport. The destination address, port, and transport for the CANCEL MUST be identical to those used to send the original request.
暫定応答が受信されていない場合、CANCEL要求を送信してはなりません。むしろ、クライアントはリクエストを送信する前に暫定応答の到着を待たなければなりません（MUST）。元の要求が最終応答を生成した場合、CANCELはすでに最終応答を生成した要求に影響を与えないため、これは効果的な何もしないので送信しないでください。クライアントがCANCELを送信することを決定すると、CANCELのクライアントトランザクションを作成し、宛先アドレス、ポート、トランスポートと共にCANCEL要求を渡します。 CANCELの宛先アドレス、ポート、およびトランスポートは、元の要求を送信するために使用されたものと同一でなければなりません。
If it was allowed to send the CANCEL before receiving a response for the previous request, the server could receive the CANCEL before the original request.
前の要求に対する応答を受信する前にCANCELを送信することが許可されていた場合、サーバーは元の要求の前にCANCELを受信する可能性があります。
Note that both the transaction corresponding to the original request and the CANCEL transaction will complete independently. However, a UAC canceling a request cannot rely on receiving a 487 (Request Terminated) response for the original request, as an RFC 2543- compliant UAS will not generate such a response. If there is no final response for the original request in 64*T1 seconds (T1 is defined in Section 17.1.1.1), the client SHOULD then consider the original transaction cancelled and SHOULD destroy the client transaction handling the original request.
元の要求に対応するトランザクションとCANCELトランザクションの両方が独立して完了することに注意してください。ただし、RFC 2543準拠のUASはそのような応答を生成しないため、要求をキャンセルするUACは、元の要求の487（Request Terminated）応答の受信に依存できません。 64 * T1秒（T1はセクション17.1.1.1で定義されています）で元の要求に対する最終応答がない場合、クライアントは元のトランザクションがキャンセルされたと見なし、元の要求を処理するクライアントトランザクションを破棄する必要があります（SHOULD）。
The CANCEL method requests that the TU at the server side cancel a pending transaction. The TU determines the transaction to be cancelled by taking the CANCEL request, and then assuming that the request method is anything but CANCEL or ACK and applying the transaction matching procedures of Section 17.2.3. The matching transaction is the one to be cancelled.
CANCELメソッドは、サーバー側のTUが保留中のトランザクションをキャンセルすることを要求します。 TUはCANCEL要求を取り、要求メソッドがCANCELまたはACK以外であると想定し、セクション17.2.3のトランザクション照合手順を適用することにより、キャンセルするトランザクションを決定します。一致するトランザクションはキャンセルされるトランザクションです。
The processing of a CANCEL request at a server depends on the type of server. A stateless proxy will forward it, a stateful proxy might respond to it and generate some CANCEL requests of its own, and a UAS will respond to it. See Section 16.10 for proxy treatment of CANCEL.
サーバーでのCANCEL要求の処理は、サーバーのタイプによって異なります。ステートレスプロキシはそれを転送し、ステートフルプロキシはそれに応答して独自のCANCEL要求を生成し、UASはそれに応答します。 CANCELの代理処理については、セクション16.10を参照してください。
A UAS first processes the CANCEL request according to the general UAS processing described in Section 8.2. However, since CANCEL requests are hop-by-hop and cannot be resubmitted, they cannot be challenged by the server in order to get proper credentials in an Authorization header field. Note also that CANCEL requests do not contain a Require header field.
UASはまず、セクション8.2で説明されている一般的なUAS処理に従ってCANCEL要求を処理します。ただし、CANCEL要求はホップバイホップであり、再送信できないため、Authorizationヘッダーフィールドで適切な資格情報を取得するためにサーバーから要求を受けることはできません。 CANCELリクエストにはRequireヘッダーフィールドが含まれていないことにも注意してください。
If the UAS did not find a matching transaction for the CANCEL according to the procedure above, it SHOULD respond to the CANCEL with a 481 (Call Leg/Transaction Does Not Exist). If the transaction for the original request still exists, the behavior of the UAS on receiving a CANCEL request depends on whether it has already sent a final response for the original request. If it has, the CANCEL request has no effect on the processing of the original request, no effect on any session state, and no effect on the responses generated for the original request. If the UAS has not issued a final response for the original request, its behavior depends on the method of the original request. If the original request was an INVITE, the UAS SHOULD immediately respond to the INVITE with a 487 (Request Terminated). A CANCEL request has no impact on the processing of transactions with any other method defined in this specification.
UASが上記の手順に従ってCANCELに一致するトランザクションを見つけられなかった場合は、481でCANCELに応答する必要があります（コールレッグ/トランザクションは存在しません）。元のリクエストのトランザクションがまだ存在する場合、CANCELリクエストを受信したときのUASの動作は、元のリクエストの最終応答がすでに送信されているかどうかによって異なります。そうである場合、CANCEL要求は、元の要求の処理、セッション状態、および元の要求に対して生成された応答に影響を与えません。 UASが元の要求に対する最終応答を発行していない場合、その動作は元の要求のメソッドによって異なります。元のリクエストがINVITEだった場合、UASは487（リクエスト終了）ですぐにINVITEに応答する必要があります（SHOULD）。 CANCEL要求は、この仕様で定義されている他のメソッドを使用したトランザクションの処理には影響を与えません。
Regardless of the method of the original request, as long as the CANCEL matched an existing transaction, the UAS answers the CANCEL request itself with a 200 (OK) response. This response is constructed following the procedures described in Section 8.2.6 noting that the To tag of the response to the CANCEL and the To tag in the response to the original request SHOULD be the same. The response to CANCEL is passed to the server transaction for transmission.
元の要求の方法に関係なく、CANCELが既存のトランザクションと一致する限り、UASはCANCEL要求自体に200（OK）応答で応答します。この応答は、セクション8.2.6で説明されている手順に従って作成されます。CANCELへの応答のToタグと元の要求への応答のToタグは同じである必要があります。 CANCELへの応答は、送信のためにサーバートランザクションに渡されます。
10 Registrations
10登録
SIP offers a discovery capability. If a user wants to initiate a session with another user, SIP must discover the current host(s) at which the destination user is reachable. This discovery process is frequently accomplished by SIP network elements such as proxy servers and redirect servers which are responsible for receiving a request, determining where to send it based on knowledge of the location of the user, and then sending it there. To do this, SIP network elements consult an abstract service known as a location service, which provides address bindings for a particular domain. These address bindings map an incoming SIP or SIPS URI, sip:bob@biloxi.com, for example, to one or more URIs that are somehow "closer" to the desired user, sip:bob@engineering.biloxi.com, for example. Ultimately, a proxy will consult a location service that maps a received URI to the user agent(s) at which the desired recipient is currently residing.
SIPは検出機能を提供します。ユーザーが別のユーザーとのセッションを開始したい場合、SIPは宛先ユーザーが到達可能な現在のホストを検出する必要があります。この検出プロセスは、要求を受信し、ユーザーの場所の知識に基づいて送信先を決定し、そこに送信するプロキシサーバーやリダイレクトサーバーなどのSIPネットワーク要素によって頻繁に実行されます。これを行うために、SIPネットワーク要素は、特定のドメインにアドレスバインディングを提供するロケーションサービスと呼ばれる抽象的なサービスを参照します。これらのアドレスバインディングは、着信SIPまたはSIPS URI、たとえばsip：bob@biloxi.comを、たとえば、目的のユーザーsip：bob@engineering.biloxi.comに何らかの形で「近い」1つ以上のURIにマッピングします。 。最終的に、プロキシは、受信したURIを、目的の受信者が現在存在するユーザーエージェントにマップするロケーションサービスに問い合わせます。
Registration creates bindings in a location service for a particular domain that associates an address-of-record URI with one or more contact addresses. Thus, when a proxy for that domain receives a request whose Request-URI matches the address-of-record, the proxy will forward the request to the contact addresses registered to that address-of-record. Generally, it only makes sense to register an address-of-record at a domain's location service when requests for that address-of-record would be routed to that domain. In most cases, this means that the domain of the registration will need to match the domain in the URI of the address-of-record.
登録により、特定のドメインのロケーションサービスにバインディングが作成され、レコードのアドレスURIが1つ以上の連絡先アドレスに関連付けられます。したがって、そのドメインのプロキシが、Request-URIがレコードのアドレスと一致する要求を受信すると、プロキシはそのレコードをそのレコードのアドレスに登録されている連絡先アドレスに転送します。一般に、レコードのアドレスの要求がそのドメインにルーティングされる場合にのみ、ドメインのロケーションサービスにレコードのアドレスを登録することは意味があります。ほとんどの場合、これは、登録のドメインがレコードのアドレスのURIのドメインと一致する必要があることを意味します。
There are many ways by which the contents of the location service can be established. One way is administratively. In the above example, Bob is known to be a member of the engineering department through access to a corporate database. However, SIP provides a mechanism for a UA to create a binding explicitly. This mechanism is known as registration.
位置情報サービスのコンテンツを確立する方法はたくさんあります。 1つの方法は、管理です。上記の例では、Bobは企業データベースへのアクセスを通じてエンジニアリング部門のメンバーであることがわかっています。ただし、SIPは、UAが明示的にバインディングを作成するためのメカニズムを提供します。このメカニズムは登録と呼ばれます。
Registration entails sending a REGISTER request to a special type of UAS known as a registrar. A registrar acts as the front end to the location service for a domain, reading and writing mappings based on the contents of REGISTER requests. This location service is then typically consulted by a proxy server that is responsible for routing requests for that domain.
登録には、レジストラと呼ばれる特殊なタイプのUASにREGISTERリクエストを送信する必要があります。レジストラは、ドメインのロケーションサービスへのフロントエンドとして機能し、REGISTERリクエストの内容に基づいてマッピングを読み書きします。この位置情報サービスは、通常、そのドメインへの要求のルーティングを担当するプロキシサーバーによって参照されます。
An illustration of the overall registration process is given in Figure 2. Note that the registrar and proxy server are logical roles that can be played by a single device in a network; for purposes of clarity the two are separated in this illustration. Also note that UAs may send requests through a proxy server in order to reach a registrar if the two are separate elements.
登録プロセス全体の図を図2に示します。レジストラとプロキシサーバーは、ネットワーク内の単一のデバイスが実行できる論理的な役割であることに注意してください。わかりやすくするために、この図では2つを分離しています。また、2つの要素が別々の場合、UAはレジストラに到達するためにプロキシサーバーを介してリクエストを送信する場合があることに注意してください。
SIP does not mandate a particular mechanism for implementing the location service. The only requirement is that a registrar for some domain MUST be able to read and write data to the location service, and a proxy or a redirect server for that domain MUST be capable of reading that same data. A registrar MAY be co-located with a particular SIP proxy server for the same domain.
SIPは、ロケーションサービスを実装するための特定のメカニズムを義務付けていません。唯一の要件は、一部のドメインのレジストラがロケーションサービスに対してデータを読み書きできる必要があり、そのドメインのプロキシまたはリダイレクトサーバーが同じデータを読み取ることができる必要があることです。レジストラは、同じドメインの特定のSIPプロキシサーバーと同じ場所に配置できます。
REGISTER requests add, remove, and query bindings. A REGISTER request can add a new binding between an address-of-record and one or more contact addresses. Registration on behalf of a particular address-of-record can be performed by a suitably authorized third party. A client can also remove previous bindings or query to determine which bindings are currently in place for an address-of-record.
REGISTERリクエストは、バインディングの追加、削除、クエリを行います。 REGISTER要求は、レコードのアドレスと1つ以上の連絡先アドレスの間に新しいバインディングを追加できます。特定の記録アドレスの代理としての登録は、適切に承認された第三者によって実行できます。クライアントは、以前のバインディングまたはクエリを削除して、レコードのアドレスに対して現在どのバインディングが設定されているかを判断することもできます。
Except as noted, the construction of the REGISTER request and the behavior of clients sending a REGISTER request is identical to the general UAC behavior described in Section 8.1 and Section 17.1.
特に明記されていない限り、REGISTERリクエストの構造と、REGISTERリクエストを送信するクライアントの動作は、セクション8.1とセクション17.1で説明されている一般的なUACの動作と同じです。
A REGISTER request does not establish a dialog. A UAC MAY include a Route header field in a REGISTER request based on a pre-existing route set as described in Section 8.1. The Record-Route header field has no meaning in REGISTER requests or responses, and MUST be ignored if present. In particular, the UAC MUST NOT create a new route set based on the presence or absence of a Record-Route header field in any response to a REGISTER request.
REGISTERリクエストはダイアログを確立しません。 UACは、セクション8.1で説明されているように、既存のルートセットに基づいて、REGISTERリクエストにルートヘッダーフィールドを含めることができます。 Record-Routeヘッダーフィールドは、REGISTER要求または応答では意味がなく、存在する場合は無視する必要があります。特に、UACは、REGISTER要求への応答におけるRecord-Routeヘッダーフィールドの有無に基づいて、新しいルートセットを作成してはなりません（MUST NOT）。
The following header fields, except Contact, MUST be included in a REGISTER request. A Contact header field MAY be included:
Contactを除く次のヘッダーフィールドは、REGISTERリクエストに含める必要があります。連絡先ヘッダーフィールドを含めることができます：
Request-URI: The Request-URI names the domain of the location service for which the registration is meant (for example, "sip:chicago.com"). The "userinfo" and "@" components of the SIP URI MUST NOT be present.
Request-URI：Request-URIは、登録が意味するロケーションサービスのドメインを指定します（たとえば、「sip：chicago.com」）。 SIP URIの「userinfo」および「@」コンポーネントが存在してはなりません。
To: The To header field contains the address of record whose registration is to be created, queried, or modified. The To header field and the Request-URI field typically differ, as the former contains a user name. This address-of-record MUST be a SIP URI or SIPS URI.
To：Toヘッダーフィールドには、登録を作成、照会、または変更するレコードのアドレスが含まれます。 ToヘッダーフィールドとRequest-URIフィールドは、ユーザー名が含まれているため、通常は異なります。このレコードのアドレスは、SIP URIまたはSIPS URIである必要があります。
From: The From header field contains the address-of-record of the person responsible for the registration. The value is the same as the To header field unless the request is a third-party registration.
From：Fromヘッダーフィールドには、登録の責任者のレコードのアドレスが含まれます。リクエストがサードパーティの登録でない限り、値はToヘッダーフィールドと同じです。
Call-ID: All registrations from a UAC SHOULD use the same Call-ID header field value for registrations sent to a particular registrar.
Call-ID：UACからのすべての登録は、特定のレジストラに送信される登録に対して同じCall-IDヘッダーフィールド値を使用する必要があります（SHOULD）。
If the same client were to use different Call-ID values, a registrar could not detect whether a delayed REGISTER request might have arrived out of order.
同じクライアントが異なるCall-ID値を使用する場合、レジストラは、遅延したREGISTER要求が順不同で到着したかどうかを検出できませんでした。
CSeq: The CSeq value guarantees proper ordering of REGISTER requests. A UA MUST increment the CSeq value by one for each REGISTER request with the same Call-ID.
CSeq：CSeq値は、REGISTER要求の適切な順序を保証します。 UAは、同じCall-IDを持つREGISTER要求ごとにCSeq値を1つずつ増加させる必要があります。
Contact: REGISTER requests MAY contain a Contact header field with zero or more values containing address bindings.
Contact：REGISTERリクエストには、アドレスバインディングを含む0個以上の値を持つContactヘッダーフィールドが含まれる場合があります。
UAs MUST NOT send a new registration (that is, containing new Contact header field values, as opposed to a retransmission) until they have received a final response from the registrar for the previous one or the previous REGISTER request has timed out.
UAは、以前のレジストラからの最終応答を受信するか、以前のREGISTERリクエストがタイムアウトするまで、新しい登録（つまり、再送信ではなく新しいContactヘッダーフィールド値を含む）を送信してはなりません（MUST NOT）。
bob
+----+
| UA |
| |
+----+
|
|3)INVITE
| carol@chicago.com
chicago.com +--------+ V
+---------+ 2)Store|Location|4)Query +-----+
|Registrar|=======>| Service|<=======|Proxy|sip.chicago.com
+---------+ +--------+=======>+-----+
A 5)Resp |
| |
| |
1)REGISTER| |
| |
+----+ |
| UA |<-------------------------------+
cube2214a| | 6)INVITE
+----+ carol@cube2214a.chicago.com
carol
Figure 2: REGISTER example
図2：レジスタの例
The following Contact header parameters have a special meaning in REGISTER requests:
次のContactヘッダーパラメータは、REGISTERリクエストで特別な意味を持っています。
action: The "action" parameter from RFC 2543 has been deprecated. UACs SHOULD NOT use the "action" parameter.
action：RFC 2543の "action"パラメータは廃止されました。 UACは「アクション」パラメータを使用してはなりません。
expires: The "expires" parameter indicates how long the UA would like the binding to be valid. The value is a number indicating seconds. If this parameter is not provided, the value of the Expires header field is used instead. Implementations MAY treat values larger than 2**32-1 (4294967295 seconds or 136 years) as equivalent to 2**32-1. Malformed values SHOULD be treated as equivalent to 3600.
expires： "expires"パラメータは、UAがバインディングを有効にする期間を示します。値は秒を示す数値です。このパラメーターが指定されていない場合は、代わりにExpiresヘッダーフィールドの値が使用されます。実装は、2 ** 32-1（4294967295秒または136年）より大きい値を2 ** 32-1と同等として扱うことができます（MAY）。不正な形式の値は3600と同等として扱われる必要があります（SHOULD）。
The REGISTER request sent to a registrar includes the contact address(es) to which SIP requests for the address-of-record should be forwarded. The address-of-record is included in the To header field of the REGISTER request.
レジストラに送信されるREGISTER要求には、レコードのアドレスに対するSIP要求の転送先の連絡先アドレスが含まれます。レコードのアドレスは、REGISTERリクエストのToヘッダーフィールドに含まれます。
The Contact header field values of the request typically consist of SIP or SIPS URIs that identify particular SIP endpoints (for example, "sip:carol@cube2214a.chicago.com"), but they MAY use any URI scheme. A SIP UA can choose to register telephone numbers (with the tel URL, RFC 2806 [9]) or email addresses (with a mailto URL, RFC 2368 [32]) as Contacts for an address-of-record, for example.
リクエストのContactヘッダーフィールド値は通常、特定のSIPエンドポイントを識別するSIPまたはSIPS URI（たとえば、「sip：carol@cube2214a.chicago.com」）で構成されますが、任意のURIスキームを使用できます（MAY）。 SIP UAは、たとえば、電話番号（tel URL、RFC 2806 [9]を使用）または電子メールアドレス（mailto URL、RFC 2368 [32]を使用）をレコードのアドレスの連絡先として登録することを選択できます。
For example, Carol, with address-of-record "sip:carol@chicago.com", would register with the SIP registrar of the domain chicago.com. Her registrations would then be used by a proxy server in the chicago.com domain to route requests for Carol's address-of-record to her SIP endpoint.
たとえば、キャロルは、レコードのアドレスが「sip：carol@chicago.com」の場合、ドメインchicago.comのSIPレジストラに登録します。次に、彼女の登録を使用して、chicago.comドメインのプロキシサーバーがCarolのレコードのアドレスのリクエストを彼女のSIPエンドポイントにルーティングします。
Once a client has established bindings at a registrar, it MAY send subsequent registrations containing new bindings or modifications to existing bindings as necessary. The 2xx response to the REGISTER request will contain, in a Contact header field, a complete list of bindings that have been registered for this address-of-record at this registrar.
クライアントがレジストラでバインディングを確立すると、必要に応じて、新しいバインディングまたは既存のバインディングへの変更を含む後続の登録を送信できます（MAY）。 REGISTER要求への2xx応答には、Contactヘッダーフィールドに、このレジストラでこのレコードのアドレスに登録されているバインディングの完全なリストが含まれます。
If the address-of-record in the To header field of a REGISTER request is a SIPS URI, then any Contact header field values in the request SHOULD also be SIPS URIs. Clients should only register non-SIPS URIs under a SIPS address-of-record when the security of the resource represented by the contact address is guaranteed by other means. This may be applicable to URIs that invoke protocols other than SIP, or SIP devices secured by protocols other than TLS.
REGISTER要求のToヘッダーフィールドのレコードのアドレスがSIPS URIである場合、要求内のすべてのContactヘッダーフィールド値もSIPS URIである必要があります（SHOULD）。連絡先アドレスで表されるリソースのセキュリティが他の方法で保証されている場合、クライアントはSIPSレコードのアドレス下でのみ非SIP URIを登録する必要があります。これは、SIP以外のプロトコルを呼び出すURI、またはTLS以外のプロトコルで保護されたSIPデバイスに適用できます。
Registrations do not need to update all bindings. Typically, a UA only updates its own contact addresses.
登録ですべてのバインディングを更新する必要はありません。通常、UAは自身の連絡先アドレスのみを更新します。
When a client sends a REGISTER request, it MAY suggest an expiration interval that indicates how long the client would like the registration to be valid. (As described in Section 10.3, the registrar selects the actual time interval based on its local policy.)
クライアントがREGISTERリクエストを送信するとき、クライアントが登録を有効にしたい期間を示す有効期限を提案する場合があります。 （セクション10.3で説明したように、レジストラはローカルポリシーに基づいて実際の時間間隔を選択します。）
There are two ways in which a client can suggest an expiration interval for a binding: through an Expires header field or an "expires" Contact header parameter. The latter allows expiration intervals to be suggested on a per-binding basis when more than one binding is given in a single REGISTER request, whereas the former suggests an expiration interval for all Contact header field values that do not contain the "expires" parameter.
クライアントがバインディングの有効期限の間隔を提案するには、Expiresヘッダーフィールドまたは「expires」Contactヘッダーパラメーターを使用する2つの方法があります。後者では、単一のREGISTERリクエストで複数のバインディングが指定されている場合に、バインディングごとに有効期限の間隔を提案できますが、前者は、「expires」パラメータを含まないすべてのContactヘッダーフィールド値の有効期限を提案します。
If neither mechanism for expressing a suggested expiration time is present in a REGISTER, the client is indicating its desire for the server to choose.
提案された有効期限を表現するメカニズムがどちらもREGISTERに存在しない場合、クライアントはサーバーが選択したいという希望を示しています。
If more than one Contact is sent in a REGISTER request, the registering UA intends to associate all of the URIs in these Contact header field values with the address-of-record present in the To field. This list can be prioritized with the "q" parameter in the Contact header field. The "q" parameter indicates a relative preference for the particular Contact header field value compared to other bindings for this address-of-record. Section 16.6 describes how a proxy server uses this preference indication.
REGISTER要求で複数の連絡先が送信された場合、登録しているUAは、これらの連絡先ヘッダーフィールド値のすべてのURIを、宛先フィールドに存在するレコードのアドレスに関連付けます。このリストは、Contactヘッダーフィールドの「q」パラメーターで優先順位を付けることができます。 「q」パラメーターは、このレコードのアドレスの他のバインディングと比較した、特定のContactヘッダーフィールド値の相対的な優先度を示します。セクション16.6では、プロキシサーバーがこの設定指示をどのように使用するかについて説明します。
Registrations are soft state and expire unless refreshed, but can also be explicitly removed. A client can attempt to influence the expiration interval selected by the registrar as described in Section 10.2.1. A UA requests the immediate removal of a binding by specifying an expiration interval of "0" for that contact address in a REGISTER request. UAs SHOULD support this mechanism so that bindings can be removed before their expiration interval has passed.
登録はソフトな状態であり、更新しない限り有効期限が切れますが、明示的に削除することもできます。クライアントは、10.2.1項で説明されているように、レジストラによって選択された有効期限に影響を与えることを試みることができます。 UAは、REGISTERリクエストでその連絡先アドレスに有効期限間隔「0」を指定することにより、バインディングの即時削除を要求します。 UAはこのメカニズムをサポートする必要があります（SHOULD）。これにより、有効期限が切れる前にバインディングを削除できます。
The REGISTER-specific Contact header field value of "*" applies to all registrations, but it MUST NOT be used unless the Expires header field is present with a value of "0".
REGISTER固有のContactヘッダーフィールド値「*」はすべての登録に適用されますが、Expiresヘッダーフィールドに「0」の値が存在しない限り、これを使用してはなりません。
Use of the "*" Contact header field value allows a registering UA to remove all bindings associated with an address-of-record without knowing their precise values.
「*」Contactヘッダーフィールド値を使用すると、登録しているUAは、正確な値を知らなくても、レコードのアドレスに関連付けられているすべてのバインディングを削除できます。
A success response to any REGISTER request contains the complete list of existing bindings, regardless of whether the request contained a Contact header field. If no Contact header field is present in a REGISTER request, the list of bindings is left unchanged.
REGISTER要求に対する成功の応答には、要求にContactヘッダーフィールドが含まれているかどうかに関係なく、既存のバインディングの完全なリストが含まれています。 REGISTERリクエストにContactヘッダーフィールドが存在しない場合、バインディングのリストは変更されません。
Each UA is responsible for refreshing the bindings that it has previously established. A UA SHOULD NOT refresh bindings set up by other UAs.
各UAは、以前に確立したバインディングを更新します。 UAは、他のUAによってセットアップされたバインディングを更新してはなりません（SHOULD NOT）。
The 200 (OK) response from the registrar contains a list of Contact fields enumerating all current bindings. The UA compares each contact address to see if it created the contact address, using comparison rules in Section 19.1.4. If so, it updates the expiration time interval according to the expires parameter or, if absent, the Expires field value. The UA then issues a REGISTER request for each of its bindings before the expiration interval has elapsed. It MAY combine several updates into one REGISTER request.
レジストラからの200（OK）応答には、現在のすべてのバインディングを列挙するContactフィールドのリストが含まれています。 UAは、19.1.4項の比較ルールを使用して、各連絡先アドレスを比較して、連絡先アドレスを作成したかどうかを確認します。存在する場合、expiresパラメータ、または存在しない場合はExpiresフィールド値に従って、有効期限の時間間隔を更新します。次に、UAは、有効期限が経過する前に、各バインディングに対してREGISTER要求を発行します。複数の更新を1つのREGISTERリクエストに結合する場合があります。
A UA SHOULD use the same Call-ID for all registrations during a single boot cycle. Registration refreshes SHOULD be sent to the same network address as the original registration, unless redirected.
UAは、1回の起動サイクル中のすべての登録に同じCall-IDを使用する必要があります（SHOULD）。登録の更新は、リダイレクトされない限り、元の登録と同じネットワークアドレスに送信する必要があります（SHOULD）。
If the response for a REGISTER request contains a Date header field, the client MAY use this header field to learn the current time in order to set any internal clocks.
REGISTER要求の応答にDateヘッダーフィールドが含まれている場合、クライアントはこのヘッダーフィールドを使用して、内部クロックを設定するために現在の時刻を知ることができます（MAY）。
UAs can use three ways to determine the address to which to send registrations: by configuration, using the address-of-record, and multicast. A UA can be configured, in ways beyond the scope of this specification, with a registrar address. If there is no configured registrar address, the UA SHOULD use the host part of the address-of-record as the Request-URI and address the request there, using the normal SIP server location mechanisms [4]. For example, the UA for the user "sip:carol@chicago.com" addresses the REGISTER request to "sip:chicago.com".
UAは、3つの方法を使用して、登録を送信するアドレスを決定できます。構成による方法、レコードのアドレスを使用する方法、およびマルチキャストです。 UAは、この仕様の範囲を超える方法で、レジストラアドレスを使用して構成できます。レジストラアドレスが設定されていない場合、UAは、レコードのアドレスのホスト部分をRequest-URIとして使用し、通常のSIPサーバーロケーションメカニズムを使用して、リクエストをそこでアドレス指定する必要があります[4]。たとえば、ユーザー「sip：carol@chicago.com」のUAは、REGISTERリクエストを「sip：chicago.com」に送信します。
Finally, a UA can be configured to use multicast. Multicast registrations are addressed to the well-known "all SIP servers" multicast address "sip.mcast.net" (224.0.1.75 for IPv4). No well-known IPv6 multicast address has been allocated; such an allocation will be documented separately when needed. SIP UAs MAY listen to that address and use it to become aware of the location of other local users (see [33]); however, they do not respond to the request.
最後に、UAはマルチキャストを使用するように構成できます。マルチキャスト登録は、よく知られた「すべてのSIPサーバー」マルチキャストアドレス「sip.mcast.net」（IPv4の場合は224.0.1.75）に宛てられます。既知のIPv6マルチキャストアドレスは割り当てられていません。このような割り当ては、必要に応じて個別に文書化されます。 SIP UAはそのアドレスをリッスンし、それを使用して他のローカルユーザーの場所を認識することができます（[33]を参照）。ただし、リクエストには応答しません。
Multicast registration may be inappropriate in some environments, for example, if multiple businesses share the same local area network.
たとえば、複数の企業が同じローカルエリアネットワークを共有している場合など、一部の環境ではマルチキャストの登録が不適切な場合があります。
Once the REGISTER method has been constructed, and the destination of the message identified, UACs follow the procedures described in Section 8.1.2 to hand off the REGISTER to the transaction layer.
REGISTERメソッドが構築され、メッセージの宛先が特定されると、UACはセクション8.1.2で説明されている手順に従って、REGISTERをトランザクション層に渡します。
If the transaction layer returns a timeout error because the REGISTER yielded no response, the UAC SHOULD NOT immediately re-attempt a registration to the same registrar.
REGISTERが応答を返さなかったためにトランザクションレイヤーがタイムアウトエラーを返した場合、UACは同じレジストラへの登録をすぐに再試行してはなりません（SHOULD NOT）。
An immediate re-attempt is likely to also timeout. Waiting some reasonable time interval for the conditions causing the timeout to be corrected reduces unnecessary load on the network. No specific interval is mandated.
即時の再試行もタイムアウトになる可能性があります。タイムアウトが修正される原因となる状況をある程度の時間待機することで、ネットワークへの不要な負荷が軽減されます。特定の間隔は必須ではありません。
If a UA receives a 423 (Interval Too Brief) response, it MAY retry the registration after making the expiration interval of all contact addresses in the REGISTER request equal to or greater than the expiration interval within the Min-Expires header field of the 423 (Interval Too Brief) response.
UAが423（Interval Too Brief）応答を受信した場合、REGISTERリクエスト内のすべての連絡先アドレスの有効期限間隔を423のMin-Expiresヘッダーフィールド内の有効期限間隔以上にしてから、登録を再試行してもよい（MAY）間隔が短すぎます）応答。
A registrar is a UAS that responds to REGISTER requests and maintains a list of bindings that are accessible to proxy servers and redirect servers within its administrative domain. A registrar handles requests according to Section 8.2 and Section 17.2, but it accepts only REGISTER requests. A registrar MUST not generate 6xx responses.
レジストラは、REGISTER要求に応答し、その管理ドメイン内のプロキシサーバーとリダイレクトサーバーにアクセスできるバインディングのリストを維持するUASです。レジストラは、セクション8.2およびセクション17.2に従って要求を処理しますが、REGISTER要求のみを受け入れます。レジストラは6xx応答を生成してはならない（MUST NOT）。
A registrar MAY redirect REGISTER requests as appropriate. One common usage would be for a registrar listening on a multicast interface to redirect multicast REGISTER requests to its own unicast interface with a 302 (Moved Temporarily) response.
レジストラは、必要に応じてREGISTERリクエストをリダイレクトしてもよい（MAY）。一般的な使用法の1つは、マルチキャストインターフェイスでリッスンするレジストラが、マルチキャストREGISTER要求を302（Moved Temporarily）応答で独自のユニキャストインターフェイスにリダイレクトすることです。
Registrars MUST ignore the Record-Route header field if it is included in a REGISTER request. Registrars MUST NOT include a Record-Route header field in any response to a REGISTER request.
レジストラは、REGISTERリクエストに含まれている場合、Record-Routeヘッダーフィールドを無視する必要があります。レジストラは、REGISTER要求への応答にRecord-Routeヘッダーフィールドを含めてはなりません（MUST NOT）。
A registrar might receive a request that traversed a proxy which treats REGISTER as an unknown request and which added a Record-Route header field value.
レジストラは、REGISTERを不明な要求として扱い、Record-Routeヘッダーフィールド値を追加したプロキシを通過した要求を受信する場合があります。
A registrar has to know (for example, through configuration) the set of domain(s) for which it maintains bindings. REGISTER requests MUST be processed by a registrar in the order that they are received. REGISTER requests MUST also be processed atomically, meaning that a particular REGISTER request is either processed completely or not at all. Each REGISTER message MUST be processed independently of any other registration or binding changes.
レジストラは、バインディングを維持するドメインのセットを（たとえば、構成を通じて）知る必要があります。 REGISTERリクエストは、レジストラが受信した順に処理する必要があります。 REGISTERリクエストもアトミックに処理する必要があります。つまり、特定のREGISTERリクエストは完全に処理されるか、まったく処理されないかのどちらかです。各REGISTERメッセージは、他の登録やバインディングの変更とは無関係に処理される必要があります。
When receiving a REGISTER request, a registrar follows these steps:
REGISTERリクエストを受信すると、レジストラは次の手順に従います。
1. The registrar inspects the Request-URI to determine whether it has access to bindings for the domain identified in the Request-URI. If not, and if the server also acts as a proxy server, the server SHOULD forward the request to the addressed domain, following the general behavior for proxying messages described in Section 16.
1. レジストラはRequest-URIを検査して、Request-URIで識別されたドメインのバインディングにアクセスできるかどうかを判断します。そうでない場合、およびサーバーがプロキシサーバーとしても機能している場合、サーバーは、セクション16で説明されているプロキシメッセージの一般的な動作に従って、要求をアドレス指定されたドメインに転送する必要があります（SHOULD）。
2. To guarantee that the registrar supports any necessary extensions, the registrar MUST process the Require header field values as described for UASs in Section 8.2.2.
2. レジストラが必要な拡張をサポートすることを保証するために、レジストラは、セクション8.2.2でUASについて説明されているように、Requireヘッダーフィールド値を処理する必要があります。
3. A registrar SHOULD authenticate the UAC. Mechanisms for the authentication of SIP user agents are described in Section 22. Registration behavior in no way overrides the generic authentication framework for SIP. If no authentication mechanism is available, the registrar MAY take the From address as the asserted identity of the originator of the request.
3. レジストラはUACを認証する必要があります。 SIPユーザーエージェントの認証メカニズムについては、セクション22で説明します。登録の動作は、SIPの一般的な認証フレームワークをオーバーライドするものではありません。認証メカニズムが利用できない場合、レジストラは、要求の発信者のアサートされたIDとしてFromアドレスを取得できます（MAY）。
4. The registrar SHOULD determine if the authenticated user is authorized to modify registrations for this address-of-record. For example, a registrar might consult an authorization database that maps user names to a list of addresses-of-record for which that user has authorization to modify bindings. If the authenticated user is not authorized to modify bindings, the registrar MUST return a 403 (Forbidden) and skip the remaining steps.
4. レジストラは、認証されたユーザーがこのレコードのアドレスの登録を変更することを許可されているかどうかを決定する必要があります（SHOULD）。たとえば、レジストラは、ユーザーをバインドを変更する権限を持つレコードのアドレスのリストにユーザー名をマップする承認データベースを調べます。認証されたユーザーがバインディングの変更を許可されていない場合、レジストラは403（禁止）を返し、残りの手順をスキップする必要があります。
In architectures that support third-party registration, one entity may be responsible for updating the registrations associated with multiple addresses-of-record.
サードパーティの登録をサポートするアーキテクチャでは、1つのエンティティが複数のレコードのアドレスに関連付けられた登録の更新を担当する場合があります。
5. The registrar extracts the address-of-record from the To header field of the request. If the address-of-record is not valid for the domain in the Request-URI, the registrar MUST send a 404 (Not Found) response and skip the remaining steps. The URI MUST then be converted to a canonical form. To do that, all URI parameters MUST be removed (including the user-param), and any escaped characters MUST be converted to their unescaped form. The result serves as an index into the list of bindings.
5. レジストラは、要求のToヘッダーフィールドからレコードのアドレスを抽出します。 Record-of-recordがRequest-URIのドメインに対して有効でない場合、レジストラは404（Not Found）応答を送信し、残りの手順をスキップする必要があります。次に、URIを標準形式に変換する必要があります。そのためには、すべてのURIパラメーター（user-paramを含む）を削除する必要があり、エスケープされた文字はエスケープされていない形式に変換する必要があります。結果は、バインディングのリストへのインデックスとして機能します。
6. The registrar checks whether the request contains the Contact header field. If not, it skips to the last step. If the Contact header field is present, the registrar checks if there is one Contact field value that contains the special value "*" and an Expires field. If the request has additional Contact fields or an expiration time other than zero, the request is invalid, and the server MUST return a 400 (Invalid Request) and skip the remaining steps. If not, the registrar checks whether the Call-ID agrees with the value stored for each binding. If not, it MUST remove the binding. If it does agree, it MUST remove the binding only if the CSeq in the request is higher than the value stored for that binding. Otherwise, the update MUST be aborted and the request fails.
6. レジストラは、リクエストにContactヘッダーフィールドが含まれているかどうかを確認します。そうでない場合は、最後のステップにスキップします。 Contactヘッダーフィールドが存在する場合、レジストラは、特別な値「*」とExpiresフィールドを含むContactフィールド値が1つあるかどうかを確認します。リクエストに追加のContactフィールドまたはゼロ以外の有効期限がある場合、リクエストは無効であり、サーバーは400（無効なリクエスト）を返し、残りの手順をスキップする必要があります。そうでない場合、レジストラはCall-IDが各バインディングに保存されている値と一致するかどうかを確認します。そうでない場合は、バインディングを削除する必要があります。同意する場合は、リクエストのCSeqがそのバインディング用に保存されている値よりも高い場合にのみ、バインディングを削除する必要があります。それ以外の場合は、更新を中止する必要があり、要求は失敗します。
7. The registrar now processes each contact address in the Contact header field in turn. For each address, it determines the expiration interval as follows:
7. レジストラは、Contactヘッダーフィールドの各連絡先アドレスを順番に処理します。アドレスごとに、次のように有効期限を決定します。
- If the field value has an "expires" parameter, that value MUST be taken as the requested expiration.
- フィールド値に「expires」パラメーターがある場合、その値を要求された有効期限と見なす必要があります。
- If there is no such parameter, but the request has an Expires header field, that value MUST be taken as the requested expiration.
- そのようなパラメーターはないが、リクエストにExpiresヘッダーフィールドがある場合、その値はリクエストされた有効期限と見なされなければなりません（MUST）。
- If there is neither, a locally-configured default value MUST be taken as the requested expiration.
- どちらもない場合は、ローカルで構成されたデフォルト値を、要求された有効期限として使用する必要があります。
The registrar MAY choose an expiration less than the requested expiration interval. If and only if the requested expiration interval is greater than zero AND smaller than one hour AND less than a registrar-configured minimum, the registrar MAY reject the registration with a response of 423 (Interval Too Brief). This response MUST contain a Min-Expires header field that states the minimum expiration interval the registrar is willing to honor. It then skips the remaining steps.
レジストラは、要求された有効期限間隔よりも短い有効期限を選択する場合があります。リクエストされた有効期限間隔がゼロより大きく、1時間未満かつレジストラが設定した最小値よりも小さい場合に限り、レジストラは423（Interval Too Brief）の応答で登録を拒否してもよい（MAY）。この応答には、レジストラが受け入れることができる最小の有効期限間隔を示すMin-Expiresヘッダーフィールドが含まれている必要があります。その後、残りのステップをスキップします。
Allowing the registrar to set the registration interval protects it against excessively frequent registration refreshes while limiting the state that it needs to maintain and decreasing the likelihood of registrations going stale. The expiration interval of a registration is frequently used in the creation of services. An example is a follow-me service, where the user may only be available at a terminal for a brief period. Therefore, registrars should accept brief registrations; a request should only be rejected if the interval is so short that the refreshes would degrade registrar performance.
レジストラが登録間隔を設定できるようにすることで、過度に頻繁な登録の更新から保護しながら、維持する必要がある状態を制限し、登録が古くなる可能性を減らします。登録の有効期限は、サービスの作成で頻繁に使用されます。例として、フォローミーサービスがあります。このサービスでは、ユーザーは端末で短時間しか使用できない場合があります。したがって、レジストラは簡単な登録を受け入れる必要があります。リクエストが拒否されるのは、間隔が短すぎて更新によってレジストラのパフォーマンスが低下する場合のみです。
For each address, the registrar then searches the list of current bindings using the URI comparison rules. If the binding does not exist, it is tentatively added. If the binding does exist, the registrar checks the Call-ID value. If the Call-ID value in the existing binding differs from the Call-ID value in the request, the binding MUST be removed if the expiration time is zero and updated otherwise. If they are the same, the registrar compares the CSeq value. If the value is higher than that of the existing binding, it MUST update or remove the binding as above. If not, the update MUST be aborted and the request fails.
次に、レジストラはアドレスごとに、URI比較ルールを使用して現在のバインディングのリストを検索します。バインディングが存在しない場合は、暫定的に追加されます。バインディングが存在する場合、レジストラはCall-ID値をチェックします。既存のバインディングのCall-ID値がリクエストのCall-ID値と異なる場合、有効期限がゼロの場合はバインディングを削除し、それ以外の場合は更新する必要があります。それらが同じである場合、レジストラはCSeq値を比較します。値が既存のバインディングの値より大きい場合は、上記のようにバインディングを更新または削除する必要があります。そうでない場合は、更新を中止する必要があり、要求は失敗します。
This algorithm ensures that out-of-order requests from the same UA are ignored.
このアルゴリズムは、同じUAからの順序外の要求が無視されることを保証します。
Each binding record records the Call-ID and CSeq values from the request.
各バインディングレコードは、要求からのCall-IDおよびCSeq値を記録します。
The binding updates MUST be committed (that is, made visible to the proxy or redirect server) if and only if all binding updates and additions succeed. If any one of them fails (for example, because the back-end database commit failed), the request MUST fail with a 500 (Server Error) response and all tentative binding updates MUST be removed.
すべてのバインディングの更新と追加が成功した場合に限り、バインディングの更新をコミットする（つまり、プロキシサーバーまたはリダイレクトサーバーから見えるようにする）必要があります。それらのいずれかが失敗した場合（たとえば、バックエンドデータベースのコミットが失敗したため）、リクエストは500（サーバーエラー）応答で失敗しなければならず、すべての一時的なバインディング更新は削除されなければなりません（MUST）。
8. The registrar returns a 200 (OK) response. The response MUST contain Contact header field values enumerating all current bindings. Each Contact value MUST feature an "expires" parameter indicating its expiration interval chosen by the registrar. The response SHOULD include a Date header field.
8. レジストラは200（OK）応答を返します。応答には、現在のすべてのバインディングを列挙するContactヘッダーフィールド値を含める必要があります。各Contact値は、レジストラによって選択された有効期間を示す「expires」パラメータを備えている必要があります。応答には、日付ヘッダーフィールドを含める必要があります（SHOULD）。
11 Querying for Capabilities
11機能のクエリ
The SIP method OPTIONS allows a UA to query another UA or a proxy server as to its capabilities. This allows a client to discover information about the supported methods, content types, extensions, codecs, etc. without "ringing" the other party. For example, before a client inserts a Require header field into an INVITE listing an option that it is not certain the destination UAS supports, the client can query the destination UAS with an OPTIONS to see if this option is returned in a Supported header field. All UAs MUST support the OPTIONS method.
SIPメソッドOPTIONSにより、UAはその機能に関して別のUAまたはプロキシサーバーにクエリを実行できます。これにより、クライアントは、相手を「呼び出す」ことなく、サポートされているメソッド、コンテンツタイプ、拡張機能、コーデックなどに関する情報を発見できます。たとえば、クライアントがRequireヘッダーフィールドをINVITEに挿入する前に、宛先UASがサポートしているかどうかが不明なオプションをリストしている場合、クライアントはOPTIONSを使用して宛先UASを照会し、このオプションがサポートされているヘッダーフィールドに返されるかどうかを確認できます。すべてのUAはOPTIONSメソッドをサポートする必要があります。
The target of the OPTIONS request is identified by the Request-URI, which could identify another UA or a SIP server. If the OPTIONS is addressed to a proxy server, the Request-URI is set without a user part, similar to the way a Request-URI is set for a REGISTER request.
OPTIONS要求のターゲットは、別のUAまたはSIPサーバーを識別することができるRequest-URIによって識別されます。 OPTIONSがプロキシサーバーにアドレス指定されている場合、Request-URIは、REGISTERリクエストに対してRequest-URIが設定される方法と同様に、ユーザー部分なしで設定されます。
Alternatively, a server receiving an OPTIONS request with a Max-Forwards header field value of 0 MAY respond to the request regardless of the Request-URI.
または、Max-Forwardsヘッダーフィールド値が0のOPTIONSリクエストを受信したサーバーは、Request-URIに関係なくリクエストに応答する場合があります。
This behavior is common with HTTP/1.1. This behavior can be used as a "traceroute" functionality to check the capabilities of individual hop servers by sending a series of OPTIONS requests with incremented Max-Forwards values.
この動作はHTTP / 1.1と共通です。この動作を「traceroute」機能として使用して、インクリメントされたMax-Forwards値を含む一連のOPTIONSリクエストを送信することにより、個々のホップサーバーの機能を確認できます。
As is the case for general UA behavior, the transaction layer can return a timeout error if the OPTIONS yields no response. This may indicate that the target is unreachable and hence unavailable.
一般的なUA動作の場合と同様に、OPTIONSが応答を返さない場合、トランザクションレイヤーはタイムアウトエラーを返すことがあります。これは、ターゲットに到達できず、使用できないことを示している可能性があります。
An OPTIONS request MAY be sent as part of an established dialog to query the peer on capabilities that may be utilized later in the dialog.
確立されたダイアログの一部としてOPTIONS要求を送信して、後でダイアログで利用できる機能についてピアに問い合わせることができます。
An OPTIONS request is constructed using the standard rules for a SIP request as discussed in Section 8.1.1.
OPTIONSリクエストは、セクション8.1.1で説明されているように、SIPリクエストの標準ルールを使用して構築されます。
A Contact header field MAY be present in an OPTIONS.
連絡先ヘッダーフィールドは、オプションに存在する場合があります。
An Accept header field SHOULD be included to indicate the type of message body the UAC wishes to receive in the response. Typically, this is set to a format that is used to describe the media capabilities of a UA, such as SDP (application/sdp).
UACが応答で受信するメッセージ本文のタイプを示すために、Acceptヘッダーフィールドを含める必要があります（SHOULD）。通常、これは、SDP（application / sdp）などのUAのメディア機能を説明するために使用される形式に設定されます。
The response to an OPTIONS request is assumed to be scoped to the Request-URI in the original request. However, only when an OPTIONS is sent as part of an established dialog is it guaranteed that future requests will be received by the server that generated the OPTIONS response.
OPTIONS要求への応答は、元の要求のRequest-URIをスコープとするものと見なされます。ただし、確立されたダイアログの一部としてOPTIONSが送信された場合にのみ、OPTIONS応答を生成したサーバーが将来の要求を受信することが保証されます。
Example OPTIONS request:
OPTIONSリクエストの例：
OPTIONS sip:carol@chicago.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
Max-Forwards: 70
To: <sip:carol@chicago.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:alice@pc33.atlanta.com>
Accept: application/sdp
Content-Length: 0
The response to an OPTIONS is constructed using the standard rules for a SIP response as discussed in Section 8.2.6. The response code chosen MUST be the same that would have been chosen had the request been an INVITE. That is, a 200 (OK) would be returned if the UAS is ready to accept a call, a 486 (Busy Here) would be returned if the UAS is busy, etc. This allows an OPTIONS request to be used to determine the basic state of a UAS, which can be an indication of whether the UAS will accept an INVITE request.
OPTIONSへの応答は、セクション8.2.6で説明するSIP応答の標準ルールを使用して構築されます。選択された応答コードは、リクエストがINVITEであった場合に選択されたものと同じでなければなりません。つまり、UASがコールを受け入れる準備ができている場合は200（OK）が返され、UASがビジーの場合は486（Busy Here）が返されます。これにより、OPTIONSリクエストを使用して基本的なUASがINVITEリクエストを受け入れるかどうかを示すUASの状態。
An OPTIONS request received within a dialog generates a 200 (OK) response that is identical to one constructed outside a dialog and does not have any impact on the dialog.
ダイアログ内で受信されたOPTIONSリクエストは、ダイアログ外で構築されたものと同じ200（OK）応答を生成し、ダイアログに影響を与えません。
This use of OPTIONS has limitations due to the differences in proxy handling of OPTIONS and INVITE requests. While a forked INVITE can result in multiple 200 (OK) responses being returned, a forked OPTIONS will only result in a single 200 (OK) response, since it is treated by proxies using the non-INVITE handling. See Section 16.7 for the normative details.
このOPTIONSの使用には、OPTIONSリクエストとINVITEリクエストのプロキシ処理の違いによる制限があります。分岐したINVITEは複数の200（OK）応答を返す可能性がありますが、分岐したOPTIONSは、非INVITE処理を使用するプロキシによって処理されるため、単一の200（OK）応答のみを返します。規範的な詳細については、セクション16.7を参照してください。
If the response to an OPTIONS is generated by a proxy server, the proxy returns a 200 (OK), listing the capabilities of the server. The response does not contain a message body.
OPTIONSへの応答がプロキシサーバーによって生成された場合、プロキシは200（OK）を返し、サーバーの機能をリストします。応答にはメッセージ本文が含まれていません。
Allow, Accept, Accept-Encoding, Accept-Language, and Supported header fields SHOULD be present in a 200 (OK) response to an OPTIONS request. If the response is generated by a proxy, the Allow header field SHOULD be omitted as it is ambiguous since a proxy is method agnostic. Contact header fields MAY be present in a 200 (OK) response and have the same semantics as in a 3xx response. That is, they may list a set of alternative names and methods of reaching the user. A Warning header field MAY be present.
Allow、Accept、Accept-Encoding、Accept-Language、およびSupportedヘッダーフィールドは、OPTIONSリクエストに対する200（OK）応答に存在する必要があります（SHOULD）。応答がプロキシによって生成される場合、プロキシはメソッドにとらわれないため、あいまいであるため、Allowヘッダーフィールドは省略してください。連絡先ヘッダーフィールドは200（OK）応答に存在する場合があり、3xx応答と同じセマンティクスを持っている場合があります。つまり、ユーザーに連絡するための一連の代替名と方法をリストすることができます。警告ヘッダーフィールドが存在する場合があります。
A message body MAY be sent, the type of which is determined by the Accept header field in the OPTIONS request (application/sdp is the default if the Accept header field is not present). If the types include one that can describe media capabilities, the UAS SHOULD include a body in the response for that purpose. Details on the construction of such a body in the case of application/sdp are described in [13].
メッセージ本文を送信できます。そのタイプは、OPTIONSリクエストのAcceptヘッダーフィールドによって決定されます（Acceptヘッダーフィールドが存在しない場合は、application / sdpがデフォルトです）。タイプにメディア機能を記述できるタイプが含まれている場合、UASはその目的で応答に本文を含める必要があります（SHOULD）。 application / sdpの場合のそのようなボディの構築の詳細は、[13]で説明されています。
Example OPTIONS response generated by a UAS (corresponding to the request in Section 11.1):
UASによって生成されたOPTIONS応答の例（セクション11.1の要求に対応）：
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
;received=192.0.2.4
To: <sip:carol@chicago.com>;tag=93810874
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:carol@chicago.com>
Contact: <mailto:carol@chicago.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
Accept: application/sdp
Accept-Encoding: gzip
Accept-Language: en
Supported: foo
Content-Type: application/sdp
Content-Length: 274
(SDP not shown)
（SDPは表示されていません）
12 Dialogs
12ダイアログ
A key concept for a user agent is that of a dialog. A dialog represents a peer-to-peer SIP relationship between two user agents that persists for some time. The dialog facilitates sequencing of messages between the user agents and proper routing of requests between both of them. The dialog represents a context in which to interpret SIP messages. Section 8 discussed method independent UA processing for requests and responses outside of a dialog. This section discusses how those requests and responses are used to construct a dialog, and then how subsequent requests and responses are sent within a dialog.
ユーザーエージェントの重要な概念は、ダイアログの概念です。ダイアログは、しばらく持続する2つのユーザーエージェント間のピアツーピアSIP関係を表します。ダイアログは、ユーザーエージェント間のメッセージの順序付けと、それらの間の要求の適切なルーティングを容易にします。ダイアログは、SIPメッセージを解釈するコンテキストを表します。セクション8では、ダイアログの外でのリクエストとレスポンスに対するメソッドに依存しないUA処理について説明しました。このセクションでは、それらの要求と応答を使用してダイアログを作成する方法と、後続の要求と応答をダイアログ内で送信する方法について説明します。
A dialog is identified at each UA with a dialog ID, which consists of a Call-ID value, a local tag and a remote tag. The dialog ID at each UA involved in the dialog is not the same. Specifically, the local tag at one UA is identical to the remote tag at the peer UA. The tags are opaque tokens that facilitate the generation of unique dialog IDs.
ダイアログは、各UAで、Call-ID値、ローカルタグ、およびリモートタグで構成されるダイアログIDで識別されます。ダイアログに含まれる各UAのダイアログIDは同じではありません。具体的には、1つのUAのローカルタグは、ピアUAのリモートタグと同じです。タグは、一意のダイアログIDの生成を容易にする不透明なトークンです。
A dialog ID is also associated with all responses and with any request that contains a tag in the To field. The rules for computing the dialog ID of a message depend on whether the SIP element is a UAC or UAS. For a UAC, the Call-ID value of the dialog ID is set to the Call-ID of the message, the remote tag is set to the tag in the To field of the message, and the local tag is set to the tag in the From field of the message (these rules apply to both requests and responses). As one would expect for a UAS, the Call-ID value of the dialog ID is set to the Call-ID of the message, the remote tag is set to the tag in the From field of the message, and the local tag is set to the tag in the To field of the message.
ダイアログIDは、すべての応答、およびToフィールドにタグを含むすべての要求にも関連付けられます。メッセージのダイアログIDを計算するためのルールは、SIP要素がUACかUASかによって異なります。 UACの場合、ダイアログIDのCall-ID値はメッセージのCall-IDに設定され、リモートタグはメッセージのToフィールドのタグに設定され、ローカルタグはメッセージのFromフィールド（これらのルールは要求と応答の両方に適用されます）。 UASに期待されるように、ダイアログIDのCall-ID値はメッセージのCall-IDに設定され、リモートタグはメッセージのFromフィールドのタグに設定され、ローカルタグが設定されます。メッセージの「宛先」フィールドのタグに。
A dialog contains certain pieces of state needed for further message transmissions within the dialog. This state consists of the dialog ID, a local sequence number (used to order requests from the UA to its peer), a remote sequence number (used to order requests from its peer to the UA), a local URI, a remote URI, remote target, a boolean flag called "secure", and a route set, which is an ordered list of URIs. The route set is the list of servers that need to be traversed to send a request to the peer. A dialog can also be in the "early" state, which occurs when it is created with a provisional response, and then transition to the "confirmed" state when a 2xx final response arrives. For other responses, or if no response arrives at all on that dialog, the early dialog terminates.
ダイアログには、ダイアログ内でさらにメッセージを送信するために必要な特定の状態が含まれています。この状態は、ダイアログID、ローカルシーケンス番号（UAからピアへの要求の順序付けに使用）、リモートシーケンス番号（ピアからUAへの要求の順序付けに使用）、ローカルURI、リモートURIで構成されます。リモートターゲット、「セキュア」と呼ばれるブールフラグ、およびURIの順序付きリストであるルートセット。ルートセットは、要求をピアに送信するために通過する必要があるサーバーのリストです。ダイアログを「初期」状態にすることもできます。これは、ダイアログが暫定応答で作成されたときに発生し、2xxの最終応答が到着したときに「確認済み」状態に移行します。他の応答の場合、またはそのダイアログに応答がまったく到着しない場合、初期のダイアログは終了します。
Dialogs are created through the generation of non-failure responses to requests with specific methods. Within this specification, only 2xx and 101-199 responses with a To tag, where the request was INVITE, will establish a dialog. A dialog established by a non-final response to a request is in the "early" state and it is called an early dialog. Extensions MAY define other means for creating dialogs. Section 13 gives more details that are specific to the INVITE method. Here, we describe the process for creation of dialog state that is not dependent on the method.
ダイアログは、特定のメソッドを使用した要求に対する失敗以外の応答の生成を通じて作成されます。この仕様内では、要求がINVITEであったToタグ付きの2xxおよび101-199応答のみがダイアログを確立します。リクエストに対する非最終的な応答によって確立されたダイアログは「初期」状態にあり、早期ダイアログと呼ばれます。拡張は、ダイアログを作成するための他の手段を定義してもよい（MAY）。セクション13では、INVITEメソッドに固有の詳細について説明します。ここでは、メソッドに依存しないダイアログ状態の作成プロセスについて説明します。
UAs MUST assign values to the dialog ID components as described below.
UAは、以下で説明するように、ダイアログIDコンポーネントに値を割り当てる必要があります。
When a UAS responds to a request with a response that establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route header field values from the request into the response (including the URIs, URI parameters, and any Record-Route header field parameters, whether they are known or unknown to the UAS) and MUST maintain the order of those values. The UAS MUST add a Contact header field to the response. The Contact header field contains an address where the UAS would like to be contacted for subsequent requests in the dialog (which includes the ACK for a 2xx response in the case of an INVITE). Generally, the host portion of this URI is the IP address or FQDN of the host. The URI provided in the Contact header field MUST be a SIP or SIPS URI. If the request that initiated the dialog contained a SIPS URI in the Request-URI or in the top Record-Route header field value, if there was any, or the Contact header field if there was no Record-Route header field, the Contact header field in the response MUST be a SIPS URI. The URI SHOULD have global scope (that is, the same URI can be used in messages outside this dialog). The same way, the scope of the URI in the Contact header field of the INVITE is not limited to this dialog either. It can therefore be used in messages to the UAC even outside this dialog.
UASがダイアログを確立する応答（2xxからINVITEなど）で要求に応答する場合、UASはすべてのRecord-Routeヘッダーフィールド値を要求から応答にコピーする必要があります（URI、URIパラメータ、 Record-Routeヘッダーフィールドパラメーターは、UASに認識されているかどうかにかかわらず）、これらの値の順序を維持する必要があります。 UASは、Contactヘッダーフィールドを応答に追加する必要があります。 Contactヘッダーフィールドには、UASがダイアログ内の後続のリクエストのために接続するアドレス（INVITEの場合は2xx応答のACKを含む）が含まれます。通常、このURIのホスト部分は、ホストのIPアドレスまたはFQDNです。 Contactヘッダーフィールドで提供されるURIは、SIPまたはSIPS URIでなければなりません。ダイアログを開始したリクエストに、Request-URIまたは上部のRecord-Routeヘッダーフィールド値（存在する場合）にSIPS URIが含まれていた場合、またはRecord-Routeヘッダーフィールドがない場合はContactヘッダーフィールドに含まれている場合、Contactヘッダー応答のフィールドはSIPS URIである必要があります。 URIはグローバルスコープを持つ必要があります（つまり、同じURIをこのダイアログ外のメッセージで使用できます）。同様に、INVITEのContactヘッダーフィールドのURIのスコープもこのダイアログに限定されません。したがって、このダイアログの外でも、UACへのメッセージで使用できます。
The UAS then constructs the state of the dialog. This state MUST be maintained for the duration of the dialog.
次に、UASはダイアログの状態を作成します。この状態は、ダイアログの期間中維持されなければなりません。
If the request arrived over TLS, and the Request-URI contained a SIPS URI, the "secure" flag is set to TRUE.
要求がTLS経由で到着し、Request-URIにSIPS URIが含まれている場合、「セキュア」フラグはTRUEに設定されます。
The route set MUST be set to the list of URIs in the Record-Route header field from the request, taken in order and preserving all URI parameters. If no Record-Route header field is present in the request, the route set MUST be set to the empty set. This route set, even if empty, overrides any pre-existing route set for future requests in this dialog. The remote target MUST be set to the URI from the Contact header field of the request.
ルートセットは、リクエストからのRecord-Routeヘッダーフィールド内のURIのリストに設定する必要があり、順番に、すべてのURIパラメーターを保持します。リクエストにRecord-Routeヘッダーフィールドが存在しない場合、ルートセットは空のセットに設定する必要があります。このルートセットは、空の場合でも、このダイアログの今後のリクエストのために既存のルートセットを上書きします。リモートターゲットは、リクエストのContactヘッダーフィールドからのURIに設定する必要があります。
The remote sequence number MUST be set to the value of the sequence number in the CSeq header field of the request. The local sequence number MUST be empty. The call identifier component of the dialog ID MUST be set to the value of the Call-ID in the request. The local tag component of the dialog ID MUST be set to the tag in the To field in the response to the request (which always includes a tag), and the remote tag component of the dialog ID MUST be set to the tag from the From field in the request. A UAS MUST be prepared to receive a request without a tag in the From field, in which case the tag is considered to have a value of null.
リモートシーケンス番号は、リクエストのCSeqヘッダーフィールドのシーケンス番号の値に設定する必要があります。ローカルシーケンス番号は空である必要があります。ダイアログIDの呼び出し識別子コンポーネントは、リクエストのCall-IDの値に設定する必要があります。ダイアログIDのローカルタグコンポーネントは、リクエストへの応答のToフィールドのタグ（常にタグを含む）に設定する必要があり、ダイアログIDのリモートタグコンポーネントは、Fromからのタグに設定する必要があります。リクエストのフィールド。 Fromフィールドにタグなしでリクエストを受信するために、UASを準備する必要があります。その場合、タグはnullの値を持つと見なされます。
This is to maintain backwards compatibility with RFC 2543, which did not mandate From tags.
これは、Fromタグを義務付けなかったRFC 2543との下位互換性を維持するためです。
The remote URI MUST be set to the URI in the From field, and the local URI MUST be set to the URI in the To field.
リモートURIはFromフィールドのURIに設定する必要があり、ローカルURIはToフィールドのURIに設定する必要があります。
When a UAC sends a request that can establish a dialog (such as an INVITE) it MUST provide a SIP or SIPS URI with global scope (i.e., the same SIP URI can be used in messages outside this dialog) in the Contact header field of the request. If the request has a Request-URI or a topmost Route header field value with a SIPS URI, the Contact header field MUST contain a SIPS URI.
UACがダイアログ（INVITEなど）を確立できる要求を送信するとき、それはSIPまたはSIPS URIにグローバルスコープを提供する必要があります（つまり、同じSIP URIをこのダイアログの外のメッセージで使用できます）の連絡先ヘッダーフィールドにリクエスト。リクエストにRequest-URIまたはSIPS URIを持つ最上位のRouteヘッダーフィールド値がある場合、ContactヘッダーフィールドにはSIPS URIが含まれている必要があります。
When a UAC receives a response that establishes a dialog, it constructs the state of the dialog. This state MUST be maintained for the duration of the dialog.
UACは、ダイアログを確立する応答を受信すると、ダイアログの状態を構築します。この状態は、ダイアログの期間中維持されなければなりません。
If the request was sent over TLS, and the Request-URI contained a SIPS URI, the "secure" flag is set to TRUE.
要求がTLS経由で送信され、Request-URIにSIPS URIが含まれている場合、「セキュア」フラグはTRUEに設定されます。
The route set MUST be set to the list of URIs in the Record-Route header field from the response, taken in reverse order and preserving all URI parameters. If no Record-Route header field is present in the response, the route set MUST be set to the empty set. This route set, even if empty, overrides any pre-existing route set for future requests in this dialog. The remote target MUST be set to the URI from the Contact header field of the response.
ルートセットは、応答からのRecord-RouteヘッダーフィールドのURIのリストに設定する必要があり、逆の順序で取得され、すべてのURIパラメーターを保持します。 Record-Routeヘッダーフィールドが応答にない場合、ルートセットは空のセットに設定する必要があります。このルートセットは、空の場合でも、このダイアログの今後のリクエストのために既存のルートセットを上書きします。リモートターゲットは、応答のContactヘッダーフィールドからのURIに設定する必要があります。
The local sequence number MUST be set to the value of the sequence number in the CSeq header field of the request. The remote sequence number MUST be empty (it is established when the remote UA sends a request within the dialog). The call identifier component of the dialog ID MUST be set to the value of the Call-ID in the request. The local tag component of the dialog ID MUST be set to the tag in the From field in the request, and the remote tag component of the dialog ID MUST be set to the tag in the To field of the response. A UAC MUST be prepared to receive a response without a tag in the To field, in which case the tag is considered to have a value of null.
ローカルシーケンス番号は、リクエストのCSeqヘッダーフィールドのシーケンス番号の値に設定する必要があります。リモートシーケンス番号は空である必要があります（リモートUAがダイアログ内で要求を送信すると確立されます）。ダイアログIDの呼び出し識別子コンポーネントは、リクエストのCall-IDの値に設定する必要があります。ダイアログIDのローカルタグコンポーネントは、リクエストのFromフィールドのタグに設定する必要があり、ダイアログIDのリモートタグコンポーネントは、応答のToフィールドのタグに設定する必要があります。 UACは、Toフィールドにタグなしで応答を受信できるように準備する必要があります。その場合、タグはnullの値を持つと見なされます。
This is to maintain backwards compatibility with RFC 2543, which did not mandate To tags.
これは、Toタグを義務付けなかったRFC 2543との下位互換性を維持するためです。
The remote URI MUST be set to the URI in the To field, and the local URI MUST be set to the URI in the From field.
リモートURIはToフィールドのURIに設定する必要があり、ローカルURIはFromフィールドのURIに設定する必要があります。
Once a dialog has been established between two UAs, either of them MAY initiate new transactions as needed within the dialog. The UA sending the request will take the UAC role for the transaction. The UA receiving the request will take the UAS role. Note that these may be different roles than the UAs held during the transaction that established the dialog.
2つのUA間でダイアログが確立されると、どちらかがダイアログ内で必要に応じて新しいトランザクションを開始できます（MAY）。リクエストを送信するUAは、トランザクションのUACの役割を果たします。リクエストを受け取ったUAがUASの役割を果たします。これらは、ダイアログを確立したトランザクション中に保持されているUAとは異なる役割である可能性があることに注意してください。
Requests within a dialog MAY contain Record-Route and Contact header fields. However, these requests do not cause the dialog's route set to be modified, although they may modify the remote target URI. Specifically, requests that are not target refresh requests do not modify the dialog's remote target URI, and requests that are target refresh requests do. For dialogs that have been established with an INVITE, the only target refresh request defined is re-INVITE (see Section 14). Other extensions may define different target refresh requests for dialogs established in other ways.
ダイアログ内のリクエストには、Record-RouteおよびContactヘッダーフィールドが含まれる場合があります。ただし、これらのリクエストによってダイアログのルートセットが変更されることはありませんが、リモートターゲットURIは変更される可能性があります。具体的には、ターゲットリフレッシュリクエストではないリクエストはダイアログのリモートターゲットURIを変更せず、ターゲットリフレッシュリクエストであるリクエストは変更します。 INVITEで確立されたダイアログの場合、定義される唯一のターゲットリフレッシュ要求はre-INVITEです（セクション14を参照）。他の拡張機能は、他の方法で確立されたダイアログに対して異なるターゲット更新要求を定義する場合があります。
Note that an ACK is NOT a target refresh request.
ACKはターゲットのリフレッシュ要求ではないことに注意してください。
Target refresh requests only update the dialog's remote target URI, and not the route set formed from the Record-Route. Updating the latter would introduce severe backwards compatibility problems with RFC 2543-compliant systems.
ターゲット更新要求は、ダイアログのリモートターゲットURIのみを更新し、Record-Routeから形成されたルートセットは更新しません。後者を更新すると、RFC 2543準拠のシステムに重大な下位互換性の問題が発生します。
A request within a dialog is constructed by using many of the components of the state stored as part of the dialog.
ダイアログ内のリクエストは、ダイアログの一部として保存されている状態のコンポーネントの多くを使用して構築されます。
The URI in the To field of the request MUST be set to the remote URI from the dialog state. The tag in the To header field of the request MUST be set to the remote tag of the dialog ID. The From URI of the request MUST be set to the local URI from the dialog state. The tag in the From header field of the request MUST be set to the local tag of the dialog ID. If the value of the remote or local tags is null, the tag parameter MUST be omitted from the To or From header fields, respectively.
リクエストのToフィールドのURIは、ダイアログの状態からのリモートURIに設定する必要があります。リクエストのToヘッダーフィールドのタグは、ダイアログIDのリモートタグに設定する必要があります。リクエストのFrom URIは、ダイアログの状態からのローカルURIに設定する必要があります。リクエストのFromヘッダーフィールドのタグは、ダイアログIDのローカルタグに設定する必要があります。リモートタグまたはローカルタグの値がnullの場合、タグパラメータは、それぞれToまたはFromヘッダーフィールドから省略される必要があります。
Usage of the URI from the To and From fields in the original request within subsequent requests is done for backwards compatibility with RFC 2543, which used the URI for dialog identification. In this specification, only the tags are used for dialog identification. It is expected that mandatory reflection of the original To and From URI in mid-dialog requests will be deprecated in a subsequent revision of this specification.
後続のリクエスト内の元のリクエストのToおよびFromフィールドからのURIの使用は、ダイアログの識別にURIを使用したRFC 2543との下位互換性のために行われます。この仕様では、ダイアログの識別にタグのみが使用されます。中間ダイアログリクエストでの元のToおよびFrom URIの必須の反映は、この仕様の後続の改訂で廃止される予定です。
The Call-ID of the request MUST be set to the Call-ID of the dialog. Requests within a dialog MUST contain strictly monotonically increasing and contiguous CSeq sequence numbers (increasing-by-one) in each direction (excepting ACK and CANCEL of course, whose numbers equal the requests being acknowledged or cancelled). Therefore, if the local sequence number is not empty, the value of the local sequence number MUST be incremented by one, and this value MUST be placed into the CSeq header field. If the local sequence number is empty, an initial value MUST be chosen using the guidelines of Section 8.1.1.5. The method field in the CSeq header field value MUST match the method of the request.
リクエストのCall-IDは、ダイアログのCall-IDに設定する必要があります。ダイアログ内のリクエストには、各方向に厳密に単調に増加し、連続するCSeqシーケンス番号（1ずつ増加）が含まれている必要があります（もちろん、ACKとCANCELを除きます。これらの番号は、確認またはキャンセルされるリクエストと同じです）。したがって、ローカルシーケンス番号が空でない場合は、ローカルシーケンス番号の値を1だけインクリメントする必要があり、この値をCSeqヘッダーフィールドに配置する必要があります。ローカルシーケンス番号が空の場合は、8.1.1.5項のガイドラインを使用して初期値を選択する必要があります。 CSeqヘッダーフィールド値のメソッドフィールドは、要求のメソッドと一致する必要があります。
With a length of 32 bits, a client could generate, within a single call, one request a second for about 136 years before needing to wrap around. The initial value of the sequence number is chosen so that subsequent requests within the same call will not wrap around. A non-zero initial value allows clients to use a time-based initial sequence number. A client could, for example, choose the 31 most significant bits of a 32-bit second clock as an initial sequence number.
32ビットの長さの場合、クライアントは、1回の呼び出しで、ラップアラウンドが必要になる前に、約136年間1秒のリクエストを生成できます。シーケンス番号の初期値は、同じ呼び出し内の後続の要求がラップアラウンドしないように選択されます。ゼロ以外の初期値を使用すると、クライアントは時間ベースの初期シーケンス番号を使用できます。たとえば、クライアントは、32ビット秒クロックの上位31ビットを初期シーケンス番号として選択できます。
The UAC uses the remote target and route set to build the Request-URI and Route header field of the request.
UACはリモートターゲットとルートセットを使用して、リクエストのRequest-URIおよびRouteヘッダーフィールドを作成します。
If the route set is empty, the UAC MUST place the remote target URI into the Request-URI. The UAC MUST NOT add a Route header field to the request.
ルートセットが空の場合、UACはリモートターゲットURIをRequest-URIに配置する必要があります。 UACは、ルートヘッダーフィールドをリクエストに追加してはなりません（MUST NOT）。
If the route set is not empty, and the first URI in the route set contains the lr parameter (see Section 19.1.1), the UAC MUST place the remote target URI into the Request-URI and MUST include a Route header field containing the route set values in order, including all parameters.
ルートセットが空ではなく、ルートセットの最初のURIにlrパラメータが含まれている場合（セクション19.1.1を参照）、UACはリモートターゲットURIをRequest-URIに配置し、すべてのパラメータを含む、順番にルート設定値。
If the route set is not empty, and its first URI does not contain the lr parameter, the UAC MUST place the first URI from the route set into the Request-URI, stripping any parameters that are not allowed in a Request-URI. The UAC MUST add a Route header field containing the remainder of the route set values in order, including all parameters. The UAC MUST then place the remote target URI into the Route header field as the last value.
ルートセットが空ではなく、その最初のURIにlrパラメータが含まれていない場合、UACはルートセットからの最初のURIをRequest-URIに配置し、Request-URIで許可されていないパラメータを削除する必要があります。 UACは、すべてのパラメーターを含む、残りのルートセット値を順番に含むルートヘッダーフィールドを追加する必要があります。次に、UACはリモートターゲットURIを最後の値としてルートヘッダーフィールドに配置する必要があります。
For example, if the remote target is sip:user@remoteua and the route set contains:
たとえば、リモートターゲットがsip：user @ remoteuaであり、ルートセットに以下が含まれている場合：
<sip:proxy1>,<sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>
The request will be formed with the following Request-URI and Route header field:
要求は、次のRequest-URIおよびRouteヘッダーフィールドで形成されます。
METHOD sip:proxy1
Route: <sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>,<sip:user@remoteua>
If the first URI of the route set does not contain the lr parameter, the proxy indicated does not understand the routing mechanisms described in this document and will act as specified in RFC 2543, replacing the Request-URI with the first Route header field value it receives while forwarding the message. Placing the Request-URI at the end of the Route header field preserves the information in that Request-URI across the strict router (it will be returned to the Request-URI when the request reaches a loose-router).
ルートセットの最初のURIにlrパラメータが含まれていない場合、示されたプロキシはこのドキュメントで説明されているルーティングメカニズムを理解せず、RFC 2543で指定されているとおりに動作し、Request-URIを最初のルートヘッダーフィールド値に置き換えます。メッセージの転送中に受信します。ルートヘッダーフィールドの最後にリクエストURIを配置すると、厳密なルーター全体でそのリクエストURIの情報が保持されます（リクエストがルーズルーターに到達すると、リクエストURIに返されます）。
A UAC SHOULD include a Contact header field in any target refresh requests within a dialog, and unless there is a need to change it, the URI SHOULD be the same as used in previous requests within the dialog. If the "secure" flag is true, that URI MUST be a SIPS URI. As discussed in Section 12.2.2, a Contact header field in a target refresh request updates the remote target URI. This allows a UA to provide a new contact address, should its address change during the duration of the dialog.
UACは、ダイアログ内のすべてのターゲットリフレッシュリクエストにContactヘッダーフィールドを含める必要があります。変更する必要がない限り、URIはダイアログ内の以前のリクエストで使用されたものと同じである必要があります（SHOULD）。 「セキュア」フラグがtrueの場合、そのURIはSIPS URIである必要があります。 12.2.2項で説明したように、ターゲットのリフレッシュ要求のContactヘッダー・フィールドは、リモートのターゲットURIを更新します。これにより、ダイアログの期間中にアドレスが変更された場合、UAは新しい連絡先アドレスを提供できます。
However, requests that are not target refresh requests do not affect the remote target URI for the dialog.
ただし、ターゲットの更新リクエストではないリクエストは、ダイアログのリモートターゲットURIに影響を与えません。
The rest of the request is formed as described in Section 8.1.1.
残りのリクエストは、セクション8.1.1で説明されているように形成されます。
Once the request has been constructed, the address of the server is computed and the request is sent, using the same procedures for requests outside of a dialog (Section 8.1.2).
リクエストが作成されると、サーバーのアドレスが計算され、ダイアログ外のリクエストと同じ手順を使用してリクエストが送信されます（セクション8.1.2）。
The procedures in Section 8.1.2 will normally result in the request being sent to the address indicated by the topmost Route header field value or the Request-URI if no Route header field is present. Subject to certain restrictions, they allow the request to be sent to an alternate address (such as a default outbound proxy not represented in the route set).
セクション8.1.2の手順では、通常、ルートヘッダーフィールドが存在しない場合、最上位のルートヘッダーフィールド値またはRequest-URIで示されるアドレスにリクエストが送信されます。特定の制限に従って、リクエストを代替アドレス（ルートセットに含まれていないデフォルトの送信プロキシなど）に送信できます。
The UAC will receive responses to the request from the transaction layer. If the client transaction returns a timeout, this is treated as a 408 (Request Timeout) response.
UACは、トランザクション層からの要求に対する応答を受け取ります。クライアントトランザクションがタイムアウトを返す場合、これは408（Request Timeout）応答として扱われます。
The behavior of a UAC that receives a 3xx response for a request sent within a dialog is the same as if the request had been sent outside a dialog. This behavior is described in Section 8.1.3.4.
ダイアログ内で送信された要求の3xx応答を受信するUACの動作は、要求がダイアログの外部で送信された場合と同じです。この動作はセクション8.1.3.4で説明されています。
Note, however, that when the UAC tries alternative locations, it still uses the route set for the dialog to build the Route header of the request.
ただし、UACが別の場所を試す場合でも、UACはダイアログのルートセットを使用してリクエストのルートヘッダーを作成します。
When a UAC receives a 2xx response to a target refresh request, it MUST replace the dialog's remote target URI with the URI from the Contact header field in that response, if present.
UACがターゲットリフレッシュリクエストへの2xx応答を受信すると、ダイアログのリモートターゲットURIが存在する場合は、その応答のContactヘッダーフィールドのURIに置き換える必要があります。
If the response for a request within a dialog is a 481 (Call/Transaction Does Not Exist) or a 408 (Request Timeout), the UAC SHOULD terminate the dialog. A UAC SHOULD also terminate a dialog if no response at all is received for the request (the client transaction would inform the TU about the timeout.)
ダイアログ内のリクエストに対する応答が481（コール/トランザクションが存在しない）または408（リクエストタイムアウト）の場合、UACはダイアログを終了する必要があります（SHOULD）。 UAC SHOULDは、要求に対する応答がまったく受信されない場合にもダイアログを終了します（クライアントトランザクションはTUにタイムアウトについて通知します）。
For INVITE initiated dialogs, terminating the dialog consists of sending a BYE.
INVITEで開始されたダイアログの場合、ダイアログを終了するにはBYEを送信します。
Requests sent within a dialog, as any other requests, are atomic. If a particular request is accepted by the UAS, all the state changes associated with it are performed. If the request is rejected, none of the state changes are performed.
ダイアログ内で送信されるリクエストは、他のリクエストと同様にアトミックです。 UASが特定の要求を受け入れると、それに関連するすべての状態変更が実行されます。要求が拒否された場合、状態変更は実行されません。
Note that some requests, such as INVITEs, affect several pieces of state.
INVITEなどの一部のリクエストは、いくつかの状態に影響を与えることに注意してください。
The UAS will receive the request from the transaction layer. If the request has a tag in the To header field, the UAS core computes the dialog identifier corresponding to the request and compares it with existing dialogs. If there is a match, this is a mid-dialog request. In that case, the UAS first applies the same processing rules for requests outside of a dialog, discussed in Section 8.2.
UASはトランザクション層から要求を受け取ります。リクエストのToヘッダーフィールドにタグがある場合、UASコアはリクエストに対応するダイアログ識別子を計算し、それを既存のダイアログと比較します。一致する場合、これはダイアログ中の要求です。その場合、UASは最初に、セクション8.2で説明されているダイアログ外の要求に同じ処理ルールを適用します。
If the request has a tag in the To header field, but the dialog identifier does not match any existing dialogs, the UAS may have crashed and restarted, or it may have received a request for a different (possibly failed) UAS (the UASs can construct the To tags so that a UAS can identify that the tag was for a UAS for which it is providing recovery). Another possibility is that the incoming request has been simply misrouted. Based on the To tag, the UAS MAY either accept or reject the request. Accepting the request for acceptable To tags provides robustness, so that dialogs can persist even through crashes. UAs wishing to support this capability must take into consideration some issues such as choosing monotonically increasing CSeq sequence numbers even across reboots, reconstructing the route set, and accepting out-of-range RTP timestamps and sequence numbers.
要求のToヘッダーフィールドにタグが付いているが、ダイアログ識別子が既存のダイアログと一致しない場合、UASがクラッシュして再起動したか、別の（おそらく失敗した）UASの要求を受け取った可能性があります（UASはUASがタグが回復を提供しているUAS用であったことを識別できるように、Toタグを作成します。別の可能性は、着信要求が単に誤ってルーティングされたということです。 Toタグに基づいて、UASは要求を受け入れるか拒否することができます。受け入れ可能なToタグのリクエストを受け入れることで堅牢性が提供されるため、クラッシュが発生してもダイアログを持続させることができます。この機能をサポートするUAは、再起動後も単調に増加するCSeqシーケンス番号を選択する、ルートセットを再構築する、範囲外のRTPタイムスタンプとシーケンス番号を受け入れるなどの問題を考慮する必要があります。
If the UAS wishes to reject the request because it does not wish to recreate the dialog, it MUST respond to the request with a 481 (Call/Transaction Does Not Exist) status code and pass that to the server transaction.
UASがダイアログの再作成を望まないために要求を拒否したい場合は、要求に481（呼び出し/トランザクションが存在しない）ステータスコードで応答し、それをサーバートランザクションに渡す必要があります。
Requests that do not change in any way the state of a dialog may be received within a dialog (for example, an OPTIONS request). They are processed as if they had been received outside the dialog.
ダイアログの状態がまったく変化しない要求は、ダイアログ内で受け取ることができます（たとえば、OPTIONS要求）。それらはダイアログの外で受信されたかのように処理されます。
If the remote sequence number is empty, it MUST be set to the value of the sequence number in the CSeq header field value in the request. If the remote sequence number was not empty, but the sequence number of the request is lower than the remote sequence number, the request is out of order and MUST be rejected with a 500 (Server Internal Error) response. If the remote sequence number was not empty, and the sequence number of the request is greater than the remote sequence number, the request is in order. It is possible for the CSeq sequence number to be higher than the remote sequence number by more than one. This is not an error condition, and a UAS SHOULD be prepared to receive and process requests with CSeq values more than one higher than the previous received request. The UAS MUST then set the remote sequence number to the value of the sequence number in the CSeq header field value in the request.
リモートシーケンス番号が空の場合は、リクエストのCSeqヘッダーフィールド値のシーケンス番号の値に設定する必要があります。リモートシーケンス番号は空ではなかったが、リクエストのシーケンス番号がリモートシーケンス番号よりも小さい場合、そのリクエストは順不同であり、500（サーバー内部エラー）応答で拒否される必要があります。リモートシーケンス番号が空でなく、リクエストのシーケンス番号がリモートシーケンス番号より大きい場合、リクエストは正しいです。 CSeqシーケンス番号は、リモートシーケンス番号よりも1つ大きくなる可能性があります。これはエラー条件ではなく、UASは、前に受信した要求よりも1つ大きいCSeq値を持つ要求を受信して処理する準備をする必要があります。次に、UASは、リモートシーケンス番号を、要求のCSeqヘッダーフィールド値のシーケンス番号の値に設定する必要があります。
If a proxy challenges a request generated by the UAC, the UAC has to resubmit the request with credentials. The resubmitted request will have a new CSeq number. The UAS will never see the first request, and thus, it will notice a gap in the CSeq number space. Such a gap does not represent any error condition.
プロキシがUACによって生成された要求に挑戦する場合、UACは資格情報を使用して要求を再送信する必要があります。再送信されたリクエストには新しいCSeq番号が付けられます。 UASは最初の要求を決して見ないため、CSeq番号スペースにギャップがあることに気づきます。このようなギャップは、エラー状態を表すものではありません。
When a UAS receives a target refresh request, it MUST replace the dialog's remote target URI with the URI from the Contact header field in that request, if present.
UASがターゲットリフレッシュリクエストを受信すると、ダイアログのリモートターゲットURIが存在する場合、そのリクエストのContactヘッダーフィールドのURIに置き換えなければなりません（MUST）。
Independent of the method, if a request outside of a dialog generates a non-2xx final response, any early dialogs created through provisional responses to that request are terminated. The mechanism for terminating confirmed dialogs is method specific. In this specification, the BYE method terminates a session and the dialog associated with it. See Section 15 for details.
メソッドとは関係なく、ダイアログの外部の要求が2xx以外の最終応答を生成した場合、その要求への暫定応答を通じて作成された初期のダイアログはすべて終了します。確認済みダイアログを終了するメカニズムはメソッド固有です。この仕様では、BYEメソッドはセッションとそれに関連付けられたダイアログを終了します。詳細については、セクション15を参照してください。
13 Initiating a Session
13セッションの開始
When a user agent client desires to initiate a session (for example, audio, video, or a game), it formulates an INVITE request. The INVITE request asks a server to establish a session. This request may be forwarded by proxies, eventually arriving at one or more UAS that can potentially accept the invitation. These UASs will frequently need to query the user about whether to accept the invitation. After some time, those UASs can accept the invitation (meaning the session is to be established) by sending a 2xx response. If the invitation is not accepted, a 3xx, 4xx, 5xx or 6xx response is sent, depending on the reason for the rejection. Before sending a final response, the UAS can also send provisional responses (1xx) to advise the UAC of progress in contacting the called user.
ユーザーエージェントクライアントがセッション（オーディオ、ビデオ、ゲームなど）の開始を希望する場合、INVITEリクエストを作成します。 INVITE要求は、サーバーにセッションの確立を要求します。このリクエストはプロキシによって転送され、最終的に招待を受け入れることができる1つ以上のUASに到達します。これらのUASは、招待を受け入れるかどうかについてユーザーに頻繁に問い合わせる必要があります。しばらくすると、それらのUASは2xx応答を送信して、招待を受け入れることができます（セッションが確立されることを意味します）。招待が受け入れられない場合、拒否の理由に応じて、3xx、4xx、5xx、または6xx応答が送信されます。最終応答を送信する前に、UASは暫定応答（1xx）を送信して、呼び出されたユーザーへの連絡の進捗状況をUACに通知することもできます。
After possibly receiving one or more provisional responses, the UAC will get one or more 2xx responses or one non-2xx final response. Because of the protracted amount of time it can take to receive final responses to INVITE, the reliability mechanisms for INVITE transactions differ from those of other requests (like OPTIONS). Once it receives a final response, the UAC needs to send an ACK for every final response it receives. The procedure for sending this ACK depends on the type of response. For final responses between 300 and 699, the ACK processing is done in the transaction layer and follows one set of rules (See Section 17). For 2xx responses, the ACK is generated by the UAC core.
UACは1つ以上の暫定応答を受信した後、1つ以上の2xx応答または1つの非2xx最終応答を取得します。 INVITEへの最終応答を受信するのにかかる時間が長くなるため、INVITEトランザクションの信頼性メカニズムは、他の要求（OPTIONSなど）の信頼性メカニズムとは異なります。最終応答を受信すると、UACは、受信する最終応答ごとにACKを送信する必要があります。このACKを送信する手順は、応答のタイプによって異なります。 300から699の間の最終応答の場合、ACK処理はトランザクション層で行われ、一連のルールに従います（セクション17を参照）。 2xx応答の場合、ACKはUACコアによって生成されます。
A 2xx response to an INVITE establishes a session, and it also creates a dialog between the UA that issued the INVITE and the UA that generated the 2xx response. Therefore, when multiple 2xx responses are received from different remote UAs (because the INVITE forked), each 2xx establishes a different dialog. All these dialogs are part of the same call.
INVITEに対する2xx応答はセッションを確立し、INVITEを発行したUAと2xx応答を生成したUA間のダイアログも作成します。したがって、複数の2xx応答が異なるリモートUAから受信されると（INVITEが分岐するため）、各2xxは異なるダイアログを確立します。これらのダイアログはすべて同じ呼び出しの一部です。
This section provides details on the establishment of a session using INVITE. A UA that supports INVITE MUST also support ACK, CANCEL and BYE.
このセクションでは、INVITEを使用したセッションの確立について詳しく説明します。 INVITEをサポートするUAは、ACK、CANCEL、およびBYEもサポートする必要があります。
Since the initial INVITE represents a request outside of a dialog, its construction follows the procedures of Section 8.1.1. Additional processing is required for the specific case of INVITE.
最初のINVITEはダイアログ外の要求を表すため、その構築はセクション8.1.1の手順に従います。 INVITEの特定のケースでは、追加の処理が必要です。
An Allow header field (Section 20.5) SHOULD be present in the INVITE. It indicates what methods can be invoked within a dialog, on the UA sending the INVITE, for the duration of the dialog. For example, a UA capable of receiving INFO requests within a dialog [34] SHOULD include an Allow header field listing the INFO method.
Allowヘッダーフィールド（セクション20.5）は、INVITEに存在する必要があります（SHOULD）。これは、ダイアログの期間中、INVITEを送信するUAのダイアログ内で呼び出すことができるメソッドを示します。たとえば、ダイアログ内でINFOリクエストを受信できるUA [34]には、INFOメソッドをリストするAllowヘッダーフィールドを含める必要があります（SHOULD）。
A Supported header field (Section 20.37) SHOULD be present in the INVITE. It enumerates all the extensions understood by the UAC.
サポートされているヘッダーフィールド（セクション20.37）は、INVITEに存在する必要があります（SHOULD）。 UACによって理解されるすべての拡張機能を列挙します。
An Accept (Section 20.1) header field MAY be present in the INVITE. It indicates which Content-Types are acceptable to the UA, in both the response received by it, and in any subsequent requests sent to it within dialogs established by the INVITE. The Accept header field is especially useful for indicating support of various session description formats.
Accept（セクション20.1）ヘッダーフィールドがINVITEに存在してもよい（MAY）。それは、UAが受信した応答と、INVITEによって確立されたダイアログ内でそれに送信された後続の要求の両方で、どのContent-TypeがUAに受け入れられるかを示します。 Acceptヘッダーフィールドは、さまざまなセッション記述形式のサポートを示すのに特に役立ちます。
The UAC MAY add an Expires header field (Section 20.19) to limit the validity of the invitation. If the time indicated in the Expires header field is reached and no final answer for the INVITE has been received, the UAC core SHOULD generate a CANCEL request for the INVITE, as per Section 9.
UACは、招待の有効性を制限するためにExpiresヘッダーフィールド（セクション20.19）を追加できます（MAY）。 Expiresヘッダーフィールドに示されている時刻に達し、INVITEの最終応答が受信されなかった場合、UACコアは、セクション9に従って、INVITEのCANCELリクエストを生成する必要があります（SHOULD）。
A UAC MAY also find it useful to add, among others, Subject (Section 20.36), Organization (Section 20.25) and User-Agent (Section 20.41) header fields. They all contain information related to the INVITE.
UACは、とりわけ、Subject（セクション20.36）、Organization（セクション20.25）、およびUser-Agent（セクション20.41）ヘッダーフィールドを追加すると便利な場合があります。それらはすべてINVITEに関連する情報を含んでいます。
The UAC MAY choose to add a message body to the INVITE. Section 8.1.1.10 deals with how to construct the header fields -- Content-Type among others -- needed to describe the message body.
UACは、メッセージ本文をINVITEに追加することを選択できます（MAY）。セクション8.1.1.10では、メッセージ本文の説明に必要なヘッダーフィールド（特にContent-Type）の作成方法について説明します。
There are special rules for message bodies that contain a session description - their corresponding Content-Disposition is "session". SIP uses an offer/answer model where one UA sends a session description, called the offer, which contains a proposed description of the session. The offer indicates the desired communications means (audio, video, games), parameters of those means (such as codec types) and addresses for receiving media from the answerer. The other UA responds with another session description, called the answer, which indicates which communications means are accepted, the parameters that apply to those means, and addresses for receiving media from the offerer. An offer/answer exchange is within the context of a dialog, so that if a SIP INVITE results in multiple dialogs, each is a separate offer/answer exchange. The offer/answer model defines restrictions on when offers and answers can be made (for example, you cannot make a new offer while one is in progress). This results in restrictions on where the offers and answers can appear in SIP messages. In this specification, offers and answers can only appear in INVITE requests and responses, and ACK. The usage of offers and answers is further restricted. For the initial INVITE transaction, the rules are:
セッションの説明を含むメッセージ本文には特別なルールがあります-対応するContent-Dispositionは「セッション」です。 SIPは、オファー/アンサーモデルを使用します。このモデルでは、1つのUAが、オファーと呼ばれるセッションの説明を送信します。オファーは、希望する通信手段（オーディオ、ビデオ、ゲーム）、それらの手段のパラメーター（コーデックの種類など）、および応答者からメディアを受信するためのアドレスを示します。他のUAは、応答と呼ばれる別のセッション記述で応答します。これは、どの通信手段が受け入れられるか、それらの手段に適用されるパラメーター、および提供者からメディアを受信するためのアドレスを示します。オファー/アンサー交換はダイアログのコンテキスト内にあるため、SIP INVITEが複数のダイアログになる場合、それぞれが別個のオファー/アンサー交換になります。オファー/アンサーモデルは、オファーとアンサーを作成できるタイミングに関する制限を定義します（たとえば、オファーの進行中は新しいオファーを作成できません）。これにより、SIPメッセージ内のオファーとアンサーを表示できる場所が制限されます。この仕様では、オファーと回答はINVITEリクエストとレスポンス、およびACKにのみ表示されます。オファーとアンサーの使用はさらに制限されています。最初のINVITEトランザクションの場合、ルールは次のとおりです。
o The initial offer MUST be in either an INVITE or, if not there, in the first reliable non-failure message from the UAS back to the UAC. In this specification, that is the final 2xx response.
o 最初のオファーは、INVITEにあるか、存在しない場合は、UASからUACに戻る最初の信頼できる非障害メッセージにある必要があります。この仕様では、これが最後の2xx応答です。
o If the initial offer is in an INVITE, the answer MUST be in a reliable non-failure message from UAS back to UAC which is correlated to that INVITE. For this specification, that is only the final 2xx response to that INVITE. That same exact answer MAY also be placed in any provisional responses sent prior to the answer. The UAC MUST treat the first session description it receives as the answer, and MUST ignore any session descriptions in subsequent responses to the initial INVITE.
o 最初のオファーがINVITEにある場合、回答は、そのINVITEに関連付けられているUASからUACに戻る、信頼性のある失敗しないメッセージに含まれている必要があります。この仕様では、これはそのINVITEに対する最後の2xx応答にすぎません。同じ正確な回答が、回答の前に送信される仮の回答にも配置される場合があります。 UACは、受け取った最初のセッションの説明を回答として扱う必要があり、最初のINVITEに対する後続の応答でセッションの説明を無視する必要があります。
o If the initial offer is in the first reliable non-failure message from the UAS back to UAC, the answer MUST be in the acknowledgement for that message (in this specification, ACK for a 2xx response).
o 最初のオファーがUASからUACに戻る最初の信頼できる非障害メッセージにある場合、回答はそのメッセージの確認応答になければなりません（この仕様では、2xx応答のACK）。
o After having sent or received an answer to the first offer, the UAC MAY generate subsequent offers in requests based on rules specified for that method, but only if it has received answers to any previous offers, and has not sent any offers to which it hasn't gotten an answer.
o UACは、最初のオファーへの回答を送信または受信した後、そのメソッドに指定されたルールに基づいてリクエストで後続のオファーを生成できます（ただし、以前のオファーへの回答を受信し、そのオファーを送信していない場合のみ）。答えを得られませんでした。
o Once the UAS has sent or received an answer to the initial offer, it MUST NOT generate subsequent offers in any responses to the initial INVITE. This means that a UAS based on this specification alone can never generate subsequent offers until completion of the initial transaction.
o UASが最初のオファーへの応答を送信または受信すると、最初のINVITEへの応答で後続のオファーを生成してはなりません。つまり、この仕様に基づくUASだけでは、最初のトランザクションが完了するまで、後続のオファーを生成できません。
Concretely, the above rules specify two exchanges for UAs compliant to this specification alone - the offer is in the INVITE, and the answer in the 2xx (and possibly in a 1xx as well, with the same value), or the offer is in the 2xx, and the answer is in the ACK. All user agents that support INVITE MUST support these two exchanges.
具体的には、上記のルールは、この仕様のみに準拠するUAの2つの交換を指定します。オファーはINVITEにあり、回答は2xx（場合によっては1xxにも同じ値）であるか、オファーは2xx、答えはACKにあります。 INVITEをサポートするすべてのユーザーエージェントは、これら2つの交換をサポートする必要があります。
The Session Description Protocol (SDP) (RFC 2327 [1]) MUST be supported by all user agents as a means to describe sessions, and its usage for constructing offers and answers MUST follow the procedures defined in [13].
セッション記述プロトコル（SDP）（RFC 2327 [1]）は、セッションを記述する手段としてすべてのユーザーエージェントによってサポートされる必要があり、オファーとアンサーを構築するためのその使用法は、[13]で定義された手順に従う必要があります。
The restrictions of the offer-answer model just described only apply to bodies whose Content-Disposition header field value is "session". Therefore, it is possible that both the INVITE and the ACK contain a body message (for example, the INVITE carries a photo (Content-Disposition: render) and the ACK a session description (Content-Disposition: session)).
今説明したオファー/アンサーモデルの制限は、Content-Dispositionヘッダーフィールドの値が「セッション」である本文にのみ適用されます。したがって、INVITEとACKの両方に本文メッセージが含まれている可能性があります（たとえば、INVITEは写真（Content-Disposition：render）を、ACKはセッションの説明（Content-Disposition：session）を伝送します）。
If the Content-Disposition header field is missing, bodies of Content-Type application/sdp imply the disposition "session", while other content types imply "render".
Content-Dispositionヘッダーフィールドが欠落している場合、Content-Type application / sdpの本文は処理「セッション」を意味し、他のコンテンツタイプは「レンダリング」を意味します。
Once the INVITE has been created, the UAC follows the procedures defined for sending requests outside of a dialog (Section 8). This results in the construction of a client transaction that will ultimately send the request and deliver responses to the UAC.
INVITEが作成されると、UACはダイアログの外でリクエストを送信するために定義された手順に従います（セクション8）。これにより、最終的に要求を送信し、応答をUACに配信するクライアントトランザクションが構築されます。
Once the INVITE has been passed to the INVITE client transaction, the UAC waits for responses for the INVITE. If the INVITE client transaction returns a timeout rather than a response the TU acts as if a 408 (Request Timeout) response had been received, as described in Section 8.1.3.
INVITEがINVITEクライアントトランザクションに渡されると、UACはINVITEの応答を待ちます。 INVITEクライアントトランザクションが応答ではなくタイムアウトを返す場合、セクション8.1.3で説明するように、TUは408（Request Timeout）応答を受信したかのように動作します。
Zero, one or multiple provisional responses may arrive before one or more final responses are received. Provisional responses for an INVITE request can create "early dialogs". If a provisional response has a tag in the To field, and if the dialog ID of the response does not match an existing dialog, one is constructed using the procedures defined in Section 12.1.2.
1つ以上の最終応答が受信される前に、ゼロ、1つ、または複数の暫定応答が到着する場合があります。 INVITEリクエストに対する暫定的な応答により、「初期のダイアログ」が作成される場合があります。暫定応答の[宛先]フィールドにタグがあり、応答のダイアログIDが既存のダイアログと一致しない場合、セクション12.1.2で定義されている手順を使用してダイアログが作成されます。
The early dialog will only be needed if the UAC needs to send a request to its peer within the dialog before the initial INVITE transaction completes. Header fields present in a provisional response are applicable as long as the dialog is in the early state (for example, an Allow header field in a provisional response contains the methods that can be used in the dialog while this is in the early state).
初期のダイアログは、UACが最初のINVITEトランザクションが完了する前にダイアログ内のピアにリクエストを送信する必要がある場合にのみ必要です。暫定応答に存在するヘッダーフィールドは、ダイアログが初期状態である限り適用できます（たとえば、暫定応答のAllowヘッダーフィールドには、初期状態のダイアログで使用できるメソッドが含まれています）。
A 3xx response may contain one or more Contact header field values providing new addresses where the callee might be reachable. Depending on the status code of the 3xx response (see Section 21.3), the UAC MAY choose to try those new addresses.
3xx応答には、1つ以上のContactヘッダーフィールド値が含まれる場合があり、呼び出し先が到達可能な新しいアドレスを提供します。 3xx応答のステータスコード（セクション21.3を参照）に応じて、UACはそれらの新しいアドレスを試すことを選択できます（MAY）。
A single non-2xx final response may be received for the INVITE. 4xx, 5xx and 6xx responses may contain a Contact header field value indicating the location where additional information about the error can be found. Subsequent final responses (which would only arrive under error conditions) MUST be ignored.
INVITEに対して、1つの非2xx最終応答が受信される場合があります。 4xx、5xx、6xx応答には、エラーに関する追加情報が見つかる場所を示すContactヘッダーフィールド値が含まれる場合があります。 （エラー状態でのみ到着する）後続の最終応答は無視する必要があります。
All early dialogs are considered terminated upon reception of the non-2xx final response.
すべての初期のダイアログは、2xx以外の最終応答を受信すると終了したと見なされます。
After having received the non-2xx final response the UAC core considers the INVITE transaction completed. The INVITE client transaction handles the generation of ACKs for the response (see Section 17).
非2xx最終応答を受信した後、UACコアはINVITEトランザクションが完了したと見なします。 INVITEクライアントトランザクションは、応答のACKの生成を処理します（セクション17を参照）。
Multiple 2xx responses may arrive at the UAC for a single INVITE request due to a forking proxy. Each response is distinguished by the tag parameter in the To header field, and each represents a distinct dialog, with a distinct dialog identifier.
フォーキングプロキシが原因で、1つのINVITEリクエストに対して複数の2xx応答がUACに到着する場合があります。各応答は、Toヘッダーフィールドのタグパラメータによって区別され、それぞれが個別のダイアログ識別子を持つ個別のダイアログを表します。
If the dialog identifier in the 2xx response matches the dialog identifier of an existing dialog, the dialog MUST be transitioned to the "confirmed" state, and the route set for the dialog MUST be recomputed based on the 2xx response using the procedures of Section 12.2.1.2. Otherwise, a new dialog in the "confirmed" state MUST be constructed using the procedures of Section 12.1.2.
2xx応答のダイアログ識別子が既存のダイアログのダイアログ識別子と一致する場合、ダイアログは「確認済み」状態に移行する必要があり、ダイアログに設定されたルートは、セクション12.2の手順を使用して2xx応答に基づいて再計算する必要があります。 .1.2。それ以外の場合、「確認済み」状態の新しいダイアログは、セクション12.1.2の手順を使用して構築する必要があります。
Note that the only piece of state that is recomputed is the route set. Other pieces of state such as the highest sequence numbers (remote and local) sent within the dialog are not recomputed. The route set only is recomputed for backwards compatibility. RFC 2543 did not mandate mirroring of the Record-Route header field in a 1xx, only 2xx. However, we cannot update the entire state of the dialog, since mid-dialog requests may have been sent within the early dialog, modifying the sequence numbers, for example.
再計算される唯一の状態はルートセットであることに注意してください。ダイアログ内で送信された最大のシーケンス番号（リモートおよびローカル）などの他の状態は再計算されません。ルートセットのみが下位互換性のために再計算されます。 RFC 2543は、1xxではRecord-Routeヘッダーフィールドのミラーリングを義務付けていませんでした。2xxのみです。ただし、ダイアログ全体の状態を更新することはできません。たとえば、ダイアログの途中で要求が送信され、シーケンス番号が変更されたためです。
The UAC core MUST generate an ACK request for each 2xx received from the transaction layer. The header fields of the ACK are constructed in the same way as for any request sent within a dialog (see Section 12) with the exception of the CSeq and the header fields related to authentication. The sequence number of the CSeq header field MUST be the same as the INVITE being acknowledged, but the CSeq method MUST be ACK. The ACK MUST contain the same credentials as the INVITE. If the 2xx contains an offer (based on the rules above), the ACK MUST carry an answer in its body. If the offer in the 2xx response is not acceptable, the UAC core MUST generate a valid answer in the ACK and then send a BYE immediately.
UACコアは、トランザクションレイヤーから受信した2xxごとにACK要求を生成する必要があります。 ACKのヘッダーフィールドは、CSeqと認証に関連するヘッダーフィールドを除いて、ダイアログ内で送信されるリクエスト（セクション12を参照）と同じ方法で作成されます。 CSeqヘッダーフィールドのシーケンス番号は確認されるINVITEと同じである必要がありますが、CSeqメソッドはACKである必要があります。 ACKには、INVITEと同じ資格が含まれている必要があります。 2xxに（上記のルールに基づく）オファーが含まれている場合、ACKは本文に回答を含める必要があります。 2xx応答のオファーが受け入れられない場合、UACコアはACKで有効な応答を生成してから、すぐにBYEを送信する必要があります。
Once the ACK has been constructed, the procedures of [4] are used to determine the destination address, port and transport. However, the request is passed to the transport layer directly for transmission, rather than a client transaction. This is because the UAC core handles retransmissions of the ACK, not the transaction layer. The ACK MUST be passed to the client transport every time a retransmission of the 2xx final response that triggered the ACK arrives.
ACKが作成されると、[4]の手順を使用して、宛先アドレス、ポート、およびトランスポートが決定されます。ただし、要求はクライアントトランザクションではなく、トランスポート層に直接渡されて送信されます。これは、UACコアがトランザクションレイヤーではなくACKの再送信を処理するためです。 ACKをトリガーした2xx最終応答の再送信が到着するたびに、ACKをクライアントトランスポートに渡す必要があります。
The UAC core considers the INVITE transaction completed 64*T1 seconds after the reception of the first 2xx response. At this point all the early dialogs that have not transitioned to established dialogs are terminated. Once the INVITE transaction is considered completed by the UAC core, no more new 2xx responses are expected to arrive.
UACコアは、最初の2xx応答を受信してから64 * T1秒後にINVITEトランザクションが完了したと見なします。この時点で、確立されたダイアログに移行していない初期のダイアログはすべて終了します。 INVITEトランザクションがUACコアによって完了したと見なされると、新しい2xx応答が到着することはありません。
If, after acknowledging any 2xx response to an INVITE, the UAC does not want to continue with that dialog, then the UAC MUST terminate the dialog by sending a BYE request as described in Section 15.
INVITEに対する2xx応答を確認した後、UACがそのダイアログを続行したくない場合、UACはセクション15で説明されているようにBYEリクエストを送信してダイアログを終了しなければなりません（MUST）。
The UAS core will receive INVITE requests from the transaction layer. It first performs the request processing procedures of Section 8.2, which are applied for both requests inside and outside of a dialog.
UASコアは、トランザクションレイヤーからINVITEリクエストを受信します。まず、セクション8.2の要求処理手順を実行します。これは、ダイアログの内部と外部の両方の要求に適用されます。
Assuming these processing states are completed without generating a response, the UAS core performs the additional processing steps:
これらの処理状態が応答を生成せずに完了すると想定すると、UASコアは追加の処理手順を実行します。
1. If the request is an INVITE that contains an Expires header field, the UAS core sets a timer for the number of seconds indicated in the header field value. When the timer fires, the invitation is considered to be expired. If the invitation expires before the UAS has generated a final response, a 487 (Request Terminated) response SHOULD be generated.
1. 要求がExpiresヘッダーフィールドを含むINVITEである場合、UASコアは、ヘッダーフィールド値に示されている秒数のタイマーを設定します。タイマーが作動すると、招待は期限切れと見なされます。 UASが最終応答を生成する前に招待が期限切れになる場合は、487（要求終了）応答を生成する必要があります（SHOULD）。
2. If the request is a mid-dialog request, the method-independent processing described in Section 12.2.2 is first applied. It might also modify the session; Section 14 provides details.
2. 要求がダイアログ中の要求である場合、12.2.2項で説明されているメソッドに依存しない処理が最初に適用されます。セッションを変更することもあります。セクション14で詳細を説明します。
3. If the request has a tag in the To header field but the dialog identifier does not match any of the existing dialogs, the UAS may have crashed and restarted, or may have received a request for a different (possibly failed) UAS. Section 12.2.2 provides guidelines to achieve a robust behavior under such a situation.
3. 要求のToヘッダーフィールドにタグがあっても、ダイアログ識別子が既存のダイアログのいずれとも一致しない場合、UASがクラッシュして再起動したか、別の（おそらく失敗した）UASの要求を受け取った可能性があります。セクション12.2.2は、このような状況で堅牢な動作を実現するためのガイドラインを提供します。
Processing from here forward assumes that the INVITE is outside of a dialog, and is thus for the purposes of establishing a new session.
ここから先の処理では、INVITEはダイアログの外側にあるため、新しいセッションを確立することを前提としています。
The INVITE may contain a session description, in which case the UAS is being presented with an offer for that session. It is possible that the user is already a participant in that session, even though the INVITE is outside of a dialog. This can happen when a user is invited to the same multicast conference by multiple other participants. If desired, the UAS MAY use identifiers within the session description to detect this duplication. For example, SDP contains a session id and version number in the origin (o) field. If the user is already a member of the session, and the session parameters contained in the session description have not changed, the UAS MAY silently accept the INVITE (that is, send a 2xx response without prompting the user).
INVITEにはセッションの説明を含めることができます。その場合、UASにはそのセッションのオファーが提示されます。 INVITEがダイアログの外にある場合でも、ユーザーがそのセッションにすでに参加している可能性があります。これは、ユーザーが他の複数の参加者によって同じマルチキャスト会議に招待された場合に発生する可能性があります。必要に応じて、UASはセッションの説明内で識別子を使用して、この重複を検出できます。たとえば、SDPのorigin（o）フィールドにはセッションIDとバージョン番号が含まれています。ユーザーが既にセッションのメンバーであり、セッションの説明に含まれているセッションパラメーターが変更されていない場合、UASは暗黙的にINVITEを受け入れます（つまり、ユーザーにプロンプトを表示せずに2xx応答を送信します）。
If the INVITE does not contain a session description, the UAS is being asked to participate in a session, and the UAC has asked that the UAS provide the offer of the session. It MUST provide the offer in its first non-failure reliable message back to the UAC. In this specification, that is a 2xx response to the INVITE.
INVITEにセッションの説明が含まれていない場合、UASはセッションへの参加を求められており、UACはUASがセッションのオファーを提供するように求めています。それはUACに戻る最初の失敗しない信頼できるメッセージでオファーを提供しなければなりません。この仕様では、これはINVITEに対する2xx応答です。
The UAS can indicate progress, accept, redirect, or reject the invitation. In all of these cases, it formulates a response using the procedures described in Section 8.2.6.
UASは、進行状況を示したり、招待を承認、リダイレクト、または拒否したりできます。これらすべてのケースで、セクション8.2.6で説明されている手順を使用して応答を作成します。
If the UAS is not able to answer the invitation immediately, it can choose to indicate some kind of progress to the UAC (for example, an indication that a phone is ringing). This is accomplished with a provisional response between 101 and 199. These provisional responses establish early dialogs and therefore follow the procedures of Section 12.1.1 in addition to those of Section 8.2.6. A UAS MAY send as many provisional responses as it likes. Each of these MUST indicate the same dialog ID. However, these will not be delivered reliably.
UASが招待にすぐに応答できない場合、UACに何らかの進行状況を示すことを選択できます（たとえば、電話が鳴っているという表示）。これは、101から199までの暫定応答で達成されます。これらの暫定応答は、初期の対話を確立するため、セクション8.2.6の手順に加えて、セクション12.1.1の手順に従います。 UASは、必要なだけの暫定応答を送信できます。これらはそれぞれ同じダイアログIDを示している必要があります。ただし、これらは確実に配信されません。
If the UAS desires an extended period of time to answer the INVITE, it will need to ask for an "extension" in order to prevent proxies from canceling the transaction. A proxy has the option of canceling a transaction when there is a gap of 3 minutes between responses in a transaction. To prevent cancellation, the UAS MUST send a non-100 provisional response at every minute, to handle the possibility of lost provisional responses.
UASがINVITEに応答するために長期間を希望する場合、プロキシがトランザクションをキャンセルしないように、「延長」を要求する必要があります。プロキシには、トランザクションの応答間に3分のギャップがある場合にトランザクションをキャンセルするオプションがあります。キャンセルを防ぐために、UASは毎分100以外の暫定応答を送信して、暫定応答が失われる可能性を処理する必要があります。
An INVITE transaction can go on for extended durations when the user is placed on hold, or when interworking with PSTN systems which allow communications to take place without answering the call. The latter is common in Interactive Voice Response (IVR) systems.
INVITEトランザクションは、ユーザーが保留にされているとき、または通話に応答せずに通信を行うことができるPSTNシステムと相互に作用しているときに、長時間継続することができます。後者は、対話型音声応答（IVR）システムでは一般的です。
If the UAS decides to redirect the call, a 3xx response is sent. A 300 (Multiple Choices), 301 (Moved Permanently) or 302 (Moved Temporarily) response SHOULD contain a Contact header field containing one or more URIs of new addresses to be tried. The response is passed to the INVITE server transaction, which will deal with its retransmissions.
UASがコールをリダイレクトすることを決定した場合、3xx応答が送信されます。 300（Multiple Choices）、301（Moved Permanently）、または302（Moved Temporarily）のレスポンスには、試行する新しいアドレスの1つ以上のURIを含むContactヘッダーフィールドを含める必要があります。応答は、その再送信を処理するINVITEサーバートランザクションに渡されます。
A common scenario occurs when the callee is currently not willing or able to take additional calls at this end system. A 486 (Busy Here) SHOULD be returned in such a scenario. If the UAS knows that no other end system will be able to accept this call, a 600 (Busy Everywhere) response SHOULD be sent instead. However, it is unlikely that a UAS will be able to know this in general, and thus this response will not usually be used. The response is passed to the INVITE server transaction, which will deal with its retransmissions.
一般的なシナリオは、呼び出し先が現在、このエンドシステムで追加の呼び出しを行う意思がないか、できない場合に発生します。そのようなシナリオでは、486（Busy Here）を返す必要があります。他のエンドシステムがこの呼び出しを受け入れることができないことをUASが知っている場合は、代わりに600（Busy Everywhere）応答を送信する必要があります（SHOULD）。ただし、UASがこれを一般的に認識できる可能性は低いため、この応答は通常は使用されません。応答は、その再送信を処理するINVITEサーバートランザクションに渡されます。
A UAS rejecting an offer contained in an INVITE SHOULD return a 488 (Not Acceptable Here) response. Such a response SHOULD include a Warning header field value explaining why the offer was rejected.
INVITE SHOULDに含まれるオファーを拒否するUASは、488（Not Acceptable Here）応答を返す必要があります。このような応答には、オファーが拒否された理由を説明する警告ヘッダーフィールド値を含める必要があります（SHOULD）。
The UAS core generates a 2xx response. This response establishes a dialog, and therefore follows the procedures of Section 12.1.1 in addition to those of Section 8.2.6.
UASコアは2xx応答を生成します。この応答はダイアログを確立するため、セクション8.2.6の手順に加えてセクション12.1.1の手順に従います。
A 2xx response to an INVITE SHOULD contain the Allow header field and the Supported header field, and MAY contain the Accept header field. Including these header fields allows the UAC to determine the features and extensions supported by the UAS for the duration of the call, without probing.
INVITE SHOULDへの2xx応答には、AllowヘッダーフィールドとSupportedヘッダーフィールドが含まれている必要があり、またAcceptヘッダーフィールドが含まれている場合があります。これらのヘッダーフィールドを含めると、UACは、プローブすることなく、コールの期間中、UASによってサポートされる機能と拡張機能を決定できます。
If the INVITE request contained an offer, and the UAS had not yet sent an answer, the 2xx MUST contain an answer. If the INVITE did not contain an offer, the 2xx MUST contain an offer if the UAS had not yet sent an offer.
INVITEリクエストにオファーが含まれていて、UASがまだ回答を送信していない場合、2xxには回答が含まれている必要があります。 INVITEにオファーが含まれていない場合、UASがまだオファーを送信していない場合、2xxにはオファーが含まれている必要があります。
Once the response has been constructed, it is passed to the INVITE server transaction. Note, however, that the INVITE server transaction will be destroyed as soon as it receives this final response and passes it to the transport. Therefore, it is necessary to periodically pass the response directly to the transport until the ACK arrives. The 2xx response is passed to the transport with an interval that starts at T1 seconds and doubles for each retransmission until it reaches T2 seconds (T1 and T2 are defined in Section 17). Response retransmissions cease when an ACK request for the response is received. This is independent of whatever transport protocols are used to send the response.
応答が作成されると、INVITEサーバートランザクションに渡されます。ただし、INVITEサーバートランザクションは、この最終応答を受信してトランスポートに渡すとすぐに破棄されることに注意してください。したがって、ACKが到着するまで、応答を定期的にトランスポートに直接渡す必要があります。 2xx応答は、T1秒から始まり、T2秒に達するまで再送信ごとに2倍になる間隔でトランスポートに渡されます（T1とT2はセクション17で定義されています）。応答のACK要求を受信すると、応答の再送信が停止します。これは、応答の送信に使用されるトランスポートプロトコルとは無関係です。
Since 2xx is retransmitted end-to-end, there may be hops between UAS and UAC that are UDP. To ensure reliable delivery across these hops, the response is retransmitted periodically even if the transport at the UAS is reliable.
2xxはエンドツーエンドで再送信されるため、UASとUACの間にUDPのホップが存在する場合があります。これらのホップで確実に配信されるように、UASでのトランスポートが信頼できる場合でも、応答は定期的に再送信されます。
If the server retransmits the 2xx response for 64*T1 seconds without receiving an ACK, the dialog is confirmed, but the session SHOULD be terminated. This is accomplished with a BYE, as described in Section 15.
サーバーがACKを受信せずに2xx応答を64 * T1秒間再送信すると、ダイアログは確認されますが、セッションは終了する必要があります（SHOULD）。これは、セクション15で説明されているように、BYEで実行されます。
14 Modifying an Existing Session
14既存のセッションの変更
A successful INVITE request (see Section 13) establishes both a dialog between two user agents and a session using the offer-answer model. Section 12 explains how to modify an existing dialog using a target refresh request (for example, changing the remote target URI of the dialog). This section describes how to modify the actual session. This modification can involve changing addresses or ports, adding a media stream, deleting a media stream, and so on. This is accomplished by sending a new INVITE request within the same dialog that established the session. An INVITE request sent within an existing dialog is known as a re-INVITE.
INVITEリクエストが成功すると（セクション13を参照）、2つのユーザーエージェント間のダイアログと、オファー/アンサーモデルを使用したセッションの両方が確立されます。セクション12では、ターゲットリフレッシュリクエストを使用して既存のダイアログを変更する方法を説明します（たとえば、ダイアログのリモートターゲットURIを変更します）。このセクションでは、実際のセッションを変更する方法について説明します。この変更には、アドレスまたはポートの変更、メディアストリームの追加、メディアストリームの削除などが含まれます。これは、セッションを確立したのと同じダイアログ内で新しいINVITE要求を送信することによって行われます。既存のダイアログ内で送信されたINVITEリクエストは、re-INVITEと呼ばれます。
Note that a single re-INVITE can modify the dialog and the parameters of the session at the same time.
1回のre-INVITEで、ダイアログとセッションのパラメーターを同時に変更できることに注意してください。
Either the caller or callee can modify an existing session.
呼び出し元または呼び出し先のどちらかが既存のセッションを変更できます。
The behavior of a UA on detection of media failure is a matter of local policy. However, automated generation of re-INVITE or BYE is NOT RECOMMENDED to avoid flooding the network with traffic when there is congestion. In any case, if these messages are sent automatically, they SHOULD be sent after some randomized interval.
メディア障害の検出におけるUAの動作は、ローカルポリシーの問題です。ただし、re-INVITEまたはBYEの自動生成は、輻輳時にネットワークがトラフィックで溢れるのを避けるために推奨されていません。いずれの場合でも、これらのメッセージが自動的に送信される場合は、ランダムな間隔を置いて送信する必要があります（SHOULD）。
Note that the paragraph above refers to automatically generated BYEs and re-INVITEs. If the user hangs up upon media failure, the UA would send a BYE request as usual.
上記の段落は、自動的に生成されたBYEとre-INVITEを指していることに注意してください。ユーザーがメディア障害で電話を切ると、UAは通常どおりBYE要求を送信します。
The same offer-answer model that applies to session descriptions in INVITEs (Section 13.2.1) applies to re-INVITEs. As a result, a UAC that wants to add a media stream, for example, will create a new offer that contains this media stream, and send that in an INVITE request to its peer. It is important to note that the full description of the session, not just the change, is sent. This supports stateless session processing in various elements, and supports failover and recovery capabilities. Of course, a UAC MAY send a re-INVITE with no session description, in which case the first reliable non-failure response to the re-INVITE will contain the offer (in this specification, that is a 2xx response).
INVITEのセッション記述（セクション13.2.1）に適用されるのと同じオファー応答モデルがre-INVITEにも適用されます。その結果、たとえば、メディアストリームを追加するUACは、このメディアストリームを含む新しいオファーを作成し、INVITEリクエストでピアに送信します。変更だけでなく、セッションの完全な説明が送信されることに注意することが重要です。これは、さまざまな要素のステートレスセッション処理をサポートし、フェイルオーバーおよびリカバリ機能をサポートします。もちろん、UACはセッションの説明なしでre-INVITEを送信できます。その場合、re-INVITEへの最初の信頼できる非障害応答にはオファーが含まれます（この仕様では、2xx応答です）。
If the session description format has the capability for version numbers, the offerer SHOULD indicate that the version of the session description has changed.
セッション記述形式にバージョン番号の機能がある場合、提供者は、セッション記述のバージョンが変更されたことを示す必要があります（SHOULD）。
The To, From, Call-ID, CSeq, and Request-URI of a re-INVITE are set following the same rules as for regular requests within an existing dialog, described in Section 12.
re-INVITEのTo、From、Call-ID、CSeq、およびRequest-URIは、セクション12で説明されている、既存のダイアログ内の通常のリクエストと同じルールに従って設定されます。
A UAC MAY choose not to add an Alert-Info header field or a body with Content-Disposition "alert" to re-INVITEs because UASs do not typically alert the user upon reception of a re-INVITE.
UASは通常re-INVITEの受信時にユーザーに警告しないため、UACはAlert-InfoヘッダーフィールドまたはContent-Disposition "alert"の本文を追加しないことを選択できます（MAY）。
Unlike an INVITE, which can fork, a re-INVITE will never fork, and therefore, only ever generate a single final response. The reason a re-INVITE will never fork is that the Request-URI identifies the target as the UA instance it established the dialog with, rather than identifying an address-of-record for the user.
フォークできるINVITEとは異なり、re-INVITEは決してフォークしないため、単一の最終応答しか生成しません。 re-INVITEが決してフォークしない理由は、Request-URIがターゲットを、ユーザーのレコードのアドレスを識別するのではなく、ダイアログを確立したUAインスタンスとして識別するためです。
Note that a UAC MUST NOT initiate a new INVITE transaction within a dialog while another INVITE transaction is in progress in either direction.
UACは、別のINVITEトランザクションがいずれかの方向で進行中の間、ダイアログ内で新しいINVITEトランザクションを開始してはならないことに注意してください。
1. If there is an ongoing INVITE client transaction, the TU MUST wait until the transaction reaches the completed or terminated state before initiating the new INVITE.
1. 進行中のINVITEクライアントトランザクションがある場合、TUは、新しいINVITEを開始する前に、トランザクションが完了または終了状態に達するまで待機する必要があります。
2. If there is an ongoing INVITE server transaction, the TU MUST wait until the transaction reaches the confirmed or terminated state before initiating the new INVITE.
2. 進行中のINVITEサーバートランザクションがある場合、TUは、新しいINVITEを開始する前に、トランザクションが確認済みまたは終了状態に達するまで待機する必要があります。
However, a UA MAY initiate a regular transaction while an INVITE transaction is in progress. A UA MAY also initiate an INVITE transaction while a regular transaction is in progress.
ただし、UAは、INVITEトランザクションの進行中に通常のトランザクションを開始できます（MAY）。 UAは、通常のトランザクションの進行中にINVITEトランザクションを開始することもできます（MAY）。
If a UA receives a non-2xx final response to a re-INVITE, the session parameters MUST remain unchanged, as if no re-INVITE had been issued. Note that, as stated in Section 12.2.1.2, if the non-2xx final response is a 481 (Call/Transaction Does Not Exist), or a 408 (Request Timeout), or no response at all is received for the re-INVITE (that is, a timeout is returned by the INVITE client transaction), the UAC will terminate the dialog.
UAがre-INVITEに対する2xx以外の最終応答を受信した場合、re-INVITEが発行されなかったかのように、セッションパラメータは変更されないままでなければなりません。セクション12.2.1.2に記載されているように、2xx以外の最終応答が481（コール/トランザクションが存在しない）または408（リクエストタイムアウト）である場合、またはre-INVITEに対する応答がまったく受信されない場合（つまり、タイムアウトがINVITEクライアントトランザクションによって返されます）、UACはダイアログを終了します。
If a UAC receives a 491 response to a re-INVITE, it SHOULD start a timer with a value T chosen as follows:
UACがre-INVITEに対する491応答を受信した場合、UACは次のように選択された値Tでタイマーを開始する必要があります（SHOULD）。
1. If the UAC is the owner of the Call-ID of the dialog ID (meaning it generated the value), T has a randomly chosen value between 2.1 and 4 seconds in units of 10 ms.
1. UACがダイアログIDのCall-IDの所有者である場合（値が生成されたことを意味します）、Tのランダムに選択された値は、10ミリ秒単位で2.1〜4秒です。
2. If the UAC is not the owner of the Call-ID of the dialog ID, T has a randomly chosen value of between 0 and 2 seconds in units of 10 ms.
2. UACがダイアログIDのCall-IDの所有者ではない場合、Tは0から2秒の間でランダムに選択された値を10ミリ秒単位で持っています。
When the timer fires, the UAC SHOULD attempt the re-INVITE once more, if it still desires for that session modification to take place. For example, if the call was already hung up with a BYE, the re-INVITE would not take place.
タイマーが作動すると、UACは、そのセッションの変更が引き続き行われることを望んでいる場合、もう一度再招待を試行する必要があります（SHOULD）。たとえば、コールがすでにBYEで切断されている場合、re-INVITEは行われません。
The rules for transmitting a re-INVITE and for generating an ACK for a 2xx response to re-INVITE are the same as for the initial INVITE (Section 13.2.1).
re-INVITEを送信するためのルールと、re-INVITEへの2xx応答のACKを生成するためのルールは、最初のINVITEの場合と同じです（セクション13.2.1）。
Section 13.3.1 describes the procedure for distinguishing incoming re-INVITEs from incoming initial INVITEs and handling a re-INVITE for an existing dialog.
セクション13.3.1では、着信re-INVITEを着信初期INVITEから区別し、既存のダイアログのre-INVITEを処理する手順について説明します。
A UAS that receives a second INVITE before it sends the final response to a first INVITE with a lower CSeq sequence number on the same dialog MUST return a 500 (Server Internal Error) response to the second INVITE and MUST include a Retry-After header field with a randomly chosen value of between 0 and 10 seconds.
同じダイアログでCSeqシーケンス番号が小さい最初のINVITEに最終応答を送信する前に2番目のINVITEを受信するUASは、2番目のINVITEに500（サーバー内部エラー）応答を返さなければならず、Retry-Afterヘッダーフィールドを含める必要があります。ランダムに選択された0〜10秒の値。
A UAS that receives an INVITE on a dialog while an INVITE it had sent on that dialog is in progress MUST return a 491 (Request Pending) response to the received INVITE.
ダイアログで送信したINVITEの進行中にダイアログでINVITEを受信するUASは、受信したINVITEに491（Request Pending）応答を返さなければなりません（MUST）。
If a UA receives a re-INVITE for an existing dialog, it MUST check any version identifiers in the session description or, if there are no version identifiers, the content of the session description to see if it has changed. If the session description has changed, the UAS MUST adjust the session parameters accordingly, possibly after asking the user for confirmation.
UAが既存のダイアログのre-INVITEを受信した場合、セッション記述のバージョン識別子を確認する必要があります。バージョン識別子がない場合は、セッション記述の内容が変更されたかどうかを確認する必要があります。セッションの説明が変更された場合、UASは、おそらくユーザーに確認を求めた後、それに応じてセッションパラメータを調整する必要があります。
Versioning of the session description can be used to accommodate the capabilities of new arrivals to a conference, add or delete media, or change from a unicast to a multicast conference.
セッション記述のバージョン管理を使用して、会議への新着者の機能に対応したり、メディアを追加または削除したり、ユニキャストからマルチキャスト会議に変更したりできます。
If the new session description is not acceptable, the UAS can reject it by returning a 488 (Not Acceptable Here) response for the re-INVITE. This response SHOULD include a Warning header field.
新しいセッションの説明が受け入れられない場合、UASはre-INVITEに対して488（Not Acceptable Here）応答を返すことにより、それを拒否できます。この応答には警告ヘッダーフィールドを含める必要があります（SHOULD）。
If a UAS generates a 2xx response and never receives an ACK, it SHOULD generate a BYE to terminate the dialog.
UASが2xx応答を生成し、ACKを受信しない場合は、BYEを生成してダイアログを終了する必要があります（SHOULD）。
A UAS MAY choose not to generate 180 (Ringing) responses for a re-INVITE because UACs do not typically render this information to the user. For the same reason, UASs MAY choose not to use an Alert-Info header field or a body with Content-Disposition "alert" in responses to a re-INVITE.
UACは通常、この情報をユーザーに表示しないため、UASはre-INVITEに対して180（Ringing）応答を生成しないことを選択できます。同じ理由で、UASはre-INVITEへの応答でAlert-InfoヘッダーフィールドまたはContent-Disposition "alert"の本文を使用しないことを選択できます（MAY）。
A UAS providing an offer in a 2xx (because the INVITE did not contain an offer) SHOULD construct the offer as if the UAS were making a brand new call, subject to the constraints of sending an offer that updates an existing session, as described in [13] in the case of SDP. Specifically, this means that it SHOULD include as many media formats and media types that the UA is willing to support. The UAS MUST ensure that the session description overlaps with its previous session description in media formats, transports, or other parameters that require support from the peer. This is to avoid the need for the peer to reject the session description. If, however, it is unacceptable to the UAC, the UAC SHOULD generate an answer with a valid session description, and then send a BYE to terminate the session.
2xxでオファーを提供するUAS（INVITEにオファーが含まれていなかったため）は、既存のセッションを更新するオファーを送信するという制約に従って、UASがまったく新しい呼び出しを行っているかのようにオファーを構築する必要があります。 [13] SDPの場合。具体的には、これは、UAがサポートしようとするのと同じ数のメディアフォーマットとメディアタイプを含める必要があることを意味します。 UASは、セッション形式が、メディア形式、トランスポート、またはピアからのサポートを必要とするその他のパラメーターの以前のセッション形式と重複していることを確認する必要があります。これは、ピアがセッションの説明を拒否する必要をなくすためです。ただし、UACが受け入れられない場合、UACは有効なセッションの説明を含む応答を生成し、BYEを送信してセッションを終了する必要があります（SHOULD）。
15 Terminating a Session
15セッションの終了
This section describes the procedures for terminating a session established by SIP. The state of the session and the state of the dialog are very closely related. When a session is initiated with an INVITE, each 1xx or 2xx response from a distinct UAS creates a dialog, and if that response completes the offer/answer exchange, it also creates a session. As a result, each session is "associated" with a single dialog - the one which resulted in its creation. If an initial INVITE generates a non-2xx final response, that terminates all sessions (if any) and all dialogs (if any) that were created through responses to the request. By virtue of completing the transaction, a non-2xx final response also prevents further sessions from being created as a result of the INVITE. The BYE request is used to terminate a specific session or attempted session. In this case, the specific session is the one with the peer UA on the other side of the dialog. When a BYE is received on a dialog, any session associated with that dialog SHOULD terminate. A UA MUST NOT send a BYE outside of a dialog. The caller's UA MAY send a BYE for either confirmed or early dialogs, and the callee's UA MAY send a BYE on confirmed dialogs, but MUST NOT send a BYE on early dialogs.
このセクションでは、SIPによって確立されたセッションを終了する手順について説明します。セッションの状態とダイアログの状態は非常に密接に関連しています。 INVITEでセッションが開始されると、個別のUASからの各1xxまたは2xx応答がダイアログを作成し、その応答がオファー/アンサー交換を完了すると、セッションも作成します。その結果、各セッションは単一のダイアログに関連付けられ、そのダイアログが作成されました。最初のINVITEが2xx以外の最終応答を生成すると、要求への応答を通じて作成されたすべてのセッション（存在する場合）およびすべてのダイアログ（存在する場合）が終了します。トランザクションが完了するため、2xx以外の最終応答では、INVITEの結果として以降のセッションが作成されることも防止されます。 BYE要求は、特定のセッションまたは試行されたセッションを終了するために使用されます。この場合、特定のセッションは、ダイアログの反対側にあるピアUAとのセッションです。 BYEがダイアログで受信されると、そのダイアログに関連付けられているすべてのセッションが終了する必要があります（SHOULD）。 UAはダイアログの外でBYEを送信してはなりません。呼び出し元のUAは確認済みダイアログまたは早期ダイアログのいずれかでBYEを送信できます。また、呼び出し先のUAは確認済みダイアログでBYEを送信してもかまいませんが、早期ダイアログでBYEを送信してはなりません。
However, the callee's UA MUST NOT send a BYE on a confirmed dialog until it has received an ACK for its 2xx response or until the server transaction times out. If no SIP extensions have defined other application layer states associated with the dialog, the BYE also terminates the dialog.
ただし、呼び出し先のUAは、2xx応答のACKを受信するまで、またはサーバートランザクションがタイムアウトするまで、確認済みダイアログでBYEを送信してはなりません（MUST NOT）。ダイアログに関連付けられている他のアプリケーション層の状態がSIP拡張機能で定義されていない場合、BYEもダイアログを終了します。
The impact of a non-2xx final response to INVITE on dialogs and sessions makes the use of CANCEL attractive. The CANCEL attempts to force a non-2xx response to the INVITE (in particular, a 487). Therefore, if a UAC wishes to give up on its call attempt entirely, it can send a CANCEL. If the INVITE results in 2xx final response(s) to the INVITE, this means that a UAS accepted the invitation while the CANCEL was in progress. The UAC MAY continue with the sessions established by any 2xx responses, or MAY terminate them with BYE.
INVITEに対する2xx以外の最終応答がダイアログとセッションに与える影響により、CANCELの使用が魅力的になります。 CANCELは、INVITEへの2xx以外の応答（特に487）を強制しようとします。したがって、UACが呼び出しの試行を完全に中止したい場合、UACはCANCELを送信できます。 INVITEがINVITEに対する2xx最終応答をもたらす場合、これは、キャンセルが進行中にUASが招待を受け入れたことを意味します。 UACは、2xx応答によって確立されたセッションを続行するか、またはBYEでセッションを終了してもよい（MAY）。
The notion of "hanging up" is not well defined within SIP. It is specific to a particular, albeit common, user interface. Typically, when the user hangs up, it indicates a desire to terminate the attempt to establish a session, and to terminate any sessions already created. For the caller's UA, this would imply a CANCEL request if the initial INVITE has not generated a final response, and a BYE to all confirmed dialogs after a final response. For the callee's UA, it would typically imply a BYE; presumably, when the user picked up the phone, a 2xx was generated, and so hanging up would result in a BYE after the ACK is received. This does not mean a user cannot hang up before receipt of the ACK, it just means that the software in his phone needs to maintain state for a short while in order to clean up properly. If the particular UI allows for the user to reject a call before its answered, a 403 (Forbidden) is a good way to express that. As per the rules above, a BYE can't be sent.
「電話を切る」という概念は、SIP内では十分に定義されていません。これは、一般的ではありますが、特定のユーザーインターフェイスに固有です。通常、ユーザーが電話を切ると、セッションを確立する試みを終了し、すでに作成されているセッションを終了したいという希望を示します。呼び出し元のUAの場合、これは、最初のINVITEが最終応答を生成していない場合はCANCEL要求を意味し、最終応答の後に確認されたすべてのダイアログに対してBYEを意味します。呼び出し先のUAの場合、通常はBYEを意味します。おそらく、ユーザーが電話に出たときに2xxが生成されたため、ハングアップするとACKを受信した後にBYEが発生しました。これは、ユーザーがACKを受信する前に電話を切ることができないことを意味するのではなく、適切にクリーンアップするために、電話機のソフトウェアがしばらくの間状態を維持する必要があることを意味します。特定のUIでユーザーが応答する前に通話を拒否できる場合、403（禁止）はそれを表現する良い方法です。上記のルールに従って、BYEは送信できません。
A BYE request is constructed as would any other request within a dialog, as described in Section 12.
BYEリクエストは、セクション12で説明されているように、ダイアログ内の他のリクエストと同様に作成されます。
Once the BYE is constructed, the UAC core creates a new non-INVITE client transaction, and passes it the BYE request. The UAC MUST consider the session terminated (and therefore stop sending or listening for media) as soon as the BYE request is passed to the client transaction. If the response for the BYE is a 481 (Call/Transaction Does Not Exist) or a 408 (Request Timeout) or no response at all is received for the BYE (that is, a timeout is returned by the client transaction), the UAC MUST consider the session and the dialog terminated.
BYEが構築されると、UACコアは新しい非INVITEクライアントトランザクションを作成し、BYEリクエストに渡します。 BYE要求がクライアントトランザクションに渡されるとすぐに、UACはセッションが終了したと見なす（したがって、メディアの送信またはリスニングを停止する）必要があります。 BYEの応答が481（コール/トランザクションが存在しない）または408（リクエストタイムアウト）であるか、BYEに対する応答がまったく受信されない（つまり、クライアントトランザクションによってタイムアウトが返される）場合、UACセッションとダイアログが終了したことを考慮しなければなりません。
A UAS first processes the BYE request according to the general UAS processing described in Section 8.2. A UAS core receiving a BYE request checks if it matches an existing dialog. If the BYE does not match an existing dialog, the UAS core SHOULD generate a 481 (Call/Transaction Does Not Exist) response and pass that to the server transaction.
UASは最初に、セクション8.2で説明されている一般的なUAS処理に従ってBYE要求を処理します。 BYEリクエストを受信したUASコアは、既存のダイアログと一致するかどうかをチェックします。 BYEが既存のダイアログと一致しない場合、UASコアは481（呼び出し/トランザクションが存在しない）応答を生成してサーバートランザクションに渡す必要があります（SHOULD）。
This rule means that a BYE sent without tags by a UAC will be rejected. This is a change from RFC 2543, which allowed BYE without tags.
このルールは、UACによってタグなしで送信されたBYEが拒否されることを意味します。これは、タグなしのBYEを許可したRFC 2543からの変更点です。
A UAS core receiving a BYE request for an existing dialog MUST follow the procedures of Section 12.2.2 to process the request. Once done, the UAS SHOULD terminate the session (and therefore stop sending and listening for media). The only case where it can elect not to are multicast sessions, where participation is possible even if the other participant in the dialog has terminated its involvement in the session. Whether or not it ends its participation on the session, the UAS core MUST generate a 2xx response to the BYE, and MUST pass that to the server transaction for transmission.
既存のダイアログのBYEリクエストを受信するUASコアは、セクション12.2.2の手順に従ってリクエストを処理する必要があります。完了すると、UASはセッションを終了する必要があります（したがって、メディアの送信とリッスンを停止します）。マルチキャストセッションではないことを選択できる唯一のケースは、ダイアログの他の参加者がセッションへの関与を終了した場合でも参加が可能な場合です。セッションへの参加を終了するかどうかにかかわらず、UASコアはBYEへの2xx応答を生成しなければならず、送信のためにそれをサーバートランザクションに渡さなければなりません（MUST）。
The UAS MUST still respond to any pending requests received for that dialog. It is RECOMMENDED that a 487 (Request Terminated) response be generated to those pending requests.
UASは引き続き、そのダイアログに対して受信された保留中の要求に応答する必要があります。これらの保留中の要求に対して487（要求終了）応答を生成することをお勧めします。
16 Proxy Behavior
16プロキシの動作
SIP proxies are elements that route SIP requests to user agent servers and SIP responses to user agent clients. A request may traverse several proxies on its way to a UAS. Each will make routing decisions, modifying the request before forwarding it to the next element. Responses will route through the same set of proxies traversed by the request in the reverse order.
SIPプロキシは、SIP要求をユーザーエージェントサーバーにルーティングし、SIP応答をユーザーエージェントクライアントにルーティングする要素です。リクエストは、UASに向かう途中でいくつかのプロキシを通過する場合があります。それぞれがルーティングの決定を行い、次の要素に転送する前にリクエストを変更します。応答は、要求によって逆の順序でトラバースされる同じプロキシのセットを介してルーティングされます。
Being a proxy is a logical role for a SIP element. When a request arrives, an element that can play the role of a proxy first decides if it needs to respond to the request on its own. For instance, the request may be malformed or the element may need credentials from the client before acting as a proxy. The element MAY respond with any appropriate error code. When responding directly to a request, the element is playing the role of a UAS and MUST behave as described in Section 8.2.
プロキシであることは、SIP要素の論理的な役割です。リクエストが到着すると、プロキシの役割を果たすことができる要素は、それ自体でリクエストに応答する必要があるかどうかを最初に決定します。たとえば、リクエストの形式が正しくない場合や、要素がプロキシとして機能する前にクライアントからの認証情報を必要とする場合があります。要素は適切なエラーコードで応答してもよい（MAY）。リクエストに直接応答する場合、要素はUASの役割を果たし、セクション8.2で説明されているように動作する必要があります。
A proxy can operate in either a stateful or stateless mode for each new request. When stateless, a proxy acts as a simple forwarding element. It forwards each request downstream to a single element determined by making a targeting and routing decision based on the request. It simply forwards every response it receives upstream. A stateless proxy discards information about a message once the message has been forwarded. A stateful proxy remembers information (specifically, transaction state) about each incoming request and any requests it sends as a result of processing the incoming request. It uses this information to affect the processing of future messages associated with that request. A stateful proxy MAY choose to "fork" a request, routing it to multiple destinations. Any request that is forwarded to more than one location MUST be handled statefully.
プロキシは、新しいリクエストごとにステートフルモードまたはステートレスモードで動作できます。ステートレスの場合、プロキシは単純な転送要素として機能します。各要求をダウンストリームに転送し、要求に基づいてターゲティングとルーティングの決定を行うことによって決定された単一の要素に転送します。上流で受け取ったすべての応答を転送するだけです。ステートレスプロキシは、メッセージが転送されると、メッセージに関する情報を破棄します。ステートフルプロキシは、各着信要求と、着信要求の処理の結果として送信されるすべての要求に関する情報（特にトランザクション状態）を記憶しています。この情報を使用して、その要求に関連付けられた今後のメッセージの処理に影響を与えます。ステートフルプロキシは、リクエストを「フォーク」して複数の宛先にルーティングすることを選択できます。複数の場所に転送される要求は、ステートフルに処理する必要があります。
In some circumstances, a proxy MAY forward requests using stateful transports (such as TCP) without being transaction-stateful. For instance, a proxy MAY forward a request from one TCP connection to another transaction statelessly as long as it places enough information in the message to be able to forward the response down the same connection the request arrived on. Requests forwarded between different types of transports where the proxy's TU must take an active role in ensuring reliable delivery on one of the transports MUST be forwarded transaction statefully.
状況によっては、プロキシはトランザクションステートフルではなく、ステートフルトランスポート（TCPなど）を使用してリクエストを転送できます（MAY）。たとえば、プロキシは、リクエストが到着した同じ接続を介して応答を転送できる十分な情報をメッセージに配置する限り、1つのTCP接続から別のトランザクションにリクエストをステートレスに転送できます。プロキシのTUがトランスポートの1つで信頼性の高い配信を保証するためにアクティブな役割を担う必要がある、異なるタイプのトランスポート間で転送される要求は、トランザクションをステートフルに転送する必要があります。
A stateful proxy MAY transition to stateless operation at any time during the processing of a request, so long as it did not do anything that would otherwise prevent it from being stateless initially (forking, for example, or generation of a 100 response). When performing such a transition, all state is simply discarded. The proxy SHOULD NOT initiate a CANCEL request.
ステートフルプロキシは、リクエストの処理中にいつでもステートレスオペレーションに移行する場合がありますが、それ以外の場合は最初にステートレスになるのを妨げるようなことは何もしません（たとえば、フォーキング、または100応答の生成）。このような遷移を実行すると、すべての状態が単に破棄されます。プロキシはCANCELリクエストを開始してはいけません。
Much of the processing involved when acting statelessly or statefully for a request is identical. The next several subsections are written from the point of view of a stateful proxy. The last section calls out those places where a stateless proxy behaves differently.
リクエストに対してステートレスまたはステートフルに動作する場合に必要な処理の多くは同じです。次のいくつかのサブセクションは、ステートフルプロキシの観点から書かれています。最後のセクションでは、ステートレスプロキシの動作が異なる場所について説明します。
When stateful, a proxy is purely a SIP transaction processing engine. Its behavior is modeled here in terms of the server and client transactions defined in Section 17. A stateful proxy has a server transaction associated with one or more client transactions by a higher layer proxy processing component (see figure 3), known as a proxy core. An incoming request is processed by a server transaction. Requests from the server transaction are passed to a proxy core. The proxy core determines where to route the request, choosing one or more next-hop locations. An outgoing request for each next-hop location is processed by its own associated client transaction. The proxy core collects the responses from the client transactions and uses them to send responses to the server transaction.
ステートフルの場合、プロキシは純粋にSIPトランザクション処理エンジンです。その動作は、セクション17で定義されたサーバーおよびクライアントトランザクションに関してここでモデル化されます。ステートフルプロキシには、プロキシコアと呼ばれる上位層のプロキシ処理コンポーネント（図3を参照）によって1つ以上のクライアントトランザクションに関連付けられたサーバートランザクションがあります。 。着信要求はサーバートランザクションによって処理されます。サーバートランザクションからの要求は、プロキシコアに渡されます。プロキシコアは、1つ以上のネクストホップの場所を選択して、要求をルーティングする場所を決定します。各ネクストホップロケーションの発信要求は、関連付けられた独自のクライアントトランザクションによって処理されます。プロキシコアは、クライアントトランザクションからの応答を収集し、それらを使用してサーバートランザクションに応答を送信します。
A stateful proxy creates a new server transaction for each new request received. Any retransmissions of the request will then be handled by that server transaction per Section 17. The proxy core MUST behave as a UAS with respect to sending an immediate provisional on that server transaction (such as 100 Trying) as described in Section 8.2.6. Thus, a stateful proxy SHOULD NOT generate 100 (Trying) responses to non-INVITE requests.
ステートフルプロキシは、新しいリクエストを受信するたびに新しいサーバートランザクションを作成します。リクエストの再送信は、セクション17に従ってそのサーバートランザクションによって処理されます。プロキシコアは、セクション8.2.6で説明されているように、そのサーバートランザクション（100 Tryingなど）の即時暫定的な送信に関してUASとして動作する必要があります。したがって、ステートフルプロキシは、非INVITEリクエストに対して100（試行中）の応答を生成するべきではありません（SHOULD NOT）。
This is a model of proxy behavior, not of software. An implementation is free to take any approach that replicates the external behavior this model defines.
これは、ソフトウェアのモデルではなく、プロキシの動作のモデルです。実装は、このモデルが定義する外部の動作を複製するアプローチを自由にとることができます。
For all new requests, including any with unknown methods, an element intending to proxy the request MUST:
未知のメソッドを含むすべての新しいリクエストについて、リクエストをプロキシすることを意図する要素は、
1. Validate the request (Section 16.3)
1. リクエストを検証する（セクション16.3）
2. Preprocess routing information (Section 16.4)
2. ルーティング情報の前処理（セクション16.4）
3. Determine target(s) for the request (Section 16.5)
3. リクエストのターゲットを決定する（セクション16.5）
+--------------------+
| | +---+
| | | C |
| | | T |
| | +---+
+---+ | Proxy | +---+ CT = Client Transaction
| S | | "Higher" Layer | | C |
| T | | | | T | ST = Server Transaction
+---+ | | +---+
| | +---+
| | | C |
| | | T |
| | +---+
+--------------------+
Figure 3: Stateful Proxy Model
図3：ステートフルプロキシモデル
4. Forward the request to each target (Section 16.6)
4. リクエストを各ターゲットに転送する（セクション16.6）
5. Process all responses (Section 16.7)
5. すべての応答を処理する（セクション16.7）
Before an element can proxy a request, it MUST verify the message's validity. A valid message must pass the following checks:
要素がリクエストをプロキシする前に、メッセージの有効性を検証する必要があります。有効なメッセージは、次のチェックに合格する必要があります。
1. Reasonable Syntax
1. 合理的な構文
2. URI scheme
2. URIスキーム
3. Max-Forwards
3. マックスフォワード
4. (Optional) Loop Detection
4. （オプション）ループ検出
5. Proxy-Require
5. プロキシが必要
6. Proxy-Authorization
6. プロキシ承認
If any of these checks fail, the element MUST behave as a user agent server (see Section 8.2) and respond with an error code.
これらのチェックのいずれかが失敗した場合、要素はユーザーエージェントサーバーとして動作し（セクション8.2を参照）、エラーコードで応答する必要があります。
Notice that a proxy is not required to detect merged requests and MUST NOT treat merged requests as an error condition. The endpoints receiving the requests will resolve the merge as described in Section 8.2.2.2.
マージされたリクエストを検出するためにプロキシは必要なく、マージされたリクエストをエラー状態として扱ってはならないことに注意してください。リクエストを受信したエンドポイントは、セクション8.2.2.2で説明されているようにマージを解決します。
1. Reasonable syntax check
1. 合理的な構文チェック
The request MUST be well-formed enough to be handled with a server transaction. Any components involved in the remainder of these Request Validation steps or the Request Forwarding section MUST be well-formed. Any other components, well-formed or not, SHOULD be ignored and remain unchanged when the message is forwarded. For instance, an element would not reject a request because of a malformed Date header field. Likewise, a proxy would not remove a malformed Date header field before forwarding a request.
リクエストは、サーバートランザクションで処理されるのに十分な形式である必要があります。これらのリクエスト検証手順の残りまたはリクエスト転送セクションに関与するコンポーネントは、整形式でなければなりません。整形式であろうとなかろうと、他のコンポーネントは無視されるべきであり、メッセージが転送されるときは変更されずに残ります。たとえば、Dateヘッダーフィールドの形式が正しくないため、要素はリクエストを拒否しません。同様に、プロキシはリクエストを転送する前に不正な日付ヘッダーフィールドを削除しません。
This protocol is designed to be extended. Future extensions may define new methods and header fields at any time. An element MUST NOT refuse to proxy a request because it contains a method or header field it does not know about.
このプロトコルは拡張されるように設計されています。将来の拡張機能では、いつでも新しいメソッドとヘッダーフィールドを定義する可能性があります。要素は、知らないメソッドまたはヘッダーフィールドを含んでいるため、要求のプロキシを拒否してはなりません（MUST NOT）。
2. URI scheme check
2. URIスキームチェック
If the Request-URI has a URI whose scheme is not understood by the proxy, the proxy SHOULD reject the request with a 416 (Unsupported URI Scheme) response.
Request-URIにスキームがプロキシで理解されていないURIがある場合、プロキシは416（サポートされていないURIスキーム）応答で要求を拒否する必要があります（SHOULD）。
3. Max-Forwards check
3. Max-Forwardsチェック
The Max-Forwards header field (Section 20.22) is used to limit the number of elements a SIP request can traverse.
Max-Forwardsヘッダーフィールド（セクション20.22）は、SIPリクエストが通過できる要素の数を制限するために使用されます。
If the request does not contain a Max-Forwards header field, this check is passed.
リクエストにMax-Forwardsヘッダーフィールドが含まれていない場合、このチェックはパスします。
If the request contains a Max-Forwards header field with a field value greater than zero, the check is passed.
リクエストに、ゼロより大きいフィールド値を持つMax-Forwardsヘッダーフィールドが含まれている場合、チェックは成功します。
If the request contains a Max-Forwards header field with a field value of zero (0), the element MUST NOT forward the request. If the request was for OPTIONS, the element MAY act as the final recipient and respond per Section 11. Otherwise, the element MUST return a 483 (Too many hops) response.
リクエストにゼロ（0）のフィールド値を持つMax-Forwardsヘッダーフィールドが含まれている場合、要素はリクエストを転送してはなりません（MUST NOT）。要求がOPTIONSに対するものであった場合、要素は最終受信者として機能し、セクション11に従って応答する場合があります。それ以外の場合、要素は483（ホップが多すぎる）応答を返す必要があります。
4. Optional Loop Detection check
4. オプションのループ検出チェック
An element MAY check for forwarding loops before forwarding a request. If the request contains a Via header field with a sent-by value that equals a value placed into previous requests by the proxy, the request has been forwarded by this element before. The request has either looped or is legitimately spiraling through the element. To determine if the request has looped, the element MAY perform the branch parameter calculation described in Step 8 of Section 16.6 on this message and compare it to the parameter received in that Via header field. If the parameters match, the request has looped. If they differ, the request is spiraling, and processing continues. If a loop is detected, the element MAY return a 482 (Loop Detected) response.
要素はリクエストを転送する前に転送ループをチェックしてもよい（MAY）。リクエストに、プロキシによって以前のリクエストに配置された値と等しい送信元の値を持つViaヘッダーフィールドが含まれている場合、リクエストはこの要素によって以前に転送されています。リクエストはループしているか、要素を介して合法的にスパイラルしています。リクエストがループしたかどうかを判断するために、要素はこのメッセージに対してセクション16.6のステップ8で説明されている分岐パラメーター計算を実行し、そのViaヘッダーフィールドで受信したパラメーターと比較する場合があります。パラメータが一致する場合、リクエストはループしています。それらが異なる場合、要求は急上昇しており、処理は続行されます。ループが検出された場合、要素は482（ループ検出）応答を返す場合があります。
5. Proxy-Require check
5. プロキシが必要なチェック
Future extensions to this protocol may introduce features that require special handling by proxies. Endpoints will include a Proxy-Require header field in requests that use these features, telling the proxy not to process the request unless the feature is understood.
このプロトコルの将来の拡張では、プロキシによる特別な処理を必要とする機能が導入される可能性があります。エンドポイントは、これらの機能を使用するリクエストにProxy-Requireヘッダーフィールドを含め、機能が理解されない限りリクエストを処理しないようプロキシに指示します。
If the request contains a Proxy-Require header field (Section 20.29) with one or more option-tags this element does not understand, the element MUST return a 420 (Bad Extension) response. The response MUST include an Unsupported (Section 20.40) header field listing those option-tags the element did not understand.
リクエストにProxy-Requireヘッダーフィールド（セクション20.29）が含まれ、この要素が理解できないオプションタグが1つ以上ある場合、要素は420（Bad Extension）応答を返す必要があります。応答には、要素が理解できなかったオプションタグをリストするUnsupported（セクション20.40）ヘッダーフィールドを含める必要があります。
6. Proxy-Authorization check
6. プロキシ承認チェック
If an element requires credentials before forwarding a request, the request MUST be inspected as described in Section 22.3. That section also defines what the element must do if the inspection fails.
要素がリクエストを転送する前に資格情報を必要とする場合、セクション22.3で説明されているようにリクエストを検査する必要があります。そのセクションでは、検査が失敗した場合に要素が実行する必要があることも定義します。
The proxy MUST inspect the Request-URI of the request. If the Request-URI of the request contains a value this proxy previously placed into a Record-Route header field (see Section 16.6 item 4), the proxy MUST replace the Request-URI in the request with the last value from the Route header field, and remove that value from the Route header field. The proxy MUST then proceed as if it received this modified request.
プロキシは、リクエストのRequest-URIを検査する必要があります。リクエストのRequest-URIにこのプロキシが以前にRecord-Routeヘッダーフィールドに配置された値が含まれている場合（セクション16.6の項目4を参照）、プロキシはリクエスト内のRequest-URIをRouteヘッダーフィールドの最後の値で置き換えなければなりません（MUST）。 、その値をルートヘッダーフィールドから削除します。プロキシは、この変更されたリクエストを受信したかのように処理を続行する必要があります。
This will only happen when the element sending the request to the proxy (which may have been an endpoint) is a strict router. This rewrite on receive is necessary to enable backwards compatibility with those elements. It also allows elements following this specification to preserve the Request-URI through strict-routing proxies (see Section 12.2.1.1).
これは、リクエストをプロキシ（エンドポイントである可能性がある）に送信する要素が厳密なルーターである場合にのみ発生します。これらの要素との下位互換性を有効にするには、受信時のこの書き換えが必要です。また、この仕様に準拠する要素は、厳密なルーティングプロキシを介してRequest-URIを保持できます（セクション12.2.1.1を参照）。
This requirement does not obligate a proxy to keep state in order to detect URIs it previously placed in Record-Route header fields. Instead, a proxy need only place enough information in those URIs to recognize them as values it provided when they later appear.
この要件は、以前にRecord-Routeヘッダーフィールドに配置されたURIを検出するために、プロキシに状態を維持することを義務付けません。代わりに、プロキシは、それらが後で表示されるときに提供された値としてそれらを認識するのに十分な情報をそれらのURIに配置するだけで済みます。
If the Request-URI contains a maddr parameter, the proxy MUST check to see if its value is in the set of addresses or domains the proxy is configured to be responsible for. If the Request-URI has a maddr parameter with a value the proxy is responsible for, and the request was received using the port and transport indicated (explicitly or by default) in the Request-URI, the proxy MUST strip the maddr and any non-default port or transport parameter and continue processing as if those values had not been present in the request.
Request-URIにmaddrパラメータが含まれている場合、プロキシは、その値がプロキシが責任を持つように構成されているアドレスまたはドメインのセットにあるかどうかを確認する必要があります。リクエストURIに、プロキシが担当する値を持つmaddrパラメータがあり、リクエストがリクエストURIで（明示的またはデフォルトで）指定されたポートとトランスポートを使用して受信された場合、プロキシはmaddrと非-defaultポートまたはトランスポートパラメーター。これらの値がリクエストに存在しないかのように処理を続行します。
A request may arrive with a maddr matching the proxy, but on a port or transport different from that indicated in the URI. Such a request needs to be forwarded to the proxy using the indicated port and transport.
リクエストは、プロキシと一致するmaddrで到着する可能性がありますが、URIに示されているものとは異なるポートまたはトランスポートに到着します。このような要求は、示されたポートとトランスポートを使用してプロキシに転送する必要があります。
If the first value in the Route header field indicates this proxy, the proxy MUST remove that value from the request.
Routeヘッダーフィールドの最初の値がこのプロキシを示す場合、プロキシは要求からその値を削除する必要があります。
Next, the proxy calculates the target(s) of the request. The set of targets will either be predetermined by the contents of the request or will be obtained from an abstract location service. Each target in the set is represented as a URI.
次に、プロキシはリクエストのターゲットを計算します。ターゲットのセットは、リクエストの内容によって事前に決定されるか、抽象的な位置情報サービスから取得されます。セット内の各ターゲットは、URIとして表されます。
If the Request-URI of the request contains an maddr parameter, the Request-URI MUST be placed into the target set as the only target URI, and the proxy MUST proceed to Section 16.6.
リクエストのRequest-URIにmaddrパラメータが含まれている場合、Request-URIを唯一のターゲットURIとしてターゲットセットに配置する必要があり、プロキシはセクション16.6に進む必要があります。
If the domain of the Request-URI indicates a domain this element is not responsible for, the Request-URI MUST be placed into the target set as the only target, and the element MUST proceed to the task of Request Forwarding (Section 16.6).
Request-URIのドメインがこの要素が担当しないドメインを示す場合、Request-URIを唯一のターゲットとしてターゲットセットに配置する必要があり、要素はリクエスト転送（セクション16.6）のタスクに進む必要があります。
There are many circumstances in which a proxy might receive a request for a domain it is not responsible for. A firewall proxy handling outgoing calls (the way HTTP proxies handle outgoing requests) is an example of where this is likely to occur.
プロキシが担当していないドメインのリクエストを受け取る可能性のある状況は数多くあります。発信呼び出しを処理するファイアウォールプロキシ（HTTPプロキシが発信要求を処理する方法）は、これが発生する可能性が高い例です。
If the target set for the request has not been predetermined as described above, this implies that the element is responsible for the domain in the Request-URI, and the element MAY use whatever mechanism it desires to determine where to send the request. Any of these mechanisms can be modeled as accessing an abstract Location Service. This may consist of obtaining information from a location service created by a SIP Registrar, reading a database, consulting a presence server, utilizing other protocols, or simply performing an algorithmic substitution on the Request-URI. When accessing the location service constructed by a registrar, the Request-URI MUST first be canonicalized as described in Section 10.3 before being used as an index. The output of these mechanisms is used to construct the target set.
上記のようにリクエストのターゲットセットが事前に決定されていない場合、これは要素がRequest-URIのドメインを担当することを意味し、要素は、リクエストの送信先を決定するために必要なメカニズムを使用できます（MAY）。これらのメカニズムはいずれも、抽象ロケーションサービスへのアクセスとしてモデル化できます。これは、SIPレジストラーによって作成されたロケーションサービスから情報を取得する、データベースを読み取る、プレゼンスサーバーに問い合わせる、他のプロトコルを利用する、または単にRequest-URIでアルゴリズム置換を実行することで構成されます。レジストラによって構築された位置情報サービスにアクセスするとき、Request-URIは、インデックスとして使用される前に、セクション10.3で説明されているように最初に正規化されなければなりません（MUST）。これらのメカニズムの出力は、ターゲットセットを構築するために使用されます。
If the Request-URI does not provide sufficient information for the proxy to determine the target set, it SHOULD return a 485 (Ambiguous) response. This response SHOULD contain a Contact header field containing URIs of new addresses to be tried. For example, an INVITE to sip:John.Smith@company.com may be ambiguous at a proxy whose location service has multiple John Smiths listed. See Section 21.4.23 for details.
Request-URIがプロキシがターゲットセットを決定するのに十分な情報を提供しない場合、485（あいまい）応答を返す必要があります（SHOULD）。この応答には、試行する新しいアドレスのURIを含むContactヘッダーフィールドを含める必要があります（SHOULD）。たとえば、sip：John.Smith@company.comへのINVITEは、ロケーションサービスに複数のJohn Smithがリストされているプロキシではあいまいになる場合があります。詳細は項21.4.23を参照してください。
Any information in or about the request or the current environment of the element MAY be used in the construction of the target set. For instance, different sets may be constructed depending on contents or the presence of header fields and bodies, the time of day of the request's arrival, the interface on which the request arrived, failure of previous requests, or even the element's current level of utilization.
要素内のリクエストまたは現在の環境に関する情報またはそのすべてに関する情報は、ターゲットセットの構築に使用される場合があります。たとえば、コンテンツまたはヘッダーフィールドと本文の存在、リクエストの到着時刻、リクエストが到着したインターフェース、以前のリクエストの失敗、または要素の現在の利用率に応じて、異なるセットが構築される場合があります。 。
As potential targets are located through these services, their URIs are added to the target set. Targets can only be placed in the target set once. If a target URI is already present in the set (based on the definition of equality for the URI type), it MUST NOT be added again.
潜在的なターゲットがこれらのサービスを通じて見つけられると、それらのURIがターゲットセットに追加されます。ターゲットは、ターゲットセットに1回だけ配置できます。 （URIタイプの等価性の定義に基づいて）ターゲットURIがセットにすでに存在する場合は、再度追加してはなりません。
A proxy MUST NOT add additional targets to the target set if the Request-URI of the original request does not indicate a resource this proxy is responsible for.
元のリクエストのRequest-URIがこのプロキシが担当するリソースを示さない場合、プロキシはターゲットセットに追加のターゲットを追加してはなりません（MUST NOT）。
A proxy can only change the Request-URI of a request during forwarding if it is responsible for that URI. If the proxy is not responsible for that URI, it will not recurse on 3xx or 416 responses as described below.
プロキシは、転送中にリクエストのRequest-URIを変更できるのは、そのURIを担当している場合のみです。プロキシがそのURIの責任を負わない場合、以下で説明するように、3xxまたは416応答で再帰しません。
If the Request-URI of the original request indicates a resource this proxy is responsible for, the proxy MAY continue to add targets to the set after beginning Request Forwarding. It MAY use any information obtained during that processing to determine new targets. For instance, a proxy may choose to incorporate contacts obtained in a redirect response (3xx) into the target set. If a proxy uses a dynamic source of information while building the target set (for instance, if it consults a SIP Registrar), it SHOULD monitor that source for the duration of processing the request. New locations SHOULD be added to the target set as they become available. As above, any given URI MUST NOT be added to the set more than once.
元のリクエストのリクエストURIがこのプロキシが担当するリソースを示している場合、プロキシはリクエスト転送を開始した後、セットにターゲットを追加し続けることができます（MAY）。その処理中に取得した情報を使用して、新しいターゲットを決定する場合があります。たとえば、プロキシはリダイレクト応答（3xx）で取得した連絡先をターゲットセットに組み込むことを選択できます。プロキシがターゲットセットの構築中に動的な情報ソースを使用する場合（たとえば、SIPレジストラーに問い合わせる場合）、リクエストの処理中、そのソースを監視する必要があります（SHOULD）。新しい場所は、利用可能になったときにターゲットセットに追加する必要があります。上記のように、特定のURIをセットに複数回追加してはなりません（MUST NOT）。
Allowing a URI to be added to the set only once reduces unnecessary network traffic, and in the case of incorporating contacts from redirect requests prevents infinite recursion.
URIをセットに1回だけ追加できるようにすることで、不要なネットワークトラフィックが削減され、リダイレクト要求からの連絡先を組み込む場合に、無限再帰が防止されます。
For example, a trivial location service is a "no-op", where the target URI is equal to the incoming request URI. The request is sent to a specific next hop proxy for further processing. During request forwarding of Section 16.6, Item 6, the identity of that next hop, expressed as a SIP or SIPS URI, is inserted as the top-most Route header field value into the request.
たとえば、トリビアルロケーションサービスは「no-op」であり、ターゲットURIは着信リクエストURIと同じです。要求は、さらに処理するために特定のネクストホッププロキシに送信されます。セクション16.6、項目6の要求転送中に、SIPまたはSIPS URIとして表されるそのネクストホップのIDが、最上位のルートヘッダーフィールド値として要求に挿入されます。
If the Request-URI indicates a resource at this proxy that does not exist, the proxy MUST return a 404 (Not Found) response.
Request-URIがこのプロキシに存在しないリソースを示している場合、プロキシは404（Not Found）応答を返さなければなりません（MUST）。
If the target set remains empty after applying all of the above, the proxy MUST return an error response, which SHOULD be the 480 (Temporarily Unavailable) response.
上記のすべてを適用した後、ターゲットセットが空のままである場合、プロキシはエラー応答を返さなければなりません（MUST）。これは480（一時的に利用不可）の応答である必要があります（SHOULD）。
As soon as the target set is non-empty, a proxy MAY begin forwarding the request. A stateful proxy MAY process the set in any order. It MAY process multiple targets serially, allowing each client transaction to complete before starting the next. It MAY start client transactions with every target in parallel. It also MAY arbitrarily divide the set into groups, processing the groups serially and processing the targets in each group in parallel.
ターゲットセットが空でないとすぐに、プロキシはリクエストの転送を開始する場合があります。ステートフルプロキシは、任意の順序でセットを処理できます（MAY）。複数のターゲットを連続的に処理して、各クライアントトランザクションが次のトランザクションを開始する前に完了することを許可する場合があります。すべてのターゲットでクライアントトランザクションを並行して開始する場合があります。また、セットを任意にグループに分割し、グループを順次処理し、各グループのターゲットを並行して処理する場合があります。
A common ordering mechanism is to use the qvalue parameter of targets obtained from Contact header fields (see Section 20.10). Targets are processed from highest qvalue to lowest. Targets with equal qvalues may be processed in parallel.
一般的な順序付けメカニズムは、Contactヘッダーフィールドから取得したターゲットのqvalueパラメータを使用することです（20.10項を参照）。ターゲットは、最高のqvalueから最低の順に処理されます。等しいqvalueを持つターゲットは、並行して処理できます。
A stateful proxy must have a mechanism to maintain the target set as responses are received and associate the responses to each forwarded request with the original request. For the purposes of this model, this mechanism is a "response context" created by the proxy layer before forwarding the first request.
ステートフルプロキシには、応答を受信したときにターゲットセットを維持し、転送された各要求への応答を元の要求に関連付けるメカニズムが必要です。このモデルでは、このメカニズムは、最初の要求を転送する前にプロキシレイヤーによって作成される「応答コンテキスト」です。
For each target, the proxy forwards the request following these steps:
ターゲットごとに、プロキシは次の手順に従って要求を転送します。
1. Make a copy of the received request
1. 受信したリクエストのコピーを作成します
2. Update the Request-URI
2. リクエストURIを更新する
3. Update the Max-Forwards header field
3. Max-Forwardsヘッダーフィールドを更新する
4. Optionally add a Record-route header field value
4. オプションでRecord-routeヘッダーフィールド値を追加する
5. Optionally add additional header fields
5. オプションで追加のヘッダーフィールドを追加する
6. Postprocess routing information
6. ポストプロセスルーティング情報
7. Determine the next-hop address, port, and transport 8. Add a Via header field value
7. ネクストホップアドレス、ポート、およびトランスポートを決定します8. Viaヘッダーフィールド値を追加します
9. Add a Content-Length header field if necessary
9. 必要に応じてContent-Lengthヘッダーフィールドを追加する
10. Forward the new request
10. 新しいリクエストを転送する
11. Set timer C
11. タイマーCを設定
Each of these steps is detailed below:
これらの各ステップの詳細は以下のとおりです。
1. Copy request
1. コピーリクエスト
The proxy starts with a copy of the received request. The copy MUST initially contain all of the header fields from the received request. Fields not detailed in the processing described below MUST NOT be removed. The copy SHOULD maintain the ordering of the header fields as in the received request. The proxy MUST NOT reorder field values with a common field name (See Section 7.3.1). The proxy MUST NOT add to, modify, or remove the message body.
プロキシは、受信したリクエストのコピーから始まります。コピーには、最初に、受信した要求からのすべてのヘッダーフィールドが含まれている必要があります。下記の処理で詳述されていないフィールドは削除してはなりません。コピーは、受信したリクエストのようにヘッダーフィールドの順序を維持する必要があります（SHOULD）。プロキシは、フィールド値を共通のフィールド名で並べ替えてはなりません（セクション7.3.1を参照）。プロキシは、メッセージ本文を追加、変更、または削除してはなりません（MUST NOT）。
An actual implementation need not perform a copy; the primary requirement is that the processing for each next hop begin with the same request.
実際の実装では、コピーを実行する必要はありません。主な要件は、各次ホップの処理が同じ要求で始まることです。
2. Request-URI
2. リクエストURI
The Request-URI in the copy's start line MUST be replaced with the URI for this target. If the URI contains any parameters not allowed in a Request-URI, they MUST be removed.
コピーの開始行のRequest-URIは、このターゲットのURIに置き換える必要があります。 URIにRequest-URIで許可されていないパラメーターが含まれている場合は、それらを削除する必要があります。
This is the essence of a proxy's role. This is the mechanism through which a proxy routes a request toward its destination.
これがプロキシの役割の本質です。これは、プロキシがリクエストを宛先にルーティングするメカニズムです。
In some circumstances, the received Request-URI is placed into the target set without being modified. For that target, the replacement above is effectively a no-op.
状況によっては、受信したRequest-URIが変更されることなくターゲットセットに配置されます。そのターゲットの場合、上記の置換は事実上何もしません。
3. Max-Forwards
3. マックスフォワード
If the copy contains a Max-Forwards header field, the proxy MUST decrement its value by one (1).
コピーにMax-Forwardsヘッダーフィールドが含まれている場合、プロキシはその値を1だけ減らす必要があります。
If the copy does not contain a Max-Forwards header field, the proxy MUST add one with a field value, which SHOULD be 70.
コピーにMax-Forwardsヘッダーフィールドが含まれていない場合、プロキシはフィールド値を1つ追加する必要があります。これは70にする必要があります（SHOULD）。
Some existing UAs will not provide a Max-Forwards header field in a request.
一部の既存のUAは、リクエストにMax-Forwardsヘッダーフィールドを提供しません。
4. Record-Route
4. レコード経路
If this proxy wishes to remain on the path of future requests in a dialog created by this request (assuming the request creates a dialog), it MUST insert a Record-Route header field value into the copy before any existing Record-Route header field values, even if a Route header field is already present.
このプロキシが、このリクエストによって作成されたダイアログの将来のリクエストのパスに留まることを望む場合（リクエストがダイアログを作成すると仮定）、既存のRecord-Routeヘッダーフィールド値の前にRecord-Routeヘッダーフィールド値をコピーに挿入する必要があります。 、Routeヘッダーフィールドがすでに存在する場合でも。
Requests establishing a dialog may contain a preloaded Route header field.
ダイアログを確立するリクエストには、プリロードされたルートヘッダーフィールドが含まれる場合があります。
If this request is already part of a dialog, the proxy SHOULD insert a Record-Route header field value if it wishes to remain on the path of future requests in the dialog. In normal endpoint operation as described in Section 12, these Record-Route header field values will not have any effect on the route sets used by the endpoints.
このリクエストがすでにダイアログの一部である場合、プロキシは、ダイアログ内の将来のリクエストのパスに留まりたい場合は、Record-Routeヘッダーフィールド値を挿入する必要があります（SHOULD）。セクション12で説明されている通常のエンドポイント操作では、これらのRecord-Routeヘッダーフィールド値は、エンドポイントで使用されるルートセットに影響を与えません。
The proxy will remain on the path if it chooses to not insert a Record-Route header field value into requests that are already part of a dialog. However, it would be removed from the path when an endpoint that has failed reconstitutes the dialog.
すでにダイアログの一部であるリクエストにRecord-Routeヘッダーフィールド値を挿入しないことを選択した場合、プロキシはパスに残ります。ただし、失敗したエンドポイントがダイアログを再構成すると、パスから削除されます。
A proxy MAY insert a Record-Route header field value into any request. If the request does not initiate a dialog, the endpoints will ignore the value. See Section 12 for details on how endpoints use the Record-Route header field values to construct Route header fields.
プロキシはRecord-Routeヘッダーフィールド値をリクエストに挿入してもよい（MAY）。リクエストがダイアログを開始しない場合、エンドポイントは値を無視します。エンドポイントがRecord-Routeヘッダーフィールド値を使用してRouteヘッダーフィールドを構築する方法の詳細については、セクション12を参照してください。
Each proxy in the path of a request chooses whether to add a Record-Route header field value independently - the presence of a Record-Route header field in a request does not obligate this proxy to add a value.
リクエストのパスの各プロキシは、Record-Routeヘッダーフィールド値を個別に追加するかどうかを選択します。リクエストにRecord-Routeヘッダーフィールドが存在しても、このプロキシに値を追加する必要はありません。
The URI placed in the Record-Route header field value MUST be a SIP or SIPS URI. This URI MUST contain an lr parameter (see Section 19.1.1). This URI MAY be different for each destination the request is forwarded to. The URI SHOULD NOT contain the transport parameter unless the proxy has knowledge (such as in a private network) that the next downstream element that will be in the path of subsequent requests supports that transport.
Record-Routeヘッダーフィールド値に配置されるURIは、SIPまたはSIPS URIである必要があります。このURIには、lrパラメータを含める必要があります（19.1.1項を参照）。このURIは、リクエストの転送先ごとに異なる場合があります。後続のリクエストのパスにある次のダウンストリーム要素がそのトランスポートをサポートすることをプロキシが（プライベートネットワークなどで）知っている場合を除き、URIにはトランスポートパラメータを含めないでください。
The URI this proxy provides will be used by some other element to make a routing decision. This proxy, in general, has no way of knowing the capabilities of that element, so it must restrict itself to the mandatory elements of a SIP implementation: SIP URIs and either the TCP or UDP transports.
このプロキシが提供するURIは、ルーティングを決定するために他の要素によって使用されます。このプロキシは、通常、その要素の機能を知る方法がないため、SIP実装の必須要素であるSIP URIとTCPまたはUDPトランスポートのいずれかに自分自身を制限する必要があります。
The URI placed in the Record-Route header field MUST resolve to the element inserting it (or a suitable stand-in) when the server location procedures of [4] are applied to it, so that subsequent requests reach the same SIP element. If the Request-URI contains a SIPS URI, or the topmost Route header field value (after the post processing of bullet 6) contains a SIPS URI, the URI placed into the Record-Route header field MUST be a SIPS URI. Furthermore, if the request was not received over TLS, the proxy MUST insert a Record-Route header field. In a similar fashion, a proxy that receives a request over TLS, but generates a request without a SIPS URI in the Request-URI or topmost Route header field value (after the post processing of bullet 6), MUST insert a Record-Route header field that is not a SIPS URI.
Record-Routeヘッダーフィールドに配置されたURIは、[4]のサーバーロケーションプロシージャが適用されるときに、それを挿入する要素（または適切な代用）に解決される必要があります。これにより、後続のリクエストが同じSIP要素に到達します。 Request-URIにSIPS URIが含まれている場合、または最上部のルートヘッダーフィールド値（箇条書き6の後処理後）にSIPS URIが含まれている場合、Record-Routeヘッダーフィールドに配置されるURIはSIPS URIでなければなりません。さらに、要求がTLS経由で受信されなかった場合、プロキシはRecord-Routeヘッダーフィールドを挿入する必要があります。同様に、TLSを介して要求を受信するが、Request-URIまたは最上位のRouteヘッダーフィールド値（箇条書き6の後処理後）にSIPS URIなしで要求を生成するプロキシは、Record-Routeヘッダーを挿入する必要があります。 SIPS URIではないフィールド。
A proxy at a security perimeter must remain on the perimeter throughout the dialog.
セキュリティ境界にあるプロキシは、ダイアログ全体を通じて境界にとどまる必要があります。
If the URI placed in the Record-Route header field needs to be rewritten when it passes back through in a response, the URI MUST be distinct enough to locate at that time. (The request may spiral through this proxy, resulting in more than one Record-Route header field value being added). Item 8 of Section 16.7 recommends a mechanism to make the URI sufficiently distinct.
Record-Routeヘッダーフィールドに配置されたURIが応答でパススルーされるときに書き換える必要がある場合、そのURIはその時点で特定できるように十分に区別されている必要があります。 （リクエストはこのプロキシを介してスパイラルになり、その結果、複数のRecord-Routeヘッダーフィールド値が追加されます）。セクション16.7の項目8は、URIを十分に区別するメカニズムを推奨しています。
The proxy MAY include parameters in the Record-Route header field value. These will be echoed in some responses to the request such as the 200 (OK) responses to INVITE. Such parameters may be useful for keeping state in the message rather than the proxy.
プロキシはRecord-Routeヘッダーフィールド値にパラメーターを含めることができます（MAY）。これらは、INVITEに対する200（OK）応答など、要求に対する一部の応答でエコーされます。このようなパラメータは、プロキシではなくメッセージの状態を維持するのに役立ちます。
If a proxy needs to be in the path of any type of dialog (such as one straddling a firewall), it SHOULD add a Record-Route header field value to every request with a method it does not understand since that method may have dialog semantics.
プロキシが任意のタイプのダイアログ（ファイアウォールにまたがるなど）のパスにある必要がある場合、そのメソッドはダイアログのセマンティクスを持っている可能性があるため、理解できないメソッドを使用してすべてのリクエストにRecord-Routeヘッダーフィールド値を追加する必要があります（SHOULD）。 。
The URI a proxy places into a Record-Route header field is only valid for the lifetime of any dialog created by the transaction in which it occurs. A dialog-stateful proxy, for example, MAY refuse to accept future requests with that value in the Request-URI after the dialog has terminated. Non-dialog-stateful proxies, of course, have no concept of when the dialog has terminated, but they MAY encode enough information in the value to compare it against the dialog identifier of future requests and MAY reject requests not matching that information. Endpoints MUST NOT use a URI obtained from a Record-Route header field outside the dialog in which it was provided. See
プロキシがRecord-Routeヘッダーフィールドに配置するURIは、それが発生するトランザクションによって作成されるダイアログの存続期間中のみ有効です。たとえば、ダイアログステートフルプロキシは、ダイアログが終了した後、Request-URIにその値を持つ将来のリクエストの受け入れを拒否する場合があります。もちろん、非ダイアログステートフルプロキシには、ダイアログがいつ終了したかという概念はありませんが、値に十分な情報をエンコードして、将来のリクエストのダイアログ識別子と比較し、その情報と一致しないリクエストを拒否する場合があります。エンドポイントは、それが提供されたダイアログの外のRecord-Routeヘッダーフィールドから取得したURIを使用してはなりません（MUST NOT）。見る
Section 12 for more information on an endpoint's use of Record-Route header fields.
エンドポイントでのRecord-Routeヘッダーフィールドの使用の詳細については、セクション12。
Record-routing may be required by certain services where the proxy needs to observe all messages in a dialog. However, it slows down processing and impairs scalability and thus proxies should only record-route if required for a particular service.
プロキシがダイアログ内のすべてのメッセージを監視する必要がある特定のサービスでは、レコードのルーティングが必要になる場合があります。ただし、処理が遅くなり、スケーラビリティが損なわれるため、プロキシは特定のサービスに必要な場合にのみルートを記録する必要があります。
The Record-Route process is designed to work for any SIP request that initiates a dialog. INVITE is the only such request in this specification, but extensions to the protocol MAY define others.
Record-Routeプロセスは、ダイアログを開始するSIP要求に対して機能するように設計されています。 INVITEはこの仕様で唯一のそのような要求ですが、プロトコルへの拡張は他のものを定義するかもしれません。
5. Add Additional Header Fields
5. 追加のヘッダーフィールドを追加する
The proxy MAY add any other appropriate header fields to the copy at this point.
この時点で、プロキシは他の適切なヘッダーフィールドをコピーに追加してもかまいません（MAY）。
6. Postprocess routing information
6. ポストプロセスルーティング情報
A proxy MAY have a local policy that mandates that a request visit a specific set of proxies before being delivered to the destination. A proxy MUST ensure that all such proxies are loose routers. Generally, this can only be known with certainty if the proxies are within the same administrative domain. This set of proxies is represented by a set of URIs (each of which contains the lr parameter). This set MUST be pushed into the Route header field of the copy ahead of any existing values, if present. If the Route header field is absent, it MUST be added, containing that list of URIs.
プロキシは、リクエストが宛先に配信される前に特定のプロキシのセットを訪問することを義務付けるローカルポリシーを持つ場合があります。プロキシは、そのようなプロキシがすべてルーズルーターであることを確認する必要があります。通常、これは確実にプロキシが同じ管理ドメイン内にある場合にのみ確実に知ることができます。このプロキシのセットは、URIのセットで表されます（それぞれにlrパラメータが含まれています）。このセットは、存在する場合、既存の値の前にコピーのルートヘッダーフィールドにプッシュする必要があります。 Routeヘッダーフィールドが存在しない場合は、そのURIリストを含むフィールドを追加する必要があります。
If the proxy has a local policy that mandates that the request visit one specific proxy, an alternative to pushing a Route value into the Route header field is to bypass the forwarding logic of item 10 below, and instead just send the request to the address, port, and transport for that specific proxy. If the request has a Route header field, this alternative MUST NOT be used unless it is known that next hop proxy is a loose router. Otherwise, this approach MAY be used, but the Route insertion mechanism above is preferred for its robustness, flexibility, generality and consistency of operation. Furthermore, if the Request-URI contains a SIPS URI, TLS MUST be used to communicate with that proxy.
プロキシに、リクエストが特定のプロキシを訪問することを義務付けるローカルポリシーがある場合、ルートヘッダーフィールドにルート値をプッシュする代わりに、以下の項目10の転送ロジックをバイパスし、代わりにリクエストをアドレスに送信します。その特定のプロキシのポートとトランスポート。リクエストにルートヘッダーフィールドがある場合、ネクストホッププロキシがルーズルーターであることがわかっていない限り、この代替手段を使用してはなりません（MUST NOT）。それ以外の場合は、このアプローチを使用できますが、堅牢性、柔軟性、一般性、および操作の一貫性のために、上記のルート挿入メカニズムが推奨されます。さらに、Request-URIにSIPS URIが含まれている場合は、TLSを使用してそのプロキシと通信する必要があります。
If the copy contains a Route header field, the proxy MUST inspect the URI in its first value. If that URI does not contain an lr parameter, the proxy MUST modify the copy as follows:
コピーにルートヘッダーフィールドが含まれている場合、プロキシは最初の値のURIを検査する必要があります。そのURIにlrパラメータが含まれていない場合、プロキシはコピーを次のように変更する必要があります。
- The proxy MUST place the Request-URI into the Route header field as the last value.
- プロキシは、Request-URIを最後の値としてRouteヘッダーフィールドに配置する必要があります。
- The proxy MUST then place the first Route header field value into the Request-URI and remove that value from the Route header field.
- 次に、プロキシは最初のルートヘッダーフィールド値をリクエストURIに配置し、その値をルートヘッダーフィールドから削除する必要があります。
Appending the Request-URI to the Route header field is part of a mechanism used to pass the information in that Request-URI through strict-routing elements. "Popping" the first Route header field value into the Request-URI formats the message the way a strict-routing element expects to receive it (with its own URI in the Request-URI and the next location to visit in the first Route header field value).
RouteヘッダーフィールドにRequest-URIを追加することは、strict-routing要素を通じてそのRequest-URIの情報を渡すために使用されるメカニズムの一部です。最初のルートヘッダーフィールド値をRequest-URIに「ポップ」すると、ストリクトルーティングエレメントがメッセージを受信するために期待する方法でメッセージがフォーマットされます（Request-URIに独自のURIがあり、最初のルートヘッダーフィールドに次にアクセスする場所がある）値）。
7. Determine Next-Hop Address, Port, and Transport
7. ネクストホップアドレス、ポート、およびトランスポートを決定する
The proxy MAY have a local policy to send the request to a specific IP address, port, and transport, independent of the values of the Route and Request-URI. Such a policy MUST NOT be used if the proxy is not certain that the IP address, port, and transport correspond to a server that is a loose router. However, this mechanism for sending the request through a specific next hop is NOT RECOMMENDED; instead a Route header field should be used for that purpose as described above.
プロキシは、ルートとリクエストURIの値に関係なく、リクエストを特定のIPアドレス、ポート、トランスポートに送信するローカルポリシーを持つ場合があります。 IPアドレス、ポート、トランスポートがルーズルーターであるサーバーに対応していることをプロキシが確信していない場合は、このようなポリシーを使用してはなりません（MUST NOT）。ただし、特定のネクストホップを介して要求を送信するこのメカニズムは推奨されません。代わりに、上記のように、Routeヘッダーフィールドをその目的で使用する必要があります。
In the absence of such an overriding mechanism, the proxy applies the procedures listed in [4] as follows to determine where to send the request. If the proxy has reformatted the request to send to a strict-routing element as described in step 6 above, the proxy MUST apply those procedures to the Request-URI of the request. Otherwise, the proxy MUST apply the procedures to the first value in the Route header field, if present, else the Request-URI. The procedures will produce an ordered set of (address, port, transport) tuples. Independently of which URI is being used as input to the procedures of [4], if the Request-URI specifies a SIPS resource, the proxy MUST follow the procedures of [4] as if the input URI were a SIPS URI.
このようなオーバーライドメカニズムがない場合、プロキシは[4]にリストされている手順を次のように適用して、リクエストの送信先を決定します。上記の手順6で説明したように、プロキシが送信するリクエストをstrict-routing要素に再フォーマットした場合、プロキシはそれらの手順をリクエストのRequest-URIに適用する必要があります。それ以外の場合、プロキシは、存在する場合はルートヘッダーフィールドの最初の値にプロシージャを適用する必要があります。プロシージャは、（アドレス、ポート、トランスポート）タプルの順序付けされたセットを生成します。 [4]の手順への入力としてどのURIが使用されているかに関係なく、Request-URIがSIPSリソースを指定している場合、プロキシは入力URIがSIPS URIであるかのように[4]の手順に従う必要があります。
As described in [4], the proxy MUST attempt to deliver the message to the first tuple in that set, and proceed through the set in order until the delivery attempt succeeds.
[4]で説明されているように、プロキシはそのセットの最初のタプルへのメッセージの配信を試み、配信の試行が成功するまで順番にセットを進めなければなりません（MUST）。
For each tuple attempted, the proxy MUST format the message as appropriate for the tuple and send the request using a new client transaction as detailed in steps 8 through 10.
試行されたタプルごとに、プロキシはタプルに応じてメッセージをフォーマットし、手順8〜10で詳しく説明されているように、新しいクライアントトランザクションを使用してリクエストを送信する必要があります。
Since each attempt uses a new client transaction, it represents a new branch. Thus, the branch parameter provided with the Via header field inserted in step 8 MUST be different for each attempt.
各試行は新しいクライアントトランザクションを使用するため、新しいブランチを表します。したがって、ステップ8で挿入されたViaヘッダーフィールドで提供されるブランチパラメータは、試行ごとに異なる必要があります。
If the client transaction reports failure to send the request or a timeout from its state machine, the proxy continues to the next address in that ordered set. If the ordered set is exhausted, the request cannot be forwarded to this element in the target set. The proxy does not need to place anything in the response context, but otherwise acts as if this element of the target set returned a 408 (Request Timeout) final response.
クライアントトランザクションがリクエストの送信に失敗したこと、またはそのステートマシンからのタイムアウトを報告した場合、プロキシはその順序付けられたセットの次のアドレスに進みます。順序付きセットが使い果たされると、要求はターゲットセット内のこの要素に転送できません。プロキシは応答コンテキストに何も配置する必要はありませんが、それ以外の場合は、ターゲットセットのこの要素が408（Request Timeout）最終応答を返したかのように動作します。
8. Add a Via header field value
8. Viaヘッダーフィールド値を追加する
The proxy MUST insert a Via header field value into the copy before the existing Via header field values. The construction of this value follows the same guidelines of Section 8.1.1.7. This implies that the proxy will compute its own branch parameter, which will be globally unique for that branch, and contain the requisite magic cookie. Note that this implies that the branch parameter will be different for different instances of a spiraled or looped request through a proxy.
プロキシは、既存のViaヘッダーフィールド値の前に、Viaヘッダーフィールド値をコピーに挿入する必要があります。この値の構成は、セクション8.1.1.7と同じガイドラインに従います。これは、プロキシが自身のブランチパラメータを計算することを意味します。これは、そのブランチに対してグローバルに一意であり、必要なマジックCookieを含みます。これは、ブランチパラメータが、プロキシ経由のスパイラルまたはループされたリクエストのインスタンスごとに異なることを意味することに注意してください。
Proxies choosing to detect loops have an additional constraint in the value they use for construction of the branch parameter. A proxy choosing to detect loops SHOULD create a branch parameter separable into two parts by the implementation. The first part MUST satisfy the constraints of Section 8.1.1.7 as described above. The second is used to perform loop detection and distinguish loops from spirals.
ループの検出を選択したプロキシは、ブランチパラメータの構築に使用する値に追加の制約があります。ループを検出することを選択するプロキシは、実装によって2つの部分に分離可能なブランチパラメータを作成する必要があります（SHOULD）。最初の部分は、上記のセクション8.1.1.7の制約を満たす必要があります。 2つ目は、ループ検出を実行し、ループとスパイラルを区別するために使用されます。
Loop detection is performed by verifying that, when a request returns to a proxy, those fields having an impact on the processing of the request have not changed. The value placed in this part of the branch parameter SHOULD reflect all of those fields (including any Route, Proxy-Require and Proxy-Authorization header fields). This is to ensure that if the request is routed back to the proxy and one of those fields changes, it is treated as a spiral and not a loop (see Section 16.3). A common way to create this value is to compute a cryptographic hash of the To tag, From tag, Call-ID header field, the Request-URI of the request received (before translation), the topmost Via header, and the sequence number from the CSeq header field, in addition to any Proxy-Require and Proxy-Authorization header fields that may be present. The algorithm used to compute the hash is implementation-dependent, but MD5 (RFC 1321 [35]), expressed in hexadecimal, is a reasonable choice. (Base64 is not permissible for a token.)
ループ検出は、要求がプロキシに戻ったときに、要求の処理に影響を与えるフィールドが変更されていないことを確認することによって実行されます。ブランチパラメータのこの部分に配置された値は、それらのすべてのフィールドを反映する必要があります（ルート、Proxy-RequireおよびProxy-Authorizationヘッダーフィールドを含む）。これは、リクエストがプロキシにルーティングされ、それらのフィールドの1つが変更された場合に、ループではなくスパイラルとして扱われるようにするためです（セクション16.3を参照）。この値を作成する一般的な方法は、Toタグ、Fromタグ、Call-IDヘッダーフィールド、受信したリクエストのRequest-URI（変換前）、最上位のViaヘッダー、およびシーケンス番号の暗号化ハッシュを計算することです存在する可能性があるすべてのProxy-RequireおよびProxy-Authorizationヘッダーフィールドに加えて、CSeqヘッダーフィールド。ハッシュの計算に使用されるアルゴリズムは実装に依存しますが、16進数で表されるMD5（RFC 1321 [35]）が妥当な選択です。 （Base64はトークンに使用できません。）
If a proxy wishes to detect loops, the "branch" parameter it supplies MUST depend on all information affecting processing of a request, including the incoming Request-URI and any header fields affecting the request's admission or routing. This is necessary to distinguish looped requests from requests whose routing parameters have changed before returning to this server.
プロキシーがループを検出したい場合、プロキシーが提供する「ブランチ」パラメーターは、要求の処理に影響するすべての情報に依存する必要があります。これには、着信Request-URIと、要求のアドミッションまたはルーティングに影響するヘッダーフィールドが含まれます。これは、ループされた要求と、このサーバーに戻る前にルーティングパラメータが変更された要求を区別するために必要です。
The request method MUST NOT be included in the calculation of the branch parameter. In particular, CANCEL and ACK requests (for non-2xx responses) MUST have the same branch value as the corresponding request they cancel or acknowledge. The branch parameter is used in correlating those requests at the server handling them (see Sections 17.2.3 and 9.2).
リクエストメソッドは、ブランチパラメータの計算に含めてはなりません（MUST NOT）。特に、CANCELおよびACKリクエスト（2xx以外の応答の場合）は、キャンセルまたは確認する対応するリクエストと同じブランチ値を持つ必要があります。ブランチパラメータは、リクエストを処理するサーバーでそれらのリクエストを関連付ける際に使用されます（セクション17.2.3および9.2を参照）。
9. Add a Content-Length header field if necessary
9. 必要に応じてContent-Lengthヘッダーフィールドを追加する
If the request will be sent to the next hop using a stream-based transport and the copy contains no Content-Length header field, the proxy MUST insert one with the correct value for the body of the request (see Section 20.14).
ストリームベースのトランスポートを使用してリクエストがネクストホップに送信され、コピーにContent-Lengthヘッダーフィールドが含まれていない場合、プロキシはリクエストの本文に正しい値を含むフィールドを挿入する必要があります（セクション20.14を参照）。
10. Forward Request
10. リクエストの転送
A stateful proxy MUST create a new client transaction for this request as described in Section 17.1 and instructs the transaction to send the request using the address, port and transport determined in step 7.
ステートフルプロキシは、セクション17.1で説明されているように、この要求に対して新しいクライアントトランザクションを作成する必要があり、トランザクションに、手順7で決定されたアドレス、ポート、およびトランスポートを使用して要求を送信するように指示します。
11. Set timer C
11. タイマーCを設定
In order to handle the case where an INVITE request never generates a final response, the TU uses a timer which is called timer C. Timer C MUST be set for each client transaction when an INVITE request is proxied. The timer MUST be larger than 3 minutes. Section 16.7 bullet 2 discusses how this timer is updated with provisional responses, and Section 16.8 discusses processing when it fires.
INVITE要求が最終応答を生成しない場合を処理するために、TUはタイマーCと呼ばれるタイマーを使用します。タイマーCは、INVITE要求がプロキシされるときに各クライアントトランザクションに設定する必要があります。タイマーは3分より大きくなければなりません。セクション16.7の箇条書き2では、このタイマーがどのように暫定応答で更新されるかを説明し、セクション16.8では、タイマーが起動したときの処理について説明します。
When a response is received by an element, it first tries to locate a client transaction (Section 17.1.3) matching the response. If none is found, the element MUST process the response (even if it is an informational response) as a stateless proxy (described below). If a match is found, the response is handed to the client transaction.
要素が応答を受信すると、最初に、その応答に一致するクライアントトランザクション（セクション17.1.3）を見つけようとします。何も見つからない場合、要素は応答を（情報応答であっても）ステートレスプロキシ（以下で説明）として処理する必要があります。一致が見つかった場合、応答はクライアントトランザクションに渡されます。
Forwarding responses for which a client transaction (or more generally any knowledge of having sent an associated request) is not found improves robustness. In particular, it ensures that "late" 2xx responses to INVITE requests are forwarded properly.
クライアントトランザクション（またはより一般的には、関連付けられた要求を送信したという知識）が見つからない応答を転送すると、堅牢性が向上します。特に、INVITE要求に対する「遅い」2xx応答が適切に転送されることが保証されます。
As client transactions pass responses to the proxy layer, the following processing MUST take place:
クライアントトランザクションがプロキシレイヤーに応答を渡すと、次の処理を実行する必要があります。
1. Find the appropriate response context
1. 適切な応答コンテキストを見つける
2. Update timer C for provisional responses
2. 暫定応答のタイマーCを更新する
3. Remove the topmost Via
3. 一番上のビアを削除
4. Add the response to the response context
4. 応答を応答コンテキストに追加する
5. Check to see if this response should be forwarded immediately
5. この応答をすぐに転送する必要があるかどうかを確認してください
6. When necessary, choose the best final response from the response context
6. 必要に応じて、応答コンテキストから最適な最終応答を選択します
If no final response has been forwarded after every client transaction associated with the response context has been terminated, the proxy must choose and forward the "best" response from those it has seen so far.
応答コンテキストに関連付けられたすべてのクライアントトランザクションが終了した後に最終応答が転送されない場合、プロキシは、これまでに確認した応答から「最適な」応答を選択して転送する必要があります。
The following processing MUST be performed on each response that is forwarded. It is likely that more than one response to each request will be forwarded: at least each provisional and one final response.
転送される応答ごとに、次の処理を実行する必要があります。各要求に対する複数の応答が転送される可能性があります。少なくとも各暫定応答と1つの最終応答です。
7. Aggregate authorization header field values if necessary
7. 必要に応じて認証ヘッダーフィールド値を集約する
8. Optionally rewrite Record-Route header field values
8. オプションでRecord-Routeヘッダーフィールドの値を書き換えます
9. Forward the response
9. 応答を転送する
10. Generate any necessary CANCEL requests
10. 必要なCANCELリクエストを生成します
Each of the above steps are detailed below:
上記の各ステップの詳細は以下のとおりです。
1. Find Context
1. コンテキストを見つける
The proxy locates the "response context" it created before forwarding the original request using the key described in Section 16.6. The remaining processing steps take place in this context.
プロキシは、セクション16.6で説明されているキーを使用して元のリクエストを転送する前に、プロキシが作成した「応答コンテキスト」を見つけます。残りの処理ステップはこのコンテキストで行われます。
2. Update timer C for provisional responses
2. 暫定応答のタイマーCを更新する
For an INVITE transaction, if the response is a provisional response with status codes 101 to 199 inclusive (i.e., anything but 100), the proxy MUST reset timer C for that client transaction. The timer MAY be reset to a different value, but this value MUST be greater than 3 minutes.
INVITEトランザクションの場合、応答がステータスコード101から199（100以外）の暫定応答である場合、プロキシはそのクライアントトランザクションのタイマーCをリセットする必要があります。タイマーは別の値にリセットできますが、この値は3分より大きくなければなりません（MUST）。
3. Via
3. 経由
The proxy removes the topmost Via header field value from the response.
プロキシは、応答から最上位のViaヘッダーフィールド値を削除します。
If no Via header field values remain in the response, the response was meant for this element and MUST NOT be forwarded. The remainder of the processing described in this section is not performed on this message, the UAC processing rules described in Section 8.1.3 are followed instead (transport layer processing has already occurred).
応答にViaヘッダーフィールド値が残っていない場合、応答はこの要素に対するものであり、転送してはなりません（MUST NOT）。このセクションで説明されている残りの処理は、このメッセージでは実行されません。代わりに、セクション8.1.3で説明されているUAC処理ルールに従います（トランスポート層の処理は既に発生しています）。
This will happen, for instance, when the element generates CANCEL requests as described in Section 10.
これは、たとえば、要素がセクション10で説明されているCANCELリクエストを生成するときに発生します。
4. Add response to context
4. コンテキストへの応答を追加
Final responses received are stored in the response context until a final response is generated on the server transaction associated with this context. The response may be a candidate for the best final response to be returned on that server transaction. Information from this response may be needed in forming the best response, even if this response is not chosen.
受信した最終応答は、このコンテキストに関連付けられたサーバートランザクションで最終応答が生成されるまで、応答コンテキストに格納されます。応答は、そのサーバートランザクションで返される最良の最終応答の候補になる場合があります。この応答が選択されていない場合でも、この応答からの情報は、最良の応答を形成するために必要になる場合があります。
If the proxy chooses to recurse on any contacts in a 3xx response by adding them to the target set, it MUST remove them from the response before adding the response to the response context. However, a proxy SHOULD NOT recurse to a non-SIPS URI if the Request-URI of the original request was a SIPS URI. If the proxy recurses on all of the contacts in a 3xx response, the proxy SHOULD NOT add the resulting contactless response to the response context.
プロキシが3xx応答の連絡先をターゲットセットに追加することで再帰することを選択した場合、応答を応答コンテキストに追加する前に、それらを応答から削除する必要があります。ただし、元の要求のRequest-URIがSIPS URIであった場合、プロキシは非SIP URIに再帰すべきではありません（SHOULD NOT）。プロキシが3xx応答のすべての連絡先で再帰する場合、プロキシは、結果の非接触応答を応答コンテキストに追加してはなりません（SHOULD NOT）。
Removing the contact before adding the response to the response context prevents the next element upstream from retrying a location this proxy has already attempted.
応答を応答コンテキストに追加する前に連絡先を削除すると、次の要素の上流が、このプロキシがすでに試みた場所を再試行することを防ぎます。
3xx responses may contain a mixture of SIP, SIPS, and non-SIP URIs. A proxy may choose to recurse on the SIP and SIPS URIs and place the remainder into the response context to be returned, potentially in the final response.
3xx応答には、SIP、SIPS、および非SIP URIの混合が含まれる場合があります。プロキシは、SIP URIとSIPS URIを再帰的に選択し、残りを応答コンテキストに入れて返されます。最終的には返される可能性があります。
If a proxy receives a 416 (Unsupported URI Scheme) response to a request whose Request-URI scheme was not SIP, but the scheme in the original received request was SIP or SIPS (that is, the proxy changed the scheme from SIP or SIPS to something else when it proxied a request), the proxy SHOULD add a new URI to the target set. This URI SHOULD be a SIP URI version of the non-SIP URI that was just tried. In the case of the tel URL, this is accomplished by placing the telephone-subscriber part of the tel URL into the user part of the SIP URI, and setting the hostpart to the domain where the prior request was sent. See Section 19.1.6 for more detail on forming SIP URIs from tel URLs.
プロキシが、Request-URIスキームがSIPではないリクエストに対する416（サポートされていないURIスキーム）応答を受信したが、元の受信リクエストのスキームがSIPまたはSIPSであった場合（つまり、プロキシがスキームをSIPまたはSIPSからに変更した場合）リクエストをプロキシするときに何か他のもの）、プロキシは新しいURIをターゲットセットに追加する必要があります（SHOULD）。このURIは、試行されたばかりの非SIP URIのSIP URIバージョンである必要があります（SHOULD）。 tel URLの場合、これはtel URLの電話加入者の部分をSIP URIのユーザー部分に配置し、前の要求が送信されたドメインにホスト部分を設定することによって実現されます。 Tel URLからSIP URIを形成する方法の詳細については、セクション19.1.6を参照してください。
As with a 3xx response, if a proxy "recurses" on the 416 by trying a SIP or SIPS URI instead, the 416 response SHOULD NOT be added to the response context.
3xx応答と同様に、プロキシがSIPまたはSIPS URIを試行することによって416で「再帰」する場合、416応答は応答コンテキストに追加してはなりません（SHOULD NOT）。
5. Check response for forwarding
5. 転送の応答を確認する
Until a final response has been sent on the server transaction, the following responses MUST be forwarded immediately:
サーバートランザクションで最終応答が送信されるまで、次の応答をすぐに転送する必要があります。
- Any provisional response other than 100 (Trying)
- 100以外の暫定応答（試行中）
- Any 2xx response
- 任意の2xx応答
If a 6xx response is received, it is not immediately forwarded, but the stateful proxy SHOULD cancel all client pending transactions as described in Section 10, and it MUST NOT create any new branches in this context.
6xx応答が受信された場合、それはすぐには転送されませんが、ステートフルプロキシはセクション10で説明されているようにすべてのクライアント保留トランザクションをキャンセルする必要があり（SHOULD）、このコンテキストで新しいブランチを作成してはなりません。
This is a change from RFC 2543, which mandated that the proxy was to forward the 6xx response immediately. For an INVITE transaction, this approach had the problem that a 2xx response could arrive on another branch, in which case the proxy would have to forward the 2xx. The result was that the UAC could receive a 6xx response followed by a 2xx response, which should never be allowed to happen. Under the new rules, upon receiving a 6xx, a proxy will issue a CANCEL request, which will generally result in 487 responses from all outstanding client transactions, and then at that point the 6xx is forwarded upstream.
これは、プロキシが6xx応答をすぐに転送することを義務付けていたRFC 2543からの変更点です。 INVITEトランザクションの場合、このアプローチには2xx応答が別のブランチに到着するという問題がありました。その場合、プロキシは2xxを転送する必要があります。その結果、UACは6xx応答を受信し、続いて2xx応答を受信する可能性がありました。新しいルールでは、6xxを受信すると、プロキシがCANCELリクエストを発行します。これにより、通常、すべての未解決のクライアントトランザクションから487の応答が返され、その時点で6xxがアップストリームに転送されます。
After a final response has been sent on the server transaction, the following responses MUST be forwarded immediately:
最後の応答がサーバートランザクションで送信された後、次の応答をすぐに転送する必要があります。
- Any 2xx response to an INVITE request
- INVITEリクエストに対する2xx応答
A stateful proxy MUST NOT immediately forward any other responses. In particular, a stateful proxy MUST NOT forward any 100 (Trying) response. Those responses that are candidates for forwarding later as the "best" response have been gathered as described in step "Add Response to Context".
ステートフルプロキシは、他の応答をすぐに転送してはなりません（MUST NOT）。特に、ステートフルプロキシは100（Trying）応答を転送してはなりません（MUST NOT）。 「コンテキストへの応答の追加」で説明されているように、「最良の」応答が収集されたときに転送の候補となる応答。
Any response chosen for immediate forwarding MUST be processed as described in steps "Aggregate Authorization Header Field Values" through "Record-Route".
即時転送用に選択された応答は、「レコード承認ルート」から「承認ヘッダーフィールド値の集計」の手順で説明されているように処理する必要があります。
This step, combined with the next, ensures that a stateful proxy will forward exactly one final response to a non-INVITE request, and either exactly one non-2xx response or one or more 2xx responses to an INVITE request.
このステップと次のステップを組み合わせると、ステートフルプロキシは、INVITE以外の要求に対する最終応答を1つだけ転送し、2xx以外の応答またはINVITE要求に対する1つ以上の2xx応答を確実に転送します。
6. Choosing the best response
6. 最良の応答を選択する
A stateful proxy MUST send a final response to a response context's server transaction if no final responses have been immediately forwarded by the above rules and all client transactions in this response context have been terminated.
ステートフルプロキシは、最終的な応答が上記のルールによってすぐに転送されておらず、この応答コンテキスト内のすべてのクライアントトランザクションが終了している場合、応答コンテキストのサーバートランザクションに最終応答を送信する必要があります。
The stateful proxy MUST choose the "best" final response among those received and stored in the response context.
ステートフルプロキシは、応答コンテキストで受信および保存された応答の中から「最良の」最終応答を選択する必要があります。
If there are no final responses in the context, the proxy MUST send a 408 (Request Timeout) response to the server transaction.
コンテキストに最終応答がない場合、プロキシはサーバートランザクションに408（Request Timeout）応答を送信する必要があります。
Otherwise, the proxy MUST forward a response from the responses stored in the response context. It MUST choose from the 6xx class responses if any exist in the context. If no 6xx class responses are present, the proxy SHOULD choose from the lowest response class stored in the response context. The proxy MAY select any response within that chosen class. The proxy SHOULD give preference to responses that provide information affecting resubmission of this request, such as 401, 407, 415, 420, and 484 if the 4xx class is chosen.
それ以外の場合、プロキシは応答コンテキストに格納されている応答から応答を転送する必要があります。コンテキストに存在する場合は、6xxクラスの応答から選択する必要があります。 6xxクラスの応答が存在しない場合、プロキシは、応答コンテキストに格納されている最も低い応答クラスから選択する必要があります（SHOULD）。プロキシは、選択したクラス内の応答を選択できます（MAY）。プロキシは、4xxクラスが選択された場合、401、407、415、420、484など、このリクエストの再送信に影響する情報を提供する応答を優先する必要があります（SHOULD）。
A proxy which receives a 503 (Service Unavailable) response SHOULD NOT forward it upstream unless it can determine that any subsequent requests it might proxy will also generate a 503. In other words, forwarding a 503 means that the proxy knows it cannot service any requests, not just the one for the Request-URI in the request which generated the 503. If the only response that was received is a 503, the proxy SHOULD generate a 500 response and forward that upstream.
503（Service Unavailable）応答を受信するプロキシは、それがプロキシする可能性のある後続の要求も503を生成すると判断できない限り、それをアップストリームに転送してはなりません（SHOULD NOT）。 、503を生成した要求のRequest-URIだけではありません。受信した応答が503のみの場合、プロキシは500応答を生成し、そのアップストリームに転送する必要があります（SHOULD）。
The forwarded response MUST be processed as described in steps "Aggregate Authorization Header Field Values" through "Record-Route".
転送された応答は、「Record-Route」から「Aggregate Authorization Header Field Values」の手順に従って処理する必要があります。
For example, if a proxy forwarded a request to 4 locations, and received 503, 407, 501, and 404 responses, it may choose to forward the 407 (Proxy Authentication Required) response.
たとえば、プロキシが要求を4つの場所に転送し、503、407、501、404の応答を受け取った場合、407（プロキシ認証が必要）応答を転送することを選択できます。
1xx and 2xx responses may be involved in the establishment of dialogs. When a request does not contain a To tag, the To tag in the response is used by the UAC to distinguish multiple responses to a dialog creating request. A proxy MUST NOT insert a tag into the To header field of a 1xx or 2xx response if the request did not contain one. A proxy MUST NOT modify the tag in the To header field of a 1xx or 2xx response.
1xxと2xxの応答がダイアログの確立に関係している可能性があります。要求にToタグが含まれていない場合、UACは応答のToタグを使用して、ダイアログ作成要求に対する複数の応答を区別します。リクエストにタグが含まれていない場合、プロキシは1xxまたは2xx応答のToヘッダーフィールドにタグを挿入してはなりません（MUST NOT）。プロキシは、1xxまたは2xx応答のToヘッダーフィールドのタグを変更してはなりません（MUST NOT）。
Since a proxy may not insert a tag into the To header field of a 1xx response to a request that did not contain one, it cannot issue non-100 provisional responses on its own. However, it can branch the request to a UAS sharing the same element as the proxy. This UAS can return its own provisional responses, entering into an early dialog with the initiator of the request. The UAS does not have to be a discreet process from the proxy. It could be a virtual UAS implemented in the same code space as the proxy.
プロキシは、タグが含まれていないリクエストに対する1xx応答のToヘッダーフィールドにタグを挿入できないため、100以外の暫定応答を単独で発行することはできません。ただし、プロキシと同じ要素を共有するUASにリクエストを分岐させることができます。このUASは、独自の暫定応答を返すことができ、要求の開始者との早期ダイアログに入ります。 UASは、プロキシからの慎重なプロセスである必要はありません。これは、プロキシと同じコード空間に実装された仮想UASである可能性があります。
3-6xx responses are delivered hop-by-hop. When issuing a 3-6xx response, the element is effectively acting as a UAS, issuing its own response, usually based on the responses received from downstream elements. An element SHOULD preserve the To tag when simply forwarding a 3-6xx response to a request that did not contain a To tag.
3-6xx応答はホップバイホップで配信されます。 3-6xx応答を発行する場合、要素はUASとして効果的に機能し、通常はダウンストリーム要素から受信した応答に基づいて、独自の応答を発行します。要素は、Toタグを含まないリクエストへの3-6xx応答を単に転送するときに、Toタグを保持する必要があります（SHOULD）。
A proxy MUST NOT modify the To tag in any forwarded response to a request that contains a To tag.
プロキシは、Toタグを含む要求への転送された応答のToタグを変更してはなりません（MUST NOT）。
While it makes no difference to the upstream elements if the proxy replaced the To tag in a forwarded 3-6xx response, preserving the original tag may assist with debugging.
転送された3-6xx応答でプロキシがToタグを置き換えた場合、上流の要素に違いはありませんが、元のタグを保持するとデバッグに役立つ場合があります。
When the proxy is aggregating information from several responses, choosing a To tag from among them is arbitrary, and generating a new To tag may make debugging easier. This happens, for instance, when combining 401 (Unauthorized) and 407 (Proxy Authentication Required) challenges, or combining Contact values from unencrypted and unauthenticated 3xx responses.
プロキシが複数の応答から情報を集約している場合、それらの中からToタグを選択することは任意であり、新しいToタグを生成するとデバッグが容易になる場合があります。これは、たとえば、401（無許可）チャレンジと407（プロキシ認証が必要）チャレンジを組み合わせたり、暗号化されていない、認証されていない3xx応答の連絡先の値を組み合わせたりすると発生します。
7. Aggregate Authorization Header Field Values
7. 集約承認ヘッダーフィールドの値
If the selected response is a 401 (Unauthorized) or 407 (Proxy Authentication Required), the proxy MUST collect any WWW-Authenticate and Proxy-Authenticate header field values from all other 401 (Unauthorized) and 407 (Proxy Authentication Required) responses received so far in this response context and add them to this response without modification before forwarding. The resulting 401 (Unauthorized) or 407 (Proxy Authentication Required) response could have several WWW-Authenticate AND Proxy-Authenticate header field values.
選択した応答が401（無許可）または407（プロキシ認証が必要）である場合、プロキシは受信した他のすべての401（無許可）および407（プロキシ認証が必要）応答からWWW-AuthenticateおよびProxy-Authenticateヘッダーフィールド値を収集する必要がありますこの応答コンテキストでははるかに遠く、転送する前に変更せずにそれらをこの応答に追加します。結果の401（無許可）または407（プロキシ認証が必要）応答には、いくつかのWWW-AuthenticateおよびProxy-Authenticateヘッダーフィールド値が含まれる可能性があります。
This is necessary because any or all of the destinations the request was forwarded to may have requested credentials. The client needs to receive all of those challenges and supply credentials for each of them when it retries the request. Motivation for this behavior is provided in Section 26.
これは、要求の転送先のいずれかまたはすべての宛先が資格情報を要求した可能性があるために必要です。クライアントは、これらのチャレンジをすべて受信し、リクエストを再試行するときに、それぞれの資格情報を提供する必要があります。この動作の動機は、セクション26に記載されています。
8. Record-Route
8. レコード経路
If the selected response contains a Record-Route header field value originally provided by this proxy, the proxy MAY choose to rewrite the value before forwarding the response. This allows the proxy to provide different URIs for itself to the next upstream and downstream elements. A proxy may choose to use this mechanism for any reason. For instance, it is useful for multi-homed hosts.
選択した応答に、このプロキシによって最初に提供されたRecord-Routeヘッダーフィールド値が含まれている場合、プロキシは応答を転送する前に値を書き換えることを選択できます（MAY）。これにより、プロキシは次のアップストリーム要素とダウンストリーム要素にそれ自体に異なるURIを提供できます。プロキシは、何らかの理由でこのメカニズムを使用することを選択できます。たとえば、マルチホームホストに役立ちます。
If the proxy received the request over TLS, and sent it out over a non-TLS connection, the proxy MUST rewrite the URI in the Record-Route header field to be a SIPS URI. If the proxy received the request over a non-TLS connection, and sent it out over TLS, the proxy MUST rewrite the URI in the Record-Route header field to be a SIP URI.
プロキシがTLS経由でリクエストを受信し、非TLS接続経由で送信した場合、プロキシはRecord-RouteヘッダーフィールドのURIをSIPS URIに書き換える必要があります。プロキシが非TLS接続を介して要求を受信し、それをTLSを介して送信した場合、プロキシはRecord-RouteヘッダーフィールドのURIをSIP URIに書き換える必要があります。
The new URI provided by the proxy MUST satisfy the same constraints on URIs placed in Record-Route header fields in requests (see Step 4 of Section 16.6) with the following modifications:
プロキシによって提供される新しいURIは、リクエストのRecord-Routeヘッダーフィールドに配置されたURIに関する同じ制約（セクション16.6のステップ4を参照）を次の変更で満たす必要があります。
The URI SHOULD NOT contain the transport parameter unless the proxy has knowledge that the next upstream (as opposed to downstream) element that will be in the path of subsequent requests supports that transport.
後続のリクエストのパスにある次のアップストリーム（ダウンストリームではなく）要素がそのトランスポートをサポートすることをプロキシが認識していない限り、URIにはトランスポートパラメータを含めないでください。
When a proxy does decide to modify the Record-Route header field in the response, one of the operations it performs is locating the Record-Route value that it had inserted. If the request spiraled, and the proxy inserted a Record-Route value in each iteration of the spiral, locating the correct value in the response (which must be the proper iteration in the reverse direction) is tricky. The rules above recommend that a proxy wishing to rewrite Record-Route header field values insert sufficiently distinct URIs into the Record-Route header field so that the right one may be selected for rewriting. A RECOMMENDED mechanism to achieve this is for the proxy to append a unique identifier for the proxy instance to the user portion of the URI.
プロキシが応答のRecord-Routeヘッダーフィールドを変更することを決定した場合、プロキシが実行する操作の1つは、挿入したRecord-Route値を見つけることです。要求がらせん状になり、プロキシがらせんの各反復にRecord-Route値を挿入した場合、応答で正しい値（逆方向の適切な反復でなければならない）を見つけるのは注意が必要です。上記のルールでは、Record-Routeヘッダーフィールドの値を書き換えたいプロキシが十分に異なるURIをRecord-Routeヘッダーフィールドに挿入して、正しいURIを選択して書き換えることを推奨しています。これを実現するための推奨メカニズムは、プロキシがプロキシインスタンスの一意の識別子をURIのユーザー部分に追加することです。
When the response arrives, the proxy modifies the first Record-Route whose identifier matches the proxy instance. The modification results in a URI without this piece of data appended to the user portion of the URI. Upon the next iteration, the same algorithm (find the topmost Record-Route header field value with the parameter) will correctly extract the next Record-Route header field value inserted by that proxy.
応答が到着すると、プロキシは、識別子がプロキシインスタンスと一致する最初のRecord-Routeを変更します。変更の結果、このデータの一部がURIのユーザー部分に追加されないURIになります。次の反復で、同じアルゴリズム（最上位のRecord-Routeヘッダーフィールド値をパラメーターで見つける）は、そのプロキシーによって挿入された次のRecord-Routeヘッダーフィールド値を正しく抽出します。
Not every response to a request to which a proxy adds a Record-Route header field value will contain a Record-Route header field. If the response does contain a Record-Route header field, it will contain the value the proxy added.
プロキシがRecord-Routeヘッダーフィールド値を追加するリクエストへのすべての応答にRecord-Routeヘッダーフィールドが含まれるわけではありません。応答にRecord-Routeヘッダーフィールドが含まれている場合は、プロキシが追加した値が含まれます。
9. Forward response
9. フォワードレスポンス
After performing the processing described in steps "Aggregate Authorization Header Field Values" through "Record-Route", the proxy MAY perform any feature specific manipulations on the selected response. The proxy MUST NOT add to, modify, or remove the message body. Unless otherwise specified, the proxy MUST NOT remove any header field values other than the Via header field value discussed in Section 16.7 Item 3. In particular, the proxy MUST NOT remove any "received" parameter it may have added to the next Via header field value while processing the request associated with this response. The proxy MUST pass the response to the server transaction associated with the response context. This will result in the response being sent to the location now indicated in the topmost Via header field value. If the server transaction is no longer available to handle the transmission, the element MUST forward the response statelessly by sending it to the server transport. The server transaction might indicate failure to send the response or signal a timeout in its state machine. These errors would be logged for diagnostic purposes as appropriate, but the protocol requires no remedial action from the proxy.
手順「Aggregate Authorization Header Field Values」〜「Record-Route」で説明されている処理を実行した後、プロキシは、選択された応答に対して機能固有の操作を実行できます（MAY）。プロキシは、メッセージ本文を追加、変更、または削除してはなりません（MUST NOT）。特に指定のない限り、プロキシは、セクション16.7の項目3で説明したViaヘッダーフィールド値以外のヘッダーフィールド値を削除してはなりません（MUST NOT）。特に、プロキシは、次のViaヘッダーフィールドに追加した「受信」パラメーターを削除してはなりません（MUST NOT）。この応答に関連付けられたリクエストの処理中の値。プロキシは、応答コンテキストに関連付けられたサーバートランザクションに応答を渡す必要があります。これにより、最上部のViaヘッダーフィールド値で示される場所に応答が送信されます。サーバートランザクションが送信の処理に使用できなくなった場合、要素は応答をサーバートランスポートに送信することにより、ステートレスに応答を転送する必要があります。サーバートランザクションは、状態マシンでの応答の送信またはタイムアウトのシグナル通知の失敗を示している可能性があります。これらのエラーは、診断目的で適切に記録されますが、プロトコルはプロキシからの修正アクションを必要としません。
The proxy MUST maintain the response context until all of its associated transactions have been terminated, even after forwarding a final response.
プロキシは、最終応答を転送した後でも、関連するトランザクションがすべて終了するまで応答コンテキストを維持する必要があります。
10. Generate CANCELs
10. キャンセルを生成
If the forwarded response was a final response, the proxy MUST generate a CANCEL request for all pending client transactions associated with this response context. A proxy SHOULD also generate a CANCEL request for all pending client transactions associated with this response context when it receives a 6xx response. A pending client transaction is one that has received a provisional response, but no final response (it is in the proceeding state) and has not had an associated CANCEL generated for it. Generating CANCEL requests is described in Section 9.1.
転送された応答が最終応答である場合、プロキシは、この応答コンテキストに関連付けられているすべての保留中のクライアントトランザクションに対してCANCEL要求を生成する必要があります。プロキシは、6xx応答を受信したときに、この応答コンテキストに関連付けられているすべての保留中のクライアントトランザクションに対するCANCEL要求も生成する必要があります（SHOULD）。保留中のクライアントトランザクションとは、暫定的な応答を受け取ったが、最終的な応答はなく（進行中の状態）、それに関連付けられたCANCELが生成されていないトランザクションです。 CANCELリクエストの生成については、セクション9.1で説明します。
The requirement to CANCEL pending client transactions upon forwarding a final response does not guarantee that an endpoint will not receive multiple 200 (OK) responses to an INVITE. 200 (OK) responses on more than one branch may be generated before the CANCEL requests can be sent and processed. Further, it is reasonable to expect that a future extension may override this requirement to issue CANCEL requests.
最終応答の転送時に保留中のクライアントトランザクションをキャンセルするという要件は、エンドポイントがINVITEに対する複数の200（OK）応答を受信しないことを保証するものではありません。 CANCEL要求を送信して処理する前に、複数のブランチで200（OK）応答が生成される場合があります。さらに、CANCEL要求を発行するために、将来の拡張機能がこの要件をオーバーライドする可能性があることを期待することは妥当です。
If timer C should fire, the proxy MUST either reset the timer with any value it chooses, or terminate the client transaction. If the client transaction has received a provisional response, the proxy MUST generate a CANCEL request matching that transaction. If the client transaction has not received a provisional response, the proxy MUST behave as if the transaction received a 408 (Request Timeout) response.
タイマーCが起動する場合、プロキシはタイマーを選択した値でリセットするか、クライアントトランザクションを終了する必要があります。クライアントトランザクションが暫定応答を受信した場合、プロキシはそのトランザクションに一致するCANCELリクエストを生成する必要があります。クライアントトランザクションが暫定応答を受信していない場合、プロキシは、トランザクションが408（リクエストタイムアウト）応答を受信したかのように動作する必要があります。
Allowing the proxy to reset the timer allows the proxy to dynamically extend the transaction's lifetime based on current conditions (such as utilization) when the timer fires.
プロキシーがタイマーをリセットできるようにすると、タイマーが起動したときに、プロキシーが現在の状態（使用率など）に基づいてトランザクションの存続時間を動的に延長できるようになります。
If the transport layer notifies a proxy of an error when it tries to forward a request (see Section 18.4), the proxy MUST behave as if the forwarded request received a 503 (Service Unavailable) response.
トランスポート層がリクエストを転送しようとしたときにプロキシのエラーを通知する場合（セクション18.4を参照）、プロキシは転送されたリクエストが503（Service Unavailable）応答を受信したかのように動作する必要があります。
If the proxy is notified of an error when forwarding a response, it drops the response. The proxy SHOULD NOT cancel any outstanding client transactions associated with this response context due to this notification.
応答の転送時にプロキシにエラーが通知されると、応答は破棄されます。プロキシは、この通知が原因で、この応答コンテキストに関連付けられている未解決のクライアントトランザクションをキャンセルしないでください。
If a proxy cancels its outstanding client transactions, a single malicious or misbehaving client can cause all transactions to fail through its Via header field.
プロキシが未処理のクライアントトランザクションをキャンセルすると、単一の悪意のあるクライアントまたは誤動作したクライアントが、Viaヘッダーフィールドを介してすべてのトランザクションを失敗させる可能性があります。
A stateful proxy MAY generate a CANCEL to any other request it has generated at any time (subject to receiving a provisional response to that request as described in section 9.1). A proxy MUST cancel any pending client transactions associated with a response context when it receives a matching CANCEL request.
ステートフルプロキシは、いつでも生成した他のすべての要求に対してCANCELを生成できます（セクション9.1で説明されているように、その要求に対する暫定応答を受信する場合があります）。プロキシは、一致するCANCEL要求を受信したときに、応答コンテキストに関連付けられている保留中のクライアントトランザクションをキャンセルする必要があります。
A stateful proxy MAY generate CANCEL requests for pending INVITE client transactions based on the period specified in the INVITE's Expires header field elapsing. However, this is generally unnecessary since the endpoints involved will take care of signaling the end of the transaction.
ステートフルプロキシは、INVITEのExpiresヘッダーフィールドの経過で指定された期間に基づいて、保留中のINVITEクライアントトランザクションのCANCELリクエストを生成する場合があります。ただし、関連するエンドポイントがトランザクションの終了の信号を処理するため、これは一般に不要です。
While a CANCEL request is handled in a stateful proxy by its own server transaction, a new response context is not created for it. Instead, the proxy layer searches its existing response contexts for the server transaction handling the request associated with this CANCEL. If a matching response context is found, the element MUST immediately return a 200 (OK) response to the CANCEL request. In this case, the element is acting as a user agent server as defined in Section 8.2. Furthermore, the element MUST generate CANCEL requests for all pending client transactions in the context as described in Section 16.7 step 10.
CANCEL要求は、独自のサーバートランザクションによってステートフルプロキシで処理されますが、新しい応答コンテキストは作成されません。代わりに、プロキシ層は既存の応答コンテキストを検索して、このCANCELに関連付けられた要求を処理するサーバートランザクションを探します。一致する応答コンテキストが見つかった場合、要素はCANCELリクエストに対して即座に200（OK）応答を返す必要があります。この場合、要素はセクション8.2で定義されているユーザーエージェントサーバーとして機能しています。さらに、要素は、セクション16.7のステップ10で説明されているように、コンテキスト内のすべての保留中のクライアントトランザクションに対してCANCELリクエストを生成する必要があります。
If a response context is not found, the element does not have any knowledge of the request to apply the CANCEL to. It MUST statelessly forward the CANCEL request (it may have statelessly forwarded the associated request previously).
応答コンテキストが見つからない場合、要素はCANCELを適用する要求を認識していません。 CANCELリクエストをステートレスに転送する必要があります（以前に関連するリクエストをステートレスに転送した可能性があります）。
When acting statelessly, a proxy is a simple message forwarder. Much of the processing performed when acting statelessly is the same as when behaving statefully. The differences are detailed here.
ステートレスに動作する場合、プロキシは単純なメッセージフォワーダーです。ステートレスに動作する場合に実行される処理の多くは、ステートフルに動作する場合と同じです。違いはここで詳しく説明されています。
A stateless proxy does not have any notion of a transaction, or of the response context used to describe stateful proxy behavior. Instead, the stateless proxy takes messages, both requests and responses, directly from the transport layer (See section 18). As a result, stateless proxies do not retransmit messages on their own. They do, however, forward all retransmissions they receive (they do not have the ability to distinguish a retransmission from the original message). Furthermore, when handling a request statelessly, an element MUST NOT generate its own 100 (Trying) or any other provisional response.
ステートレスプロキシには、トランザクションの概念や、ステートフルプロキシの動作を記述するために使用される応答コンテキストの概念はありません。代わりに、ステートレスプロキシは、要求と応答の両方のメッセージをトランスポート層から直接受け取ります（セクション18を参照）。その結果、ステートレスプロキシはそれ自体でメッセージを再送信しません。ただし、受信したすべての再送信は転送されます（再送信と元のメッセージを区別する機能はありません）。さらに、リクエストをステートレスに処理する場合、要素は独自の100（試行中）またはその他の暫定応答を生成してはなりません（MUST NOT）。
A stateless proxy MUST validate a request as described in Section 16.3
ステートレスプロキシは、セクション16.3で説明されているように、リクエストを検証する必要があります。
A stateless proxy MUST follow the request processing steps described in Sections 16.4 through 16.5 with the following exception:
ステートレスプロキシは、次の例外を除き、セクション16.4から16.5で説明されている要求処理手順に従う必要があります。
o A stateless proxy MUST choose one and only one target from the target set. This choice MUST only rely on fields in the message and time-invariant properties of the server. In particular, a retransmitted request MUST be forwarded to the same destination each time it is processed. Furthermore, CANCEL and non-Routed ACK requests MUST generate the same choice as their associated INVITE.
o ステートレスプロキシは、ターゲットセットからターゲットを1つだけ選択する必要があります。この選択は、メッセージのフィールドとサーバーの時間に依存しないプロパティのみに依存する必要があります。特に、再送信された要求は、処理されるたびに同じ宛先に転送される必要があります。さらに、CANCELおよび非ルーティングACKリクエストは、関連するINVITEと同じ選択肢を生成する必要があります。
A stateless proxy MUST follow the request processing steps described in Section 16.6 with the following exceptions:
ステートレスプロキシは、次の例外を除き、セクション16.6で説明されている要求処理手順に従う必要があります。
o The requirement for unique branch IDs across space and time applies to stateless proxies as well. However, a stateless proxy cannot simply use a random number generator to compute the first component of the branch ID, as described in Section 16.6 bullet 8. This is because retransmissions of a request need to have the same value, and a stateless proxy cannot tell a retransmission from the original request. Therefore, the component of the branch parameter that makes it unique MUST be the same each time a retransmitted request is forwarded. Thus for a stateless proxy, the branch parameter MUST be computed as a combinatoric function of message parameters which are invariant on retransmission.
o 空間と時間にまたがる一意のブランチIDの要件は、ステートレスプロキシにも適用されます。ただし、ステートレスプロキシは、セクション16.6の箇条書き8で説明されているように、単に乱数ジェネレータを使用してブランチIDの最初のコンポーネントを計算することはできません。元のリクエストからの再送信。したがって、それを一意にするブランチパラメータのコンポーネントは、再送信されたリクエストが転送されるたびに同じでなければなりません。したがって、ステートレスプロキシの場合、ブランチパラメータは、再送信時に不変であるメッセージパラメータの組み合わせ関数として計算する必要があります。
The stateless proxy MAY use any technique it likes to guarantee uniqueness of its branch IDs across transactions. However, the following procedure is RECOMMENDED. The proxy examines the branch ID in the topmost Via header field of the received request. If it begins with the magic cookie, the first component of the branch ID of the outgoing request is computed as a hash of the received branch ID. Otherwise, the first component of the branch ID is computed as a hash of the topmost Via, the tag in the To header field, the tag in the From header field, the Call-ID header field, the CSeq number (but not method), and the Request-URI from the received request. One of these fields will always vary across two different transactions.
ステートレスプロキシは、トランザクション間でブランチIDの一意性を保証するために、任意の手法を使用できます（MAY）。ただし、次の手順をお勧めします。プロキシは、受信したリクエストの最上位のViaヘッダーフィールドのブランチIDを調べます。マジックCookieで始まる場合、送信要求のブランチIDの最初のコンポーネントは、受信したブランチIDのハッシュとして計算されます。それ以外の場合、ブランチIDの最初のコンポーネントは、最上位のVia、Toヘッダーフィールドのタグ、Fromヘッダーフィールドのタグ、Call-IDヘッダーフィールド、CSeq番号（ただし、メソッドではない）のハッシュとして計算されます。 、および受信したリクエストからのRequest-URI。これらのフィールドの1つは、常に2つの異なるトランザクション間で異なります。
o All other message transformations specified in Section 16.6 MUST result in the same transformation of a retransmitted request. In particular, if the proxy inserts a Record-Route value or pushes URIs into the Route header field, it MUST place the same values in retransmissions of the request. As for the Via branch parameter, this implies that the transformations MUST be based on time-invariant configuration or retransmission-invariant properties of the request.
o セクション16.6で指定された他のすべてのメッセージ変換は、再送信された要求の同じ変換をもたらす必要があります。特に、プロキシがRecord-Route値を挿入するか、URIをルートヘッダーフィールドにプッシュする場合、リクエストの再送信に同じ値を配置する必要があります。 Viaブランチパラメータに関しては、これは変換がリクエストの時間不変構成または再送信不変プロパティに基づく必要があることを意味します。
o A stateless proxy determines where to forward the request as described for stateful proxies in Section 16.6 Item 10. The request is sent directly to the transport layer instead of through a client transaction.
o ステートレスプロキシは、セクション16.6の項目10でステートフルプロキシについて説明したように、要求をどこに転送するかを決定します。要求は、クライアントトランザクションではなく、トランスポート層に直接送信されます。
Since a stateless proxy must forward retransmitted requests to the same destination and add identical branch parameters to each of them, it can only use information from the message itself and time-invariant configuration data for those calculations. If the configuration state is not time-invariant (for example, if a routing table is updated) any requests that could be affected by the change may not be forwarded statelessly during an interval equal to the transaction timeout window before or after the change. The method of processing the affected requests in that interval is an implementation decision. A common solution is to forward them transaction statefully.
ステートレスプロキシは、再送信されたリクエストを同じ宛先に転送し、それぞれに同一のブランチパラメータを追加する必要があるため、メッセージ自体の情報とそれらの計算に時不変の構成データのみを使用できます。構成状態が時不変でない場合（たとえば、ルーティングテーブルが更新された場合）、変更の影響を受ける可能性のある要求は、変更前または変更後のトランザクションタイムアウトウィンドウと等しい間隔でステートレスに転送されない可能性があります。その間隔で影響を受ける要求を処理する方法は、実装の決定です。一般的な解決策は、トランザクションをステートフルに転送することです。
Stateless proxies MUST NOT perform special processing for CANCEL requests. They are processed by the above rules as any other requests. In particular, a stateless proxy applies the same Route header field processing to CANCEL requests that it applies to any other request.
ステートレスプロキシは、CANCELリクエストに対して特別な処理を実行してはなりません。これらは、他の要求と同様に上記のルールによって処理されます。特に、ステートレスプロキシは、他のリクエストに適用するのと同じルートヘッダーフィールド処理をCANCELリクエストに適用します。
Response processing as described in Section 16.7 does not apply to a proxy behaving statelessly. When a response arrives at a stateless proxy, the proxy MUST inspect the sent-by value in the first (topmost) Via header field value. If that address matches the proxy, (it equals a value this proxy has inserted into previous requests) the proxy MUST remove that header field value from the response and forward the result to the location indicated in the next Via header field value. The proxy MUST NOT add to, modify, or remove the message body. Unless specified otherwise, the proxy MUST NOT remove any other header field values. If the address does not match the proxy, the message MUST be silently discarded.
セクション16.7で説明されている応答処理は、ステートレスに動作するプロキシには適用されません。応答がステートレスプロキシに到着すると、プロキシは最初（最上位）のViaヘッダーフィールド値のsent-by値を検査する必要があります。そのアドレスがプロキシと一致する場合（このプロキシが以前の要求に挿入した値と等しい）、プロキシは応答からそのヘッダーフィールド値を削除し、次のViaヘッダーフィールド値で示される場所に結果を転送する必要があります。プロキシは、メッセージ本文を追加、変更、または削除してはなりません（MUST NOT）。特に指定がない限り、プロキシは他のヘッダーフィールド値を削除してはなりません（MUST NOT）。アドレスがプロキシと一致しない場合、メッセージは黙って破棄されなければなりません（MUST）。
In the absence of local policy to the contrary, the processing a proxy performs on a request containing a Route header field can be summarized in the following steps.
反対のローカルポリシーがない場合、ルートヘッダーフィールドを含むリクエストに対してプロキシが実行する処理は、次の手順で要約できます。
1. The proxy will inspect the Request-URI. If it indicates a resource owned by this proxy, the proxy will replace it with the results of running a location service. Otherwise, the proxy will not change the Request-URI.
1. プロキシはRequest-URIを検査します。このプロキシが所有するリソースを示している場合、プロキシはそれを位置情報サービスの実行結果に置き換えます。それ以外の場合、プロキシはRequest-URIを変更しません。
2. The proxy will inspect the URI in the topmost Route header field value. If it indicates this proxy, the proxy removes it from the Route header field (this route node has been reached).
2. プロキシは、最上位のルートヘッダーフィールド値のURIを検査します。このプロキシを示している場合、プロキシはそれをルートヘッダーフィールドから削除します（このルートノードに到達しています）。
3. The proxy will forward the request to the resource indicated by the URI in the topmost Route header field value or in the Request-URI if no Route header field is present. The proxy determines the address, port and transport to use when forwarding the request by applying the procedures in [4] to that URI.
3. プロキシは、最上位のルートヘッダーフィールド値のURI、またはルートヘッダーフィールドが存在しない場合はRequest-URIで指定されたリソースにリクエストを転送します。プロキシは、[4]の手順をそのURIに適用することにより、リクエストを転送するときに使用するアドレス、ポート、トランスポートを決定します。
If no strict-routing elements are encountered on the path of the request, the Request-URI will always indicate the target of the request.
リクエストのパスでストリクトルーティングエレメントが検出されない場合、Request-URIは常にリクエストのターゲットを示します。
This scenario is the basic SIP trapezoid, U1 -> P1 -> P2 -> U2, with both proxies record-routing. Here is the flow.
このシナリオは、両方のプロキシレコードルーティングを持つ基本的なSIP台形、U1-> P1-> P2-> U2です。こちらが流れです。
U1 sends:
U1が送信するもの：
INVITE sip:callee@domain.com SIP/2.0
Contact: sip:caller@u1.example.com
to P1. P1 is an outbound proxy. P1 is not responsible for domain.com, so it looks it up in DNS and sends it there. It also adds a Record-Route header field value:
P1に。 P1は発信プロキシです。 P1はdomain.comを担当しないため、DNSで検索して送信します。また、Record-Routeヘッダーフィールド値を追加します。
INVITE sip:callee@domain.com SIP/2.0
Contact: sip:caller@u1.example.com
Record-Route: <sip:p1.example.com;lr>
P2 gets this. It is responsible for domain.com so it runs a location service and rewrites the Request-URI. It also adds a Record-Route header field value. There is no Route header field, so it resolves the new Request-URI to determine where to send the request:
P2はこれを取得します。これはdomain.comを担当するため、ロケーションサービスを実行し、Request-URIを書き換えます。また、Record-Routeヘッダーフィールド値を追加します。 Routeヘッダーフィールドはないため、新しいRequest-URIを解決して、リクエストの送信先を決定します。
INVITE sip:callee@u2.domain.com SIP/2.0
Contact: sip:caller@u1.example.com
Record-Route: <sip:p2.domain.com;lr>
Record-Route: <sip:p1.example.com;lr>
The callee at u2.domain.com gets this and responds with a 200 OK:
u2.domain.comの呼び出し先がこれを受け取り、200 OKで応答します。
SIP/2.0 200 OK
Contact: sip:callee@u2.domain.com
Record-Route: <sip:p2.domain.com;lr>
Record-Route: <sip:p1.example.com;lr>
The callee at u2 also sets its dialog state's remote target URI to sip:caller@u1.example.com and its route set to:
u2の呼び出し先も、ダイアログステートのリモートターゲットURIをsip：caller@u1.example.comに設定し、ルートを次のように設定します。
(<sip:p2.domain.com;lr>,<sip:p1.example.com;lr>)
This is forwarded by P2 to P1 to U1 as normal. Now, U1 sets its dialog state's remote target URI to sip:callee@u2.domain.com and its route set to:
これは、通常どおりP2からP1からU1に転送されます。これで、U1はダイアログ状態のリモートターゲットURIをsip：callee@u2.domain.comに設定し、ルートを次のように設定します。
(<sip:p1.example.com;lr>,<sip:p2.domain.com;lr>)
Since all the route set elements contain the lr parameter, U1 constructs the following BYE request:
すべてのルートセット要素にlrパラメータが含まれているため、U1は次のBYEリクエストを作成します。
BYE sip:callee@u2.domain.com SIP/2.0
Route: <sip:p1.example.com;lr>,<sip:p2.domain.com;lr>
As any other element (including proxies) would do, it resolves the URI in the topmost Route header field value using DNS to determine where to send the request. This goes to P1. P1 notices that it is not responsible for the resource indicated in the Request-URI so it doesn't change it. It does see that it is the first value in the Route header field, so it removes that value, and forwards the request to P2:
他の要素（プロキシを含む）と同じように、DNSを使用して最上位のルートヘッダーフィールド値のURIを解決し、リクエストの送信先を決定します。これはP1に行きます。 P1は、Request-URIで示されたリソースを担当しないため、リソースを変更しないことに注意します。 Routeヘッダーフィールドの最初の値であることを確認しているため、その値を削除し、リクエストをP2に転送します。
BYE sip:callee@u2.domain.com SIP/2.0
Route: <sip:p2.domain.com;lr>
P2 also notices it is not responsible for the resource indicated by the Request-URI (it is responsible for domain.com, not u2.domain.com), so it doesn't change it. It does see itself in the first Route header field value, so it removes it and forwards the following to u2.domain.com based on a DNS lookup against the Request-URI:
また、P2は、Request-URIによって示されるリソースには責任がない（u2.domain.comではなくdomain.comに責任がある）ことにも気づくため、変更しません。最初のルートヘッダーフィールドの値には自分自身が含まれているため、それを削除し、Request-URIに対するDNSルックアップに基づいて、次のものをu2.domain.comに転送します。
BYE sip:callee@u2.domain.com SIP/2.0
In this scenario, a dialog is established across four proxies, each of which adds Record-Route header field values. The third proxy implements the strict-routing procedures specified in RFC 2543 and many works in progress.
このシナリオでは、ダイアログが4つのプロキシにわたって確立され、それぞれがRecord-Routeヘッダーフィールド値を追加します。 3番目のプロキシは、RFC 2543で指定されている厳密なルーティング手順を実装しており、多くの作業が進行中です。
U1->P1->P2->P3->P4->U2
The INVITE arriving at U2 contains:
U2に到着するINVITEには以下が含まれます。
INVITE sip:callee@u2.domain.com SIP/2.0
Contact: sip:caller@u1.example.com
Record-Route: <sip:p4.domain.com;lr>
Record-Route: <sip:p3.middle.com>
Record-Route: <sip:p2.example.com;lr>
Record-Route: <sip:p1.example.com;lr>
Which U2 responds to with a 200 OK. Later, U2 sends the following BYE request to P4 based on the first Route header field value.
どのU2が200 OKで応答するか。その後、U2は最初のルートヘッダーフィールド値に基づいて、次のBYEリクエストをP4に送信します。
BYE sip:caller@u1.example.com SIP/2.0
Route: <sip:p4.domain.com;lr>
Route: <sip:p3.middle.com>
Route: <sip:p2.example.com;lr>
Route: <sip:p1.example.com;lr>
P4 is not responsible for the resource indicated in the Request-URI so it will leave it alone. It notices that it is the element in the first Route header field value so it removes it. It then prepares to send the request based on the now first Route header field value of sip:p3.middle.com, but it notices that this URI does not contain the lr parameter, so before sending, it reformats the request to be:
P4はRequest-URIで示されるリソースに責任を負わないため、そのままにします。最初のルートヘッダーフィールド値の要素であることを認識し、それを削除します。次に、sip：p3.middle.comの最初のルートヘッダーフィールド値に基づいて要求を送信する準備をしますが、このURIにlrパラメータが含まれていないことに気づくため、送信する前に、要求を次のように再フォーマットします。
BYE sip:p3.middle.com SIP/2.0
Route: <sip:p2.example.com;lr>
Route: <sip:p1.example.com;lr>
Route: <sip:caller@u1.example.com>
P3 is a strict router, so it forwards the following to P2:
P3は厳密なルーターであるため、次のものをP2に転送します。
BYE sip:p2.example.com;lr SIP/2.0
Route: <sip:p1.example.com;lr>
Route: <sip:caller@u1.example.com>
P2 sees the request-URI is a value it placed into a Record-Route header field, so before further processing, it rewrites the request to be:
P2は、request-URIがRecord-Routeヘッダーフィールドに配置された値であることを確認するため、さらに処理する前に、要求を次のように書き換えます。
BYE sip:caller@u1.example.com SIP/2.0
Route: <sip:p1.example.com;lr>
P2 is not responsible for u1.example.com, so it sends the request to P1 based on the resolution of the Route header field value.
P2はu1.example.comを担当しないため、ルートヘッダーフィールド値の解決に基づいて要求をP1に送信します。
P1 notices itself in the topmost Route header field value, so it removes it, resulting in:
P1は最上位のルートヘッダーフィールド値に自分自身を認識しているため、それを削除し、次のようになります。
BYE sip:caller@u1.example.com SIP/2.0
Since P1 is not responsible for u1.example.com and there is no Route header field, P1 will forward the request to u1.example.com based on the Request-URI.
P1はu1.example.comを担当せず、ルートヘッダーフィールドがないため、P1はRequest-URIに基づいてリクエストをu1.example.comに転送します。
In this scenario, U1 and U2 are in different private namespaces and they enter a dialog through a proxy P1, which acts as a gateway between the namespaces.
このシナリオでは、U1とU2は異なるプライベート名前空間にあり、名前空間間のゲートウェイとして機能するプロキシP1を介してダイアログに入ります。
U1->P1->U2
U1-> P1-> U2
U1 sends:
U1が送信するもの：
INVITE sip:callee@gateway.leftprivatespace.com SIP/2.0
Contact: <sip:caller@u1.leftprivatespace.com>
P1 uses its location service and sends the following to U2:
P1はそのロケーションサービスを使用して、次のものをU2に送信します。
INVITE sip:callee@rightprivatespace.com SIP/2.0
Contact: <sip:caller@u1.leftprivatespace.com>
Record-Route: <sip:gateway.rightprivatespace.com;lr>
U2 sends this 200 (OK) back to P1:
U2はこの200（OK）をP1に送り返します。
SIP/2.0 200 OK
Contact: <sip:callee@u2.rightprivatespace.com>
Record-Route: <sip:gateway.rightprivatespace.com;lr>
P1 rewrites its Record-Route header parameter to provide a value that U1 will find useful, and sends the following to U1:
P1は、そのRecord-Routeヘッダーパラメーターを書き換えて、U1が役立つと思われる値を提供し、以下をU1に送信します。
SIP/2.0 200 OK
Contact: <sip:callee@u2.rightprivatespace.com>
Record-Route: <sip:gateway.leftprivatespace.com;lr>
Later, U1 sends the following BYE request to P1:
その後、U1は次のBYEリクエストをP1に送信します。
BYE sip:callee@u2.rightprivatespace.com SIP/2.0
Route: <sip:gateway.leftprivatespace.com;lr>
which P1 forwards to U2 as:
P1は次のようにU2に転送します。
BYE sip:callee@u2.rightprivatespace.com SIP/2.0
17 Transactions
17トランザクション
SIP is a transactional protocol: interactions between components take place in a series of independent message exchanges. Specifically, a SIP transaction consists of a single request and any responses to that request, which include zero or more provisional responses and one or more final responses. In the case of a transaction where the request was an INVITE (known as an INVITE transaction), the transaction also includes the ACK only if the final response was not a 2xx response. If the response was a 2xx, the ACK is not considered part of the transaction.
SIPはトランザクションプロトコルです。コンポーネント間の対話は、一連の独立したメッセージ交換で行われます。具体的には、SIPトランザクションは、単一の要求とその要求に対する応答で構成されます。これには、0個以上の暫定応答と1つ以上の最終応答が含まれます。要求がINVITEであるトランザクション（INVITEトランザクションと呼ばれる）の場合、トランザクションには、最終応答が2xx応答でない場合にのみACKも含まれます。応答が2xxの場合、ACKはトランザクションの一部とは見なされません。
The reason for this separation is rooted in the importance of delivering all 200 (OK) responses to an INVITE to the UAC. To deliver them all to the UAC, the UAS alone takes responsibility for retransmitting them (see Section 13.3.1.4), and the UAC alone takes responsibility for acknowledging them with ACK (see Section 13.2.2.4). Since this ACK is retransmitted only by the UAC, it is effectively considered its own transaction.
この分離の理由は、INVITEへの200（OK）応答すべてをUACに配信することの重要性にあります。それらすべてをUACに配信するために、UASのみが再送信を担当し（セクション13.3.1.4を参照）、UACのみがそれらをACKで確認する責任を負います（セクション13.2.2.4を参照）。このACKはUACによってのみ再送信されるため、実質的に独自のトランザクションと見なされます。
Transactions have a client side and a server side. The client side is known as a client transaction and the server side as a server transaction. The client transaction sends the request, and the server transaction sends the response. The client and server transactions are logical functions that are embedded in any number of elements. Specifically, they exist within user agents and stateful proxy servers. Consider the example in Section 4. In this example, the UAC executes the client transaction, and its outbound proxy executes the server transaction. The outbound proxy also executes a client transaction, which sends the request to a server transaction in the inbound proxy. That proxy also executes a client transaction, which in turn sends the request to a server transaction in the UAS. This is shown in Figure 4.
トランザクションには、クライアント側とサーバー側があります。クライアント側はクライアントトランザクションと呼ばれ、サーバー側はサーバートランザクションと呼ばれます。クライアントトランザクションが要求を送信し、サーバートランザクションが応答を送信します。クライアントとサーバーのトランザクションは、任意の数の要素に埋め込まれた論理関数です。具体的には、ユーザーエージェントとステートフルプロキシサーバー内に存在します。セクション4の例を検討してください。この例では、UACがクライアントトランザクションを実行し、そのアウトバウンドプロキシがサーバートランザクションを実行します。アウトバウンドプロキシは、クライアントトランザクションも実行します。クライアントトランザクションは、インバウンドプロキシのサーバートランザクションに要求を送信します。そのプロキシは、クライアントトランザクションも実行します。クライアントトランザクションは、UASのサーバートランザクションに要求を送信します。これを図4に示します。
+---------+ +---------+ +---------+ +---------+
| +-+|Request |+-+ +-+|Request |+-+ +-+|Request |+-+ |
| |C||------->||S| |C||------->||S| |C||------->||S| |
| |l|| ||e| |l|| ||e| |l|| ||e| |
| |i|| ||r| |i|| ||r| |i|| ||r| |
| |e|| ||v| |e|| ||v| |e|| ||v| |
| |n|| ||e| |n|| ||e| |n|| ||e| |
| |t|| ||r| |t|| ||r| |t|| ||r| |
| | || || | | || || | | || || | |
| |T|| ||T| |T|| ||T| |T|| ||T| |
| |r|| ||r| |r|| ||r| |r|| ||r| |
| |a|| ||a| |a|| ||a| |a|| ||a| |
| |n|| ||n| |n|| ||n| |n|| ||n| |
| |s||Response||s| |s||Response||s| |s||Response||s| |
| +-+|<-------|+-+ +-+|<-------|+-+ +-+|<-------|+-+ |
+---------+ +---------+ +---------+ +---------+
UAC Outbound Inbound UAS
Proxy Proxy
Figure 4: Transaction relationships
図4：トランザクションの関係
A stateless proxy does not contain a client or server transaction. The transaction exists between the UA or stateful proxy on one side, and the UA or stateful proxy on the other side. As far as SIP transactions are concerned, stateless proxies are effectively transparent. The purpose of the client transaction is to receive a request from the element in which the client is embedded (call this element the "Transaction User" or TU; it can be a UA or a stateful proxy), and reliably deliver the request to a server transaction.
ステートレスプロキシには、クライアントまたはサーバートランザクションは含まれません。トランザクションは、一方のUAまたはステートフルプロキシともう一方のUAまたはステートフルプロキシの間に存在します。 SIPトランザクションに関する限り、ステートレスプロキシは事実上透過的です。クライアントトランザクションの目的は、クライアントが埋め込まれている要素から要求を受け取り（この要素を「トランザクションユーザー」またはTUと呼びます。これはUAまたはステートフルプロキシの場合があります）、要求を確実にサーバートランザクション。
The client transaction is also responsible for receiving responses and delivering them to the TU, filtering out any response retransmissions or disallowed responses (such as a response to ACK). Additionally, in the case of an INVITE request, the client transaction is responsible for generating the ACK request for any final response accepting a 2xx response.
クライアントトランザクションは、応答の受信とTUへの配信も担当し、応答の再送信または許可されていない応答（ACKへの応答など）を除外します。さらに、INVITE要求の場合、クライアントトランザクションは、2xx応答を受け入れる最終応答に対するACK要求の生成を担当します。
Similarly, the purpose of the server transaction is to receive requests from the transport layer and deliver them to the TU. The server transaction filters any request retransmissions from the network. The server transaction accepts responses from the TU and delivers them to the transport layer for transmission over the network. In the case of an INVITE transaction, it absorbs the ACK request for any final response excepting a 2xx response.
同様に、サーバートランザクションの目的は、トランスポート層から要求を受信し、それらをTUに配信することです。サーバートランザクションは、ネットワークからのリクエストの再送信をフィルタリングします。サーバートランザクションは、TUからの応答を受け入れ、ネットワーク経由で送信するためにトランスポート層に配信します。 INVITEトランザクションの場合、2xx応答を除くすべての最終応答のACK要求を吸収します。
The 2xx response and its ACK receive special treatment. This response is retransmitted only by a UAS, and its ACK generated only by the UAC. This end-to-end treatment is needed so that a caller knows the entire set of users that have accepted the call. Because of this special handling, retransmissions of the 2xx response are handled by the UA core, not the transaction layer. Similarly, generation of the ACK for the 2xx is handled by the UA core. Each proxy along the path merely forwards each 2xx response to INVITE and its corresponding ACK.
2xx応答とそのACKは特別な扱いを受けます。この応答はUASによってのみ再送信され、そのACKはUACによってのみ生成されます。このエンドツーエンドの処理は、発信者が通話を受け入れたユーザーのセット全体を知るために必要です。この特別な処理のため、2xx応答の再送信は、トランザクションレイヤーではなくUAコアによって処理されます。同様に、2xxのACKの生成は、UAコアによって処理されます。パス上の各プロキシは、各2xx応答をINVITEおよび対応するACKに転送するだけです。
The client transaction provides its functionality through the maintenance of a state machine.
クライアントトランザクションは、ステートマシンのメンテナンスを通じて機能を提供します。
The TU communicates with the client transaction through a simple interface. When the TU wishes to initiate a new transaction, it creates a client transaction and passes it the SIP request to send and an IP address, port, and transport to which to send it. The client transaction begins execution of its state machine. Valid responses are passed up to the TU from the client transaction.
TUは、シンプルなインターフェースを介してクライアントトランザクションと通信します。 TUが新しいトランザクションを開始する場合、クライアントトランザクションを作成し、送信するSIPリクエストと、送信先のIPアドレス、ポート、トランスポートを渡します。クライアントトランザクションは、ステートマシンの実行を開始します。有効な応答は、クライアントトランザクションからTUに渡されます。
There are two types of client transaction state machines, depending on the method of the request passed by the TU. One handles client transactions for INVITE requests. This type of machine is referred to as an INVITE client transaction. Another type handles client transactions for all requests except INVITE and ACK. This is referred to as a non-INVITE client transaction. There is no client transaction for ACK. If the TU wishes to send an ACK, it passes one directly to the transport layer for transmission.
TUから渡される要求の方法に応じて、クライアントトランザクションステートマシンには2つのタイプがあります。 1つは、INVITE要求のクライアントトランザクションを処理します。このタイプのマシンは、INVITEクライアントトランザクションと呼ばれます。別のタイプは、INVITEとACKを除くすべての要求のクライアントトランザクションを処理します。これは、非INVITEクライアントトランザクションと呼ばれます。 ACKのクライアントトランザクションはありません。 TUがACKを送信したい場合は、トランスポート層に直接送信して送信します。
The INVITE transaction is different from those of other methods because of its extended duration. Normally, human input is required in order to respond to an INVITE. The long delays expected for sending a response argue for a three-way handshake. On the other hand, requests of other methods are expected to complete rapidly. Because of the non-INVITE transaction's reliance on a two-way handshake, TUs SHOULD respond immediately to non-INVITE requests.
INVITEトランザクションは、期間が長いため、他の方法のトランザクションとは異なります。通常、INVITEに応答するには、人の入力が必要です。応答の送信に予想される長い遅延は、スリーウェイハンドシェイクを主張しています。一方、他の方法のリクエストは迅速に完了すると予想されます。非INVITEトランザクションは双方向ハンドシェイクに依存しているため、TUは非INVITEリクエストにすぐに応答する必要があります（SHOULD）。
The INVITE transaction consists of a three-way handshake. The client transaction sends an INVITE, the server transaction sends responses, and the client transaction sends an ACK. For unreliable transports (such as UDP), the client transaction retransmits requests at an interval that starts at T1 seconds and doubles after every retransmission. T1 is an estimate of the round-trip time (RTT), and it defaults to 500 ms. Nearly all of the transaction timers described here scale with T1, and changing T1 adjusts their values. The request is not retransmitted over reliable transports. After receiving a 1xx response, any retransmissions cease altogether, and the client waits for further responses. The server transaction can send additional 1xx responses, which are not transmitted reliably by the server transaction. Eventually, the server transaction decides to send a final response. For unreliable transports, that response is retransmitted periodically, and for reliable transports, it is sent once. For each final response that is received at the client transaction, the client transaction sends an ACK, the purpose of which is to quench retransmissions of the response.
INVITEトランザクションは、3ウェイハンドシェイクで構成されています。クライアントトランザクションはINVITEを送信し、サーバートランザクションは応答を送信し、クライアントトランザクションはACKを送信します。信頼性の低いトランスポート（UDPなど）の場合、クライアントトランザクションはT1秒から始まり、再送信ごとに2倍の間隔で要求を再送信します。 T1は往復時間（RTT）の推定値であり、デフォルトは500ミリ秒です。ここで説明するほぼすべてのトランザクションタイマーはT1に対応しており、T1を変更すると値が調整されます。要求は信頼できるトランスポートを介して再送信されません。 1xx応答を受信した後、再送信はすべて中止され、クライアントはさらに応答を待ちます。サーバートランザクションは、サーバートランザクションによって確実に送信されない追加の1xx応答を送信できます。最終的に、サーバートランザクションは最終応答を送信することを決定します。信頼できないトランスポートの場合、その応答は定期的に再送信され、信頼できるトランスポートの場合は1回送信されます。クライアントトランザクションで受信される最終応答ごとに、クライアントトランザクションはACKを送信します。ACKの目的は、応答の再送信を抑制することです。
The state machine for the INVITE client transaction is shown in Figure 5. The initial state, "calling", MUST be entered when the TU initiates a new client transaction with an INVITE request. The client transaction MUST pass the request to the transport layer for transmission (see Section 18). If an unreliable transport is being used, the client transaction MUST start timer A with a value of T1. If a reliable transport is being used, the client transaction SHOULD NOT start timer A (Timer A controls request retransmissions). For any transport, the client transaction MUST start timer B with a value of 64*T1 seconds (Timer B controls transaction timeouts).
INVITEクライアントトランザクションのステートマシンを図5に示します。TUがINVITE要求で新しいクライアントトランザクションを開始すると、初期状態の「呼び出し中」に入る必要があります。クライアントトランザクションは、送信のためにトランスポート層にリクエストを渡さなければなりません（セクション18を参照）。信頼できないトランスポートが使用されている場合、クライアントトランザクションはT1の値でタイマーAを開始する必要があります。信頼性の高いトランスポートが使用されている場合、クライアントトランザクションはタイマーAを開始しないでください（タイマーAはリクエストの再送信を制御します）。どのトランスポートでも、クライアントトランザクションは64 * T1秒の値でタイマーBを開始する必要があります（タイマーBはトランザクションのタイムアウトを制御します）。
When timer A fires, the client transaction MUST retransmit the request by passing it to the transport layer, and MUST reset the timer with a value of 2*T1. The formal definition of retransmit within the context of the transaction layer is to take the message previously sent to the transport layer and pass it to the transport layer once more.
タイマーAが起動すると、クライアントトランザクションは要求をトランスポート層に渡して再送信する必要があり、2 * T1の値でタイマーをリセットする必要があります。トランザクション層のコンテキスト内での再送信の正式な定義は、以前にトランスポート層に送信されたメッセージを取得して、もう一度トランスポート層に渡すことです。
When timer A fires 2*T1 seconds later, the request MUST be retransmitted again (assuming the client transaction is still in this state). This process MUST continue so that the request is retransmitted with intervals that double after each transmission. These retransmissions SHOULD only be done while the client transaction is in the "calling" state.
タイマーAが2 * T1秒後に起動すると、要求は再度再送信されなければなりません（クライアントトランザクションがまだこの状態にあると想定）。このプロセスは継続する必要があるため、各送信後に2倍の間隔でリクエストが再送信されます。これらの再送信は、クライアントトランザクションが「呼び出し中」の状態にあるときにのみ行う必要があります。
The default value for T1 is 500 ms. T1 is an estimate of the RTT between the client and server transactions. Elements MAY (though it is NOT RECOMMENDED) use smaller values of T1 within closed, private networks that do not permit general Internet connection. T1 MAY be chosen larger, and this is RECOMMENDED if it is known in advance (such as on high latency access links) that the RTT is larger. Whatever the value of T1, the exponential backoffs on retransmissions described in this section MUST be used.
T1のデフォルト値は500ミリ秒です。 T1は、クライアントとサーバーのトランザクション間のRTTの見積もりです。エレメントは（推奨されていませんが）、一般的なインターネット接続を許可しない閉じたプライベートネットワーク内でT1のより小さい値を使用できます（MAY）。 T1はより大きく選択される場合があり、RTTがより大きいことが事前に（高レイテンシアクセスリンクなどで）わかっている場合は、これをお勧めします。 T1の値が何であれ、このセクションで説明されている再送信の指数バックオフを使用する必要があります。
If the client transaction is still in the "Calling" state when timer B fires, the client transaction SHOULD inform the TU that a timeout has occurred. The client transaction MUST NOT generate an ACK. The value of 64*T1 is equal to the amount of time required to send seven requests in the case of an unreliable transport.
タイマーBが起動したときにクライアントトランザクションがまだ「呼び出し中」状態である場合、クライアントトランザクションは、タイムアウトが発生したことをTUに通知する必要があります（SHOULD）。クライアントトランザクションはACKを生成してはなりません（MUST NOT）。 64 * T1の値は、トランスポートの信頼性が低い場合に7つの要求を送信するのに必要な時間と同じです。
If the client transaction receives a provisional response while in the "Calling" state, it transitions to the "Proceeding" state. In the "Proceeding" state, the client transaction SHOULD NOT retransmit the request any longer. Furthermore, the provisional response MUST be passed to the TU. Any further provisional responses MUST be passed up to the TU while in the "Proceeding" state.
「呼び出し中」状態のときにクライアントトランザクションが暫定応答を受信すると、「処理中」状態に遷移します。 "Proceeding"状態では、クライアントトランザクションはリクエストを再送すべきではありません（SHOULD NOT）。さらに、暫定応答をTUに渡す必要があります。それ以上の暫定応答は、「Proceeding」状態の間にTUに渡されなければなりません（MUST）。
When in either the "Calling" or "Proceeding" states, reception of a response with status code from 300-699 MUST cause the client transaction to transition to "Completed". The client transaction MUST pass the received response up to the TU, and the client transaction MUST generate an ACK request, even if the transport is reliable (guidelines for constructing the ACK from the response are given in Section 17.1.1.3) and then pass the ACK to the transport layer for transmission. The ACK MUST be sent to the same address, port, and transport to which the original request was sent. The client transaction SHOULD start timer D when it enters the "Completed" state, with a value of at least 32 seconds for unreliable transports, and a value of zero seconds for reliable transports. Timer D reflects the amount of time that the server transaction can remain in the "Completed" state when unreliable transports are used. This is equal to Timer H in the INVITE server transaction, whose default is 64*T1. However, the client transaction does not know the value of T1 in use by the server transaction, so an absolute minimum of 32s is used instead of basing Timer D on T1.
「呼び出し中」または「処理中」のいずれかの状態の場合、ステータスコード300-699の応答を受信すると、クライアントトランザクションが「完了」に遷移する必要があります。トランスポートが信頼できる場合でも、クライアントトランザクションは受信した応答をTUまで渡す必要があり、クライアントトランザクションはACK要求を生成する必要があります（応答からACKを作成するためのガイドラインはセクション17.1.1.3に記載されています）。送信のためのトランスポート層へのACK。 ACKは、元の要求が送信されたのと同じアドレス、ポート、およびトランスポートに送信する必要があります。クライアントトランザクションは、「完了」状態になるとタイマーDを開始する必要があります（SHOULD）。信頼できないトランスポートの場合は少なくとも32秒の値、信頼できるトランスポートの場合は0秒の値を使用します。タイマーDは、信頼性の低いトランスポートが使用されている場合にサーバートランザクションが「完了」状態のままでいられる時間を反映しています。これは、INVITEサーバートランザクションのタイマーHに等しく、デフォルトは64 * T1です。ただし、クライアントトランザクションは、サーバートランザクションが使用しているT1の値を認識しないため、T1に基づいてタイマーDを使用する代わりに、最低でも32秒が使用されます。
Any retransmissions of the final response that are received while in the "Completed" state MUST cause the ACK to be re-passed to the transport layer for retransmission, but the newly received response MUST NOT be passed up to the TU. A retransmission of the response is defined as any response which would match the same client transaction based on the rules of Section 17.1.3.
「完了」状態の間に受信された最終応答の再送信では、ACKが再送信のためにトランスポート層に再渡される必要がありますが、新しく受信された応答はTUに渡してはなりません。応答の再送信は、セクション17.1.3のルールに基づいて同じクライアントトランザクションと一致する応答として定義されます。
|INVITE from TU
Timer A fires |INVITE sent
Reset A, V Timer B fires
INVITE sent +-----------+ or Transport Err.
+---------| |---------------+inform TU
| | Calling | |
+-------->| |-------------->|
+-----------+ 2xx |
| | 2xx to TU |
| |1xx |
300-699 +---------------+ |1xx to TU |
ACK sent | | |
resp. to TU | 1xx V |
| 1xx to TU -----------+ |
| +---------| | |
| | |Proceeding |-------------->|
| +-------->| | 2xx |
| +-----------+ 2xx to TU |
| 300-699 | |
| ACK sent, | |
| resp. to TU| |
| | | NOTE:
| 300-699 V |
| ACK sent +-----------+Transport Err. | transitions
| +---------| |Inform TU | labeled with
| | | Completed |-------------->| the event
| +-------->| | | over the action
| +-----------+ | to take
| ^ | |
| | | Timer D fires |
+--------------+ | - |
| |
V |
+-----------+ |
| | |
| Terminated|<--------------+
| |
+-----------+
Figure 5: INVITE client transaction
図5：INVITEクライアントトランザクション
If timer D fires while the client transaction is in the "Completed" state, the client transaction MUST move to the terminated state.
クライアントトランザクションが「完了」状態のときにタイマーDが発生した場合、クライアントトランザクションは終了状態に移行する必要があります。
When in either the "Calling" or "Proceeding" states, reception of a 2xx response MUST cause the client transaction to enter the "Terminated" state, and the response MUST be passed up to the TU. The handling of this response depends on whether the TU is a proxy core or a UAC core. A UAC core will handle generation of the ACK for this response, while a proxy core will always forward the 200 (OK) upstream. The differing treatment of 200 (OK) between proxy and UAC is the reason that handling of it does not take place in the transaction layer.
「Calling」または「Proceeding」状態の場合、2xx応答を受信すると、クライアントトランザクションが「Terminated」状態になり、応答がTUに渡される必要があります。この応答の処理は、TUがプロキシコアかUACコアかによって異なります。 UACコアはこの応答のACKの生成を処理しますが、プロキシコアは常に200（OK）アップストリームを転送します。プロキシとUACで200（OK）の扱いが異なるため、トランザクション層で処理されないのです。
The client transaction MUST be destroyed the instant it enters the "Terminated" state. This is actually necessary to guarantee correct operation. The reason is that 2xx responses to an INVITE are treated differently; each one is forwarded by proxies, and the ACK handling in a UAC is different. Thus, each 2xx needs to be passed to a proxy core (so that it can be forwarded) and to a UAC core (so it can be acknowledged). No transaction layer processing takes place. Whenever a response is received by the transport, if the transport layer finds no matching client transaction (using the rules of Section 17.1.3), the response is passed directly to the core. Since the matching client transaction is destroyed by the first 2xx, subsequent 2xx will find no match and therefore be passed to the core.
クライアントトランザクションは、「終了」状態になった瞬間に破棄する必要があります。これは実際に正しい動作を保証するために必要です。その理由は、INVITEに対する2xx応答の扱いが異なるためです。それぞれがプロキシによって転送され、UACでのACK処理は異なります。したがって、各2xxは（転送できるように）プロキシコアとUACコア（確認できるように）に渡す必要があります。トランザクション層の処理は行われません。トランスポートが応答を受信するたびに、トランスポート層が一致するクライアントトランザクションを検出しない場合（セクション17.1.3のルールを使用）、応答はコアに直接渡されます。一致するクライアントトランザクションは最初の2xxによって破棄されるため、後続の2xxでは一致が見つからないため、コアに渡されます。
This section specifies the construction of ACK requests sent within the client transaction. A UAC core that generates an ACK for 2xx MUST instead follow the rules described in Section 13.
このセクションでは、クライアントトランザクション内で送信されるACK要求の構成を指定します。 2xxのACKを生成するUACコアは、セクション13で説明されているルールに従う必要があります。
The ACK request constructed by the client transaction MUST contain values for the Call-ID, From, and Request-URI that are equal to the values of those header fields in the request passed to the transport by the client transaction (call this the "original request"). The To header field in the ACK MUST equal the To header field in the response being acknowledged, and therefore will usually differ from the To header field in the original request by the addition of the tag parameter. The ACK MUST contain a single Via header field, and this MUST be equal to the top Via header field of the original request. The CSeq header field in the ACK MUST contain the same value for the sequence number as was present in the original request, but the method parameter MUST be equal to "ACK".
クライアントトランザクションによって構築されたACK要求には、クライアントトランザクションによってトランスポートに渡された要求内のヘッダーフィールドの値と等しいCall-ID、From、およびRequest-URIの値が含まれている必要があります（これを「元のリクエスト"）。 ACKのToヘッダーフィールドは、確認応答のToヘッダーフィールドと等しい必要があるため、通常、タグパラメータの追加によって元のリクエストのToヘッダーフィールドとは異なります。 ACKには単一のViaヘッダーフィールドが含まれている必要があり、これは元の要求の最上位のViaヘッダーフィールドと等しい必要があります。 ACKのCSeqヘッダーフィールドには、元のリクエストに存在していたのと同じシーケンス番号の値が含まれている必要がありますが、メソッドパラメータは「ACK」に等しい必要があります。
If the INVITE request whose response is being acknowledged had Route header fields, those header fields MUST appear in the ACK. This is to ensure that the ACK can be routed properly through any downstream stateless proxies.
応答が確認されているINVITE要求にルートヘッダーフィールドがあった場合、それらのヘッダーフィールドはACKに表示される必要があります。これは、ダウンストリームのステートレスプロキシを介してACKを適切にルーティングできるようにするためです。
Although any request MAY contain a body, a body in an ACK is special since the request cannot be rejected if the body is not understood. Therefore, placement of bodies in ACK for non-2xx is NOT RECOMMENDED, but if done, the body types are restricted to any that appeared in the INVITE, assuming that the response to the INVITE was not 415. If it was, the body in the ACK MAY be any type listed in the Accept header field in the 415.
リクエストにはボディが含まれる場合がありますが、ボディが理解されていないとリクエストを拒否できないため、ACKのボディは特別です。したがって、2xx以外のACKでの本文の配置は推奨されませんが、実行すると、INVITEへの応答が415でないと想定して、本文のタイプはINVITEに表示されたものに制限されます。 ACKは、415のAcceptヘッダーフィールドにリストされているどのタイプでもかまいません。
For example, consider the following request:
たとえば、次のリクエストについて考えてみます。
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=88sja8x
Max-Forwards: 70
Call-ID: 987asjd97y7atg
CSeq: 986759 INVITE
The ACK request for a non-2xx final response to this request would look like this:
この要求に対する2xx以外の最終応答のACK要求は、次のようになります。
ACK sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff
To: Bob <sip:bob@biloxi.com>;tag=99sa0xk
From: Alice <sip:alice@atlanta.com>;tag=88sja8x
Max-Forwards: 70
Call-ID: 987asjd97y7atg
CSeq: 986759 ACK
Non-INVITE transactions do not make use of ACK. They are simple request-response interactions. For unreliable transports, requests are retransmitted at an interval which starts at T1 and doubles until it hits T2. If a provisional response is received, retransmissions continue for unreliable transports, but at an interval of T2. The server transaction retransmits the last response it sent, which can be a provisional or final response, only when a retransmission of the request is received. This is why request retransmissions need to continue even after a provisional response; they are to ensure reliable delivery of the final response.
INVITE以外のトランザクションはACKを使用しません。これらは単純な要求と応答の相互作用です。信頼性の低いトランスポートの場合、要求はT1から始まり、T2に到達するまで倍増する間隔で再送信されます。暫定応答を受信した場合、信頼性のないトランスポートの再送信は続行されますが、T2の間隔で行われます。サーバートランザクションは、リクエストの再送信を受信した場合にのみ、送信した最後の応答（暫定または最終応答）を再送信します。これが、仮の応答の後でもリクエストの再送信を継続する必要がある理由です。最終的な応答を確実に配信するためのものです。
Unlike an INVITE transaction, a non-INVITE transaction has no special handling for the 2xx response. The result is that only a single 2xx response to a non-INVITE is ever delivered to a UAC.
INVITEトランザクションとは異なり、非INVITEトランザクションには2xx応答に対する特別な処理はありません。その結果、非INVITEに対する単一の2xx応答のみがUACに配信されます。
The state machine for the non-INVITE client transaction is shown in Figure 6. It is very similar to the state machine for INVITE.
非INVITEクライアントトランザクションの状態マシンを図6に示します。これは、INVITEの状態マシンと非常によく似ています。
The "Trying" state is entered when the TU initiates a new client transaction with a request. When entering this state, the client transaction SHOULD set timer F to fire in 64*T1 seconds. The request MUST be passed to the transport layer for transmission. If an unreliable transport is in use, the client transaction MUST set timer E to fire in T1 seconds. If timer E fires while still in this state, the timer is reset, but this time with a value of MIN(2*T1, T2). When the timer fires again, it is reset to a MIN(4*T1, T2). This process continues so that retransmissions occur with an exponentially increasing interval that caps at T2. The default value of T2 is 4s, and it represents the amount of time a non-INVITE server transaction will take to respond to a request, if it does not respond immediately. For the default values of T1 and T2, this results in intervals of 500 ms, 1 s, 2 s, 4 s, 4 s, 4 s, etc.
TUが要求を使用して新しいクライアントトランザクションを開始すると、「試行中」状態になります。この状態に入るとき、クライアントトランザクションはタイマーFを64 * T1秒で起動するように設定する必要があります（SHOULD）。要求は、送信のためにトランスポート層に渡されなければなりません（MUST）。信頼できないトランスポートが使用されている場合、クライアントトランザクションはタイマーEをT1秒で起動するように設定する必要があります。この状態のままタイマーEが起動すると、タイマーはリセットされますが、今回はMIN（2 * T1、T2）の値を使用します。タイマーが再び起動すると、MIN（4 * T1、T2）にリセットされます。このプロセスは継続するため、T2で上限となる指数関数的に増加する間隔で再送信が発生します。 T2のデフォルト値は4秒であり、非INVITEサーバートランザクションが要求に応答するのにかかる時間（即時に応答しない場合）を表します。 T1およびT2のデフォルト値の場合、これは500 ms、1秒、2秒、4秒、4秒、4秒などの間隔になります。
If Timer F fires while the client transaction is still in the "Trying" state, the client transaction SHOULD inform the TU about the timeout, and then it SHOULD enter the "Terminated" state. If a provisional response is received while in the "Trying" state, the response MUST be passed to the TU, and then the client transaction SHOULD move to the "Proceeding" state. If a final response (status codes 200-699) is received while in the "Trying" state, the response MUST be passed to the TU, and the client transaction MUST transition to the "Completed" state.
クライアントトランザクションがまだ「試行中」状態のときにタイマーFが発生した場合、クライアントトランザクションはTUにタイムアウトについて通知する必要があり（SHOULD）、次に「終了」状態に入る必要があります（SHOULD）。 「試行中」状態の間に暫定応答を受信した場合、その応答をTUに渡さなければならず（MUST）、クライアントトランザクションは「処理中」状態に移行する必要があります（SHOULD）。 「試行中」状態の間に最終応答（ステータスコード200〜699）を受信した場合、その応答はTUに渡されなければならず（MUST）、クライアントトランザクションは「完了」状態に移行しなければなりません（MUST）。
If Timer E fires while in the "Proceeding" state, the request MUST be passed to the transport layer for retransmission, and Timer E MUST be reset with a value of T2 seconds. If timer F fires while in the "Proceeding" state, the TU MUST be informed of a timeout, and the client transaction MUST transition to the terminated state. If a final response (status codes 200-699) is received while in the "Proceeding" state, the response MUST be passed to the TU, and the client transaction MUST transition to the "Completed" state.
「Proceeding」状態の間にタイマーEが発生した場合、再送信のために要求をトランスポート層に渡さなければならず（MUST）、タイマーEはT2秒の値でリセットされなければなりません（MUST）。 「Proceeding」状態の間にタイマーFが発生した場合、TUはタイムアウトを通知されなければならず（MUST）、クライアントトランザクションは終了状態に遷移しなければなりません（MUST）。 「Proceeding」状態の間に最終応答（ステータスコード200〜699）を受信した場合、その応答をTUに渡す必要があり、クライアントトランザクションは「Completed」状態に遷移する必要があります。
Once the client transaction enters the "Completed" state, it MUST set Timer K to fire in T4 seconds for unreliable transports, and zero seconds for reliable transports. The "Completed" state exists to buffer any additional response retransmissions that may be received (which is why the client transaction remains there only for unreliable transports). T4 represents the amount of time the network will take to clear messages between client and server transactions. The default value of T4 is 5s. A response is a retransmission when it matches the same transaction, using the rules specified in Section 17.1.3. If Timer K fires while in this state, the client transaction MUST transition to the "Terminated" state.
クライアントトランザクションが「完了」状態になると、タイマーKを、信頼性の低いトランスポートの場合はT4秒で、信頼性の高いトランスポートの場合は0秒で起動するように設定する必要があります。 「完了」状態は、受信される可能性のある追加の応答再送信をバッファリングするために存在します（そのため、クライアントトランザクションは、信頼できないトランスポートに対してのみそこに残ります）。 T4は、ネットワークがクライアントとサーバーのトランザクション間のメッセージをクリアするのにかかる時間を表します。 T4のデフォルト値は5秒です。レスポンスは、セクション17.1.3で指定されたルールを使用して、同じトランザクションと一致する場合の再送信です。この状態でタイマーKが発生した場合、クライアントトランザクションは「Terminated」状態に移行する必要があります。
Once the transaction is in the terminated state, it MUST be destroyed immediately.
トランザクションが終了状態になると、すぐに破棄する必要があります。
When the transport layer in the client receives a response, it has to determine which client transaction will handle the response, so that the processing of Sections 17.1.1 and 17.1.2 can take place. The branch parameter in the top Via header field is used for this purpose. A response matches a client transaction under two conditions:
クライアントのトランスポート層が応答を受信すると、セクション17.1.1および17.1.2の処理を実行できるように、応答を処理するクライアントトランザクションを決定する必要があります。上部のViaヘッダーフィールドのブランチパラメータは、この目的で使用されます。応答は、次の2つの条件下でクライアントトランザクションと一致します。
1. If the response has the same value of the branch parameter in the top Via header field as the branch parameter in the top Via header field of the request that created the transaction.
1. 応答の上部のViaヘッダーフィールドのブランチパラメーターの値が、トランザクションを作成したリクエストの上部のViaヘッダーフィールドのブランチパラメーターと同じである場合。
2. If the method parameter in the CSeq header field matches the method of the request that created the transaction. The method is needed since a CANCEL request constitutes a different transaction, but shares the same value of the branch parameter.
2. CSeqヘッダーフィールドのメソッドパラメータが、トランザクションを作成したリクエストのメソッドと一致する場合。 CANCELリクエストは別のトランザクションを構成するため、このメソッドが必要ですが、ブランチパラメータの同じ値を共有します。
If a request is sent via multicast, it is possible that it will generate multiple responses from different servers. These responses will all have the same branch parameter in the topmost Via, but vary in the To tag. The first response received, based on the rules above, will be used, and others will be viewed as retransmissions. That is not an error; multicast SIP provides only a rudimentary "single-hop-discovery-like" service that is limited to processing a single response. See Section 18.1.1 for details.
リクエストがマルチキャストで送信された場合、異なるサーバーから複数の応答が生成される可能性があります。これらの応答はすべて、最上位のViaで同じブランチパラメータを持ちますが、Toタグは異なります。上記のルールに基づいて受信された最初の応答が使用され、他の応答は再送信と見なされます。これはエラーではありません。マルチキャストSIPは、単一の応答の処理に限定された基本的な「シングルホップディスカバリーのような」サービスのみを提供します。詳細については、セクション18.1.1を参照してください。
|Request from TU
|send request
Timer E V
send request +-----------+
+---------| |-------------------+
| | Trying | Timer F |
+-------->| | or Transport Err.|
+-----------+ inform TU |
200-699 | | |
resp. to TU | |1xx |
+---------------+ |resp. to TU |
| | |
| Timer E V Timer F |
| send req +-----------+ or Transport Err. |
| +---------| | inform TU |
| | |Proceeding |------------------>|
| +-------->| |-----+ |
| +-----------+ |1xx |
| | ^ |resp to TU |
| 200-699 | +--------+ |
| resp. to TU | |
| | |
| V |
| +-----------+ |
| | | |
| | Completed | |
| | | |
| +-----------+ |
| ^ | |
| | | Timer K |
+--------------+ | - |
| |
V |
NOTE: +-----------+ |
| | |
transitions | Terminated|<------------------+
labeled with | |
the event +-----------+
over the action
to take
Figure 6: non-INVITE client transaction
図6：非INVITEクライアントトランザクション
When the client transaction sends a request to the transport layer to be sent, the following procedures are followed if the transport layer indicates a failure.
クライアントトランザクションがトランスポート層に送信する要求を送信するとき、トランスポート層が失敗を示している場合は、次の手順に従います。
The client transaction SHOULD inform the TU that a transport failure has occurred, and the client transaction SHOULD transition directly to the "Terminated" state. The TU will handle the failover mechanisms described in [4].
クライアントトランザクションは、トランスポート障害が発生したことをTUに通知する必要があり（SHOULD）、クライアントトランザクションは「Terminated」状態に直接移行する必要があります（SHOULD）。 TUは、[4]で説明されているフェイルオーバーメカニズムを処理します。
The server transaction is responsible for the delivery of requests to the TU and the reliable transmission of responses. It accomplishes this through a state machine. Server transactions are created by the core when a request is received, and transaction handling is desired for that request (this is not always the case).
サーバートランザクションは、TUへの要求の配信と応答の信頼できる送信を担当します。これは、状態マシンを通じてこれを実現します。サーバートランザクションは、リクエストが受信されたときにコアによって作成され、そのリクエストに対してトランザクション処理が必要です（これは常にそうであるとは限りません）。
As with the client transactions, the state machine depends on whether the received request is an INVITE request.
クライアントトランザクションと同様に、状態マシンは、受信した要求がINVITE要求であるかどうかによって異なります。
The state diagram for the INVITE server transaction is shown in Figure 7.
INVITEサーバートランザクションの状態図を図7に示します。
When a server transaction is constructed for a request, it enters the "Proceeding" state. The server transaction MUST generate a 100 (Trying) response unless it knows that the TU will generate a provisional or final response within 200 ms, in which case it MAY generate a 100 (Trying) response. This provisional response is needed to quench request retransmissions rapidly in order to avoid network congestion. The 100 (Trying) response is constructed according to the procedures in Section 8.2.6, except that the insertion of tags in the To header field of the response (when none was present in the request) is downgraded from MAY to SHOULD NOT. The request MUST be passed to the TU.
リクエストに対してサーバートランザクションが作成されると、「Proceeding」状態になります。サーバートランザクションは、TUが200ミリ秒以内に暫定応答または最終応答を生成することがわかっている場合を除いて、100（試行）応答を生成する必要があります。その場合、100（試行）応答を生成する場合があります。この暫定応答は、ネットワークの輻輳を回避するために、要求の再送信を迅速に停止するために必要です。 100（Trying）応答は、セクション8.2.6の手順に従って作成されますが、応答のToヘッダーフィールドへのタグの挿入（リクエストに何も存在しない場合）は、MAYからSHOULD NOTにダウングレードされます。要求はTUに渡されなければなりません。
The TU passes any number of provisional responses to the server transaction. So long as the server transaction is in the "Proceeding" state, each of these MUST be passed to the transport layer for transmission. They are not sent reliably by the transaction layer (they are not retransmitted by it) and do not cause a change in the state of the server transaction. If a request retransmission is received while in the "Proceeding" state, the most recent provisional response that was received from the TU MUST be passed to the transport layer for retransmission. A request is a retransmission if it matches the same server transaction based on the rules of Section 17.2.3.
TUは任意の数の暫定応答をサーバートランザクションに渡します。サーバートランザクションが "Proceeding"状態である限り、これらのそれぞれをトランスポート層に渡して送信する必要があります。それらはトランザクション層によって確実に送信されず（トランザクション層によって再送信されません）、サーバートランザクションの状態に変化を引き起こしません。 「Proceeding」状態のときに再送信要求を受信した場合、TUから受信した最新の暫定応答を再送信のためにトランスポート層に渡す必要があります。セクション17.2.3のルールに基づいて同じサーバートランザクションと一致する場合、リクエストは再送信です。
If, while in the "Proceeding" state, the TU passes a 2xx response to the server transaction, the server transaction MUST pass this response to the transport layer for transmission. It is not retransmitted by the server transaction; retransmissions of 2xx responses are handled by the TU. The server transaction MUST then transition to the "Terminated" state.
「Proceeding」状態の間に、TUが2xx応答をサーバートランザクションに渡す場合、サーバートランザクションはこの応答をトランスポート層に渡して送信する必要があります。サーバートランザクションによって再送信されることはありません。 2xx応答の再送信はTUによって処理されます。その後、サーバートランザクションは「終了」状態に遷移する必要があります。
While in the "Proceeding" state, if the TU passes a response with status code from 300 to 699 to the server transaction, the response MUST be passed to the transport layer for transmission, and the state machine MUST enter the "Completed" state. For unreliable transports, timer G is set to fire in T1 seconds, and is not set to fire for reliable transports.
"Proceeding"状態のときに、TUがステータスコード300〜699の応答をサーバートランザクションに渡す場合、応答はトランスポート層に渡されて送信される必要があり、ステートマシンは "Completed"状態に入る必要があります。信頼性の低いトランスポートの場合、タイマーGはT1秒で起動するように設定され、信頼性の高いトランスポートの場合は起動するように設定されていません。
This is a change from RFC 2543, where responses were always retransmitted, even over reliable transports.
これはRFC 2543からの変更点であり、信頼性の高いトランスポートを介しても、常に応答が再送信されていました。
When the "Completed" state is entered, timer H MUST be set to fire in 64*T1 seconds for all transports. Timer H determines when the server transaction abandons retransmitting the response. Its value is chosen to equal Timer B, the amount of time a client transaction will continue to retry sending a request. If timer G fires, the response is passed to the transport layer once more for retransmission, and timer G is set to fire in MIN(2*T1, T2) seconds. From then on, when timer G fires, the response is passed to the transport again for transmission, and timer G is reset with a value that doubles, unless that value exceeds T2, in which case it is reset with the value of T2. This is identical to the retransmit behavior for requests in the "Trying" state of the non-INVITE client transaction. Furthermore, while in the "Completed" state, if a request retransmission is received, the server SHOULD pass the response to the transport for retransmission.
「完了」状態に入ると、タイマーHはすべてのトランスポートに対して64 * T1秒で起動するように設定する必要があります。タイマーHは、サーバートランザクションが応答の再送信をいつ中止するかを決定します。その値は、タイマーB、つまりクライアントトランザクションがリクエストの送信を再試行し続ける時間と等しくなるように選択されます。タイマーGが起動すると、再送信のために応答がトランスポート層にもう一度渡され、タイマーGはMIN（2 * T1、T2）秒で起動するように設定されます。その後、タイマーGが起動すると、応答はトランスポートに再度送信されて送信され、タイマーGは2倍の値でリセットされます。これは、非INVITEクライアントトランザクションの「試行中」状態の要求の再送信動作と同じです。さらに、「完了」状態のときに、再送要求を受信した場合、サーバーは再送のためにトランスポートに応答を渡す必要があります（SHOULD）。
If an ACK is received while the server transaction is in the "Completed" state, the server transaction MUST transition to the "Confirmed" state. As Timer G is ignored in this state, any retransmissions of the response will cease.
サーバートランザクションが「完了」状態のときにACKを受信した場合、サーバートランザクションは「確認済み」状態に遷移する必要があります。この状態ではタイマーGが無視されるため、応答の再送信は停止します。
If timer H fires while in the "Completed" state, it implies that the ACK was never received. In this case, the server transaction MUST transition to the "Terminated" state, and MUST indicate to the TU that a transaction failure has occurred.
「完了」状態の間にタイマーHが発生した場合、ACKが受信されなかったことを意味します。この場合、サーバートランザクションは「Terminated」状態に移行する必要があり、トランザクション障害が発生したことをTUに示す必要があります。
|INVITE
|pass INV to TU
INVITE V send 100 if TU won't in 200ms
send response+-----------+
+--------| |--------+101-199 from TU
| | Proceeding| |send response
+------->| |<-------+
| | Transport Err.
| | Inform TU
| |--------------->+
+-----------+ |
300-699 from TU | |2xx from TU |
send response | |send response |
| +------------------>+
| |
INVITE V Timer G fires |
send response+-----------+ send response |
+--------| |--------+ |
| | Completed | | |
+------->| |<-------+ |
+-----------+ |
| | |
ACK | | |
- | +------------------>+
| Timer H fires |
V or Transport Err.|
+-----------+ Inform TU |
| | |
| Confirmed | |
| | |
+-----------+ |
| |
|Timer I fires |
|- |
| |
V |
+-----------+ |
| | |
| Terminated|<---------------+
| |
+-----------+
Figure 7: INVITE server transaction
図7：INVITEサーバートランザクション
The purpose of the "Confirmed" state is to absorb any additional ACK messages that arrive, triggered from retransmissions of the final response. When this state is entered, timer I is set to fire in T4 seconds for unreliable transports, and zero seconds for reliable transports. Once timer I fires, the server MUST transition to the "Terminated" state.
「確認済み」状態の目的は、最終応答の再送信からトリガーされて到着する追加のACKメッセージを吸収することです。この状態に入ると、タイマーIは、信頼性の低いトランスポートの場合はT4秒で、信頼性のあるトランスポートの場合は0秒で起動するように設定されます。タイマーが作動すると、サーバーは「終了」状態に遷移する必要があります。
Once the transaction is in the "Terminated" state, it MUST be destroyed immediately. As with client transactions, this is needed to ensure reliability of the 2xx responses to INVITE.
トランザクションが「終了」状態になると、すぐに破棄する必要があります。クライアントトランザクションと同様に、これはINVITEに対する2xx応答の信頼性を確保するために必要です。
The state machine for the non-INVITE server transaction is shown in Figure 8.
非INVITEサーバートランザクションのステートマシンを図8に示します。
The state machine is initialized in the "Trying" state and is passed a request other than INVITE or ACK when initialized. This request is passed up to the TU. Once in the "Trying" state, any further request retransmissions are discarded. A request is a retransmission if it matches the same server transaction, using the rules specified in Section 17.2.3.
状態マシンは「試行中」状態で初期化され、初期化時にINVITEまたはACK以外の要求が渡されます。この要求はTUに渡されます。 「試行中」状態になると、それ以降の要求の再送信は破棄されます。セクション17.2.3で指定されたルールを使用して、同じサーバートランザクションに一致するリクエストは再送信です。
While in the "Trying" state, if the TU passes a provisional response to the server transaction, the server transaction MUST enter the "Proceeding" state. The response MUST be passed to the transport layer for transmission. Any further provisional responses that are received from the TU while in the "Proceeding" state MUST be passed to the transport layer for transmission. If a retransmission of the request is received while in the "Proceeding" state, the most recently sent provisional response MUST be passed to the transport layer for retransmission. If the TU passes a final response (status codes 200-699) to the server while in the "Proceeding" state, the transaction MUST enter the "Completed" state, and the response MUST be passed to the transport layer for transmission.
「試行中」状態のときに、TUがサーバートランザクションに暫定応答を渡すと、サーバートランザクションは「処理中」状態になります。応答は、送信のためにトランスポート層に渡されなければなりません（MUST）。 "Proceeding"状態にある間にTUから受信したそれ以降の暫定応答は、送信のためにトランスポート層に渡される必要があります。 「Proceeding」状態でリクエストの再送信を受信した場合、最後に送信された暫定応答を再送信のためにトランスポート層に渡す必要があります。 「処理中」状態の間にTUが最終応答（ステータスコード200〜699）をサーバーに渡す場合、トランザクションは「完了」状態に入り、応答は転送のためにトランスポート層に渡される必要があります。
When the server transaction enters the "Completed" state, it MUST set Timer J to fire in 64*T1 seconds for unreliable transports, and zero seconds for reliable transports. While in the "Completed" state, the server transaction MUST pass the final response to the transport layer for retransmission whenever a retransmission of the request is received. Any other final responses passed by the TU to the server transaction MUST be discarded while in the "Completed" state. The server transaction remains in this state until Timer J fires, at which point it MUST transition to the "Terminated" state.
サーバートランザクションが「完了」状態になると、タイマーJを、信頼できないトランスポートの場合は64 * T1秒、信頼できるトランスポートの場合は0秒で起動するように設定する必要があります。 「完了」状態にある間、サーバートランザクションは、リクエストの再送信を受信するたびに、再送信のためにトランスポート層に最終応答を渡す必要があります。 TUからサーバートランザクションに渡されるその他の最終応答は、「完了」状態にある間は破棄する必要があります。サーバートランザクションは、タイマーJが起動するまでこの状態を維持します。この時点で、サーバーは「終了」状態に遷移する必要があります。
The server transaction MUST be destroyed the instant it enters the "Terminated" state.
サーバートランザクションは、「終了」状態になった瞬間に破棄する必要があります。
When a request is received from the network by the server, it has to be matched to an existing transaction. This is accomplished in the following manner.
サーバーがネットワークからリクエストを受信した場合、既存のトランザクションと照合する必要があります。これは次の方法で行われます。
The branch parameter in the topmost Via header field of the request is examined. If it is present and begins with the magic cookie "z9hG4bK", the request was generated by a client transaction compliant to this specification. Therefore, the branch parameter will be unique across all transactions sent by that client. The request matches a transaction if:
リクエストの一番上のViaヘッダーフィールドのブランチパラメータが調べられます。それが存在し、マジッククッキー「z9hG4bK」で始まる場合、リクエストはこの仕様に準拠するクライアントトランザクションによって生成されました。したがって、ブランチパラメータは、そのクライアントによって送信されたすべてのトランザクションにわたって一意になります。次の場合、リクエストはトランザクションと一致します。
1. the branch parameter in the request is equal to the one in the top Via header field of the request that created the transaction, and
1. リクエストのブランチパラメータは、トランザクションを作成したリクエストの上部のViaヘッダーフィールドのパラメータと同じです。
2. the sent-by value in the top Via of the request is equal to the one in the request that created the transaction, and
2. リクエストの一番上のViaの送信された値が、トランザクションを作成したリクエストの値と等しい。
3. the method of the request matches the one that created the transaction, except for ACK, where the method of the request that created the transaction is INVITE.
3. リクエストのメソッドは、トランザクションを作成したものと一致します。ただし、ACKは、トランザクションを作成したリクエストのメソッドがINVITEです。
This matching rule applies to both INVITE and non-INVITE transactions alike.
この一致ルールは、INVITEトランザクションと非INVITEトランザクションの両方に同様に適用されます。
The sent-by value is used as part of the matching process because there could be accidental or malicious duplication of branch parameters from different clients.
異なるクライアントからのブランチパラメータの偶発的または悪意のある複製が存在する可能性があるため、sent-by値は照合プロセスの一部として使用されます。
If the branch parameter in the top Via header field is not present, or does not contain the magic cookie, the following procedures are used. These exist to handle backwards compatibility with RFC 2543 compliant implementations.
上部のViaヘッダーフィールドのブランチパラメータが存在しない場合、またはマジッククッキーが含まれていない場合は、次の手順が使用されます。これらは、RFC 2543準拠の実装との下位互換性を処理するために存在します。
The INVITE request matches a transaction if the Request-URI, To tag, From tag, Call-ID, CSeq, and top Via header field match those of the INVITE request which created the transaction. In this case, the INVITE is a retransmission of the original one that created the transaction. The ACK request matches a transaction if the Request-URI, From tag, Call-ID, CSeq number (not the method), and top Via header field match those of the INVITE request which created the transaction, and the To tag of the ACK matches the To tag of the response sent by the server transaction. Matching is done based on the matching rules defined for each of those header fields. Inclusion of the tag in the To header field in the ACK matching process helps disambiguate ACK for 2xx from ACK for other responses at a proxy, which may have forwarded both responses (This can occur in unusual conditions. Specifically, when a proxy forked a request, and then crashes, the responses may be delivered to another proxy, which might end up forwarding multiple responses upstream). An ACK request that matches an INVITE transaction matched by a previous ACK is considered a retransmission of that previous ACK.
INVITE要求は、Request-URI、Toタグ、Fromタグ、Call-ID、CSeq、およびトップViaヘッダーフィールドがトランザクションを作成したINVITE要求のフィールドと一致する場合、トランザクションと一致します。この場合、INVITEは、トランザクションを作成した元のINVITEの再送信です。 ACK要求は、Request-URI、Fromタグ、Call-ID、CSeq番号（メソッドではない）、および上部のViaヘッダーフィールドが、トランザクションを作成したINVITE要求のものと、ACKのToタグと一致する場合、トランザクションと一致します。サーバートランザクションによって送信された応答のToタグに一致します。マッチングは、これらの各ヘッダーフィールドに定義されたマッチングルールに基づいて行われます。 ACKマッチングプロセスのToヘッダーフィールドにタグを含めることで、2xxのACKをプロキシでの他の応答のACKから明確化し、両方の応答を転送した可能性があります（これは異常な状況で発生する可能性があります。特に、プロキシがリクエストをフォークした場合、その後クラッシュすると、応答が別のプロキシに配信され、最終的に複数の応答がアップストリームに転送される可能性があります）。以前のACKと一致するINVITEトランザクションと一致するACK要求は、その以前のACKの再送信と見なされます。
|Request received
|pass to TU
V
+-----------+
| |
| Trying |-------------+
| | |
+-----------+ |200-699 from TU
| |send response
|1xx from TU |
|send response |
| |
Request V 1xx from TU |
send response+-----------+send response|
+--------| |--------+ |
| | Proceeding| | |
+------->| |<-------+ |
+<--------------| | |
|Trnsprt Err +-----------+ |
|Inform TU | |
| | |
| |200-699 from TU |
| |send response |
| Request V |
| send response+-----------+ |
| +--------| | |
| | | Completed |<------------+
| +------->| |
+<--------------| |
|Trnsprt Err +-----------+
|Inform TU |
| |Timer J fires
| |-
| |
| V
| +-----------+
| | |
+-------------->| Terminated|
| |
+-----------+
Figure 8: non-INVITE server transaction
図8：非INVITEサーバートランザクション
For all other request methods, a request is matched to a transaction if the Request-URI, To tag, From tag, Call-ID, CSeq (including the method), and top Via header field match those of the request that created the transaction. Matching is done based on the matching rules defined for each of those header fields. When a non-INVITE request matches an existing transaction, it is a retransmission of the request that created that transaction.
他のすべての要求メソッドでは、Request-URI、Toタグ、Fromタグ、Call-ID、CSeq（メソッドを含む）、およびトップViaヘッダーフィールドがトランザクションを作成した要求のフィールドと一致する場合、要求はトランザクションと一致します。 。マッチングは、これらの各ヘッダーフィールドに定義されたマッチングルールに基づいて行われます。 INVITE以外の要求が既存のトランザクションと一致する場合、それはそのトランザクションを作成した要求の再送信です。
Because the matching rules include the Request-URI, the server cannot match a response to a transaction. When the TU passes a response to the server transaction, it must pass it to the specific server transaction for which the response is targeted.
一致ルールにはRequest-URIが含まれているため、サーバーはトランザクションへの応答を照合できません。 TUは、サーバートランザクションに応答を渡すとき、応答の対象となる特定のサーバートランザクションにそれを渡す必要があります。
When the server transaction sends a response to the transport layer to be sent, the following procedures are followed if the transport layer indicates a failure.
サーバートランザクションが送信するトランスポート層に応答を送信するとき、トランスポート層が障害を示している場合は、次の手順に従います。
First, the procedures in [4] are followed, which attempt to deliver the response to a backup. If those should all fail, based on the definition of failure in [4], the server transaction SHOULD inform the TU that a failure has occurred, and SHOULD transition to the terminated state.
まず、[4]の手順に従い、バックアップへの応答を提供しようとします。これらすべてが失敗した場合、[4]の失敗の定義に基づいて、サーバートランザクションはTUに失敗が発生したことを通知し（SHOULD）、終了状態に移行する必要があります（SHOULD）。
18 Transport
18輸送
The transport layer is responsible for the actual transmission of requests and responses over network transports. This includes determination of the connection to use for a request or response in the case of connection-oriented transports.
トランスポート層は、ネットワークトランスポートを介した要求と応答の実際の送信を担当します。これには、コネクション型トランスポートの場合に要求または応答に使用する接続の決定が含まれます。
The transport layer is responsible for managing persistent connections for transport protocols like TCP and SCTP, or TLS over those, including ones opened to the transport layer. This includes connections opened by the client or server transports, so that connections are shared between client and server transport functions. These connections are indexed by the tuple formed from the address, port, and transport protocol at the far end of the connection. When a connection is opened by the transport layer, this index is set to the destination IP, port and transport. When the connection is accepted by the transport layer, this index is set to the source IP address, port number, and transport. Note that, because the source port is often ephemeral, but it cannot be known whether it is ephemeral or selected through procedures in [4], connections accepted by the transport layer will frequently not be reused. The result is that two proxies in a "peering" relationship using a connection-oriented transport frequently will have two connections in use, one for transactions initiated in each direction.
トランスポート層は、TCPやSCTPなどのトランスポートプロトコルの永続的な接続、またはトランスポート層に開かれているものを含むTLSを介したTLSの管理を担当します。これには、クライアントまたはサーバーのトランスポートによって開かれた接続が含まれるため、接続はクライアントとサーバーのトランスポート機能の間で共有されます。これらの接続は、接続の遠端のアドレス、ポート、およびトランスポートプロトコルから形成されたタプルによってインデックスが作成されます。トランスポート層によって接続が開かれると、このインデックスは宛先IP、ポート、トランスポートに設定されます。接続がトランスポート層によって受け入れられると、このインデックスは送信元IPアドレス、ポート番号、およびトランスポートに設定されます。送信元ポートは一時的であることが多いため、一時的であるか[4]の手順で選択されたかがわからないため、トランスポート層によって受け入れられた接続は再利用されないことが多いことに注意してください。その結果、接続指向のトランスポートを使用する「ピアリング」関係にある2つのプロキシは、2つの接続を使用します。1つは、各方向で開始されたトランザクション用です。
It is RECOMMENDED that connections be kept open for some implementation-defined duration after the last message was sent or received over that connection. This duration SHOULD at least equal the longest amount of time the element would need in order to bring a transaction from instantiation to the terminated state. This is to make it likely that transactions are completed over the same connection on which they are initiated (for example, request, response, and in the case of INVITE, ACK for non-2xx responses). This usually means at least 64*T1 (see Section 17.1.1.1 for a definition of T1). However, it could be larger in an element that has a TU using a large value for timer C (bullet 11 of Section 16.6), for example.
最後のメッセージがその接続を介して送信または受信された後、実装で定義された期間、接続を開いたままにしておくことをお勧めします。この期間は、トランザクションをインスタンス化から終了状態にするために要素が必要とする最長時間に少なくとも等しい必要があります。これは、トランザクションが開始されるのと同じ接続を介してトランザクションが完了する可能性を高めるためです（たとえば、要求、応答、およびINVITEの場合は非2xx応答のACK）。これは通常、少なくとも64 * T1を意味します（T1の定義については、セクション17.1.1.1を参照してください）。ただし、たとえば、タイマーC（セクション16.6の箇条書き11）に大きな値を使用するTUを持つ要素では、それより大きくなる可能性があります。
All SIP elements MUST implement UDP and TCP. SIP elements MAY implement other protocols.
すべてのSIP要素はUDPとTCPを実装する必要があります。 SIP要素は他のプロトコルを実装してもよい（MAY）。
Making TCP mandatory for the UA is a substantial change from RFC 2543. It has arisen out of the need to handle larger messages, which MUST use TCP, as discussed below. Thus, even if an element never sends large messages, it may receive one and needs to be able to handle them.
UAにTCPを必須にすることは、RFC 2543からの大幅な変更です。これは、以下で説明するように、TCPを使用する必要がある大きなメッセージを処理する必要性から生じています。したがって、要素が大きなメッセージを送信しない場合でも、要素はメッセージを受信する可能性があり、それらを処理できる必要があります。
The client side of the transport layer is responsible for sending the request and receiving responses. The user of the transport layer passes the client transport the request, an IP address, port, transport, and possibly TTL for multicast destinations.
トランスポート層のクライアント側は、要求の送信と応答の受信を担当します。トランスポート層のユーザーは、クライアントのトランスポート要求、IPアドレス、ポート、トランスポート、および場合によってはマルチキャスト宛先のTTLを渡します。
If a request is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU is unknown, the request MUST be sent using an RFC 2914 [43] congestion controlled transport protocol, such as TCP. If this causes a change in the transport protocol from the one indicated in the top Via, the value in the top Via MUST be changed. This prevents fragmentation of messages over UDP and provides congestion control for larger messages. However, implementations MUST be able to handle messages up to the maximum datagram packet size. For UDP, this size is 65,535 bytes, including IP and UDP headers.
リクエストがパスMTUの200バイト以内にある場合、または1300バイトより大きく、パスMTUが不明の場合、TCPなどのRFC 2914 [43]輻輳制御トランスポートプロトコルを使用してリクエストを送信する必要があります。これにより、トランスポートプロトコルが最上位のViaに示されているプロトコルから変更される場合は、最上位のViaの値を変更する必要があります。これにより、UDPを介したメッセージの断片化が防止され、より大きなメッセージに輻輳制御が提供されます。ただし、実装は最大データグラムパケットサイズまでメッセージを処理できなければなりません（MUST）。 UDPの場合、このサイズは65,535バイトで、IPヘッダーとUDPヘッダーを含みます。
The 200 byte "buffer" between the message size and the MTU accommodates the fact that the response in SIP can be larger than the request. This happens due to the addition of Record-Route header field values to the responses to INVITE, for example. With the extra buffer, the response can be about 170 bytes larger than the request, and still not be fragmented on IPv4 (about 30 bytes is consumed by IP/UDP, assuming no IPSec). 1300 is chosen when path MTU is not known, based on the assumption of a 1500 byte Ethernet MTU.
メッセージサイズとMTUの間の200バイトの「バッファ」は、SIPでの応答が要求よりも大きくなる可能性があるという事実に対応します。これは、たとえばINVITEへの応答にRecord-Routeヘッダーフィールド値が追加されたために発生します。追加のバッファーを使用すると、応答は要求よりも約170バイト大きくなる可能性がありますが、IPv4では断片化されません（IPSecがないと仮定すると、IP / UDPによって約30バイトが消費されます）。 1500バイトのイーサネットMTUの想定に基づいて、パスMTUが不明な場合は1300が選択されます。
If an element sends a request over TCP because of these message size constraints, and that request would have otherwise been sent over UDP, if the attempt to establish the connection generates either an ICMP Protocol Not Supported, or results in a TCP reset, the element SHOULD retry the request, using UDP. This is only to provide backwards compatibility with RFC 2543 compliant implementations that do not support TCP. It is anticipated that this behavior will be deprecated in a future revision of this specification.
これらのメッセージサイズの制約のためにエレメントがTCPを介してリクエストを送信し、そのリクエストがUDPを介して送信された場合、接続を確立しようとするとICMPプロトコルがサポートされないか、TCPリセットが発生する場合、エレメントはUDPを使用してリクエストを再試行する必要があります。これは、TCPをサポートしないRFC 2543準拠の実装との下位互換性を提供するためだけのものです。この動作は、この仕様の将来のリビジョンで廃止される予定です。
A client that sends a request to a multicast address MUST add the "maddr" parameter to its Via header field value containing the destination multicast address, and for IPv4, SHOULD add the "ttl" parameter with a value of 1. Usage of IPv6 multicast is not defined in this specification, and will be a subject of future standardization when the need arises.
マルチキャストアドレスに要求を送信するクライアントは、宛先マルチキャストアドレスを含むViaヘッダーフィールド値に「maddr」パラメーターを追加する必要があり、IPv4の場合、値1の「ttl」パラメーターを追加する必要があります（SHOULD）。IPv6マルチキャストの使用この仕様では定義されておらず、必要に応じて将来の標準化の対象となります。
These rules result in a purposeful limitation of multicast in SIP. Its primary function is to provide a "single-hop-discovery-like" service, delivering a request to a group of homogeneous servers, where it is only required to process the response from any one of them. This functionality is most useful for registrations. In fact, based on the transaction processing rules in Section 17.1.3, the client transaction will accept the first response, and view any others as retransmissions because they all contain the same Via branch identifier.
これらのルールにより、SIPでのマルチキャストの意図的な制限が発生します。その主な機能は、「シングルホップディスカバリーのような」サービスを提供し、同種サーバーのグループにリクエストを配信することです。同種サーバーのいずれかからの応答を処理するだけで済みます。この機能は、登録に最も役立ちます。実際、17.1.3項のトランザクション処理ルールに基づいて、クライアントトランザクションは最初の応答を受け入れ、他のすべては同じViaブランチ識別子を含んでいるため、再送信として表示します。
Before a request is sent, the client transport MUST insert a value of the "sent-by" field into the Via header field. This field contains an IP address or host name, and port. The usage of an FQDN is RECOMMENDED. This field is used for sending responses under certain conditions, described below. If the port is absent, the default value depends on the transport. It is 5060 for UDP, TCP and SCTP, 5061 for TLS.
リクエストが送信される前に、クライアントトランスポートは「送信者」フィールドの値をViaヘッダーフィールドに挿入する必要があります。このフィールドには、IPアドレスまたはホスト名、およびポートが含まれます。 FQDNの使用をお勧めします。このフィールドは、以下で説明する特定の条件下で応答を送信するために使用されます。ポートがない場合、デフォルト値はトランスポートによって異なります。 UDP、TCPおよびSCTPの場合は5060、TLSの場合は5061です。
For reliable transports, the response is normally sent on the connection on which the request was received. Therefore, the client transport MUST be prepared to receive the response on the same connection used to send the request. Under error conditions, the server may attempt to open a new connection to send the response. To handle this case, the transport layer MUST also be prepared to receive an incoming connection on the source IP address from which the request was sent and port number in the "sent-by" field. It also MUST be prepared to receive incoming connections on any address and port that would be selected by a server based on the procedures described in Section 5 of [4].
信頼できるトランスポートの場合、応答は通常、要求が受信された接続で送信されます。したがって、クライアントトランスポートは、要求の送信に使用したのと同じ接続で応答を受信できるように準備する必要があります。エラー状態では、サーバーは新しい接続を開いて応答を送信しようとする場合があります。このケースを処理するために、トランスポート層は、要求の送信元のソースIPアドレスと「送信元」フィールドのポート番号で着信接続を受信する準備もしなければなりません（MUST）。また、[4]のセクション5で説明されている手順に基づいてサーバーによって選択される任意のアドレスとポートで着信接続を受信できるように準備する必要があります。
For unreliable unicast transports, the client transport MUST be prepared to receive responses on the source IP address from which the request is sent (as responses are sent back to the source address) and the port number in the "sent-by" field. Furthermore, as with reliable transports, in certain cases the response will be sent elsewhere. The client MUST be prepared to receive responses on any address and port that would be selected by a server based on the procedures described in Section 5 of [4].
信頼性の低いユニキャストトランスポートの場合、クライアントトランスポートは、要求の送信元の送信元IPアドレス（応答が送信元アドレスに返送されるため）および "送信元"フィールドのポート番号で応答を受信できるように準備する必要があります。さらに、信頼できるトランスポートと同様に、特定のケースでは応答が別の場所に送信されます。クライアントは、[4]のセクション5で説明されている手順に基づいてサーバーによって選択される任意のアドレスとポートで応答を受信する準備ができていなければなりません。
For multicast, the client transport MUST be prepared to receive responses on the same multicast group and port to which the request is sent (that is, it needs to be a member of the multicast group it sent the request to.)
マルチキャストの場合、クライアントトランスポートは、要求の送信先と同じマルチキャストグループとポートで応答を受信できるように準備する必要があります（つまり、要求を送信したマルチキャストグループのメンバーである必要があります）。
If a request is destined to an IP address, port, and transport to which an existing connection is open, it is RECOMMENDED that this connection be used to send the request, but another connection MAY be opened and used.
リクエストの宛先が既存の接続が開いているIPアドレス、ポート、トランスポートである場合、この接続を使用してリクエストを送信することをお勧めしますが、別の接続を開いて使用することもできます（MAY）。
If a request is sent using multicast, it is sent to the group address, port, and TTL provided by the transport user. If a request is sent using unicast unreliable transports, it is sent to the IP address and port provided by the transport user.
要求がマルチキャストを使用して送信される場合、トランスポートユーザーによって提供されたグループアドレス、ポート、およびTTLに送信されます。ユニキャストの信頼性の低いトランスポートを使用して要求が送信される場合、トランスポートユーザーによって提供されたIPアドレスとポートに送信されます。
When a response is received, the client transport examines the top Via header field value. If the value of the "sent-by" parameter in that header field value does not correspond to a value that the client transport is configured to insert into requests, the response MUST be silently discarded.
応答を受信すると、クライアントトランスポートは上部のViaヘッダーフィールド値を調べます。そのヘッダーフィールド値の "sent-by"パラメータの値が、クライアントトランスポートが要求に挿入するように構成されている値に対応していない場合、応答は黙って破棄されなければなりません（MUST）。
If there are any client transactions in existence, the client transport uses the matching procedures of Section 17.1.3 to attempt to match the response to an existing transaction. If there is a match, the response MUST be passed to that transaction. Otherwise, the response MUST be passed to the core (whether it be stateless proxy, stateful proxy, or UA) for further processing. Handling of these "stray" responses is dependent on the core (a proxy will forward them, while a UA will discard, for example).
クライアントトランザクションが存在する場合、クライアントトランスポートはセクション17.1.3のマッチング手順を使用して、既存のトランザクションへの応答のマッチングを試みます。一致がある場合、そのトランザクションに応答を渡す必要があります。それ以外の場合は、応答をコア（ステートレスプロキシ、ステートフルプロキシ、UAのいずれか）に渡して、さらに処理する必要があります。これらの「迷子」応答の処理はコアに依存します（たとえば、UAが破棄する一方で、プロキシはそれらを転送します）。
A server SHOULD be prepared to receive requests on any IP address, port and transport combination that can be the result of a DNS lookup on a SIP or SIPS URI [4] that is handed out for the purposes of communicating with that server. In this context, "handing out" includes placing a URI in a Contact header field in a REGISTER request or a redirect response, or in a Record-Route header field in a request or response. A URI can also be "handed out" by placing it on a web page or business card. It is also RECOMMENDED that a server listen for requests on the default SIP ports (5060 for TCP and UDP, 5061 for TLS over TCP) on all public interfaces. The typical exception would be private networks, or when multiple server instances are running on the same host. For any port and interface that a server listens on for UDP, it MUST listen on that same port and interface for TCP. This is because a message may need to be sent using TCP, rather than UDP, if it is too large. As a result, the converse is not true. A server need not listen for UDP on a particular address and port just because it is listening on that same address and port for TCP. There may, of course, be other reasons why a server needs to listen for UDP on a particular address and port.
サーバーは、そのサーバーとの通信のために渡されるSIPまたはSIPS URI [4]でのDNSルックアップの結果である可能性がある任意のIPアドレス、ポート、およびトランスポートの組み合わせでリクエストを受信する準備ができている必要があります。このコンテキストでは、「配布」には、REGISTER要求またはリダイレクト応答のContactヘッダーフィールド、または要求または応答のRecord-RouteヘッダーフィールドにURIを配置することが含まれます。 URIは、Webページまたは名刺に配置することで「配布」することもできます。また、サーバーがすべてのパブリックインターフェイス上のデフォルトのSIPポート（TCPおよびUDPの場合は5060、TLS over TCPの場合は5061）で要求をリッスンすることもお勧めします。典型的な例外は、プライベートネットワーク、または複数のサーバーインスタンスが同じホスト上で実行されている場合です。サーバーがUDPをリッスンするすべてのポートとインターフェイスについては、同じポートとインターフェイスでTCPをリッスンする必要があります。これは、メッセージが大きすぎる場合、UDPではなくTCPを使用してメッセージを送信する必要があるためです。その結果、その逆は成り立ちません。サーバーは、同じアドレスとポートでTCPをリッスンしているという理由だけで、特定のアドレスとポートでUDPをリッスンする必要はありません。もちろん、サーバーが特定のアドレスとポートでUDPをリッスンする必要がある理由は他にもあります。
When the server transport receives a request over any transport, it MUST examine the value of the "sent-by" parameter in the top Via header field value. If the host portion of the "sent-by" parameter contains a domain name, or if it contains an IP address that differs from the packet source address, the server MUST add a "received" parameter to that Via header field value. This parameter MUST contain the source address from which the packet was received. This is to assist the server transport layer in sending the response, since it must be sent to the source IP address from which the request came.
サーバートランスポートは、トランスポートを介して要求を受信すると、上部のViaヘッダーフィールド値の "sent-by"パラメーターの値を検査する必要があります。 「sent-by」パラメータのホスト部分にドメイン名が含まれている場合、またはパケットの送信元アドレスとは異なるIPアドレスが含まれている場合、サーバーはそのViaヘッダーフィールド値に「received」パラメータを追加する必要があります。このパラメーターには、パケットの受信元の送信元アドレスを含める必要があります。これは、リクエストの送信元のIPアドレスに送信する必要があるため、サーバートランスポート層が応答を送信するのを支援するためのものです。
Consider a request received by the server transport which looks like, in part:
サーバートランスポートによって受信された、次のようなリクエストについて考えてみます。
INVITE sip:bob@Biloxi.com SIP/2.0
Via: SIP/2.0/UDP bobspc.biloxi.com:5060
The request is received with a source IP address of 192.0.2.4. Before passing the request up, the transport adds a "received" parameter, so that the request would look like, in part:
要求は、192.0.2.4のソースIPアドレスで受信されます。リクエストを渡す前に、トランスポートは「受信」パラメータを追加して、リクエストが次のようになるようにします。
INVITE sip:bob@Biloxi.com SIP/2.0
Via: SIP/2.0/UDP bobspc.biloxi.com:5060;received=192.0.2.4
Next, the server transport attempts to match the request to a server transaction. It does so using the matching rules described in Section 17.2.3. If a matching server transaction is found, the request is passed to that transaction for processing. If no match is found, the request is passed to the core, which may decide to construct a new server transaction for that request. Note that when a UAS core sends a 2xx response to INVITE, the server transaction is destroyed. This means that when the ACK arrives, there will be no matching server transaction, and based on this rule, the ACK is passed to the UAS core, where it is processed.
次に、サーバートランスポートは要求をサーバートランザクションに一致させようとします。これは、17.2.3項で説明されている一致ルールを使用して行われます。一致するサーバートランザクションが見つかった場合、リクエストはそのトランザクションに渡されて処理されます。一致するものが見つからない場合、要求はコアに渡され、その要求に対して新しいサーバートランザクションを構築することが決定される場合があります。 UASコアがINVITEに2xx応答を送信すると、サーバートランザクションが破棄されることに注意してください。つまり、ACKが到着すると、一致するサーバートランザクションは存在せず、このルールに基づいて、ACKはUASコアに渡され、そこで処理されます。
The server transport uses the value of the top Via header field in order to determine where to send a response. It MUST follow the following process:
サーバートランスポートは、応答の送信先を決定するために、先頭のViaヘッダーフィールドの値を使用します。次のプロセスに従う必要があります。
o If the "sent-protocol" is a reliable transport protocol such as TCP or SCTP, or TLS over those, the response MUST be sent using the existing connection to the source of the original request that created the transaction, if that connection is still open. This requires the server transport to maintain an association between server transactions and transport connections. If that connection is no longer open, the server SHOULD open a connection to the IP address in the "received" parameter, if present, using the port in the "sent-by" value, or the default port for that transport, if no port is specified. If that connection attempt fails, the server SHOULD use the procedures in [4] for servers in order to determine the IP address and port to open the connection and send the response to.
o 「送信プロトコル」がTCPやSCTPなどの信頼できるトランスポートプロトコル、またはそれらを介したTLSである場合、既存の接続を使用して、トランザクションを作成した元の要求のソースへの応答を送信する必要があります（その接続がまだ開いている場合）。 。これには、サーバートランスポートがサーバートランザクションとトランスポート接続の間の関連付けを維持する必要があります。その接続が開かれていない場合、サーバーは、「送信済み」値のポートを使用して、「受信」パラメータのIPアドレスへの接続を開く必要があります（存在しない場合はそのトランスポートのデフォルトのポートを使用）。ポートを指定します。その接続試行が失敗した場合、サーバーは、接続を開いて応答を送信するIPアドレスとポートを決定するために、サーバーの[4]の手順を使用する必要があります（SHOULD）。
o Otherwise, if the Via header field value contains a "maddr" parameter, the response MUST be forwarded to the address listed there, using the port indicated in "sent-by", or port 5060 if none is present. If the address is a multicast address, the response SHOULD be sent using the TTL indicated in the "ttl" parameter, or with a TTL of 1 if that parameter is not present.
o それ以外の場合、Viaヘッダーフィールドの値に「maddr」パラメーターが含まれていると、「sent-by」で示されたポート、または存在しない場合はポート5060を使用して、そこにリストされたアドレスに応答を転送する必要があります。アドレスがマルチキャストアドレスの場合、応答は「ttl」パラメータで指定されたTTLを使用して送信する必要があります。そのパラメータが存在しない場合は、TTLを1にして送信してください。
o Otherwise (for unreliable unicast transports), if the top Via has a "received" parameter, the response MUST be sent to the address in the "received" parameter, using the port indicated in the "sent-by" value, or using port 5060 if none is specified explicitly. If this fails, for example, elicits an ICMP "port unreachable" response, the procedures of Section 5 of [4] SHOULD be used to determine where to send the response.
o それ以外の場合（信頼性の低いユニキャストトランスポートの場合）、上部のViaに "received"パラメータがある場合、 "sent-by"値で示されたポートを使用するか、ポートを使用して、応答を "received"パラメータのアドレスに送信する必要があります。明示的に指定されていない場合は5060。これが失敗した場合、たとえば、ICMPの「ポート到達不能」応答が発生した場合、[4]のセクション5の手順を使用して、応答の送信先を決定する必要があります（SHOULD）。
o Otherwise, if it is not receiver-tagged, the response MUST be sent to the address indicated by the "sent-by" value, using the procedures in Section 5 of [4].
o それ以外の場合、受信者のタグが付いていない場合、[4]のセクション5の手順を使用して、「送信者」の値で示されたアドレスに応答を送信する必要があります。
In the case of message-oriented transports (such as UDP), if the message has a Content-Length header field, the message body is assumed to contain that many bytes. If there are additional bytes in the transport packet beyond the end of the body, they MUST be discarded. If the transport packet ends before the end of the message body, this is considered an error. If the message is a response, it MUST be discarded. If the message is a request, the element SHOULD generate a 400 (Bad Request) response. If the message has no Content-Length header field, the message body is assumed to end at the end of the transport packet.
メッセージ指向のトランスポート（UDPなど）の場合、メッセージにContent-Lengthヘッダーフィールドがある場合、メッセージ本文にはそのバイト数が含まれていると想定されます。本文の終わりを超えてトランスポートパケットに追加のバイトがある場合、それらは破棄されなければなりません（MUST）。トランスポートパケットがメッセージ本文の終了前に終了する場合、これはエラーと見なされます。メッセージが応答の場合は、破棄する必要があります。メッセージがリクエストの場合、要素は400（Bad Request）レスポンスを生成する必要があります（SHOULD）。メッセージにContent-Lengthヘッダーフィールドがない場合、メッセージ本文はトランスポートパケットの最後で終了すると見なされます。
In the case of stream-oriented transports such as TCP, the Content-Length header field indicates the size of the body. The Content-Length header field MUST be used with stream oriented transports.
TCPなどのストリーム指向のトランスポートの場合、Content-Lengthヘッダーフィールドは本文のサイズを示します。 Content-Lengthヘッダーフィールドは、ストリーム指向のトランスポートで使用する必要があります。
Error handling is independent of whether the message was a request or response.
エラー処理は、メッセージが要求であるか応答であるかには依存しません。
If the transport user asks for a message to be sent over an unreliable transport, and the result is an ICMP error, the behavior depends on the type of ICMP error. Host, network, port or protocol unreachable errors, or parameter problem errors SHOULD cause the transport layer to inform the transport user of a failure in sending. Source quench and TTL exceeded ICMP errors SHOULD be ignored.
トランスポートユーザーが信頼できないトランスポートを介してメッセージを送信するように要求し、その結果がICMPエラーである場合、動作はICMPエラーの種類によって異なります。ホスト、ネットワーク、ポート、プロトコルの到達不能エラー、またはパラメーターの問題エラーにより、トランスポート層はトランスポートユーザーに送信の失敗を通知する必要があります（SHOULD）。ソースの抑制とTTLがICMPエラーを超えた場合は無視してください。
If the transport user asks for a request to be sent over a reliable transport, and the result is a connection failure, the transport layer SHOULD inform the transport user of a failure in sending.
トランスポートユーザーが信頼できるトランスポートを介して送信されるリクエストを要求し、その結果が接続失敗である場合、トランスポート層は送信の失敗をトランスポートユーザーに通知する必要があります（SHOULD）。
19 Common Message Components
19共通メッセージコンポーネント
There are certain components of SIP messages that appear in various places within SIP messages (and sometimes, outside of them) that merit separate discussion.
SIPメッセージには、SIPメッセージのさまざまな場所（場合によってはメッセージの外部）に表示される特定のコンポーネントがあり、個別に説明する必要があります。
A SIP or SIPS URI identifies a communications resource. Like all URIs, SIP and SIPS URIs may be placed in web pages, email messages, or printed literature. They contain sufficient information to initiate and maintain a communication session with the resource.
SIPまたはSIPS URIは、通信リソースを識別します。すべてのURIと同様に、SIPおよびSIPS URIは、Webページ、電子メールメッセージ、または印刷物に配置できます。これらには、リソースとの通信セッションを開始および維持するための十分な情報が含まれています。
Examples of communications resources include the following:
通信リソースの例には次のものがあります。
o a user of an online service
o オンラインサービスのユーザー
o an appearance on a multi-line phone
o 複数回線の電話での外観
o a mailbox on a messaging system
o メッセージングシステム上のメールボックス
o a PSTN number at a gateway service
o ゲートウェイサービスでのPSTN番号
o a group (such as "sales" or "helpdesk") in an organization
o 組織内のグループ（「販売」や「ヘルプデスク」など）
A SIPS URI specifies that the resource be contacted securely. This means, in particular, that TLS is to be used between the UAC and the domain that owns the URI. From there, secure communications are used to reach the user, where the specific security mechanism depends on the policy of the domain. Any resource described by a SIP URI can be "upgraded" to a SIPS URI by just changing the scheme, if it is desired to communicate with that resource securely.
SIPS URIは、リソースに安全に接続することを指定します。これは特に、UACとURIを所有するドメインの間でTLSが使用されることを意味します。そこから、ユーザーに到達するために安全な通信が使用されます。特定のセキュリティメカニズムはドメインのポリシーに依存します。 SIP URIで記述されたリソースは、そのリソースと安全に通信する必要がある場合は、スキームを変更するだけでSIPS URIに「アップグレード」できます。
The "sip:" and "sips:" schemes follow the guidelines in RFC 2396 [5]. They use a form similar to the mailto URL, allowing the specification of SIP request-header fields and the SIP message-body. This makes it possible to specify the subject, media type, or urgency of sessions initiated by using a URI on a web page or in an email message. The formal syntax for a SIP or SIPS URI is presented in Section 25. Its general form, in the case of a SIP URI, is:
"sip："および "sips："スキームは、RFC 2396 [5]のガイドラインに従います。それらは、mailto URLに似た形式を使用して、SIPリクエストヘッダーフィールドとSIPメッセージ本文を指定できるようにします。これにより、Webページまたは電子メールメッセージでURIを使用して開始されたセッションの件名、メディアタイプ、または緊急度を指定できます。 SIPまたはSIPS URIの正式な構文は、セクション25に示されています。SIPURIの場合、その一般的な形式は次のとおりです。
sip:user:password@host:port;uri-parameters?headers
The format for a SIPS URI is the same, except that the scheme is "sips" instead of sip. These tokens, and some of the tokens in their expansions, have the following meanings:
SIPS URIの形式は同じですが、スキームがsipではなく「sips」である点が異なります。これらのトークン、およびそれらの拡張の一部のトークンには、次の意味があります。
user: The identifier of a particular resource at the host being addressed. The term "host" in this context frequently refers to a domain. The "userinfo" of a URI consists of this user field, the password field, and the @ sign following them. The userinfo part of a URI is optional and MAY be absent when the destination host does not have a notion of users or when the host itself is the resource being identified. If the @ sign is present in a SIP or SIPS URI, the user field MUST NOT be empty.
user：アドレス指定されているホストの特定のリソースの識別子。この文脈での「ホスト」という用語は、しばしばドメインを指します。 URIの「userinfo」は、このユーザーフィールド、パスワードフィールド、およびそれらに続く@記号で構成されます。 URIのuserinfo部分はオプションであり、宛先ホストにユーザーの概念がない場合、またはホスト自体が識別されるリソースである場合は存在しない場合があります。 @記号がSIPまたはSIPS URIに存在する場合、ユーザーフィールドを空にすることはできません。
If the host being addressed can process telephone numbers, for instance, an Internet telephony gateway, a telephone-subscriber field defined in RFC 2806 [9] MAY be used to populate the user field. There are special escaping rules for encoding telephone-subscriber fields in SIP and SIPS URIs described in Section 19.1.2.
アドレス指定されているホストが電話番号、たとえばインターネットテレフォニーゲートウェイを処理できる場合、RFC 2806 [9]で定義されている電話加入者フィールドを使用して、ユーザーフィールドを設定できます。セクション19.1.2で説明されているSIPおよびSIPS URIの電話加入者フィールドをエンコードするための特別なエスケープルールがあります。
password: A password associated with the user. While the SIP and SIPS URI syntax allows this field to be present, its use is NOT RECOMMENDED, because the passing of authentication information in clear text (such as URIs) has proven to be a security risk in almost every case where it has been used. For instance, transporting a PIN number in this field exposes the PIN.
password：ユーザーに関連付けられたパスワード。 SIPおよびSIPS URI構文ではこのフィールドが存在することが許可されていますが、クリアテキスト（URIなど）での認証情報の受け渡しは、使用されているほとんどすべてのケースでセキュリティリスクであることが証明されているため、このフィールドの使用は推奨されません。 。たとえば、このフィールドでPIN番号を転送すると、PINが公開されます。
Note that the password field is just an extension of the user portion. Implementations not wishing to give special significance to the password portion of the field MAY simply treat "user:password" as a single string.
パスワードフィールドはユーザー部分の拡張にすぎないことに注意してください。フィールドのパスワード部分に特別な意味を与えたくない実装は、単に "user：password"を単一の文字列として扱うことができます。
host: The host providing the SIP resource. The host part contains either a fully-qualified domain name or numeric IPv4 or IPv6 address. Using the fully-qualified domain name form is RECOMMENDED whenever possible.
host：SIPリソースを提供するホスト。ホスト部分には、完全修飾ドメイン名または数値のIPv4またはIPv6アドレスが含まれます。可能な限り、完全修飾ドメイン名形式を使用することをお勧めします。
port: The port number where the request is to be sent.
port：リクエストが送信されるポート番号。
URI parameters: Parameters affecting a request constructed from the URI.
URIパラメータ：URIから作成されたリクエストに影響するパラメータ。
URI parameters are added after the hostport component and are separated by semi-colons.
URIパラメータはhostportコンポーネントの後に追加され、セミコロンで区切られます。
URI parameters take the form:
URIパラメータの形式は次のとおりです。
parameter-name "=" parameter-value
パラメータ名 "="パラメータ値
Even though an arbitrary number of URI parameters may be included in a URI, any given parameter-name MUST NOT appear more than once.
任意の数のURIパラメーターをURIに含めることができますが、特定のパラメーター名は2回以上指定してはなりません。
This extensible mechanism includes the transport, maddr, ttl, user, method and lr parameters.
この拡張可能なメカニズムには、transport、maddr、ttl、user、method、lrパラメータが含まれます。
The transport parameter determines the transport mechanism to be used for sending SIP messages, as specified in [4]. SIP can use any network transport protocol. Parameter names are defined for UDP (RFC 768 [14]), TCP (RFC 761 [15]), and SCTP (RFC 2960 [16]). For a SIPS URI, the transport parameter MUST indicate a reliable transport.
トランスポートパラメータは、[4]で指定されているように、SIPメッセージの送信に使用されるトランスポートメカニズムを決定します。 SIPは任意のネットワーク転送プロトコルを使用できます。パラメータ名は、UDP（RFC 768 [14]）、TCP（RFC 761 [15]）、およびSCTP（RFC 2960 [16]）に対して定義されています。 SIPS URIの場合、トランスポートパラメータは信頼できるトランスポートを示している必要があります。
The maddr parameter indicates the server address to be contacted for this user, overriding any address derived from the host field. When an maddr parameter is present, the port and transport components of the URI apply to the address indicated in the maddr parameter value. [4] describes the proper interpretation of the transport, maddr, and hostport in order to obtain the destination address, port, and transport for sending a request.
maddrパラメータは、このユーザーの連絡先となるサーバーアドレスを示し、ホストフィールドから取得したアドレスを上書きします。 maddrパラメータが存在する場合、URIのポートおよびトランスポートコンポーネントは、maddrパラメータ値で指定されたアドレスに適用されます。 [4]は、リクエストを送信するための宛先アドレス、ポート、およびトランスポートを取得するための、トランスポート、maddr、およびhostportの適切な解釈について説明しています。
The maddr field has been used as a simple form of loose source routing. It allows a URI to specify a proxy that must be traversed en-route to the destination. Continuing to use the maddr parameter this way is strongly discouraged (the mechanisms that enable it are deprecated). Implementations should instead use the Route mechanism described in this document, establishing a pre-existing route set if necessary (see Section 8.1.1.1). This provides a full URI to describe the node to be traversed.
maddrフィールドは、ルーズソースルーティングの単純な形式として使用されています。 URIは、宛先への途中で通過する必要があるプロキシを指定できます。この方法でmaddrパラメータを引き続き使用することは強くお勧めしません（これを有効にするメカニズムは非推奨です）。実装では、代わりに、このドキュメントで説明されているルートメカニズムを使用して、必要に応じて既存のルートセットを確立する必要があります（セクション8.1.1.1を参照）。これは、トラバースされるノードを説明する完全なURIを提供します。
The ttl parameter determines the time-to-live value of the UDP multicast packet and MUST only be used if maddr is a multicast address and the transport protocol is UDP. For example, to specify a call to alice@atlanta.com using multicast to 239.255.255.1 with a ttl of 15, the following URI would be used:
ttlパラメータは、UDPマルチキャストパケットの存続時間の値を決定し、maddrがマルチキャストアドレスであり、トランスポートプロトコルがUDPである場合にのみ使用する必要があります。たとえば、ttlが15の239.255.255.1へのマルチキャストを使用してalice@atlanta.comへの呼び出しを指定するには、次のURIを使用します。
sip:alice@atlanta.com;maddr=239.255.255.1;ttl=15
The set of valid telephone-subscriber strings is a subset of valid user strings. The user URI parameter exists to distinguish telephone numbers from user names that happen to look like telephone numbers. If the user string contains a telephone number formatted as a telephone-subscriber, the user parameter value "phone" SHOULD be present. Even without this parameter, recipients of SIP and SIPS URIs MAY interpret the pre-@ part as a telephone number if local restrictions on the name space for user name allow it.
有効な電話加入者文字列のセットは、有効なユーザー文字列のサブセットです。ユーザーURIパラメーターは、電話番号を電話番号のように見えるユーザー名から区別するために存在します。ユーザー文字列に電話加入者としてフォーマットされた電話番号が含まれている場合、ユーザーパラメータ値「phone」が存在する必要があります。このパラメーターがない場合でも、SIPおよびSIPS URIの受信者は、ユーザー名の名前空間のローカル制限で許可されている場合、pre- @の部分を電話番号として解釈する場合があります。
The method of the SIP request constructed from the URI can be specified with the method parameter.
URIから構築されたSIPリクエストのメソッドは、methodパラメータで指定できます。
The lr parameter, when present, indicates that the element responsible for this resource implements the routing mechanisms specified in this document. This parameter will be used in the URIs proxies place into Record-Route header field values, and may appear in the URIs in a pre-existing route set.
lrパラメータは、存在する場合、このリソースを担当する要素が、このドキュメントで指定されているルーティングメカニズムを実装することを示します。このパラメーターはRecord-Routeヘッダーフィールド値に配置されるURIプロキシで使用され、既存のルートセットのURIに表示される場合があります。
This parameter is used to achieve backwards compatibility with systems implementing the strict-routing mechanisms of RFC 2543 and the rfc2543bis drafts up to bis-05. An element preparing to send a request based on a URI not containing this parameter can assume the receiving element implements strict-routing and reformat the message to preserve the information in the Request-URI.
このパラメータは、RFC 2543およびbis-05までのrfc2543bisドラフトの完全ルーティングメカニズムを実装するシステムとの下位互換性を実現するために使用されます。このパラメーターを含まないURIに基づいて要求を送信する準備をしている要素は、受信要素が厳密なルーティングを実装していると想定し、メッセージを再フォーマットしてRequest-URIの情報を保持できます。
Since the uri-parameter mechanism is extensible, SIP elements MUST silently ignore any uri-parameters that they do not understand.
URIパラメータメカニズムは拡張可能であるため、SIP要素は、理解できないURIパラメータを暗黙的に無視する必要があります。
Headers: Header fields to be included in a request constructed from the URI.
ヘッダー：URIから作成されたリクエストに含まれるヘッダーフィールド。
Headers fields in the SIP request can be specified with the "?" mechanism within a URI. The header names and values are encoded in ampersand separated hname = hvalue pairs. The special hname "body" indicates that the associated hvalue is the message-body of the SIP request.
SIPリクエストのヘッダーフィールドは「？」で指定できます。 URI内のメカニズム。ヘッダーの名前と値は、アンパサンドで区切られたhname = hvalueのペアでエンコードされます。特別なhname "body"は、関連付けられたhvalueがSIPリクエストのメッセージ本文であることを示します。
Table 1 summarizes the use of SIP and SIPS URI components based on the context in which the URI appears. The external column describes URIs appearing anywhere outside of a SIP message, for instance on a web page or business card. Entries marked "m" are mandatory, those marked "o" are optional, and those marked "-" are not allowed. Elements processing URIs SHOULD ignore any disallowed components if they are present. The second column indicates the default value of an optional element if it is not present. "--" indicates that the element is either not optional, or has no default value.
表1は、URIが出現するコンテキストに基づいたSIPおよびSIPS URIコンポーネントの使用をまとめたものです。外部列は、Webページやビジネスカードなど、SIPメッセージの外部に表示されるURIを示します。 「m」の付いたエントリは必須、「o」の付いたエントリはオプション、「-」の付いたエントリは使用できません。 URIを処理する要素は、許可されていないコンポーネントがあっても無視する必要があります（SHOULD）。 2番目の列は、オプションの要素が存在しない場合のデフォルト値を示します。 「-」は、要素がオプションではないか、デフォルト値がないことを示します。
URIs in Contact header fields have different restrictions depending on the context in which the header field appears. One set applies to messages that establish and maintain dialogs (INVITE and its 200 (OK) response). The other applies to registration and redirection messages (REGISTER, its 200 (OK) response, and 3xx class responses to any method).
ContactヘッダーフィールドのURIには、ヘッダーフィールドが表示されるコンテキストに応じて異なる制限があります。 1つのセットは、ダイアログ（INVITEとその200（OK）応答）を確立および維持するメッセージに適用されます。もう1つは登録メッセージとリダイレクトメッセージに適用されます（REGISTER、その200（OK）応答、および任意のメソッドに対する3xxクラス応答）。
dialog
reg./redir. Contact/
default Req.-URI To From Contact R-R/Route external
user -- o o o o o o
password -- o o o o o o
host -- m m m m m m
port (1) o - - o o o
user-param ip o o o o o o
method INVITE - - - - - o
maddr-param -- o - - o o o
ttl-param 1 o - - o - o
transp.-param (2) o - - o o o
lr-param -- o - - - o o
other-param -- o o o o o o
headers -- - - - o - o
(1): The default port value is transport and scheme dependent. The default is 5060 for sip: using UDP, TCP, or SCTP. The default is 5061 for sip: using TLS over TCP and sips: over TCP.
（1）：デフォルトのポート値はトランスポートとスキームに依存します。 sipのデフォルトは5060です。UDP、TCP、またはSCTPを使用します。デフォルトは、sip：TLS over TCPおよびsips：over TCPを使用する場合は5061です。
(2): The default transport is scheme dependent. For sip:, it is UDP. For sips:, it is TCP.
（2）：デフォルトのトランスポートはスキームに依存します。 sip：の場合、これはUDPです。 sipsの場合：TCPです。
Table 1: Use and default values of URI components for SIP header field values, Request-URI and references
表1：SIPヘッダーフィールド値、Request-URI、および参照のURIコンポーネントの使用とデフォルト値
SIP follows the requirements and guidelines of RFC 2396 [5] when defining the set of characters that must be escaped in a SIP URI, and uses its ""%" HEX HEX" mechanism for escaping. From RFC 2396 [5]:
SIPは、SIP URIでエスケープする必要がある文字のセットを定義するときに、RFC 2396 [5]の要件とガイドラインに従い、エスケープに「 "％" HEX HEX」メカニズムを使用します。 RFC 2396 [5]から：
The set of characters actually reserved within any given URI component is defined by that component. In general, a character is reserved if the semantics of the URI changes if the character is replaced with its escaped US-ASCII encoding [5]. Excluded US-ASCII characters (RFC 2396 [5]), such as space and control characters and characters used as URI delimiters, also MUST be escaped. URIs MUST NOT contain unescaped space and control characters.
特定のURIコンポーネント内で実際に予約されている文字のセットは、そのコンポーネントによって定義されます。一般に、文字がエスケープされたUS-ASCIIエンコーディングで置き換えられた場合にURIのセマンティクスが変更されると、文字は予約されます[5]。スペースや制御文字、URI区切り文字として使用される文字など、除外されたUS-ASCII文字（RFC 2396 [5]）もエスケープする必要があります。 URIには、エスケープされていないスペースと制御文字を含めることはできません。
For each component, the set of valid BNF expansions defines exactly which characters may appear unescaped. All other characters MUST be escaped.
各コンポーネントについて、有効なBNF拡張のセットは、エスケープされていないように見える文字を正確に定義します。他のすべての文字はエスケープする必要があります。
For example, "@" is not in the set of characters in the user component, so the user "j@s0n" must have at least the @ sign encoded, as in "j%40s0n".
たとえば、「@」はユーザーコンポーネントの文字セットに含まれていないため、「j％40s0n」のように、ユーザー「j @ s0n」は少なくとも@記号をエンコードする必要があります。
Expanding the hname and hvalue tokens in Section 25 show that all URI reserved characters in header field names and values MUST be escaped.
セクション25で名前と値のトークンを展開すると、ヘッダーフィールドの名前と値のすべてのURI予約文字をエスケープする必要があることが示されます。
The telephone-subscriber subset of the user component has special escaping considerations. The set of characters not reserved in the RFC 2806 [9] description of telephone-subscriber contains a number of characters in various syntax elements that need to be escaped when used in SIP URIs. Any characters occurring in a telephone-subscriber that do not appear in an expansion of the BNF for the user rule MUST be escaped.
ユーザーコンポーネントの電話加入者サブセットには、特別なエスケープの考慮事項があります。電話加入者のRFC 2806 [9]の説明で予約されていない文字のセットには、SIP URIで使用するときにエスケープする必要があるさまざまな構文要素の文字が含まれています。電話加入者で発生し、ユーザールールのBNFの展開に現れない文字はエスケープする必要があります。
Note that character escaping is not allowed in the host component of a SIP or SIPS URI (the % character is not valid in its expansion). This is likely to change in the future as requirements for Internationalized Domain Names are finalized. Current implementations MUST NOT attempt to improve robustness by treating received escaped characters in the host component as literally equivalent to their unescaped counterpart. The behavior required to meet the requirements of IDN may be significantly different.
SIPまたはSIPS URIのホストコンポーネントでは文字のエスケープは許可されていないことに注意してください（％文字はその拡張では無効です）。国際化ドメイン名の要件が確定すると、これは将来変更される可能性があります。現在の実装では、ホストコンポーネントで受信したエスケープ文字を、エスケープされていない対応文字と同等に扱うことで、堅牢性を向上させてはなりません。 IDNの要件を満たすために必要な動作は、大幅に異なる場合があります。
sip:alice@atlanta.com
sip:alice:secretword@atlanta.com;transport=tcp
sips:alice@atlanta.com?subject=project%20x&priority=urgent
sip:+1-212-555-1212:1234@gateway.com;user=phone
sips:1212@gateway.com
sip:alice@192.0.2.4
sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com
sip:alice;day=tuesday@atlanta.com
The last sample URI above has a user field value of "alice;day=tuesday". The escaping rules defined above allow a semicolon to appear unescaped in this field. For the purposes of this protocol, the field is opaque. The structure of that value is only useful to the SIP element responsible for the resource.
上記の最後のサンプルURIのユーザーフィールド値は「alice; day = tuesday」です。上記で定義したエスケープルールでは、セミコロンをこのフィールドにエスケープせずに表示できます。このプロトコルでは、フィールドは不透明です。その値の構造は、リソースを担当するSIP要素にのみ役立ちます。
Some operations in this specification require determining whether two SIP or SIPS URIs are equivalent. In this specification, registrars need to compare bindings in Contact URIs in REGISTER requests (see Section 10.3.). SIP and SIPS URIs are compared for equality according to the following rules:
この仕様の一部の操作では、2つのSIP URIまたはSIPS URIが同等であるかどうかを判断する必要があります。この仕様では、レジストラはREGISTERリクエストのContact URIのバインディングを比較する必要があります（セクション10.3を参照）。 SIPおよびSIPS URIは、次のルールに従って等しいかどうか比較されます。
o A SIP and SIPS URI are never equivalent.
o SIPとSIPS URIが同じになることはありません。
o Comparison of the userinfo of SIP and SIPS URIs is case-sensitive. This includes userinfo containing passwords or formatted as telephone-subscribers. Comparison of all other components of the URI is case-insensitive unless explicitly defined otherwise.
o SIPとSIPS URIのuserinfoの比較では、大文字と小文字が区別されます。これには、パスワードを含む、または電話加入者としてフォーマットされたuserinfoが含まれます。 URIの他のすべてのコンポーネントの比較は、特に明示的に定義されていない限り、大文字と小文字を区別しません。
o The ordering of parameters and header fields is not significant in comparing SIP and SIPS URIs.
o パラメータとヘッダーフィールドの順序は、SIP URIとSIPS URIの比較では重要ではありません。
o Characters other than those in the "reserved" set (see RFC 2396 [5]) are equivalent to their ""%" HEX HEX" encoding.
o 「予約済み」セット（RFC 2396 [5]を参照）以外の文字は、「 "％" HEX HEX」エンコーディングと同等です。
o An IP address that is the result of a DNS lookup of a host name does not match that host name.
o ホスト名のDNSルックアップの結果であるIPアドレスがそのホスト名と一致しません。
o For two URIs to be equal, the user, password, host, and port components must match.
o 2つのURIが等しいためには、ユーザー、パスワード、ホスト、およびポートのコンポーネントが一致している必要があります。
A URI omitting the user component will not match a URI that includes one. A URI omitting the password component will not match a URI that includes one.
ユーザーコンポーネントを省略したURIは、それを含むURIと一致しません。パスワードコンポーネントを省略したURIは、それを含むURIと一致しません。
A URI omitting any component with a default value will not match a URI explicitly containing that component with its default value. For instance, a URI omitting the optional port component will not match a URI explicitly declaring port 5060. The same is true for the transport-parameter, ttl-parameter, user-parameter, and method components.
デフォルト値を持つコンポーネントを省略したURIは、デフォルト値を持つコンポーネントを明示的に含むURIとは一致しません。たとえば、オプションのポートコンポーネントを省略したURIは、ポート5060を明示的に宣言したURIと一致しません。トランスポートパラメーター、ttlパラメーター、ユーザーパラメーター、およびメソッドコンポーネントについても同様です。
Defining sip:user@host to not be equivalent to sip:user@host:5060 is a change from RFC 2543. When deriving addresses from URIs, equivalent addresses are expected from equivalent URIs. The URI sip:user@host:5060 will always resolve to port 5060. The URI sip:user@host may resolve to other ports through the DNS SRV mechanisms detailed in [4].
sip：user @ hostをsip：user @ host：5060と等しくないように定義することは、RFC 2543からの変更です。URIからアドレスを取得する場合、同等のURIから同等のアドレスが期待されます。 URI sip：user @ host：5060は常にポート5060に解決されます。URIsip：user @ hostは、[4]で詳述されているDNS SRVメカニズムを通じて他のポートに解決される場合があります。
o URI uri-parameter components are compared as follows:
o URI uri-parameterコンポーネントは次のように比較されます。
- Any uri-parameter appearing in both URIs must match.
- 両方のURIに現れるURIパラメータはすべて一致する必要があります。
- A user, ttl, or method uri-parameter appearing in only one URI never matches, even if it contains the default value.
- デフォルト値が含まれている場合でも、1つのURIのみに表示されるユーザー、ttl、またはメソッドuri-parameterは一致しません。
- A URI that includes an maddr parameter will not match a URI that contains no maddr parameter.
- maddrパラメータを含むURIは、maddrパラメータを含まないURIとは一致しません。
- All other uri-parameters appearing in only one URI are ignored when comparing the URIs.
- URIを比較するとき、1つのURIのみに現れる他のすべてのuriパラメータは無視されます。
o URI header components are never ignored. Any present header component MUST be present in both URIs and match for the URIs to match. The matching rules are defined for each header field in Section 20.
o URIヘッダーコンポーネントが無視されることはありません。存在するヘッダーコンポーネントは両方のURIに存在し、URIが一致するために一致する必要があります。一致ルールは、セクション20で各ヘッダーフィールドに対して定義されます。
The URIs within each of the following sets are equivalent:
以下の各セット内のURIは同等です。
sip:%61lice@atlanta.com;transport=TCP
sip:alice@AtLanTa.CoM;Transport=tcp
sip:carol@chicago.com
sip:carol@chicago.com;newparam=5
sip:carol@chicago.com;security=on
sip:biloxi.com;transport=tcp;method=REGISTER?to=sip:bob%40biloxi.com
sip:biloxi.com;method=REGISTER;transport=tcp?to=sip:bob%40biloxi.com
sip:alice@atlanta.com?subject=project%20x&priority=urgent
sip:alice@atlanta.com?priority=urgent&subject=project%20x
The URIs within each of the following sets are not equivalent:
次の各セット内のURIは同等ではありません。
SIP:ALICE@AtLanTa.CoM;Transport=udp (different usernames)
sip:alice@AtLanTa.CoM;Transport=UDP
sip:bob@biloxi.com (can resolve to different ports)
sip:bob@biloxi.com:5060
sip:bob@biloxi.com (can resolve to different transports)
sip:bob@biloxi.com;transport=udp
sip:bob@biloxi.com (can resolve to different port and transports)
sip:bob@biloxi.com:6000;transport=tcp
sip:carol@chicago.com (different header component)
sip:carol@chicago.com?Subject=next%20meeting
sip:bob@phone21.boxesbybob.com (even though that's what
sip:bob@192.0.2.4 phone21.boxesbybob.com resolves to)
Note that equality is not transitive:
等式は推移的ではないことに注意してください。
o sip:carol@chicago.com and sip:carol@chicago.com;security=on are equivalent
o sip：carol@chicago.comとsip：carol@chicago.com; security = onは同等です
o sip:carol@chicago.com and sip:carol@chicago.com;security=off are equivalent
o sip：carol@chicago.comとsip：carol@chicago.com; security = offは同等です
o sip:carol@chicago.com;security=on and sip:carol@chicago.com;security=off are not equivalent
o sip：carol@chicago.com; security = onとsip：carol@chicago.com; security = offは同等ではありません
An implementation needs to take care when forming requests directly from a URI. URIs from business cards, web pages, and even from sources inside the protocol such as registered contacts may contain inappropriate header fields or body parts.
実装は、URIから直接要求を形成するときに注意する必要があります。名刺、Webページ、さらには登録済みの連絡先などのプロトコル内のソースからのURIには、不適切なヘッダーフィールドやボディパーツが含まれている場合があります。
An implementation MUST include any provided transport, maddr, ttl, or user parameter in the Request-URI of the formed request. If the URI contains a method parameter, its value MUST be used as the method of the request. The method parameter MUST NOT be placed in the Request-URI. Unknown URI parameters MUST be placed in the message's Request-URI.
実装では、形成された要求のRequest-URIに、提供されたトランスポート、maddr、ttl、またはユーザーパラメータを含める必要があります。 URIにメソッドパラメータが含まれている場合、その値をリクエストのメソッドとして使用する必要があります。メソッドパラメータはRequest-URIに配置してはなりません（MUST NOT）。不明なURIパラメータをメッセージのRequest-URIに配置する必要があります。
An implementation SHOULD treat the presence of any headers or body parts in the URI as a desire to include them in the message, and choose to honor the request on a per-component basis.
実装は、URI内のヘッダーまたはボディパーツの存在をメッセージに含めたいという要望として扱い、コンポーネントごとにリクエストを受け入れることを選択する必要があります（SHOULD）。
An implementation SHOULD NOT honor these obviously dangerous header fields: From, Call-ID, CSeq, Via, and Record-Route.
実装はこれらの明らかに危険なヘッダーフィールドを尊重しないでください：From、Call-ID、CSeq、Via、およびRecord-Route。
An implementation SHOULD NOT honor any requested Route header field values in order to not be used as an unwitting agent in malicious attacks.
実装は、悪意のある攻撃で無意識のエージェントとして使用されないようにするために、要求されたルートヘッダーフィールド値を尊重するべきではありません。
An implementation SHOULD NOT honor requests to include header fields that may cause it to falsely advertise its location or capabilities. These include: Accept, Accept-Encoding, Accept-Language, Allow, Contact (in its dialog usage), Organization, Supported, and User-Agent.
実装は、位置または機能を誤ってアドバタイズする可能性があるヘッダーフィールドを含める要求を尊重すべきではありません。これらには、Accept、Accept-Encoding、Accept-Language、Allow、Contact（ダイアログの使用法）、Organization、Supported、およびUser-Agentが含まれます。
An implementation SHOULD verify the accuracy of any requested descriptive header fields, including: Content-Disposition, Content-Encoding, Content-Language, Content-Length, Content-Type, Date, Mime-Version, and Timestamp.
実装では、要求された説明ヘッダーフィールド（Content-Disposition、Content-Encoding、Content-Language、Content-Length、Content-Type、Date、Mime-Version、Timestampなど）の正確性を検証する必要があります（SHOULD）。
If the request formed from constructing a message from a given URI is not a valid SIP request, the URI is invalid. An implementation MUST NOT proceed with transmitting the request. It should instead pursue the course of action due an invalid URI in the context it occurs.
特定のURIからメッセージを作成することによって形成された要求が有効なSIP要求でない場合、URIは無効です。実装はリクエストの送信を続行してはなりません。代わりに、発生したコンテキストでの無効なURIに起因する一連のアクションを追跡する必要があります。
The constructed request can be invalid in many ways. These include, but are not limited to, syntax error in header fields, invalid combinations of URI parameters, or an incorrect description of the message body.
構築されたリクエストは、多くの点で無効である可能性があります。これらには、ヘッダーフィールドの構文エラー、URIパラメータの無効な組み合わせ、またはメッセージ本文の誤った説明が含まれますが、これらに限定されません。
Sending a request formed from a given URI may require capabilities unavailable to the implementation. The URI might indicate use of an unimplemented transport or extension, for example. An implementation SHOULD refuse to send these requests rather than modifying them to match their capabilities. An implementation MUST NOT send a request requiring an extension that it does not support.
特定のURIから形成された要求を送信するには、実装で使用できない機能が必要になる場合があります。 URIは、たとえば、実装されていないトランスポートまたは拡張の使用を示している場合があります。実装は、機能に合わせて変更するのではなく、これらの要求の送信を拒否する必要があります。実装は、サポートしていない拡張を必要とするリクエストを送信してはいけません（MUST NOT）。
For example, such a request can be formed through the presence of a Require header parameter or a method URI parameter with an unknown or explicitly unsupported value.
たとえば、このような要求は、不明なヘッダーまたは明示的にサポートされていない値を持つRequireヘッダーパラメーターまたはメソッドURIパラメーターの存在によって形成されます。
When a tel URL (RFC 2806 [9]) is converted to a SIP or SIPS URI, the entire telephone-subscriber portion of the tel URL, including any parameters, is placed into the userinfo part of the SIP or SIPS URI.
Tel URL（RFC 2806 [9]）がSIPまたはSIPS URIに変換されると、パラメーターを含むTel URLの電話加入者部分全体が、SIPまたはSIPS URIのuserinfo部分に配置されます。
Thus, tel:+358-555-1234567;postd=pp22 becomes
sip:+358-555-1234567;postd=pp22@foo.com;user=phone
or
sips:+358-555-1234567;postd=pp22@foo.com;user=phone
not
sip:+358-555-1234567@foo.com;postd=pp22;user=phone
or
または
sips:+358-555-1234567@foo.com;postd=pp22;user=phone
In general, equivalent "tel" URLs converted to SIP or SIPS URIs in this fashion may not produce equivalent SIP or SIPS URIs. The userinfo of SIP and SIPS URIs are compared as a case-sensitive string. Variance in case-insensitive portions of tel URLs and reordering of tel URL parameters does not affect tel URL equivalence, but does affect the equivalence of SIP URIs formed from them.
一般に、この方法でSIPまたはSIPS URIに変換された同等の「tel」URLは、同等のSIPまたはSIPS URIを生成しない場合があります。 SIPおよびSIPS URIのuserinfoは、大文字と小文字が区別される文字列として比較されます。 tel URLの大文字と小文字を区別しない部分の差異とtel URLパラメータの並べ替えは、tel URLの同等性には影響しませんが、それらから形成されるSIP URIの同等性には影響します。
For example,
例えば、
tel:+358-555-1234567;postd=pp22
tel:+358-555-1234567;POSTD=PP22
are equivalent, while
同等ですが、
sip:+358-555-1234567;postd=pp22@foo.com;user=phone
sip:+358-555-1234567;POSTD=PP22@foo.com;user=phone
are not.
そうではありません。
Likewise,
同様に、
tel:+358-555-1234567;postd=pp22;isub=1411
tel:+358-555-1234567;isub=1411;postd=pp22
are equivalent, while
同等ですが、
sip:+358-555-1234567;postd=pp22;isub=1411@foo.com;user=phone
sip:+358-555-1234567;isub=1411;postd=pp22@foo.com;user=phone
are not.
そうではありません。
To mitigate this problem, elements constructing telephone-subscriber fields to place in the userinfo part of a SIP or SIPS URI SHOULD fold any case-insensitive portion of telephone-subscriber to lower case, and order the telephone-subscriber parameters lexically by parameter name, excepting isdn-subaddress and post-dial, which occur first and in that order. (All components of a tel URL except for future-extension parameters are defined to be compared case-insensitive.)
この問題を軽減するために、SIPまたはSIPS URIのuserinfo部分に配置する電話サブスクライバーフィールドを構築する要素は、電話サブスクライバーの大文字と小文字を区別しない部分を小文字に折りたたみ、電話サブスクライバーパラメーターをパラメーター名で字句順に並べます。 isdn-subaddressとpost-dialを除いて、これらは最初に、この順序で発生します。 （将来の拡張パラメータを除くtel URLのすべてのコンポーネントは、大文字と小文字を区別しないで比較されるように定義されています。）
Following this suggestion, both
この提案に従って、両方
tel:+358-555-1234567;postd=pp22
tel:+358-555-1234567;POSTD=PP22
become
なる
sip:+358-555-1234567;postd=pp22@foo.com;user=phone
and both
そして両方
tel:+358-555-1234567;tsp=a.b;phone-context=5
tel:+358-555-1234567;phone-context=5;tsp=a.b
become
なる
sip:+358-555-1234567;phone-context=5;tsp=a.b@foo.com;user=phone
Option tags are unique identifiers used to designate new options (extensions) in SIP. These tags are used in Require (Section 20.32), Proxy-Require (Section 20.29), Supported (Section 20.37) and Unsupported (Section 20.40) header fields. Note that these options appear as parameters in those header fields in an option-tag = token form (see Section 25 for the definition of token).
オプションタグは、SIPで新しいオプション（拡張）を指定するために使用される一意の識別子です。これらのタグは、Require（セクション20.32）、Proxy-Require（セクション20.29）、Supported（セクション20.37）およびUnsupported（セクション20.40）ヘッダーフィールドで使用されます。これらのオプションは、option-tag = tokenフォームのこれらのヘッダーフィールドのパラメーターとして表示されることに注意してください（トークンの定義については、セクション25を参照してください）。
Option tags are defined in standards track RFCs. This is a change from past practice, and is instituted to ensure continuing multi-vendor interoperability (see discussion in Section 20.32 and Section 20.37). An IANA registry of option tags is used to ensure easy reference.
オプションタグは、標準トラックRFCで定義されています。これは過去の慣例からの変更であり、継続的なマルチベンダー相互運用性を保証するために制定されました（セクション20.32およびセクション20.37の説明を参照）。簡単に参照できるように、オプションタグのIANAレジストリが使用されます。
The "tag" parameter is used in the To and From header fields of SIP messages. It serves as a general mechanism to identify a dialog, which is the combination of the Call-ID along with two tags, one from each participant in the dialog. When a UA sends a request outside of a dialog, it contains a From tag only, providing "half" of the dialog ID. The dialog is completed from the response(s), each of which contributes the second half in the To header field. The forking of SIP requests means that multiple dialogs can be established from a single request. This also explains the need for the two-sided dialog identifier; without a contribution from the recipients, the originator could not disambiguate the multiple dialogs established from a single request.
「タグ」パラメータは、SIPメッセージのToおよびFromヘッダーフィールドで使用されます。これは、ダイアログを識別するための一般的なメカニズムとして機能します。これは、ダイアログの各参加者からの2つのタグとCall-IDの組み合わせです。 UAがダイアログの外でリクエストを送信する場合、UAにはFromタグのみが含まれ、ダイアログIDの「半分」を提供します。ダイアログは応答から完成します。各応答は、Toヘッダーフィールドの後半を提供します。 SIP要求の分岐は、単一の要求から複数のダイアログを確立できることを意味します。これは、両面ダイアログ識別子の必要性も説明します。受信者からの貢献がなければ、発信者は単一の要求から確立された複数のダイアログを明確にすることができませんでした。
When a tag is generated by a UA for insertion into a request or response, it MUST be globally unique and cryptographically random with at least 32 bits of randomness. A property of this selection requirement is that a UA will place a different tag into the From header of an INVITE than it would place into the To header of the response to the same INVITE. This is needed in order for a UA to invite itself to a session, a common case for "hairpinning" of calls in PSTN gateways. Similarly, two INVITEs for different calls will have different From tags, and two responses for different calls will have different To tags.
タグがリクエストまたはレスポンスへの挿入のためにUAによって生成されるとき、それはグローバルに一意であり、少なくとも32ビットのランダム性を備えた暗号的にランダムである必要があります。この選択要件の特性は、UAが同じINVITEへの応答のToヘッダーに配置するよりも、異なるタグをINVITEのFromヘッダーに配置することです。これは、UAがセッションに自分自身を招待するために必要です。これは、PSTNゲートウェイでのコールの「ヘアピニング」の一般的なケースです。同様に、異なるコールの2つのINVITEには異なるFromタグがあり、異なるコールの2つの応答には異なるToタグがあります。
Besides the requirement for global uniqueness, the algorithm for generating a tag is implementation-specific. Tags are helpful in fault tolerant systems, where a dialog is to be recovered on an alternate server after a failure. A UAS can select the tag in such a way that a backup can recognize a request as part of a dialog on the failed server, and therefore determine that it should attempt to recover the dialog and any other state associated with it.
グローバルな一意性の要件に加えて、タグを生成するアルゴリズムは実装固有です。タグは、障害発生後にダイアログが代替サーバーで回復されるフォールトトレラントシステムで役立ちます。 UASは、バックアップが障害が発生したサーバー上のダイアログの一部として要求を認識できるようにタグを選択できるため、ダイアログとそれに関連付けられているその他の状態を回復する必要があると判断できます。
20 Header Fields
20ヘッダーフィールド
The general syntax for header fields is covered in Section 7.3. This section lists the full set of header fields along with notes on syntax, meaning, and usage. Throughout this section, we use [HX.Y] to refer to Section X.Y of the current HTTP/1.1 specification RFC 2616 [8]. Examples of each header field are given.
ヘッダーフィールドの一般的な構文については、セクション7.3で説明します。このセクションでは、構文、意味、および使用法に関する注記とともに、ヘッダーフィールドの完全なセットをリストします。このセクション全体で、[HX.Y]を使用して、現在のHTTP / 1.1仕様RFC 2616 [8]のセクションX.Yを参照します。各ヘッダーフィールドの例を示します。
Information about header fields in relation to methods and proxy processing is summarized in Tables 2 and 3.
メソッドとプロキシ処理に関連するヘッダーフィールドに関する情報を表2および3にまとめます。
The "where" column describes the request and response types in which the header field can be used. Values in this column are:
「where」列は、ヘッダーフィールドを使用できるリクエストとレスポンスのタイプを示しています。この列の値は次のとおりです。
R: header field may only appear in requests;
R：ヘッダーフィールドはリクエストにのみ表示されます。
r: header field may only appear in responses;
r：ヘッダーフィールドは応答にのみ表示されます。
2xx, 4xx, etc.: A numerical value or range indicates response codes with which the header field can be used;
2xx、4xxなど：数値または範囲は、ヘッダーフィールドを使用できる応答コードを示します。
c: header field is copied from the request to the response.
c：ヘッダーフィールドがリクエストからレスポンスにコピーされます。
An empty entry in the "where" column indicates that the header field may be present in all requests and responses.
「where」列の空のエントリは、ヘッダーフィールドがすべての要求と応答に存在する可能性があることを示します。
The "proxy" column describes the operations a proxy may perform on a header field:
「プロキシ」列は、プロキシがヘッダーフィールドで実行できる操作を示しています。
a: A proxy can add or concatenate the header field if not present.
a：存在しない場合、プロキシはヘッダーフィールドを追加または連結できます。
m: A proxy can modify an existing header field value.
m：プロキシは既存のヘッダーフィールド値を変更できます。
d: A proxy can delete a header field value.
d：プロキシはヘッダーフィールド値を削除できます。
r: A proxy must be able to read the header field, and thus this header field cannot be encrypted.
r：プロキシはヘッダーフィールドを読み取れる必要があるため、このヘッダーフィールドは暗号化できません。
The next six columns relate to the presence of a header field in a method:
次の6つの列は、メソッド内のヘッダーフィールドの存在に関連しています。
c: Conditional; requirements on the header field depend on the context of the message.
c：条件付き。ヘッダーフィールドの要件は、メッセージのコンテキストによって異なります。
m: The header field is mandatory.
m：ヘッダーフィールドは必須です。
m*: The header field SHOULD be sent, but clients/servers need to be prepared to receive messages without that header field.
m *：ヘッダーフィールドを送信する必要があります（SHOULD）が、クライアント/サーバーは、そのヘッダーフィールドなしでメッセージを受信できるように準備する必要があります。
o: The header field is optional.
o：ヘッダーフィールドはオプションです。
t: The header field SHOULD be sent, but clients/servers need to be prepared to receive messages without that header field.
t：ヘッダーフィールドを送信する必要があります（SHOULD）が、クライアント/サーバーは、そのヘッダーフィールドなしでメッセージを受信できるように準備する必要があります。
If a stream-based protocol (such as TCP) is used as a transport, then the header field MUST be sent.
ストリームベースのプロトコル（TCPなど）をトランスポートとして使用する場合は、ヘッダーフィールドを送信する必要があります。
*: The header field is required if the message body is not empty. See Sections 20.14, 20.15 and 7.4 for details.
*：メッセージ本文が空でない場合、ヘッダーフィールドは必須です。詳細については、セクション20.14、20.15、および7.4を参照してください。
-: The header field is not applicable.
-：ヘッダーフィールドは適用されません。
"Optional" means that an element MAY include the header field in a request or response, and a UA MAY ignore the header field if present in the request or response (The exception to this rule is the Require header field discussed in 20.32). A "mandatory" header field MUST be present in a request, and MUST be understood by the UAS receiving the request. A mandatory response header field MUST be present in the response, and the header field MUST be understood by the UAC processing the response. "Not applicable" means that the header field MUST NOT be present in a request. If one is placed in a request by mistake, it MUST be ignored by the UAS receiving the request. Similarly, a header field labeled "not applicable" for a response means that the UAS MUST NOT place the header field in the response, and the UAC MUST ignore the header field in the response.
「オプション」は、要素がリクエストまたはレスポンスにヘッダーフィールドを含む場合があり、リクエストまたはレスポンスに存在する場合、UAがヘッダーフィールドを無視する場合があることを意味します（このルールの例外は、20.32で説明するRequireヘッダーフィールドです）。 「必須」ヘッダーフィールドはリクエストに存在しなければならず、リクエストを受信するUASによって理解されなければなりません（MUST）。必須の応答ヘッダーフィールドが応答に存在する必要があり、ヘッダーフィールドは、応答を処理するUACによって理解される必要があります。 「該当なし」は、ヘッダーフィールドがリクエストに存在してはならないことを意味します。誤ってリクエストに配置された場合、リクエストを受信するUASはそれを無視する必要があります。同様に、応答に「該当なし」というラベルの付いたヘッダーフィールドは、UASが応答にヘッダーフィールドを配置してはならず（MUST NOT）、UACが応答のヘッダーフィールドを無視する必要があることを意味します。
A UA SHOULD ignore extension header parameters that are not understood.
UAは、理解できない拡張ヘッダーパラメーターを無視する必要があります（SHOULD）。
A compact form of some common header field names is also defined for use when overall message size is an issue.
いくつかの一般的なヘッダーフィールド名のコンパクトな形式も、全体的なメッセージサイズが問題になる場合に使用するために定義されています。
The Contact, From, and To header fields contain a URI. If the URI contains a comma, question mark or semicolon, the URI MUST be enclosed in angle brackets (< and >). Any URI parameters are contained within these brackets. If the URI is not enclosed in angle brackets, any semicolon-delimited parameters are header-parameters, not URI parameters.
Contact、From、およびToヘッダーフィールドにはURIが含まれます。 URIにコンマ、疑問符、またはセミコロンが含まれている場合、URIは山括弧（<および>）で囲む必要があります。 URIパラメータは、これらの括弧内に含まれています。 URIが山括弧で囲まれていない場合、セミコロンで区切られたパラメーターは、URIパラメーターではなくヘッダーパラメーターです。
The Accept header field follows the syntax defined in [H14.1]. The semantics are also identical, with the exception that if no Accept header field is present, the server SHOULD assume a default value of application/sdp.
Acceptヘッダーフィールドは、[H14.1]で定義された構文に従います。意味も同じですが、Acceptヘッダーフィールドが存在しない場合、サーバーはapplication / sdpのデフォルト値を想定する必要があります（SHOULD）。
An empty Accept header field means that no formats are acceptable.
空のAcceptヘッダーフィールドは、受け入れ可能な形式がないことを意味します。
Example:
例：
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Accept R - o - o m* o
Accept 2xx - - - o m* o
Accept 415 - c - c c c
Accept-Encoding R - o - o o o
Accept-Encoding 2xx - - - o m* o
Accept-Encoding 415 - c - c c c
Accept-Language R - o - o o o
Accept-Language 2xx - - - o m* o
Accept-Language 415 - c - c c c
Alert-Info R ar - - - o - -
Alert-Info 180 ar - - - o - -
Allow R - o - o o o
Allow 2xx - o - m* m* o
Allow r - o - o o o
Allow 405 - m - m m m
Authentication-Info 2xx - o - o o o
Authorization R o o o o o o
Call-ID c r m m m m m m
Call-Info ar - - - o o o
Contact R o - - m o o
Contact 1xx - - - o - -
Contact 2xx - - - m o o
Contact 3xx d - o - o o o
Contact 485 - o - o o o
Content-Disposition o o - o o o
Content-Encoding o o - o o o
Content-Language o o - o o o
Content-Length ar t t t t t t
Content-Type * * - * * *
CSeq c r m m m m m m
Date a o o o o o o
Error-Info 300-699 a - o o o o o
Expires - - - o - o
From c r m m m m m m
In-Reply-To R - - - o - -
Max-Forwards R amr m m m m m m
Min-Expires 423 - - - - - m
MIME-Version o o - o o o
Organization ar - - - o o o
Table 2: Summary of header fields, A--O
表2：ヘッダーフィールドの概要、A--O
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________________
Priority R ar - - - o - -
Proxy-Authenticate 407 ar - m - m m m
Proxy-Authenticate 401 ar - o o o o o
Proxy-Authorization R dr o o - o o o
Proxy-Require R ar - o - o o o
Record-Route R ar o o o o o -
Record-Route 2xx,18x mr - o o o o -
Reply-To - - - o - -
Require ar - c - c c c
Retry-After 404,413,480,486 - o o o o o
500,503 - o o o o o
600,603 - o o o o o
Route R adr c c c c c c
Server r - o o o o o
Subject R - - - o - -
Supported R - o o m* o o
Supported 2xx - o o m* m* o
Timestamp o o o o o o
To c(1) r m m m m m m
Unsupported 420 - m - m m m
User-Agent o o o o o o
Via R amr m m m m m m
Via rc dr m m m m m m
Warning r - o o o o o
WWW-Authenticate 401 ar - m - m m m
WWW-Authenticate 407 ar - o - o o o
Table 3: Summary of header fields, P--Z; (1): copied with possible addition of tag
表3：ヘッダーフィールドの概要、P--Z; （1）：タグの追加が可能なコピー
Accept: application/sdp;level=1, application/x-private, text/html
The Accept-Encoding header field is similar to Accept, but restricts the content-codings [H3.5] that are acceptable in the response. See [H14.3]. The semantics in SIP are identical to those defined in [H14.3].
Accept-EncodingヘッダーフィールドはAcceptに似ていますが、応答で許容されるコンテンツコーディング[H3.5]を制限します。 [H14.3]を参照してください。 SIPのセマンティクスは、[H14.3]で定義されているものと同じです。
An empty Accept-Encoding header field is permissible. It is equivalent to Accept-Encoding: identity, that is, only the identity encoding, meaning no encoding, is permissible.
空のAccept-Encodingヘッダーフィールドは許可されます。これはAccept-Encoding：identityと同等です。つまり、IDエンコードのみ、つまりエンコードなしが許可されます。
If no Accept-Encoding header field is present, the server SHOULD assume a default value of identity.
Accept-Encodingヘッダーフィールドが存在しない場合、サーバーはデフォルト値のidentityを想定する必要があります（SHOULD）。
This differs slightly from the HTTP definition, which indicates that when not present, any encoding can be used, but the identity encoding is preferred.
これはHTTP定義とは少し異なります。HTTP定義は、存在しない場合は任意のエンコーディングを使用できることを示していますが、IDエンコーディングが推奨されます。
Example:
例：
Accept-Encoding: gzip
Accept-Encoding：gzip
The Accept-Language header field is used in requests to indicate the preferred languages for reason phrases, session descriptions, or status responses carried as message bodies in the response. If no Accept-Language header field is present, the server SHOULD assume all languages are acceptable to the client.
Accept-Languageヘッダーフィールドは、理由フレーズ、セッションの説明、または応答でメッセージ本文として伝送されるステータス応答の優先言語を示すために要求で使用されます。 Accept-Languageヘッダーフィールドが存在しない場合、サーバーはすべての言語がクライアントに受け入れ可能であると想定する必要があります（SHOULD）。
The Accept-Language header field follows the syntax defined in [H14.4]. The rules for ordering the languages based on the "q" parameter apply to SIP as well.
Accept-Languageヘッダーフィールドは、[H14.4]で定義された構文に従います。 「q」パラメーターに基づいて言語を順序付ける規則は、SIPにも適用されます。
Example:
例：
Accept-Language: da, en-gb;q=0.8, en;q=0.7
When present in an INVITE request, the Alert-Info header field specifies an alternative ring tone to the UAS. When present in a 180 (Ringing) response, the Alert-Info header field specifies an alternative ringback tone to the UAC. A typical usage is for a proxy to insert this header field to provide a distinctive ring feature.
INVITE要求に存在する場合、Alert-Infoヘッダーフィールドは、UASの代替呼び出し音を指定します。 180（Ringing）応答に存在する場合、Alert-Infoヘッダーフィールドは、UACへの代替リングバックトーンを指定します。典型的な使用法は、プロキシがこのヘッダーフィールドを挿入して、独特のリング機能を提供することです。
The Alert-Info header field can introduce security risks. These risks and the ways to handle them are discussed in Section 20.9, which discusses the Call-Info header field since the risks are identical.
Alert-Infoヘッダーフィールドは、セキュリティリスクをもたらす可能性があります。これらのリスクとそれらを処理する方法については、セクション20.9で説明しています。このセクションでは、リスクが同一であるため、Call-Infoヘッダーフィールドについて説明します。
In addition, a user SHOULD be able to disable this feature selectively.
さらに、ユーザーはこの機能を選択的に無効にできる必要があります（SHOULD）。
This helps prevent disruptions that could result from the use of this header field by untrusted elements.
これにより、信頼できない要素によるこのヘッダーフィールドの使用に起因する混乱を防ぐことができます。
Example:
例：
Alert-Info: <http://www.example.com/sounds/moo.wav>
The Allow header field lists the set of methods supported by the UA generating the message.
Allowヘッダーフィールドには、メッセージを生成するUAがサポートする一連のメソッドが一覧表示されます。
All methods, including ACK and CANCEL, understood by the UA MUST be included in the list of methods in the Allow header field, when present. The absence of an Allow header field MUST NOT be interpreted to mean that the UA sending the message supports no methods. Rather, it implies that the UA is not providing any information on what methods it supports.
ACKとCANCELを含む、UAによって理解されるすべてのメソッドは、存在する場合、Allowヘッダーフィールドのメソッドのリストに含める必要があります。 Allowヘッダーフィールドがないことは、メッセージを送信するUAがメソッドをサポートしないことを意味するものとして解釈してはなりません（MUST NOT）。むしろ、UAがサポートするメソッドに関する情報を提供していないことを意味します。
Supplying an Allow header field in responses to methods other than OPTIONS reduces the number of messages needed.
OPTIONS以外のメソッドへの応答でAllowヘッダーフィールドを指定すると、必要なメッセージの数が減ります。
Example:
例：
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE
許可：INVITE、ACK、OPTIONS、CANCEL、BYE
The Authentication-Info header field provides for mutual authentication with HTTP Digest. A UAS MAY include this header field in a 2xx response to a request that was successfully authenticated using digest based on the Authorization header field.
Authentication-Infoヘッダーフィールドは、HTTPダイジェストとの相互認証を提供します。 UASは、Authorizationヘッダーフィールドに基づくダイジェストを使用して正常に認証された要求への2xx応答にこのヘッダーフィールドを含めることができます。
Syntax and semantics follow those specified in RFC 2617 [17].
構文とセマンティクスは、RFC 2617 [17]で指定されているものに従います。
Example:
例：
Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c"
Authentication-Info：nextnonce = "47364c23432d2e131a5fb210812c"
The Authorization header field contains authentication credentials of a UA. Section 22.2 overviews the use of the Authorization header field, and Section 22.4 describes the syntax and semantics when used with HTTP authentication.
Authorizationヘッダーフィールドには、UAの認証資格情報が含まれています。セクション22.2はAuthorizationヘッダーフィールドの使用の概要を示し、セクション22.4はHTTP認証で使用される場合の構文とセマンティクスを説明します。
This header field, along with Proxy-Authorization, breaks the general rules about multiple header field values. Although not a comma-separated list, this header field name may be present multiple times, and MUST NOT be combined into a single header line using the usual rules described in Section 7.3.
このヘッダーフィールドは、Proxy-Authorizationとともに、複数のヘッダーフィールド値に関する一般的な規則に違反します。コンマで区切られたリストではありませんが、このヘッダーフィールド名は複数回存在する可能性があり、7.3節で説明されている通常の規則を使用して単一のヘッダー行に結合してはなりません。
In the example below, there are no quotes around the Digest parameter:
以下の例では、Digestパラメーターの前後に引用符はありません。
Authorization: Digest username="Alice", realm="atlanta.com",
nonce="84a4cc6f3082121f32b42a2187831a9e",
response="7587245234b3434cc3412213e5f113a5432"
The Call-ID header field uniquely identifies a particular invitation or all registrations of a particular client. A single multimedia conference can give rise to several calls with different Call-IDs, for example, if a user invites a single individual several times to the same (long-running) conference. Call-IDs are case-sensitive and are simply compared byte-by-byte.
Call-IDヘッダーフィールドは、特定の招待または特定のクライアントのすべての登録を一意に識別します。たとえば、ユーザーが1人の個人を同じ（長時間にわたる）会議に数回招待した場合など、1つのマルチメディア会議で異なるCall-IDを持つ複数の通話が発生する可能性があります。 Call-IDは大文字と小文字が区別され、単純にバイトごとに比較されます。
The compact form of the Call-ID header field is i.
Call-IDヘッダーフィールドのコンパクトな形式はiです。
Examples:
例：
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@biloxi.com
i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4
The Call-Info header field provides additional information about the caller or callee, depending on whether it is found in a request or response. The purpose of the URI is described by the "purpose" parameter. The "icon" parameter designates an image suitable as an iconic representation of the caller or callee. The "info" parameter describes the caller or callee in general, for example, through a web page. The "card" parameter provides a business card, for example, in vCard [36] or LDIF [37] formats. Additional tokens can be registered using IANA and the procedures in Section 27.
Call-Infoヘッダーフィールドは、要求または応答のどちらで見つかったかに応じて、呼び出し元または呼び出し先に関する追加情報を提供します。 URIの目的は、「purpose」パラメーターによって記述されます。 「アイコン」パラメータは、呼び出し元または呼び出し先のアイコン表現として適切な画像を指定します。 "info"パラメータは、たとえばWebページを通じて、一般的に呼び出し元または呼び出し先を記述します。 「card」パラメータは、たとえばvCard [36]またはLDIF [37]形式の名刺を提供します。 IANAおよびセクション27の手順を使用して、追加のトークンを登録できます。
Use of the Call-Info header field can pose a security risk. If a callee fetches the URIs provided by a malicious caller, the callee may be at risk for displaying inappropriate or offensive content, dangerous or illegal content, and so on. Therefore, it is RECOMMENDED that a UA only render the information in the Call-Info header field if it can verify the authenticity of the element that originated the header field and trusts that element. This need not be the peer UA; a proxy can insert this header field into requests.
Call-Infoヘッダーフィールドを使用すると、セキュリティリスクが発生する可能性があります。呼び出し先が悪意のある呼び出し元から提供されたURIをフェッチすると、呼び出し先は不適切または攻撃的なコンテンツ、危険または違法なコンテンツなどを表示する危険にさらされる可能性があります。したがって、UAがCall-Infoヘッダーフィールドに情報を表示するのは、ヘッダーフィールドを発信した要素の信頼性を確認でき、その要素を信頼できる場合のみにすることをお勧めします。これはピアUAである必要はありません。プロキシはこのヘッダーフィールドをリクエストに挿入できます。
Example:
例：
Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon,
<http://www.example.com/alice/> ;purpose=info
A Contact header field value provides a URI whose meaning depends on the type of request or response it is in.
Contactヘッダーフィールドの値は、URIを提供します。その意味は、リクエストまたは応答のタイプによって異なります。
A Contact header field value can contain a display name, a URI with URI parameters, and header parameters.
Contactヘッダーフィールドの値には、表示名、URIパラメーター付きのURI、およびヘッダーパラメーターを含めることができます。
This document defines the Contact parameters "q" and "expires". These parameters are only used when the Contact is present in a REGISTER request or response, or in a 3xx response. Additional parameters may be defined in other specifications.
このドキュメントでは、Contactパラメータの「q」と「expires」を定義しています。これらのパラメーターは、連絡先がREGISTER要求または応答、または3xx応答に存在する場合にのみ使用されます。追加のパラメータは、他の仕様で定義される場合があります。
When the header field value contains a display name, the URI including all URI parameters is enclosed in "<" and ">". If no "<" and ">" are present, all parameters after the URI are header parameters, not URI parameters. The display name can be tokens, or a quoted string, if a larger character set is desired.
ヘッダーフィールドの値に表示名が含まれている場合、すべてのURIパラメーターを含むURIは「<」と「>」で囲まれます。 「<」および「>」が存在しない場合、URIの後のすべてのパラメーターは、URIパラメーターではなくヘッダーパラメーターです。より大きな文字セットが必要な場合、表示名はトークンまたは引用符付き文字列にすることができます。
Even if the "display-name" is empty, the "name-addr" form MUST be used if the "addr-spec" contains a comma, semicolon, or question mark. There may or may not be LWS between the display-name and the "<".
「display-name」が空の場合でも、「addr-spec」にカンマ、セミコロン、または疑問符が含まれている場合は、「name-addr」形式を使用する必要があります。表示名と「<」の間にLWSがある場合とない場合があります。
These rules for parsing a display name, URI and URI parameters, and header parameters also apply for the header fields To and From.
表示名、URIおよびURIパラメーター、およびヘッダーパラメーターの解析に関するこれらのルールは、ヘッダーフィールドToおよびFromにも適用されます。
The Contact header field has a role similar to the Location header field in HTTP. However, the HTTP header field only allows one address, unquoted. Since URIs can contain commas and semicolons as reserved characters, they can be mistaken for header or parameter delimiters, respectively.
Contactヘッダーフィールドには、HTTPのLocationヘッダーフィールドと同様の役割があります。ただし、HTTPヘッダーフィールドでは、引用符なしの1つのアドレスしか使用できません。 URIにはコンマとセミコロンを予約文字として含めることができるので、URIはそれぞれヘッダーまたはパラメーターの区切り文字と間違われる可能性があります。
The compact form of the Contact header field is m (for "moved").
Contactヘッダーフィールドのコンパクトな形式はm（「移動」の場合）です。
Examples:
例：
Contact: "Mr. Watson" <sip:watson@worcester.bell-telephone.com>
;q=0.7; expires=3600,
"Mr. Watson" <mailto:watson@bell-telephone.com> ;q=0.1
m: <sips:bob@192.0.2.4>;expires=60
The Content-Disposition header field describes how the message body or, for multipart messages, a message body part is to be interpreted by the UAC or UAS. This SIP header field extends the MIME Content-Type (RFC 2183 [18]).
Content-Dispositionヘッダーフィールドは、メッセージ本文、またはマルチパートメッセージの場合はメッセージ本文部分がUACまたはUASによってどのように解釈されるかを記述します。このSIPヘッダーフィールドは、MIME Content-Type（RFC 2183 [18]）を拡張します。
Several new "disposition-types" of the Content-Disposition header are defined by SIP. The value "session" indicates that the body part describes a session, for either calls or early (pre-call) media. The value "render" indicates that the body part should be displayed or otherwise rendered to the user. Note that the value "render" is used rather than "inline" to avoid the connotation that the MIME body is displayed as a part of the rendering of the entire message (since the MIME bodies of SIP messages oftentimes are not displayed to users). For backward-compatibility, if the Content-Disposition header field is missing, the server SHOULD assume bodies of Content-Type application/sdp are the disposition "session", while other content types are "render".
Content-Dispositionヘッダーのいくつかの新しい「disposition-types」がSIPによって定義されています。値 "session"は、通話または初期（通話前）メディアのいずれかの本体部分がセッションを表すことを示します。値「render」は、ボディパーツを表示するか、ユーザーにレンダリングする必要があることを示します。メッセージ全体のレンダリングの一部としてMIME本文が表示されるという意味合いを避けるために、「インライン」ではなく値「render」が使用されることに注意してください（SIPメッセージのMIME本文はユーザーに表示されないことが多いため）。下位互換性のために、Content-Dispositionヘッダーフィールドが欠落している場合、サーバーはContent-Type application / sdpの本体が後処理「セッション」であると想定し、他のコンテンツタイプは「レンダリング」であると想定する必要があります。
The disposition type "icon" indicates that the body part contains an image suitable as an iconic representation of the caller or callee that could be rendered informationally by a user agent when a message has been received, or persistently while a dialog takes place. The value "alert" indicates that the body part contains information, such as an audio clip, that should be rendered by the user agent in an attempt to alert the user to the receipt of a request, generally a request that initiates a dialog; this alerting body could for example be rendered as a ring tone for a phone call after a 180 Ringing provisional response has been sent.
配置タイプ「アイコン」は、メッセージが受信されたとき、またはダイアログが行われている間も持続的にユーザーエージェントによって情報としてレンダリングできる、呼び出し元または呼び出し先のアイコン表現として適切な画像がボディパーツに含まれていることを示します。値「alert」は、リクエスト、通常はダイアログを開始するリクエストの受信をユーザーに警告するためにユーザーエージェントがレンダリングする必要のあるオーディオクリップなどの情報がボディパーツに含まれていることを示します。このアラート本文は、たとえば、180 Ringing暫定応答が送信された後、電話の呼び出し音としてレンダリングできます。
Any MIME body with a "disposition-type" that renders content to the user should only be processed when a message has been properly authenticated.
コンテンツをユーザーに表示する「廃棄タイプ」のMIME本文は、メッセージが適切に認証された場合にのみ処理する必要があります。
The handling parameter, handling-param, describes how the UAS should react if it receives a message body whose content type or disposition type it does not understand. The parameter has defined values of "optional" and "required". If the handling parameter is missing, the value "required" SHOULD be assumed. The handling parameter is described in RFC 3204 [19].
処理パラメーター（handleing-param）は、コンテンツタイプまたは処理タイプが理解できないメッセージ本文を受信した場合に、UASがどのように反応するかを記述します。このパラメーターには、「オプション」および「必須」の値が定義されています。処理パラメーターが欠落している場合は、「必須」という値を想定する必要があります（SHOULD）。処理パラメータはRFC 3204 [19]で説明されています。
If this header field is missing, the MIME type determines the default content disposition. If there is none, "render" is assumed.
このヘッダーフィールドがない場合、MIMEタイプによってデフォルトのコンテンツ処理が決定されます。存在しない場合、「レンダリング」が想定されます。
Example:
例：
Content-Disposition: session
Content-Disposition：セッション
The Content-Encoding header field is used as a modifier to the "media-type". When present, its value indicates what additional content codings have been applied to the entity-body, and thus what decoding mechanisms MUST be applied in order to obtain the media-type referenced by the Content-Type header field. Content-Encoding is primarily used to allow a body to be compressed without losing the identity of its underlying media type.
Content-Encodingヘッダーフィールドは、「メディアタイプ」の修飾子として使用されます。存在する場合、その値は、エンティティ本体に適用されている追加のコンテンツコーディングを示します。したがって、Content-Typeヘッダーフィールドによって参照されるメディアタイプを取得するために、どのデコードメカニズムを適用する必要があります。 Content-Encodingは主に、基礎となるメディアタイプのIDを失うことなくボディを圧縮できるようにするために使用されます。
If multiple encodings have been applied to an entity-body, the content codings MUST be listed in the order in which they were applied.
エンティティ本体に複数のエンコーディングが適用されている場合、コンテンツコーディングは、それらが適用された順序でリストされている必要があります。
All content-coding values are case-insensitive. IANA acts as a registry for content-coding value tokens. See [H3.5] for a definition of the syntax for content-coding.
content-codingの値はすべて大文字と小文字が区別されません。 IANAは、コンテンツコーディング値トークンのレジストリとして機能します。 content-codingの構文の定義については、[H3.5]を参照してください。
Clients MAY apply content encodings to the body in requests. A server MAY apply content encodings to the bodies in responses. The server MUST only use encodings listed in the Accept-Encoding header field in the request.
クライアントは、リクエストの本文にコンテンツエンコーディングを適用できます（MAY）。サーバーは、応答の本文にコンテンツエンコーディングを適用してもよい（MAY）。サーバーは、リクエストのAccept-Encodingヘッダーフィールドにリストされているエンコーディングのみを使用する必要があります。
The compact form of the Content-Encoding header field is e. Examples:
Content-Encodingヘッダーフィールドのコンパクトな形式はeです。例：
Content-Encoding: gzip e: tar
Content-Encoding：gzip e：tar
See [H14.12]. Example:
[H14.12]を参照してください。例：
Content-Language: fr
コンテンツ言語：fr
The Content-Length header field indicates the size of the message-body, in decimal number of octets, sent to the recipient. Applications SHOULD use this field to indicate the size of the message-body to be transferred, regardless of the media type of the entity. If a stream-based protocol (such as TCP) is used as transport, the header field MUST be used.
The Content-Length header field indicates the size of the message-body, in decimal number of octets, sent to the recipient. Applications SHOULD use this field to indicate the size of the message-body to be transferred, regardless of the media type of the entity. If a stream-based protocol (such as TCP) is used as transport, the header field MUST be used.
The size of the message-body does not include the CRLF separating header fields and body. Any Content-Length greater than or equal to zero is a valid value. If no body is present in a message, then the Content-Length header field value MUST be set to zero.
メッセージ本文のサイズには、ヘッダーフィールドと本文を区切るCRLFは含まれません。ゼロ以上のContent-Lengthは有効な値です。メッセージに本文がない場合は、Content-Lengthヘッダーフィールドの値をゼロに設定する必要があります。
The ability to omit Content-Length simplifies the creation of cgi-like scripts that dynamically generate responses.
Content-Lengthを省略する機能により、動的に応答を生成するcgiのようなスクリプトの作成が簡単になります。
The compact form of the header field is l.
The compact form of the header field is l.
Examples:
例：
Content-Length: 349 l: 173
コンテンツの長さ：349 l：173
The Content-Type header field indicates the media type of the message-body sent to the recipient. The "media-type" element is defined in [H3.7]. The Content-Type header field MUST be present if the body is not empty. If the body is empty, and a Content-Type header field is present, it indicates that the body of the specific type has zero length (for example, an empty audio file).
Content-Typeヘッダーフィールドは、受信者に送信されるメッセージ本文のメディアタイプを示します。 「media-type」要素は[H3.7]で定義されています。本文が空でない場合は、Content-Typeヘッダーフィールドが存在する必要があります。本文が空でContent-Typeヘッダーフィールドが存在する場合は、特定のタイプの本文の長さがゼロであることを示します（たとえば、空のオーディオファイル）。
The compact form of the header field is c.
ヘッダーフィールドのコンパクトな形式はcです。
Examples:
例：
Content-Type: application/sdp
c: text/html; charset=ISO-8859-4
A CSeq header field in a request contains a single decimal sequence number and the request method. The sequence number MUST be expressible as a 32-bit unsigned integer. The method part of CSeq is case-sensitive. The CSeq header field serves to order transactions within a dialog, to provide a means to uniquely identify transactions, and to differentiate between new requests and request retransmissions. Two CSeq header fields are considered equal if the sequence number and the request method are identical. Example:
A CSeq header field in a request contains a single decimal sequence number and the request method. The sequence number MUST be expressible as a 32-bit unsigned integer. The method part of CSeq is case-sensitive. The CSeq header field serves to order transactions within a dialog, to provide a means to uniquely identify transactions, and to differentiate between new requests and request retransmissions. Two CSeq header fields are considered equal if the sequence number and the request method are identical. Example:
CSeq: 4711 INVITE
CSeq：4711 INVITE
The Date header field contains the date and time. Unlike HTTP/1.1, SIP only supports the most recent RFC 1123 [20] format for dates. As in [H3.3], SIP restricts the time zone in SIP-date to "GMT", while RFC 1123 allows any time zone. An RFC 1123 date is case-sensitive.
Dateヘッダーフィールドには、日付と時刻が含まれています。 HTTP / 1.1とは異なり、SIPは日付の最新のRFC 1123 [20]形式のみをサポートします。 [H3.3]と同様に、SIPはSIP-dateのタイムゾーンを「GMT」に制限しますが、RFC 1123は任意のタイムゾーンを許可します。 RFC 1123の日付では大文字と小文字が区別されます。
The Date header field reflects the time when the request or response is first sent.
Dateヘッダーフィールドは、要求または応答が最初に送信された時刻を反映しています。
The Date header field can be used by simple end systems without a battery-backed clock to acquire a notion of current time. However, in its GMT form, it requires clients to know their offset from GMT.
Dateヘッダーフィールドは、バッテリバックアップクロックのない単純なエンドシステムで現在の時間の概念を取得するために使用できます。ただし、そのGMT形式では、クライアントはGMTからのオフセットを知る必要があります。
Example:
例：
Date: Sat, 13 Nov 2010 23:29:00 GMT
The Error-Info header field provides a pointer to additional information about the error status response.
The Error-Info header field provides a pointer to additional information about the error status response.
SIP UACs have user interface capabilities ranging from pop-up windows and audio on PC softclients to audio-only on "black" phones or endpoints connected via gateways. Rather than forcing a server generating an error to choose between sending an error status code with a detailed reason phrase and playing an audio recording, the Error-Info header field allows both to be sent. The UAC then has the choice of which error indicator to render to the caller.
SIP UACには、PCソフトクライアントのポップアップウィンドウとオーディオから、ゲートウェイを介して接続された「黒い」電話またはエンドポイントのオーディオのみに至るまで、ユーザーインターフェイス機能があります。エラーを生成するサーバーに、詳細な理由フレーズを含むエラーステータスコードを送信するか、オーディオ録音を再生するかを選択させるのではなく、Error-Infoヘッダーフィールドで両方を送信できます。 UACは、呼び出し元に表示するエラーインジケーターを選択できます。
A UAC MAY treat a SIP or SIPS URI in an Error-Info header field as if it were a Contact in a redirect and generate a new INVITE, resulting in a recorded announcement session being established. A non-SIP URI MAY be rendered to the user.
UACは、Error-InfoヘッダーフィールドのSIPまたはSIPS URIを、リダイレクトの連絡先であるかのように扱い、新しいINVITEを生成して、アナウンスセッションの記録を確立することができます（MAY）。 SIP以外のURIがユーザーに表示される場合があります。
Examples:
例：
SIP/2.0 404 The number you have dialed is not in service
Error-Info: <sip:not-in-service-recording@atlanta.com>
The Expires header field gives the relative time after which the message (or content) expires.
Expiresヘッダーフィールドは、メッセージ（またはコンテンツ）が期限切れになるまでの相対的な時間を示します。
The precise meaning of this is method dependent.
The precise meaning of this is method dependent.
The expiration time in an INVITE does not affect the duration of the actual session that may result from the invitation. Session description protocols may offer the ability to express time limits on the session duration, however.
INVITEの有効期限は、招待から生じる可能性のある実際のセッションの期間には影響しません。ただし、セッション記述プロトコルは、セッション期間の時間制限を表現する機能を提供する場合があります。
The value of this field is an integral number of seconds (in decimal) between 0 and (2**32)-1, measured from the receipt of the request.
このフィールドの値は、要求の受信から測定された、0から（2 ** 32）-1までの秒数（10進数）の整数です。
Example:
例：
Expires: 5
有効期限：5
The From header field indicates the initiator of the request. This may be different from the initiator of the dialog. Requests sent by the callee to the caller use the callee's address in the From header field.
Fromヘッダーフィールドは、要求の開始者を示します。これは、ダイアログの開始者とは異なる場合があります。呼び出し先から呼び出し元に送信される要求は、Fromヘッダーフィールドの呼び出し先のアドレスを使用します。
The optional "display-name" is meant to be rendered by a human user interface. A system SHOULD use the display name "Anonymous" if the identity of the client is to remain hidden. Even if the "display-name" is empty, the "name-addr" form MUST be used if the "addr-spec" contains a comma, question mark, or semicolon. Syntax issues are discussed in Section 7.3.1.
オプションの「display-name」は、ヒューマンユーザーインターフェイスによってレンダリングされることを意図しています。クライアントのIDを非表示のままにする場合、システムは表示名「匿名」を使用する必要があります。 「display-name」が空の場合でも、「addr-spec」にカンマ、疑問符、またはセミコロンが含まれている場合は、「name-addr」形式を使用する必要があります。構文の問題については、セクション7.3.1で説明します。
Two From header fields are equivalent if their URIs match, and their parameters match. Extension parameters in one header field, not present in the other are ignored for the purposes of comparison. This means that the display name and presence or absence of angle brackets do not affect matching.
2つのFromヘッダーフィールドは、URIが一致し、パラメーターが一致する場合、同等です。 1つのヘッダーフィールドの拡張パラメーターで、他のフィールドには存在しないものは、比較の目的で無視されます。つまり、表示名と山括弧の有無は照合に影響しません。
See Section 20.10 for the rules for parsing a display name, URI and URI parameters, and header field parameters.
表示名、URIおよびURIパラメータ、およびヘッダーフィールドパラメータを解析するためのルールについては、セクション20.10を参照してください。
The compact form of the From header field is f.
The compact form of the From header field is f.
Examples:
例：
From: "A. G. Bell" <sip:agb@bell-telephone.com> ;tag=a48s
From: sip:+12125551212@server.phone2net.com;tag=887s
f: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8
The In-Reply-To header field enumerates the Call-IDs that this call references or returns. These Call-IDs may have been cached by the client then included in this header field in a return call.
The In-Reply-To header field enumerates the Call-IDs that this call references or returns. These Call-IDs may have been cached by the client then included in this header field in a return call.
This allows automatic call distribution systems to route return calls to the originator of the first call. This also allows callees to filter calls, so that only return calls for calls they originated will be accepted. This field is not a substitute for request authentication.
これにより、自動コール分配システムは、リターンコールを最初のコールの発信者にルーティングできます。これにより、受信者は通話をフィルタリングできるため、発信者が発信した通話の戻り通話のみが受け入れられます。このフィールドは、リクエスト認証の代わりにはなりません。
Example:
例：
In-Reply-To: 70710@saturn.bell-tel.com, 17320@saturn.bell-tel.com
The Max-Forwards header field must be used with any SIP method to limit the number of proxies or gateways that can forward the request to the next downstream server. This can also be useful when the client is attempting to trace a request chain that appears to be failing or looping in mid-chain.
Max-Forwardsヘッダーフィールドは、任意のSIPメソッドで使用して、要求を次のダウンストリームサーバーに転送できるプロキシまたはゲートウェイの数を制限する必要があります。これは、クライアントが途中のチェーンで失敗またはループしているように見えるリクエストチェーンをトレースしようとしている場合にも役立ちます。
The Max-Forwards value is an integer in the range 0-255 indicating the remaining number of times this request message is allowed to be forwarded. This count is decremented by each server that forwards the request. The recommended initial value is 70.
Max-Forwards値は0〜255の範囲の整数で、この要求メッセージの転送が許可される残りの回数を示します。このカウントは、要求を転送するサーバーごとに減少します。推奨される初期値は70です。
This header field should be inserted by elements that can not otherwise guarantee loop detection. For example, a B2BUA should insert a Max-Forwards header field.
このヘッダーフィールドは、ループ検出を保証できない要素によって挿入する必要があります。たとえば、B2BUAはMax-Forwardsヘッダーフィールドを挿入する必要があります。
Example:
例：
Max-Forwards: 6
最大フォワード：6
The Min-Expires header field conveys the minimum refresh interval supported for soft-state elements managed by that server. This includes Contact header fields that are stored by a registrar. The header field contains a decimal integer number of seconds from 0 to (2**32)-1. The use of the header field in a 423 (Interval Too Brief) response is described in Sections 10.2.8, 10.3, and 21.4.17.
The Min-Expires header field conveys the minimum refresh interval supported for soft-state elements managed by that server. This includes Contact header fields that are stored by a registrar. The header field contains a decimal integer number of seconds from 0 to (2**32)-1. The use of the header field in a 423 (Interval Too Brief) response is described in Sections 10.2.8, 10.3, and 21.4.17.
Example:
例：
Min-Expires: 60
最小有効期限：60
See [H19.4.1].
See [H19.4.1].
Example:
例：
MIME-Version: 1.0
MIMEバージョン：1.0
The Organization header field conveys the name of the organization to which the SIP element issuing the request or response belongs.
組織ヘッダーフィールドは、要求または応答を発行するSIP要素が属する組織の名前を伝えます。
The field MAY be used by client software to filter calls.
フィールドは、呼び出しをフィルタリングするためにクライアントソフトウェアによって使用される場合があります。
Example:
例：
Organization: Boxes by Bob
組織：ボブによるボックス
The Priority header field indicates the urgency of the request as perceived by the client. The Priority header field describes the priority that the SIP request should have to the receiving human or its agent. For example, it may be factored into decisions about call routing and acceptance. For these decisions, a message containing no Priority header field SHOULD be treated as if it specified a Priority of "normal". The Priority header field does not influence the use of communications resources such as packet forwarding priority in routers or access to circuits in PSTN gateways. The header field can have the values "non-urgent", "normal", "urgent", and "emergency", but additional values can be defined elsewhere. It is RECOMMENDED that the value of "emergency" only be used when life, limb, or property are in imminent danger. Otherwise, there are no semantics defined for this header field.
Priorityヘッダーフィールドは、クライアントが認識したリクエストの緊急度を示します。 Priorityヘッダーフィールドは、受信側の人間またはそのエージェントに対してSIPリクエストが持つべき優先度を示します。たとえば、これは、コールのルーティングと受け入れに関する決定に考慮される場合があります。これらの決定のために、優先度ヘッダーフィールドを含まないメッセージは、「通常」の優先度を指定したかのように扱われるべきです（SHOULD）。 Priorityヘッダーフィールドは、ルーターのパケット転送優先順位やPSTNゲートウェイの回線へのアクセスなどの通信リソースの使用には影響しません。ヘッダーフィールドには「non-urgent」、「normal」、「urgent」、および「emergency」の値を指定できますが、他の場所で追加の値を定義できます。 「緊急」の値は、生命、手足、または財産が差し迫った危険にさらされている場合にのみ使用することをお勧めします。それ以外の場合、このヘッダーフィールドに定義されているセマンティクスはありません。
These are the values of RFC 2076 [38], with the addition of "emergency".
これらはRFC 2076 [38]の値であり、「緊急」が追加されています。
Examples:
例：
Subject: A tornado is heading our way! Priority: emergency
件名：竜巻が向かっています！優先度：緊急
or
または
Subject: Weekend plans Priority: non-urgent
件名：週末の計画優先度：緊急ではない
A Proxy-Authenticate header field value contains an authentication challenge.
Proxy-Authenticateヘッダーフィールドの値には、認証チャレンジが含まれています。
The use of this header field is defined in [H14.33]. See Section 22.3 for further details on its usage.
このヘッダフィールドの使用は[H14.33]で定義されています。使用方法の詳細については、セクション22.3を参照してください。
Example:
例：
Proxy-Authenticate: Digest realm="atlanta.com",
domain="sip:ss1.carrier.com", qop="auth",
nonce="f84f1cec41e6cbe5aea9c8e88d359",
opaque="", stale=FALSE, algorithm=MD5
The Proxy-Authorization header field allows the client to identify itself (or its user) to a proxy that requires authentication. A Proxy-Authorization field value consists of credentials containing the authentication information of the user agent for the proxy and/or realm of the resource being requested.
The Proxy-Authorization header field allows the client to identify itself (or its user) to a proxy that requires authentication. A Proxy-Authorization field value consists of credentials containing the authentication information of the user agent for the proxy and/or realm of the resource being requested.
See Section 22.3 for a definition of the usage of this header field.
このヘッダーフィールドの使用法の定義については、セクション22.3を参照してください。
This header field, along with Authorization, breaks the general rules about multiple header field names. Although not a comma-separated list, this header field name may be present multiple times, and MUST NOT be combined into a single header line using the usual rules described in Section 7.3.1.
このヘッダーフィールドは、Authorizationとともに、複数のヘッダーフィールド名に関する一般的な規則に違反します。コンマで区切られたリストではありませんが、このヘッダーフィールド名は複数回存在する可能性があり、セクション7.3.1で説明されている通常のルールを使用して単一のヘッダー行に結合してはなりません。
Example:
Example:
Proxy-Authorization: Digest username="Alice", realm="atlanta.com",
nonce="c60f3082ee1212b402a21831ae",
response="245f23415f11432b3434341c022"
The Proxy-Require header field is used to indicate proxy-sensitive features that must be supported by the proxy. See Section 20.32 for more details on the mechanics of this message and a usage example.
Proxy-Requireヘッダーフィールドは、プロキシがサポートする必要があるプロキシ依存の機能を示すために使用されます。このメッセージの仕組みの詳細と使用例については、セクション20.32を参照してください。
Example:
例：
Proxy-Require: foo
Proxy-Require：foo
The Record-Route header field is inserted by proxies in a request to force future requests in the dialog to be routed through the proxy.
Record-Routeヘッダーフィールドは、プロキシによってリクエストに挿入され、ダイアログ内の今後のリクエストをプロキシ経由でルーティングするよう強制します。
Examples of its use with the Route header field are described in Sections 16.12.1.
Examples of its use with the Route header field are described in Sections 16.12.1.
Example:
例：
Record-Route: <sip:server10.biloxi.com;lr>,
<sip:bigbox3.site3.atlanta.com;lr>
The Reply-To header field contains a logical return URI that may be different from the From header field. For example, the URI MAY be used to return missed calls or unestablished sessions. If the user wished to remain anonymous, the header field SHOULD either be omitted from the request or populated in such a way that does not reveal any private information.
Reply-Toヘッダーフィールドには、Fromヘッダーフィールドとは異なる可能性がある論理的な戻りURIが含まれます。たとえば、URIは、不在着信または未確立のセッションを返すために使用される場合があります。ユーザーが匿名のままでいることを希望する場合、ヘッダーフィールドはリクエストから省略されるか、個人情報を公開しないように入力する必要があります（SHOULD）。
Even if the "display-name" is empty, the "name-addr" form MUST be used if the "addr-spec" contains a comma, question mark, or semicolon. Syntax issues are discussed in Section 7.3.1.
「display-name」が空の場合でも、「addr-spec」にカンマ、疑問符、またはセミコロンが含まれている場合は、「name-addr」形式を使用する必要があります。構文の問題については、セクション7.3.1で説明します。
Example:
例：
Reply-To: Bob <sip:bob@biloxi.com>
The Require header field is used by UACs to tell UASs about options that the UAC expects the UAS to support in order to process the request. Although an optional header field, the Require MUST NOT be ignored if it is present.
要求ヘッダーフィールドは、UACが要求を処理するためにUASがUASがサポートすることを期待しているオプションについてUASに通知するために使用されます。オプションのヘッダーフィールドですが、存在する場合はRequireを無視してはなりません（MUST NOT）。
The Require header field contains a list of option tags, described in Section 19.2. Each option tag defines a SIP extension that MUST be understood to process the request. Frequently, this is used to indicate that a specific set of extension header fields need to be understood. A UAC compliant to this specification MUST only include option tags corresponding to standards-track RFCs.
The Require header field contains a list of option tags, described in Section 19.2. Each option tag defines a SIP extension that MUST be understood to process the request. Frequently, this is used to indicate that a specific set of extension header fields need to be understood. A UAC compliant to this specification MUST only include option tags corresponding to standards-track RFCs.
Example:
例：
Require: 100rel
Require: 100rel
The Retry-After header field can be used with a 500 (Server Internal Error) or 503 (Service Unavailable) response to indicate how long the service is expected to be unavailable to the requesting client and with a 404 (Not Found), 413 (Request Entity Too Large), 480 (Temporarily Unavailable), 486 (Busy Here), 600 (Busy), or 603 (Decline) response to indicate when the called party anticipates being available again. The value of this field is a positive integer number of seconds (in decimal) after the time of the response.
Retry-Afterヘッダーフィールドを500（サーバーの内部エラー）または503（サービス使用不可）応答で使用して、要求元のクライアントがサービスを利用できないと予想される期間と404（見つかりません）、413（要求されたエンティティが大きすぎる）、480（一時的に利用不可）、486（ここでビジー）、600（ビジー）、または603（拒否）応答は、着信側が再び利用可能になると予測するタイミングを示します。このフィールドの値は、応答時からの正の整数秒数（10進数）です。
An optional comment can be used to indicate additional information about the time of callback. An optional "duration" parameter indicates how long the called party will be reachable starting at the initial time of availability. If no duration parameter is given, the service is assumed to be available indefinitely.
オプションのコメントを使用して、コールバックの時間に関する追加情報を示すことができます。オプションの「期間」パラメータは、最初のアベイラビリティの時間から、着信側に到達できる時間を示します。期間パラメータが指定されていない場合、サービスは無期限に利用可能であると見なされます。
Examples:
例：
Retry-After: 18000;duration=3600
Retry-After: 120 (I'm in a meeting)
The Route header field is used to force routing for a request through the listed set of proxies. Examples of the use of the Route header field are in Section 16.12.1.
Routeヘッダーフィールドは、リストされた一連のプロキシを介してリクエストのルーティングを強制するために使用されます。 Routeヘッダーフィールドの使用例は、セクション16.12.1にあります。
Example:
例：
Route: <sip:bigbox3.site3.atlanta.com;lr>,
<sip:server10.biloxi.com;lr>
The Server header field contains information about the software used by the UAS to handle the request.
Serverヘッダーフィールドには、UASが要求を処理するために使用するソフトウェアに関する情報が含まれています。
Revealing the specific software version of the server might allow the server to become more vulnerable to attacks against software that is known to contain security holes. Implementers SHOULD make the Server header field a configurable option.
サーバーの特定のソフトウェアバージョンを明らかにすると、セキュリティホールが含まれていることがわかっているソフトウェアに対する攻撃に対して、サーバーがより脆弱になる可能性があります。実装者は、サーバーヘッダーフィールドを構成可能なオプションにする必要があります（SHOULD）。
Example:
例：
Server: HomeServer v2
Server: HomeServer v2
The Subject header field provides a summary or indicates the nature of the call, allowing call filtering without having to parse the session description. The session description does not have to use the same subject indication as the invitation.
件名ヘッダーフィールドは、概要を提供するか、通話の性質を示します。これにより、セッションの説明を解析せずに通話をフィルタリングできます。セッションの説明では、招待と同じ件名を使用する必要はありません。
The compact form of the Subject header field is s.
件名ヘッダーフィールドのコンパクトな形式はsです。
Example:
例：
Subject: Need more boxes s: Tech Support
件名：ボックスがさらに必要ですs：テクニカルサポート
The Supported header field enumerates all the extensions supported by the UAC or UAS.
The Supported header field enumerates all the extensions supported by the UAC or UAS.
The Supported header field contains a list of option tags, described in Section 19.2, that are understood by the UAC or UAS. A UA compliant to this specification MUST only include option tags corresponding to standards-track RFCs. If empty, it means that no extensions are supported.
サポートされているヘッダーフィールドには、セクション19.2で説明されている、UACまたはUASによって認識されるオプションタグのリストが含まれています。この仕様に準拠するUAは、標準化過程のRFCに対応するオプションタグのみを含まなければなりません（MUST）。空の場合、サポートされている拡張機能はありません。
The compact form of the Supported header field is k.
サポートされるヘッダーフィールドのコンパクトな形式はkです。
Example:
例：
Supported: 100rel
Supported: 100rel
The Timestamp header field describes when the UAC sent the request to the UAS.
Timestampヘッダーフィールドは、UACがUASにリクエストをいつ送信したかを示します。
See Section 8.2.6 for details on how to generate a response to a request that contains the header field. Although there is no normative behavior defined here that makes use of the header, it allows for extensions or SIP applications to obtain RTT estimates.
See Section 8.2.6 for details on how to generate a response to a request that contains the header field. Although there is no normative behavior defined here that makes use of the header, it allows for extensions or SIP applications to obtain RTT estimates.
Example:
例：
Timestamp: 54
タイムスタンプ：54
The To header field specifies the logical recipient of the request.
Toヘッダーフィールドは、リクエストの論理受信者を指定します。
The optional "display-name" is meant to be rendered by a human-user interface. The "tag" parameter serves as a general mechanism for dialog identification.
オプションの「display-name」は、ヒューマンユーザーインターフェイスによってレンダリングされることを意図しています。 「タグ」パラメータは、ダイアログを識別するための一般的なメカニズムとして機能します。
See Section 19.3 for details of the "tag" parameter.
「タグ」パラメータの詳細については、セクション19.3を参照してください。
Comparison of To header fields for equality is identical to comparison of From header fields. See Section 20.10 for the rules for parsing a display name, URI and URI parameters, and header field parameters.
等しいかどうかのToヘッダーフィールドの比較は、Fromヘッダーフィールドの比較と同じです。表示名、URIおよびURIパラメータ、およびヘッダーフィールドパラメータを解析するためのルールについては、セクション20.10を参照してください。
The compact form of the To header field is t.
Toヘッダーフィールドのコンパクトな形式はtです。
The following are examples of valid To header fields:
次に、有効なToヘッダーフィールドの例を示します。
To: The Operator <sip:operator@cs.columbia.edu>;tag=287447
t: sip:+12125551212@server.phone2net.com
The Unsupported header field lists the features not supported by the UAS. See Section 20.32 for motivation.
The Unsupported header field lists the features not supported by the UAS. See Section 20.32 for motivation.
Example:
例：
Unsupported: foo
サポートされていません：foo
The User-Agent header field contains information about the UAC originating the request. The semantics of this header field are defined in [H14.43].
The User-Agent header field contains information about the UAC originating the request. The semantics of this header field are defined in [H14.43].
Revealing the specific software version of the user agent might allow the user agent to become more vulnerable to attacks against software that is known to contain security holes. Implementers SHOULD make the User-Agent header field a configurable option.
ユーザーエージェントの特定のソフトウェアバージョンを明らかにすると、ユーザーエージェントがセキュリティホールを含むことがわかっているソフトウェアに対する攻撃に対してより脆弱になる可能性があります。実装者は、User-Agentヘッダーフィールドを構成可能なオプションにする必要があります（SHOULD）。
Example:
例：
User-Agent: Softphone Beta1.5
ユーザーエージェント：Softphone Beta1.5
The Via header field indicates the path taken by the request so far and indicates the path that should be followed in routing responses. The branch ID parameter in the Via header field values serves as a transaction identifier, and is used by proxies to detect loops.
Viaヘッダーフィールドは、これまでに要求がたどったパスを示し、ルーティング応答で従う必要があるパスを示します。 Viaヘッダーフィールド値のブランチIDパラメータはトランザクション識別子として機能し、ループを検出するためにプロキシによって使用されます。
A Via header field value contains the transport protocol used to send the message, the client's host name or network address, and possibly the port number at which it wishes to receive responses. A Via header field value can also contain parameters such as "maddr", "ttl", "received", and "branch", whose meaning and use are described in other sections. For implementations compliant to this specification, the value of the branch parameter MUST start with the magic cookie "z9hG4bK", as discussed in Section 8.1.1.7.
Viaヘッダーフィールド値には、メッセージの送信に使用されるトランスポートプロトコル、クライアントのホスト名またはネットワークアドレス、および場合によっては応答の受信を希望するポート番号が含まれます。 Viaヘッダーフィールド値には、「maddr」、「ttl」、「received」、「branch」などのパラメーターを含めることもできます。これらの意味と使用法については、他のセクションで説明します。この仕様に準拠した実装の場合、8.1.1.7項で説明するように、ブランチパラメータの値はマジッククッキー「z9hG4bK」で始まる必要があります。
Transport protocols defined here are "UDP", "TCP", "TLS", and "SCTP". "TLS" means TLS over TCP. When a request is sent to a SIPS URI, the protocol still indicates "SIP", and the transport protocol is TLS.
ここで定義されているトランスポートプロトコルは、「UDP」、「TCP」、「TLS」、および「SCTP」です。 「TLS」は、TLS over TCPを意味します。リクエストがSIPS URIに送信されるとき、プロトコルは引き続き「SIP」を示し、トランスポートプロトコルはTLSです。
Via: SIP/2.0/UDP erlang.bell-telephone.com:5060;branch=z9hG4bK87asdks7
Via: SIP/2.0/UDP 192.0.2.1:5060 ;received=192.0.2.207
;branch=z9hG4bK77asjd
The compact form of the Via header field is v.
Viaヘッダーフィールドのコンパクトな形式はvです。
In this example, the message originated from a multi-homed host with two addresses, 192.0.2.1 and 192.0.2.207. The sender guessed wrong as to which network interface would be used. Erlang.bell-telephone.com noticed the mismatch and added a parameter to the previous hop's Via header field value, containing the address that the packet actually came from.
この例では、メッセージは2つのアドレス192.0.2.1および192.0.2.207を持つマルチホームホストから発信されました。送信者は、どのネットワークインターフェイスが使用されるかを誤って推測しました。 Erlang.bell-telephone.comは不一致に気づき、パケットが実際に送信されたアドレスを含む、前のホップのViaヘッダーフィールド値にパラメーターを追加しました。
The host or network address and port number are not required to follow the SIP URI syntax. Specifically, LWS on either side of the ":" or "/" is allowed, as shown here:
The host or network address and port number are not required to follow the SIP URI syntax. Specifically, LWS on either side of the ":" or "/" is allowed, as shown here:
Via: SIP / 2.0 / UDP first.example.com: 4000;ttl=16
;maddr=224.2.0.1 ;branch=z9hG4bKa7c6a8dlze.1
Even though this specification mandates that the branch parameter be present in all requests, the BNF for the header field indicates that it is optional. This allows interoperation with RFC 2543 elements, which did not have to insert the branch parameter.
Even though this specification mandates that the branch parameter be present in all requests, the BNF for the header field indicates that it is optional. This allows interoperation with RFC 2543 elements, which did not have to insert the branch parameter.
Two Via header fields are equal if their sent-protocol and sent-by fields are equal, both have the same set of parameters, and the values of all parameters are equal.
2つのViaヘッダーフィールドは、それらの送信プロトコルフィールドと送信者フィールドが等しく、両方に同じパラメーターセットがあり、すべてのパラメーターの値が等しい場合に等しくなります。
The Warning header field is used to carry additional information about the status of a response. Warning header field values are sent with responses and contain a three-digit warning code, host name, and warning text.
警告ヘッダーフィールドは、応答のステータスに関する追加情報を伝えるために使用されます。警告ヘッダーフィールドの値は応答とともに送信され、3桁の警告コード、ホスト名、警告テキストが含まれます。
The "warn-text" should be in a natural language that is most likely to be intelligible to the human user receiving the response. This decision can be based on any available knowledge, such as the location of the user, the Accept-Language field in a request, or the Content-Language field in a response. The default language is i-default [21].
「警告テキスト」は、応答を受け取ったユーザーが理解できる可能性が最も高い自然言語である必要があります。この決定は、ユーザーの場所、要求のAccept-Languageフィールド、応答のContent-Languageフィールドなど、利用可能な知識に基づいて行うことができます。デフォルトの言語はi-default [21]です。
The currently-defined "warn-code"s are listed below, with a recommended warn-text in English and a description of their meaning. These warnings describe failures induced by the session description. The first digit of warning codes beginning with "3" indicates warnings specific to SIP. Warnings 300 through 329 are reserved for indicating problems with keywords in the session description, 330 through 339 are warnings related to basic network services requested in the session description, 370 through 379 are warnings related to quantitative QoS parameters requested in the session description, and 390 through 399 are miscellaneous warnings that do not fall into one of the above categories.
現在定義されている「警告コード」と、推奨される警告テキスト（英語）とその意味の説明を以下に示します。これらの警告は、セッションの説明によって引き起こされた障害を説明しています。 「3」で始まる警告コードの最初の桁は、SIP固有の警告を示します。警告300〜329は、セッションの説明のキーワードに関する問題を示すために予約されています。330〜339は、セッションの説明で要求される基本的なネットワークサービスに関連する警告です。370〜379は、セッションの説明で要求される定量的QoSパラメータに関連する警告です。 〜399は、上記のカテゴリのいずれにも該当しないその他の警告です。
300 Incompatible network protocol: One or more network protocols contained in the session description are not available.
300 Incompatible network protocol: One or more network protocols contained in the session description are not available.
301 Incompatible network address formats: One or more network address formats contained in the session description are not available.
301互換性のないネットワークアドレス形式：セッションの説明に含まれている1つ以上のネットワークアドレス形式が使用できません。
302 Incompatible transport protocol: One or more transport protocols described in the session description are not available.
302互換性のないトランスポートプロトコル：セッションの説明に記載されている1つ以上のトランスポートプロトコルが使用できません。
303 Incompatible bandwidth units: One or more bandwidth measurement units contained in the session description were not understood.
303互換性のない帯域幅単位：セッションの説明に含まれる1つ以上の帯域幅測定単位が理解されませんでした。
304 Media type not available: One or more media types contained in the session description are not available.
304メディアタイプを使用できません：セッションの説明に含まれている1つ以上のメディアタイプが使用できません。
305 Incompatible media format: One or more media formats contained in the session description are not available.
305互換性のないメディア形式：セッションの説明に含まれている1つ以上のメディア形式が使用できません。
306 Attribute not understood: One or more of the media attributes in the session description are not supported.
306属性を理解できません：セッションの説明にある1つ以上のメディア属性がサポートされていません。
307 Session description parameter not understood: A parameter other than those listed above was not understood.
307セッション記述パラメーターが理解されていません：上記以外のパラメーターが理解されませんでした。
330 Multicast not available: The site where the user is located does not support multicast.
330マルチキャストを使用できません：ユーザーが配置されているサイトはマルチキャストをサポートしていません。
331 Unicast not available: The site where the user is located does not support unicast communication (usually due to the presence of a firewall).
331 Unicast not available: The site where the user is located does not support unicast communication (usually due to the presence of a firewall).
370 Insufficient bandwidth: The bandwidth specified in the session description or defined by the media exceeds that known to be available.
370不十分な帯域幅：セッションの説明で指定された、またはメディアによって定義された帯域幅が、利用可能であることがわかっている帯域幅を超えています。
399 Miscellaneous warning: The warning text can include arbitrary information to be presented to a human user or logged. A system receiving this warning MUST NOT take any automated action.
399その他の警告：警告テキストには、人間のユーザーに提示する、またはログに記録する任意の情報を含めることができます。この警告を受信するシステムは、自動化されたアクションを実行してはなりません。
1xx and 2xx have been taken by HTTP/1.1.
1xxと2xxはHTTP / 1.1で採用されています。
Additional "warn-code"s can be defined through IANA, as defined in Section 27.2.
セクション27.2で定義されているように、追加の「警告コード」はIANAを通じて定義できます。
Examples:
例：
Warning: 307 isi.edu "Session parameter 'foo' not understood" Warning: 301 isi.edu "Incompatible network address type 'E.164'"
警告：307 isi.edu "セッションパラメータ 'foo'が理解できませんでした"警告：301 isi.edu "互換性のないネットワークアドレスタイプ 'E.164'"
A WWW-Authenticate header field value contains an authentication challenge. See Section 22.2 for further details on its usage.
WWW-Authenticateヘッダーフィールドの値には、認証チャレンジが含まれています。使用方法の詳細については、セクション22.2を参照してください。
Example:
例：
WWW-Authenticate: Digest realm="atlanta.com",
domain="sip:boxesbybob.com", qop="auth",
nonce="f84f1cec41e6cbe5aea9c8e88d359",
opaque="", stale=FALSE, algorithm=MD5
21 Response Codes
21応答コード
The response codes are consistent with, and extend, HTTP/1.1 response codes. Not all HTTP/1.1 response codes are appropriate, and only those that are appropriate are given here. Other HTTP/1.1 response codes SHOULD NOT be used. Also, SIP defines a new class, 6xx.
応答コードは、HTTP / 1.1応答コードと一貫性があり、拡張されています。すべてのHTTP / 1.1応答コードが適切であるとは限らず、適切なものだけがここに示されています。他のHTTP / 1.1応答コードは使用すべきではありません。また、SIPは新しいクラス6xxを定義します。
Provisional responses, also known as informational responses, indicate that the server contacted is performing some further action and does not yet have a definitive response. A server sends a 1xx response if it expects to take more than 200 ms to obtain a final response. Note that 1xx responses are not transmitted reliably. They never cause the client to send an ACK. Provisional (1xx) responses MAY contain message bodies, including session descriptions.
暫定応答は、情報応答とも呼ばれ、接続先のサーバーがさらにアクションを実行中であり、まだ確定的な応答がないことを示しています。サーバーは、最終応答を取得するのに200ミリ秒以上かかると予想される場合、1xx応答を送信します。 1xx応答は確実に送信されないことに注意してください。クライアントにACKを送信させることはありません。暫定（1xx）応答には、セッションの説明を含むメッセージ本文が含まれる場合があります。
This response indicates that the request has been received by the next-hop server and that some unspecified action is being taken on behalf of this call (for example, a database is being consulted). This response, like all other provisional responses, stops retransmissions of an INVITE by a UAC. The 100 (Trying) response is different from other provisional responses, in that it is never forwarded upstream by a stateful proxy.
この応答は、要求がネクストホップサーバーによって受信され、この呼び出しに代わって不特定のアクションが実行されていることを示します（たとえば、データベースが参照されています）。この応答は、他のすべての暫定応答と同様に、UACによるINVITEの再送信を停止します。 100（Trying）応答は、ステートフルプロキシによってアップストリームに転送されることはないという点で、他の暫定応答とは異なります。
The UA receiving the INVITE is trying to alert the user. This response MAY be used to initiate local ringback.
The UA receiving the INVITE is trying to alert the user. This response MAY be used to initiate local ringback.
A server MAY use this status code to indicate that the call is being forwarded to a different set of destinations.
サーバーはこのステータスコードを使用して、呼び出しが別の宛先セットに転送されていることを示すことができます。
The called party is temporarily unavailable, but the server has decided to queue the call rather than reject it. When the callee becomes available, it will return the appropriate final status response. The reason phrase MAY give further details about the status of the call, for example, "5 calls queued; expected waiting time is 15 minutes". The server MAY issue several 182 (Queued) responses to update the caller about the status of the queued call.
The called party is temporarily unavailable, but the server has decided to queue the call rather than reject it. When the callee becomes available, it will return the appropriate final status response. The reason phrase MAY give further details about the status of the call, for example, "5 calls queued; expected waiting time is 15 minutes". The server MAY issue several 182 (Queued) responses to update the caller about the status of the queued call.
The 183 (Session Progress) response is used to convey information about the progress of the call that is not otherwise classified. The Reason-Phrase, header fields, or message body MAY be used to convey more details about the call progress.
183（セッション進行状況）応答は、他の方法では分類されない、通話の進行状況に関する情報を伝えるために使用されます。 Reason-Phrase、ヘッダーフィールド、またはメッセージ本文を使用して、通話の進行状況の詳細を伝えることができます。
The request was successful.
リクエストは成功しました。
The request has succeeded. The information returned with the response depends on the method used in the request.
リクエストは成功しました。応答で返される情報は、要求で使用されるメソッドによって異なります。
3xx responses give information about the user's new location, or about alternative services that might be able to satisfy the call.
3xx応答は、ユーザーの新しい場所に関する情報、または通話に対応できる可能性のある代替サービスに関する情報を提供します。
The address in the request resolved to several choices, each with its own specific location, and the user (or UA) can select a preferred communication end point and redirect its request to that location.
リクエスト内のアドレスはいくつかの選択肢に解決され、それぞれに固有の場所があり、ユーザー（またはUA）は優先通信エンドポイントを選択して、その場所にリクエストをリダイレクトできます。
The response MAY include a message body containing a list of resource characteristics and location(s) from which the user or UA can choose the one most appropriate, if allowed by the Accept request header field. However, no MIME types have been defined for this message body.
The response MAY include a message body containing a list of resource characteristics and location(s) from which the user or UA can choose the one most appropriate, if allowed by the Accept request header field. However, no MIME types have been defined for this message body.
The choices SHOULD also be listed as Contact fields (Section 20.10). Unlike HTTP, the SIP response MAY contain several Contact fields or a list of addresses in a Contact field. UAs MAY use the Contact header field value for automatic redirection or MAY ask the user to confirm a choice. However, this specification does not define any standard for such automatic selection.
選択肢は、連絡先フィールド（セクション20.10）としてリストする必要があります（SHOULD）。 HTTPとは異なり、SIP応答には複数の連絡先フィールドまたは連絡先フィールドのアドレスのリストが含まれる場合があります。 UAは、自動リダイレクトにContactヘッダーフィールド値を使用する場合と、選択を確認するようユーザーに要求する場合があります（MAY）。ただし、この仕様では、このような自動選択の標準を定義していません。
This status response is appropriate if the callee can be reached at several different locations and the server cannot or prefers not to proxy the request.
このステータス応答は、呼び出し先が複数の異なる場所に到達でき、サーバーがリクエストをプロキシできないか、プロキシしないことを希望する場合に適しています。
The user can no longer be found at the address in the Request-URI, and the requesting client SHOULD retry at the new address given by the Contact header field (Section 20.10). The requestor SHOULD update any local directories, address books, and user location caches with this new value and redirect future requests to the address(es) listed.
The user can no longer be found at the address in the Request-URI, and the requesting client SHOULD retry at the new address given by the Contact header field (Section 20.10). The requestor SHOULD update any local directories, address books, and user location caches with this new value and redirect future requests to the address(es) listed.
The requesting client SHOULD retry the request at the new address(es) given by the Contact header field (Section 20.10). The Request-URI of the new request uses the value of the Contact header field in the response.
要求側クライアントは、Contactヘッダーフィールド（セクション20.10）で指定された新しいアドレスで要求を再試行する必要があります（SHOULD）。新しい要求のRequest-URIは、応答のContactヘッダーフィールドの値を使用します。
The duration of the validity of the Contact URI can be indicated through an Expires (Section 20.19) header field or an expires parameter in the Contact header field. Both proxies and UAs MAY cache this URI for the duration of the expiration time. If there is no explicit expiration time, the address is only valid once for recursing, and MUST NOT be cached for future transactions.
Contact URIの有効期間は、Expires（セクション20.19）ヘッダーフィールドまたはContactヘッダーフィールドのexpiresパラメーターを使用して示すことができます。プロキシとUAの両方が、有効期限の間、このURIをキャッシュしてもよい（MAY）。明示的な有効期限がない場合、アドレスは再帰に対して1回のみ有効であり、将来のトランザクションのためにキャッシュしてはなりません。
If the URI cached from the Contact header field fails, the Request-URI from the redirected request MAY be tried again a single time.
ContactヘッダーフィールドからキャッシュされたURIが失敗した場合、リダイレクトされたリクエストからのRequest-URIが1回再試行される場合があります。
The temporary URI may have become out-of-date sooner than the expiration time, and a new temporary URI may be available.
一時URIが有効期限よりも早く古くなっている可能性があり、新しい一時URIが使用可能である可能性があります。
The requested resource MUST be accessed through the proxy given by the Contact field. The Contact field gives the URI of the proxy. The recipient is expected to repeat this single request via the proxy. 305 (Use Proxy) responses MUST only be generated by UASs.
要求されたリソースは、Contactフィールドで指定されたプロキシを介してアクセスする必要があります。 ContactフィールドはプロキシのURIを示します。受信者は、プロキシ経由でこの単一の要求を繰り返すことが期待されています。 305（Use Proxy）応答は、UASによってのみ生成される必要があります。
The call was not successful, but alternative services are possible.
The call was not successful, but alternative services are possible.
The alternative services are described in the message body of the response. Formats for such bodies are not defined here, and may be the subject of future standardization.
代替サービスは、応答のメッセージ本文に記述されています。そのような団体のフォーマットはここでは定義されておらず、将来の標準化の対象となる可能性があります。
4xx responses are definite failure responses from a particular server. The client SHOULD NOT retry the same request without modification (for example, adding appropriate authorization). However, the same request to a different server might be successful.
4xx responses are definite failure responses from a particular server. The client SHOULD NOT retry the same request without modification (for example, adding appropriate authorization). However, the same request to a different server might be successful.
The request could not be understood due to malformed syntax. The Reason-Phrase SHOULD identify the syntax problem in more detail, for example, "Missing Call-ID header field".
不正な構文のため、リクエストを理解できませんでした。 Reason-Phraseは、「Missing Call-ID header field」など、構文の問題をより詳細に特定する必要があります（SHOULD）。
The request requires user authentication. This response is issued by UASs and registrars, while 407 (Proxy Authentication Required) is used by proxy servers.
リクエストにはユーザー認証が必要です。この応答はUASとレジストラによって発行され、407（プロキシ認証が必要）はプロキシサーバーによって使用されます。
Reserved for future use.
将来の使用のために予約されています。
The server understood the request, but is refusing to fulfill it. Authorization will not help, and the request SHOULD NOT be repeated.
サーバーはリクエストを理解しましたが、リクエストの実行を拒否しています。承認は役に立たず、リクエストは繰り返されるべきではありません。
The server has definitive information that the user does not exist at the domain specified in the Request-URI. This status is also returned if the domain in the Request-URI does not match any of the domains handled by the recipient of the request.
サーバーには、Request-URIで指定されたドメインにユーザーが存在しないという明確な情報があります。このステータスは、Request-URIのドメインが、リクエストの受信者が処理するドメインのいずれとも一致しない場合にも返されます。
The method specified in the Request-Line is understood, but not allowed for the address identified by the Request-URI.
Request-Lineで指定されたメソッドは理解されていますが、Request-URIで識別されるアドレスには許可されていません。
The response MUST include an Allow header field containing a list of valid methods for the indicated address.
応答には、指定されたアドレスの有効なメソッドのリストを含むAllowヘッダーフィールドが含まれている必要があります。
The resource identified by the request is only capable of generating response entities that have content characteristics not acceptable according to the Accept header field sent in the request.
The resource identified by the request is only capable of generating response entities that have content characteristics not acceptable according to the Accept header field sent in the request.
This code is similar to 401 (Unauthorized), but indicates that the client MUST first authenticate itself with the proxy. SIP access authentication is explained in Sections 26 and 22.3.
このコードは401（Unauthorized）に似ていますが、クライアントが最初にプロキシで自身を認証する必要があることを示しています。 SIPアクセス認証については、セクション26および22.3で説明しています。
This status code can be used for applications where access to the communication channel (for example, a telephony gateway) rather than the callee requires authentication.
このステータスコードは、呼び出し先ではなく通信チャネル（テレフォニーゲートウェイなど）へのアクセスに認証が必要なアプリケーションに使用できます。
The server could not produce a response within a suitable amount of time, for example, if it could not determine the location of the user in time. The client MAY repeat the request without modifications at any later time.
サーバーは、適切な時間内に応答を生成できませんでした。たとえば、ユーザーの場所を特定できなかった場合などです。クライアントは、いつでも変更なしでリクエストを繰り返すことができます。
The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead.
要求されたリソースはサーバーで使用できなくなり、転送先アドレスが不明です。この状態は永続的であると考えられています。サーバーが状態が永続的であるかどうかを判断できない、または判断する機能がない場合は、代わりにステータスコード404（見つかりません）を使用する必要があります（SHOULD）。
The server is refusing to process a request because the request entity-body is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request.
リクエストのエンティティ本体がサーバーの処理能力または処理能力を超えているため、サーバーはリクエストの処理を拒否しています。サーバーは接続を閉じて、クライアントがリクエストを続行できないようにすることができます。
If the condition is temporary, the server SHOULD include a Retry-After header field to indicate that it is temporary and after what time the client MAY try again.
条件が一時的なものである場合、サーバーはRetry-Afterヘッダーフィールドを含めて、それが一時的なものであること、およびクライアントが再試行する可能性のある時間を示す必要があります。
The server is refusing to service the request because the Request-URI is longer than the server is willing to interpret.
Request-URIがサーバーが解釈するよりも長いため、サーバーは要求の処理を拒否しています。
The server is refusing to service the request because the message body of the request is in a format not supported by the server for the requested method. The server MUST return a list of acceptable formats using the Accept, Accept-Encoding, or Accept-Language header field, depending on the specific problem with the content. UAC processing of this response is described in Section 8.1.3.5.
要求のメッセージ本文の形式が、要求されたメソッドのサーバーでサポートされていないため、サーバーは要求の処理を拒否しています。サーバーは、コンテンツの特定の問題に応じて、Accept、Accept-Encoding、またはAccept-Languageヘッダーフィールドを使用して、受け入れ可能な形式のリストを返す必要があります。この応答のUAC処理については、セクション8.1.3.5で説明しています。
The server cannot process the request because the scheme of the URI in the Request-URI is unknown to the server. Client processing of this response is described in Section 8.1.3.5.
The server cannot process the request because the scheme of the URI in the Request-URI is unknown to the server. Client processing of this response is described in Section 8.1.3.5.
The server did not understand the protocol extension specified in a Proxy-Require (Section 20.29) or Require (Section 20.32) header field. The server MUST include a list of the unsupported extensions in an Unsupported header field in the response. UAC processing of this response is described in Section 8.1.3.5.
サーバーは、Proxy-Require（セクション20.29）またはRequire（セクション20.32）ヘッダーフィールドで指定されたプロトコル拡張を理解できませんでした。サーバーは、応答のサポートされていないヘッダーフィールドにサポートされていない拡張機能のリストを含める必要があります。この応答のUAC処理については、セクション8.1.3.5で説明しています。
The UAS needs a particular extension to process the request, but this extension is not listed in a Supported header field in the request. Responses with this status code MUST contain a Require header field listing the required extensions.
The UAS needs a particular extension to process the request, but this extension is not listed in a Supported header field in the request. Responses with this status code MUST contain a Require header field listing the required extensions.
A UAS SHOULD NOT use this response unless it truly cannot provide any useful service to the client. Instead, if a desirable extension is not listed in the Supported header field, servers SHOULD process the request using baseline SIP capabilities and any extensions supported by the client.
A UAS SHOULD NOT use this response unless it truly cannot provide any useful service to the client. Instead, if a desirable extension is not listed in the Supported header field, servers SHOULD process the request using baseline SIP capabilities and any extensions supported by the client.
The server is rejecting the request because the expiration time of the resource refreshed by the request is too short. This response can be used by a registrar to reject a registration whose Contact header field expiration time was too small. The use of this response and the related Min-Expires header field are described in Sections 10.2.8, 10.3, and 20.23.
リクエストによって更新されたリソースの有効期限が短すぎるため、サーバーはリクエストを拒否しています。レジストラはこの応答を使用して、Contactヘッダーフィールドの有効期限が小さすぎる登録を拒否できます。この応答と関連するMin-Expiresヘッダーフィールドの使用については、セクション10.2.8、10.3、および20.23で説明しています。
The callee's end system was contacted successfully but the callee is currently unavailable (for example, is not logged in, logged in but in a state that precludes communication with the callee, or has activated the "do not disturb" feature). The response MAY indicate a better time to call in the Retry-After header field. The user could also be available elsewhere (unbeknownst to this server). The reason phrase SHOULD indicate a more precise cause as to why the callee is unavailable. This value SHOULD be settable by the UA. Status 486 (Busy Here) MAY be used to more precisely indicate a particular reason for the call failure.
The callee's end system was contacted successfully but the callee is currently unavailable (for example, is not logged in, logged in but in a state that precludes communication with the callee, or has activated the "do not disturb" feature). The response MAY indicate a better time to call in the Retry-After header field. The user could also be available elsewhere (unbeknownst to this server). The reason phrase SHOULD indicate a more precise cause as to why the callee is unavailable. This value SHOULD be settable by the UA. Status 486 (Busy Here) MAY be used to more precisely indicate a particular reason for the call failure.
This status is also returned by a redirect or proxy server that recognizes the user identified by the Request-URI, but does not currently have a valid forwarding location for that user.
このステータスは、Request-URIで識別されたユーザーを認識するリダイレクトサーバーまたはプロキシサーバーからも返されますが、現在そのユーザーには有効な転送場所がありません。
This status indicates that the UAS received a request that does not match any existing dialog or transaction.
このステータスは、UASが既存のダイアログまたはトランザクションと一致しない要求を受信したことを示します。
The server has detected a loop (Section 16.3 Item 4).
サーバーがループを検出しました（セクション16.3アイテム4）。
The server received a request that contains a Max-Forwards (Section 20.22) header field with the value zero.
サーバーは、値がゼロのMax-Forwards（セクション20.22）ヘッダーフィールドを含むリクエストを受信しました。
The server received a request with a Request-URI that was incomplete. Additional information SHOULD be provided in the reason phrase.
The server received a request with a Request-URI that was incomplete. Additional information SHOULD be provided in the reason phrase.
This status code allows overlapped dialing. With overlapped dialing, the client does not know the length of the dialing string. It sends strings of increasing lengths, prompting the user for more input, until it no longer receives a 484 (Address Incomplete) status response.
このステータスコードは、重複したダイヤルを許可します。重複したダイヤリングでは、クライアントはダイヤリング文字列の長さを知りません。長さが増加する文字列を送信し、484（Address Incomplete）ステータス応答を受信しなくなるまで、ユーザーに入力を求めます。
The Request-URI was ambiguous. The response MAY contain a listing of possible unambiguous addresses in Contact header fields. Revealing alternatives can infringe on privacy of the user or the organization. It MUST be possible to configure a server to respond with status 404 (Not Found) or to suppress the listing of possible choices for ambiguous Request-URIs.
Request-URIがあいまいです。応答には、Contactヘッダーフィールドに明確なアドレスのリストが含まれる場合があります。代替案を明らかにすることは、ユーザーまたは組織のプライバシーを侵害する可能性があります。ステータス404（Not Found）で応答するようにサーバーを構成したり、あいまいなRequest-URIの可能な選択肢のリストを抑制したりできるようにする必要があります。
Example response to a request with the Request-URI sip:lee@example.com:
Request-URI sip：lee@example.comを使用したリクエストへの応答例：
SIP/2.0 485 Ambiguous
Contact: Carol Lee <sip:carol.lee@example.com>
Contact: Ping Lee <sip:p.lee@example.com>
Contact: Lee M. Foote <sips:lee.foote@example.com>
Some email and voice mail systems provide this functionality. A status code separate from 3xx is used since the semantics are different: for 300, it is assumed that the same person or service will be reached by the choices provided. While an automated choice or sequential search makes sense for a 3xx response, user intervention is required for a 485 (Ambiguous) response.
Some email and voice mail systems provide this functionality. A status code separate from 3xx is used since the semantics are different: for 300, it is assumed that the same person or service will be reached by the choices provided. While an automated choice or sequential search makes sense for a 3xx response, user intervention is required for a 485 (Ambiguous) response.
The callee's end system was contacted successfully, but the callee is currently not willing or able to take additional calls at this end system. The response MAY indicate a better time to call in the Retry-After header field. The user could also be available elsewhere, such as through a voice mail service. Status 600 (Busy Everywhere) SHOULD be used if the client knows that no other end system will be able to accept this call.
呼び出し先のエンドシステムに正常に接続しましたが、呼び出し先は現在、このエンドシステムで追加の呼び出しを行うことはできません。応答は、Retry-Afterヘッダーフィールドで呼び出すより良い時間を示してもよい（MAY）。ユーザーは、ボイスメールサービスなど、他の場所でも利用できる場合があります。ステータス600（Busy Everywhere）は、他のエンドシステムがこの呼び出しを受け入れることができないことをクライアントが知っている場合に使用する必要があります。
The request was terminated by a BYE or CANCEL request. This response is never returned for a CANCEL request itself.
BYEまたはCANCELリクエストによってリクエストが終了しました。この応答は、CANCEL要求自体に対して返されることはありません。
The response has the same meaning as 606 (Not Acceptable), but only applies to the specific resource addressed by the Request-URI and the request may succeed elsewhere.
応答の意味は606（受け入れ不可）と同じですが、Request-URIによってアドレス指定された特定のリソースにのみ適用され、要求は他の場所で成功する可能性があります。
A message body containing a description of media capabilities MAY be present in the response, which is formatted according to the Accept header field in the INVITE (or application/sdp if not present), the same as a message body in a 200 (OK) response to an OPTIONS request.
メディア機能の説明を含むメッセージ本文が応答に存在する場合があります。これは、INVITEのAcceptヘッダーフィールド（存在しない場合はapplication / sdp）に従ってフォーマットされ、200（OK）のメッセージ本文と同じです。 OPTIONSリクエストへの応答。
The request was received by a UAS that had a pending request within the same dialog. Section 14.2 describes how such "glare" situations are resolved.
同じダイアログ内に保留中の要求があったUASが要求を受信しました。セクション14.2では、そのような「まぶしさ」の状況がどのように解決されるかについて説明します。
The request was received by a UAS that contained an encrypted MIME body for which the recipient does not possess or will not provide an appropriate decryption key. This response MAY have a single body containing an appropriate public key that should be used to encrypt MIME bodies sent to this UA. Details of the usage of this response code can be found in Section 23.2.
要求は、受信者が所有していないか、適切な復号化キーを提供しない暗号化されたMIME本文を含むUASによって受信されました。この応答は、このUAに送信されるMIME本文を暗号化するために使用する必要がある適切な公開鍵を含む単一の本文を持つ場合があります。この応答コードの使用法の詳細は項23.2にあります。
5xx responses are failure responses given when a server itself has erred.
5xx応答は、サーバー自体にエラーが発生したときに与えられる失敗応答です。
The server encountered an unexpected condition that prevented it from fulfilling the request. The client MAY display the specific error condition and MAY retry the request after several seconds.
サーバーで予期しない状態が発生したため、リクエストを実行できませんでした。クライアントは特定のエラー状態を表示してもよく（MAY）、数秒後にリクエストを再試行してもよい（MAY）。
If the condition is temporary, the server MAY indicate when the client may retry the request using the Retry-After header field.
条件が一時的である場合、サーバーは、クライアントがRetry-Afterヘッダーフィールドを使用してリクエストを再試行できる時期を示すことができます。
The server does not support the functionality required to fulfill the request. This is the appropriate response when a UAS does not recognize the request method and is not capable of supporting it for any user. (Proxies forward all requests regardless of method.)
サーバーは、要求を満たすために必要な機能をサポートしていません。これは、UASが要求メソッドを認識せず、どのユーザーに対してもそれをサポートできない場合の適切な応答です。 （プロキシは、メソッドに関係なくすべてのリクエストを転送します。）
Note that a 405 (Method Not Allowed) is sent when the server recognizes the request method, but that method is not allowed or supported.
サーバーが要求メソッドを認識したときに405（メソッドは許可されていません）が送信されますが、そのメソッドは許可またはサポートされていないことに注意してください。
The server, while acting as a gateway or proxy, received an invalid response from the downstream server it accessed in attempting to fulfill the request.
サーバーは、ゲートウェイまたはプロキシとして機能しているときに、要求を満たすためにアクセスしたダウンストリームサーバーから無効な応答を受け取りました。
The server is temporarily unable to process the request due to a temporary overloading or maintenance of the server. The server MAY indicate when the client should retry the request in a Retry-After header field. If no Retry-After is given, the client MUST act as if it had received a 500 (Server Internal Error) response.
サーバーの一時的な過負荷またはメンテナンスのため、サーバーは一時的に要求を処理できません。サーバーは、クライアントがRetry-Afterヘッダーフィールドのリクエストをいつ再試行する必要があるかを示してもよい（MAY）。 Retry-Afterが指定されていない場合、クライアントは、500（サーバー内部エラー）応答を受信したかのように動作する必要があります。
A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD attempt to forward the request to an alternate server. It SHOULD NOT forward any other requests to that server for the duration specified in the Retry-After header field, if present.
503（Service Unavailable）を受信するクライアント（プロキシまたはUAC）は、リクエストを代替サーバーに転送する必要があります（SHOULD）。存在する場合は、Retry-Afterヘッダーフィールドで指定された期間、他の要求をそのサーバーに転送しないでください。
Servers MAY refuse the connection or drop the request instead of responding with 503 (Service Unavailable).
Servers MAY refuse the connection or drop the request instead of responding with 503 (Service Unavailable).
The server did not receive a timely response from an external server it accessed in attempting to process the request. 408 (Request Timeout) should be used instead if there was no response within the period specified in the Expires header field from the upstream server.
The server did not receive a timely response from an external server it accessed in attempting to process the request. 408 (Request Timeout) should be used instead if there was no response within the period specified in the Expires header field from the upstream server.
The server does not support, or refuses to support, the SIP protocol version that was used in the request. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client, other than with this error message.
サーバーは、要求で使用されたSIPプロトコルバージョンをサポートしないか、サポートを拒否します。サーバーは、このエラーメッセージ以外では、クライアントと同じメジャーバージョンを使用して要求を完了できないか、または実行したくないことを示しています。
The server was unable to process the request since the message length exceeded its capabilities.
メッセージの長さがその機能を超えたため、サーバーは要求を処理できませんでした。
6xx responses indicate that a server has definitive information about a particular user, not just the particular instance indicated in the Request-URI.
6xx応答は、サーバーが、Request-URIに示されている特定のインスタンスだけでなく、特定のユーザーに関する明確な情報を持っていることを示しています。
The callee's end system was contacted successfully but the callee is busy and does not wish to take the call at this time. The response MAY indicate a better time to call in the Retry-After header field. If the callee does not wish to reveal the reason for declining the call, the callee uses status code 603 (Decline) instead. This status response is returned only if the client knows that no other end point (such as a voice mail system) will answer the request. Otherwise, 486 (Busy Here) should be returned.
呼び出し先のエンドシステムに正常に接続されましたが、呼び出し先はビジー状態であり、現時点では呼び出しを受け付けません。応答は、Retry-Afterヘッダーフィールドで呼び出すより良い時間を示してもよい（MAY）。呼び出し先が呼び出しを拒否する理由を明らかにしたくない場合、呼び出し先は代わりにステータスコード603（拒否）を使用します。このステータス応答は、他のエンドポイント（ボイスメールシステムなど）が要求に応答しないことをクライアントが知っている場合にのみ返されます。それ以外の場合は、486（Busy Here）が返されます。
The callee's machine was successfully contacted but the user explicitly does not wish to or cannot participate. The response MAY indicate a better time to call in the Retry-After header field. This status response is returned only if the client knows that no other end point will answer the request.
呼び出し先のマシンに正常に接続しましたが、ユーザーは明示的に参加したくないか、参加できません。応答は、Retry-Afterヘッダーフィールドで呼び出すより良い時間を示してもよい（MAY）。このステータス応答は、他のエンドポイントが要求に応答しないことをクライアントが知っている場合にのみ返されます。
The server has authoritative information that the user indicated in the Request-URI does not exist anywhere.
サーバーには、Request-URIで示されたユーザーがどこにも存在しないという信頼できる情報があります。
The user's agent was contacted successfully but some aspects of the session description such as the requested media, bandwidth, or addressing style were not acceptable.
ユーザーのエージェントに正常に接続しましたが、要求されたメディア、帯域幅、アドレッシングスタイルなど、セッションの説明の一部の側面が受け入れられませんでした。
A 606 (Not Acceptable) response means that the user wishes to communicate, but cannot adequately support the session described. The 606 (Not Acceptable) response MAY contain a list of reasons in a Warning header field describing why the session described cannot be supported. Warning reason codes are listed in Section 20.43.
606（Not Acceptable）応答は、ユーザーが通信したいが、説明されているセッションを適切にサポートできないことを意味します。 606（Not Acceptable）応答には、説明されたセッションがサポートできない理由を説明する警告ヘッダーフィールドに理由のリストが含まれている場合があります。警告理由コードは、セクション20.43にリストされています。
A message body containing a description of media capabilities MAY be present in the response, which is formatted according to the Accept header field in the INVITE (or application/sdp if not present), the same as a message body in a 200 (OK) response to an OPTIONS request.
メディア機能の説明を含むメッセージ本文が応答に存在する場合があります。これは、INVITEのAcceptヘッダーフィールド（存在しない場合はapplication / sdp）に従ってフォーマットされ、200（OK）のメッセージ本文と同じです。 OPTIONSリクエストへの応答。
It is hoped that negotiation will not frequently be needed, and when a new user is being invited to join an already existing conference, negotiation may not be possible. It is up to the invitation initiator to decide whether or not to act on a 606 (Not Acceptable) response.
ネゴシエーションが頻繁に不要になることが望まれます。また、新しいユーザーが既存の会議に参加するよう招待されている場合、ネゴシエーションができない場合があります。 606（Not Acceptable）応答に基づいて行動するかどうかを決定するのは招待の開始者次第です。
This status response is returned only if the client knows that no other end point will answer the request.
このステータス応答は、他のエンドポイントが要求に応答しないことをクライアントが知っている場合にのみ返されます。
22 Usage of HTTP Authentication
22 HTTP認証の使用
SIP provides a stateless, challenge-based mechanism for authentication that is based on authentication in HTTP. Any time that a proxy server or UA receives a request (with the exceptions given in Section 22.1), it MAY challenge the initiator of the request to provide assurance of its identity. Once the originator has been identified, the recipient of the request SHOULD ascertain whether or not this user is authorized to make the request in question. No authorization systems are recommended or discussed in this document.
SIPは、HTTPでの認証に基づく認証のための、ステートレスなチャレンジベースのメカニズムを提供します。プロキシサーバーまたはUAがリクエストを受信するときはいつでも（セクション22.1に示されている例外を除き）、IDの保証を提供するようにリクエストのイニシエーターにチャレンジすることができます。発信者が特定されると、要求の受信者は、このユーザーが問題の要求を行うことを許可されているかどうかを確認する必要があります。このドキュメントでは、承認システムは推奨または説明されていません。
The "Digest" authentication mechanism described in this section provides message authentication and replay protection only, without message integrity or confidentiality. Protective measures above and beyond those provided by Digest need to be taken to prevent active attackers from modifying SIP requests and responses.
このセクションで説明する「ダイジェスト」認証メカニズムは、メッセージの完全性や機密性なしで、メッセージ認証と再生保護のみを提供します。アクティブな攻撃者がSIPリクエストとSIPリクエストを変更できないようにするには、ダイジェストが提供する以上の保護対策を講じる必要があります。
Note that due to its weak security, the usage of "Basic" authentication has been deprecated. Servers MUST NOT accept credentials using the "Basic" authorization scheme, and servers also MUST NOT challenge with "Basic". This is a change from RFC 2543.
セキュリティが弱いため、「基本」認証の使用は推奨されていません。サーバーは、「基本」認証スキームを使用して資格情報を受け入れてはならず（MUST NOT）、サーバーは「基本」にチャレンジしてはなりません。これはRFC 2543からの変更点です。
The framework for SIP authentication closely parallels that of HTTP (RFC 2617 [17]). In particular, the BNF for auth-scheme, auth-param, challenge, realm, realm-value, and credentials is identical (although the usage of "Basic" as a scheme is not permitted). In SIP, a UAS uses the 401 (Unauthorized) response to challenge the identity of a UAC. Additionally, registrars and redirect servers MAY make use of 401 (Unauthorized) responses for authentication, but proxies MUST NOT, and instead MAY use the 407 (Proxy Authentication Required) response. The requirements for inclusion of the Proxy-Authenticate, Proxy-Authorization, WWW-Authenticate, and Authorization in the various messages are identical to those described in RFC 2617 [17].
SIP認証のフレームワークは、HTTPのフレームワークと非常によく似ています（RFC 2617 [17]）。特に、auth-scheme、auth-param、challenge、realm、realm-value、および信任状のBNFは同じです（ただし、スキームとしての「Basic」の使用は許可されていません）。 SIPでは、UASは401（無許可）応答を使用して、UACのIDを要求します。さらに、レジストラーとリダイレクトサーバーは、認証に401（無許可）応答を使用する場合がありますが、プロキシは使用してはならず、代わりに407（プロキシ認証が必要）応答を使用する必要があります。さまざまなメッセージにProxy-Authenticate、Proxy-Authorization、WWW-Authenticate、およびAuthorizationを含めるための要件は、RFC 2617 [17]で説明されている要件と同じです。
Since SIP does not have the concept of a canonical root URL, the notion of protection spaces is interpreted differently in SIP. The realm string alone defines the protection domain. This is a change from RFC 2543, in which the Request-URI and the realm together defined the protection domain.
SIPには正規ルートURLの概念がないため、SIPでは保護スペースの概念の解釈が異なります。領域文字列だけで保護ドメインを定義します。これはRFC 2543からの変更で、Request-URIとレルムが一緒に保護ドメインを定義しました。
This previous definition of protection domain caused some amount of confusion since the Request-URI sent by the UAC and the Request-URI received by the challenging server might be different, and indeed the final form of the Request-URI might not be known to the UAC. Also, the previous definition depended on the presence of a SIP URI in the Request-URI and seemed to rule out alternative URI schemes (for example, the tel URL).
この以前の保護ドメインの定義では、UACによって送信されたRequest-URIとチャレンジングサーバーによって受信されたRequest-URIが異なる場合があり、実際にRequest-URIの最終的な形式がUAC。また、以前の定義は、Request-URI内のSIP URIの存在に依存しており、代替のURIスキーム（たとえば、tel URL）を除外するように見えました。
Operators of user agents or proxy servers that will authenticate received requests MUST adhere to the following guidelines for creation of a realm string for their server:
受信したリクエストを認証するユーザーエージェントまたはプロキシサーバーのオペレーターは、サーバーのレルム文字列の作成に関する次のガイドラインに準拠する必要があります。
o Realm strings MUST be globally unique. It is RECOMMENDED that a realm string contain a hostname or domain name, following the recommendation in Section 3.2.1 of RFC 2617 [17].
o レルム文字列はグローバルに一意である必要があります。 RFC 2617 [17]のセクション3.2.1の推奨に従って、領域文字列にホスト名またはドメイン名を含めることをお勧めします。
o Realm strings SHOULD present a human-readable identifier that can be rendered to a user.
o レルム文字列は、ユーザーに表示できる人間が読める識別子を提示する必要があります（SHOULD）。
For example:
例えば：
INVITE sip:bob@biloxi.com SIP/2.0
Authorization: Digest realm="biloxi.com", <...>
Generally, SIP authentication is meaningful for a specific realm, a protection domain. Thus, for Digest authentication, each such protection domain has its own set of usernames and passwords. If a server does not require authentication for a particular request, it MAY accept a default username, "anonymous", which has no password (password of ""). Similarly, UACs representing many users, such as PSTN gateways, MAY have their own device-specific username and password, rather than accounts for particular users, for their realm.
一般に、SIP認証は特定のレルムである保護ドメインにとって意味があります。したがって、ダイジェスト認証では、このような保護ドメインごとに独自のユーザー名とパスワードのセットがあります。サーバーが特定のリクエストに対して認証を必要としない場合、デフォルトのユーザー名「anonymous」を受け入れてもよい（MAY）。パスワードはありません（パスワード「」）。同様に、PSTNゲートウェイなどの多くのユーザーを表すUACは、レルムに対して特定のユーザーのアカウントではなく、独自のデバイス固有のユーザー名とパスワードを持っている場合があります。
While a server can legitimately challenge most SIP requests, there are two requests defined by this document that require special handling for authentication: ACK and CANCEL.
サーバーはほとんどのSIP要求に合法的にチャレンジできますが、このドキュメントで定義されている認証には特別な処理が必要な2つの要求があります。ACKとCANCELです。
Under an authentication scheme that uses responses to carry values used to compute nonces (such as Digest), some problems come up for any requests that take no response, including ACK. For this reason, any credentials in the INVITE that were accepted by a server MUST be accepted by that server for the ACK. UACs creating an ACK message will duplicate all of the Authorization and Proxy-Authorization header field values that appeared in the INVITE to which the ACK corresponds. Servers MUST NOT attempt to challenge an ACK.
Under an authentication scheme that uses responses to carry values used to compute nonces (such as Digest), some problems come up for any requests that take no response, including ACK. For this reason, any credentials in the INVITE that were accepted by a server MUST be accepted by that server for the ACK. UACs creating an ACK message will duplicate all of the Authorization and Proxy-Authorization header field values that appeared in the INVITE to which the ACK corresponds. Servers MUST NOT attempt to challenge an ACK.
Although the CANCEL method does take a response (a 2xx), servers MUST NOT attempt to challenge CANCEL requests since these requests cannot be resubmitted. Generally, a CANCEL request SHOULD be accepted by a server if it comes from the same hop that sent the request being canceled (provided that some sort of transport or network layer security association, as described in Section 26.2.1, is in place).
CANCELメソッドは応答（2xx）を受け取りますが、CANCEL要求は再送信できないため、サーバーはCANCEL要求にチャレンジしてはなりません。一般に、キャンセルされた要求を送信したのと同じホップから送信された場合、サーバーはCANCEL要求を受け入れる必要があります（セクション26.2.1で説明されているようなトランスポートまたはネットワークレイヤーのセキュリティアソシエーションがある場合）。
When a UAC receives a challenge, it SHOULD render to the user the contents of the "realm" parameter in the challenge (which appears in either a WWW-Authenticate header field or Proxy-Authenticate header field) if the UAC device does not already know of a credential for the realm in question. A service provider that pre-configures UAs with credentials for its realm should be aware that users will not have the opportunity to present their own credentials for this realm when challenged at a pre-configured device.
UACがチャレンジを受信すると、UACデバイスがまだ認識していない場合、チャレンジの「レルム」パラメーター（WWW-AuthenticateヘッダーフィールドまたはProxy-Authenticateヘッダーフィールドに表示される）のコンテンツをユーザーにレンダリングする必要があります（SHOULD）。問題のレルムのクレデンシャルの。レルムの資格情報を使用してUAを事前設定するサービスプロバイダーは、事前設定されたデバイスでチャレンジされたときに、ユーザーがこのレルムの独自の資格情報を提示する機会がないことに注意する必要があります。
Finally, note that even if a UAC can locate credentials that are associated with the proper realm, the potential exists that these credentials may no longer be valid or that the challenging server will not accept these credentials for whatever reason (especially when "anonymous" with no password is submitted). In this instance a server may repeat its challenge, or it may respond with a 403 Forbidden. A UAC MUST NOT re-attempt requests with the credentials that have just been rejected (though the request may be retried if the nonce was stale).
最後に、UACが適切なレルムに関連付けられている資格情報を見つけることができたとしても、これらの資格情報が有効でなくなったり、何らかの理由で（特に「匿名」でパスワードは送信されません）。この場合、サーバーはチャレンジを繰り返すか、403 Forbiddenで応答します。 UACは、拒否されたばかりの資格情報を使用して要求を再試行してはなりません（ただし、nonceが古くなっている場合、要求は再試行される可能性があります）。
When a UAS receives a request from a UAC, the UAS MAY authenticate the originator before the request is processed. If no credentials (in the Authorization header field) are provided in the request, the UAS can challenge the originator to provide credentials by rejecting the request with a 401 (Unauthorized) status code.
UASがUACから要求を受信すると、UASは要求が処理される前に発信者を認証できます（MAY）。 （Authorizationヘッダーフィールドの）資格情報が要求で提供されない場合、UASは、401（Unauthorized）ステータスコードで要求を拒否することにより、発信者に資格情報の提供を要求できます。
The WWW-Authenticate response-header field MUST be included in 401 (Unauthorized) response messages. The field value consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the realm.
WWW-Authenticate応答ヘッダーフィールドは、401（無許可）応答メッセージに含まれている必要があります。フィールド値は、レルムに適用可能な認証方式とパラメータを示す少なくとも1つのチャレンジで構成されます。
An example of the WWW-Authenticate header field in a 401 challenge is:
401チャレンジのWWW-Authenticateヘッダーフィールドの例は次のとおりです。
WWW-Authenticate: Digest realm="biloxi.com", qop="auth,auth-int", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41"
WWW-Authenticate：Digest realm = "biloxi.com"、qop = "auth、auth-int"、nonce = "dcd98b7102dd2f0e8b11d0f600bfb0c093"、opaque = "5ccc069c403ebaf9f0171e9517f40e41"
When the originating UAC receives the 401 (Unauthorized), it SHOULD, if it is able, re-originate the request with the proper credentials. The UAC may require input from the originating user before proceeding. Once authentication credentials have been supplied (either directly by the user, or discovered in an internal keyring), UAs SHOULD cache the credentials for a given value of the To header field and "realm" and attempt to re-use these values on the next request for that destination. UAs MAY cache credentials in any way they would like.
元のUACが401（無許可）を受信すると、可能であれば、適切な資格情報を使用して要求を再発信する必要があります（SHOULD）。 UACは、続行する前に発信元ユーザーからの入力を必要とする場合があります。認証資格情報が（ユーザーによって直接、または内部キーリングで検出されて）提供されると、UAはToヘッダーフィールドと「レルム」の指定された値の資格情報をキャッシュし、次のときにこれらの値の再利用を試みる必要があります（SHOULD）。その宛先のリクエスト。 UAは、希望する方法で資格情報をキャッシュできます。
If no credentials for a realm can be located, UACs MAY attempt to retry the request with a username of "anonymous" and no password (a password of "").
レルムの資格情報が見つからない場合、UACは、「匿名」のユーザー名とパスワード（「」のパスワード）なしで要求を再試行する場合があります。
Once credentials have been located, any UA that wishes to authenticate itself with a UAS or registrar -- usually, but not necessarily, after receiving a 401 (Unauthorized) response -- MAY do so by including an Authorization header field with the request. The Authorization field value consists of credentials containing the authentication information of the UA for the realm of the resource being requested as well as parameters required in support of authentication and replay protection.
資格情報が見つかると、UASまたはレジストラで自身を認証することを望むすべてのUA（通常、ただし必須ではありませんが、401（Unauthorized）応答を受け取った後）は、要求にAuthorizationヘッダーフィールドを含めることで可能になります。 Authorizationフィールド値は、要求されているリソースのレルムのUAの認証情報を含む資格情報と、認証とリプレイ保護のサポートに必要なパラメーターで構成されます。
An example of the Authorization header field is:
Authorizationヘッダーフィールドの例は次のとおりです。
Authorization: Digest username="bob",
realm="biloxi.com",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="sip:bob@biloxi.com",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
When a UAC resubmits a request with its credentials after receiving a 401 (Unauthorized) or 407 (Proxy Authentication Required) response, it MUST increment the CSeq header field value as it would normally when sending an updated request.
UACが401（無許可）または407（プロキシ認証が必要）応答を受信した後、資格情報を使用して要求を再送信する場合、更新された要求を送信するときと同じように、CSeqヘッダーフィールド値をインクリメントする必要があります。
Similarly, when a UAC sends a request to a proxy server, the proxy server MAY authenticate the originator before the request is processed. If no credentials (in the Proxy-Authorization header field) are provided in the request, the proxy can challenge the originator to provide credentials by rejecting the request with a 407 (Proxy Authentication Required) status code. The proxy MUST populate the 407 (Proxy Authentication Required) message with a Proxy-Authenticate header field value applicable to the proxy for the requested resource.
同様に、UACがリクエストをプロキシサーバーに送信すると、プロキシサーバーはリクエストが処理される前に発信者を認証できます。要求に資格情報（Proxy-Authorizationヘッダーフィールド内）が提供されていない場合、プロキシは407（プロキシ認証が必要）ステータスコードで要求を拒否することにより、発信者に資格情報の提供を要求できます。プロキシは、要求されたリソースのプロキシに適用可能なProxy-Authenticateヘッダーフィールド値を407（Proxy Authentication Required）メッセージに入力する必要があります。
The use of Proxy-Authenticate and Proxy-Authorization parallel that described in [17], with one difference. Proxies MUST NOT add values to the Proxy-Authorization header field. All 407 (Proxy Authentication Required) responses MUST be forwarded upstream toward the UAC following the procedures for any other response. It is the UAC's responsibility to add the Proxy-Authorization header field value containing credentials for the realm of the proxy that has asked for authentication.
Proxy-AuthenticateとProxy-Authorizationの使用は、[17]で説明されているのと同じですが、1つの違いがあります。プロキシは、Proxy-Authorizationヘッダーフィールドに値を追加してはなりません。すべての407（プロキシ認証が必要）応答は、他の応答の手順に従ってUACに向けてアップストリームに転送する必要があります。認証を要求したプロキシのレルムの資格情報を含むProxy-Authorizationヘッダーフィールド値を追加するのはUACの責任です。
If a proxy were to resubmit a request adding a Proxy-Authorization header field value, it would need to increment the CSeq in the new request. However, this would cause the UAC that submitted the original request to discard a response from the UAS, as the CSeq value would be different.
プロキシがProxy-Authorizationヘッダーフィールド値を追加してリクエストを再送信する場合、新しいリクエストのCSeqをインクリメントする必要があります。ただし、CSeq値が異なるため、元の要求を送信したUACがUASからの応答を破棄することになります。
When the originating UAC receives the 407 (Proxy Authentication Required) it SHOULD, if it is able, re-originate the request with the proper credentials. It should follow the same procedures for the display of the "realm" parameter that are given above for responding to 401.
発信元UACが407（プロキシ認証が必要）を受信すると、それが可能であれば、適切な資格情報を使用して要求を再発信する必要があります（SHOULD）。 401に応答するための上記の「レルム」パラメーターの表示と同じ手順に従う必要があります。
If no credentials for a realm can be located, UACs MAY attempt to retry the request with a username of "anonymous" and no password (a password of "").
レルムの資格情報が見つからない場合、UACは、「匿名」のユーザー名とパスワード（「」のパスワード）なしで要求を再試行する場合があります。
The UAC SHOULD also cache the credentials used in the re-originated request.
UACは、再発信された要求で使用される資格情報もキャッシュする必要があります（SHOULD）。
The following rule is RECOMMENDED for proxy credential caching:
次のルールは、プロキシ資格情報のキャッシュに推奨されます。
If a UA receives a Proxy-Authenticate header field value in a 401/407 response to a request with a particular Call-ID, it should incorporate credentials for that realm in all subsequent requests that contain the same Call-ID. These credentials MUST NOT be cached across dialogs; however, if a UA is configured with the realm of its local outbound proxy, when one exists, then the UA MAY cache credentials for that realm across dialogs. Note that this does mean a future request in a dialog could contain credentials that are not needed by any proxy along the Route header path.
UAが特定のCall-IDを持つ要求への401/407応答でProxy-Authenticateヘッダーフィールド値を受信する場合、それは同じCall-IDを含む後続のすべての要求にそのレルムの資格情報を組み込む必要があります。これらの資格情報は、ダイアログ間でキャッシュしてはなりません（MUST NOT）。ただし、UAがローカルの発信プロキシのレルムで構成されている場合、存在する場合、UAはダイアログ全体でそのレルムの資格をキャッシュできます（MAY）。これは、ダイアログの将来のリクエストに、ルートヘッダーパス上のプロキシが必要としない資格情報が含まれる可能性があることを意味することに注意してください。
Any UA that wishes to authenticate itself to a proxy server -- usually, but not necessarily, after receiving a 407 (Proxy Authentication Required) response -- MAY do so by including a Proxy-Authorization header field value with the request. The Proxy-Authorization request-header field allows the client to identify itself (or its user) to a proxy that requires authentication. The Proxy-Authorization header field value consists of credentials containing the authentication information of the UA for the proxy and/or realm of the resource being requested.
プロキシサーバーに対して自分自身を認証することを望むすべてのUA-通常は、必須ではありませんが、407（Proxy Authentication Required）応答を受け取った後-要求にProxy-Authorizationヘッダーフィールド値を含めることによって、そうすることができます。 Proxy-Authorizationリクエストヘッダーフィールドを使用すると、認証を必要とするプロキシに対してクライアント（またはそのユーザー）を識別できます。 Proxy-Authorizationヘッダーフィールド値は、リクエストされているリソースのプロキシまたはレルム、あるいはその両方のUAの認証情報を含む資格情報で構成されています。
A Proxy-Authorization header field value applies only to the proxy whose realm is identified in the "realm" parameter (this proxy may previously have demanded authentication using the Proxy-Authenticate field). When multiple proxies are used in a chain, a Proxy-Authorization header field value MUST NOT be consumed by any proxy whose realm does not match the "realm" parameter specified in that value.
Proxy-Authorizationヘッダーフィールドの値は、「realm」パラメーターでレルムが識別されているプロキシにのみ適用されます（このプロキシは、以前にProxy-Authenticateフィールドを使用した認証を要求した可能性があります）。チェーンで複数のプロキシが使用されている場合、Proxy-Authorizationヘッダーフィールドの値は、そのレルムがその値で指定された「レルム」パラメーターと一致しないプロキシによって消費されてはなりません（MUST NOT）。
Note that if an authentication scheme that does not support realms is used in the Proxy-Authorization header field, a proxy server MUST attempt to parse all Proxy-Authorization header field values to determine whether one of them has what the proxy server considers to be valid credentials. Because this is potentially very time-consuming in large networks, proxy servers SHOULD use an authentication scheme that supports realms in the Proxy-Authorization header field.
レルムをサポートしていない認証方式がProxy-Authorizationヘッダーフィールドで使用されている場合、プロキシサーバーはすべてのProxy-Authorizationヘッダーフィールド値を解析して、プロキシサーバーが有効と見なすものがあるかどうかを判別する必要があることに注意してください。資格情報。これは大規模なネットワークでは非常に時間がかかる可能性があるため、プロキシサーバーは、Proxy-Authorizationヘッダーフィールドでレルムをサポートする認証スキームを使用する必要があります（SHOULD）。
If a request is forked (as described in Section 16.7), various proxy servers and/or UAs may wish to challenge the UAC. In this case, the forking proxy server is responsible for aggregating these challenges into a single response. Each WWW-Authenticate and Proxy-Authenticate value received in responses to the forked request MUST be placed into the single response that is sent by the forking proxy to the UA; the ordering of these header field values is not significant.
リクエストがフォークされた場合（セクション16.7で説明）、さまざまなプロキシサーバーやUAがUACへのチャレンジを希望する場合があります。この場合、フォーキングプロキシサーバーは、これらの課題を単一の応答に集約する役割を果たします。 forkされたリクエストへの応答で受信された各WWW-AuthenticateとProxy-Authenticateの値は、forkプロキシからUAに送信される単一の応答に配置する必要があります。これらのヘッダーフィールド値の順序は重要ではありません。
When a proxy server issues a challenge in response to a request, it will not proxy the request until the UAC has retried the request with valid credentials. A forking proxy may forward a request simultaneously to multiple proxy servers that require authentication, each of which in turn will not forward the request until the originating UAC has authenticated itself in their respective realm. If the UAC does not provide credentials for each challenge, the proxy servers that issued the challenges will not forward requests to the UA where the destination user might be located, and therefore, the virtues of forking are largely lost.
プロキシサーバーが要求に応答してチャレンジを発行する場合、UACが有効な資格情報で要求を再試行するまで、要求はプロキシされません。フォーキングプロキシは、認証を必要とする複数のプロキシサーバーに同時に要求を転送できます。各プロキシサーバーは、元のUACがそれぞれのレルムで自分自身を認証するまで要求を転送しません。 UACがチャレンジごとに資格情報を提供しない場合、チャレンジを発行したプロキシサーバーは宛先ユーザーが配置されている可能性があるUAに要求を転送しないため、分岐のメリットはほとんど失われます。
When resubmitting its request in response to a 401 (Unauthorized) or 407 (Proxy Authentication Required) that contains multiple challenges, a UAC MAY include an Authorization value for each WWW-Authenticate value and a Proxy-Authorization value for each Proxy-Authenticate value for which the UAC wishes to supply a credential. As noted above, multiple credentials in a request SHOULD be differentiated by the "realm" parameter.
複数のチャレンジを含む401（無許可）または407（プロキシ認証が必要）への応答として要求を再送信する場合、UACは、各WWW-Authenticate値の承認値と、各Proxy-Authenticate値のProxy-Authorization値を含めることができます（MAY）。 UACは資格情報を提供したいと考えています。上記のように、リクエスト内の複数の認証情報は、「レルム」パラメーターによって区別されるべきです（SHOULD）。
It is possible for multiple challenges associated with the same realm to appear in the same 401 (Unauthorized) or 407 (Proxy Authentication Required). This can occur, for example, when multiple proxies within the same administrative domain, which use a common realm, are reached by a forking request. When it retries a request, a UAC MAY therefore supply multiple credentials in Authorization or Proxy-Authorization header fields with the same "realm" parameter value. The same credentials SHOULD be used for the same realm.
同じレルムに関連付けられた複数のチャレンジが、同じ401（無許可）または407（プロキシ認証が必要）に表示される可能性があります。これは、たとえば、共通のレルムを使用する同じ管理ドメイン内の複数のプロキシにforkリクエストが到達した場合に発生する可能性があります。したがって、UACは要求を再試行するときに、AuthorizationまたはProxy-Authorizationヘッダーフィールドに、同じ「レルム」パラメーター値を持つ複数の資格情報を提供できます（MAY）。同じレルムに同じ資格情報を使用する必要があります。
This section describes the modifications and clarifications required to apply the HTTP Digest authentication scheme to SIP. The SIP scheme usage is almost completely identical to that for HTTP [17].
このセクションでは、HTTPダイジェスト認証スキームをSIPに適用するために必要な変更と説明について説明します。 SIPスキームの使用法は、HTTPの使用法とほぼ完全に同じです[17]。
Since RFC 2543 is based on HTTP Digest as defined in RFC 2069 [39], SIP servers supporting RFC 2617 MUST ensure they are backwards compatible with RFC 2069. Procedures for this backwards compatibility are specified in RFC 2617. Note, however, that SIP servers MUST NOT accept or request Basic authentication.
RFC 2543はRFC 2069 [39]で定義されているHTTPダイジェストに基づいているため、RFC 2617をサポートするSIPサーバーは、RFC 2069との下位互換性を保証する必要があります。この下位互換性の手順はRFC 2617で指定されています。ただし、SIPサーバー基本認証を受け入れたり要求したりしてはなりません。
The rules for Digest authentication follow those defined in [17], with "HTTP/1.1" replaced by "SIP/2.0" in addition to the following differences:
ダイジェスト認証のルールは、[17]で定義されているルールに従い、以下の違いに加えて、「HTTP / 1.1」が「SIP / 2.0」に置き換えられています。
1. The URI included in the challenge has the following BNF:
1. チャレンジに含まれるURIには次のBNFがあります。
URI = SIP-URI / SIPS-URI
URI = SIP-URI / SIPS-URI
2. The BNF in RFC 2617 has an error in that the 'uri' parameter of the Authorization header field for HTTP Digest authentication is not enclosed in quotation marks. (The example in Section 3.5 of RFC 2617 is correct.) For SIP, the 'uri' MUST be enclosed in quotation marks.
2. RFC 2617のBNFには、HTTPダイジェスト認証のAuthorizationヘッダーフィールドの「uri」パラメーターが引用符で囲まれていないというエラーがあります。 （RFC 2617のセクション3.5の例は正しいです。）SIPの場合、「uri」は引用符で囲む必要があります。
3. The BNF for digest-uri-value is:
3. digest-uri-valueのBNFは次のとおりです。
digest-uri-value = Request-URI ; as defined in Section 25
digest-uri-value = Request-URI;セクション25で定義
4. The example procedure for choosing a nonce based on Etag does not work for SIP.
4. Etagに基づいてnonceを選択する手順の例は、SIPでは機能しません。
5. The text in RFC 2617 [17] regarding cache operation does not apply to SIP.
5. キャッシュ操作に関するRFC 2617 [17]のテキストはSIPには適用されません。
6. RFC 2617 [17] requires that a server check that the URI in the request line and the URI included in the Authorization header field point to the same resource. In a SIP context, these two URIs may refer to different users, due to forwarding at some proxy. Therefore, in SIP, a server MAY check that the Request-URI in the Authorization header field value corresponds to a user for whom the server is willing to accept forwarded or direct requests, but it is not necessarily a failure if the two fields are not equivalent.
6. RFC 2617 [17]では、サーバーがリクエスト行のURIとAuthorizationヘッダーフィールドに含まれるURIが同じリソースを指していることを確認する必要があります。 SIPコンテキストでは、これらの2つのURIは、いくつかのプロキシでの転送が原因で、異なるユーザーを参照する場合があります。したがって、SIPでは、サーバーはAuthorizationヘッダーフィールド値のRequest-URIが、サーバーが転送または直接の要求を受け入れる用意があるユーザーに対応していることを確認できますが、2つのフィールドがそうでない場合は必ずしも失敗ではありません同等。
7. As a clarification to the calculation of the A2 value for message integrity assurance in the Digest authentication scheme, implementers should assume, when the entity-body is empty (that is, when SIP messages have no body) that the hash of the entity-body resolves to the MD5 hash of an empty string, or:
7. ダイジェスト認証方式でのメッセージ整合性保証のA2値の計算の明確化として、実装者は、エンティティボディが空の場合（つまり、SIPメッセージにボディがない場合）、エンティティボディのハッシュが空の文字列のMD5ハッシュに解決する、または：
H(entity-body) = MD5("") =
"d41d8cd98f00b204e9800998ecf8427e"
8. RFC 2617 notes that a cnonce value MUST NOT be sent in an Authorization (and by extension Proxy-Authorization) header field if no qop directive has been sent. Therefore, any algorithms that have a dependency on the cnonce (including "MD5-Sess") require that the qop directive be sent. Use of the "qop" parameter is optional in RFC 2617 for the purposes of backwards compatibility with RFC 2069; since RFC 2543 was based on RFC 2069, the "qop" parameter must unfortunately remain optional for clients and servers to receive. However, servers MUST always send a "qop" parameter in WWW-Authenticate and Proxy-Authenticate header field values. If a client receives a "qop" parameter in a challenge header field, it MUST send the "qop" parameter in any resulting authorization header field.
8. RFC 2617は、qopディレクティブが送信されていない場合、許可値（および拡張Proxy-Authorizationによる）ヘッダーフィールドにcnonce値を送信してはならないことを記述しています。したがって、cnonce（「MD5-Sess」を含む）に依存するアルゴリズムでは、qopディレクティブを送信する必要があります。 「qop」パラメータの使用は、RFC 2069との下位互換性のために、RFC 2617ではオプションです。 RFC 2543はRFC 2069に基づいていたため、残念ながら、クライアントとサーバーが受信する「qop」パラメーターはオプションのままにする必要があります。ただし、サーバーは常にWQW-AuthenticateおよびProxy-Authenticateヘッダーフィールド値で「qop」パラメータを送信する必要があります。クライアントがチャレンジヘッダーフィールドで「qop」パラメーターを受信した場合、クライアントは、結果の承認ヘッダーフィールドで「qop」パラメーターを送信する必要があります。
RFC 2543 did not allow usage of the Authentication-Info header field (it effectively used RFC 2069). However, we now allow usage of this header field, since it provides integrity checks over the bodies and provides mutual authentication. RFC 2617 [17] defines mechanisms for backwards compatibility using the qop attribute in the request. These mechanisms MUST be used by a server to determine if the client supports the new mechanisms in RFC 2617 that were not specified in RFC 2069.
RFC 2543では、Authentication-Infoヘッダーフィールドを使用できませんでした（RFC 2069を効果的に使用していました）。ただし、本文の整合性チェックを提供し、相互認証を提供するため、このヘッダーフィールドの使用を許可します。 RFC 2617 [17]は、リクエストでqop属性を使用して下位互換性のメカニズムを定義しています。サーバーがこれらのメカニズムを使用して、クライアントがRFC 2069で指定されていなかったRFC 2617の新しいメカニズムをサポートしているかどうかを判断する必要があります。
23 S/MIME
23 S / MIME
SIP messages carry MIME bodies and the MIME standard includes mechanisms for securing MIME contents to ensure both integrity and confidentiality (including the 'multipart/signed' and 'application/pkcs7-mime' MIME types, see RFC 1847 [22], RFC 2630 [23] and RFC 2633 [24]). Implementers should note, however, that there may be rare network intermediaries (not typical proxy servers) that rely on viewing or modifying the bodies of SIP messages (especially SDP), and that secure MIME may prevent these sorts of intermediaries from functioning.
SIPメッセージはMIME本文を伝送し、MIME標準には、MIMEコンテンツを保護して整合性と機密性の両方を保証するメカニズムが含まれます（「multipart / signed」および「application / pkcs7-mime」MIMEタイプを含む。RFC1847 [22]、RFC 2630を参照） 23]およびRFC 2633 [24]）。ただし、実装者は、SIPメッセージ（特にSDP）の本文の表示または変更に依存するまれなネットワーク仲介者（通常のプロキシサーバーではない）があり、安全なMIMEがこれらの種類の仲介者の機能を妨げる可能性があることに注意する必要があります。
This applies particularly to certain types of firewalls.
これは特に、特定の種類のファイアウォールに適用されます。
The PGP mechanism for encrypting the header fields and bodies of SIP messages described in RFC 2543 has been deprecated.
RFC 2543で説明されているSIPメッセージのヘッダーフィールドと本文を暗号化するPGPメカニズムは廃止されました。
The certificates that are used to identify an end-user for the purposes of S/MIME differ from those used by servers in one important respect - rather than asserting that the identity of the holder corresponds to a particular hostname, these certificates assert that the holder is identified by an end-user address. This address is composed of the concatenation of the "userinfo" "@" and "domainname" portions of a SIP or SIPS URI (in other words, an email address of the form "bob@biloxi.com"), most commonly corresponding to a user's address-of-record.
S / MIMEの目的でエンドユーザーを識別するために使用される証明書は、サーバーが使用する証明書と1つの重要な点で異なります。これらの証明書は、所有者のIDが特定のホスト名に対応していることを主張するのではなく、ホルダーがエンドユーザーのアドレスで識別されます。このアドレスは、SIPまたはSIPS URIの「userinfo」「@」および「domainname」部分の連結（つまり、「bob@biloxi.com」の形式の電子メールアドレス）で構成され、最も一般的にはユーザーのレコードのアドレス。
These certificates are also associated with keys that are used to sign or encrypt bodies of SIP messages. Bodies are signed with the private key of the sender (who may include their public key with the message as appropriate), but bodies are encrypted with the public key of the intended recipient. Obviously, senders must have foreknowledge of the public key of recipients in order to encrypt message bodies. Public keys can be stored within a UA on a virtual keyring.
これらの証明書は、SIPメッセージの本文の署名または暗号化に使用される鍵にも関連付けられています。ボディは送信者の秘密キー（必要に応じてメッセージに公開キーを含めることができます）で署名されますが、ボディは目的の受信者の公開キーで暗号化されます。明らかに、送信者はメッセージ本文を暗号化するために受信者の公開鍵を事前に知っている必要があります。公開鍵は、仮想鍵リング上のUA内に保管できます。
Each user agent that supports S/MIME MUST contain a keyring specifically for end-users' certificates. This keyring should map between addresses of record and corresponding certificates. Over time, users SHOULD use the same certificate when they populate the originating URI of signaling (the From header field) with the same address-of-record.
S / MIMEをサポートする各ユーザーエージェントには、エンドユーザーの証明書専用のキーリングが含まれている必要があります。このキーリングは、レコードのアドレスと対応する証明書の間でマッピングする必要があります。時間の経過とともに、ユーザーは、シグナリングの元のURI（Fromヘッダーフィールド）に同じレコードのアドレスを入力するときに、同じ証明書を使用する必要があります（SHOULD）。
Any mechanisms depending on the existence of end-user certificates are seriously limited in that there is virtually no consolidated authority today that provides certificates for end-user applications. However, users SHOULD acquire certificates from known public certificate authorities. As an alternative, users MAY create self-signed certificates. The implications of self-signed certificates are explored further in Section 26.4.2. Implementations may also use pre-configured certificates in deployments in which a previous trust relationship exists between all SIP entities.
エンドユーザー証明書の存在に依存するメカニズムは、エンドユーザーアプリケーションに証明書を提供する統合された機関が事実上存在しないという点で、深刻に制限されています。ただし、ユーザーは、既知の公的な認証局から証明書を取得する必要があります（SHOULD）。別の方法として、ユーザーは自己署名証明書を作成してもよい（MAY）。自己署名証明書の意味については、セクション26.4.2で詳しく説明します。実装では、すべてのSIPエンティティ間に以前の信頼関係が存在する展開で、事前構成された証明書を使用することもできます。
Above and beyond the problem of acquiring an end-user certificate, there are few well-known centralized directories that distribute end-user certificates. However, the holder of a certificate SHOULD publish their certificate in any public directories as appropriate. Similarly, UACs SHOULD support a mechanism for importing (manually or automatically) certificates discovered in public directories corresponding to the target URIs of SIP requests.
エンドユーザー証明書を取得する問題以外にも、エンドユーザー証明書を配布するよく知られた一元化されたディレクトリはほとんどありません。ただし、証明書の所有者は、必要に応じて証明書を公開ディレクトリに公開する必要があります。同様に、UACは、SIPリクエストのターゲットURIに対応するパブリックディレクトリで発見された証明書を（手動または自動で）インポートするメカニズムをサポートする必要があります（SHOULD）。
SIP itself can also be used as a means to distribute public keys in the following manner.
SIP自体は、次の方法で公開鍵を配布する手段としても使用できます。
Whenever the CMS SignedData message is used in S/MIME for SIP, it MUST contain the certificate bearing the public key necessary to verify the signature.
CMS SignedDataメッセージがSIPのS / MIMEで使用される場合は常に、署名を検証するために必要な公開鍵を保持する証明書が含まれている必要があります。
When a UAC sends a request containing an S/MIME body that initiates a dialog, or sends a non-INVITE request outside the context of a dialog, the UAC SHOULD structure the body as an S/MIME 'multipart/signed' CMS SignedData body. If the desired CMS service is EnvelopedData (and the public key of the target user is known), the UAC SHOULD send the EnvelopedData message encapsulated within a SignedData message.
UACがダイアログを開始するS / MIMEボディを含むリクエストを送信するか、ダイアログのコンテキスト外で非INVITEリクエストを送信する場合、UACはボディをS / MIME 'multipart / signed' CMS SignedDataボディとして構造化する必要があります（SHOULD） 。目的のCMSサービスがEnvelopedDataである（かつターゲットユーザーの公開キーがわかっている）場合、UACは、SignedDataメッセージ内にカプセル化されたEnvelopedDataメッセージを送信する必要があります（SHOULD）。
When a UAS receives a request containing an S/MIME CMS body that includes a certificate, the UAS SHOULD first validate the certificate, if possible, with any available root certificates for certificate authorities. The UAS SHOULD also determine the subject of the certificate (for S/MIME, the SubjectAltName will contain the appropriate identity) and compare this value to the From header field of the request. If the certificate cannot be verified, because it is self-signed, or signed by no known authority, or if it is verifiable but its subject does not correspond to the From header field of request, the UAS MUST notify its user of the status of the certificate (including the subject of the certificate, its signer, and any key fingerprint information) and request explicit permission before proceeding. If the certificate was successfully verified and the subject of the certificate corresponds to the From header field of the SIP request, or if the user (after notification) explicitly authorizes the use of the certificate, the UAS SHOULD add this certificate to a local keyring, indexed by the address-of-record of the holder of the certificate.
UASが、証明書を含むS / MIME CMS本文を含む要求を受信すると、UASは、可能であれば、最初に、証明機関が利用できるルート証明書を使用して証明書を検証する必要があります（SHOULD）。 UASは、証明書のサブジェクト（S / MIMEの場合、SubjectAltNameに適切なIDが含まれる）も決定し、この値をリクエストのFromヘッダーフィールドと比較する必要があります（SHOULD）。証明書が自己署名されているか、既知の機関によって署名されていないために証明書を検証できない場合、または証明書は検証可能であるが、件名が要求のFromヘッダーフィールドに対応していない場合、UASはユーザーに次のステータスを通知する必要があります。証明書（証明書のサブジェクト、その署名者、およびキーフィンガープリント情報を含む）を使用して、続行する前に明示的な許可を要求します。証明書が正常に検証され、証明書のサブジェクトがSIP要求のFromヘッダーフィールドに対応する場合、またはユーザーが（通知後）証明書の使用を明示的に承認した場合、UASはこの証明書をローカルキーリングに追加する必要があります（SHOULD）。証明書の所有者のレコードのアドレスによって索引付けされます。
When a UAS sends a response containing an S/MIME body that answers the first request in a dialog, or a response to a non-INVITE request outside the context of a dialog, the UAS SHOULD structure the body as an S/MIME 'multipart/signed' CMS SignedData body. If the desired CMS service is EnvelopedData, the UAS SHOULD send the EnvelopedData message encapsulated within a SignedData message.
UASがダイアログの最初のリクエストに応答するS / MIMEボディを含む応答、またはダイアログのコンテキスト外の非INVITEリクエストへの応答を送信する場合、UASはボディをS / MIME 'multipartとして構造化する必要があります（SHOULD） / signed 'CMS SignedData本文。目的のCMSサービスがEnvelopedDataの場合、UASは、SignedDataメッセージ内にカプセル化されたEnvelopedDataメッセージを送信する必要があります（SHOULD）。
When a UAC receives a response containing an S/MIME CMS body that includes a certificate, the UAC SHOULD first validate the certificate, if possible, with any appropriate root certificate. The UAC SHOULD also determine the subject of the certificate and compare this value to the To field of the response; although the two may very well be different, and this is not necessarily indicative of a security breach. If the certificate cannot be verified because it is self-signed, or signed by no known authority, the UAC MUST notify its user of the status of the certificate (including the subject of the certificate, its signator, and any key fingerprint information) and request explicit permission before proceeding. If the certificate was successfully verified, and the subject of the certificate corresponds to the To header field in the response, or if the user (after notification) explicitly authorizes the use of the certificate, the UAC SHOULD add this certificate to a local keyring, indexed by the address-of-record of the holder of the certificate. If the UAC had not transmitted its own certificate to the UAS in any previous transaction, it SHOULD use a CMS SignedData body for its next request or response.
UACが、証明書を含むS / MIME CMS本文を含む応答を受信すると、UACは、可能であれば、適切なルート証明書を使用して、最初に証明書を検証する必要があります（SHOULD）。 UACは証明書のサブジェクトも決定し、この値を応答のToフィールドと比較する必要があります（SHOULD）。ただし、この2つは非常に異なる可能性があり、これは必ずしもセキュリティ違反を示すものではありません。証明書が自己署名されているか、既知の機関によって署名されていないために証明書を検証できない場合、UACはユーザーに証明書のステータス（証明書のサブジェクト、署名者、およびキーフィンガープリント情報を含む）を通知する必要があります。続行する前に、明示的な許可を要求してください。証明書が正常に検証され、証明書のサブジェクトが応答のToヘッダーフィールドに対応する場合、またはユーザー（通知後）が証明書の使用を明示的に承認した場合、UACはこの証明書をローカルキーリングに追加する必要があります（SHOULD）。証明書の所有者のレコードのアドレスによって索引付けされます。 UACが以前のトランザクションで独自の証明書をUASに送信していない場合は、次の要求または応答にCMS SignedDataボディを使用する必要があります（SHOULD）。
On future occasions, when the UA receives requests or responses that contain a From header field corresponding to a value in its keyring, the UA SHOULD compare the certificate offered in these messages with the existing certificate in its keyring. If there is a discrepancy, the UA MUST notify its user of a change of the certificate (preferably in terms that indicate that this is a potential security breach) and acquire the user's permission before continuing to process the signaling. If the user authorizes this certificate, it SHOULD be added to the keyring alongside any previous value(s) for this address-of-record.
将来、UAがキーリングの値に対応するFromヘッダーフィールドを含む要求または応答を受信した場合、UAはこれらのメッセージで提供される証明書をそのキーリングの既存の証明書と比較する必要があります（SHOULD）。不一致がある場合、UAはユーザーに証明書の変更を通知し（できれば、これが潜在的なセキュリティ違反であることを示す観点から）、シグナリングの処理を続行する前にユーザーの許可を取得する必要があります。ユーザーがこの証明書を承認する場合は、このレコードのこのアドレスの以前の値と一緒にキーリングに追加する必要があります。
Note well however, that this key exchange mechanism does not guarantee the secure exchange of keys when self-signed certificates, or certificates signed by an obscure authority, are used - it is vulnerable to well-known attacks. In the opinion of the authors, however, the security it provides is proverbially better than nothing; it is in fact comparable to the widely used SSH application. These limitations are explored in greater detail in Section 26.4.2.
ただし、この鍵交換メカニズムは、自己署名証明書または不明瞭な機関によって署名された証明書が使用された場合の鍵の安全な交換を保証しないことに注意してください。これは、既知の攻撃に対して脆弱です。しかし、著者の意見では、それによって提供されるセキュリティは、何もないよりも明らかに優れています。実際、広く使用されているSSHアプリケーションに匹敵します。これらの制限については、セクション26.4.2で詳しく説明します。
If a UA receives an S/MIME body that has been encrypted with a public key unknown to the recipient, it MUST reject the request with a 493 (Undecipherable) response. This response SHOULD contain a valid certificate for the respondent (corresponding, if possible, to any address of record given in the To header field of the rejected request) within a MIME body with a 'certs-only' "smime-type" parameter.
UAが受信者にとって不明な公開鍵で暗号化されたS / MIME本体を受信した場合、UAは493（Undecipherable）応答で要求を拒否する必要があります。この応答には、「certs-only」「smime-type」パラメータを使用して、MIME本体内の応答者（可能な場合は、拒否された要求のToヘッダーフィールドで指定されたレコードのアドレスに対応）の有効な証明書を含める必要があります（SHOULD）。
A 493 (Undecipherable) sent without any certificate indicates that the respondent cannot or will not utilize S/MIME encrypted messages, though they may still support S/MIME signatures.
証明書なしで送信された493（解読不可）は、回答者がS / MIME署名を引き続きサポートしている場合でも、S / MIME暗号化メッセージを利用できない、または利用しないことを示します。
Note that a user agent that receives a request containing an S/MIME body that is not optional (with a Content-Disposition header "handling" parameter of "required") MUST reject the request with a 415 Unsupported Media Type response if the MIME type is not understood. A user agent that receives such a response when S/MIME is sent SHOULD notify its user that the remote device does not support S/MIME, and it MAY subsequently resend the request without S/MIME, if appropriate; however, this 415 response may constitute a downgrade attack.
オプションではないS / MIMEボディを含むリクエストを受信するユーザーエージェントは、（Content-Dispositionヘッダーの「処理」パラメーターが「必須」である）MIMEタイプの場合、415 Unsupported Media Typeレスポンスでリクエストを拒否する必要があることに注意してください。理解されていません。 S / MIMEが送信されたときにそのような応答を受信するユーザーエージェントは、リモートデバイスがS / MIMEをサポートしていないことをユーザーに通知する必要があり（SHOULD）、その後、適切であれば、S / MIMEなしで要求を再送信してもよい（MAY）。ただし、この415応答はダウングレード攻撃を構成する場合があります。
If a user agent sends an S/MIME body in a request, but receives a response that contains a MIME body that is not secured, the UAC SHOULD notify its user that the session could not be secured. However, if a user agent that supports S/MIME receives a request with an unsecured body, it SHOULD NOT respond with a secured body, but if it expects S/MIME from the sender (for example, because the sender's From header field value corresponds to an identity on its keychain), the UAS SHOULD notify its user that the session could not be secured.
ユーザーエージェントがリクエストでS / MIME本文を送信したが、保護されていないMIME本文を含む応答を受信した場合、UACはユーザーにセッションを保護できなかったことを通知する必要があります（SHOULD）。ただし、S / MIMEをサポートするユーザーエージェントがセキュリティで保護されていない本文を含むリクエストを受信した場合、セキュリティで保護された本文で応答するべきではありませんが、送信者からのS / MIMEを期待している場合（たとえば、送信者のFromヘッダーフィールド値が対応しているため）キーチェーン上のIDに対して）、UASはセッションを保護できなかったことをユーザーに通知する必要があります。
A number of conditions that arise in the previous text call for the notification of the user when an anomalous certificate-management event occurs. Users might well ask what they should do under these circumstances. First and foremost, an unexpected change in a certificate, or an absence of security when security is expected, are causes for caution but not necessarily indications that an attack is in progress. Users might abort any connection attempt or refuse a connection request they have received; in telephony parlance, they could hang up and call back. Users may wish to find an alternate means to contact the other party and confirm that their key has legitimately changed. Note that users are sometimes compelled to change their certificates, for example when they suspect that the secrecy of their private key has been compromised. When their private key is no longer private, users must legitimately generate a new key and re-establish trust with any users that held their old key.
前のテキストで発生したいくつかの条件は、異常な証明書管理イベントが発生したときにユーザーに通知することを求めています。ユーザーは、これらの状況下で何をすべきかを尋ねるかもしれません。何よりもまず、証明書が予期せず変更されたり、セキュリティが期待されているときにセキュリティが失われたりすることは、注意が必要ですが、必ずしも攻撃が進行中であることを示すものではありません。ユーザーは、接続の試行を中止するか、受け取った接続要求を拒否する場合があります。電話用語では、電話を切って電話をかけることができます。ユーザーは、相手に連絡して自分のキーが合法的に変更されたことを確認する別の手段を見つけたいと思うかもしれません。たとえば、秘密鍵の機密性が侵害された疑いがある場合など、ユーザーは証明書を変更せざるを得ない場合があります。プライベートキーがプライベートでなくなった場合、ユーザーは新しいキーを合法的に生成し、古いキーを保持していたユーザーとの信頼を再確立する必要があります。
Finally, if during the course of a dialog a UA receives a certificate in a CMS SignedData message that does not correspond with the certificates previously exchanged during a dialog, the UA MUST notify its user of the change, preferably in terms that indicate that this is a potential security breach.
最後に、ダイアログの過程でUAがCMS SignedDataメッセージで以前にダイアログ中に交換された証明書に対応しない証明書を受信した場合、UAはユーザーに変更を通知する必要があります。潜在的なセキュリティ違反。
There are two types of secure MIME bodies that are of interest to SIP: use of these bodies should follow the S/MIME specification [24] with a few variations.
SIPにとって重要な2種類の安全なMIME本文があります。これらの本文の使用は、いくつかのバリエーションを含めてS / MIME仕様[24]に従う必要があります。
o "multipart/signed" MUST be used only with CMS detached signatures.
o 「multipart / signed」は、CMSデタッチ署名でのみ使用する必要があります。
This allows backwards compatibility with non-S/MIME-compliant recipients.
これにより、S / MIMEに準拠していない受信者との下位互換性が可能になります。
o S/MIME bodies SHOULD have a Content-Disposition header field, and the value of the "handling" parameter SHOULD be "required."
o S / MIME本文にはContent-Dispositionヘッダーフィールドがあり、「処理」パラメーターの値は「必須」である必要があります（SHOULD）。
o If a UAC has no certificate on its keyring associated with the address-of-record to which it wants to send a request, it cannot send an encrypted "application/pkcs7-mime" MIME message. UACs MAY send an initial request such as an OPTIONS message with a CMS detached signature in order to solicit the certificate of the remote side (the signature SHOULD be over a "message/sip" body of the type described in Section 23.4).
o UACが、リクエストを送信するレコードのアドレスに関連付けられたキーリングに証明書を持たない場合、暗号化された「application / pkcs7-mime」MIMEメッセージを送信できません。 UACは、リモート側の証明書を要求するために、CMS分離署名付きのOPTIONSメッセージなどの初期リクエストを送信できます（署名は、セクション23.4で説明されているタイプの「メッセージ/ SIP」本文上にある必要があります）。
Note that future standardization work on S/MIME may define non-certificate based keys.
S / MIMEに関する将来の標準化作業では、非証明書ベースのキーが定義される可能性があることに注意してください。
o Senders of S/MIME bodies SHOULD use the "SMIMECapabilities" (see Section 2.5.2 of [24]) attribute to express their capabilities and preferences for further communications. Note especially that senders MAY use the "preferSignedData" capability to encourage receivers to respond with CMS SignedData messages (for example, when sending an OPTIONS request as described above).
o S / MIMEボディの送信者は、「SMIMECapabilities」（[24]のセクション2.5.2を参照）属性を使用して、今後のコミュニケーションのための機能と設定を表現する必要があります（SHOULD）。特に、送信者は "preferSignedData"機能を使用して、受信者がCMS SignedDataメッセージで応答するようにすることができます（たとえば、上記のOPTIONSリクエストを送信する場合）。
o S/MIME implementations MUST at a minimum support SHA1 as a digital signature algorithm, and 3DES as an encryption algorithm. All other signature and encryption algorithms MAY be supported. Implementations can negotiate support for these algorithms with the "SMIMECapabilities" attribute.
o S / MIME実装は、少なくともデジタル署名アルゴリズムとしてSHA1をサポートし、暗号化アルゴリズムとして3DESをサポートする必要があります。他のすべての署名および暗号化アルゴリズムがサポートされる場合があります。実装は、「SMIMECapabilities」属性を使用してこれらのアルゴリズムのサポートをネゴシエートできます。
o Each S/MIME body in a SIP message SHOULD be signed with only one certificate. If a UA receives a message with multiple signatures, the outermost signature should be treated as the single certificate for this body. Parallel signatures SHOULD NOT be used.
o SIPメッセージの各S / MIMEボディは、1つの証明書のみで署名する必要があります（SHOULD）。 UAが複数の署名を持つメッセージを受信する場合、最も外側の署名は、この本文の単一の証明書として扱われる必要があります。並列署名は使用すべきではありません（SHOULD NOT）。
The following is an example of an encrypted S/MIME SDP body within a SIP message:
次に、SIPメッセージ内の暗号化されたS / MIME SDP本体の例を示します。
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Max-Forwards: 70
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name=smime.p7m
Content-Disposition: attachment; filename=smime.p7m
handling=required
*******************************************************
* Content-Type: application/sdp *
* *
* v=0 *
* o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com *
* s=- *
* t=0 0 *
* c=IN IP4 pc33.atlanta.com *
* m=audio 3456 RTP/AVP 0 1 3 99 *
* a=rtpmap:0 PCMU/8000 *
*******************************************************
As a means of providing some degree of end-to-end authentication, integrity or confidentiality for SIP header fields, S/MIME can encapsulate entire SIP messages within MIME bodies of type "message/sip" and then apply MIME security to these bodies in the same manner as typical SIP bodies. These encapsulated SIP requests and responses do not constitute a separate dialog or transaction, they are a copy of the "outer" message that is used to verify integrity or to supply additional information.
SIPヘッダーフィールドにある程度のエンドツーエンドの認証、整合性、または機密性を提供する手段として、S / MIMEは、タイプ "message / sip"のMIME本文内にSIPメッセージ全体をカプセル化し、MIMEセキュリティをこれらの本文に適用できます。一般的なSIP本体と同じ方法。これらのカプセル化されたSIP要求と応答は、個別のダイアログまたはトランザクションを構成するのではなく、整合性の検証または追加情報の提供に使用される「外部」メッセージのコピーです。
If a UAS receives a request that contains a tunneled "message/sip" S/MIME body, it SHOULD include a tunneled "message/sip" body in the response with the same smime-type.
UASがトンネル化された「メッセージ/ sip」S / MIME本文を含む要求を受信した場合、同じスミームタイプの応答にトンネル化された「メッセージ/ sip」本文を含める必要があります（SHOULD）。
Any traditional MIME bodies (such as SDP) SHOULD be attached to the "inner" message so that they can also benefit from S/MIME security. Note that "message/sip" bodies can be sent as a part of a MIME "multipart/mixed" body if any unsecured MIME types should also be transmitted in a request.
従来のMIME本体（SDPなど）は、「内部」メッセージに添付する必要があります（SHOULD）。これにより、S / MIMEセキュリティからもメリットを得られます。保護されていないMIMEタイプもリクエストで送信する必要がある場合は、「メッセージ/ SIP」ボディをMIME「マルチパート/混合」ボディの一部として送信できることに注意してください。
When the S/MIME integrity or confidentiality mechanisms are used, there may be discrepancies between the values in the "inner" message and values in the "outer" message. The rules for handling any such differences for all of the header fields described in this document are given in this section.
S / MIMEの整合性または機密性のメカニズムが使用されている場合、「内部」メッセージの値と「外部」メッセージの値の間に不一致がある場合があります。このセクションでは、このドキュメントで説明されているすべてのヘッダーフィールドでこのような違いを処理するためのルールを示します。
Note that for the purposes of loose timestamping, all SIP messages that tunnel "message/sip" SHOULD contain a Date header in both the "inner" and "outer" headers.
緩やかなタイムスタンプのために、「message / sip」をトンネリングするすべてのSIPメッセージには、「inner」ヘッダーと「outer」ヘッダーの両方にDateヘッダーを含める必要があります。
Whenever integrity checks are performed, the integrity of a header field should be determined by matching the value of the header field in the signed body with that in the "outer" messages using the comparison rules of SIP as described in 20.
整合性チェックが実行されるときは常に、20で説明されているように、SIPの比較ルールを使用して、署名済みボディのヘッダーフィールドの値を「外部」メッセージのヘッダーフィールドの値と照合することにより、ヘッダーフィールドの整合性を判断する必要があります。
Header fields that can be legitimately modified by proxy servers are: Request-URI, Via, Record-Route, Route, Max-Forwards, and Proxy-Authorization. If these header fields are not intact end-to-end, implementations SHOULD NOT consider this a breach of security. Changes to any other header fields defined in this document constitute an integrity violation; users MUST be notified of a discrepancy.
プロキシサーバーによって正当に変更できるヘッダーフィールドは、Request-URI、Via、Record-Route、Route、Max-Forwards、およびProxy-Authorizationです。これらのヘッダーフィールドが完全なエンドツーエンドでない場合、実装はこれをセキュリティ違反と見なしてはなりません。このドキュメントで定義されている他のヘッダーフィールドを変更すると、整合性違反になります。ユーザーは矛盾を通知する必要があります。
When messages are encrypted, header fields may be included in the encrypted body that are not present in the "outer" message.
メッセージが暗号化されている場合、「外部」メッセージには存在しないヘッダーフィールドが暗号化された本文に含まれることがあります。
Some header fields must always have a plaintext version because they are required header fields in requests and responses - these include:
一部のヘッダーフィールドはリクエストとレスポンスで必須のヘッダーフィールドであるため、常にプレーンテキストバージョンである必要があります。
To, From, Call-ID, CSeq, Contact. While it is probably not useful to provide an encrypted alternative for the Call-ID, CSeq, or Contact, providing an alternative to the information in the "outer" To or From is permitted. Note that the values in an encrypted body are not used for the purposes of identifying transactions or dialogs - they are merely informational. If the From header field in an encrypted body differs from the value in the "outer" message, the value within the encrypted body SHOULD be displayed to the user, but MUST NOT be used in the "outer" header fields of any future messages.
To、From、Call-ID、CSeq、Contact。 Call-ID、CSeq、またはContactの暗号化された代替を提供することはおそらく役に立ちませんが、「外部」のToまたはFromの情報の代替を提供することは許可されます。暗号化された本文の値は、トランザクションまたはダイアログを識別する目的で使用されないことに注意してください。これらは単なる情報です。暗号化された本文のFromヘッダーフィールドが「outer」メッセージの値と異なる場合、暗号化された本文内の値をユーザーに表示する必要がありますが、今後のメッセージの「outer」ヘッダーフィールドでは使用しないでください。
Primarily, a user agent will want to encrypt header fields that have an end-to-end semantic, including: Subject, Reply-To, Organization, Accept, Accept-Encoding, Accept-Language, Alert-Info, Error-Info, Authentication-Info, Expires, In-Reply-To, Require, Supported, Unsupported, Retry-After, User-Agent, Server, and Warning. If any of these header fields are present in an encrypted body, they should be used instead of any "outer" header fields, whether this entails displaying the header field values to users or setting internal states in the UA. They SHOULD NOT however be used in the "outer" headers of any future messages.
主に、ユーザーエージェントは、サブジェクト、返信先、組織、承諾、承諾、エンコード、承諾言語、警告情報、エラー情報、認証など、エンドツーエンドのセマンティックを持つヘッダーフィールドを暗号化する必要があります。 -Info、Expires、In-Reply-To、Require、Supported、Unsupported、Retry-After、User-Agent、Server、およびWarning。これらのヘッダーフィールドのいずれかが暗号化された本文に存在する場合、ユーザーへのヘッダーフィールド値の表示またはUAの内部状態の設定に関係なく、「外部」ヘッダーフィールドの代わりにそれらを使用する必要があります。ただし、今後のメッセージの「外部」ヘッダーでは使用しないでください。
If present, the Date header field MUST always be the same in the "inner" and "outer" headers.
存在する場合、Dateヘッダーフィールドは常に「inner」ヘッダーと「outer」ヘッダーで同じでなければなりません。
Since MIME bodies are attached to the "inner" message, implementations will usually encrypt MIME-specific header fields, including: MIME-Version, Content-Type, Content-Length, Content-Language, Content-Encoding and Content-Disposition. The "outer" message will have the proper MIME header fields for S/MIME bodies. These header fields (and any MIME bodies they preface) should be treated as normal MIME header fields and bodies received in a SIP message.
MIMEボディは「内部」メッセージに添付されるため、実装は通常、MIME-Version、Content-Type、Content-Length、Content-Language、Content-Encoding、およびContent-DispositionなどのMIME固有のヘッダーフィールドを暗号化します。 「外部」メッセージには、S / MIME本文の適切なMIMEヘッダーフィールドがあります。これらのヘッダーフィールド（および冒頭にあるMIME本文）は、SIPメッセージで受信される通常のMIMEヘッダーフィールドおよび本文として扱われる必要があります。
It is not particularly useful to encrypt the following header fields: Min-Expires, Timestamp, Authorization, Priority, and WWW-Authenticate. This category also includes those header fields that can be changed by proxy servers (described in the preceding section). UAs SHOULD never include these in an "inner" message if they are not included in the "outer" message. UAs that receive any of these header fields in an encrypted body SHOULD ignore the encrypted values.
次のヘッダーフィールドを暗号化することは特に有用ではありません：Min-Expires、Timestamp、Authorization、Priority、およびWWW-Authenticate。このカテゴリには、プロキシサーバー（前のセクションで説明）によって変更できるヘッダーフィールドも含まれます。 UAは、「外部」メッセージに含まれていない場合、これらを「内部」メッセージに含めないでください。暗号化された本文でこれらのヘッダーフィールドのいずれかを受け取るUAは、暗号化された値を無視する必要があります（SHOULD）。
Note that extensions to SIP may define additional header fields; the authors of these extensions should describe the integrity and confidentiality properties of such header fields. If a SIP UA encounters an unknown header field with an integrity violation, it MUST ignore the header field.
SIPの拡張により、追加のヘッダーフィールドが定義される場合があることに注意してください。これらの拡張機能の作成者は、そのようなヘッダーフィールドの整合性と機密性のプロパティについて説明する必要があります。 SIP UAが整合性違反のある不明なヘッダーフィールドを検出した場合、SIP UAはヘッダーフィールドを無視する必要があります。
Tunneling SIP messages within S/MIME bodies can provide integrity for SIP header fields if the header fields that the sender wishes to secure are replicated in a "message/sip" MIME body signed with a CMS detached signature.
S / MIME本体内のSIPメッセージのトンネリングは、送信者が保護したいヘッダーフィールドがCMS分離署名で署名された「メッセージ/ SIP」MIME本体に複製されている場合、SIPヘッダーフィールドの整合性を提供できます。
Provided that the "message/sip" body contains at least the fundamental dialog identifiers (To, From, Call-ID, CSeq), then a signed MIME body can provide limited authentication. At the very least, if the certificate used to sign the body is unknown to the recipient and cannot be verified, the signature can be used to ascertain that a later request in a dialog was transmitted by the same certificate-holder that initiated the dialog. If the recipient of the signed MIME body has some stronger incentive to trust the certificate (they were able to validate it, they acquired it from a trusted repository, or they have used it frequently) then the signature can be taken as a stronger assertion of the identity of the subject of the certificate.
「メッセージ/ SIP」ボディに少なくとも基本的なダイアログ識別子（To、From、Call-ID、CSeq）が含まれている場合、署名付きMIMEボディは限定された認証を提供できます。少なくとも、本文の署名に使用された証明書が受信者にとって不明であり、検証できない場合、署名を使用して、ダイアログ内の後続の要求が、ダイアログを開始した同じ証明書所有者によって送信されたことを確認できます。署名されたMIME本文の受信者が証明書を信頼する強いインセンティブを持っている場合（証明書を検証できた、信頼できるリポジトリから取得した、または頻繁に使用した）場合、署名はより強力なアサーションと見なすことができます。証明書のサブジェクトのID。
In order to eliminate possible confusions about the addition or subtraction of entire header fields, senders SHOULD replicate all header fields from the request within the signed body. Any message bodies that require integrity protection MUST be attached to the "inner" message.
ヘッダーフィールド全体の追加または削除に関する混乱の可能性を排除するために、送信者は、署名された本文内のリクエストからすべてのヘッダーフィールドを複製する必要があります。整合性保護を必要とするメッセージ本文は、「内部」メッセージに添付する必要があります。
If a Date header is present in a message with a signed body, the recipient SHOULD compare the header field value with its own internal clock, if applicable. If a significant time discrepancy is detected (on the order of an hour or more), the user agent SHOULD alert the user to the anomaly, and note that it is a potential security breach.
署名された本文を含むメッセージにDateヘッダーが存在する場合、受信者はヘッダーフィールドの値を該当する場合は独自の内部クロックと比較する必要があります（SHOULD）。かなりの時間の不一致が検出された場合（1時間以上のオーダー）、ユーザーエージェントはユーザーに異常を警告し、それが潜在的なセキュリティ違反であることを注意する必要があります。
If an integrity violation in a message is detected by its recipient, the message MAY be rejected with a 403 (Forbidden) response if it is a request, or any existing dialog MAY be terminated. UAs SHOULD notify users of this circumstance and request explicit guidance on how to proceed.
メッセージの整合性違反が受信者によって検出された場合、メッセージがリクエストの場合、メッセージは403（Forbidden）応答で拒否されるか、既存のダイアログが終了する場合があります。 UAは、この状況をユーザーに通知し、続行方法に関する明確なガイダンスを要求する必要があります（SHOULD）。
The following is an example of the use of a tunneled "message/sip" body:
次に、トンネル化された「メッセージ/ SIP」本文の使用例を示します。
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
Content-Length: 568
--boundary42 Content-Type: message/sip
--boundary42 Content-Type：message / sip
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
To: Bob <bob@biloxi.com>
From: Alice <alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 147
v=0
o=UserA 2890844526 2890844526 IN IP4 here.com
s=Session SDP
c=IN IP4 pc33.atlanta.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
--boundary42
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s;
handling=required
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756
--boundary42-
--boundary42-
It may also be desirable to use this mechanism to encrypt a "message/sip" MIME body within a CMS EnvelopedData message S/MIME body, but in practice, most header fields are of at least some use to the network; the general use of encryption with S/MIME is to secure message bodies like SDP rather than message headers. Some informational header fields, such as the Subject or Organization could perhaps warrant end-to-end security. Headers defined by future SIP applications might also require obfuscation.
このメカニズムを使用して、CMS EnvelopedDataメッセージのS / MIME本体内の「メッセージ/ sip」MIME本体を暗号化することも望ましいかもしれませんが、実際には、ほとんどのヘッダーフィールドは少なくともネットワークである程度使用されます。 S / MIMEでの暗号化の一般的な用途は、メッセージヘッダーではなくSDPなどのメッセージ本文を保護することです。件名や組織などの一部の情報ヘッダーフィールドは、エンドツーエンドのセキュリティを保証する可能性があります。将来のSIPアプリケーションで定義されるヘッダーも難読化が必要になる可能性があります。
Another possible application of encrypting header fields is selective anonymity. A request could be constructed with a From header field that contains no personal information (for example, sip:anonymous@anonymizer.invalid). However, a second From header field containing the genuine address-of-record of the originator could be encrypted within a "message/sip" MIME body where it will only be visible to the endpoints of a dialog.
ヘッダーフィールドを暗号化する別の可能なアプリケーションは、選択的な匿名性です。個人情報を含まないFromヘッダーフィールドを使用してリクエストを作成できます（たとえば、sip：anonymous@anonymizer.invalid）。ただし、発信者の本物のレコードのアドレスを含む2番目のFromヘッダーフィールドは、「メッセージ/ SIP」MIME本体内で暗号化され、ダイアログのエンドポイントにのみ表示されます。
Note that if this mechanism is used for anonymity, the From header field will no longer be usable by the recipient of a message as an index to their certificate keychain for retrieving the proper S/MIME key to associated with the sender. The message must first be decrypted, and the "inner" From header field MUST be used as an index.
このメカニズムが匿名性に使用される場合、送信者に関連付けられる適切なS / MIMEキーを取得するための証明書キーチェーンへのインデックスとして、メッセージの受信者はFromヘッダーフィールドを使用できなくなります。最初にメッセージを復号化する必要があり、「内部」のFromヘッダーフィールドをインデックスとして使用する必要があります。
In order to provide end-to-end integrity, encrypted "message/sip" MIME bodies SHOULD be signed by the sender. This creates a "multipart/signed" MIME body that contains an encrypted body and a signature, both of type "application/pkcs7-mime".
エンドツーエンドの整合性を提供するために、暗号化された「メッセージ/ SIP」MIME本体に送信者が署名する必要があります。これにより、「application / pkcs7-mime」タイプの暗号化された本文と署名を含む「multipart / signed」MIME本文が作成されます。
In the following example, of an encrypted and signed message, the text boxed in asterisks ("*") is encrypted:
次の例では、暗号化および署名されたメッセージのうち、アスタリスク（ "*"）で囲まれたテキストが暗号化されています。
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@biloxi.com>
From: Anonymous <sip:anonymous@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Contact: <sip:pc33.atlanta.com>
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
Content-Length: 568
--boundary42
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
handling=required
Content-Length: 231
***********************************************************
* Content-Type: message/sip *
* *
* INVITE sip:bob@biloxi.com SIP/2.0 *
* Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 *
* To: Bob <bob@biloxi.com> *
* From: Alice <alice@atlanta.com>;tag=1928301774 *
* Call-ID: a84b4c76e66710 *
* CSeq: 314159 INVITE *
* Max-Forwards: 70 *
* Date: Thu, 21 Feb 2002 13:02:03 GMT *
* Contact: <sip:alice@pc33.atlanta.com> *
* *
* Content-Type: application/sdp *
* *
* v=0 *
* o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com *
* s=Session SDP *
* t=0 0 *
* c=IN IP4 pc33.atlanta.com *
* m=audio 3456 RTP/AVP 0 1 3 99 *
* a=rtpmap:0 PCMU/8000 *
***********************************************************
--boundary42
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s;
handling=required
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756
--boundary42-
--boundary42-
24 Examples
24例
In the following examples, we often omit the message body and the corresponding Content-Length and Content-Type header fields for brevity.
次の例では、簡潔にするために、メッセージ本文と対応するContent-LengthおよびContent-Typeヘッダーフィールドを省略していることがよくあります。
Bob registers on start-up. The message flow is shown in Figure 9. Note that the authentication usually required for registration is not shown for simplicity.
Bobは起動時に登録します。メッセージフローを図9に示します。簡単にするために、通常は登録に必要な認証は示していません。
biloxi.com Bob's
registrar softphone
| |
| REGISTER F1 |
|<---------------|
| 200 OK F2 |
|--------------->|
Figure 9: SIP Registration Example
図9：SIP登録の例
F1 REGISTER Bob -> Registrar
F1レジスターボブ->レジストラ
REGISTER sip:registrar.biloxi.com SIP/2.0
Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Bob <sip:bob@biloxi.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:bob@192.0.2.4>
Expires: 7200
Content-Length: 0
The registration expires after two hours. The registrar responds with a 200 OK:
登録は2時間後に期限切れになります。レジストラは200 OKで応答します。
F2 200 OK Registrar -> Bob
F2 200 OKレジストラ->ボブ
SIP/2.0 200 OK
Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
;received=192.0.2.4
To: Bob <sip:bob@biloxi.com>;tag=2493k59kd
From: Bob <sip:bob@biloxi.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:bob@192.0.2.4>
Expires: 7200
Content-Length: 0
This example contains the full details of the example session setup in Section 4. The message flow is shown in Figure 1. Note that these flows show the minimum required set of header fields - some other header fields such as Allow and Supported would normally be present.
この例には、セクション4のセッション設定例の詳細が含まれています。メッセージフローを図1に示します。これらのフローは、ヘッダーフィールドの最低限必要なセットを示しています。通常、AllowやSupportedなどの他のヘッダーフィールドが存在します。 。
F1 INVITE Alice -> atlanta.com proxy
F1 INVITE Alice-> atlanta.comプロキシ
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown) F2 100 Trying atlanta.com proxy -> Alice
（アリスのSDPは表示されていません）F2 100トライアルatlanta.comプロキシ->アリス
SIP/2.0 100 Trying
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Content-Length: 0
F3 INVITE atlanta.com proxy -> biloxi.com proxy
F3 INVITE atlanta.comプロキシ-> biloxi.comプロキシ
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
Max-Forwards: 69
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)
（アリスのSDPは表示されていません）
F4 100 Trying biloxi.com proxy -> atlanta.com proxy
F4 100 biloxi.comプロキシを試す-> atlanta.comプロキシ
SIP/2.0 100 Trying
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Content-Length: 0 F5 INVITE biloxi.com proxy -> Bob
INVITE sip:bob@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
Max-Forwards: 68
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)
（アリスのSDPは表示されていません）
F6 180 Ringing Bob -> biloxi.com proxy
F6 180 Ringing Bob-> biloxi.comプロキシ
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
;received=192.0.2.3
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
Contact: <sip:bob@192.0.2.4>
CSeq: 314159 INVITE
Content-Length: 0
F7 180 Ringing biloxi.com proxy -> atlanta.com proxy
F7 180リンギングbiloxi.comプロキシ-> atlanta.comプロキシ
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
Contact: <sip:bob@192.0.2.4>
CSeq: 314159 INVITE
Content-Length: 0 F8 180 Ringing atlanta.com proxy -> Alice
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
Contact: <sip:bob@192.0.2.4>
CSeq: 314159 INVITE
Content-Length: 0
F9 200 OK Bob -> biloxi.com proxy
F9 200 OKボブ-> biloxi.comプロキシ
SIP/2.0 200 OK
Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
;received=192.0.2.3
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:bob@192.0.2.4>
Content-Type: application/sdp
Content-Length: 131
(Bob's SDP not shown)
（ボブのSDPは表示されていません）
F10 200 OK biloxi.com proxy -> atlanta.com proxy
F10 200 OK biloxi.comプロキシ-> atlanta.comプロキシ
SIP/2.0 200 OK
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:bob@192.0.2.4>
Content-Type: application/sdp
Content-Length: 131
(Bob's SDP not shown) F11 200 OK atlanta.com proxy -> Alice
（ボブのSDPは表示されていません）F11 200 OK atlanta.comプロキシ->アリス
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:bob@192.0.2.4>
Content-Type: application/sdp
Content-Length: 131
(Bob's SDP not shown)
（ボブのSDPは表示されていません）
F12 ACK Alice -> Bob
F12 ACKアリス->ボブ
ACK sip:bob@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 ACK
Content-Length: 0
The media session between Alice and Bob is now established.
これで、アリスとボブの間のメディアセッションが確立されました。
Bob hangs up first. Note that Bob's SIP phone maintains its own CSeq numbering space, which, in this example, begins with 231. Since Bob is making the request, the To and From URIs and tags have been swapped.
ボブが最初に電話を切ります。ボブのSIP電話機は、独自のCSeqナンバリングスペースを維持していることに注意してください。この例では、231で始まります。ボブがリクエストを行っているため、To URIとFrom URIおよびタグが交換されています。
F13 BYE Bob -> Alice
F13 BYEボブ->アリス
BYE sip:alice@pc33.atlanta.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10
Max-Forwards: 70
From: Bob <sip:bob@biloxi.com>;tag=a6c85cf
To: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 231 BYE
Content-Length: 0 F14 200 OK Alice -> Bob
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10
From: Bob <sip:bob@biloxi.com>;tag=a6c85cf
To: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 231 BYE
Content-Length: 0
The SIP Call Flows document [40] contains further examples of SIP messages.
SIPコールフロードキュメント[40]には、SIPメッセージの例がさらに含まれています。
25 Augmented BNF for the SIP Protocol
25 SIPプロトコル用のBNFの拡張
All of the mechanisms specified in this document are described in both prose and an augmented Backus-Naur Form (BNF) defined in RFC 2234 [10]. Section 6.1 of RFC 2234 defines a set of core rules that are used by this specification, and not repeated here. Implementers need to be familiar with the notation and content of RFC 2234 in order to understand this specification. Certain basic rules are in uppercase, such as SP, LWS, HTAB, CRLF, DIGIT, ALPHA, etc. Angle brackets are used within definitions to clarify the use of rule names.
このドキュメントで指定されているすべてのメカニズムは、RFC 2234 [10]で定義されている散文と拡張バッカスナウアフォーム（BNF）の両方で説明されています。 RFC 2234のセクション6.1は、この仕様で使用される一連のコアルールを定義しており、ここでは繰り返されません。この仕様を理解するには、実装者はRFC 2234の表記法と内容に精通している必要があります。 SP、LWS、HTAB、CRLF、DIGIT、ALPHAなどの特定の基本ルールは大文字です。山括弧は、ルール名の使用を明確にするために定義内で使用されます。
The use of square brackets is redundant syntactically. It is used as a semantic hint that the specific parameter is optional to use.
角括弧の使用は構文的に冗長です。これは、特定のパラメーターの使用がオプションであることを意味的なヒントとして使用します。
The following rules are used throughout this specification to describe basic parsing constructs. The US-ASCII coded character set is defined by ANSI X3.4-1986.
この仕様全体で、次のルールを使用して、基本的な構文解析構文を説明しています。 US-ASCIIコード化文字セットは、ANSI X3.4-1986で定義されています。
alphanum = ALPHA / DIGIT
alphanum = ALPHA / DIGIT
Several rules are incorporated from RFC 2396 [5] but are updated to make them compliant with RFC 2234 [10]. These include:
RFC 2396 [5]からいくつかのルールが組み込まれていますが、RFC 2234 [10]に準拠するように更新されています。これらには以下が含まれます：
reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+"
/ "$" / ","
unreserved = alphanum / mark
mark = "-" / "_" / "." / "!" / "~" / "*" / "'"
/ "(" / ")"
escaped = "%" HEXDIG HEXDIG
SIP header field values can be folded onto multiple lines if the continuation line begins with a space or horizontal tab. All linear white space, including folding, has the same semantics as SP. A recipient MAY replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream. This is intended to behave exactly as HTTP/1.1 as described in RFC 2616 [8]. The SWS construct is used when linear white space is optional, generally between tokens and separators.
継続行がスペースまたは水平タブで始まる場合、SIPヘッダーフィールド値は複数行に折りたたむことができます。折りたたみを含むすべての線形空白は、SPと同じセマンティクスを持っています。受信者は、フィールド値を解釈したり、メッセージをダウンストリームに転送したりする前に、線形空白を単一のSPで置き換えてもよい（MAY）。これは、RFC 2616 [8]で説明されているように、HTTP / 1.1とまったく同じように動作することを目的としています。 SWSコンストラクトは、線形の空白がオプションの場合に使用されます。通常、トークンと区切り文字の間です。
LWS = [*WSP CRLF] 1*WSP ; linear whitespace
SWS = [LWS] ; sep whitespace
To separate the header name from the rest of value, a colon is used, which, by the above rule, allows whitespace before, but no line break, and whitespace after, including a linebreak. The HCOLON defines this construct.
ヘッダー名を残りの値から分離するために、コロンが使用されます。これは、上記のルールにより、前に空白を許可しますが、改行を含めて後の空白を許可します。 HCOLONはこの構成を定義します。
HCOLON = *( SP / HTAB ) ":" SWS
The TEXT-UTF8 rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. Words of *TEXT-UTF8 contain characters from the UTF-8 charset (RFC 2279 [7]). The TEXT-UTF8-TRIM rule is used for descriptive field contents that are n t quoted strings, where leading and trailing LWS is not meaningful. In this regard, SIP differs from HTTP, which uses the ISO 8859-1 character set.
TEXT-UTF8ルールは、メッセージパーサーによる解釈を目的としない説明的なフィールドの内容と値にのみ使用されます。 * TEXT-UTF8の単語には、UTF-8文字セット（RFC 2279 [7]）の文字が含まれています。 TEXT-UTF8-TRIMルールは、先頭と末尾のLWSが意味を持たない、引用符で囲まれていない文字列である説明フィールドの内容に使用されます。この点で、SIPは、ISO 8859-1文字セットを使用するHTTPとは異なります。
TEXT-UTF8-TRIM = 1*TEXT-UTF8char *(*LWS TEXT-UTF8char)
TEXT-UTF8char = %x21-7E / UTF8-NONASCII
UTF8-NONASCII = %xC0-DF 1UTF8-CONT
/ %xE0-EF 2UTF8-CONT
/ %xF0-F7 3UTF8-CONT
/ %xF8-Fb 4UTF8-CONT
/ %xFC-FD 5UTF8-CONT
UTF8-CONT = %x80-BF
A CRLF is allowed in the definition of TEXT-UTF8-TRIM only as part of a header field continuation. It is expected that the folding LWS will be replaced with a single SP before interpretation of the TEXT-UTF8-TRIM value.
CRLFは、ヘッダーフィールドの継続の一部としてのみ、TEXT-UTF8-TRIMの定義で許可されます。 TEXT-UTF8-TRIM値の解釈の前に、フォールディングLWSが単一のSPに置き換えられることが期待されています。
Hexadecimal numeric characters are used in several protocol elements. Some elements (authentication) force hex alphas to be lower case.
16進数の数字は、いくつかのプロトコル要素で使用されます。一部の要素（認証）では、16進数のアルファが小文字になります。
LHEX = DIGIT / %x61-66 ;lowercase a-f
Many SIP header field values consist of words separated by LWS or special characters. Unless otherwise stated, tokens are case-insensitive. These special characters MUST be in a quoted string to be used within a parameter value. The word construct is used in Call-ID to allow most separators to be used.
多くのSIPヘッダーフィールド値は、LWSまたは特殊文字で区切られた単語で構成されています。特に明記しない限り、トークンは大文字と小文字を区別しません。これらの特殊文字は、パラメータ値内で使用される引用符付きの文字列に含まれている必要があります。ワード構成はCall-IDで使用され、ほとんどのセパレーターを使用できるようにします。
token = 1*(alphanum / "-" / "." / "!" / "%" / "*"
/ "_" / "+" / "`" / "'" / "~" )
separators = "(" / ")" / "<" / ">" / "@" /
"," / ";" / ":" / "\" / DQUOTE /
"/" / "[" / "]" / "?" / "=" /
"{" / "}" / SP / HTAB
word = 1*(alphanum / "-" / "." / "!" / "%" / "*" /
"_" / "+" / "`" / "'" / "~" /
"(" / ")" / "<" / ">" /
":" / "\" / DQUOTE /
"/" / "[" / "]" / "?" /
"{" / "}" )
When tokens are used or separators are used between elements, whitespace is often allowed before or after these characters:
トークンが使用されている場合、または要素間でセパレータが使用されている場合、これらの文字の前後に空白が許可されることがよくあります。
STAR = SWS "*" SWS ; asterisk
SLASH = SWS "/" SWS ; slash
EQUAL = SWS "=" SWS ; equal
LPAREN = SWS "(" SWS ; left parenthesis
RPAREN = SWS ")" SWS ; right parenthesis
RAQUOT = ">" SWS ; right angle quote
LAQUOT = SWS "<"; left angle quote
COMMA = SWS "," SWS ; comma
SEMI = SWS ";" SWS ; semicolon
COLON = SWS ":" SWS ; colon
LDQUOT = SWS DQUOTE; open double quotation mark
RDQUOT = DQUOTE SWS ; close double quotation mark
Comments can be included in some SIP header fields by surrounding the comment text with parentheses. Comments are only allowed in fields containing "comment" as part of their field value definition. In all other fields, parentheses are considered part of the field value.
コメントは、コメントテキストを括弧で囲むことにより、一部のSIPヘッダーフィールドに含めることができます。コメントは、フィールド値の定義の一部として「コメント」を含むフィールドでのみ許可されます。他のすべてのフィールドでは、括弧はフィールド値の一部と見なされます。
comment = LPAREN *(ctext / quoted-pair / comment) RPAREN
ctext = %x21-27 / %x2A-5B / %x5D-7E / UTF8-NONASCII
/ LWS
ctext includes all chars except left and right parens and backslash. A string of text is parsed as a single word if it is quoted using double-quote marks. In quoted strings, quotation marks (") and backslashes (\) need to be escaped.
ctextには、左括弧、右括弧、およびバックスラッシュを除くすべての文字が含まれます。テキストの文字列は、二重引用符で囲まれている場合、1つの単語として解析されます。引用符付き文字列では、引用符（ "）とバックスラッシュ（\）をエスケープする必要があります。
quoted-string = SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE
qdtext = LWS / %x21 / %x23-5B / %x5D-7E
/ UTF8-NONASCII
The backslash character ("\") MAY be used as a single-character quoting mechanism only within quoted-string and comment constructs. Unlike HTTP/1.1, the characters CR and LF cannot be escaped by this mechanism to avoid conflict with line folding and header separation.
バックスラッシュ文字（ "\"）は、引用文字列およびコメント構造内でのみ、単一文字の引用メカニズムとして使用できます。 HTTP / 1.1とは異なり、CRとLFの文字は、行の折りたたみやヘッダーの分離との競合を回避するために、このメカニズムではエスケープできません。
quoted-pair = "\" (%x00-09 / %x0B-0C / %x0E-7F)
quoted-pair = "\"（％x00-09 /％x0B-0C /％x0E-7F）
SIP-URI = "sip:" [ userinfo ] hostport
uri-parameters [ headers ]
SIPS-URI = "sips:" [ userinfo ] hostport
uri-parameters [ headers ]
userinfo = ( user / telephone-subscriber ) [ ":" password ] "@"
user = 1*( unreserved / escaped / user-unreserved )
user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/"
password = *( unreserved / escaped /
"&" / "=" / "+" / "$" / "," )
hostport = host [ ":" port ]
host = hostname / IPv4address / IPv6reference
hostname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum
/ alphanum *( alphanum / "-" ) alphanum
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
IPv6reference = "[" IPv6address "]"
IPv6address = hexpart [ ":" IPv4address ]
hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ]
hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG
port = 1*DIGIT
The BNF for telephone-subscriber can be found in RFC 2806 [9]. Note, however, that any characters allowed there that are not allowed in the user part of the SIP URI MUST be escaped.
電話加入者のBNFはRFC 2806 [9]にあります。ただし、SIP URIのユーザー部分で許可されていない、許可されている文字はエスケープする必要があります。
uri-parameters = *( ";" uri-parameter)
uri-parameter = transport-param / user-param / method-param
/ ttl-param / maddr-param / lr-param / other-param
transport-param = "transport="
( "udp" / "tcp" / "sctp" / "tls"
/ other-transport)
other-transport = token
user-param = "user=" ( "phone" / "ip" / other-user)
other-user = token
method-param = "method=" Method
ttl-param = "ttl=" ttl
maddr-param = "maddr=" host
lr-param = "lr"
other-param = pname [ "=" pvalue ]
pname = 1*paramchar
pvalue = 1*paramchar
paramchar = param-unreserved / unreserved / escaped
param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$"
headers = "?" header *( "&" header )
header = hname "=" hvalue
hname = 1*( hnv-unreserved / unreserved / escaped )
hvalue = *( hnv-unreserved / unreserved / escaped )
hnv-unreserved = "[" / "]" / "/" / "?" / ":" / "+" / "$"
SIP-message = Request / Response
Request = Request-Line
*( message-header )
CRLF
[ message-body ]
Request-Line = Method SP Request-URI SP SIP-Version CRLF
Request-URI = SIP-URI / SIPS-URI / absoluteURI
absoluteURI = scheme ":" ( hier-part / opaque-part )
hier-part = ( net-path / abs-path ) [ "?" query ]
net-path = "//" authority [ abs-path ]
abs-path = "/" path-segments opaque-part = uric-no-slash *uric
uric = reserved / unreserved / escaped
uric-no-slash = unreserved / escaped / ";" / "?" / ":" / "@"
/ "&" / "=" / "+" / "$" / ","
path-segments = segment *( "/" segment )
segment = *pchar *( ";" param )
param = *pchar
pchar = unreserved / escaped /
":" / "@" / "&" / "=" / "+" / "$" / ","
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
authority = srvr / reg-name
srvr = [ [ userinfo "@" ] hostport ]
reg-name = 1*( unreserved / escaped / "$" / ","
/ ";" / ":" / "@" / "&" / "=" / "+" )
query = *uric
SIP-Version = "SIP" "/" 1*DIGIT "." 1*DIGIT
message-header = (Accept
/ Accept-Encoding
/ Accept-Language
/ Alert-Info
/ Allow
/ Authentication-Info
/ Authorization
/ Call-ID
/ Call-Info
/ Contact
/ Content-Disposition
/ Content-Encoding
/ Content-Language
/ Content-Length
/ Content-Type
/ CSeq
/ Date
/ Error-Info
/ Expires
/ From
/ In-Reply-To
/ Max-Forwards
/ MIME-Version
/ Min-Expires
/ Organization
/ Priority
/ Proxy-Authenticate
/ Proxy-Authorization
/ Proxy-Require
/ Record-Route
/ Reply-To
/ Require
/ Retry-After
/ Route
/ Server
/ Subject
/ Supported
/ Timestamp
/ To
/ Unsupported
/ User-Agent
/ Via
/ Warning
/ WWW-Authenticate
/ extension-header) CRLF
INVITEm = %x49.4E.56.49.54.45 ; INVITE in caps
ACKm = %x41.43.4B ; ACK in caps
OPTIONSm = %x4F.50.54.49.4F.4E.53 ; OPTIONS in caps
BYEm = %x42.59.45 ; BYE in caps
CANCELm = %x43.41.4E.43.45.4C ; CANCEL in caps
REGISTERm = %x52.45.47.49.53.54.45.52 ; REGISTER in caps
Method = INVITEm / ACKm / OPTIONSm / BYEm
/ CANCELm / REGISTERm
/ extension-method
extension-method = token
Response = Status-Line
*( message-header )
CRLF
[ message-body ]
Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF
Status-Code = Informational
/ Redirection
/ Success
/ Client-Error
/ Server-Error
/ Global-Failure
/ extension-code
extension-code = 3DIGIT
Reason-Phrase = *(reserved / unreserved / escaped
/ UTF8-NONASCII / UTF8-CONT / SP / HTAB)
Informational = "100" ; Trying
/ "180" ; Ringing
/ "181" ; Call Is Being Forwarded
/ "182" ; Queued
/ "183" ; Session Progress
Success = "200" ; OK
成功= "200"; OK
Redirection = "300" ; Multiple Choices
/ "301" ; Moved Permanently
/ "302" ; Moved Temporarily
/ "305" ; Use Proxy
/ "380" ; Alternative Service
Client-Error = "400" ; Bad Request
/ "401" ; Unauthorized
/ "402" ; Payment Required
/ "403" ; Forbidden
/ "404" ; Not Found
/ "405" ; Method Not Allowed
/ "406" ; Not Acceptable
/ "407" ; Proxy Authentication Required
/ "408" ; Request Timeout
/ "410" ; Gone
/ "413" ; Request Entity Too Large
/ "414" ; Request-URI Too Large
/ "415" ; Unsupported Media Type
/ "416" ; Unsupported URI Scheme
/ "420" ; Bad Extension
/ "421" ; Extension Required
/ "423" ; Interval Too Brief
/ "480" ; Temporarily not available
/ "481" ; Call Leg/Transaction Does Not Exist
/ "482" ; Loop Detected
/ "483" ; Too Many Hops
/ "484" ; Address Incomplete
/ "485" ; Ambiguous
/ "486" ; Busy Here
/ "487" ; Request Terminated
/ "488" ; Not Acceptable Here
/ "491" ; Request Pending
/ "493" ; Undecipherable
Server-Error = "500" ; Internal Server Error
/ "501" ; Not Implemented
/ "502" ; Bad Gateway
/ "503" ; Service Unavailable
/ "504" ; Server Time-out
/ "505" ; SIP Version not supported
/ "513" ; Message Too Large
Global-Failure = "600" ; Busy Everywhere
/ "603" ; Decline
/ "604" ; Does not exist anywhere
/ "606" ; Not Acceptable
Accept = "Accept" HCOLON
[ accept-range *(COMMA accept-range) ]
accept-range = media-range *(SEMI accept-param)
media-range = ( "*/*"
/ ( m-type SLASH "*" )
/ ( m-type SLASH m-subtype )
) *( SEMI m-parameter )
accept-param = ("q" EQUAL qvalue) / generic-param
qvalue = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] )
generic-param = token [ EQUAL gen-value ]
gen-value = token / host / quoted-string
Accept-Encoding = "Accept-Encoding" HCOLON
[ encoding *(COMMA encoding) ]
encoding = codings *(SEMI accept-param)
codings = content-coding / "*"
content-coding = token
Accept-Language = "Accept-Language" HCOLON
[ language *(COMMA language) ]
language = language-range *(SEMI accept-param)
language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) / "*" )
Alert-Info = "Alert-Info" HCOLON alert-param *(COMMA alert-param)
alert-param = LAQUOT absoluteURI RAQUOT *( SEMI generic-param )
Allow = "Allow" HCOLON [Method *(COMMA Method)]
Allow = "Allow" HCOLON [メソッド*（COMMAメソッド）]
Authorization = "Authorization" HCOLON credentials
credentials = ("Digest" LWS digest-response)
/ other-response
digest-response = dig-resp *(COMMA dig-resp)
dig-resp = username / realm / nonce / digest-uri
/ dresponse / algorithm / cnonce
/ opaque / message-qop
/ nonce-count / auth-param
username = "username" EQUAL username-value
username-value = quoted-string
digest-uri = "uri" EQUAL LDQUOT digest-uri-value RDQUOT
digest-uri-value = rquest-uri ; Equal to request-uri as specified
by HTTP/1.1
message-qop = "qop" EQUAL qop-value cnonce = "cnonce" EQUAL cnonce-value
cnonce-value = nonce-value
nonce-count = "nc" EQUAL nc-value
nc-value = 8LHEX
dresponse = "response" EQUAL request-digest
request-digest = LDQUOT 32LHEX RDQUOT
auth-param = auth-param-name EQUAL
( token / quoted-string )
auth-param-name = token
other-response = auth-scheme LWS auth-param
*(COMMA auth-param)
auth-scheme = token
Authentication-Info = "Authentication-Info" HCOLON ainfo
*(COMMA ainfo)
ainfo = nextnonce / message-qop
/ response-auth / cnonce
/ nonce-count
nextnonce = "nextnonce" EQUAL nonce-value
response-auth = "rspauth" EQUAL response-digest
response-digest = LDQUOT *LHEX RDQUOT
Call-ID = ( "Call-ID" / "i" ) HCOLON callid
callid = word [ "@" word ]
Call-Info = "Call-Info" HCOLON info *(COMMA info)
info = LAQUOT absoluteURI RAQUOT *( SEMI info-param)
info-param = ( "purpose" EQUAL ( "icon" / "info"
/ "card" / token ) ) / generic-param
Contact = ("Contact" / "m" ) HCOLON
( STAR / (contact-param *(COMMA contact-param)))
contact-param = (name-addr / addr-spec) *(SEMI contact-params)
name-addr = [ display-name ] LAQUOT addr-spec RAQUOT
addr-spec = SIP-URI / SIPS-URI / absoluteURI
display-name = *(token LWS)/ quoted-string
contact-params = c-p-q / c-p-expires
/ contact-extension
c-p-q = "q" EQUAL qvalue
c-p-expires = "expires" EQUAL delta-seconds
contact-extension = generic-param
delta-seconds = 1*DIGIT
Content-Disposition = "Content-Disposition" HCOLON
disp-type *( SEMI disp-param )
disp-type = "render" / "session" / "icon" / "alert"
/ disp-extension-token
disp-param = handling-param / generic-param handling-param = "handling" EQUAL ( "optional" / "required" / other-handling ) other-handling = token disp-extension-token = token
disp-param = Handling-param / generic-param Handling-param = "handling" EQUAL（ "optional" / "required" / other-handling）other-handling = token disp-extension-token = token
Content-Encoding = ( "Content-Encoding" / "e" ) HCOLON content-coding *(COMMA content-coding)
Content-Encoding =（ "Content-Encoding" / "e"）HCOLON content-coding *（COMMA content-coding）
Content-Language = "Content-Language" HCOLON
language-tag *(COMMA language-tag)
language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA
Content-Length = ( "Content-Length" / "l" ) HCOLON 1*DIGIT
Content-Type = ( "Content-Type" / "c" ) HCOLON media-type
media-type = m-type SLASH m-subtype *(SEMI m-parameter)
m-type = discrete-type / composite-type
discrete-type = "text" / "image" / "audio" / "video"
/ "application" / extension-token
composite-type = "message" / "multipart" / extension-token
extension-token = ietf-token / x-token
ietf-token = token
x-token = "x-" token
m-subtype = extension-token / iana-token
iana-token = token
m-parameter = m-attribute EQUAL m-value
m-attribute = token
m-value = token / quoted-string
CSeq = "CSeq" HCOLON 1*DIGIT LWS Method
CSeq = "CSeq" HCOLON 1 * DIGIT LWSメソッド
Date = "Date" HCOLON SIP-date
SIP-date = rfc1123-date
rfc1123-date = wkday "," SP date1 SP time SP "GMT"
date1 = 2DIGIT SP month SP 4DIGIT
; day month year (e.g., 02 Jun 1982)
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
; 00:00:00 - 23:59:59
wkday = "Mon" / "Tue" / "Wed"
/ "Thu" / "Fri" / "Sat" / "Sun"
month = "Jan" / "Feb" / "Mar" / "Apr"
/ "May" / "Jun" / "Jul" / "Aug"
/ "Sep" / "Oct" / "Nov" / "Dec"
Error-Info = "Error-Info" HCOLON error-uri *(COMMA error-uri) error-uri = LAQUOT absoluteURI RAQUOT *( SEMI generic-param )
Expires = "Expires" HCOLON delta-seconds
From = ( "From" / "f" ) HCOLON from-spec
from-spec = ( name-addr / addr-spec )
*( SEMI from-param )
from-param = tag-param / generic-param
tag-param = "tag" EQUAL token
In-Reply-To = "In-Reply-To" HCOLON callid *(COMMA callid)
In-Reply-To = "In-Reply-To" HCOLON callid *（COMMA callid）
Max-Forwards = "Max-Forwards" HCOLON 1*DIGIT
Max-Forwards = "Max-Forwards" HCOLON 1 * DIGIT
MIME-Version = "MIME-Version" HCOLON 1*DIGIT "." 1*DIGIT
Min-Expires = "Min-Expires" HCOLON delta-seconds
Min-Expires = "Min-Expires" HCOLONデルタ秒
Organization = "Organization" HCOLON [TEXT-UTF8-TRIM]
組織= "組織" HCOLON [TEXT-UTF8-TRIM]
Priority = "Priority" HCOLON priority-value
priority-value = "emergency" / "urgent" / "normal"
/ "non-urgent" / other-priority
other-priority = token
Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge
challenge = ("Digest" LWS digest-cln *(COMMA digest-cln))
/ other-challenge
other-challenge = auth-scheme LWS auth-param
*(COMMA auth-param)
digest-cln = realm / domain / nonce
/ opaque / stale / algorithm
/ qop-options / auth-param
realm = "realm" EQUAL realm-value
realm-value = quoted-string
domain = "domain" EQUAL LDQUOT URI
*( 1*SP URI ) RDQUOT
URI = absoluteURI / abs-path
nonce = "nonce" EQUAL nonce-value
nonce-value = quoted-string
opaque = "opaque" EQUAL quoted-string
stale = "stale" EQUAL ( "true" / "false" )
algorithm = "algorithm" EQUAL ( "MD5" / "MD5-sess"
/ token )
qop-options = "qop" EQUAL LDQUOT qop-value
*("," qop-value) RDQUOT
qop-value = "auth" / "auth-int" / token
Proxy-Authorization = "Proxy-Authorization" HCOLON credentials Proxy-Require = "Proxy-Require" HCOLON option-tag *(COMMA option-tag) option-tag = token
Proxy-Authorization = "Proxy-Authorization" HCOLON資格情報Proxy-Require = "Proxy-Require" HCOLON option-tag *（COMMA option-tag）option-tag = token
Record-Route = "Record-Route" HCOLON rec-route *(COMMA rec-route)
rec-route = name-addr *( SEMI rr-param )
rr-param = generic-param
Reply-To = "Reply-To" HCOLON rplyto-spec
rplyto-spec = ( name-addr / addr-spec )
*( SEMI rplyto-param )
rplyto-param = generic-param
Require = "Require" HCOLON option-tag *(COMMA option-tag)
Retry-After = "Retry-After" HCOLON delta-seconds [ comment ] *( SEMI retry-param )
Retry-After = "Retry-After" HCOLON delta-seconds [コメント] *（SEMI retry-param）
retry-param = ("duration" EQUAL delta-seconds) / generic-param
retry-param =（ "duration" EQUAL delta-seconds）/ generic-param
Route = "Route" HCOLON route-param *(COMMA route-param)
route-param = name-addr *( SEMI rr-param )
Server = "Server" HCOLON server-val *(LWS server-val)
server-val = product / comment
product = token [SLASH product-version]
product-version = token
Subject = ( "Subject" / "s" ) HCOLON [TEXT-UTF8-TRIM]
件名=（ "件名" / "s"）HCOLON [TEXT-UTF8-TRIM]
Supported = ( "Supported" / "k" ) HCOLON [option-tag *(COMMA option-tag)]
サポート=（ "サポート" / "k"）HCOLON [オプションタグ*（COMMAオプションタグ）]
Timestamp = "Timestamp" HCOLON 1*(DIGIT)
[ "." *(DIGIT) ] [ LWS delay ]
delay = *(DIGIT) [ "." *(DIGIT) ]
To = ( "To" / "t" ) HCOLON ( name-addr
/ addr-spec ) *( SEMI to-param )
to-param = tag-param / generic-param
Unsupported = "Unsupported" HCOLON option-tag *(COMMA option-tag)
User-Agent = "User-Agent" HCOLON server-val *(LWS server-val) Via = ( "Via" / "v" ) HCOLON via-parm *(COMMA via-parm)
via-parm = sent-protocol LWS sent-by *( SEMI via-params )
via-params = via-ttl / via-maddr
/ via-received / via-branch
/ via-extension
via-ttl = "ttl" EQUAL ttl
via-maddr = "maddr" EQUAL host
via-received = "received" EQUAL (IPv4address / IPv6address)
via-branch = "branch" EQUAL token
via-extension = generic-param
sent-protocol = protocol-name SLASH protocol-version
SLASH transport
protocol-name = "SIP" / token
protocol-version = token
transport = "UDP" / "TCP" / "TLS" / "SCTP"
/ other-transport
sent-by = host [ COLON port ]
ttl = 1*3DIGIT ; 0 to 255
Warning = "Warning" HCOLON warning-value *(COMMA warning-value)
warning-value = warn-code SP warn-agent SP warn-text
warn-code = 3DIGIT
warn-agent = hostport / pseudonym
; the name or pseudonym of the server adding
; the Warning header, for use in debugging
warn-text = quoted-string
pseudonym = token
WWW-Authenticate = "WWW-Authenticate" HCOLON challenge
WWW-Authenticate = "WWW-Authenticate" HCOLONチャレンジ
extension-header = header-name HCOLON header-value
header-name = token
header-value = *(TEXT-UTF8char / UTF8-CONT / LWS)
message-body = *OCTET
26 Security Considerations: Threat Model and Security Usage Recommendations
26セキュリティに関する考慮事項：脅威モデルとセキュリティの使用に関する推奨事項
SIP is not an easy protocol to secure. Its use of intermediaries, its multi-faceted trust relationships, its expected usage between elements with no trust at all, and its user-to-user operation make security far from trivial. Security solutions are needed that are deployable today, without extensive coordination, in a wide variety of environments and usages. In order to meet these diverse needs, several distinct mechanisms applicable to different aspects and usages of SIP will be required.
SIPは安全なプロトコルではありません。仲介者の使用、多面的な信頼関係、まったく信頼されていない要素間の予想される使用法、およびユーザー間の操作により、セキュリティは簡単なものにはなりません。広範な調整なしで、さまざまな環境と使用法で今日展開可能なセキュリティソリューションが必要です。これらの多様なニーズを満たすために、SIPのさまざまな側面と使用法に適用可能ないくつかの異なるメカニズムが必要になります。
Note that the security of SIP signaling itself has no bearing on the security of protocols used in concert with SIP such as RTP, or with the security implications of any specific bodies SIP might carry (although MIME security plays a substantial role in securing SIP). Any media associated with a session can be encrypted end-to-end independently of any associated SIP signaling. Media encryption is outside the scope of this document.
SIPシグナリング自体のセキュリティは、RTPなどのSIPと組み合わせて使用されるプロトコルのセキュリティや、SIPが運ぶ可能性のある特定のボディのセキュリティに影響を与えないことに注意してください（ただし、MIMEセキュリティはSIPの保護に重要な役割を果たします）。セッションに関連付けられたメディアは、関連付けられたSIPシグナリングとは無関係にエンドツーエンドで暗号化できます。メディアの暗号化は、このドキュメントの範囲外です。
The considerations that follow first examine a set of classic threat models that broadly identify the security needs of SIP. The set of security services required to address these threats is then detailed, followed by an explanation of several security mechanisms that can be used to provide these services. Next, the requirements for implementers of SIP are enumerated, along with exemplary deployments in which these security mechanisms could be used to improve the security of SIP. Some notes on privacy conclude this section.
以下の考慮事項では、最初にSIPのセキュリティニーズを広く識別する一連の古典的な脅威モデルを調べます。次に、これらの脅威に対処するために必要な一連のセキュリティサービスについて詳しく説明し、次にこれらのサービスの提供に使用できるいくつかのセキュリティメカニズムについて説明します。次に、SIPの実装者の要件が、SIPのセキュリティを向上させるためにこれらのセキュリティメカニズムを使用できる例示的な展開とともに列挙されます。プライバシーに関するいくつかの注意事項がこのセクションの最後にあります。
This section details some threats that should be common to most deployments of SIP. These threats have been chosen specifically to illustrate each of the security services that SIP requires.
このセクションでは、SIPのほとんどの展開に共通する脅威について詳しく説明します。これらの脅威は、SIPが必要とする各セキュリティサービスを具体的に説明するために選択されています。
The following examples by no means provide an exhaustive list of the threats against SIP; rather, these are "classic" threats that demonstrate the need for particular security services that can potentially prevent whole categories of threats.
次の例は、SIPに対する脅威の完全なリストを提供するものではありません。むしろ、これらは「古典的な」脅威であり、脅威のカテゴリ全体を潜在的に防止できる特定のセキュリティサービスの必要性を示しています。
These attacks assume an environment in which attackers can potentially read any packet on the network - it is anticipated that SIP will frequently be used on the public Internet. Attackers on the network may be able to modify packets (perhaps at some compromised intermediary). Attackers may wish to steal services, eavesdrop on communications, or disrupt sessions.
これらの攻撃は、攻撃者がネットワーク上の任意のパケットを潜在的に読み取ることができる環境を想定しています-SIPは公衆インターネットで頻繁に使用されることが予想されます。ネットワーク上の攻撃者は、パケットを変更できる可能性があります（おそらく何らかの侵害された仲介者で）。攻撃者は、サービスを盗んだり、通信を盗聴したり、セッションを妨害したりすることがあります。
The SIP registration mechanism allows a user agent to identify itself to a registrar as a device at which a user (designated by an address of record) is located. A registrar assesses the identity asserted in the From header field of a REGISTER message to determine whether this request can modify the contact addresses associated with the address-of-record in the To header field. While these two fields are frequently the same, there are many valid deployments in which a third-party may register contacts on a user's behalf.
SIP登録メカニズムにより、ユーザーエージェントは、レジストラに対して、ユーザー（レコードのアドレスで指定）が配置されているデバイスとして自分自身を識別できます。レジストラは、REGISTERメッセージのFromヘッダーフィールドでアサートされたIDを評価して、この要求がToヘッダーフィールドのレコードのアドレスに関連付けられた連絡先アドレスを変更できるかどうかを判断します。これら2つのフィールドは同じであることがよくありますが、サードパーティがユーザーの代わりに連絡先を登録できる有効な展開が数多くあります。
The From header field of a SIP request, however, can be modified arbitrarily by the owner of a UA, and this opens the door to malicious registrations. An attacker that successfully impersonates a party authorized to change contacts associated with an address-of-record could, for example, de-register all existing contacts for a URI and then register their own device as the appropriate contact address, thereby directing all requests for the affected user to the attacker's device.
ただし、SIPリクエストのFromヘッダーフィールドは、UAの所有者が任意に変更できるため、悪意のある登録への扉が開かれます。レコードのアドレスに関連付けられた連絡先を変更する権限を与えられた当事者を偽装する攻撃者は、たとえば、URIのすべての既存の連絡先の登録を解除し、適切な連絡先アドレスとして自分のデバイスを登録することにより、攻撃者のデバイスへの影響を受けるユーザー。
This threat belongs to a family of threats that rely on the absence of cryptographic assurance of a request's originator. Any SIP UAS that represents a valuable service (a gateway that interworks SIP requests with traditional telephone calls, for example) might want to control access to its resources by authenticating requests that it receives. Even end-user UAs, for example SIP phones, have an interest in ascertaining the identities of originators of requests.
この脅威は、要求の発信者の暗号による保証がないことに依存する脅威のファミリーに属しています。価値のあるサービスを表すSIP UAS（たとえば、SIP要求を従来の電話呼び出しと相互運用するゲートウェイ）は、受信した要求を認証することにより、リソースへのアクセスを制御する必要があります。エンドユーザーUA、たとえばSIP電話も、要求の発信者のIDを確認することに関心があります。
This threat demonstrates the need for security services that enable SIP entities to authenticate the originators of requests.
この脅威は、SIPエンティティが要求の発信者を認証できるようにするセキュリティサービスの必要性を示しています。
The domain to which a request is destined is generally specified in the Request-URI. UAs commonly contact a server in this domain directly in order to deliver a request. However, there is always a possibility that an attacker could impersonate the remote server, and that the UA's request could be intercepted by some other party.
リクエストの宛先となるドメインは、通常、Request-URIで指定されます。 UAは通常、リクエストを配信するためにこのドメインのサーバーに直接接続します。ただし、攻撃者がリモートサーバーになりすまし、UAのリクエストが他のパーティに傍受される可能性は常にあります。
For example, consider a case in which a redirect server at one domain, chicago.com, impersonates a redirect server at another domain, biloxi.com. A user agent sends a request to biloxi.com, but the redirect server at chicago.com answers with a forged response that has appropriate SIP header fields for a response from biloxi.com. The forged contact addresses in the redirection response could direct the originating UA to inappropriate or insecure resources, or simply prevent requests for biloxi.com from succeeding.
たとえば、あるドメイン（chicago.com）のリダイレクトサーバーが別のドメイン（biloxi.com）のリダイレクトサーバーになりすます場合を考えてみます。ユーザーエージェントはbiloxi.comにリクエストを送信しますが、chicago.comのリダイレクトサーバーは、biloxi.comからの応答に適切なSIPヘッダーフィールドを持つ偽造された応答で応答します。リダイレクト応答の偽造された連絡先アドレスは、発信元のUAを不適切または安全でないリソースに誘導したり、biloxi.comへの要求の成功を妨げたりする可能性があります。
This family of threats has a vast membership, many of which are critical. As a converse to the registration hijacking threat, consider the case in which a registration sent to biloxi.com is intercepted by chicago.com, which replies to the intercepted registration with a forged 301 (Moved Permanently) response. This response might seem to come from biloxi.com yet designate chicago.com as the appropriate registrar. All future REGISTER requests from the originating UA would then go to chicago.com.
この脅威のファミリーは広大なメンバーシップを持ち、その多くは重要です。登録ハイジャックの脅威とは逆に、biloxi.comに送信された登録が、偽造された301（Moved Permanently）応答でインターセプトされた登録に返信するchicago.comによってインターセプトされた場合を考えます。この応答はbiloxi.comから送信されたように見えるかもしれませんが、適切なレジストラとしてchicago.comを指定しています。その後、元のUAからのすべてのREGISTER要求は、chicago.comに送信されます。
Prevention of this threat requires a means by which UAs can authenticate the servers to whom they send requests.
この脅威を防止するには、UAがリクエストの送信先のサーバーを認証できる手段が必要です。
As a matter of course, SIP UAs route requests through trusted proxy servers. Regardless of how that trust is established (authentication of proxies is discussed elsewhere in this section), a UA may trust a proxy server to route a request, but not to inspect or possibly modify the bodies contained in that request.
もちろん、SIP UAは信頼されたプロキシサーバーを介して要求をルーティングします。その信頼がどのように確立されるかに関係なく（プロキシの認証については、このセクションの他の場所で説明します）、UAはプロキシサーバーを信頼して要求をルーティングしますが、その要求に含まれる本文を検査または変更することはできません。
Consider a UA that is using SIP message bodies to communicate session encryption keys for a media session. Although it trusts the proxy server of the domain it is contacting to deliver signaling properly, it may not want the administrators of that domain to be capable of decrypting any subsequent media session. Worse yet, if the proxy server were actively malicious, it could modify the session key, either acting as a man-in-the-middle, or perhaps changing the security characteristics requested by the originating UA.
メディアセッションのセッション暗号化キーを通信するためにSIPメッセージ本文を使用しているUAを検討してください。連絡先のドメインのプロキシサーバーを信頼してシグナリングを適切に配信しますが、そのドメインの管理者が後続のメディアセッションを復号化できないようにする場合があります。さらに悪いことに、プロキシサーバーがアクティブに悪意のある場合、中間者として機能するか、発信元UAから要求されたセキュリティ特性を変更して、セッションキーを変更する可能性があります。
This family of threats applies not only to session keys, but to most conceivable forms of content carried end-to-end in SIP. These might include MIME bodies that should be rendered to the user, SDP, or encapsulated telephony signals, among others. Attackers might attempt to modify SDP bodies, for example, in order to point RTP media streams to a wiretapping device in order to eavesdrop on subsequent voice communications.
この脅威のファミリーは、セッションキーだけでなく、SIPでエンドツーエンドで伝送される考えられるほとんどの形式のコンテンツに適用されます。これらには、ユーザー、SDP、またはカプセル化されたテレフォニー信号などにレンダリングされるMIME本文が含まれる場合があります。攻撃者は、たとえば、RTPメディアストリームを盗聴デバイスにポイントして後続の音声通信を傍受するために、SDP本体を変更しようと試みる可能性があります。
Also note that some header fields in SIP are meaningful end-to-end, for example, Subject. UAs might be protective of these header fields as well as bodies (a malicious intermediary changing the Subject header field might make an important request appear to be spam, for example). However, since many header fields are legitimately inspected or altered by proxy servers as a request is routed, not all header fields should be secured end-to-end.
また、SIPの一部のヘッダーフィールドは、Subjectなど、エンドツーエンドで意味があることに注意してください。 UAはこれらのヘッダーフィールドと本文を保護している可能性があります（たとえば、悪意のある仲介者がSubjectヘッダーフィールドを変更すると、重要なリクエストがスパムであるように見えることがあります）。ただし、リクエストがルーティングされると、多くのヘッダーフィールドがプロキシサーバーによって合法的に検査または変更されるため、すべてのヘッダーフィールドをエンドツーエンドで保護する必要はありません。
For these reasons, the UA might want to secure SIP message bodies, and in some limited cases header fields, end-to-end. The security services required for bodies include confidentiality, integrity, and authentication. These end-to-end services should be independent of the means used to secure interactions with intermediaries such as proxy servers.
これらの理由により、UAはSIPメッセージ本文を保護したい場合があり、場合によってはヘッダーフィールドをエンドツーエンドで保護する必要があります。組織に必要なセキュリティサービスには、機密性、整合性、および認証が含まれます。これらのエンドツーエンドサービスは、プロキシサーバーなどの仲介者とのやり取りを保護するために使用される手段から独立している必要があります。
Once a dialog has been established by initial messaging, subsequent requests can be sent that modify the state of the dialog and/or session. It is critical that principals in a session can be certain that such requests are not forged by attackers.
最初のメッセージングによってダイアログが確立されると、ダイアログやセッションの状態を変更する後続の要求を送信できます。セッションのプリンシパルが、そのようなリクエストが攻撃者によって偽造されていないことを確認できることが重要です。
Consider a case in which a third-party attacker captures some initial messages in a dialog shared by two parties in order to learn the parameters of the session (To tag, From tag, and so forth) and then inserts a BYE request into the session. The attacker could opt to forge the request such that it seemed to come from either participant. Once the BYE is received by its target, the session will be torn down prematurely.
サードパーティの攻撃者が、セッションのパラメータ（Toタグ、Fromタグなど）を知るために2つのパーティが共有するダイアログでいくつかの初期メッセージをキャプチャし、BYEリクエストをセッションに挿入する場合を考えます。 。攻撃者は、どちらかの参加者からのものであるようにリクエストを偽造することを選択できます。 BYEがターゲットによって受信されると、セッションは途中で破棄されます。
Similar mid-session threats include the transmission of forged re-INVITEs that alter the session (possibly to reduce session security or redirect media streams as part of a wiretapping attack).
同様のセッション中の脅威には、セッションを変更する偽造されたre-INVITEの送信が含まれます（おそらく、セッションのセキュリティを低下させるか、盗聴攻撃の一部としてメディアストリームをリダイレクトするためです）。
The most effective countermeasure to this threat is the authentication of the sender of the BYE. In this instance, the recipient needs only know that the BYE came from the same party with whom the corresponding dialog was established (as opposed to ascertaining the absolute identity of the sender). Also, if the attacker is unable to learn the parameters of the session due to confidentiality, it would not be possible to forge the BYE. However, some intermediaries (like proxy servers) will need to inspect those parameters as the session is established.
この脅威に対する最も効果的な対策は、BYEの送信者の認証です。この場合、受信者は、BYEが対応するダイアログが確立されたのと同じ当事者から送信されたことを知るだけで済みます（送信者の絶対的なIDを確認するのではなく）。また、機密性のために攻撃者がセッションのパラメータを知ることができない場合、BYEを偽造することはできません。ただし、一部の仲介者（プロキシサーバーなど）は、セッションの確立時にこれらのパラメーターを検査する必要があります。
Denial-of-service attacks focus on rendering a particular network element unavailable, usually by directing an excessive amount of network traffic at its interfaces. A distributed denial-of-service attack allows one network user to cause multiple network hosts to flood a target host with a large amount of network traffic.
サービス拒否攻撃は、通常、そのインターフェイスに過剰な量のネットワークトラフィックを送ることにより、特定のネットワーク要素を使用不可にすることに重点を置いています。分散型サービス拒否攻撃により、1人のネットワークユーザーが複数のネットワークホストに大量のネットワークトラフィックでターゲットホストをあふれさせることができます。
In many architectures, SIP proxy servers face the public Internet in order to accept requests from worldwide IP endpoints. SIP creates a number of potential opportunities for distributed denial-of-service attacks that must be recognized and addressed by the implementers and operators of SIP systems.
多くのアーキテクチャでは、世界中のIPエンドポイントからの要求を受け入れるために、SIPプロキシサーバーがパブリックインターネットに面しています。 SIPは、SIPシステムの実装者と運用者が認識して対処する必要のある、分散型サービス拒否攻撃の潜在的な機会を数多く生み出します。
Attackers can create bogus requests that contain a falsified source IP address and a corresponding Via header field that identify a targeted host as the originator of the request and then send this request to a large number of SIP network elements, thereby using hapless SIP UAs or proxies to generate denial-of-service traffic aimed at the target.
攻撃者は、偽造された送信元IPアドレスと対応するViaヘッダーフィールドを含む偽の要求を作成し、ターゲットホストを要求の発信元として識別して、この要求を多数のSIPネットワーク要素に送信することにより、不幸なSIP UAまたはプロキシを使用できます。ターゲットを狙ったサービス拒否トラフィックを生成します。
Similarly, attackers might use falsified Route header field values in a request that identify the target host and then send such messages to forking proxies that will amplify messaging sent to the target.
同様に、攻撃者は、リクエストで偽造されたルートヘッダーフィールド値を使用してターゲットホストを識別し、ターゲットに送信されるメッセージングを増幅するフォークプロキシにそのようなメッセージを送信する可能性があります。
Record-Route could be used to similar effect when the attacker is certain that the SIP dialog initiated by the request will result in numerous transactions originating in the backwards direction.
Record-Routeは、リクエストによって開始されたSIPダイアログが多数のトランザクションを逆方向に発生させることを攻撃者が確信している場合に、同様の効果に使用される可能性があります。
A number of denial-of-service attacks open up if REGISTER requests are not properly authenticated and authorized by registrars. Attackers could de-register some or all users in an administrative domain, thereby preventing these users from being invited to new sessions. An attacker could also register a large number of contacts designating the same host for a given address-of-record in order to use the registrar and any associated proxy servers as amplifiers in a denial-of-service attack. Attackers might also attempt to deplete available memory and disk resources of a registrar by registering huge numbers of bindings.
REGISTERリクエストがレジストラによって適切に認証および承認されない場合、多くのサービス拒否攻撃が発生します。攻撃者は、管理ドメイン内の一部またはすべてのユーザーの登録を解除して、これらのユーザーが新しいセッションに招待されないようにする可能性があります。攻撃者は、レジストラと関連するプロキシサーバーをサービス拒否攻撃の増幅器として使用するために、特定のレコードのアドレスに同じホストを指定する多数の連絡先を登録することもできます。攻撃者はまた、膨大な数のバインディングを登録することにより、レジストラの利用可能なメモリとディスクリソースを使い果たしようとする可能性があります。
The use of multicast to transmit SIP requests can greatly increase the potential for denial-of-service attacks.
マルチキャストを使用してSIP要求を送信すると、サービス拒否攻撃の可能性が大幅に高まります。
These problems demonstrate a general need to define architectures that minimize the risks of denial-of-service, and the need to be mindful in recommendations for security mechanisms of this class of attacks.
これらの問題は、サービス拒否のリスクを最小限に抑えるアーキテクチャを定義する一般的な必要性、およびこのクラスの攻撃のセキュリティメカニズムの推奨事項に留意する必要性を示しています。
From the threats described above, we gather that the fundamental security services required for the SIP protocol are: preserving the confidentiality and integrity of messaging, preventing replay attacks or message spoofing, providing for the authentication and privacy of the participants in a session, and preventing denial-of-service attacks. Bodies within SIP messages separately require the security services of confidentiality, integrity, and authentication.
上記の脅威から、SIPプロトコルに必要な基本的なセキュリティサービスは次のとおりです。メッセージングの機密性と整合性の保持、リプレイ攻撃またはメッセージスプーフィングの防止、セッションの参加者の認証とプライバシーの提供、および防止サービス拒否攻撃。 SIPメッセージ内の本体には、機密性、整合性、および認証のセキュリティサービスが個別に必要です。
Rather than defining new security mechanisms specific to SIP, SIP reuses wherever possible existing security models derived from the HTTP and SMTP space.
SIPは、SIPに固有の新しいセキュリティメカニズムを定義するのではなく、HTTPおよびSMTPスペースから派生した既存のセキュリティモデルを可能な限り再利用します。
Full encryption of messages provides the best means to preserve the confidentiality of signaling - it can also guarantee that messages are not modified by any malicious intermediaries. However, SIP requests and responses cannot be naively encrypted end-to-end in their entirety because message fields such as the Request-URI, Route, and Via need to be visible to proxies in most network architectures so that SIP requests are routed correctly. Note that proxy servers need to modify some features of messages as well (such as adding Via header field values) in order for SIP to function. Proxy servers must therefore be trusted, to some degree, by SIP UAs. To this purpose, low-layer security mechanisms for SIP are recommended, which encrypt the entire SIP requests or responses on the wire on a hop-by-hop basis, and that allow endpoints to verify the identity of proxy servers to whom they send requests.
メッセージの完全な暗号化は、シグナリングの機密性を保持するための最良の手段を提供します。また、悪意のある仲介者によってメッセージが変更されないことも保証できます。ただし、SIP要求が正しくルーティングされるように、ほとんどのネットワークアーキテクチャでは、Request-URI、Route、Viaなどのメッセージフィールドをプロキシから認識できるようにする必要があるため、SIP要求と応答全体を単純に暗号化することはできません。 SIPが機能するためには、プロキシサーバーもメッセージの一部の機能（Viaヘッダーフィールド値の追加など）を変更する必要があることに注意してください。したがって、プロキシサーバーは、ある程度、SIP UAによって信頼されている必要があります。この目的のために、SIPの低層セキュリティメカニズムをお勧めします。これにより、SIP要求全体またはホップバイホップベースでワイヤ上の応答を暗号化し、エンドポイントが要求の送信先のプロキシサーバーのIDを確認できるようになります。 。
SIP entities also have a need to identify one another in a secure fashion. When a SIP endpoint asserts the identity of its user to a peer UA or to a proxy server, that identity should in some way be verifiable. A cryptographic authentication mechanism is provided in SIP to address this requirement.
また、SIPエンティティは、安全な方法でお互いを識別する必要があります。 SIPエンドポイントがピアUAまたはプロキシサーバーにユーザーのIDをアサートする場合、そのIDは何らかの方法で検証可能である必要があります。この要件に対処するために、SIPには暗号化認証メカニズムが用意されています。
An independent security mechanism for SIP message bodies supplies an alternative means of end-to-end mutual authentication, as well as providing a limit on the degree to which user agents must trust intermediaries.
SIPメッセージ本文の独立したセキュリティメカニズムは、エンドツーエンドの相互認証の代替手段を提供するだけでなく、ユーザーエージェントが仲介者を信頼する必要がある度合いに制限を提供します。
Transport or network layer security encrypts signaling traffic, guaranteeing message confidentiality and integrity.
トランスポートまたはネットワーク層のセキュリティは、シグナリングトラフィックを暗号化し、メッセージの機密性と整合性を保証します。
Oftentimes, certificates are used in the establishment of lower-layer security, and these certificates can also be used to provide a means of authentication in many architectures.
多くの場合、証明書は下位層セキュリティの確立に使用され、これらの証明書は多くのアーキテクチャで認証の手段を提供するためにも使用できます。
Two popular alternatives for providing security at the transport and network layer are, respectively, TLS [25] and IPSec [26].
トランスポート層とネットワーク層でセキュリティを提供するための一般的な2つの代替策は、それぞれTLS [25]とIPSec [26]です。
IPSec is a set of network-layer protocol tools that collectively can be used as a secure replacement for traditional IP (Internet Protocol). IPSec is most commonly used in architectures in which a set of hosts or administrative domains have an existing trust relationship with one another. IPSec is usually implemented at the operating system level in a host, or on a security gateway that provides confidentiality and integrity for all traffic it receives from a particular interface (as in a VPN architecture). IPSec can also be used on a hop-by-hop basis.
IPSecは、従来のIP（インターネットプロトコル）の安全な代替として集合的に使用できるネットワーク層プロトコルツールのセットです。 IPSecは、ホストまたは管理ドメインのセットが互いに既存の信頼関係を持っているアーキテクチャで最も一般的に使用されます。 IPSecは通常、ホストのオペレーティングシステムレベル、または特定のインターフェイスから受信するすべてのトラフィックに機密性と整合性を提供するセキュリティゲートウェイに実装されます（VPNアーキテクチャの場合と同様）。 IPSecは、ホップバイホップベースで使用することもできます。
In many architectures IPSec does not require integration with SIP applications; IPSec is perhaps best suited to deployments in which adding security directly to SIP hosts would be arduous. UAs that have a pre-shared keying relationship with their first-hop proxy server are also good candidates to use IPSec. Any deployment of IPSec for SIP would require an IPSec profile describing the protocol tools that would be required to secure SIP. No such profile is given in this document.
多くのアーキテクチャでは、IPSecはSIPアプリケーションとの統合を必要としません。 IPSecは、SIPホストに直接セキュリティを追加することが困難な展開に最適です。ファーストホッププロキシサーバーとの事前共有キーイング関係を持つUAも、IPSecの使用に適しています。 SIP用のIPSecを展開するには、SIPを保護するために必要なプロトコルツールを記述したIPSecプロファイルが必要です。このドキュメントでは、そのようなプロファイルは提供されていません。
TLS provides transport-layer security over connection-oriented protocols (for the purposes of this document, TCP); "tls" (signifying TLS over TCP) can be specified as the desired transport protocol within a Via header field value or a SIP-URI. TLS is most suited to architectures in which hop-by-hop security is required between hosts with no pre-existing trust association. For example, Alice trusts her local proxy server, which after a certificate exchange decides to trust Bob's local proxy server, which Bob trusts, hence Bob and Alice can communicate securely.
TLSは、接続指向のプロトコル（このドキュメントではTCP）を介したトランスポート層セキュリティを提供します。 "tls"（TLS over TCPを示す）は、Viaヘッダーフィールド値またはSIP-URI内で目的のトランスポートプロトコルとして指定できます。 TLSは、既存の信頼アソシエーションのないホスト間でホップバイホップのセキュリティが必要とされるアーキテクチャに最も適しています。たとえば、アリスは自分のローカルプロキシサーバーを信頼します。これは、証明書の交換後に、ボブが信頼するボブのローカルプロキシサーバーを信頼することを決定するため、ボブとアリスは安全に通信できます。
TLS must be tightly coupled with a SIP application. Note that transport mechanisms are specified on a hop-by-hop basis in SIP, thus a UA that sends requests over TLS to a proxy server has no assurance that TLS will be used end-to-end.
TLSはSIPアプリケーションと緊密に結合する必要があります。トランスポートメカニズムはSIPでホップバイホップベースで指定されるため、TLS経由でプロキシサーバーにリクエストを送信するUAは、TLSがエンドツーエンドで使用されるとは限りません。
The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6] MUST be supported at a minimum by implementers when TLS is used in a SIP application. For purposes of backwards compatibility, proxy servers, redirect servers, and registrars SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any other ciphersuite.
The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6] MUST be supported at a minimum by implementers when TLS is used in a SIP application. For purposes of backwards compatibility, proxy servers, redirect servers, and registrars SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any other ciphersuite.
The SIPS URI scheme adheres to the syntax of the SIP URI (described in 19), although the scheme string is "sips" rather than "sip". The semantics of SIPS are very different from the SIP URI, however. SIPS allows resources to specify that they should be reached securely.
SIPS URIスキームはSIP URI（19で説明）の構文に準拠していますが、スキーム文字列は「sip」ではなく「sips」です。ただし、SIPSのセマンティクスはSIP URIとは大きく異なります。 SIPSを使用すると、リソースは安全に到達する必要があることを指定できます。
A SIPS URI can be used as an address-of-record for a particular user - the URI by which the user is canonically known (on their business cards, in the From header field of their requests, in the To header field of REGISTER requests). When used as the Request-URI of a request, the SIPS scheme signifies that each hop over which the request is forwarded, until the request reaches the SIP entity responsible for the domain portion of the Request-URI, must be secured with TLS; once it reaches the domain in question it is handled in accordance with local security and routing policy, quite possibly using TLS for any last hop to a UAS. When used by the originator of a request (as would be the case if they employed a SIPS URI as the address-of-record of the target), SIPS dictates that the entire request path to the target domain be so secured.
SIPS URIは、特定のユーザーのレコードのアドレスとして使用できます-ユーザーが正規に認識されるURI（名刺上、要求のFromヘッダーフィールド、REGISTER要求のToヘッダーフィールド） ）。要求のRequest-URIとして使用される場合、SIPSスキームは、要求が転送される各ホップが、要求がRequest-URIのドメイン部分を担当するSIPエンティティに到達するまで、TLSで保護する必要があることを示します。問題のドメインに到達すると、ローカルセキュリティとルーティングポリシーに従って処理され、UASへの最後のホップにTLSを使用する可能性があります。リクエストの発信者が（ターゲットのレコードのアドレスとしてSIPS URIを使用した場合と同様に）使用する場合、SIPSは、ターゲットドメインへのリクエストパス全体を保護するように指示します。
The SIPS scheme is applicable to many of the other ways in which SIP URIs are used in SIP today in addition to the Request-URI, including in addresses-of-record, contact addresses (the contents of Contact headers, including those of REGISTER methods), and Route headers. In each instance, the SIPS URI scheme allows these existing fields to designate secure resources. The manner in which a SIPS URI is dereferenced in any of these contexts has its own security properties which are detailed in [4].
The SIPS scheme is applicable to many of the other ways in which SIP URIs are used in SIP today in addition to the Request-URI, including in addresses-of-record, contact addresses (the contents of Contact headers, including those of REGISTER methods), and Route headers. In each instance, the SIPS URI scheme allows these existing fields to designate secure resources. The manner in which a SIPS URI is dereferenced in any of these contexts has its own security properties which are detailed in [4].
The use of SIPS in particular entails that mutual TLS authentication SHOULD be employed, as SHOULD the ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA. Certificates received in the authentication process SHOULD be validated with root certificates held by the client; failure to validate a certificate SHOULD result in the failure of the request.
特にSIPSを使用する場合は、暗号スイートTLS_RSA_WITH_AES_128_CBC_SHAを使用する必要があるため（SHOULD）、相互TLS認証を使用する必要があります（SHOULD）。認証プロセスで受信した証明書は、クライアントが保持するルート証明書で検証する必要があります（SHOULD）。証明書の検証に失敗すると、リクエストが失敗します。
Note that in the SIPS URI scheme, transport is independent of TLS, and thus "sips:alice@atlanta.com;transport=tcp" and "sips:alice@atlanta.com;transport=sctp" are both valid (although note that UDP is not a valid transport for SIPS). The use of "transport=tls" has consequently been deprecated, partly because it was specific to a single hop of the request. This is a change since RFC 2543.
SIPS URIスキームでは、トランスポートはTLSから独立しているため、「sips：alice@atlanta.com; transport = tcp」と「sips：alice@atlanta.com; transport = sctp」はどちらも有効です（ただし、 UDPはSIPSの有効なトランスポートではありません）。 「transport = tls」の使用は、リクエストの単一のホップに固有であったことも理由の1つとして、廃止されました。これはRFC 2543以降の変更です。
Users that distribute a SIPS URI as an address-of-record may elect to operate devices that refuse requests over insecure transports.
SIPS URIをレコードのアドレスとして配布するユーザーは、安全でないトランスポートを介した要求を拒否するデバイスを操作することを選択できます。
SIP provides a challenge capability, based on HTTP authentication, that relies on the 401 and 407 response codes as well as header fields for carrying challenges and credentials. Without significant modification, the reuse of the HTTP Digest authentication scheme in SIP allows for replay protection and one-way authentication.
SIPは、HTTP認証に基づくチャレンジ機能を提供します。これは、401と407の応答コード、およびチャレンジと資格情報を運ぶためのヘッダーフィールドに依存しています。大幅な変更を加えずに、SIPのHTTPダイジェスト認証スキームを再利用することで、リプレイ保護と一方向認証が可能になります。
The usage of Digest authentication in SIP is detailed in Section 22.
The usage of Digest authentication in SIP is detailed in Section 22.
As is discussed above, encrypting entire SIP messages end-to-end for the purpose of confidentiality is not appropriate because network intermediaries (like proxy servers) need to view certain header fields in order to route messages correctly, and if these intermediaries are excluded from security associations, then SIP messages will essentially be non-routable.
上で説明したように、メッセージを正しくルーティングするためにネットワーク仲介者（プロキシサーバーなど）が特定のヘッダーフィールドを表示する必要があり、これらの仲介者がセキュリティアソシエーションの場合、SIPメッセージは基本的にルーティング不可能になります。
However, S/MIME allows SIP UAs to encrypt MIME bodies within SIP, securing these bodies end-to-end without affecting message headers. S/MIME can provide end-to-end confidentiality and integrity for message bodies, as well as mutual authentication. It is also possible to use S/MIME to provide a form of integrity and confidentiality for SIP header fields through SIP message tunneling.
ただし、S / MIMEを使用すると、SIP UAはSIP内のMIME本体を暗号化でき、メッセージヘッダーに影響を与えることなくこれらの本体をエンドツーエンドで保護できます。 S / MIMEは、メッセージ本文のエンドツーエンドの機密性と整合性、および相互認証を提供できます。また、S / MIMEを使用して、SIPメッセージトンネリングを通じてSIPヘッダーフィールドの完全性と機密性の形式を提供することもできます。
The usage of S/MIME in SIP is detailed in Section 23.
The usage of S/MIME in SIP is detailed in Section 23.
Proxy servers, redirect servers, and registrars MUST implement TLS, and MUST support both mutual and one-way authentication. It is strongly RECOMMENDED that UAs be capable initiating TLS; UAs MAY also be capable of acting as a TLS server. Proxy servers, redirect servers, and registrars SHOULD possess a site certificate whose subject corresponds to their canonical hostname. UAs MAY have certificates of their own for mutual authentication with TLS, but no provisions are set forth in this document for their use. All SIP elements that support TLS MUST have a mechanism for validating certificates received during TLS negotiation; this entails possession of one or more root certificates issued by certificate authorities (preferably well-known distributors of site certificates comparable to those that issue root certificates for web browsers).
プロキシサーバー、リダイレクトサーバー、およびレジストラはTLSを実装する必要があり、相互認証と一方向認証の両方をサポートする必要があります。 UAがTLSを開始できることを強くお勧めします。 UAは、TLSサーバーとして機能することもできます（MAY）。プロキシサーバー、リダイレクトサーバー、およびレジストラは、サブジェクトが正規のホスト名に対応するサイト証明書を所有する必要があります（SHOULD）。 UAは、TLSとの相互認証のために独自の証明書を持っている場合がありますが、このドキュメントでは、その使用のための規定は規定されていません。 TLSをサポートするすべてのSIP要素は、TLSネゴシエーション中に受信した証明書を検証するためのメカニズムを備えている必要があります。これには、認証局（Webブラウザー用のルート証明書を発行するものに匹敵するサイト証明書のよく知られているディストリビューター）が発行した1つ以上のルート証明書を所有する必要があります。
All SIP elements that support TLS MUST also support the SIPS URI scheme.
TLSをサポートするすべてのSIP要素は、SIPS URIスキームもサポートする必要があります。
Proxy servers, redirect servers, registrars, and UAs MAY also implement IPSec or other lower-layer security protocols.
プロキシサーバー、リダイレクトサーバー、レジストラ、およびUAも、IPSecまたはその他の下位層セキュリティプロトコルを実装する場合があります。
When a UA attempts to contact a proxy server, redirect server, or registrar, the UAC SHOULD initiate a TLS connection over which it will send SIP messages. In some architectures, UASs MAY receive requests over such TLS connections as well.
UAがプロキシサーバー、リダイレクトサーバー、またはレジストラへの接続を試みる場合、UACはSIPメッセージを送信するTLS接続を開始する必要があります（SHOULD）。一部のアーキテクチャでは、UASはそのようなTLS接続を介して要求を受信する場合もあります。
Proxy servers, redirect servers, registrars, and UAs MUST implement Digest Authorization, encompassing all of the aspects required in 22. Proxy servers, redirect servers, and registrars SHOULD be configured with at least one Digest realm, and at least one "realm" string supported by a given server SHOULD correspond to the server's hostname or domainname.
プロキシサーバー、リダイレクトサーバー、レジストラ、およびUAは、22で必要なすべての側面を網羅するダイジェスト認証を実装する必要があります。プロキシサーバー、リダイレクトサーバー、およびレジストラは、少なくとも1つのダイジェストレルムと少なくとも1つの「レルム」文字列で構成する必要があります。与えられたサーバーによってサポートされるべきであるSHOULDはサーバーのホスト名またはドメイン名に対応します。
UAs MAY support the signing and encrypting of MIME bodies, and transference of credentials with S/MIME as described in Section 23. If a UA holds one or more root certificates of certificate authorities in order to validate certificates for TLS or IPSec, it SHOULD be capable of reusing these to verify S/MIME certificates, as appropriate. A UA MAY hold root certificates specifically for validating S/MIME certificates.
UAs MAY support the signing and encrypting of MIME bodies, and transference of credentials with S/MIME as described in Section 23. If a UA holds one or more root certificates of certificate authorities in order to validate certificates for TLS or IPSec, it SHOULD be capable of reusing these to verify S/MIME certificates, as appropriate. A UA MAY hold root certificates specifically for validating S/MIME certificates.
Note that is it anticipated that future security extensions may upgrade the normative strength associated with S/MIME as S/MIME implementations appear and the problem space becomes better understood.
Note that is it anticipated that future security extensions may upgrade the normative strength associated with S/MIME as S/MIME implementations appear and the problem space becomes better understood.
The operation of these security mechanisms in concert can follow the existing web and email security models to some degree. At a high level, UAs authenticate themselves to servers (proxy servers, redirect servers, and registrars) with a Digest username and password; servers authenticate themselves to UAs one hop away, or to another server one hop away (and vice versa), with a site certificate delivered by TLS.
これらのセキュリティメカニズムの協調動作は、既存のWebおよび電子メールのセキュリティモデルにある程度従うことができます。高レベルでは、UAはダイジェストのユーザー名とパスワードを使用してサーバー（プロキシサーバー、リダイレクトサーバー、およびレジストラー）に対して自分自身を認証します。サーバーは、TLSによって配信されるサイト証明書を使用して、1ホップ離れたUAまたは1ホップ離れた別のサーバー（またはその逆）に対して自分自身を認証します。
On a peer-to-peer level, UAs trust the network to authenticate one another ordinarily; however, S/MIME can also be used to provide direct authentication when the network does not, or if the network itself is not trusted.
ピアツーピアレベルでは、UAは通常、ネットワークを信頼して相互に認証します。ただし、S / MIMEは、ネットワークがそうでない場合、またはネットワーク自体が信頼されていない場合に、直接認証を提供するために使用することもできます。
The following is an illustrative example in which these security mechanisms are used by various UAs and servers to prevent the sorts of threats described in Section 26.1. While implementers and network administrators MAY follow the normative guidelines given in the remainder of this section, these are provided only as example implementations.
以下は、これらのセキュリティメカニズムがセクション26.1で説明されている種類の脅威を防止するためにさまざまなUAおよびサーバーによって使用される例証的な例です。実装者とネットワーク管理者は、このセクションの残りの部分で提供される規範的なガイドラインに従う場合がありますが、これらは実装例としてのみ提供されています。
When a UA comes online and registers with its local administrative domain, it SHOULD establish a TLS connection with its registrar (Section 10 describes how the UA reaches its registrar). The registrar SHOULD offer a certificate to the UA, and the site identified by the certificate MUST correspond with the domain in which the UA intends to register; for example, if the UA intends to register the address-of-record 'alice@atlanta.com', the site certificate must identify a host within the atlanta.com domain (such as sip.atlanta.com). When it receives the TLS Certificate message, the UA SHOULD verify the certificate and inspect the site identified by the certificate. If the certificate is invalid, revoked, or if it does not identify the appropriate party, the UA MUST NOT send the REGISTER message and otherwise proceed with the registration.
UAがオンラインになり、そのローカル管理ドメインに登録されると、レジストラとのTLS接続を確立する必要があります（セクション10では、UAがレジストラに到達する方法を説明しています）。レジストラはUAに証明書を提供する必要があり（SHOULD）、証明書によって識別されるサイトは、UAが登録する予定のドメインに対応している必要があります。たとえば、UAがレコードのアドレス「alice@atlanta.com」を登録する場合、サイト証明書はatlanta.comドメイン内のホスト（sip.atlanta.comなど）を識別する必要があります。 TLS証明書メッセージを受信すると、UAは証明書を検証し、証明書によって識別されるサイトを検査する必要があります（SHOULD）。証明書が無効である、失効している、または適切な当事者を識別できない場合、UAはREGISTERメッセージを送信してはならず、それ以外の場合は登録を続行してはなりません。
When a valid certificate has been provided by the registrar, the UA knows that the registrar is not an attacker who might redirect the UA, steal passwords, or attempt any similar attacks.
レジストラから有効な証明書が提供されると、UAは、レジストラがUAをリダイレクトしたり、パスワードを盗んだり、同様の攻撃を試みたりする可能性のある攻撃者ではないことを認識します。
The UA then creates a REGISTER request that SHOULD be addressed to a Request-URI corresponding to the site certificate received from the registrar. When the UA sends the REGISTER request over the existing TLS connection, the registrar SHOULD challenge the request with a 401 (Proxy Authentication Required) response. The "realm" parameter within the Proxy-Authenticate header field of the response SHOULD correspond to the domain previously given by the site certificate. When the UAC receives the challenge, it SHOULD either prompt the user for credentials or take an appropriate credential from a keyring corresponding to the "realm" parameter in the challenge. The username of this credential SHOULD correspond with the "userinfo" portion of the URI in the To header field of the REGISTER request. Once the Digest credentials have been inserted into an appropriate Proxy-Authorization header field, the REGISTER should be resubmitted to the registrar.
The UA then creates a REGISTER request that SHOULD be addressed to a Request-URI corresponding to the site certificate received from the registrar. When the UA sends the REGISTER request over the existing TLS connection, the registrar SHOULD challenge the request with a 401 (Proxy Authentication Required) response. The "realm" parameter within the Proxy-Authenticate header field of the response SHOULD correspond to the domain previously given by the site certificate. When the UAC receives the challenge, it SHOULD either prompt the user for credentials or take an appropriate credential from a keyring corresponding to the "realm" parameter in the challenge. The username of this credential SHOULD correspond with the "userinfo" portion of the URI in the To header field of the REGISTER request. Once the Digest credentials have been inserted into an appropriate Proxy-Authorization header field, the REGISTER should be resubmitted to the registrar.
Since the registrar requires the user agent to authenticate itself, it would be difficult for an attacker to forge REGISTER requests for the user's address-of-record. Also note that since the REGISTER is sent over a confidential TLS connection, attackers will not be able to intercept the REGISTER to record credentials for any possible replay attack.
Since the registrar requires the user agent to authenticate itself, it would be difficult for an attacker to forge REGISTER requests for the user's address-of-record. Also note that since the REGISTER is sent over a confidential TLS connection, attackers will not be able to intercept the REGISTER to record credentials for any possible replay attack.
Once the registration has been accepted by the registrar, the UA SHOULD leave this TLS connection open provided that the registrar also acts as the proxy server to which requests are sent for users in this administrative domain. The existing TLS connection will be reused to deliver incoming requests to the UA that has just completed registration.
レジストラが登録を受け入れると、UAはこのTLS接続を開いたままにする必要があります。ただし、レジストラが、この管理ドメインのユーザーに要求を送信するプロキシサーバーとしても機能する場合に限ります。登録を完了したばかりのUAに着信要求を配信するために、既存のTLS接続が再利用されます。
Because the UA has already authenticated the server on the other side of the TLS connection, all requests that come over this connection are known to have passed through the proxy server - attackers cannot create spoofed requests that appear to have been sent through that proxy server.
UAはTLS接続の反対側のサーバーを既に認証しているため、この接続を介して送信されるすべての要求はプロキシサーバーを通過したことがわかります。攻撃者は、そのプロキシサーバーを介して送信されたように見える偽の要求を作成できません。
Now let's say that Alice's UA would like to initiate a session with a user in a remote administrative domain, namely "bob@biloxi.com". We will also say that the local administrative domain (atlanta.com) has a local outbound proxy.
ここで、アリスのUAがリモート管理ドメイン、つまり「bob@biloxi.com」のユーザーとのセッションを開始したいとします。また、ローカル管理ドメイン（atlanta.com）にはローカルアウトバウンドプロキシがあると言います。
The proxy server that handles inbound requests for an administrative domain MAY also act as a local outbound proxy; for simplicity's sake we'll assume this to be the case for atlanta.com (otherwise the user agent would initiate a new TLS connection to a separate server at this point). Assuming that the client has completed the registration process described in the preceding section, it SHOULD reuse the TLS connection to the local proxy server when it sends an INVITE request to another user. The UA SHOULD reuse cached credentials in the INVITE to avoid prompting the user unnecessarily.
管理ドメインのインバウンド要求を処理するプロキシサーバーは、ローカルのアウトバウンドプロキシとしても機能する場合があります。簡単にするために、これはatlanta.comの場合であると想定します（そうでない場合、ユーザーエージェントはこの時点で別のサーバーへの新しいTLS接続を開始します）。クライアントが前のセクションで説明した登録プロセスを完了したと仮定すると、別のユーザーにINVITE要求を送信するときに、ローカルプロキシサーバーへのTLS接続を再利用する必要があります（SHOULD）。 UAは、ユーザーに不必要にプロンプトを表示しないように、INVITEでキャッシュされた資格情報を再利用する必要があります（SHOULD）。
When the local outbound proxy server has validated the credentials presented by the UA in the INVITE, it SHOULD inspect the Request-URI to determine how the message should be routed (see [4]). If the "domainname" portion of the Request-URI had corresponded to the local domain (atlanta.com) rather than biloxi.com, then the proxy server would have consulted its location service to determine how best to reach the requested user.
ローカルアウトバウンドプロキシサーバーは、UAがINVITEで提示した資格情報を検証すると、Request-URIを検査して、メッセージのルーティング方法を決定する必要があります（[4]を参照）。 Request-URIの「ドメイン名」部分がbiloxi.comではなくローカルドメイン（atlanta.com）に対応している場合、プロキシサーバーはそのロケーションサービスに問い合わせて、要求されたユーザーに最適な方法で到達する方法を決定します。
Had "alice@atlanta.com" been attempting to contact, say, "alex@atlanta.com", the local proxy would have proxied to the request to the TLS connection Alex had established with the registrar when he registered. Since Alex would receive this request over his authenticated channel, he would be assured that Alice's request had been authorized by the proxy server of the local administrative domain.
Had "alice@atlanta.com" been attempting to contact, say, "alex@atlanta.com", the local proxy would have proxied to the request to the TLS connection Alex had established with the registrar when he registered. Since Alex would receive this request over his authenticated channel, he would be assured that Alice's request had been authorized by the proxy server of the local administrative domain.
However, in this instance the Request-URI designates a remote domain. The local outbound proxy server at atlanta.com SHOULD therefore establish a TLS connection with the remote proxy server at biloxi.com. Since both of the participants in this TLS connection are servers that possess site certificates, mutual TLS authentication SHOULD occur. Each side of the connection SHOULD verify and inspect the certificate of the other, noting the domain name that appears in the certificate for comparison with the header fields of SIP messages. The atlanta.com proxy server, for example, SHOULD verify at this stage that the certificate received from the remote side corresponds with the biloxi.com domain. Once it has done so, and TLS negotiation has completed, resulting in a secure channel between the two proxies, the atlanta.com proxy can forward the INVITE request to biloxi.com.
ただし、この場合、Request-URIはリモートドメインを指定します。したがって、atlanta.comのローカル送信プロキシサーバーは、biloxi.comのリモートプロキシサーバーとのTLS接続を確立する必要があります（SHOULD）。このTLS接続の参加者は両方ともサイト証明書を所有するサーバーであるため、相互TLS認証が発生する必要があります（SHOULD）。接続の各サイドは、SIPメッセージのヘッダーフィールドと比較するために証明書に表示されるドメイン名に注意して、もう一方の証明書を検証および検査する必要があります（SHOULD）。たとえば、atlanta.comプロキシサーバーは、リモート側から受信した証明書がbiloxi.comドメインに対応していることをこの段階で確認する必要があります（SHOULD）。完了すると、TLSネゴシエーションが完了し、2つのプロキシ間に安全なチャネルが作成されると、atlanta.comプロキシはINVITE要求をbiloxi.comに転送できます。
The proxy server at biloxi.com SHOULD inspect the certificate of the proxy server at atlanta.com in turn and compare the domain asserted by the certificate with the "domainname" portion of the From header field in the INVITE request. The biloxi proxy MAY have a strict security policy that requires it to reject requests that do not match the administrative domain from which they have been proxied.
The proxy server at biloxi.com SHOULD inspect the certificate of the proxy server at atlanta.com in turn and compare the domain asserted by the certificate with the "domainname" portion of the From header field in the INVITE request. The biloxi proxy MAY have a strict security policy that requires it to reject requests that do not match the administrative domain from which they have been proxied.
Such security policies could be instituted to prevent the SIP equivalent of SMTP 'open relays' that are frequently exploited to generate spam.
このようなセキュリティポリシーは、スパムを生成するために頻繁に悪用されるSMTPの「オープンリレー」に相当するSIPを防止するために制定される可能性があります。
This policy, however, only guarantees that the request came from the domain it ascribes to itself; it does not allow biloxi.com to ascertain how atlanta.com authenticated Alice. Only if biloxi.com has some other way of knowing atlanta.com's authentication policies could it possibly ascertain how Alice proved her identity. biloxi.com might then institute an even stricter policy that forbids requests that come from domains that are not known administratively to share a common authentication policy with biloxi.com.
ただし、このポリシーは、リクエストが自分自身に属するドメインからのものであることを保証するだけです。 biloxi.comがatlanta.comがAliceを認証した方法を確認することはできません。 biloxi.comがatlanta.comの認証ポリシーを知る方法が他にある場合のみ、アリスが自分の身元を証明した方法を確認できます。次に、biloxi.comは、管理上知られていないドメインからのリクエストがbiloxi.comと共通の認証ポリシーを共有することを禁止するさらに厳しいポリシーを制定する場合があります。
Once the INVITE has been approved by the biloxi proxy, the proxy server SHOULD identify the existing TLS channel, if any, associated with the user targeted by this request (in this case "bob@biloxi.com"). The INVITE should be proxied through this channel to Bob. Since the request is received over a TLS connection that had previously been authenticated as the biloxi proxy, Bob knows that the From header field was not tampered with and that atlanta.com has validated Alice, although not necessarily whether or not to trust Alice's identity.
INVITEがbiloxiプロキシによって承認されると、プロキシサーバーは、この要求のターゲットユーザー（この場合は "bob@biloxi.com"）に関連付けられている既存のTLSチャネル（存在する場合）を特定する必要があります（SHOULD）。 INVITEは、このチャネルを介してボブにプロキシされる必要があります。以前はbiloxiプロキシとして認証されていたTLS接続を介して要求が受信されるため、ボブはFromヘッダーフィールドが改ざんされておらず、atlanta.comがAliceを検証したことを知っていますが、必ずしもAliceのIDを信頼するかどうかは関係ありません。
Before they forward the request, both proxy servers SHOULD add a Record-Route header field to the request so that all future requests in this dialog will pass through the proxy servers. The proxy servers can thereby continue to provide security services for the lifetime of this dialog. If the proxy servers do not add themselves to the Record-Route, future messages will pass directly end-to-end between Alice and Bob without any security services (unless the two parties agree on some independent end-to-end security such as S/MIME). In this respect the SIP trapezoid model can provide a nice structure where conventions of agreement between the site proxies can provide a reasonably secure channel between Alice and Bob.
リクエストを転送する前に、両方のプロキシサーバーはRecord-Routeヘッダーフィールドをリクエストに追加する必要があります（SHOULD）。このダイアログの今後のすべてのリクエストがプロキシサーバーを通過するようにします。これにより、プロキシサーバーは、このダイアログの存続期間中、セキュリティサービスを提供し続けることができます。プロキシサーバーがRecord-Routeに自身を追加しない場合、将来のメッセージはセキュリティサービスなしでAliceとBobの間を直接エンドツーエンドで通過します（Sのような独立したエンドツーエンドのセキュリティに2つの当事者が同意しない限り） / MIME）。この点で、SIP台形モデルは、サイトプロキシ間の合意の取り決めにより、アリスとボブの間に適度に安全なチャネルを提供できる優れた構造を提供できます。
An attacker preying on this architecture would, for example, be unable to forge a BYE request and insert it into the signaling stream between Bob and Alice because the attacker has no way of ascertaining the parameters of the session and also because the integrity mechanism transitively protects the traffic between Alice and Bob.
たとえば、このアーキテクチャを利用する攻撃者は、BYEリクエストを偽造してBobとAliceの間のシグナリングストリームに挿入することができません。これは、攻撃者がセッションのパラメータを確認する方法がなく、整合性メカニズムが推移的に保護するためです。アリスとボブの間のトラフィック。
Alternatively, consider a UA asserting the identity "carol@chicago.com" that has no local outbound proxy. When Carol wishes to send an INVITE to "bob@biloxi.com", her UA SHOULD initiate a TLS connection with the biloxi proxy directly (using the mechanism described in [4] to determine how to best to reach the given Request-URI). When her UA receives a certificate from the biloxi proxy, it SHOULD be verified normally before she passes her INVITE across the TLS connection. However, Carol has no means of proving her identity to the biloxi proxy, but she does have a CMS-detached signature over a "message/sip" body in the INVITE. It is unlikely in this instance that Carol would have any credentials in the biloxi.com realm, since she has no formal association with biloxi.com. The biloxi proxy MAY also have a strict policy that precludes it from even bothering to challenge requests that do not have biloxi.com in the "domainname" portion of the From header field - it treats these users as unauthenticated.
または、ローカルアウトバウンドプロキシを持たない "carol@chicago.com"というIDをアサートするUAを検討してください。 CarolがINVITEを "bob@biloxi.com"に送信したい場合、彼女のUAは、biloxiプロキシと直接TLS接続を開始する必要があります（[4]で説明されているメカニズムを使用して、指定されたRequest-URIに到達する最善の方法を決定します）。 。彼女のUAがbiloxiプロキシから証明書を受け取ったら、TLS接続を介してINVITEを渡す前に、それを通常どおり検証する必要があります。ただし、キャロルには自分のIDをビロキシプロキシに証明する手段はありませんが、INVITEの「メッセージ/ SIP」本文にCMS分離の署名があります。このインスタンスでは、キャロルはbiloxi.comと正式な関係がないため、biloxi.comレルムで資格を取得することはほとんどありません。 biloxiプロキシには、Fromヘッダーフィールドの「domainname」部分にbiloxi.comが含まれていないリクエストに挑戦することさえ禁止する厳密なポリシーがあります-これらのユーザーを認証されていないものとして扱います。
The biloxi proxy has a policy for Bob that all non-authenticated requests should be redirected to the appropriate contact address registered against 'bob@biloxi.com', namely <sip:bob@192.0.2.4>. Carol receives the redirection response over the TLS connection she established with the biloxi proxy, so she trusts the veracity of the contact address.
biloxiプロキシには、認証されていないすべてのリクエストを「bob@biloxi.com」に対して登録された適切な連絡先アドレス、つまり<sip：bob@192.0.2.4>にリダイレクトするというボブのポリシーがあります。 Carolは、biloxiプロキシで確立したTLS接続を介してリダイレクト応答を受信するため、連絡先アドレスの信憑性を信頼します。
Carol SHOULD then establish a TCP connection with the designated address and send a new INVITE with a Request-URI containing the received contact address (recomputing the signature in the body as the request is readied). Bob receives this INVITE on an insecure interface, but his UA inspects and, in this instance, recognizes the From header field of the request and subsequently matches a locally cached certificate with the one presented in the signature of the body of the INVITE. He replies in similar fashion, authenticating himself to Carol, and a secure dialog begins.
キャロルは次に、指定されたアドレスとのTCP接続を確立し、受信した連絡先アドレスを含むRequest-URIを使用して新しいINVITEを送信する必要があります（要求が準備されると、本文の署名を再計算します）。ボブは安全でないインターフェイスでこのINVITEを受信しますが、彼のUAは検査し、この例では、要求のFromヘッダーフィールドを認識して、ローカルにキャッシュされた証明書をINVITEの本文の署名で提示された証明書と照合します。彼は同様の方法で応答し、Carolに対して自分自身を認証し、安全なダイアログが始まります。
Sometimes firewalls or NATs in an administrative domain could preclude the establishment of a direct TCP connection to a UA. In these cases, proxy servers could also potentially relay requests to UAs in a way that has no trust implications (for example, forgoing an existing TLS connection and forwarding the request over cleartext TCP) as local policy dictates.
場合によっては、管理ドメイン内のファイアウォールまたはNATが、UAへの直接TCP接続の確立を妨げることがあります。これらの場合、プロキシサーバーは、ローカルポリシーの指示に従って、信頼関係のない方法（たとえば、既存のTLS接続を放棄し、クリアテキストTCP経由で要求を転送する）で要求をUAに中継する可能性もあります。
In order to minimize the risk of a denial-of-service attack against architectures using these security solutions, implementers should take note of the following guidelines.
これらのセキュリティソリューションを使用するアーキテクチャに対するサービス拒否攻撃のリスクを最小限に抑えるために、実装者は次のガイドラインに注意する必要があります。
When the host on which a SIP proxy server is operating is routable from the public Internet, it SHOULD be deployed in an administrative domain with defensive operational policies (blocking source-routed traffic, preferably filtering ping traffic). Both TLS and IPSec can also make use of bastion hosts at the edges of administrative domains that participate in the security associations to aggregate secure tunnels and sockets. These bastion hosts can also take the brunt of denial-of-service attacks, ensuring that SIP hosts within the administrative domain are not encumbered with superfluous messaging.
SIPプロキシサーバーが動作しているホストがパブリックインターネットからルーティング可能な場合、防御的な運用ポリシー（ソースルートトラフィックのブロック、できればpingトラフィックのフィルタリング）を使用して管理ドメインに展開する必要があります（SHOULD）。 TLSとIPSecはどちらも、セキュリティアソシエーションに参加する管理ドメインのエッジにある要塞ホストを利用して、安全なトンネルとソケットを集約できます。これらの要塞ホストは、サービス拒否攻撃の真っ先にかかる可能性もあり、管理ドメイン内のSIPホストが余分なメッセージングに邪魔されないようにします。
No matter what security solutions are deployed, floods of messages directed at proxy servers can lock up proxy server resources and prevent desirable traffic from reaching its destination. There is a computational expense associated with processing a SIP transaction at a proxy server, and that expense is greater for stateful proxy servers than it is for stateless proxy servers. Therefore, stateful proxies are more susceptible to flooding than stateless proxy servers.
導入されているセキュリティソリューションに関係なく、プロキシサーバーに向けられた大量のメッセージは、プロキシサーバーのリソースをロックし、望ましいトラフィックが宛先に到達するのを妨げます。プロキシサーバーでのSIPトランザクションの処理に関連する計算費用があり、その費用はステートレスプロキシサーバーの場合よりステートフルプロキシサーバーの方が高くなります。したがって、ステートフルプロキシは、ステートレスプロキシサーバーよりもフラッディングの影響を受けやすくなります。
UAs and proxy servers SHOULD challenge questionable requests with only a single 401 (Unauthorized) or 407 (Proxy Authentication Required), forgoing the normal response retransmission algorithm, and thus behaving statelessly towards unauthenticated requests.
UAs and proxy servers SHOULD challenge questionable requests with only a single 401 (Unauthorized) or 407 (Proxy Authentication Required), forgoing the normal response retransmission algorithm, and thus behaving statelessly towards unauthenticated requests.
Retransmitting the 401 (Unauthorized) or 407 (Proxy Authentication Required) status response amplifies the problem of an attacker using a falsified header field value (such as Via) to direct traffic to a third party.
401（Unauthorized）または407（Proxy Authentication Required）ステータス応答を再送信すると、攻撃者が偽のヘッダーフィールド値（Viaなど）を使用してトラフィックをサードパーティに転送するという問題が増幅します。
In summary, the mutual authentication of proxy servers through mechanisms such as TLS significantly reduces the potential for rogue intermediaries to introduce falsified requests or responses that can deny service. This commensurately makes it harder for attackers to make innocent SIP nodes into agents of amplification.
要約すると、TLSなどのメカニズムを介したプロキシサーバーの相互認証により、不正な仲介者がサービスを拒否する可能性のある要求または応答を改ざんする可能性が大幅に減少します。これにより、攻撃者が無実のSIPノードを増幅のエージェントにすることが難しくなります。
Although these security mechanisms, when applied in a judicious manner, can thwart many threats, there are limitations in the scope of the mechanisms that must be understood by implementers and network operators.
これらのセキュリティメカニズムを慎重に適用すると、多くの脅威を阻止できますが、実装者とネットワークオペレーターが理解する必要のあるメカニズムの範囲には制限があります。
One of the primary limitations of using HTTP Digest in SIP is that the integrity mechanisms in Digest do not work very well for SIP. Specifically, they offer protection of the Request-URI and the method of a message, but not for any of the header fields that UAs would most likely wish to secure.
SIPでHTTPダイジェストを使用する場合の主な制限の1つは、ダイジェストの整合性メカニズムがSIPでうまく機能しないことです。具体的には、Request-URIとメッセージのメソッドの保護を提供しますが、UAが保護する可能性が最も高いヘッダーフィールドは保護しません。
The existing replay protection mechanisms described in RFC 2617 also have some limitations for SIP. The next-nonce mechanism, for example, does not support pipelined requests. The nonce-count mechanism should be used for replay protection.
RFC 2617で説明されている既存のリプレイ保護メカニズムにも、SIPに関するいくつかの制限があります。たとえば、next-nonceメカニズムはパイプライン化されたリクエストをサポートしていません。 nonce-countメカニズムをリプレイ保護に使用する必要があります。
Another limitation of HTTP Digest is the scope of realms. Digest is valuable when a user wants to authenticate themselves to a resource with which they have a pre-existing association, like a service provider of which the user is a customer (which is quite a common scenario and thus Digest provides an extremely useful function). By way of contrast, the scope of TLS is interdomain or multirealm, since certificates are often globally verifiable, so that the UA can authenticate the server with no pre-existing association.
HTTPダイジェストのもう1つの制限は、レルムのスコープです。ダイジェストは、ユーザーが顧客であるサービスプロバイダーなど、既存の関連付けがあるリソースに対してユーザーが自分自身を認証したい場合に役立ちます（これは非常に一般的なシナリオであり、ダイジェストは非常に便利な機能を提供します）。 。対照的に、証明書はしばしばグローバルに検証可能であるため、TLSのスコープはドメイン間またはマルチレルムです。これにより、UAは既存の関連付けなしでサーバーを認証できます。
The largest outstanding defect with the S/MIME mechanism is the lack of a prevalent public key infrastructure for end users. If self-signed certificates (or certificates that cannot be verified by one of the participants in a dialog) are used, the SIP-based key exchange mechanism described in Section 23.2 is susceptible to a man-in-the-middle attack with which an attacker can potentially inspect and modify S/MIME bodies. The attacker needs to intercept the first exchange of keys between the two parties in a dialog, remove the existing CMS-detached signatures from the request and response, and insert a different CMS-detached signature containing a certificate supplied by the attacker (but which seems to be a certificate for the proper address-of-record). Each party will think they have exchanged keys with the other, when in fact each has the public key of the attacker.
S / MIMEメカニズムの最大の未解決の欠点は、エンドユーザーに普及している公開キーインフラストラクチャがないことです。自己署名証明書（またはダイアログの参加者の1人が検証できない証明書）が使用されている場合、セクション23.2で説明されているSIPベースの鍵交換メカニズムは、中間者攻撃の影響を受けやすくなります。攻撃者はS / MIME本文を検査および変更する可能性があります。攻撃者は、ダイアログで2者間の最初のキー交換を傍受し、既存のCMS分離署名を要求と応答から削除し、攻撃者から提供された証明書を含む別のCMS分離署名を挿入する必要があります（ただし、適切なレコードのアドレスの証明書であること）。各当事者は、実際にはそれぞれが攻撃者の公開鍵を持っている場合でも、お互いに鍵を交換したと考えます。
It is important to note that the attacker can only leverage this vulnerability on the first exchange of keys between two parties - on subsequent occasions, the alteration of the key would be noticeable to the UAs. It would also be difficult for the attacker to remain in the path of all future dialogs between the two parties over time (as potentially days, weeks, or years pass).
It is important to note that the attacker can only leverage this vulnerability on the first exchange of keys between two parties - on subsequent occasions, the alteration of the key would be noticeable to the UAs. It would also be difficult for the attacker to remain in the path of all future dialogs between the two parties over time (as potentially days, weeks, or years pass).
SSH is susceptible to the same man-in-the-middle attack on the first exchange of keys; however, it is widely acknowledged that while SSH is not perfect, it does improve the security of connections. The use of key fingerprints could provide some assistance to SIP, just as it does for SSH. For example, if two parties use SIP to establish a voice communications session, each could read off the fingerprint of the key they received from the other, which could be compared against the original. It would certainly be more difficult for the man-in-the-middle to emulate the voices of the participants than their signaling (a practice that was used with the Clipper chip-based secure telephone).
SSHは、鍵の最初の交換で同じ中間者攻撃を受けやすい。ただし、SSHは完璧ではありませんが、接続のセキュリティが向上することは広く認められています。キーフィンガープリントを使用すると、SSHの場合と同様に、SIPにいくつかの支援を提供できます。たとえば、2つのパーティがSIPを使用して音声通信セッションを確立する場合、それぞれが他方から受信したキーのフィンガープリントを読み取ることができ、それをオリジナルと比較することができます。中間者が参加者の声をエミュレートすることは、彼らのシグナリング（クリッパーチップベースの安全な電話で使用されていた方法）よりも確かに困難です。
The S/MIME mechanism allows UAs to send encrypted requests without preamble if they possess a certificate for the destination address-of-record on their keyring. However, it is possible that any particular device registered for an address-of-record will not hold the certificate that has been previously employed by the device's current user, and that it will therefore be unable to process an encrypted request properly, which could lead to some avoidable error signaling. This is especially likely when an encrypted request is forked.
S / MIMEメカニズムにより、UAは、キーリング上の宛先レコードのアドレスの証明書を所有している場合、プリアンブルなしで暗号化された要求を送信できます。ただし、レコードのアドレスに登録された特定のデバイスは、デバイスの現在のユーザーが以前に使用した証明書を保持していない可能性があるため、暗号化された要求を適切に処理できず、一部の回避可能なエラー信号に。これは、暗号化されたリクエストがフォークされた場合に特に発生しやすくなります。
The keys associated with S/MIME are most useful when associated with a particular user (an address-of-record) rather than a device (a UA). When users move between devices, it may be difficult to transport private keys securely between UAs; how such keys might be acquired by a device is outside the scope of this document.
S / MIMEに関連付けられているキーは、デバイス（UA）ではなく特定のユーザー（レコードのアドレス）に関連付けられている場合に最も役立ちます。ユーザーがデバイス間を移動すると、プライベートキーをUA間で安全に転送することが困難になる場合があります。このようなキーがデバイスによって取得される方法は、このドキュメントの範囲外です。
Another, more prosaic difficulty with the S/MIME mechanism is that it can result in very large messages, especially when the SIP tunneling mechanism described in Section 23.4 is used. For that reason, it is RECOMMENDED that TCP should be used as a transport protocol when S/MIME tunneling is employed.
S / MIMEメカニズムのもう1つのより一般的な問題は、特にセクション23.4で説明されているSIPトンネリングメカニズムが使用されている場合に、非常に大きなメッセージになる可能性があることです。そのため、S / MIMEトンネリングを使用する場合は、トランスポートプロトコルとしてTCPを使用することをお勧めします。
The most commonly voiced concern about TLS is that it cannot run over UDP; TLS requires a connection-oriented underlying transport protocol, which for the purposes of this document means TCP.
TLSに関して最もよく言われる懸念は、それがUDP上で実行できないことです。 TLSには、接続指向の基礎となるトランスポートプロトコルが必要です。このドキュメントでは、TCPを意味します。
It may also be arduous for a local outbound proxy server and/or registrar to maintain many simultaneous long-lived TLS connections with numerous UAs. This introduces some valid scalability concerns, especially for intensive ciphersuites. Maintaining redundancy of long-lived TLS connections, especially when a UA is solely responsible for their establishment, could also be cumbersome.
また、ローカルのアウトバウンドプロキシサーバーやレジストラが、多数のUAとの多数の同時長寿命TLS接続を維持するのは困難な場合もあります。これは、特に集中的な暗号スイートに対して、いくつかの有効なスケーラビリティの懸念をもたらします。特にUAがその確立に単独で責任を負う場合、長寿命のTLS接続の冗長性を維持することも面倒な場合があります。
TLS only allows SIP entities to authenticate servers to which they are adjacent; TLS offers strictly hop-by-hop security. Neither TLS, nor any other mechanism specified in this document, allows clients to authenticate proxy servers to whom they cannot form a direct TCP connection.
TLSは、SIPエンティティが隣接するサーバーを認証することのみを許可します。 TLSは、厳密にホップバイホップのセキュリティを提供します。 TLSも、このドキュメントで指定されている他のメカニズムも、クライアントが直接TCP接続を形成できないプロキシサーバーを認証することを許可していません。
Actually using TLS on every segment of a request path entails that the terminating UAS must be reachable over TLS (perhaps registering with a SIPS URI as a contact address). This is the preferred use of SIPS. Many valid architectures, however, use TLS to secure part of the request path, but rely on some other mechanism for the final hop to a UAS, for example. Thus SIPS cannot guarantee that TLS usage will be truly end-to-end. Note that since many UAs will not accept incoming TLS connections, even those UAs that do support TLS may be required to maintain persistent TLS connections as described in the TLS limitations section above in order to receive requests over TLS as a UAS.
要求パスのすべてのセグメントで実際にTLSを使用するには、終端のUASがTLS経由で到達可能でなければならない（おそらくSIPS URIを連絡先アドレスとして登録する）。これはSIPSの推奨される使用法です。ただし、有効なアーキテクチャの多くはTLSを使用してリクエストパスの一部を保護しますが、たとえばUASへの最終ホップは他のメカニズムに依存しています。したがってSIPSは、TLSの使用が真にエンドツーエンドであることを保証できません。多くのUAは着信TLS接続を受け入れないため、TLSを介してリクエストをUASとして受信するために、TLSをサポートするUAでも永続的なTLS接続を維持する必要がある場合があることに注意してください。
Location services are not required to provide a SIPS binding for a SIPS Request-URI. Although location services are commonly populated by user registrations (as described in Section 10.2.1), various other protocols and interfaces could conceivably supply contact addresses for an AOR, and these tools are free to map SIPS URIs to SIP URIs as appropriate. When queried for bindings, a location service returns its contact addresses without regard for whether it received a request with a SIPS Request-URI. If a redirect server is accessing the location service, it is up to the entity that processes the Contact header field of a redirection to determine the propriety of the contact addresses.
位置情報サービスは、SIPSリクエストURIにSIPSバインディングを提供する必要はありません。ロケーションサービスは一般にユーザー登録によって入力されますが（セクション10.2.1で説明）、他のさまざまなプロトコルおよびインターフェースがAORの連絡先アドレスを提供する可能性があり、これらのツールはSIPS URIをSIP URIに適宜マップできます。バインディングのクエリを実行すると、ロケーションサービスはSIPSリクエストURIでリクエストを受信したかどうかに関係なく、連絡先アドレスを返します。リダイレクトサーバーがロケーションサービスにアクセスしている場合、リダイレクトの連絡先ヘッダーフィールドを処理して連絡先アドレスの妥当性を判断するのは、エンティティ次第です。
Ensuring that TLS will be used for all of the request segments up to the target domain is somewhat complex. It is possible that cryptographically authenticated proxy servers along the way that are non-compliant or compromised may choose to disregard the forwarding rules associated with SIPS (and the general forwarding rules in Section 16.6). Such malicious intermediaries could, for example, retarget a request from a SIPS URI to a SIP URI in an attempt to downgrade security.
ターゲットドメインまでのすべてのリクエストセグメントにTLSが使用されるようにすることは、やや複雑です。非準拠または侵害された途中の暗号化されたプロキシサーバーがSIPSに関連付けられた転送ルール（およびセクション16.6の一般的な転送ルール）を無視することを選択する可能性があります。このような悪意のある仲介者は、たとえば、セキュリティをダウングレードしようとして、要求をSIPS URIからSIP URIにリターゲットする可能性があります。
Alternatively, an intermediary might legitimately retarget a request from a SIP to a SIPS URI. Recipients of a request whose Request-URI uses the SIPS URI scheme thus cannot assume on the basis of the Request-URI alone that SIPS was used for the entire request path (from the client onwards).
または、仲介者がSIPからSIPS URIにリクエストを合法的にリターゲットする場合もあります。したがって、Request-URIがSIPS URIスキームを使用する要求の受信者は、Request-URIのみに基づいて、（クライアントからの）要求パス全体にSIPSが使用されたと想定できません。
To address these concerns, it is RECOMMENDED that recipients of a request whose Request-URI contains a SIP or SIPS URI inspect the To header field value to see if it contains a SIPS URI (though note that it does not constitute a breach of security if this URI has the same scheme but is not equivalent to the URI in the To header field). Although clients may choose to populate the Request-URI and To header field of a request differently, when SIPS is used this disparity could be interpreted as a possible security violation, and the request could consequently be rejected by its recipient. Recipients MAY also inspect the Via header chain in order to double-check whether or not TLS was used for the entire request path until the local administrative domain was reached. S/MIME may also be used by the originating UAC to help ensure that the original form of the To header field is carried end-to-end.
これらの懸念に対処するには、Request-URIにSIPまたはSIPS URIが含まれるリクエストの受信者がToヘッダーフィールドの値を調べてSIPS URIが含まれているかどうかを確認することをお勧めします（ただし、次の場合はセキュリティ違反にはなりません。このURIのスキームは同じですが、ToヘッダーフィールドのURIとは異なります）。クライアントは要求のRequest-URIおよびToヘッダーフィールドに異なる方法で入力することを選択できますが、SIPSが使用される場合、この不一致はセキュリティ違反の可能性として解釈され、その結果、要求は受信者によって拒否される可能性があります。受信者は、ローカル管理ドメインに到達するまで、要求パス全体にTLSが使用されたかどうかを再確認するために、Viaヘッダーチェーンを検査することもできます（MAY）。 S / MIMEは、元のUACでも使用され、元の形式のToヘッダーフィールドがエンドツーエンドで確実に伝達されるようにします。
If the UAS has reason to believe that the scheme of the Request-URI has been improperly modified in transit, the UA SHOULD notify its user of a potential security breach.
UASがRequest-URIのスキームが転送中に不適切に変更されたと信じる理由がある場合、UAはユーザーに潜在的なセキュリティ違反を通知する必要があります（SHOULD）。
As a further measure to prevent downgrade attacks, entities that accept only SIPS requests MAY also refuse connections on insecure ports.
ダウングレード攻撃を防ぐためのさらなる手段として、SIPSリクエストのみを受け入れるエンティティは、安全でないポートでの接続も拒否する場合があります。
End users will undoubtedly discern the difference between SIPS and SIP URIs, and they may manually edit them in response to stimuli. This can either benefit or degrade security. For example, if an attacker corrupts a DNS cache, inserting a fake record set that effectively removes all SIPS records for a proxy server, then any SIPS requests that traverse this proxy server may fail. When a user, however, sees that repeated calls to a SIPS AOR are failing, they could on some devices manually convert the scheme from SIPS to SIP and retry. Of course, there are some safeguards against this (if the destination UA is truly paranoid it could refuse all non-SIPS requests), but it is a limitation worth noting. On the bright side, users might also divine that 'SIPS' would be valid even when they are presented only with a SIP URI.
エンドユーザーは間違いなくSIPSとSIP URIの違いを認識し、刺激に応じて手動で編集することができます。これは、セキュリティを向上または低下させる可能性があります。たとえば、攻撃者がDNSキャッシュを破損し、プロキシサーバーのすべてのSIPSレコードを効果的に削除する偽のレコードセットを挿入すると、このプロキシサーバーを通過するSIPS要求は失敗する可能性があります。ただし、ユーザーがSIPS AORへの繰り返し呼び出しが失敗していることを確認すると、一部のデバイスでは手動でスキームをSIPSからSIPに変換して再試行できます。もちろん、これに対するいくつかの保護策があります（宛先UAが本当に偏執狂的である場合、SIPS以外のすべての要求を拒否する可能性があります）が、これは注目に値する制限です。明るい面を言えば、ユーザーは、SIP URIのみが提示されている場合でも「SIPS」が有効であることを理解するかもしれません。
SIP messages frequently contain sensitive information about their senders - not just what they have to say, but with whom they communicate, when they communicate and for how long, and from where they participate in sessions. Many applications and their users require that this sort of private information be hidden from any parties that do not need to know it.
SIPメッセージには、送信者に関する機密情報が含まれていることがよくあります。送信者の発言だけでなく、通信相手、通信時間、通信時間、セッションのどこから参加したかなどです。多くのアプリケーションとそのユーザーは、この種の個人情報を、知る必要のない関係者から隠すことを要求しています。
Note that there are also less direct ways in which private information can be divulged. If a user or service chooses to be reachable at an address that is guessable from the person's name and organizational affiliation (which describes most addresses-of-record), the traditional method of ensuring privacy by having an unlisted "phone number" is compromised. A user location service can infringe on the privacy of the recipient of a session invitation by divulging their specific whereabouts to the caller; an implementation consequently SHOULD be able to restrict, on a per-user basis, what kind of location and availability information is given out to certain classes of callers. This is a whole class of problem that is expected to be studied further in ongoing SIP work.
Note that there are also less direct ways in which private information can be divulged. If a user or service chooses to be reachable at an address that is guessable from the person's name and organizational affiliation (which describes most addresses-of-record), the traditional method of ensuring privacy by having an unlisted "phone number" is compromised. A user location service can infringe on the privacy of the recipient of a session invitation by divulging their specific whereabouts to the caller; an implementation consequently SHOULD be able to restrict, on a per-user basis, what kind of location and availability information is given out to certain classes of callers. This is a whole class of problem that is expected to be studied further in ongoing SIP work.
In some cases, users may want to conceal personal information in header fields that convey identity. This can apply not only to the From and related headers representing the originator of the request, but also the To - it may not be appropriate to convey to the final destination a speed-dialing nickname, or an unexpanded identifier for a group of targets, either of which would be removed from the Request-URI as the request is routed, but not changed in the To header field if the two were initially identical. Thus it MAY be desirable for privacy reasons to create a To header field that differs from the Request-URI.
場合によっては、ユーザーは、身元を伝えるヘッダーフィールドに個人情報を隠したいことがあります。これは、要求の発信元を表すFromヘッダーと関連ヘッダーだけでなく、Toにも適用できます。最終宛先にスピードダイヤルニックネーム、またはターゲットのグループの拡張されていない識別子を伝えることは適切でない場合があります。どちらも、リクエストがルーティングされるときにRequest-URIから削除されますが、2つが最初は同じである場合は、Toヘッダーフィールドで変更されません。したがって、プライバシー上の理由から、Request-URIとは異なるToヘッダーフィールドを作成することが望ましい場合があります。
27 IANA Considerations
27 IANAに関する考慮事項
All method names, header field names, status codes, and option tags used in SIP applications are registered with IANA through instructions in an IANA Considerations section in an RFC.
SIPアプリケーションで使用されるすべてのメソッド名、ヘッダーフィールド名、ステータスコード、およびオプションタグは、RFCのIANAに関する考慮事項セクションの指示に従ってIANAに登録されます。
The specification instructs the IANA to create four new sub-registries under http://www.iana.org/assignments/sip-parameters: Option Tags, Warning Codes (warn-codes), Methods and Response Codes, added to the sub-registry of Header Fields that is already present there.
この仕様は、IANAに対して、http：//www.iana.org/assignments/sip-parametersの下に4つの新しいサブレジストリを作成するように指示しています。オプションタグ、警告コード（warn-codes）、メソッドおよび応答コードは、サブすでにそこに存在するヘッダーフィールドのレジストリ。
This specification establishes the Option Tags sub-registry under http://www.iana.org/assignments/sip-parameters.
この仕様は、http：//www.iana.org/assignments/sip-parametersの下にオプションタグサブレジストリを確立します。
Option tags are used in header fields such as Require, Supported, Proxy-Require, and Unsupported in support of SIP compatibility mechanisms for extensions (Section 19.2). The option tag itself is a string that is associated with a particular SIP option (that is, an extension). It identifies the option to SIP endpoints.
オプションタグは、拡張機能のSIP互換性メカニズムをサポートするために、Require、Supported、Proxy-Require、Unsupportedなどのヘッダーフィールドで使用されます（セクション19.2）。オプションタグ自体は、特定のSIPオプション（つまり、拡張機能）に関連付けられている文字列です。 SIPエンドポイントのオプションを識別します。
Option tags are registered by the IANA when they are published in standards track RFCs. The IANA Considerations section of the RFC must include the following information, which appears in the IANA registry along with the RFC number of the publication.
オプションタグは、標準トラックRFCで公開されるときにIANAによって登録されます。 RFCのIANAに関する考慮事項セクションには、次の情報を含める必要があります。これらの情報は、IANAレジストリに、出版物のRFC番号とともに表示されます。
o Name of the option tag. The name MAY be of any length, but SHOULD be no more than twenty characters long. The name MUST consist of alphanum (Section 25) characters only.
o オプションタグの名前。名前は任意の長さにすることができますが、長さは20文字以下にする必要があります。名前は、英数字（セクション25）文字のみで構成する必要があります。
o Descriptive text that describes the extension.
o Descriptive text that describes the extension.
This specification establishes the Warn-codes sub-registry under http://www.iana.org/assignments/sip-parameters and initiates its population with the warn-codes listed in Section 20.43. Additional warn-codes are registered by RFC publication.
この仕様は、http：//www.iana.org/assignments/sip-parametersの下にWarn-codesサブレジストリを確立し、セクション20.43にリストされているwarn-codesでその母集団を開始します。追加の警告コードはRFCの発行によって登録されています。
The descriptive text for the table of warn-codes is:
警告コードの表の説明テキストは次のとおりです。
Warning codes provide information supplemental to the status code in SIP response messages when the failure of the transaction results from a Session Description Protocol (SDP) (RFC 2327 [1]) problem.
警告コードは、トランザクションの失敗の原因がセッション記述プロトコル（SDP）（RFC 2327 [1]）の問題である場合に、SIP応答メッセージのステータスコードを補足する情報を提供します。
The "warn-code" consists of three digits. A first digit of "3" indicates warnings specific to SIP. Until a future specification describes uses of warn-codes other than 3xx, only 3xx warn-codes may be registered.
「警告コード」は3桁で構成されます。最初の数字の「3」は、SIPに固有の警告を示します。将来の仕様で3xx以外の警告コードの使用について説明するまでは、3xx警告コードのみを登録できます。
Warnings 300 through 329 are reserved for indicating problems with keywords in the session description, 330 through 339 are warnings related to basic network services requested in the session description, 370 through 379 are warnings related to quantitative QoS parameters requested in the session description, and 390 through 399 are miscellaneous warnings that do not fall into one of the above categories.
警告300〜329は、セッションの説明のキーワードに関する問題を示すために予約されています。330〜339は、セッションの説明で要求される基本的なネットワークサービスに関連する警告です。370〜379は、セッションの説明で要求される定量的QoSパラメータに関連する警告です。 〜399は、上記のカテゴリのいずれにも該当しないその他の警告です。
This obsoletes the IANA instructions about the header sub-registry under http://www.iana.org/assignments/sip-parameters.
これにより、http：//www.iana.org/assignments/sip-parametersにあるヘッダーサブレジストリに関するIANAの指示が廃止されます。
The following information needs to be provided in an RFC publication in order to register a new header field name:
新しいヘッダーフィールド名を登録するには、RFC出版物で次の情報を提供する必要があります。
o The RFC number in which the header is registered;
o ヘッダーが登録されているRFC番号。
o the name of the header field being registered;
o 登録されているヘッダーフィールドの名前。
o a compact form version for that header field, if one is defined;
o ヘッダーフィールドが定義されている場合、そのヘッダーフィールドのコンパクトフォームバージョン。
Some common and widely used header fields MAY be assigned one-letter compact forms (Section 7.3.3). Compact forms can only be assigned after SIP working group review, followed by RFC publication.
いくつかの一般的で広く使用されているヘッダーフィールドには、1文字のコンパクトフォームを割り当てることができます（セクション7.3.3）。コンパクトフォームは、SIPワーキンググループのレビュー、RFC発行の後にのみ割り当てることができます。
This specification establishes the Method and Response-Code sub-registries under http://www.iana.org/assignments/sip-parameters and initiates their population as follows. The initial Methods table is:
この仕様は、http：//www.iana.org/assignments/sip-parametersの下にMethodおよびResponse-Codeサブレジストリを確立し、次のようにその母集団を開始します。最初のメソッドテーブルは次のとおりです。
INVITE [RFC3261]
ACK [RFC3261]
BYE [RFC3261]
CANCEL [RFC3261]
REGISTER [RFC3261]
OPTIONS [RFC3261]
INFO [RFC2976]
The response code table is initially populated from Section 21, the portions labeled Informational, Success, Redirection, Client-Error, Server-Error, and Global-Failure. The table has the following format:
応答コードテーブルは、最初にセクション21から読み込まれます。これは、情報、成功、リダイレクト、クライアントエラー、サーバーエラー、グローバル失敗のラベルが付けられた部分です。テーブルの形式は次のとおりです。
Type (e.g., Informational) Number Default Reason Phrase [RFC3261]
タイプ（情報など）番号デフォルトの理由フレーズ[RFC3261]
The following information needs to be provided in an RFC publication in order to register a new response code or method:
新しい応答コードまたはメソッドを登録するには、RFC資料で以下の情報を提供する必要があります。
o The RFC number in which the method or response code is registered;
o メソッドまたは応答コードが登録されているRFC番号。
o the number of the response code or name of the method being registered;
o 応答コードの番号または登録されているメソッドの名前。
o the default reason phrase for that response code, if applicable;
o 該当する場合、その応答コードのデフォルトの理由句。
27.5 The "message/sip" MIME type.
27.5 "message / sip" MIMEタイプ。
This document registers the "message/sip" MIME media type in order to allow SIP messages to be tunneled as bodies within SIP, primarily for end-to-end security purposes. This media type is defined by the following information:
このドキュメントでは、主にエンドツーエンドのセキュリティを目的として、SIPメッセージをSIP内のボディとしてトンネリングできるようにするために、「メッセージ/ sip」MIMEメディアタイプを登録します。このメディアタイプは、次の情報によって定義されます。
Media type name: message Media subtype name: sip Required parameters: none
メディアタイプ名：メッセージメディアサブタイプ名：sip必須パラメーター：なし
Optional parameters: version version: The SIP-Version number of the enclosed message (e.g., "2.0"). If not present, the version defaults to "2.0". Encoding scheme: SIP messages consist of an 8-bit header optionally followed by a binary MIME data object. As such, SIP messages must be treated as binary. Under normal circumstances SIP messages are transported over binary-capable transports, no special encodings are needed.
オプションパラメータ：バージョンバージョン：囲まれたメッセージのSIPバージョン番号（例：「2.0」）。存在しない場合、バージョンはデフォルトで「2.0」になります。エンコーディング方式：SIPメッセージは、オプションでバイナリMIMEデータオブジェクトが後に続く8ビットヘッダーで構成されます。そのため、SIPメッセージはバイナリとして処理する必要があります。通常の状況では、SIPメッセージはバイナリ対応のトランスポートを介して転送されるため、特別なエンコーディングは必要ありません。
Security considerations: see below Motivation and examples of this usage as a security mechanism in concert with S/MIME are given in 23.4.
セキュリティに関する考慮事項：下記を参照してください。S/ MIMEと連携したセキュリティメカニズムとしての動機とこの使用例は、23.4に記載されています。
This document also registers four new Content-Disposition header "disposition-types": alert, icon, session and render. The authors request that these values be recorded in the IANA registry for Content-Dispositions.
このドキュメントは、4つの新しいContent-Dispositionヘッダー「disposition-types」も登録しています。アラート、アイコン、セッション、レンダリングです。著者は、これらの値がContent-DispositionsのIANAレジストリに記録されることを要求します。
Descriptions of these "disposition-types", including motivation and examples, are given in Section 20.11.
動機や例を含む、これらの「処分タイプ」の説明は、セクション20.11にあります。
Short descriptions suitable for the IANA registry are:
IANAレジストリに適した簡単な説明は次のとおりです。
alert the body is a custom ring tone to alert the user icon the body is displayed as an icon to the user render the body should be displayed to the user session the body describes a communications session, for example, as RFC 2327 SDP body
本体に警告するカスタムの着信音で、ユーザーに警告するアイコンです。本体はユーザーにアイコンとして表示されます。本体はユーザーセッションに表示されます。本体は通信セッションを記述します。たとえば、RFC 2327 SDP本体などです。
28 Changes From RFC 2543
RFC 2543からの28の変更
This RFC revises RFC 2543. It is mostly backwards compatible with RFC 2543. The changes described here fix many errors discovered in RFC 2543 and provide information on scenarios not detailed in RFC 2543. The protocol has been presented in a more cleanly layered model here.
This RFC revises RFC 2543. It is mostly backwards compatible with RFC 2543. The changes described here fix many errors discovered in RFC 2543 and provide information on scenarios not detailed in RFC 2543. The protocol has been presented in a more cleanly layered model here.
We break the differences into functional behavior that is a substantial change from RFC 2543, which has impact on interoperability or correct operation in some cases, and functional behavior that is different from RFC 2543 but not a potential source of interoperability problems. There have been countless clarifications as well, which are not documented here.
相互運用性または正常な動作に影響を与えるRFC 2543からの大幅な変更である機能動作と、RFC 2543とは異なるが相互運用性の問題の潜在的な原因ではない機能動作に違いを分けます。ここにも記載されていない説明も無数にあります。
o When a UAC wishes to terminate a call before it has been answered, it sends CANCEL. If the original INVITE still returns a 2xx, the UAC then sends BYE. BYE can only be sent on an existing call leg (now called a dialog in this RFC), whereas it could be sent at any time in RFC 2543.
o UACが応答する前にコールを終了したい場合、UACはCANCELを送信します。元のINVITEが引き続き2xxを返す場合、UACはBYEを送信します。 BYEは、既存のコールレッグ（このRFCではダイアログと呼ばれる）でのみ送信できますが、RFC 2543ではいつでも送信できます。
o The SIP BNF was converted to be RFC 2234 compliant.
o The SIP BNF was converted to be RFC 2234 compliant.
o SIP URL BNF was made more general, allowing a greater set of characters in the user part. Furthermore, comparison rules were simplified to be primarily case-insensitive, and detailed handling of comparison in the presence of parameters was described. The most substantial change is that a URI with a parameter with the default value does not match a URI without that parameter.
o SIP URL BNFがより一般的になり、ユーザー部分でより多くの文字セットを使用できるようになりました。さらに、比較ルールは主に大文字と小文字を区別しないように簡略化され、パラメーターが存在する場合の比較の詳細な処理が説明されました。最も重要な変更は、デフォルト値のパラメーターを持つURIが、そのパラメーターのないURIと一致しないことです。
o Removed Via hiding. It had serious trust issues, since it relied on the next hop to perform the obfuscation process. Instead, Via hiding can be done as a local implementation choice in stateful proxies, and thus is no longer documented.
o 非表示を介して削除されました。難読化プロセスの実行はネクストホップに依存していたため、深刻な信頼の問題がありました。代わりに、Viaの非表示は、ステートフルプロキシのローカル実装の選択肢として行うことができるため、ドキュメント化されなくなりました。
o In RFC 2543, CANCEL and INVITE transactions were intermingled. They are separated now. When a user sends an INVITE and then a CANCEL, the INVITE transaction still terminates normally. A UAS needs to respond to the original INVITE request with a 487 response.
o RFC 2543では、CANCELトランザクションとINVITEトランザクションが混在していました。それらは現在分離されています。ユーザーがINVITEを送信してからCANCELを送信しても、INVITEトランザクションは正常に終了します。 UASは、487応答で元のINVITE要求に応答する必要があります。
o Similarly, CANCEL and BYE transactions were intermingled; RFC 2543 allowed the UAS not to send a response to INVITE when a BYE was received. That is disallowed here. The original INVITE needs a response.
o 同様に、CANCELトランザクションとBYEトランザクションが混在していた。 RFC 2543は、BYEを受信したときにUASがINVITEに応答を送信しないようにしました。ここでは許可されていません。元のINVITEには応答が必要です。
o In RFC 2543, UAs needed to support only UDP. In this RFC, UAs need to support both UDP and TCP.
o RFC 2543では、UAはUDPのみをサポートする必要がありました。このRFCでは、UAはUDPとTCPの両方をサポートする必要があります。
o In RFC 2543, a forking proxy only passed up one challenge from downstream elements in the event of multiple challenges. In this RFC, proxies are supposed to collect all challenges and place them into the forwarded response.
o RFC 2543では、分岐プロキシは、複数のチャレンジが発生した場合に、ダウンストリーム要素からの1つのチャレンジのみを渡しました。このRFCでは、プロキシがすべてのチャレンジを収集し、転送された応答に配置することになっています。
o In Digest credentials, the URI needs to be quoted; this is unclear from RFC 2617 and RFC 2069 which are both inconsistent on it.
o In Digest credentials, the URI needs to be quoted; this is unclear from RFC 2617 and RFC 2069 which are both inconsistent on it.
o SDP processing has been split off into a separate specification [13], and more fully specified as a formal offer/answer exchange process that is effectively tunneled through SIP. SDP is allowed in INVITE/200 or 200/ACK for baseline SIP implementations; RFC 2543 alluded to the ability to use it in INVITE, 200, and ACK in a single transaction, but this was not well specified. More complex SDP usages are allowed in extensions.
o SDP処理は個別の仕様[13]に分割され、SIPを介して効果的にトンネリングされる正式なオファー/アンサー交換プロセスとしてより完全に指定されています。 SDPは、ベースラインSIP実装のINVITE / 200または200 / ACKで許可されます。 RFC 2543は、単一トランザクションのINVITE、200、およびACKで使用できることをほのめかしていましたが、これは十分に指定されていませんでした。拡張機能では、より複雑なSDPの使用が許可されています。
o Added full support for IPv6 in URIs and in the Via header field. Support for IPv6 in Via has required that its header field parameters allow the square bracket and colon characters. These characters were previously not permitted. In theory, this could cause interop problems with older implementations. However, we have observed that most implementations accept any non-control ASCII character in these parameters.
o URIとViaヘッダーフィールドにIPv6の完全サポートが追加されました。 ViaでのIPv6のサポートでは、そのヘッダーフィールドパラメータで角括弧とコロン文字を許可する必要があります。これらの文字は、以前は許可されていませんでした。理論的には、これは古い実装で相互運用性の問題を引き起こす可能性があります。ただし、ほとんどの実装では、これらのパラメーターで非制御ASCII文字を受け入れることがわかっています。
o DNS SRV procedure is now documented in a separate specification [4]. This procedure uses both SRV and NAPTR resource records and no longer combines data from across SRV records as described in RFC 2543.
o DNS SRV手順は、別の仕様[4]で文書化されています。この手順では、SRVとNAPTRの両方のリソースレコードを使用し、RFC 2543で説明されているように、SRVレコード全体のデータを結合しなくなりました。
o Loop detection has been made optional, supplanted by a mandatory usage of Max-Forwards. The loop detection procedure in RFC 2543 had a serious bug which would report "spirals" as an error condition when it was not. The optional loop detection procedure is more fully and correctly specified here.
o Loop detection has been made optional, supplanted by a mandatory usage of Max-Forwards. The loop detection procedure in RFC 2543 had a serious bug which would report "spirals" as an error condition when it was not. The optional loop detection procedure is more fully and correctly specified here.
o Usage of tags is now mandatory (they were optional in RFC 2543), as they are now the fundamental building blocks of dialog identification.
o タグは現在、ダイアログ識別の基本的なビルディングブロックであるため、タグの使用は必須です（RFC 2543ではオプションでした）。
o Added the Supported header field, allowing for clients to indicate what extensions are supported to a server, which can apply those extensions to the response, and indicate their usage with a Require in the response.
o サポートされているヘッダーフィールドが追加されました。これにより、クライアントがサーバーでサポートされている拡張機能を示し、それらの拡張機能を応答に適用し、応答でRequireを使用してその使用法を示すことができます。
o Extension parameters were missing from the BNF for several header fields, and they have been added.
o いくつかのヘッダーフィールドのBNFから拡張パラメーターが欠落しており、それらが追加されました。
o Handling of Route and Record-Route construction was very underspecified in RFC 2543, and also not the right approach. It has been substantially reworked in this specification (and made vastly simpler), and this is arguably the largest change. Backwards compatibility is still provided for deployments that do not use "pre-loaded routes", where the initial request has a set of Route header field values obtained in some way outside of Record-Route. In those situations, the new mechanism is not interoperable.
o RouteおよびRecord-Routeの構築の処理はRFC 2543で十分に規定されておらず、適切なアプローチでもありませんでした。これはこの仕様で大幅に作り直され（そして非常に単純化されました）、これは間違いなく最大の変更です。下位互換性は、「プリロードされたルート」を使用しない展開でも引き続き提供されます。最初のリクエストには、Record-Routeの外で何らかの方法で取得された一連のルートヘッダーフィールド値があります。これらの状況では、新しいメカニズムは相互運用できません。
o In RFC 2543, lines in a message could be terminated with CR, LF, or CRLF. This specification only allows CRLF.
o RFC 2543では、メッセージの行はCR、LF、またはCRLFで終了する可能性があります。この仕様はCRLFのみを許可します。
o Usage of Route in CANCEL and ACK was not well defined in RFC 2543. It is now well specified; if a request had a Route header field, its CANCEL or ACK for a non-2xx response to the request need to carry the same Route header field values. ACKs for 2xx responses use the Route values learned from the Record-Route of the 2xx responses.
o CANCELおよびACKでのルートの使用法は、RFC 2543で十分に定義されていませんでした。リクエストにルートヘッダーフィールドがあった場合、リクエストに対する2xx以外の応答のCANCELまたはACKは、同じルートヘッダーフィールドの値を運ぶ必要があります。 2xx応答のACKは、2xx応答のRecord-Routeから学習したルート値を使用します。
o RFC 2543 allowed multiple requests in a single UDP packet. This usage has been removed.
o RFC 2543では、単一のUDPパケットで複数の要求を許可していました。この使用法は削除されました。
o Usage of absolute time in the Expires header field and parameter has been removed. It caused interoperability problems in elements that were not time synchronized, a common occurrence. Relative times are used instead.
o Expiresヘッダーフィールドとパラメーターでの絶対時間の使用が削除されました。これは、よく発生する、時間同期されていない要素の相互運用性の問題を引き起こしました。代わりに、相対時間が使用されます。
o The branch parameter of the Via header field value is now mandatory for all elements to use. It now plays the role of a unique transaction identifier. This avoids the complex and bug-laden transaction identification rules from RFC 2543. A magic cookie is used in the parameter value to determine if the previous hop has made the parameter globally unique, and comparison falls back to the old rules when it is not present. Thus, interoperability is assured.
o Viaヘッダーフィールド値のブランチパラメータは、すべての要素で使用するために必須になりました。これは、一意のトランザクション識別子の役割を果たします。これにより、RFC 2543の複雑でバグの多いトランザクション識別ルールが回避されます。パラメーター値でマジックCookieを使用して、前のホップでパラメーターがグローバルに一意になっているかどうかを判断し、存在しない場合は比較によって古いルールにフォールバックします。したがって、相互運用性が保証されます。
o In RFC 2543, closure of a TCP connection was made equivalent to a CANCEL. This was nearly impossible to implement (and wrong) for TCP connections between proxies. This has been eliminated, so that there is no coupling between TCP connection state and SIP processing.
o RFC 2543では、TCP接続のクローズはCANCELと同等に行われました。これは、プロキシ間のTCP接続に対して実装するのがほぼ不可能でした（そして間違っていました）。これは排除されたため、TCP接続状態とSIP処理の間のカップリングはありません。
o RFC 2543 was silent on whether a UA could initiate a new transaction to a peer while another was in progress. That is now specified here. It is allowed for non-INVITE requests, disallowed for INVITE.
o RFC 2543は、UAが別のトランザクションの進行中にピアへの新しいトランザクションを開始できるかどうかについては黙っていました。これはここで指定されています。 INVITEでは許可されていない、INVITE以外の要求で許可されます。
o PGP was removed. It was not sufficiently specified, and not compatible with the more complete PGP MIME. It was replaced with S/MIME.
o PGPは削除されました。これは十分に指定されておらず、より完全なPGP MIMEと互換性がありません。 S / MIMEに置き換えられました。
o Added the "sips" URI scheme for end-to-end TLS. This scheme is not backwards compatible with RFC 2543. Existing elements that receive a request with a SIPS URI scheme in the Request-URI will likely reject the request. This is actually a feature; it ensures that a call to a SIPS URI is only delivered if all path hops can be secured.
o エンドツーエンドTLSの「sips」URIスキームを追加しました。このスキームはRFC 2543との下位互換性がありません。Request-URIのSIPS URIスキームでリクエストを受信する既存の要素は、リクエストを拒否する可能性があります。これは実際には機能です。これにより、すべてのパスホップを保護できる場合にのみSIPS URIへの呼び出しが配信されます。
o Additional security features were added with TLS, and these are described in a much larger and complete security considerations section.
o TLSで追加のセキュリティ機能が追加されました。これらの機能については、はるかに大きく完全なセキュリティに関する考慮事項のセクションで説明しています。
o In RFC 2543, a proxy was not required to forward provisional responses from 101 to 199 upstream. This was changed to MUST. This is important, since many subsequent features depend on delivery of all provisional responses from 101 to 199.
o In RFC 2543, a proxy was not required to forward provisional responses from 101 to 199 upstream. This was changed to MUST. This is important, since many subsequent features depend on delivery of all provisional responses from 101 to 199.
o Little was said about the 503 response code in RFC 2543. It has since found substantial use in indicating failure or overload conditions in proxies. This requires somewhat special treatment. Specifically, receipt of a 503 should trigger an attempt to contact the next element in the result of a DNS SRV lookup. Also, 503 response is only forwarded upstream by a proxy under certain conditions.
o Little was said about the 503 response code in RFC 2543. It has since found substantial use in indicating failure or overload conditions in proxies. This requires somewhat special treatment. Specifically, receipt of a 503 should trigger an attempt to contact the next element in the result of a DNS SRV lookup. Also, 503 response is only forwarded upstream by a proxy under certain conditions.
o RFC 2543 defined, but did no sufficiently specify, a mechanism for UA authentication of a server. That has been removed. Instead, the mutual authentication procedures of RFC 2617 are allowed.
o RFC 2543は、サーバーのUA認証のメカニズムを定義しましたが、十分に指定していませんでした。それは削除されました。代わりに、RFC 2617の相互認証手順が許可されます。
o A UA cannot send a BYE for a call until it has received an ACK for the initial INVITE. This was allowed in RFC 2543 but leads to a potential race condition.
o UAは、最初のINVITEのACKを受信するまで、コールのBYEを送信できません。これはRFC 2543で許可されていましたが、潜在的な競合状態が発生しました。
o A UA or proxy cannot send CANCEL for a transaction until it gets a provisional response for the request. This was allowed in RFC 2543 but leads to potential race conditions.
o UAまたはプロキシは、要求に対する暫定応答を取得するまで、トランザクションのCANCELを送信できません。これはRFC 2543で許可されていましたが、潜在的な競合状態を引き起こしています。
o The action parameter in registrations has been deprecated. It was insufficient for any useful services, and caused conflicts when application processing was applied in proxies.
o 登録のアクションパラメータは廃止されました。有用なサービスには不十分で、プロキシでアプリケーション処理を適用すると競合が発生しました。
o RFC 2543 had a number of special cases for multicast. For example, certain responses were suppressed, timers were adjusted, and so on. Multicast now plays a more limited role, and the protocol operation is unaffected by usage of multicast as opposed to unicast. The limitations as a result of that are documented.
o RFC 2543には、マルチキャストに関するいくつかの特殊なケースがありました。たとえば、特定の応答が抑制された、タイマーが調整された、などです。マルチキャストはより限定的な役割を果たすようになり、プロトコル操作はユニキャストではなくマルチキャストの使用による影響を受けません。その結果としての制限は文書化されています。
o Basic authentication has been removed entirely and its usage forbidden.
o 基本認証は完全に削除され、その使用は禁止されています。
o Proxies no longer forward a 6xx immediately on receiving it. Instead, they CANCEL pending branches immediately. This avoids a potential race condition that would result in a UAC getting a 6xx followed by a 2xx. In all cases except this race condition, the result will be the same - the 6xx is forwarded upstream.
o プロキシは6xxを受信してもすぐに転送しなくなりました。代わりに、保留中のブランチをすぐにキャンセルします。これにより、UACが6xxに続いて2xxを取得する可能性のある潜在的な競合状態が回避されます。この競合状態を除くすべてのケースで、結果は同じになります-6xxがアップストリームに転送されます。
o RFC 2543 did not address the problem of request merging. This occurs when a request forks at a proxy and later rejoins at an element. Handling of merging is done only at a UA, and procedures are defined for rejecting all but the first request.
o RFC 2543は、要求のマージの問題に対処していませんでした。これは、リクエストがプロキシでforkし、後で要素に再結合したときに発生します。マージの処理はUAでのみ行われ、最初の要求以外のすべてを拒否するための手順が定義されています。
o Added the Alert-Info, Error-Info, and Call-Info header fields for optional content presentation to users.
o Added the Alert-Info, Error-Info, and Call-Info header fields for optional content presentation to users.
o Added the Content-Language, Content-Disposition and MIME-Version header fields.
o Content-Language、Content-Disposition、MIME-Versionヘッダーフィールドが追加されました。
o Added a "glare handling" mechanism to deal with the case where both parties send each other a re-INVITE simultaneously. It uses the new 491 (Request Pending) error code.
o 両当事者がお互いにre-INVITEを同時に送信する場合に対処するための「グレア処理」メカニズムが追加されました。新しい491（Request Pending）エラーコードを使用します。
o Added the In-Reply-To and Reply-To header fields for supporting the return of missed calls or messages at a later time.
o 不在着信またはメッセージの後での返信をサポートするために、In-Reply-ToおよびReply-Toヘッダーフィールドを追加しました。
o Added TLS and SCTP as valid SIP transports.
o 有効なSIPトランスポートとしてTLSおよびSCTPを追加しました。
o There were a variety of mechanisms described for handling failures at any time during a call; those are now generally unified. BYE is sent to terminate.
o 通話中にいつでも障害を処理するためのさまざまなメカニズムが説明されていました。それらは現在、一般的に統一されています。 BYEが送信されて終了します。
o RFC 2543 mandated retransmission of INVITE responses over TCP, but noted it was really only needed for 2xx. That was an artifact of insufficient protocol layering. With a more coherent transaction layer defined here, that is no longer needed. Only 2xx responses to INVITEs are retransmitted over TCP.
o RFC 2543は、TCPを介したINVITE応答の再送信を義務付けていましたが、これは実際には2xxにのみ必要であると指摘しました。これは、プロトコルの階層化が不十分なことによるアーチファクトでした。ここでより一貫性のあるトランザクションレイヤーが定義されているため、これは不要になりました。 INVITEへの2xx応答のみがTCP経由で再送信されます。
o Client and server transaction machines are now driven based on timeouts rather than retransmit counts. This allows the state machines to be properly specified for TCP and UDP.
o クライアントとサーバーのトランザクションマシンは、再送信カウントではなく、タイムアウトに基づいて駆動されるようになりました。これにより、ステートマシンをTCPおよびUDPに対して適切に指定できます。
o The Date header field is used in REGISTER responses to provide a simple means for auto-configuration of dates in user agents.
o DateヘッダーフィールドはREGISTER応答で使用され、ユーザーエージェントで日付を自動構成するための簡単な手段を提供します。
o Allowed a registrar to reject registrations with expirations that are too short in duration. Defined the 423 response code and the Min-Expires for this purpose.
o レジストラが有効期限が短すぎる登録を拒否できるようになりました。この目的のために、423応答コードとMin-Expiresを定義しました。
29 Normative References
29規範的な参照
[1] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[1] Handley、M。およびV. Jacobson、「SDP：Session Description Protocol」、RFC 2327、1998年4月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[3] Resnick、P。、「Internet Message Format」、RFC 2822、2001年4月。
[4] Rosenberg, J. and H. Schulzrinne, "SIP: Locating SIP Servers", RFC 3263, June 2002.
[4] Rosenberg、J。およびH. Schulzrinne、「SIP：Locating SIP Servers」、RFC 3263、2002年6月。
[5] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[5] Berners-Lee、T.、Fielding、R。およびL. Masinter、「Uniform Resource Identifiers（URI）：Generic Syntax」、RFC 2396、1998年8月。
[6] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002.
[6] Chown、P。、「Advanced Encryption Standard（AES）Ciphersuites for Transport Layer Security（TLS）」、RFC 3268、2002年6月。
[7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[8] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[8] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P. and T. Berners-Lee、 "Hypertext Transfer Protocol-HTTP / 1.1"、RFC 2616、 1999年6月。
[9] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 2000.
[9] Vaha-Sipila、A。、「電話のURL」、RFC 2806、2000年4月。
[10] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[10] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、RFC 2234、1997年11月。
[11] Freed, F. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[11] Freed, F. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[12] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[12] Eastlake、D.、Crocker、S。およびJ. Schiller、「Randomness Recommendations for Security」、RFC 1750、1994年12月。
[13] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with SDP", RFC 3264, June 2002.
[13] Rosenberg、J。およびH. Schulzrinne、「SDPを使用したオファー/アンサーモデル」、RFC 3264、2002年6月。
[14] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[14] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[15] Postel, J., "DoD Standard Transmission Control Protocol", RFC 761, January 1980.
[15] Postel、J。、「DoD Standard Transmission Control Protocol」、RFC 761、1980年1月。
[16] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[16] スチュワート、R。、シェ、Q。、モーノー、K。、シャープ、C。、シュワルツバウアー、H。、テイラー、T。、リティーナ、I。、カラ、M。、チャン、L.、V。パクソン、「 Stream Control Transmission Protocol」、RFC 2960、2000年10月。
[17] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, "HTTP authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[17] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Lawrence、S.、Leach、P.、Luotonen、A. and L. Stewart、 "HTTP authentication：Basic and Digest Access Authentication"、RFC 2617、 1999年6月。
[18] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[18] Troost、R.、Dorner、S。、およびK. Moore、「インターネットメッセージでのプレゼンテーション情報の伝達：Content-Dispositionヘッダーフィールド」、RFC 2183、1997年8月。
[19] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG Objects", RFC 3204, December 2001.
[19] Zimmerer、E.、Peterson、J.、Vemuri、A.、Ong、L.、Audet、F.、Watson、M. and M. Zonoun、 "MIME media types for ISUP and QSIG Objects"、RFC 3204、December 2001 。
[20] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[20] Braden、R。、「インターネットホストの要件-アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
[21] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[21] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[22] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
[22] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
[23] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[23] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[24] Ramsdell B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[24] Ramsdell B。、「S / MIMEバージョン3メッセージ仕様」、RFC 2633、1999年6月。
[25] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[25] Dierks、T。およびC. Allen、「The TLS Protocol Version 1.0」、RFC 2246、1999年1月。
[26] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[26] ケントS.およびR.アトキンソン、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
30 Informative References
30参考情報
[27] R. Pandya, "Emerging mobile and personal communication systems," IEEE Communications Magazine, Vol. 33, pp. 44--52, June 1995.
[27] R. Pandya、「新興のモバイルおよびパーソナル通信システム」、IEEE Communications Magazine、Vol。 33、44-52ページ、1995年6月。
[28] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[28] Schulzrinne、H.、Casner、S.、Frederick、R。およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、RFC 1889、1996年1月。
[29] Schulzrinne, H., Rao, R. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[29] Schulzrinne、H.、Rao、R。およびR. Lanphier、「Real Time Streaming Protocol（RTSP）」、RFC 2326、1998年4月。
[30] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and J. Segers, "Megaco Protocol Version 1.0", RFC 3015, November 2000.
[30] Cuervo、F.、Greene、N.、Rayhan、A.、Huitema、C.、Rosen、B。およびJ. Segers、「Megaco Protocol Version 1.0」、RFC 3015、2000年11月。
[31] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[31] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[32] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL scheme", RFC 2368, July 1998.
[32] Hoffman、P.、Masinter、L。およびJ. Zawinski、「mailto URLスキーム」、RFC 2368、1998年7月。
[33] E. M. Schooler, "A multicast user directory service for synchronous rendezvous," Master's Thesis CS-TR-96-18, Department of Computer Science, California Institute of Technology, Pasadena, California, Aug. 1996.
[33] E. M. Schooler、「同期ランデブー用のマルチキャストユーザーディレクトリサービス」修士論文CS-TR-96-18、カリフォルニア工科大学コンピューターサイエンス学部、パサデナ、カリフォルニア、1996年8月。
[34] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[34] Donovan、S。、「The SIP INFO Method」、RFC 2976、2000年10月。
[35] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[35] Rivest、R。、「MD5メッセージダイジェストアルゴリズム」、RFC 1321、1992年4月。
[36] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, September 1998.
[36] Dawson、F。およびT. Howes、「vCard MIME Directory Profile」、RFC 2426、1998年9月。
[37] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical Specification", RFC 2849, June 2000.
[37] Good、G。、「LDAPデータ交換フォーマット（LDIF）-技術仕様」、RFC 2849、2000年6月。
[38] Palme, J., "Common Internet Message Headers", RFC 2076, February 1997.
[38] Palme、J。、「Common Internet Message Headers」、RFC 2076、1997年2月。
[39] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP: Digest Access Authentication", RFC 2069, January 1997.
[39] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Leach、P.、Luotonen、A.、Sink、E.、L。Stewart、「An Extension to HTTP：Digest Access Authentication」、RFC 2069、 1997年1月。
[40] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., Willis, D., Rosenberg, J., Summers, K. and H. Schulzrinne, "SIP Call Flow Examples", Work in Progress.
[40] ジョンストン、A。、ドノバン、S。、スパークス、R。、カニンガム、C。、ウィリス、D。、ローゼンバーグ、J。、サマーズ、K。およびH.シュルズリンネ、「SIPコールフローの例」、Work in Progress。
[41] E. M. Schooler, "Case study: multimedia conference control in a packet-switched teleconferencing system," Journal of Internetworking: Research and Experience, Vol. 4, pp. 99--120, June 1993. ISI reprint series ISI/RS-93-359.
[41] E. M. Schooler、「ケーススタディ：パケット交換電話会議システムでのマルチメディア会議制御」、Journal of Internetworking：Research and Experience、Vol。 4、pp。99--120、1993年6月。ISI再版シリーズISI / RS-93-359。
[42] H. Schulzrinne, "Personal mobility for multimedia services in the Internet," in European Workshop on Interactive Distributed Multimedia Systems and Services (IDMS), (Berlin, Germany), Mar. 1996.
[42] H.シュルズリンネ、「インターネットにおけるマルチメディアサービスのパーソナルモビリティ」、インタラクティブ分散マルチメディアシステムおよびサービスに関するヨーロッパのワークショップ（IDMS）（ベルリン、ドイツ）、1996年3月。
[43] Floyd, S., "Congestion Control Principles", RFC 2914, September 2000.
[43] Floyd、S。、「輻輳制御原則」、RFC 2914、2000年9月。
A Table of Timer Values
タイマー値の表
Table 4 summarizes the meaning and defaults of the various timers used by this specification.
表4は、この仕様で使用されるさまざまなタイマーの意味とデフォルトをまとめたものです。
Timer Value Section Meaning
----------------------------------------------------------------------
T1 500ms default Section 17.1.1.1 RTT Estimate
T2 4s Section 17.1.2.2 The maximum retransmit
interval for non-INVITE
requests and INVITE
responses
T4 5s Section 17.1.2.2 Maximum duration a
message will
remain in the network
Timer A initially T1 Section 17.1.1.2 INVITE request retransmit
interval, for UDP only
Timer B 64*T1 Section 17.1.1.2 INVITE transaction
timeout timer
Timer C > 3min Section 16.6 proxy INVITE transaction
bullet 11 timeout
Timer D > 32s for UDP Section 17.1.1.2 Wait time for response
0s for TCP/SCTP retransmits
Timer E initially T1 Section 17.1.2.2 non-INVITE request
retransmit interval,
UDP only
Timer F 64*T1 Section 17.1.2.2 non-INVITE transaction
timeout timer
Timer G initially T1 Section 17.2.1 INVITE response
retransmit interval
Timer H 64*T1 Section 17.2.1 Wait time for
ACK receipt
Timer I T4 for UDP Section 17.2.1 Wait time for
0s for TCP/SCTP ACK retransmits
Timer J 64*T1 for UDP Section 17.2.2 Wait time for
0s for TCP/SCTP non-INVITE request
retransmits
Timer K T4 for UDP Section 17.1.2.2 Wait time for
0s for TCP/SCTP response retransmits
Table 4: Summary of timers
Table 4: Summary of timers
Acknowledgments
謝辞
We wish to thank the members of the IETF MMUSIC and SIP WGs for their comments and suggestions. Detailed comments were provided by Ofir Arkin, Brian Bidulock, Jim Buller, Neil Deason, Dave Devanathan, Keith Drage, Bill Fenner, Cedric Fluckiger, Yaron Goland, John Hearty, Bernie Hoeneisen, Jo Hornsby, Phil Hoffer, Christian Huitema, Hisham Khartabil, Jean Jervis, Gadi Karmi, Peter Kjellerstedt, Anders Kristensen, Jonathan Lennox, Gethin Liddell, Allison Mankin, William Marshall, Rohan Mahy, Keith Moore, Vern Paxson, Bob Penfield, Moshe J. Sambol, Chip Sharp, Igor Slepchin, Eric Tremblay, and Rick Workman.
We wish to thank the members of the IETF MMUSIC and SIP WGs for their comments and suggestions. Detailed comments were provided by Ofir Arkin, Brian Bidulock, Jim Buller, Neil Deason, Dave Devanathan, Keith Drage, Bill Fenner, Cedric Fluckiger, Yaron Goland, John Hearty, Bernie Hoeneisen, Jo Hornsby, Phil Hoffer, Christian Huitema, Hisham Khartabil, Jean Jervis, Gadi Karmi, Peter Kjellerstedt, Anders Kristensen, Jonathan Lennox, Gethin Liddell, Allison Mankin, William Marshall, Rohan Mahy, Keith Moore, Vern Paxson, Bob Penfield, Moshe J. Sambol, Chip Sharp, Igor Slepchin, Eric Tremblay, and Rick Workman.
Brian Rosen provided the compiled BNF.
Brian Rosen provided the compiled BNF.
Jean Mahoney provided technical writing assistance.
Jean Mahoneyはテクニカルライティングアシスタンスを提供しました。
This work is based, inter alia, on [41,42].
この作品は、とりわけ[41,42]に基づいています。
Authors' Addresses
著者のアドレス
Authors addresses are listed alphabetically for the editors, the writers, and then the original authors of RFC 2543. All listed authors actively contributed large amounts of text to this document.
著者のアドレスは、編集者、作家、およびRFC 2543の元の著者のアルファベット順にリストされています。リストされているすべての著者は、このドキュメントに大量のテキストを積極的に提供しています。
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Ave East Hanover, NJ 07936 USA
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Ave East Hanover、NJ 07936 USA
EMail: jdrosen@dynamicsoft.com
Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA
ヘニングシュルズリンネコロンビア大学コンピュータサイエンス学部1214アムステルダムアベニューニューヨーク、ニューヨーク10027アメリカ
EMail: schulzrinne@cs.columbia.edu
Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland
Gonzalo Camarillo Ericsson Advanced Signaling Research Lab。 FIN-02420 Jorvasフィンランド
EMail: Gonzalo.Camarillo@ericsson.com
Alan Johnston WorldCom 100 South 4th Street St. Louis, MO 63102 USA
Alan Johnston WorldCom 100 South 4th Street St. Louis、MO 63102 USA
EMail: alan.johnston@wcom.com Jon Peterson
NeuStar, Inc
1800 Sutter Street, Suite 570
Concord, CA 94520
USA
EMail: jon.peterson@neustar.com
Robert Sparks dynamicsoft, Inc. 5100 Tennyson Parkway Suite 1200 Plano, Texas 75024 USA
Robert Sparks dynamicsoft, Inc. 5100 Tennyson Parkway Suite 1200 Plano, Texas 75024 USA
EMail: rsparks@dynamicsoft.com
Mark Handley International Computer Science Institute 1947 Center St, Suite 600 Berkeley, CA 94704 USA
Mark Handley International Computer Science Institute 1947 Center St、Suite 600 Berkeley、CA 94704 USA
EMail: mjh@icir.org
Eve Schooler AT&T Labs-Research 75 Willow Road Menlo Park, CA 94025 USA
Eve Schooler AT＆T Labs-Research 75 Willow Road Menlo Park、CA 94025 USA
EMail: schooler@research.att.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（C）The Internet Society（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができます。ただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、この文書自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。