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
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
会话启动协议
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.
版权所有（C）互联网协会（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.
本文档描述了会话启动协议（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
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
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
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
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
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
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
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
有许多互联网应用需要创建和管理会话，其中会话被视为参与者协会之间的数据交换。这些应用程序的实现因参与者的实践而变得复杂：用户可能在端点之间移动，他们可能通过多个名称进行寻址，他们可能在多个不同的媒体中进行通信——有时是同时进行的。许多协议已经被编写出来，它们携带各种形式的实时多媒体会话数据，如语音、视频或文本消息。会话启动协议（SIP）通过以下方式与这些协议协同工作：
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.
使Internet端点（称为用户代理）能够相互发现，并就他们想要共享的会话的特征达成一致。为了定位潜在的会话参与者以及实现其他功能，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是一种应用层控制协议，可以建立、修改和终止多媒体会话（会议），如Internet电话呼叫。SIP还可以邀请参与者参加现有的会话，如多播会议。可以将媒体添加到现有会话中（或从中删除）。SIP透明地支持名称映射和重定向服务，支持个人移动[27]-用户可以维护一个外部可见的标识符，无论其网络位置如何。
SIP supports five facets of establishing and terminating multimedia communications:
SIP支持建立和终止多媒体通信的五个方面：
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反馈的实时传输协议（RTP）（RFC 1889[28]）、用于控制流媒体的交付的实时流协议（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.
网关控制协议（MEGACO）（RFC 3015[30]），用于控制公共交换电话网（PSTN）的网关，以及用于描述多媒体会话的会话描述协议（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.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”将按照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显示了两个用户Alice和Bob之间SIP消息交换的典型示例。（每条消息都标有字母“F”和一个数字，以供文本参考。）在本例中，Alice使用PC上的SIP应用程序（称为软电话）通过Internet与Bob的SIP电话通话。还显示了代表Alice和Bob的两个SIP代理服务器，以促进会话的建立。这种典型布置通常被称为“SIP梯形”，如图1中虚线的几何形状所示。
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.
Alice使用Bob的SIP标识“调用”Bob，这是一种称为SIP URI的统一资源标识符（URI）。第19.1节定义了SIP URI。它的形式与电子邮件地址类似，通常包含用户名和主机名。在这种情况下，它是sip：bob@biloxi.com，其中biloxi.com是Bob的SIP服务提供商的域。Alice的SIP URI为SIP:alice@atlanta.com. Alice可能输入了Bob的URI，或者单击了地址簿中的超链接或条目。SIP还提供一个安全URI，称为SIPS 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的请求/响应事务模型。每个事务由一个调用服务器上特定方法或函数的请求和至少一个响应组成。在本例中，事务从Alice的软电话向Bob的SIPURI发送INVITE请求开始。INVITE是SIP方法的一个示例，它指定请求者（Alice）希望服务器（Bob）执行的操作。INVITE请求包含多个标题字段。标题字段是提供有关消息的附加信息的命名属性。INVITE中的内容包括呼叫的唯一标识符、目标地址、Alice的地址以及Alice希望与Bob建立的会话类型的信息。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 |
|------------------------------------------------->|
| |
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
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)
（未显示Alice的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:
文本编码消息的第一行包含方法名称（INVITE）。下面的几行是标题字段的列表。此示例包含所需的最小集合。标题字段简要描述如下：
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.
Via包含Alice希望收到此请求响应的地址（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.
Contact包含一个SIP或SIPS URI，表示联系Alice的直接路由，通常由完全限定域名（FQDN）处的用户名组成。虽然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用于限制一个请求在到达目的地的过程中可以进行的跳数。它由一个整数组成，每个跃点递减一。
Content-Type contains a description of the message body (not shown).
内容类型包含消息正文的描述（未显示）。
Content-Length contains an octet (byte) count of the message body.
内容长度包含消息正文的八位字节（字节）计数。
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消息的主体包含会话的描述，以某种其他协议格式编码。其中一种格式是会话描述协议（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.
例如）由SIP消息以类似于电子邮件消息所承载的文档附件或HTTP消息所承载的网页的方式承载。
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.
由于软电话不知道Bob或SIP服务器在biloxi.com域中的位置，因此软电话将邀请发送到为Alice的域atlanta.com服务的SIP服务器。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（尝试）响应发送回Alice的软电话。100（尝试）响应表示已收到邀请，并且代理正在代表她将邀请路由到目标。SIP中的响应使用三位数代码，后跟描述性短语。此响应在VITE中包含与INVITE相同的To、From、Call ID、CSeq和branch参数，允许Alice的软电话将此响应与发送的INVITE关联。atlanta.com代理服务器可能通过执行特定类型的DNS（域名服务）查找来查找为biloxi.com域提供服务的SIP服务器，从而将代理服务器定位在biloxi.com。这在[4]中进行了描述。因此，它获取biloxi.com代理服务器的IP地址，并在那里转发或代理INVITE请求。在转发请求之前，atlanta.com代理服务器会添加一个额外的Via标头字段值，该字段值包含其自己的地址（邀请已包含Alice在第一个Via中的地址）。biloxi.com代理服务器接收到邀请，并向atlanta.com代理服务器返回100（尝试）响应，以表明其已收到邀请并正在处理请求。代理服务器查询一个数据库（通常称为位置服务），该数据库包含Bob的当前IP地址。（我们将在下一节中了解如何填充此数据库。）biloxi.com代理服务器将另一个Via标头字段值及其自己的地址添加到INVITE，并将其代理到Bob的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
Bob的SIP电话接收邀请并提醒Bob来自Alice的来电，以便Bob可以决定是否接听电话，即Bob的电话响起。Bob的SIP电话以180（响铃）响应表示这一点，该响应以相反方向通过两个代理返回。每个代理使用Via header字段来确定发送响应的位置，并从顶部删除自己的地址。因此，尽管路由初始邀请需要DNS和位置服务查找，但180（振铃）响应可以在不查找或不显示状态的情况下返回给呼叫者
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.
在代理中维护。这还有一个可取的特性，即每个看到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（响铃）响应时，它会将此信息传递给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:
在本例中，Bob决定接听电话。当他拿起手机时，他的SIP手机会发送一个200（OK）响应，表示呼叫已经应答。200（OK）包含一个消息正文，其中包含Bob愿意与Alice建立的会话类型的SDP媒体描述。因此，SDP消息的交换分为两个阶段：Alice将一个发送给Bob，Bob将一个发送回Alice。此两阶段交换提供基本的协商功能，并基于SDP交换的简单提供/应答模型。如果Bob不想接听电话或正在接听另一个电话，则会发送错误响应，而不是200（OK），这将导致未建立媒体会话。SIP响应代码的完整列表见第21节。当Bob发出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
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
响应的第一行包含响应代码（200）和原因短语（OK）。其余行包含标题字段。Via、To、From、Call ID和CSeq头字段从INVITE请求复制。（有三个Via标头字段值-一个由Alice的SIP phone添加，一个由atlanta.com代理添加，一个由biloxi.com代理添加。）Bob的SIP phone已将标记参数添加到to标头字段。此标记将由两个端点合并到对话框中，并将包含在将来的所有会话中
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.
此呼叫中的请求和响应。Contact header字段包含一个URI，Bob可以通过SIP电话直接访问该URI。内容类型和内容长度指的是包含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（此处忙）响应，则biloxi.com代理服务器可以将邀请代理到Bob的语音邮件服务器。代理服务器还可以同时向多个位置发送邀请。这种类型的并行搜索称为分叉。
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）通过两个代理路由回，并由Alice的软电话接收，然后停止回铃并指示呼叫已应答。最后，Alice的软电话向Bob的SIP电话发送确认消息ACK，以确认接收到最终响应（200（OK））。在本例中，ACK直接从Alice的软电话发送到Bob的SIP电话，绕过两个代理。发生这种情况是因为端点通过INVITE/200（OK）交换从联系人标头字段中了解了彼此的地址，而初始INVITE在发送时不知道对方的地址。两个代理执行的查找不再需要，因此代理退出调用流。这就完成了用于建立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.
Alice和Bob的媒体会话现在已经开始，他们使用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.
会话期间，Alice或Bob可能决定更改媒体会话的特征。这是通过发送包含新媒体描述的重新邀请来实现的。此重新邀请将引用现有对话框，以便另一方知道它将修改现有会话，而不是建立新会话。另一方发送200（确定）以接受更改。请求者用ACK响应200（OK）。如果另一方不接受更改，他将发送一个错误响应，如488（此处不可接受），该响应也会收到ACK。但是，重新邀请失败不会导致现有调用失败-会话继续使用先前协商的特征。有关会话修改的详细信息，请参见第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.
在通话结束时，Bob首先断开（挂断）连接并生成一条BYE消息。这个BYE直接路由到Alice的软电话，再次绕过代理。Alice使用200（OK）响应确认收到BYE，该响应终止会话和BYE事务。不发送ACK-仅在响应INVITE请求时发送ACK。对INVITE进行这种特殊处理的原因将在后面讨论，但与SIP中的可靠性机制、接听来电所需的时间长度以及分叉有关。因此，SIP中的请求处理通常被分类为INVITE或non 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消息传递路径中，它将向INVITE添加一个称为记录路由的必需路由头字段，该字段包含解析为代理主机名或IP地址的URI。Bob的SIP电话和Alice的软电话（由于记录路由报头字段在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中的另一个常见操作。注册是biloxi.com服务器了解Bob当前位置的一种方式。初始化后，Bob的SIP电话会定期向biloxi.com域中的服务器发送注册消息，称为SIP注册器。注册消息关联Bob的SIP或SIPS URI（SIP:bob@biloxi.com)使用他当前登录的机器（在Contact header字段中作为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
Bob不限于从单个设备注册。例如，他家里的SIP电话和办公室里的SIP电话都可以发送注册信息。此信息一起存储在位置中
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.
服务，并允许代理执行各种类型的搜索以定位Bob。类似地，可以同时在单个设备上注册多个用户。
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并接收一组零个或多个URI的信息，这些URI告诉代理将请求发送到哪里。注册是创建此信息的一种方法，但不是唯一的方法。管理员可以自行配置任意映射功能。
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请求，在授权传出请求时不起作用。授权和认证在SIP中通过质询/响应机制逐个请求处理，或者使用第26节中讨论的较低层方案处理。
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.
SIP中的其他操作，如使用选项查询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）指定的。第25节规定了完整的BNF；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.
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.translate error, please retry
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.
第三层是事务层。事务是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也可以取消它。当客户端取消事务时，它会请求服务器停止进一步的处理，恢复到事务启动前的状态，并对该事务生成特定的错误响应。这是通过取消请求完成的，该请求构成其自身的事务，但引用要取消的事务（第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中起着重要作用，因此处理注册的UAS被赋予特殊名称registrar。第10节描述了注册方法的UAC和UAS核心行为。第11节描述了期权方法的UAC和UAS核心行为，用于确定UA的能力。
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.
某些其他请求在对话框中发送。对话是两个用户代理之间持续一段时间的对等SIP关系。该对话框有助于在用户代理之间对消息排序和请求的正确路由。INVITE方法是本规范中定义的建立对话框的唯一方法。当UAC发送对话上下文中的请求时，它遵循第8节中讨论的通用UAC规则，但也遵循mid对话请求的规则。第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节讨论如何启动会话，从而产生一个或多个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）是一个SIP或SIPS URI，它指向具有位置服务的域，该服务可以将URI映射到用户可能可用的另一个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.
调用段：对话框的另一个名称[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：如果代理保留从发起邀请到终止BYE请求的对话框的状态，那么它就是Call Stateful。调用有状态代理始终是事务有状态的，但反之不一定成立。
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.
对话：对话是两个UAs之间持续一段时间的对等SIP关系。对话框是通过SIP消息建立的，例如对INVITE请求的2xx响应。对话框由调用标识符、本地标记和远程标记标识。在RFC2543中，对话框以前称为调用分支。
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.
Header：Header是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
Header字段：Header字段是SIP消息头的一个组件。标题字段可以显示为一个或多个标题字段行。标题字段行由标题字段名称和零个或多个标题字段值组成。一个表上有多个标题字段值
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.
给定标题字段行由逗号分隔。某些标题字段只能有一个标题字段值，因此始终显示为一个标题字段行。
Header Field Value: A header field value is a single value; a header field consists of zero or more header field values.
表头字段值：表头字段值为单个值；标题字段由零个或多个标题字段值组成。
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请求发起会话（和对话）的一方。调用者从发送建立对话框的初始邀请时起一直保留此角色，直到该对话框终止。
Invitation: An INVITE request.
邀请：邀请请求。
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.
受邀方、受邀用户、被叫方、被叫方：为建立新会话而接收邀请请求的一方。被调用方从收到邀请起一直保留此角色，直到该邀请建立的对话框终止。
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.
循环：到达代理的请求被转发，然后返回到同一代理。当它第二次到达时，其请求URI与第一次相同，并且影响代理操作的其他头字段不变，因此代理将对其第一次发出的请求做出相同的处理决策。循环请求是错误，协议描述了检测和处理它们的过程。
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
松散路由：如果代理遵循本规范中定义的处理路由头字段的过程，则称其为松散路由。这些过程将请求的目标（存在于请求URI中）与
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.
沿途需要访问的代理集（出现在Route header字段中）。符合这些机制的代理也称为松散路由器。
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.
出站代理：从客户端接收请求的代理，即使它可能不是由请求URI解析的服务器。通常，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.
并行搜索：在并行搜索中，代理在接收到传入请求时向可能的用户位置发出多个请求。并行搜索不像顺序搜索那样发出一个请求，然后在发出下一个请求之前等待最终响应，而是在不等待前一个请求的结果的情况下发出请求。
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 header字段中向一个或多个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.
注册器：注册器是一个服务器，它接受注册请求，并将在这些请求中接收到的信息放入它处理的域的位置服务中。
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).
Ringback：Ringback是主叫方应用程序发出的信号音，表示被叫方正在收到警报（振铃）。
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的集合，表示发送特定请求时必须遍历的代理列表。可以通过诸如记录路由之类的头来学习路由集，也可以对其进行配置。
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定义的会话可以包括一个或多个RTP会话。）如定义，可以通过不同的呼叫多次邀请被叫方参加同一会话。如果使用SDP，则会话由SDP用户名、会话id、网络类型、地址类型和源字段中的地址元素串联来定义。
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
SIP事务：SIP事务发生在客户端和服务器之间，包括从客户端发送到服务器的第一个请求到最终（非1xx）响应的所有消息
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.
从服务器发送到客户端。如果请求为INVITE且最终响应为非2xx，则事务还包括对响应的确认。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请求，它被路由到一个代理，向前转发，然后再次到达该代理，但这次的不同方式将导致与原始请求不同的处理决策。通常，这意味着请求的请求URI与其以前到达的请求URI不同。与循环不同，螺旋线不是错误条件。一个典型的原因是呼叫转移。用户呼叫joe@example.com. example.com代理将其转发给Joe的PC，而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的许多以前正在进行的工作版本，则称其为严格路由。该规则导致代理在存在路由头字段时销毁请求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。类似地，相同的软件可以充当一个请求的代理服务器和下一个请求的重定向服务器。
Proxy, location, and registrar servers defined above are logical entities; implementations MAY combine them into a single application.
上面定义的代理服务器、位置服务器和注册服务器是逻辑实体；实现可以将它们组合到单个应用程序中。
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头字段。）这两种类型的消息都由起始行、一个或多个头字段、指示头字段结尾的空行和可选消息正文组成。
generic-message = start-line *message-header CRLF [ message-body ] start-line = Request-Line / Status-Line
通用消息=起始行*消息头CRLF[消息正文]起始行=请求行/状态行
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请求通过请求行作为起始行来区分。请求行包含一个方法名、一个请求URI和由单个空格（SP）字符分隔的协议版本。
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.
请求行以CRLF结尾。除线路末端CRLF序列外，不允许使用CR或LF。任何元素中都不允许使用线性空白（LWS）。
Request-Line = Method SP Request-URI SP SIP-Version CRLF
请求行=方法SP请求URI SP SIP版本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，以及查询服务器功能的选项。标准跟踪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]）。它指示此请求所针对的用户或服务。请求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元素可以支持具有除“SIP”和“sips”之外的方案的请求URI，例如RFC 2806的“tel”URI方案[9]。SIP元素可以使用任意机制转换非SIP URI，从而生成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版本的“SIP/2.0”。SIP版本字符串不区分大小写，但实现必须发送大写。
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响应与请求的区别在于以状态行作为它们的起始行。状态行由协议版本、数字状态代码及其关联的文本短语组成，每个元素由单个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.
状态代码是一个3位整数结果代码，表示试图理解和满足请求的结果。原因短语旨在对状态代码进行简短的文本描述。状态代码用于自动机，而原因短语用于人类用户。客户端不需要检查或显示原因短语。
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 header字段中指示的语言。
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:
状态代码的第一位数字定义了响应的类别。最后两位数字没有任何分类角色。因此，状态代码介于100和199之间的任何响应称为“1x响应”，状态代码介于200和299之间的任何响应称为“2xx响应”，依此类推。SIP/2.0允许第一个数字有六个值：
1xx: Provisional -- request received, continuing to process the request;
1xx：临时——收到请求，继续处理请求；
2xx: Success -- the action was successfully received, understood, and accepted;
2xx:Success——成功地接收、理解和接受了操作；
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]还指定可以将值为逗号分隔列表的相同字段名的多个标题字段组合到一个标题字段中。这同样适用于SIP，但由于语法不同，具体规则也不同。具体而言，语法为以下形式的任何SIP头
header = "header-name" HCOLON header-value *(COMMA header-value)
header=“header name”HCOLON头值*（逗号头值）
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 "*".
允许将相同名称的标题字段合并到逗号分隔的列表中。联系人标题字段允许使用逗号分隔的列表，除非标题字段值为“*”。
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:
通过在每一额外行之前至少添加一个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
具有不同字段名的标题字段的相对顺序不重要。但是，建议代理处理所需的标头字段（例如，Via、Route、Record Route、proxy Required、Max Forwards和proxy Authorization）显示在消息顶部，以便于快速解析。具有相同字段名的标题字段行的相对顺序很重要。当且仅当标题字段的整个字段值定义为逗号分隔列表时（即，如果遵循第7.3节中定义的语法），消息中可能存在具有相同字段名的多个标题字段行。必须能够将多个标题字段行组合成一个“字段名称：字段值”对，而不改变消息的语义，方法是将每个后续字段值附加到第一个字段值，每个字段值用逗号分隔。此规则的例外情况是WWW Authenticate、authentication、Proxy Authenticate和Proxy authentication标头字段。多头
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.
消息中可能存在具有这些名称的字段行，但由于它们的语法不遵循第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.
实现必须能够以每行单个值或逗号分隔值形式的任意组合处理具有相同名称的多个标题字段行。
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>
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
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>
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: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: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>
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)
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.
即使可以将任意数量的参数对附加到标头字段值，任何给定的参数名称也不得出现多次。
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
Contact: <sip:alice@atlanta.com>;expires=3600
is equivalent to
相当于
CONTACT: <sip:alice@atlanta.com>;ExPiReS=3600
CONTACT: <sip:alice@atlanta.com>;ExPiReS=3600
and
和
Content-Disposition: session;handling=optional
Content-Disposition: session;handling=optional
is equivalent to
相当于
content-disposition: Session;HANDLING=OPTIONAL
content-disposition: Session;HANDLING=OPTIONAL
The following two header fields are not equivalent:
以下两个标题字段不等效：
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.
某些标题字段仅在请求或响应中有意义。这些字段分别称为请求头字段和响应头字段。如果消息中出现的标题字段与其类别不匹配（例如响应中的请求标题字段），则必须忽略该字段。第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
SIP提供了一种以缩写形式表示公共头字段名称的机制。当消息变得太大而无法在可用的传输中传输时（例如，使用UDP时超过最大传输单位（MTU）），这可能很有用。这些紧凑形式在第20节中有定义。在任何时候，在不改变消息语义的情况下，都可以用紧凑形式替换较长形式的报头字段名。标题
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.
字段名可以在同一消息中以长格式和短格式出现。实现必须接受每个头名称的长形式和短形式。
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.
邮件正文的Internet媒体类型必须由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 header字段请求会话描述，则发送包含多部分消息体的请求的实现必须将会话描述作为非多部分消息体发送。
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消息可能包含二进制正文或正文部分。当发送方未提供显式字符集参数时，“text”类型的媒体子类型被定义为具有默认字符集值“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。（注意：分块编码修改消息体，以便将其作为一系列分块传输，每个分块都有自己的大小指示符。）
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或其他不可靠的数据报协议。每个这样的数据报携带一个请求或响应。参见第18节“不可靠运输的使用限制”。
Implementations processing SIP messages over stream-oriented transports MUST ignore any CRLF appearing before the start-line [H4.1].
通过面向流的传输处理SIP消息的实现必须忽略起始行[H4.1]之前出现的任何CRLF。
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.
内容长度头字段值用于定位流中每个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程序主要取决于两个因素。首先，基于请求或响应是在对话框内部还是外部，其次，基于请求的方法。第12节详细讨论了对话；它们表示用户代理之间的对等关系，并由特定的SIP方法（如INVITE）建立。
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、呼叫ID、Max FORWARD和Via；所有这些头字段在所有SIP请求中都是必需的。这六个报头字段是SIP消息的基本构建块，因为它们共同提供了大多数关键消息路由服务，包括消息寻址、响应路由、限制消息传播、消息排序和事务的唯一标识。这些头字段是对强制请求行的补充，强制请求行包含方法、请求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).
在对话框外部发送的请求示例包括建立会话的邀请（第13节）和查询功能的选项（第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).
消息的初始请求URI应设置为to字段中URI的值。一个显著的例外是寄存器方法；第10节给出了设置寄存器请求URI的行为。出于隐私原因或方便起见，将这些字段设置为相同的值也可能是不可取的（特别是如果发起UA期望在传输过程中更改请求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.
在某些特殊情况下，预先存在的路由集的存在可能会影响消息的请求URI。预先存在的路由集是一组有序的URI，用于标识服务器链，UAC将向其发送对话框之外的传出请求。通常，它们由用户或服务提供商在UA上手动配置，或通过其他一些非SIP机制配置。当提供商希望为UA配置出站代理时，建议为其提供一个预先存在的路由集，该路由集具有一个URI，即出站代理的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节中详述的填充请求URI和路由头字段的过程（即使没有对话框），使用所需的请求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 header字段首先指定请求的所需“逻辑”收件人，或作为此请求目标的用户或资源的记录地址。这可能是也可能不是请求的最终接收者。To头字段可以包含SIP或SIPS URI，但也可以在适当时使用其他URI方案（例如，tel URL（RFC 2806[9]）。所有SIP实现都必须支持SIP URI方案。任何支持TLS的实现都必须支持SIPS URI方案。“收件人标题”字段允许显示名称。
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 header字段。通常，用户会通过人机界面建议To头字段，可能是手动输入URI或从某种地址簿中选择URI。通常，用户不会输入完整的URI，而是输入一串数字或字母（例如，“bob”）。UA可自行决定如何解释该输入。使用字符串构成SIP URI的用户部分意味着UA希望在域中将名称解析到SIP URI中at符号的右侧（RHS）（例如，SIP:bob@example.com). 使用字符串构成SIPS URI的用户部分意味着UA希望安全通信，并且名称将在域中解析为at符号的RHS。RHS通常是请求者的主域，允许主域处理传出请求。这对于需要在主域中解释用户部分的“快速拨号”等功能非常有用。当UA不希望指定应解释用户输入的电话号码的域时，可以使用tel URL。相反，请求通过的每个域都将获得该机会。例如，机场中的用户可能登录并通过机场中的出站代理发送请求。如果他们输入“411”（这是美国本地目录帮助的电话号码），则需要由机场的出站代理进行解释和处理，而不是用户的主域。在这种情况下，电话：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标记；请求的“收件人”字段中的标记标识对话框的对等方。由于未建立对话框，因此不存在标记。
For further information on the To header field, see Section 20.39. The following is an example of a valid To header field:
有关“收件人”标题字段的更多信息，请参阅第20.39节。以下是“有效收件人”标题字段的示例：
To: Carol <sip:carol@chicago.com>
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 header字段指示请求发起方的逻辑标识，可能是用户的记录地址。与To header字段类似，它包含一个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 header字段允许显示名称。UAC应该使用显示名称“Anonymous”，以及语法正确但没有意义的URI（如sip:thisis@anonymous.invalid)，如果客户端的标识将保持隐藏状态。
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 header字段的值由用户或用户本地域的管理员预先设置。如果一个特定的UA被多个用户使用，那么它可能具有可切换的配置文件，其中包括与已配置用户的标识相对应的URI。请求的接收人可以对请求的发起人进行身份验证，以便根据其标题字段声明确定他们是谁（有关身份验证的更多信息，请参阅第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
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 header字段用作将一系列消息分组在一起的唯一标识符。对话中任一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
在UAC在任何对话框之外创建的新请求中，除非被方法特定行为覆盖，否则UAC必须选择Call ID header字段作为空间和时间上的全局唯一标识符。所有SIP UA必须有一种方法来保证它们生成的呼叫ID头字段不会被任何其他UA无意中生成。请注意，当请求在特定时间后重试时
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.
请求修改请求（例如，验证质询）的失败响应，这些重试请求不被视为新请求，因此不需要新的呼叫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.
建议在生成呼叫ID时使用加密随机标识符（RFC 1750[12]）。实施可使用以下表格“localid@host". 调用ID区分大小写，只需逐字节进行比较。
Using cryptographically random identifiers provides some protection against session hijacking and reduces the likelihood of unintentional Call-ID collisions.
使用加密随机标识符可以防止会话劫持，并降低意外调用ID冲突的可能性。
No provisioning or human interface is required for the selection of the Call-ID header field value for a request.
为请求选择Call ID header字段值不需要设置或人机界面。
For further information on the Call-ID header field, see Section 20.8.
有关Call ID header字段的更多信息，请参阅第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标题字段用作识别和订购交易的方法。它由一个序列号和一个方法组成。方法必须与请求的方法匹配。对于对话框之外的非寄存器请求，序列号值是任意的。序列号值必须可以表示为32位无符号整数，并且必须小于2**31。只要遵循上述准则，客户机就可以使用它想要选择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邀请
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标头字段用于限制请求在到达目的地的途中可以传输的跃点数。它由一个整数组成，每个跃点递减一。如果“最大转发”值在请求到达目的地之前达到0，则将以483（跳数过多）错误响应拒绝该请求。
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必须在其发起的每个请求中插入一个最大转发头字段，该字段的值应为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 header字段指示用于事务的传输，并标识要发送响应的位置。只有在选择了将用于到达下一跳的传输之后（这可能涉及使用[4]中的过程），才会添加Via标头字段值。
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。header字段中的协议名称和协议版本必须分别为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响应。如下所述，取消请求将具有与其取消的请求相同的分支参数值。如第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，分支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
由符合本规范的元素插入的分支ID必须始终以字符“z9hG4bK”开头。这7个字符被用作魔法cookie（7被认为足以确保较旧的RFC 2543实现不会选择这样的值），因此接收请求的服务器可以确定分支ID是以本文描述的方式构造的
specification (that is, globally unique). Beyond this requirement, the precise format of the branch token is implementation-defined.
规范（即，全局唯一）。除此之外，分支令牌的精确格式由实现定义。
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和由组件发送（第18节）。
Via processing for proxies is described in Section 16.6 Item 8 and Section 16.7 Item 3.
第16.6节第8项和第16.7节第3项描述了代理的Via处理。
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 header字段提供SIP或SIPS URI，可用于联系UA的特定实例以进行后续请求。联系人标头字段必须存在，并且在任何可能导致建立对话框的请求中，该字段必须仅包含一个SIP或SIPS URI。对于本规范中定义的方法，它仅包括INVITE请求。对于这些请求，联系人的范围是全局的。也就是说，Contact header字段值包含UA希望接收请求的URI，即使在任何对话框之外的后续请求中使用该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.
如果请求URI或顶部路由标头字段值包含SIPS URI，则联系人标头字段也必须包含SIPS URI。
For further information on the Contact header field, see Section 20.10.
有关联系人标题字段的更多信息，请参阅第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节）。
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定义的扩展在请求中被明确排除在支持的头字段之外，因为它们也经常用于记录供应商定义的扩展。
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
如果UAC希望坚持要求UAS理解UAC将应用于请求的扩展以处理请求，则必须在请求中插入Require header字段，列出该扩展的选项标记。如果UAC希望对请求进行延期，并坚持要求
traversed understand that extension, it MUST insert a Proxy-Require header field into the request listing the option tag for that extension.
要理解该扩展，它必须在请求中插入一个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节中所述的请求），则必须将程序应用于请求的请求URI。否则，这些过程将应用于请求中的第一个路由头字段值（如果存在），或者应用于请求的请求URI（如果不存在路由头字段）。这些过程产生一组有序的地址、端口和传输来尝试。与将哪个URI用作[4]过程的输入无关，如果请求URI指定SIPS资源，UAC必须遵循[4]的过程，就像输入URI是SIPS URI一样。
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
本地策略可以指定要尝试的备用目标集。如果请求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.
这确保了不添加记录路由头字段值的出站代理将从后续请求的路径中退出。它允许无法解析第一个路由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]中为有状态元素定义的过程，尝试每个地址，直到联系到服务器。每个try都构成一个新事务，因此每个try都带有一个带有新分支参数的不同顶部Via头字段值。此外，Via header字段中的transport值被设置为为为目标服务器确定的任何传输。
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（请求超时）状态代码。如果传输层报告了致命的传输错误（通常是由于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必须处理其不认为是183（会话进度）的任何不同于100的临时响应。UAC必须能够处理100和183个响应。
If more than one Via header field value is present in a response, the UAC SHOULD discard the message.
如果响应中存在多个Via标头字段值，UAC应丢弃该消息。
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响应状态代码）后，客户端应使用联系人标头字段中的URI根据重定向的请求制定一个或多个新请求。该过程类似于第16.5节和第16.6节详述的在3xx类响应上递归的代理。客户端从一个初始目标集开始，该初始目标集正好包含一个URI，即原始请求的请求URI。如果客户机希望基于对该请求的3xx类响应制定新请求，它会将URI放入目标集中。根据本规范中的限制，客户端可以选择将哪些联系人URI放入目标集中。与代理递归一样，处理3xx类响应的客户机不能将任何给定URI添加到目标集超过一次。如果原始请求在请求URI中具有SIPS URI，则客户端可以选择递归到非SIPS URI，但应通知用户重定向到不安全的URI。
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.
任何新请求本身都可能收到3xx响应，其中包含作为联系人的原始URI。可以将两个位置配置为相互重定向。在目标集中只放置一次任何给定URI可防止无限重定向循环。
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生成新的请求。一种常见的机制是根据联系人标题字段值中的“q”参数值对设置进行排序。对URI的请求可以串行或并行生成。一种方法是串行处理递减q值的组，并行处理每个q值组中的URI。另一种方法是仅以降低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）检测故障；对于网络错误，客户端事务将向事务用户报告任何传输层故障。请注意，一些响应代码（详见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.
当收到特定联系人地址的故障时，客户端应尝试下一个联系人地址。这将涉及到创建一个新的客户端事务来传递一个新的请求。
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必须将整个URI从目标集复制到请求URI中，但“方法参数”和“标头”URI参数除外（这些参数的定义见第19.1.1节）。它使用“header”参数为新请求创建标头字段值，根据第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>
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.
然后覆盖原始重定向请求中的任何主题标头字段，但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头字段值，例如。
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.
最后，一旦构建了新请求，它将使用新的客户端事务发送，因此必须在顶部的Via字段中有一个新的分支ID，如第8.1.1.7节所述。
In all other respects, requests sent upon receipt of a redirect response SHOULD re-use the header fields and bodies of the original request.
在所有其他方面，在收到重定向响应时发送的请求应重新使用原始请求的头字段和正文。
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.
在某些情况下，根据接收到的状态码和过期时间间隔的存在，联系人头字段值可以临时或永久地缓存在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节的授权程序，以使用凭据重试请求。
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（请求实体太大）响应（第21.4.11节），则请求包含的主体长度超过UAS愿意接受的长度。如果可能，UAC应该重试请求，要么省略正文，要么使用较小长度的正文。
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 header字段中列出的类型、响应中Accept Encoding header字段中列出的编码以及响应中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节），则请求URI使用服务器不支持的URI方案。客户端应该使用SIPURI重试该请求。
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（错误扩展）响应（第21.4.15节），则请求包含Require或Proxy Require标头字段，其中列出了代理或UAS不支持的功能的选项标记。UAC应重试该请求，这次将忽略响应中不支持的标头字段中列出的任何扩展。
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.
在上述所有情况下，通过创建具有适当修改的新请求来重试请求。这个新请求构成了一个新事务，并且应该具有与前一个请求相同的调用ID、To和From值，但是CSeq应该包含一个比前一个更高的新序列号。
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.
请注意，请求处理是原子的。如果请求被接受，则必须执行与其关联的所有状态更改。如果被拒绝，则不得执行所有状态更改。
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必须检查请求的方法。如果UAS识别但不支持请求的方法，则必须生成405（不允许方法）响应。第8.2.6节描述了生成响应的程序。UAS还必须向405（方法不允许）响应中添加允许标头字段。Allow header字段必须列出生成消息的UAS支持的方法集。第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应忽略处理请求时不需要的任何格式错误的标头字段。
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
“收件人标头”字段标识由“发件人”字段中标识的用户指定的请求的原始收件人。由于呼叫转移或其他代理操作，原始收件人可能是也可能不是处理请求的UAS。UAS可以应用其希望确定是否接受请求的任何策略
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.
标头字段不是UAS的标识。但是，建议UAS接受请求，即使它们不识别To标头字段中的URI方案（例如，tel:URI），或者如果To标头字段未寻址此UAS的已知或当前用户。另一方面，如果UAS决定拒绝请求，它应该生成一个带有403（禁止）状态代码的响应，并将其传递给服务器事务进行传输。
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.
但是，请求URI标识要处理请求的UAS。如果请求URI使用UAS不支持的方案，则它应使用416（不支持的URI方案）响应拒绝请求。如果请求URI未标识UAS愿意接受请求的地址，则应使用404（未找到）响应拒绝请求。通常，使用REGISTER方法将其记录地址绑定到特定联系人地址的UA将看到其请求URI等于该联系人地址的请求。收到的请求URI的其他潜在来源包括UA发送的建立或刷新对话框的请求和响应的联系人标头字段。
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 header字段中没有标记，UAS core必须根据正在进行的事务检查请求。如果From标记、呼叫ID和CSeq与正在进行的事务相关联的标记、呼叫ID和CSeq完全匹配，但请求与该事务不匹配（根据第17.2.3节中的匹配规则），则UAS core应生成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确定它是处理请求的适当元素，它将检查Require头字段（如果存在）。
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使用Require header字段告诉UAS UAC希望UAS支持的SIP扩展，以便正确处理请求。其格式见第20.32节。如果UAS不理解Require标头字段中列出的选项标记，则必须通过生成状态代码为420（错误扩展）的响应进行响应。UAS必须添加一个不受支持的标题字段，并在其中列出在请求的Require header字段中它不理解的选项。
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取消请求，也不能用于为非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
UAC->UAS: INVITE sip:watson@bell-telephone.com SIP/2.0
Require: 100rel
UAS->UAC: SIP/2.0 420 Bad Extension
Unsupported: 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将检查消息体以及描述消息的头字段。如果有任何主体的类型（由内容类型指示）、语言（由内容语言指示）或编码（由内容编码指示）不被理解，并且该主体部分不是可选的（由内容处置头字段指示），UAS必须以415（不支持的媒体类型）拒绝请求回答如果请求包含UAS不支持的类型的主体，则响应必须包含一个Accept header字段，其中列出了它所理解的所有主体的类型。如果请求包含UAS不理解的内容编码，则响应必须包含一个Accept Encoding标头字段，列出UAS理解的编码。如果请求包含UAS无法理解的语言内容，则响应必须包含表示UAS可以理解的语言的Accept Language header字段。除了这些检查，车身处理取决于方法和类型。有关处理特定于内容的标题字段的更多信息，请参阅第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不得这样做，除非在请求中的Supported header字段中指示对该扩展的支持。如果不支持所需的扩展，则服务器应仅依赖于基线SIP和客户端支持的任何其他扩展。在极少数情况下，如果服务器无法处理没有扩展名的请求，服务器可能会发送421（需要扩展名）响应。此响应表示如果没有特定扩展的支持，就无法生成正确的响应。所需的扩展必须包含在响应的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 header字段中列出。当然，服务器不能应用请求中支持的标头字段中未列出的扩展。因此，响应中的Require header字段将只包含在标准跟踪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节介绍注册请求，第11节介绍选项请求，第13节介绍邀请请求，第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.
生成响应的一个基本上不特定于方法的准则是，UAS不应为非INVITE请求发出临时响应。相反，UAS应该尽快生成对非INVITE请求的最终响应。
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（尝试）响应时，必须将请求中存在的任何时间戳头字段复制到此100（尝试）响应中。如果在生成响应时存在延迟，UAS应在响应中的时间戳值中添加延迟值。此值必须包含发送响应和接收请求之间的时间差（以秒为单位）。
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 header字段添加标记（100（尝试）响应除外，其中可能存在标记）。这用于识别正在响应的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
无状态UAS角色主要用于处理发出质询响应的未经验证的请求。如果未经身份验证的请求被有状态地处理，那么未经身份验证的请求的恶意泛滥可能会造成大量的错误
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中呼叫处理的事务状态，从而有效地造成拒绝服务条件；有关更多信息，请参见第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）响应。
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必须忽略取消请求。
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 必须以无状态的方式为响应生成To头标记—以一致地为相同请求生成相同标记的方式。有关标签构造的信息，请参见第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目标的一个或多个备选位置之间的映射。
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
重定向服务器不会发出自己的任何SIP请求。在接收到除“取消”之外的请求后，服务器会拒绝该请求或从服务器收集替代位置列表
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.
定位服务，并返回3xx类的最终响应。对于格式正确的取消请求，它应该返回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响应时，它会将（一个或多个）备选位置列表填充到Contact header字段中。还可以向联系人标头字段值提供“expires”参数，以指示联系人数据的生存期。
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 header字段包含URI，这些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.
但是，重定向服务器不能将请求重定向到与请求URI中的URI相同的URI；相反，如果URI不指向自身，服务器可以将请求代理到目标URI，或者可以使用404拒绝它。
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."
请注意，联系人标头字段值也可能引用与最初调用的资源不同的资源。例如，连接到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 response header字段可以包含任何适当的URI，指示可以到达被叫方的位置，但不限于SIPURI。例如，它可以包含电话、传真或irc（如果已定义）的URI或mailto:（RFC 2368[32]）URL。第26.4.4节讨论了将SIPS URI重定向到非SIPS 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.
联系人标头字段值的“expires”参数指示URI的有效期。该参数的值是一个表示秒数的数字。如果未提供此参数，则Expires标头字段的值确定URI的有效期。格式错误的值应视为等同于3600。
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.
重定向服务器必须忽略无法理解的功能（包括无法识别的头字段、Require中的任何未知选项标记，甚至方法名称），然后继续重定向相关请求。
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停止处理该请求，并对该请求生成错误响应。取消对UAS已经给出最终响应的请求没有影响。因此，最有用的方法是取消服务器可能需要很长时间才能响应的请求。因此，CANCEL最适合于INVITE请求，因为生成响应可能需要很长时间。在这种用法中，收到取消邀请请求但尚未发送最终响应的UAS将“停止振铃”，然后用特定的错误响应（a 487）响应邀请。
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.
取消请求可以由代理和用户代理客户端构造和发送。第15节讨论了UAC在什么情况下会取消邀请请求，第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被称为“逐跳”请求，因为它在每个有状态的代理跃点都会被响应。
A CANCEL request SHOULD NOT be sent to cancel a request other than INVITE.
不应发送取消请求来取消邀请以外的请求。
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请求发送取消将始终创建竞争条件。
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请求中的请求URI、调用ID、To、CSeq的数字部分和From头字段必须与被取消的请求中的字段相同，包括标记。客户端构造的取消必须只有一个与被取消请求中的顶部通过值匹配的通过头字段值。对这些标题字段使用相同的值，可以将取消与它取消的请求进行匹配（第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.
这是必要的，以便无状态代理能够正确路由取消请求。
The CANCEL request MUST NOT contain any Require or Proxy-Require header fields.
取消请求不得包含任何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").
一旦构建了取消，客户应检查其是否已收到被取消请求（此处称为“原始请求”）的任何响应（临时或最终）。
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.
如果未收到临时响应，则不得发送取消请求；相反，客户端在发送请求之前必须等待临时响应的到来。如果原始请求已生成最终响应，则不应发送取消，因为它是有效的no op，因为取消对已生成最终响应的请求没有影响。当客户端决定发送取消时，它会为取消创建一个客户端事务，并将取消请求连同目标地址、端口和传输一起传递给它。取消的目标地址、端口和传输必须与用于发送原始请求的地址、端口和传输相同。
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.
如果允许服务器在收到前一个请求的响应之前发送取消，则服务器可以在原始请求之前接收取消。
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
请注意，与原始请求相对应的事务和取消事务都将独立完成。然而，取消请求的UAC不能依赖于接收原始请求的487（请求终止）响应，因为符合RFC2543的UAS不会生成这样的响应。如果在64*T1秒内没有原始请求的最终响应（T1为
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.
在第1.1.1.1节中定义，客户端应该考虑原始事务被取消，并且应该破坏处理原始请求的客户端事务。
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或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.
服务器上取消请求的处理取决于服务器的类型。无状态代理将转发它，有状态代理可能会响应它并生成自己的一些取消请求，UAS将响应它。有关取消的代理处理，请参见第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处理来处理取消请求。但是，由于取消请求是逐跳的，无法重新提交，因此服务器无法对其进行质询，以便在授权标头字段中获取正确的凭据。还要注意，取消请求不包含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未根据上述程序找到与取消匹配的交易，则应使用481响应取消（呼叫分支/交易不存在）。如果原始请求的事务仍然存在，UAS在接收取消请求时的行为取决于其是否已发送原始请求的最终响应。如果有，取消请求对原始请求的处理没有影响，对任何会话状态没有影响，对为原始请求生成的响应也没有影响。如果UAS没有对原始请求发出最终响应，则其行为取决于原始请求的方法。如果原始请求是邀请，UAS应立即以487（请求终止）响应邀请。取消请求不会影响使用本规范中定义的任何其他方法处理事务。
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.
不管原始请求的方法是什么，只要取消匹配现有事务，UAS就会用200（确定）响应来回答取消请求本身。该响应按照第8.2.6节中描述的程序构造，注意取消响应的To标记和原始请求响应中的To标记应相同。取消响应被传递到服务器事务以进行传输。
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，例如，对于某种程度上“更接近”所需用户的一个或多个URI，sip：bob@engineering.biloxi.com例如最终，代理将咨询位置服务，该服务将接收到的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的地址与一个或多个联系人地址相关联。因此，当该域的代理收到请求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.
有许多方法可以建立位置服务的内容。一种方法是行政管理。在上面的示例中，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发送注册请求。注册器充当域位置服务的前端，根据注册请求的内容读取和写入映射。然后，负责为该域路由请求的代理服务器通常会咨询此位置服务。
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
整个注册过程如图2所示。注意，注册器和代理服务器是可以由网络中的单个设备扮演的逻辑角色；为了
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.
在本图中，这两者是分开的。还请注意，如果代理服务器和注册服务器是独立的元素，UAs可能会通过代理服务器发送请求以到达注册服务器。
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.
注册请求添加、删除和查询绑定。注册请求可以在记录地址和一个或多个联系人地址之间添加新绑定。代表特定记录地址的注册可由适当授权的第三方执行。客户机还可以删除以前的绑定或查询，以确定记录地址的当前绑定。
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.
除非另有说明，否则注册请求的构造和客户端发送注册请求的行为与第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.
注册请求不建立对话框。UAC可根据第8.1节所述的预先存在的路由集，在注册请求中包含路由头字段。记录路由头字段在注册请求或响应中没有意义，如果存在，则必须忽略。特别是，UAC不得基于对注册请求的任何响应中是否存在记录路由头字段来创建新路由集。
The following header fields, except Contact, MUST be included in a REGISTER request. A Contact header field MAY be included:
注册请求中必须包括以下标题字段（联系人除外）。可包括联系人标题字段：
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.
请求URI：请求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.
收件人：收件人标题字段包含要创建、查询或修改其注册的记录的地址。“收件人标头”字段和“请求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.
发件人：发件人标题字段包含负责注册的人员的记录地址。除非请求是第三方注册，否则该值与“收件人标头”字段相同。
Call-ID: All registrations from a UAC SHOULD use the same Call-ID header field value for registrations sent to a particular registrar.
呼叫ID：来自UAC的所有注册应使用相同的呼叫ID头字段值用于发送到特定注册器的注册。
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.
如果同一客户机使用不同的调用ID值，则注册器无法检测延迟的注册请求是否出现故障。
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值保证寄存器请求的正确顺序。UA必须为具有相同调用ID的每个寄存器请求将CSeq值增加1。
Contact: REGISTER requests MAY contain a Contact header field with zero or more values containing address bindings.
联系人：注册请求可能包含一个联系人标头字段，该字段具有零个或多个包含地址绑定的值。
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.
UAs不得发送新的注册（即，包含新的联系人标头字段值，而不是重新传输），直到收到来自注册商的前一个注册的最终响应或前一个注册请求超时。
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
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:
以下联系人标头参数在注册请求中具有特殊意义：
action: The "action" parameter from RFC 2543 has been deprecated. UACs SHOULD NOT use the "action" parameter.
操作：RFC 2543中的“操作”参数已被弃用。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。格式错误的值应视为等同于3600。
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.
发送给注册商的注册请求包括SIP记录地址请求应转发到的联系地址。记录的地址包含在寄存器请求的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 header字段值通常由标识特定SIP端点的SIP或SIPS URI组成（例如，“SIP:carol@cube2214a.chicago.com），但它们可以使用任何URI方案。例如，SIP UA可以选择将电话号码（使用电话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.
例如，Carol，记录地址为“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.
一旦客户机在注册器上建立了绑定，它可以根据需要发送包含新绑定或对现有绑定的修改的后续注册。对REGISTER请求的2xx响应将在Contact header字段中包含一个完整的绑定列表，这些绑定已在该注册器中针对该记录地址注册。
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.
如果注册请求的To头字段中的记录地址是SIPS URI，则请求中的任何联系人头字段值也应该是SIPS URI。当联系人地址所代表的资源的安全性通过其他方式得到保证时，客户端应仅在SIPS记录地址下注册非SIPS 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.)
当客户端发送注册请求时，它可能会建议一个过期时间间隔，该时间间隔指示客户端希望注册有效的时间。（如第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标头参数。后者允许在单个寄存器请求中提供多个绑定时，根据每个绑定建议过期时间间隔，而前者为不包含“expires”参数的所有联系人标头字段值建议过期时间间隔。
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.
如果寄存器中不存在表示建议过期时间的机制，则客户端表示希望服务器进行选择。
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.
如果在注册请求中发送了多个联系人，则注册UA打算将这些联系人标头字段值中的所有URI与“收件人”字段中的记录地址相关联。此列表可以通过联系人标题字段中的“q”参数进行优先级排序。“q”参数表示与此记录地址的其他绑定相比，特定联系人标头字段值的相对首选项。第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通过在注册请求中为联系人地址指定“0”的过期时间间隔来请求立即删除绑定。UAs应该支持这种机制，以便在绑定过期之前将其删除。
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".
特定于注册的联系人标头字段值“*”适用于所有注册，但除非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.
使用“*”联系人标头字段值允许注册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.
对任何注册请求的成功响应都包含现有绑定的完整列表，无论该请求是否包含联系人标头字段。如果注册请求中不存在联系人标头字段，则绑定列表保持不变。
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设置的绑定。
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）响应包含一个联系人字段列表，列出了所有当前绑定。UA使用第19.1.4节中的比较规则，比较每个联系人地址，查看是否创建了联系人地址。如果是，它将根据expires参数或expires字段值（如果不存在）更新过期时间间隔。然后，UA在过期时间间隔过去之前为其每个绑定发出注册请求。它可以将多个更新合并到一个注册请求中。
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应在单个引导周期内对所有注册使用相同的呼叫ID。除非重定向，否则注册刷新应发送到与原始注册相同的网络地址。
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.
如果注册请求的响应包含日期标头字段，则客户端可以使用此标头字段来了解当前时间，以便设置任何内部时钟。
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".
UAs可以使用三种方式来确定向其发送注册的地址：通过配置、使用记录地址和多播。UA可以使用注册器地址以超出本规范范围的方式进行配置。如果没有配置的注册器地址，UA应使用记录地址的主机部分作为请求URI，并使用正常的SIP服务器定位机制在那里寻址请求[4]。例如，用户“sip:carol@chicago.com将注册请求发送到“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 UAs可以监听该地址，并使用该地址了解其他本地用户的位置（参见[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.
一旦构建了寄存器方法，并确定了消息的目的地，UAC将按照第8.1.2节所述的程序将寄存器移交给事务层。
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.
如果事务层由于寄存器未产生响应而返回超时错误，则UAC不应立即重新尝试向同一注册器注册。
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（间隔太短）响应，则在使寄存器请求中所有联系人地址的过期间隔等于或大于423（间隔太短）响应的Min Expires报头字段中的过期间隔后，UA可以重试注册。
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.
注册器是一个UAS，它响应注册请求并维护一个绑定列表，代理服务器和重定向服务器可以在其管理域内访问这些绑定。注册员根据第8.2节和第17.2节处理请求，但只接受注册请求。注册员不得生成6xx响应。
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.
注册官可根据情况重定向注册请求。一种常见的用法是，注册器在多播接口上侦听，以302（临时移动）响应将多播注册请求重定向到其自己的单播接口。
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.
如果记录路由头字段包含在注册请求中，注册者必须忽略该字段。登记员不得在对登记请求的任何响应中包含记录路由头字段。
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.
注册器可能会收到一个请求，该请求遍历了一个代理，该代理将注册视为一个未知请求，并添加了一个记录路由头字段值。
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.
注册器必须知道（例如，通过配置）它维护绑定的域集。注册请求必须由注册官按照接收顺序进行处理。注册请求还必须以原子方式处理，这意味着特定的注册请求要么完全处理，要么根本不处理。必须独立于任何其他注册或绑定更改来处理每个注册消息。
When receiving a REGISTER request, a registrar follows these steps:
当收到注册请求时，注册员遵循以下步骤：
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. 注册器检查请求URI以确定它是否可以访问请求URI中标识的域的绑定。如果不是，并且服务器还充当代理服务器，则服务器应按照第16节中描述的代理消息的一般行为将请求转发到寻址域。
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所需的报头字段值。
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。第22节描述了SIP用户代理的认证机制。注册行为决不会覆盖SIP的通用身份验证框架。如果没有可用的身份验证机制，注册官可以将发件人地址作为请求发起人的断言身份。
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. 注册官应确定认证用户是否有权修改该记录地址的注册。例如，注册员可以查阅授权数据库，该数据库将用户名映射到该用户有权修改绑定的记录地址列表。如果经过身份验证的用户无权修改绑定，则注册器必须返回403（禁止）并跳过其余步骤。
In architectures that support third-party registration, one entity may be responsible for updating the registrations associated with multiple addresses-of-record.
在支持第三方注册的体系结构中，一个实体可能负责更新与多个记录地址相关联的注册。
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头字段中提取记录地址。如果记录地址对于请求URI中的域无效，则注册器必须发送404（未找到）响应并跳过其余步骤。然后必须将URI转换为规范形式。为此，必须删除所有URI参数（包括用户参数），并且必须将任何转义字符转换为其未转义形式。结果用作绑定列表的索引。
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. 注册员检查请求是否包含联系人标头字段。如果没有，则跳到最后一步。如果存在联系人标题字段，则注册官会检查是否有一个联系人字段值包含特殊值“*”和Expires字段。如果请求有其他联系人字段或过期时间不是零，则该请求无效，服务器必须返回400（无效请求）并跳过其余步骤。如果没有，注册器将检查调用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. 登记员现在依次处理联系人标题字段中的每个联系人地址。对于每个地址，它确定到期时间间隔如下：
- 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标头字段，则该值必须作为请求的过期。
- 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.
注册官可以选择小于请求的到期时间间隔的到期时间。如果且仅当所请求的到期间隔大于零且小于一小时且小于注册器配置的最小值时，注册器可以423的响应（间隔太短）拒绝注册。此响应必须包含一个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.
允许注册器设置注册间隔可以防止过度频繁的注册刷新，同时限制需要维护的状态并降低注册过期的可能性。注册的过期时间间隔经常用于创建服务。一个例子是follow me服务，其中用户可能仅在终端短暂地可用。因此，登记员应接受简短登记；只有当间隔很短，刷新会降低注册器性能时，才应拒绝请求。
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比较规则搜索当前绑定的列表。如果绑定不存在，则暂时添加该绑定。如果绑定确实存在，注册器将检查调用ID值。如果现有绑定中的调用ID值与请求中的调用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.
每个绑定记录记录请求中的调用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（服务器错误）响应，并且必须删除所有临时绑定更新。
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）响应。响应必须包含枚举所有当前绑定的联系人标头字段值。每个联系人值必须具有一个“expires”参数，该参数指示注册器选择的过期时间间隔。响应应包括日期标题字段。
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方法选项允许UA向另一UA或代理服务器查询其能力。这允许客户端发现有关支持的方法、内容类型、扩展、编解码器等的信息，而无需“打电话”给另一方。例如，在客户机将Require头字段插入到INVITE中，列出一个不确定目标UAS支持的选项之前，客户机可以使用选项查询目标UAS，以查看该选项是否在支持的头字段中返回。所有UAs必须支持选项方法。
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请求的目标由请求URI标识，该URI可以标识另一个UA或SIP服务器。如果这些选项指向代理服务器，则设置请求URI时不使用用户部分，类似于为注册请求设置请求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.
或者，接收最大转发头字段值为0的选项请求的服务器可以响应该请求，而不考虑请求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中很常见。此行为可用作“跟踪路由”功能，通过发送一系列带有递增最大转发值的选项请求来检查各个跃点服务器的功能。
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行为一样，如果选项不产生响应，事务层可以返回超时错误。这可能表明目标无法到达，因此不可用。
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.
选项请求可以作为已建立对话框的一部分发送，以查询对等方在该对话框中稍后可能使用的功能。
An OPTIONS request is constructed using the standard rules for a SIP request as discussed in Section 8.1.1.
使用第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).
应包括Accept header字段，以指示UAC希望在响应中接收的消息正文类型。通常，这被设置为用于描述UA的媒体能力的格式，例如SDP（应用程序/SDP）。
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.
假设对选项请求的响应范围为原始请求中的请求URI。但是，只有当选项作为已建立对话框的一部分发送时，才能保证生成选项响应的服务器将收到未来的请求。
Example OPTIONS request:
选项请求示例：
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
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.
对选项的响应使用第8.2.6节中讨论的SIP响应标准规则构建。选择的响应代码必须与请求为邀请时选择的响应代码相同。也就是说，如果UAS准备好接受呼叫，将返回200（确定），如果UAS忙，将返回486（此处忙），等等。这允许使用选项请求来确定UAS的基本状态，这可以指示UAS是否将接受INVITE请求。
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.
在对话框内接收的选项请求生成200（确定）响应，该响应与在对话框外构造的响应相同，并且不会对对话框产生任何影响。
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.
由于选项和INVITE请求的代理处理方式不同，因此使用选项具有局限性。虽然forked INVITE可能会返回多个200（OK）响应，但forked OPTIONS只会返回一个200（OK）响应，因为它由代理使用非INVITE处理进行处理。有关规范性详细信息，请参见第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.
如果对选项的响应是由代理服务器生成的，则代理服务器将返回200（确定），列出服务器的功能。响应不包含消息正文。
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.
允许、接受、接受编码、接受语言和支持的标题字段应出现在对选项请求的200（确定）响应中。如果响应是由代理生成的，则应忽略Allow header字段，因为它是不明确的，因为代理是方法无关的。联系人标头字段可能出现在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].
可以发送消息正文，其类型由选项请求中的Accept header字段确定（如果Accept header字段不存在，则默认为application/sdp）。如果类型包括一个可以描述媒体能力的类型，UAS应该在响应中包含一个主体。[13]中描述了应用/sdp情况下此类主体的构造细节。
Example OPTIONS response generated by a UAS (corresponding to the request in Section 11.1):
UAS生成的选项响应示例（对应于第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
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.
用户代理的一个关键概念是对话框。对话框表示两个用户代理之间持续一段时间的对等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上都有一个对话框ID，该ID由呼叫ID值、本地标记和远程标记组成。对话中涉及的每个UA的对话ID不相同。具体地说，一个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
对话框ID还与所有响应以及“收件人”字段中包含标记的任何请求相关联。计算消息对话框ID的规则取决于SIP元素是UAC还是UAS。对于UAC，对话框ID的Call ID值设置为消息的Call ID，远程标记设置为消息的to字段中的标记，本地标记设置为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.
消息字段（这些规则适用于请求和响应）。正如人们对UAS的期望，对话框ID的Call ID值设置为消息的Call ID，远程标记设置为消息的From字段中的标记，本地标记设置为消息的to字段中的标记。
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.
对话框是通过使用特定方法生成对请求的无故障响应来创建的。在本规范中，只有2xx和101-199带有To标记的响应（请求被邀请的位置）将建立一个对话框。由请求的非最终响应建立的对话框处于“早期”状态，称为早期对话框。扩展可以定义创建对话框的其他方法。第13节给出了INVITE方法特有的更多细节。这里，我们描述了创建不依赖于方法的对话框状态的过程。
UAs MUST assign values to the dialog ID components as described below.
UAs必须为对话框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
当UAS使用建立对话框的响应（如2xx to INVITE）响应请求时，UAS必须将所有记录路由标头字段值从请求复制到响应中（包括URI、URI参数和任何记录路由标头字段参数，无论UAS是否知道）并且必须保持这些值的顺序。UAS必须在响应中添加联系人标题字段。Contact header字段包含一个地址，在该地址中，UAS希望在对话框中的后续请求中与之联系（如果是邀请，则包括2xx响应的ACK）。通常，此URI的主机部分是主机的IP地址或FQDN。联系人标头字段中提供的URI必须是SIP或SIPS URI。如果启动对话框的请求包含
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.
请求URI或顶部记录路由标头字段值中的SIPS URI（如果有）或联系人标头字段（如果没有记录路由标头字段），响应中的联系人标头字段必须是SIPS URI。URI应该具有全局作用域（也就是说，在该对话框之外的消息中可以使用相同的URI）。同样，INVITE的Contact header字段中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到达，并且请求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 header字段中的URI列表，按顺序排列并保留所有URI参数。如果请求中不存在记录路由标头字段，则必须将路由集设置为空集。此路由集即使为空，也会覆盖此对话框中未来请求的任何预先存在的路由集。远程目标必须从请求的Contact header字段设置为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的调用标识符组件必须设置为请求中调用ID的值。对话框ID的本地标记组件必须设置为请求响应中“收件人”字段中的标记（始终包含标记），而对话框ID的远程标记组件必须设置为请求中“发件人”字段中的标记。UAS必须准备好接收From字段中没有标记的请求，在这种情况下，标记的值被视为null。
This is to maintain backwards compatibility with RFC 2543, which did not mandate From tags.
这是为了保持与RFC 2543的向后兼容性，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必须设置为“发件人”字段中的URI，本地URI必须设置为“收件人”字段中的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可用于此对话之外的消息）。如果请求具有请求URI或具有SIPS URI的最顶端路由标头字段值，则联系人标头字段必须包含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发送，并且请求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.
路由集必须设置为响应中记录路由头字段中的URI列表，按相反顺序进行，并保留所有URI参数。如果响应中不存在记录路由标头字段，则必须将路由集设置为空集。此路由集即使为空，也会覆盖此对话框中未来请求的任何预先存在的路由集。远程目标必须从响应的Contact header字段设置为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的调用标识符组件必须设置为请求中调用ID的值。对话框ID的本地标记组件必须设置为请求的“发件人”字段中的标记，而对话框ID的远程标记组件必须设置为响应的“收件人”字段中的标记。UAC必须准备好接收到to字段中没有标记的响应，在这种情况下，标记的值被视为null。
This is to maintain backwards compatibility with RFC 2543, which did not mandate To tags.
这是为了保持与RFC 2543的向后兼容性，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必须设置为“收件人”字段中的URI，本地URI必须设置为“发件人”字段中的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.
一旦两个UAs之间建立了对话，其中任何一个都可以根据需要在对话中启动新的事务。发送请求的UA将担任事务的UAC角色。接收请求的UA将担任UAS角色。请注意，这些角色可能与建立对话框的交易期间持有的UAs不同。
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
对话框中的请求可能包含记录路由和联系人标头字段。但是，这些请求不会导致修改对话框的路由集，尽管它们可能会修改远程目标URI。具体来说，不是目标刷新请求的请求不会修改对话框的远程目标URI，而作为目标刷新请求的请求会修改对话框的远程目标URI。对于已使用
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.
INVITE，唯一定义的目标刷新请求是REINVITE（请参阅第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，而不更新从记录路由形成的路由集。更新后者将导致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.
请求的“收件人”字段中的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是为了向后兼容RFC 2543，RFC 2543使用URI进行对话框标识。在本规范中，只有标签用于对话框标识。在本规范的后续版本中，预期在mid对话请求中强制反射原始的往返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.
请求的调用ID必须设置为对话框的调用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位的长度，一个客户端可以在一次调用中每秒生成一个请求，持续约136年，然后才需要结束。选择序列号的初始值，以便同一调用中的后续请求不会环绕。非零初始值允许客户端使用基于时间的初始序列号。例如，客户机可以选择32位秒时钟的31个最高有效位作为初始序列号。
The UAC uses the remote target and route set to build the Request-URI and Route header field of the request.
UAC使用远程目标和路由集来构建请求的请求URI和路由头字段。
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放入请求URI中。UAC不得向请求中添加路由头字段。
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放入请求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放入请求URI，去掉请求URI中不允许的任何参数。UAC必须按顺序添加包含剩余路由集值（包括所有参数）的路由头字段。然后UAC必须将远程目标URI作为最后一个值放入Route header字段中。
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>
<sip:proxy1>,<sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>
The request will be formed with the following Request-URI and Route header field:
请求将由以下请求URI和路由头字段组成：
METHOD sip:proxy1
Route: <sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>,<sip:user@remoteua>
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
如果路由集的第一个URI不包含lr参数，则指示的代理不理解本文档中描述的路由机制，并将按照RFC 2543中的规定行事，在转发消息时用它接收的第一个路由头字段值替换请求URI。将请求URI放在Route header字段的末尾将保留
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中的信息（当请求到达松散路由器时，它将返回到请求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应在对话框中的任何目标刷新请求中包含联系人标头字段，除非需要更改，否则URI应与对话框中以前请求中使用的URI相同。如果“secure”标志为true，则该URI必须是SIPS URI。如第12.2.2节所述，目标刷新请求中的联系人标头字段更新远程目标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节中的程序通常会导致将请求发送到最顶端的路由头字段值或请求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（请求超时）响应。
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.
对于在对话框内发送的请求，UAC接收3xx响应的行为与在对话框外发送的请求相同。第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尝试其他位置时，它仍然使用为对话框设置的路由来构建请求的路由头。
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（如果存在）替换对话框的远程目标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应终止对话框。如果没有收到任何请求响应，UAC也应该终止对话框（客户端事务将通知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.
请注意，某些请求（如邀请）会影响多个状态。
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核心计算与请求对应的对话框标识符，并将其与现有对话框进行比较。如果存在匹配项，则这是一个mid对话框请求。在这种情况下，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可以构造To标记，以便UAS可以识别该标记是针对其正在提供恢复的UAS的）. 另一种可能是传入的请求只是被错误路由了。根据To标签，UAS可以接受或拒绝请求。接受可接受标记的请求提供了健壮性，因此对话框即使在崩溃时也可以保持。希望支持此功能的UAs必须考虑一些问题，例如选择单调递增的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.
在对话框中可以接收不以任何方式更改对话框状态的请求（例如，选项请求）。它们的处理方式就像是在对话框外部接收到的一样。
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序列号可能比远程序列号高出一个以上。这不是错误情况，UAS应准备接收和处理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（如果存在）替换对话框的远程目标URI。
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
当用户代理客户端希望启动会话（例如，音频、视频或游戏）时，它会制定一个INVITE请求。INVITE请求请求服务器建立会话。该请求可由代理转发，最终到达可能接受邀请的一个或多个UAS。这些UAS经常需要向用户查询是否接受该请求
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.
邀请一段时间后，这些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将得到一个或多个2xx响应或一个非2xx最终响应。由于接收INVITE的最终响应可能需要较长的时间，INVITE事务的可靠性机制与其他请求（如选项）的可靠性机制不同。一旦收到最终响应，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之间创建一个对话框。因此，当从不同的远程UAs接收到多个2xx响应时（因为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.
邀请中应存在允许标题字段（第20.5节）。它指示在对话框期间，在发送INVITE的UA上，可以在对话框内调用哪些方法。例如，能够在对话框[34]中接收信息请求的UA应包括列出信息方法的Allow header字段。
A Supported header field (Section 20.37) SHOULD be present in the INVITE. It enumerates all the extensions understood by the UAC.
邀请中应包含受支持的标题字段（第20.37节）。它列举了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.
邀请中可能存在接受（第20.1节）标题字段。它在UA接收到的响应以及在INVITE建立的对话框中发送给UA的任何后续请求中指示UA可接受的内容类型。Accept header字段对于指示支持各种会话描述格式特别有用。
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节），以限制邀请的有效性。如果达到Expires标头字段中指示的时间且未收到邀请的最终答复，则UAC核心应根据第9节生成邀请的取消请求。
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可能还发现，添加主题（第20.36节）、组织（第20.25节）和用户代理（第20.41节）标题字段等也很有用。它们都包含与邀请相关的信息。
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可以选择向邀请添加消息正文。第8.1.1.10节讨论了如何构造描述消息体所需的标题字段（内容类型等）。
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:
对于包含会话描述的消息体，有一些特殊的规则——它们对应的内容配置是“会话”。SIP使用提供/应答模型，其中一个UA发送一个会话描述，称为提供，其中包含会话的建议描述。要约表明了期望的通信手段（音频、视频、游戏）、这些手段的参数（例如编解码器类型）以及从应答者接收媒体的地址。另一个UA用另一个会话描述（称为应答）进行响应，该会话描述指示接受哪些通信手段、适用于这些手段的参数以及从报价人接收媒体的地址。提供/应答交换在对话框的上下文中，因此，如果SIP INVITE导致多个对话框，则每个对话框都是单独的提供/应答交换。“报价/答复”模型定义了对何时可以提供报价和答复的限制（例如，在进行报价时不能提供新报价）。这导致限制了在SIP消息中提供和应答的位置。在本规范中，提供和回答只能出现在邀请请求和响应以及确认中。提议和答复的使用受到进一步限制。对于初始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 初始报价必须包含在邀请函中，如果没有，则包含在从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 如果初始报价是在邀请中，则答案必须是从UAS返回给UAC的可靠无故障消息，该消息与该邀请相关。对于本规范，这只是对该邀请的最终2xx响应。同样的确切答案也可以放在答复之前发送的任何临时答复中。UAC必须将收到的第一个会话描述视为答案，并且必须在对初始邀请的后续响应中忽略任何会话描述。
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响应的确认）。
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发送或接收到对初始邀请的回复，它不得在对初始邀请的任何响应中生成后续邀请。这意味着，仅基于此规范的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.
具体地说，上述规则规定了仅符合本规范的UAs的两种交换——报价在INVITE中，答案在2xx中（可能也在1xx中，具有相同的值），或者报价在2xx中，答案在ACK中。所有支持INVITE的用户代理都必须支持这两种交换。
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)).
刚才描述的要约-应答模型的限制仅适用于内容处置头字段值为“session”的主体。因此，INVITE和ACK都可能包含正文消息（例如，INVITE携带照片（内容处置：呈现），ACK携带会话描述（内容处置：会话））。
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 header字段，则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的响应。如第8.1.3节所述，如果INVITE客户端事务返回的是超时而不是响应，则TU的行为就好像收到了408（请求超时）响应一样。
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.
在收到一个或多个最终响应之前，可能会收到零个、一个或多个临时响应。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事务完成之前向对话框中的对等方发送请求时，才需要早期对话框。只要对话框处于早期状态，临时响应中的标题字段就适用（例如，临时响应中的允许标题字段包含对话框处于早期状态时可以使用的方法）。
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响应可能包含一个或多个联系人标头字段值，这些字段值提供了被呼叫方可以访问的新地址。根据3xx响应的状态代码（参见第21.3节），UAC可以选择尝试这些新地址。
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.
可能会收到邀请的单个非2xx最终响应。4xx、5xx和6xx响应可能包含一个Contact header字段值，该字段值指示可以找到有关错误的其他信息的位置。必须忽略后续的最终响应（只有在错误条件下才会到达）。
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 client事务处理响应的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.
由于分叉代理，对于单个INVITE请求，可能会有多个2xx响应到达UAC。每个响应都通过To header字段中的tag参数进行区分，每个响应都表示一个具有不同对话框标识符的不同对话框。
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.1.2节中的程序基于2xx响应重新计算对话框的路由设置。否则，必须使用第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未要求在1x（仅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的头字段的构造方式与在对话框中发送的任何请求的构造方式相同（参见第12节），CSeq和与身份验证相关的头字段除外。CSeq头字段的序列号必须与确认的INVITE相同，但CSeq方法必须为ACK。确认必须包含与邀请相同的凭据。如果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核心认为INVITE事务在收到第一个2xx响应后64*T1秒完成。此时，所有尚未转换为已建立对话框的早期对话框都将终止。一旦UAC核心认为INVITE事务已完成，则预计不会再收到新的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.
如果在确认对邀请的任何2xx响应后，UAC不想继续该对话，则UAC必须按照第15节所述发送BYE请求来终止该对话。
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 core将为标头字段值中指示的秒数设置计时器。计时器启动时，邀请被视为已过期。如果邀请在UAS生成最终响应之前过期，则应生成487（请求终止）响应。
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. 如果请求是mid对话请求，则首先应用第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. 如果请求的“收件人”标题字段中有一个标记，但对话框标识符与任何现有对话框都不匹配，则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
邀请可能包含会话描述，在这种情况下，UAS将收到该会话的报价。用户可能已经是该会话的参与者，即使邀请在对话框之外。当多个其他参与者邀请用户参加同一个多播会议时，可能会发生这种情况。如果需要，UAS可以使用会话描述中的标识符来检测该重复。比如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).
在源（o）字段中包含会话id和版本号。如果用户已经是会话的成员，并且会话描述中包含的会话参数没有更改，UAS可以静默地接受邀请（即，在不提示用户的情况下发送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.
如果邀请不包含会话描述，则会要求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希望延长应答邀请的时间，则需要请求“延长”，以防止代理取消交易。当事务中的响应之间有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.
当用户处于等待状态时，或者当与PSTN系统互通时，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
如果UAS决定重定向呼叫，则发送3xx响应。300（多选）、301（永久移动）或302（临时移动）响应应包含联系人标题字段
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.
包含一个或多个要尝试的新地址的URI。响应被传递到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（此处繁忙）。如果UAS知道没有其他终端系统能够接受此呼叫，则应发送600（到处忙）响应。然而，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.
拒绝邀请中包含的报价的UAS应返回488（此处不接受）响应。此类响应应包括一个警告标题字段值，解释拒绝报价的原因。
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.
对邀请的2xx响应应包含允许标头字段和支持的标头字段，并且可能包含接受标头字段。包括这些头字段允许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必须包含答复。如果邀请不包含报价，则如果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秒（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秒，则对话框将被确认，但会话应终止。如第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节）在两个用户代理之间建立了一个对话框，并使用提供-应答模型建立了一个会话。第12节说明如何使用目标刷新请求修改现有对话框（例如，更改对话框的远程目标URI）。本节介绍如何修改实际会话。此修改可能涉及更改地址或端口、添加媒体流、删除媒体流等。这是通过在建立会话的同一对话框中发送新的INVITE请求来实现的。在现有对话框中发送的邀请请求称为重新邀请。
Note that a single re-INVITE can modify the dialog and the parameters of the session at the same time.
请注意，一次重新邀请可以同时修改对话框和会话参数。
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在检测媒体故障时的行为取决于当地政策。但是，不建议自动生成重新邀请或再见，以避免出现拥塞时网络流量泛滥。在任何情况下，如果这些消息是自动发送的，则应在随机间隔后发送。
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.
请注意，上面的段落指的是自动生成的“是”和“重新邀请”。如果用户在媒体故障时挂断，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
适用于邀请中的会话描述（第13.2.1节）的相同报价-应答模型适用于重新邀请。因此，例如，想要添加媒体流的UAC将创建包含该媒体流的新要约，并在邀请请求中将其发送给对等方。需要注意的是，发送的是会话的完整描述，而不仅仅是更改。这支持各种元素中的无状态会话处理，并支持故障切换和恢复功能。当然，UAC可以
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).
发送不带会话描述的重新邀请，在这种情况下，对重新邀请的第一个可靠的无故障响应将包含报价（在本规范中，这是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.
如果会话描述格式具有版本号功能，则报价人应指出会话描述的版本已更改。
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.
重新邀请的To、From、调用ID、CSeq和请求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.
UAC可以选择不向重新邀请添加警报信息标题字段或内容处置为“警报”的正文，因为UAS通常不会在收到重新邀请时向用户发出警报。
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不同，REINVITE可以分叉，REINVITE永远不会分叉，因此只生成一个最终响应。重新邀请永远不会分叉的原因是，请求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.
请注意，当另一个INVITE事务在任一方向上进行时，UAC不得在对话框中启动新的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事务进行中启动常规事务。UA还可以在常规事务进行中启动INVITE事务。
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收到对重新邀请的非2xx最终响应，则会话参数必须保持不变，就像没有发出重新邀请一样。请注意，如第12.2.1.2节所述，如果非2xx最终响应为481（呼叫/事务不存在）或408（请求超时），或者根本没有收到重新邀请的响应（即，邀请客户端事务返回超时），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接收到对重新邀请的491响应，它应该启动一个定时器，其值T选择如下：
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的调用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的调用ID的所有者，则T有一个以10毫秒为单位的0到2秒之间的随机选择值。
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仍希望进行会话修改，则应再次尝试重新邀请。例如，如果电话已挂断并伴有“再见”，则不会进行重新邀请。
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).
发送重新邀请和为重新邀请的2xx响应生成ACK的规则与初始邀请的规则相同（第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节描述了区分传入的重新邀请和传入的初始邀请以及处理现有对话框的重新邀请的程序。
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发送最终响应之前接收到第二个INVITE的UAS必须向第二个INVITE返回500（服务器内部错误）响应，并且必须包含一个Retry After header字段，该字段的随机选择值介于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.
当UAS在对话框上发送的邀请正在进行时，在该对话框上接收到邀请的UAS必须对接收到的邀请返回491（请求挂起）响应。
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收到现有对话框的重新邀请，则必须检查会话描述中的任何版本标识符，如果没有版本标识符，则检查会话描述的内容，以查看其是否已更改。如果会话描述已更改，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可以通过为重新邀请返回488（此处不可接受）响应来拒绝它。此响应应包括警告标题字段。
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以终止对话。
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.
UAS可以选择不为重新邀请生成180（振铃）响应，因为UAC通常不会向用户呈现此信息。出于同样的原因，UAS可能会选择不使用警报信息标题字段或内容处置为“警报”的正文来响应重新邀请。
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（因为邀请中不包含报价）应构建报价，就好像UAS正在进行全新呼叫一样，受发送更新现有会话的报价的约束，如SDP中[13]所述。具体而言，这意味着它应该包括UA愿意支持的尽可能多的媒体格式和媒体类型。UAS必须确保会话描述在媒体格式、传输或其他需要对等方支持的参数中与其先前的会话描述重叠。这是为了避免对等方拒绝会话描述。但是，如果UAC不能接受，UAC应生成带有有效会话描述的答案，然后发送BYE以终止会话。
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的每个1x或2xx响应都会创建一个对话框，如果该响应完成要约/应答交换，则还会创建一个会话。因此，每个会话都与一个单独的对话框“关联”，即创建会话的对话框。如果初始邀请生成非2xx最终响应，则终止通过响应请求创建的所有会话（如果有）和所有对话框（如果有）。通过完成事务，非2xx最终响应还可以防止由于邀请而创建更多会话。BYE请求用于终止特定会话或尝试的会话。在这种情况下，特定会话是对等UA位于对话框另一侧的会话。当在对话框上收到BYE时，与该对话框关联的任何会话都应终止。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。如果没有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尝试强制对邀请进行非2xx响应（尤其是487）。因此，如果UAC希望完全放弃呼叫尝试，它可以发送取消。如果邀请导致对邀请的2xx最终响应，这意味着UAS在取消过程中接受了邀请。UAC可以继续使用任何2xx响应建立的会话，也可以通过BYE终止会话。
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，如果初始邀请没有生成最终响应，这将意味着取消请求，并在最终响应后向所有已确认的对话框说再见。对于被叫方的UA，它通常意味着再见；据推测，当用户拿起电话时，会生成一个2xx，因此在收到确认后挂断电话会导致“再见”。这并不意味着用户在收到ACK之前不能挂断，它只是意味着他的手机中的软件需要保持一段时间的状态，以便正确地清理。如果特定的用户界面允许用户在接听来电之前拒绝来电，那么403（禁止）是一个很好的表达方式。根据上述规则，无法发送再见。
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
构建BYE后，UAC核心将创建一个新的非邀请客户端事务，并将BYE请求传递给它。一旦将再见请求传递给客户端事务，UAC必须考虑终止会话（因此停止发送或收听媒体）。如果BYE的响应为481（呼叫/事务不存在）或408（请求超时）或否
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.
接收到的响应为再见（即，由客户端事务返回超时），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（调用/事务不存在）响应，并将其传递给服务器事务。
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将被拒绝。这是对RFC 2543的更改，它允许BYE不带标记。
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响应，并且必须将该响应传递给服务器事务进行传输。
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
代理是SIP元素的逻辑角色。当请求到达时，可以扮演代理角色的元素首先决定是否需要自己响应请求。例如，请求的格式可能不正确，或者元素在充当代理之前可能需要来自客户端的凭据。该元素可以用任何形式响应
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.
正确的错误代码。当直接响应请求时，该元素扮演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）转发请求，而不使用事务状态。例如，代理可以无状态地将请求从一个TCP连接转发到另一个事务，只要它在消息中放置了足够的信息，以便能够将响应转发到请求到达的同一个连接。在不同类型的传输之间转发的请求，其中代理的TU必须在确保其中一个传输上的可靠传递方面发挥积极作用，必须以事务状态转发请求。
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响应）。当执行这样的转换时，所有状态都被丢弃。代理不应启动取消请求。
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
有状态时，代理纯粹是SIP事务处理引擎。它的行为在这里根据第17节中定义的服务器和客户端事务进行建模。有状态代理有一个服务器事务，通过一个更高层的代理处理组件（见图3）与一个或多个客户端事务关联，该组件称为代理核心。传入请求由服务器处理
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.
交易来自服务器事务的请求被传递到代理核心。代理核心通过选择一个或多个下一跳位置来确定将请求路由到何处。每个下一跳位置的传出请求由其自己的关联客户端事务处理。代理核心从客户端事务收集响应，并使用它们向服务器事务发送响应。
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节所述，代理核心必须作为UAS在该服务器事务上发送即时临时消息（如100 Trying）。因此，有状态代理不应该对非INVITE请求生成100（尝试）响应。
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 |
| | +---+
+--------------------+
+--------------------+
| | +---+
| | | 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.
请求的格式必须足够好，才能用服务器事务处理。这些请求验证步骤的剩余部分或请求转发部分中涉及的任何组件都必须格式良好。任何其他组件，无论是否格式正确，都应忽略，并在转发消息时保持不变。例如，元素不会因为日期头字段格式错误而拒绝请求。同样，在转发请求之前，代理不会删除格式错误的日期头字段。
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.
该协议旨在扩展。未来的扩展可能会在任何时候定义新的方法和头字段。元素不能拒绝代理请求，因为它包含它不知道的方法或头字段。
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.
如果请求URI具有代理无法理解其方案的URI，则代理应使用416（不支持的URI方案）响应拒绝请求。
3. Max-Forwards check
3. 最大远期支票
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标头字段，则元素不得转发请求。如果请求是针对选项的，元素可以作为最终接收者，并根据第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.
元素可以在转发请求之前检查转发循环。如果请求包含一个Via标头字段，其sent by值等于代理在以前的请求中放置的值，则该请求之前已由该元素转发。请求已经循环或合法地螺旋式地通过元素。为了确定请求是否已循环，该元素可对该消息执行第16.6节第8步中所述的分支参数计算，并将其与通过报头字段接收的参数进行比较。如果参数匹配，则请求已循环。如果它们不同，请求将螺旋上升，处理将继续。如果检测到回路，则元件可能返回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 header字段，告诉代理不要处理该请求，除非了解该功能。
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.
如果请求包含一个代理请求标头字段（第20.29节），其中包含一个或多个该元素无法理解的选项标记，则该元素必须返回420（错误扩展）响应。响应必须包含一个不受支持的（第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.
代理必须检查请求的请求URI。如果请求的请求URI包含该代理先前放入记录路由头字段中的值（参见第16.6节第4项），则代理必须用路由头字段中的最后一个值替换请求中的请求URI，并从路由头字段中删除该值。然后，代理必须继续，就好像它收到了这个修改后的请求一样。
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).
只有当向代理（可能是端点）发送请求的元素是严格的路由器时，才会发生这种情况。接收时的这种重写对于实现与这些元素的向后兼容性是必要的。它还允许遵循此规范的元素通过严格的路由代理保留请求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.
此要求并不要求代理必须保持状态，以便检测它以前放置在记录路由头字段中的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.
如果请求URI包含maddr参数，则代理必须检查其值是否在配置代理负责的地址或域集中。如果请求URI有一个maddr参数，该参数的值由代理负责，并且该请求是使用请求URI中指示的端口和传输（显式或默认）接收的，代理必须去除maddr和任何非默认端口或传输参数，并继续处理，就像请求中不存在这些值一样。
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 header字段中的第一个值指示此代理，则代理必须从请求中删除该值。
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.
如果请求的请求URI包含maddr参数，则必须将请求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).
如果请求URI的域表示此元素不负责的域，则必须将请求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.
如果没有如上所述预先确定请求的目标集，这意味着该元素负责请求URI中的域，并且该元素可以使用它想要的任何机制来确定将请求发送到哪里。这些机制中的任何一个都可以建模为访问抽象位置服务。这可能包括从SIP注册器创建的位置服务获取信息、读取数据库、咨询存在服务器、利用其他协议，或者简单地对请求URI执行算法替换。当访问由注册器构造的位置服务时，在用作索引之前，必须首先按照第10.3节所述规范化请求URI。这些机制的输出用于构造目标集。
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
如果请求URI没有为代理提供足够的信息来确定目标集，它应该返回485（不明确）响应。此响应应包含联系人标头字段，其中包含要尝试的新地址的URI。例如，邀请
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.
啜饮：约翰。Smith@company.com在其位置服务列出多个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将添加到目标集中。目标只能在目标集中放置一次。如果目标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.
如果原始请求的请求URI未指示该代理负责的资源，则代理不得向目标集添加其他目标。
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.
代理只能在转发期间更改请求的请求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指示该代理负责的资源，则该代理可以在开始请求转发后继续向集合中添加目标。它可以使用在处理过程中获得的任何信息来确定新的目标。例如，代理可以选择将重定向响应（3xx）中获得的联系人合并到目标集中。如果代理在构建目标集时使用动态信息源（例如，如果它咨询SIP注册器），那么它应该在处理请求的过程中监视该源。新位置可用时应添加到目标集中。如上所述，任何给定的URI都不能多次添加到集合中。
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添加到集合中一次可以减少不必要的网络流量，并且在合并来自重定向请求的联系人的情况下可以防止无限递归。
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
例如，一个普通的位置服务是“no-op”，其中目标URI等于传入的请求URI。请求被发送到特定的下一跳代理进行进一步处理。在请求期间
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.
转发第16.6节第6项，下一跳的标识（表示为SIP或SIPS URI）作为最顶端的路由头字段值插入到请求中。
If the Request-URI indicates a resource at this proxy that does not exist, the proxy MUST return a 404 (Not Found) response.
如果请求URI指示此代理上不存在的资源，则该代理必须返回404（未找到）响应。
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.
如果目标集在应用上述所有内容后仍为空，则代理必须返回错误响应，该响应应为480（暂时不可用）响应。
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.
一旦目标集非空，代理就可以开始转发请求。有状态代理可以按任何顺序处理集合。它可以连续处理多个目标，允许每个客户端事务在开始下一个事务之前完成。它可以与每个目标并行启动客户端事务。它还可以将集合任意分组，串行处理组，并行处理每个组中的目标。
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 header字段获得的目标的qvalue参数（参见第20.10节）。目标从最高qvalue到最低qvalue进行处理。可以并行处理具有相等Q值的目标。
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. 更新最大转发头字段
4. Optionally add a Record-route header field value
4. （可选）添加记录路由标头字段值
5. Optionally add additional header fields
5. （可选）添加其他标题字段
6. Postprocess routing information
6. 后处理路由信息
7. Determine the next-hop address, port, and transport
7. 确定下一跳地址、端口和传输
8. Add a Via header field value
8. 添加一个Via头字段值
9. Add a Content-Length header field if necessary
9. 如有必要，添加内容长度标题字段
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.
代理从接收到的请求的副本开始。副本最初必须包含收到的请求中的所有标头字段。不得删除下述处理中未详细说明的字段。副本应保持标题字段的顺序与收到的请求相同。代理不得使用公共字段名对字段值重新排序（见第7.3.1节）。代理不得添加、修改或删除邮件正文。
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. 请求地址
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.
副本开始行中的请求URI必须替换为此目标的URI。如果URI包含请求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.
在某些情况下，接收到的请求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标头字段，则代理必须添加一个字段值为70的字段。
Some existing UAs will not provide a Max-Forwards header field in a request.
一些现有UAs不会在请求中提供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.
如果此代理希望保留在此请求创建的对话框中的未来请求路径上（假设请求创建了一个对话框），则它必须在任何现有记录路由头字段值之前将记录路由头字段值插入副本中，即使路由头字段已经存在。
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.
如果此请求已经是对话框的一部分，则如果代理希望保留在对话框中未来请求的路径上，则应插入记录路由头字段值。在第12节所述的正常端点操作中，这些记录路由头字段值不会对端点使用的路由集产生任何影响。
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.
如果代理选择不将记录路由头字段值插入到已经是对话框一部分的请求中，则代理将保留在路径上。但是，当失败的端点重建对话框时，它将从路径中删除。
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.
代理可以在任何请求中插入记录路由头字段值。如果请求未启动对话框，端点将忽略该值。有关端点如何使用记录路由头字段值来构造路由头字段的详细信息，请参见第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.
请求路径中的每个代理选择是否独立添加记录路由头字段值-请求中存在记录路由头字段并不要求该代理添加值。
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.
记录路由头字段值中的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.
当[4]的服务器定位过程应用于记录路由头字段时，放置在记录路由头字段中的URI必须解析为插入它的元素（或合适的替代），以便后续请求到达相同的SIP元素。如果请求URI包含SIPS URI，或者最顶端的路由标头字段值（在bullet 6的后期处理之后）包含SIPS URI，则放入记录路由标头字段的URI必须是SIPS URI。此外，如果请求未通过TLS接收，则代理必须插入记录路由头字段。以类似的方式，通过TLS接收请求但在请求URI或最顶端的路由标头字段值（在bullet 6的后处理之后）中生成没有SIPS URI的请求的代理必须插入不是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.
如果放置在记录路由头字段中的URI在响应中传回时需要重写，则该URI必须足够清晰，以便在当时定位。（请求可能会螺旋式地通过该代理，导致添加多个记录路由头字段值）。第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.
代理可以在记录路由头字段值中包含参数。这些将在一些对请求的响应中得到响应，例如200（确定）个INVITE响应。这些参数可能有助于在消息中而不是代理中保持状态。
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.
如果代理需要位于任何类型对话框（例如跨防火墙的对话框）的路径中，它应该使用它不理解的方法向每个请求添加记录路由头字段值，因为该方法可能具有对话框语义。
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
代理放置在记录路由头字段中的URI仅在发生该URI的事务创建的任何对话框的生存期内有效。例如，对话框有状态代理可能在对话框终止后拒绝接受请求URI中具有该值的未来请求。当然，非对话状态代理不知道对话何时终止，但它们可能在值中编码足够的信息，以便将其与未来请求的对话标识符进行比较，并可能拒绝与该信息不匹配的请求。端点不得使用从提供URI的对话框外部的记录路由头字段中获取的URI。看见
Section 12 for more information on an endpoint's use of Record-Route header fields.
有关端点使用记录路由头字段的更多信息，请参见第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.
记录路由过程设计用于启动对话的任何SIP请求。INVITE是本规范中唯一的此类请求，但协议的扩展可能会定义其他请求。
5. Add Additional Header Fields
5. 添加其他标题字段
The proxy MAY add any other appropriate header fields to the copy at this point.
此时，代理可以向副本添加任何其他适当的头字段。
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表示（每个URI都包含lr参数）。此集合必须在任何现有值（如果存在）之前推入副本的Route header字段。如果缺少Route header字段，则必须添加该字段，其中包含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.
如果代理有一个本地策略，要求请求访问一个特定代理，将路由值推送到Route header字段的替代方法是绕过下面第10项的转发逻辑，而只将请求发送到该特定代理的地址、端口和传输。如果请求具有路由头字段，则除非知道下一跳代理是松散路由器，否则不得使用此替代方案。否则，可以使用该方法，但上述路由插入机制因其健壮性、灵活性、通用性和操作一致性而更受欢迎。此外，如果请求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.
- 代理必须将请求URI作为最后一个值放入Route header字段。
- 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).
将请求URI追加到Route header字段是用于通过严格的路由元素传递该请求URI中的信息的机制的一部分。将第一个路由头字段值“弹出”到请求URI中，以严格路由元素期望接收消息的方式格式化消息（在请求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.
代理可以具有将请求发送到特定IP地址、端口和传输的本地策略，而与路由和请求URI的值无关。如果代理无法确定IP地址、端口和传输是否对应于松散路由器的服务器，则不得使用此类策略。但是，不推荐通过特定下一跳发送请求的这种机制；相反，应使用Route header字段实现上述目的。
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中的描述重新格式化了发送到严格路由元素的请求，那么代理必须将这些过程应用于请求的请求URI。否则，代理必须将过程应用于Route header字段中的第一个值（如果存在），否则应用于请求URI。这些过程将生成一组有序的（地址、端口、传输）元组。与将哪个URI用作[4]过程的输入无关，如果请求URI指定SIPS资源，则代理必须遵循[4]的过程，就像输入URI是SIPS URI一样。
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]所述，代理必须尝试将消息传递到该集合中的第一个元组，并按顺序遍历该集合，直到传递尝试成功。
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 header字段所提供的分支参数对于每次尝试都必须不同。
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（请求超时）最终响应一样。
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.
选择检测循环的代理在用于构造分支参数的值中有一个附加约束。选择检测循环的代理应创建一个分支参数，该参数可由实现分为两部分。第一部分必须满足上述第8.1.1.7节的约束条件。第二个用于执行回路检测并区分回路和螺旋。
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
循环检测是通过验证当请求返回到代理时，对请求处理有影响的字段没有更改来执行的。分支参数此部分中的值应反映所有这些字段（包括任何路由、代理要求和代理授权标头字段）。这是为了确保如果请求被路由回代理，并且其中一个字段发生更改，则将其视为螺旋而不是循环（请参见第16.3节）。创建此值的常用方法是计算to标记、From标记、Call ID标头字段、接收到的请求的请求URI（翻译前）、最顶端的Via标头以及CSeq标头字段中的序列号的加密哈希，以及可能存在的任何代理要求和代理授权标头字段。这个
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.)
用于计算散列的算法取决于实现，但以十六进制表示的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.
如果代理希望检测循环，则它提供的“分支”参数必须取决于影响请求处理的所有信息，包括传入请求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).
请求方法不得包含在分支参数的计算中。特别是，取消和确认请求（对于非2xx响应）必须与它们取消或确认的相应请求具有相同的分支值。branch参数用于在处理这些请求的服务器上关联这些请求（请参见第17.2.3和9.2节）。
9. Add a Content-Length header field if necessary
9. 如有必要，添加内容长度标题字段
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).
如果将使用基于流的传输将请求发送到下一个跃点，并且副本不包含内容长度头字段，则代理必须为请求正文插入一个具有正确值的头字段（参见第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的定时器。当INVITE请求被代理时，必须为每个客户端事务设置定时器C。计时器必须大于3分钟。第16.7节bullet 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.
必须对转发的每个响应执行以下处理。可能会转发对每个请求的多个响应：至少每个临时响应和一个最终响应。
7. Aggregate authorization header field values if necessary
7. 如有必要，聚合授权标头字段值
8. Optionally rewrite Record-Route header field values
8. 可选地重写记录路由头字段值
9. Forward the response
9. 转发回复
10. Generate any necessary CANCEL requests
10. 生成任何必要的取消请求
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分钟。
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标头字段值，则响应是针对此元素的，不得转发。本节中描述的其余处理不会在此消息上执行，而是遵循第8.1.3节中描述的UAC处理规则（传输层处理已经发生）。
This will happen, for instance, when the element generates CANCEL requests as described in Section 10.
例如，当元素生成第10节所述的取消请求时，就会发生这种情况。
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
如果代理选择通过将联系人添加到目标集在3xx响应中的任何联系人上递归，则必须在将响应添加到响应上下文之前将其从响应中删除。但是，如果原始请求的请求URI是SIPS URI，则代理不应递归到非SIPS URI。如果
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响应中的所有联系人上递归，代理不应将生成的非接触响应添加到响应上下文中。
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、SIP和非SIP URI的混合物。代理可以选择在SIP和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.
如果代理收到416（不支持的URI方案）对请求的响应，该请求的请求URI方案不是SIP，但原始接收请求中的方案是SIP或SIPS（即，代理在代理请求时将方案从SIP或SIPS更改为其他内容），则代理应向目标集添加新的URI。此URI应该是刚刚尝试的非SIP URI的SIP URI版本。在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响应添加到响应上下文中。
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节中所述的所有客户端挂起事务，并且不得在此上下文中创建任何新分支。
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
这与RFC 2543有所不同，RFC 2543要求代理立即转发6xx响应。对于INVITE事务，这种方法的问题是2xx响应可能到达另一个分支，在这种情况下，代理将
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.
必须转发2xx。结果是UAC可能会收到一个6xx响应，然后是一个2xx响应，这是绝对不允许发生的。根据新规则，在收到6xx后，代理将发出取消请求，这通常会导致所有未完成的客户交易的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
- 对邀请请求的任何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".
有状态代理不能立即转发任何其他响应。特别是，有状态代理不能转发任何100（尝试）响应。如步骤“将响应添加到上下文”中所述，已经收集了那些作为“最佳”响应转发的候选响应。
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请求转发一个最终响应，并向INVITE请求转发一个非2xx响应或一个或多个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（请求超时）响应。
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
否则，代理必须转发来自存储在响应上下文中的响应的响应。如果上下文中存在任何响应，则必须从6xx类响应中进行选择。如果不存在6xx类响应，则代理应从响应上下文中存储的最低响应类中进行选择。代理可以选择所选类中的任何响应。代理应该
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.
优先选择提供影响此请求重新提交的信息的响应，如401、407、415、420和484（如果选择了4xx类）。
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（服务不可用）响应的代理不应将其转发到上游，除非它可以确定它可能代理的任何后续请求也将生成503。换句话说，转发503意味着代理知道它不能服务于任何请求，而不仅仅是针对生成503的请求中的请求URI的请求。如果收到的唯一响应是503，则代理应生成500响应并将其转发到上游。
The forwarded response MUST be processed as described in steps "Aggregate Authorization Header Field Values" through "Record-Route".
转发的响应必须按照步骤“聚合授权标头字段值”通过“记录路由”进行处理。
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标头字段。代理不得修改1xx或2xx响应的To header字段中的标记。
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 header字段中，因此它无法自行发出非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，通常根据从下游元素收到的响应发出自己的响应。当简单地将3-6xx响应转发给不包含To标记的请求时，元素应该保留To标记。
A proxy MUST NOT modify the To tag in any forwarded response to a request that contains a To tag.
代理不得在对包含To标记的请求的任何转发响应中修改To标记。
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身份验证和代理身份验证标头字段值在此响应上下文中接收到的响应，并在转发之前将它们添加到此响应中，而不进行修改。生成的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.
如果所选响应包含此代理最初提供的记录路由头字段值，则代理可以选择在转发响应之前重写该值。这允许代理为自己向下一个上游和下游元素提供不同的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连接将其发送出去，则代理必须将记录路由头字段中的URI重写为SIPS URI。如果代理通过非TLS连接接收到请求，并通过TLS发送出去，则代理必须将记录路由头字段中的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必须满足对请求中记录路由头字段中的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.
当代理决定修改响应中的记录路由头字段时，它执行的操作之一是定位它插入的记录路由值。如果请求是螺旋式的，并且代理在螺旋式的每次迭代中插入了一个记录路由值，那么在响应中定位正确的值（必须是反向的正确迭代）是很困难的。上述规则建议希望重写记录路由头字段值的代理在记录路由头字段中插入足够不同的URI，以便选择正确的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.
当响应到达时，代理修改标识符与代理实例匹配的第一条记录路由。修改会产生一个URI，该URI的用户部分没有附加这段数据。在下一次迭代中，相同的算法（使用参数查找最上面的记录路由头字段值）将正确提取该代理插入的下一个记录路由头字段值。
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.
对于代理向其添加记录路由头字段值的请求，并非每个响应都包含记录路由头字段。如果响应确实包含记录路由头字段，则它将包含代理添加的值。
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
在通过“记录路由”执行步骤“聚合授权标头字段值”中描述的处理之后，代理可以对所选响应执行任何特定于功能的操作。代理不得添加、修改或删除邮件正文。除非另有规定，否则代理不得删除除第16.7节第3项中讨论的Via标头字段值以外的任何标头字段值。特别是，代理不得删除任何“已接收”参数
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.
在处理与此响应关联的请求时，它可能已添加到next Via header字段值。代理必须将响应传递给与响应上下文关联的服务器事务。这将导致响应被发送到当前最顶部的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.
如果转发的响应是最终响应，则代理必须为与此响应上下文关联的所有挂起的客户端事务生成取消请求。当代理收到6xx响应时，还应该为与此响应上下文关联的所有挂起的客户端事务生成取消请求。挂起的客户端事务是一个已收到临时响应但没有最终响应（它处于继续状态）且未生成相关取消的事务。第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）响应。在发送和处理取消请求之前，可以在多个分支上生成200（确定）个响应。此外，可以合理预期，未来的扩展可能会覆盖此要求以发出取消请求。
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，则代理必须使用其选择的任何值重置计时器，或终止客户端事务。如果客户端事务已收到临时响应，则代理必须生成与该事务匹配的取消请求。如果客户端事务尚未收到临时响应，则代理必须表现为事务收到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（服务不可用）响应的行为相同。
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.
有状态代理可以随时生成对其生成的任何其他请求的取消（前提是收到第9.1节所述的对该请求的临时响应）。代理收到匹配的取消请求时，必须取消与响应上下文关联的任何挂起的客户端事务。
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标头字段elapsing中指定的时间段，为挂起的INVITE客户端事务生成取消请求。然而，这通常是不必要的，因为所涉及的端点将负责发出事务结束的信号。
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.
当取消请求由其自己的服务器事务在有状态代理中处理时，不会为其创建新的响应上下文。相反，代理层在其现有响应上下文中搜索处理与此取消关联的请求的服务器事务。如果找到匹配的响应上下文，元素必须立即返回一个200（OK）响应到CANCEL请求。在这种情况下，该元素充当第8.2节中定义的用户代理服务器。此外，元素必须为第16.7节步骤10中描述的上下文中的所有挂起的客户端事务生成取消请求。
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).
如果未找到响应上下文，则元素不知道要对其应用取消的请求。它必须无状态地转发取消请求（它以前可能无状态地转发了关联的请求）。
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（Trying）或任何其他临时响应。
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 无状态代理必须从目标集中选择一个且仅选择一个目标。此选择只能依赖于消息中的字段和服务器的时间不变属性。特别是，每次处理重新传输的请求时，都必须将其转发到相同的目的地。此外，取消和非路由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要求也适用于无状态代理。但是，无状态代理不能简单地使用随机数生成器来计算分支ID的第一个组件，如第16.6.8节所述。这是因为请求的重新传输需要具有相同的值，并且无状态代理无法将重新传输与原始请求区分开来。因此，每次转发重新传输的请求时，使其唯一的分支参数的组件必须相同。因此，对于无状态代理，分支参数必须作为消息参数的组合函数进行计算，这些参数在重新传输时是不变的。
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在事务中的唯一性。但是，建议采用以下程序。代理检查接收到的请求的最顶端Via头字段中的分支ID。如果它以magic cookie开头，则传出请求的分支ID的第一个组件将被计算为接收到的分支ID的哈希。否则，分支ID的第一个组件将被计算为最顶端的Via、To头字段中的标记、From头字段中的标记、Call ID头字段、CSeq号的哈希（但不是方法），以及来自接收到的请求的请求URI。这些字段中的一个字段在两个不同的事务中总是不同的。
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节中规定的所有其他消息转换必须导致对重新传输的请求进行相同的转换。特别是，如果代理插入记录路由值或将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.
无状态代理不能对取消请求执行特殊处理。它们与任何其他请求一样，按照上述规则进行处理。特别是，无状态代理应用与应用于任何其他请求相同的路由头字段处理来取消请求。
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头字段值中的send by值。如果该地址与代理匹配（它等于此代理已插入到以前请求中的值），则代理必须从响应中删除该标头字段值，并将结果转发到下一个Via标头字段值中指示的位置。代理不得添加、修改或删除邮件正文。除非另有规定，否则代理不得删除任何其他头字段值。如果地址与代理不匹配，则必须以静默方式丢弃消息。
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. 代理将检查请求URI。如果它指示此代理拥有的资源，则代理将用运行位置服务的结果替换它。否则，代理将不会更改请求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所指示的资源，或者如果不存在路由头字段，则转发到请求URI中的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.
如果在请求的路径上没有遇到严格的路由元素，那么请求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
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中查找并发送到那里。它还添加了一个记录路由头字段值：
INVITE sip:callee@domain.com SIP/2.0
Contact: sip:caller@u1.example.com
Record-Route: <sip:p1.example.com;lr>
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，因此它运行位置服务并重写请求URI。它还添加了一个记录路由头字段值。没有Route header字段，因此它解析新的请求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>
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>
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>)
(<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>)
(<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>
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注意到它不负责请求URI中指示的资源，因此它不会更改它。它确实看到它是Route header字段中的第一个值，因此它删除该值，并将请求转发给P2：
BYE sip:callee@u2.domain.com SIP/2.0
Route: <sip:p2.domain.com;lr>
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还注意到它不负责请求URI所指示的资源（它负责domain.com，而不是u2.domain.com），因此它不会更改它。它确实会在第一个路由头字段值中看到自己，因此它会删除它并根据请求URI的DNS查找将以下内容转发到u2.domain.com：
BYE sip:callee@u2.domain.com SIP/2.0
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.
在这种情况下，将跨四个代理建立一个对话框，每个代理都会添加记录路由头字段值。第三个代理实现RFC2543中指定的严格路由过程，许多工作正在进行中。
U1->P1->P2->P3->P4->U2
U1->P1->P2->P3->P4->U2
The INVITE arriving at U2 contains:
到达U2的邀请包含：
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>
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基于第一个路由头字段值向P4发送以下BYE请求。
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>
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不负责请求URI中指示的资源，因此它将不处理该资源。它注意到它是第一个路由头字段值中的元素，因此将其删除。然后，它准备根据sip:p3.middle.com的now first Route header字段值发送请求，但它注意到此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>
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>
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认为请求URI是它放在记录路由头字段中的一个值，因此在进一步处理之前，它将请求重写为：
BYE sip:caller@u1.example.com SIP/2.0
Route: <sip:p1.example.com;lr>
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在最顶端的Route header字段值中注意到自己，因此将其删除，从而导致：
BYE sip:caller@u1.example.com SIP/2.0
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将根据请求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进入一个对话框，代理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>
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>
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（正常）发送回P1：
SIP/2.0 200 OK
Contact: <sip:callee@u2.rightprivatespace.com>
Record-Route: <sip:gateway.rightprivatespace.com;lr>
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重写其记录路由标头参数，以提供U1将发现有用的值，并将以下内容发送给U1：
SIP/2.0 200 OK
Contact: <sip:callee@u2.rightprivatespace.com>
Record-Route: <sip:gateway.leftprivatespace.com;lr>
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向P1发送以下BYE请求：
BYE sip:callee@u2.rightprivatespace.com SIP/2.0
Route: <sip:gateway.leftprivatespace.com;lr>
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
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事务由单个请求和对该请求的任何响应组成，其中包括零个或多个临时响应和一个或多个最终响应。对于请求为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
这种分离的原因源于向UAC发送邀请的所有200（OK）响应的重要性。要将它们全部交付给UAC，UAS独自承担责任
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.
对于重传它们（见第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
+---------+ +---------+ +---------+ +---------+
| +-+|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传递请求的方法，有两种类型的客户端事务状态机。一种处理INVITE请求的客户端事务。这种类型的机器称为INVITE客户端事务。另一种类型处理除INVITE和ACK之外的所有请求的客户端事务。这称为非邀请客户端事务。没有ACK的客户端事务。如果TU希望发送ACK，它会将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事务与其他方法不同，因为它的持续时间延长。通常，需要人工输入才能响应邀请。发送响应的长时间延迟需要三方握手。另一方面，其他方法的请求有望迅速完成。由于非邀请事务依赖于双向握手，因此TUs应该立即响应非邀请请求。
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事务由三方握手组成。客户端事务发送INVITE，服务器事务发送响应，客户端事务发送ACK。对于不可靠的传输（如UDP），客户端事务以从T1秒开始并在每次重新传输后加倍的间隔重新传输请求。T1是对往返时间（RTT）的估计，默认值为500毫秒。这里描述的几乎所有事务计时器都使用T1进行缩放，更改T1会调整它们的值。请求不会通过可靠的传输重新传输。在收到1xx响应后，任何重新传输都将完全停止，客户端将等待进一步的响应。服务器事务可以发送额外的1xx响应，而服务器事务不能可靠地传输这些响应。最后，服务器事务决定发送最终响应。对于不可靠的传输，该响应会定期重新传输，而对于可靠的传输，则只发送一次。对于在客户端事务处接收到的每个最终响应，客户端事务发送一个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).
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).translate error, please retry
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
当触发计时器A时，客户端事务必须通过将请求传递到传输层来重新传输请求，并且必须使用2*T1的值重置计时器。重传的形式化定义
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.
在事务层的上下文中，获取先前发送到传输层的消息并再次将其传递到传输层。
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秒后触发时，必须再次重新传输请求（假设客户端事务仍处于此状态）。此过程必须继续，以便在每次传输后以双倍的间隔重新传输请求。这些重传只能在客户端事务处于“调用”状态时进行。
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值。T1可以选择更大，如果事先知道（例如在高延迟访问链路上）RTT更大，则建议选择更大的T1。无论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已发生超时。客户端事务不能生成ACK。64*T1的值等于在传输不可靠的情况下发送七个请求所需的时间量。
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.
如果客户机事务在“调用”状态下收到临时响应，它将转换到“继续”状态。在“继续”状态下，客户端事务不应再重新传输请求。此外，临时响应必须传递给TU。任何进一步的临时响应必须在“继续”状态下传递给TU。
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
当处于“呼叫”或“继续”状态时，收到状态代码为300-699的响应必须导致客户端事务转换为“已完成”。客户端事务必须将接收到的响应传递给TU，并且客户端事务必须生成ACK请求，即使传输是可靠的（第17.1.1.3节给出了从响应构造ACK的指南），然后将ACK传递给传输层进行传输。ACK必须发送到原始请求发送到的相同地址、端口和传输。客户端事务应在进入“完成”状态时启动计时器D，对于不可靠的传输，其值至少为32秒，对于可靠的传输，其值为零秒。计时器D反映了当使用不可靠的传输时，服务器事务可以保持在“完成”状态的时间量。这等于INVITE服务器事务中的计时器H，其
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.
默认值为64*T1。但是，客户机事务不知道服务器事务使用的T1的值，因此使用绝对最小值32s，而不是基于T1的计时器D。
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|<--------------+
| |
+-----------+
|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：邀请客户端事务
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
当处于“调用”或“继续”状态时，接收2xx响应必须导致客户端事务进入“终止”状态，并且响应必须传递给TU。此响应的处理取决于TU是否是代理
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.
核心或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.
客户机事务必须在进入“终止”状态时立即销毁。这实际上是保证正确操作所必需的。原因是对邀请的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确认的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请求必须包含调用ID、From和请求URI的值，这些值等于客户端事务传递给传输的请求中的头字段的值（称为“原始请求”）。ACK中的To header字段必须等于待确认响应中的To header字段，因此通常通过添加tag参数而与原始请求中的To header字段不同。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中的任何主体，假设对INVITE的响应不是415。如果是，则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
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
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.
非邀请事务不使用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响应没有特殊处理。结果是，只有一个对非邀请的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秒内启动。请求必须传递到传输层进行传输。如果正在使用不可靠的传输，则客户端事务必须将计时器E设置为在T1秒内启动。如果计时器E在仍处于该状态时触发，则计时器将重置，但这次的值为MIN（2*T1，T2）。当计时器再次启动时，将重置为分钟（4*T1，T2）。此过程继续进行，以使重传以指数增长的间隔发生，该间隔以T2为上限。T2的默认值是4s，它表示非INVITE服务器事务在未立即响应请求时响应请求所需的时间。对于T1和T2的默认值，这将导致500毫秒、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超时，然后进入“终止”状态。如果在“尝试”状态下收到临时响应，则必须将响应传递给TU，然后客户端事务应移动到“继续”状态。如果在“尝试”状态下收到最终响应（状态代码200-699），则必须将响应传递给TU，并且客户端事务必须转换为“完成”状态。
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.
如果计时器E在“继续”状态下触发，则必须将请求传递到传输层进行重新传输，并且必须使用T2秒的值重置计时器E。如果计时器F在“继续”状态下触发，则必须通知TU超时，并且客户端事务必须转换到终止状态。如果在“继续”状态下收到最终响应（状态代码200-699），则必须将响应传递给TU，并且客户端事务必须转换为“完成”状态。
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
一旦客户机事务进入“完成”状态，它必须将计时器K设置为在T4秒内启动（对于不可靠的传输），并在零秒内启动（对于可靠的传输）。“已完成”状态的存在是为了缓冲可能接收到的任何额外的响应重新传输（这就是为什么客户端事务只保留一段时间）
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.
不可靠的运输）。T4表示网络清除客户端和服务器事务之间的消息所需的时间。T4的默认值为5s。使用第17.1.3节规定的规则，当响应与同一事务匹配时，即为重新传输。如果计时器K在此状态下触发，则客户端事务必须转换为“已终止”状态。
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节的处理。top Via header字段中的分支参数用于此目的。响应在两种情况下匹配客户端事务：
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. 如果响应的top Via header字段中的分支参数值与创建事务的请求的top Via header字段中的分支参数值相同。
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标头字段中的方法参数与创建事务的请求的方法匹配。该方法是必需的，因为取消请求构成不同的事务，但共享相同的分支参数值。
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.
如果通过多播发送请求，则可能会从不同的服务器生成多个响应。这些响应在最上面的过孔中都具有相同的分支参数，但在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
|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：非邀请客户端事务
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发生传输故障，并且客户端事务应直接转换到“终止”状态。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.
当为请求构造服务器事务时，它将进入“继续”状态。服务器事务必须生成100（尝试）响应，除非它知道TU将在200毫秒内生成临时或最终响应，在这种情况下，它可能会生成100（尝试）响应。为了避免网络拥塞，需要这个临时响应来快速终止请求重传。100（Trying）响应是根据第8.2.6节中的程序构造的，除了在响应的to标头字段中插入标记（当请求中不存在标记时）从5月降级为不应。请求必须传递给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将任意数量的临时响应传递给服务器事务。只要服务器事务处于“继续”状态，这些事务中的每一个都必须传递到传输层进行传输。事务层不会可靠地发送它们（它们不会被事务层重新传输），也不会导致服务器事务状态的更改。如果在“继续”状态下接收到请求重传，则必须将从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
如果在“继续”状态下，TU将2xx响应传递给服务器事务，则服务器事务必须将该响应传递给传输层进行传输。事实并非如此
retransmitted by the server transaction; retransmissions of 2xx responses are handled by the TU. The server transaction MUST then transition to the "Terminated" state.
由服务器事务重新传输；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.
在“继续”状态下，如果TU将状态代码为300到699的响应传递给服务器事务，则响应必须传递给传输层进行传输，并且状态机必须进入“完成”状态。对于不可靠传输，定时器G设置为在T1秒内启动，而对于可靠传输，定时器G未设置为启动。
This is a change from RFC 2543, where responses were always retransmitted, even over reliable transports.
这与RFC 2543有所不同，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将在分钟（2*T1，T2）秒内设置为触发。从那时起，当定时器G触发时，响应再次传递给传输，并使用双倍的值重置定时器G，除非该值超过T2，否则在这种情况下，将使用T2值重置定时器G。这与非INVITE客户端事务处于“尝试”状态的请求的重新传输行为相同。此外，当处于“完成”状态时，如果接收到请求重传，则服务器应将响应传递给传输以进行重传。
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。在这种情况下，服务器事务必须转换为“已终止”状态，并且必须向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|<---------------+
| |
+-----------+
|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：邀请服务器事务
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秒内启动（对于可靠的传输）。一旦计时器I启动，服务器必须转换到“终止”状态。
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向服务器事务传递临时响应，则服务器事务必须进入“继续”状态。响应必须传递到传输层进行传输。当处于“继续”状态时从TU接收的任何进一步的临时响应必须传递到传输层以进行传输。如果在“继续”状态下接收到请求的重新传输，则最近发送的临时响应必须传递给传输层进行重新传输。如果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秒内启动，对于可靠的传输，它必须设置为零秒。在“完成”状态下，服务器事务必须将最终响应传递给传输层，以便在收到请求的重传时进行重传。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标头字段中的分支参数。如果存在并以神奇cookie“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. 请求中的branch参数等于创建事务的请求的top Via header字段中的参数，并且
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. 请求顶部通孔中的sent by值等于创建事务的请求中的值，并且
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.
此匹配规则同样适用于邀请和非邀请事务。
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.
如果top Via header字段中的branch参数不存在，或者不包含magic cookie，则使用以下过程。它们的存在是为了处理与RFC2543兼容实现的向后兼容性。
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
如果请求URI、To标记、From标记、调用ID、CSeq和top Via头字段与创建事务的INVITE请求的URI、To标记、From标记、调用ID、CSeq和top Via头字段匹配，则INVITE请求与事务匹配。在这种情况下，INVITE是创建事务的原始INVITE的重新传输。如果请求URI、From标记、调用ID、CSeq编号（不是方法）和top Via标头字段与创建事务的INVITE请求的URI匹配，并且ACK的To标记与服务器事务发送的响应的To标记匹配，则ACK请求与事务匹配。根据为每个标题字段定义的匹配规则进行匹配。在ACK匹配过程中，将标记包含在To header字段中有助于消除2xx的ACK与其他响应的ACK之间的歧义
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.
在一个代理上，该代理可能转发了两个响应（在异常情况下可能会发生这种情况。特别是，当一个代理分叉一个请求，然后崩溃时，响应可能会被传递到另一个代理，而另一个代理可能会向上游转发多个响应）。与先前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|
| |
+-----------+
|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：非邀请服务器事务
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
对于所有其他请求方法，如果请求URI、to标记、From标记、调用ID、CSeq（包括该方法）和top Via标头字段与创建事务的请求的URI、to标记、From标记、调用ID、CSeq和top Via标头字段匹配，则请求与事务匹配。在匹配的基础上进行匹配
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.
为每个标题字段定义的规则。当非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.
因为匹配规则包括请求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发生了故障，并应转换到终止状态。
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（包括对传输层开放的协议）的持久连接。这包括由客户端或服务器传输打开的连接，以便在客户端和服务器传输功能之间共享连接。这些连接由连接远端的地址、端口和传输协议形成的元组索引。当传输层打开连接时，此索引设置为目标IP、端口和传输。当传输层接受连接时，此索引将设置为源IP地址、端口号和传输。请注意，由于源端口通常是临时的，但无法知道它是临时的还是通过[4]中的过程选择的，因此传输层接受的连接通常不会被重用。结果是，使用面向连接的传输的“对等”关系中的两个代理经常会使用两个连接，一个用于在每个方向启动的事务。
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节）。然而，例如，在具有TU的元素中，它可以更大，使用定时器C的大值（第16.6节中的项目符号11）。
All SIP elements MUST implement UDP and TCP. SIP elements MAY implement other protocols.
所有SIP元素都必须实现UDP和TCP。SIP元素可以实现其他协议。
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.
将TCP强制用于UA是对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未知，则必须使用RFC 2914[43]拥塞控制传输协议（如TCP）发送请求。如果这导致传输协议从顶部通孔中指示的协议发生更改，则必须更改顶部通孔中的值。这可以防止UDP上的消息碎片，并为较大的消息提供拥塞控制。但是，实现必须能够处理最大数据报数据包大小的消息。对于UDP，此大小为65535字节，包括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
消息大小和MTU之间的200字节“缓冲区”适应了SIP中的响应可能大于请求的事实。例如，这是由于在INVITE响应中添加了记录路由头字段值所致。有了额外的缓冲区，响应可以比请求大大约170字节，并且在IPv4上仍然不会被分段（大约30字节）
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.
由IP/UDP使用，假设没有IPSec）。基于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.
向多播地址发送请求的客户端必须将“maddr”参数添加到其包含目标多播地址的Via标头字段值中，对于IPv4，应添加值为1的“ttl”参数。本规范中未定义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
对于可靠的传输，响应通常在接收请求的连接上发送。因此，客户端传输必须准备好在用于发送请求的同一连接上接收响应。在错误情况下，服务器可能会尝试打开新连接以发送响应。为了处理这种情况，传输层还必须准备好在发送请求的源IP地址和“发送人”字段中的端口号上接收传入连接。它也
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].
必须准备好接收服务器根据[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地址、端口和传输，建议使用此连接发送请求，但也可以打开并使用另一个连接。
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.
当接收到响应时，客户端传输将检查top Via头字段值。如果该标头字段值中“sent by”参数的值与客户端传输配置为插入到请求中的值不对应，则必须以静默方式放弃响应。
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.
服务器应准备好接收任何IP地址、端口和传输组合上的请求，这些请求可能是为了与该服务器通信而分发的SIP或SIPS URI[4]上DNS查找的结果。在此上下文中，“分发”包括将URI放置在注册请求或重定向响应中的联系人标头字段中，或放置在请求或响应中的记录路由标头字段中。URI也可以通过放在网页或名片上“分发”。还建议服务器在所有公共接口的默认SIP端口（5060用于TCP和UDP，5061用于TCP上的TLS）上侦听请求。典型的例外情况是专用网络，或者当多个服务器实例在同一主机上运行时。对于服务器侦听UDP的任何端口和接口，它必须侦听TCP的同一端口和接口。这是因为如果消息太大，可能需要使用TCP而不是UDP发送消息。因此，情况并非如此。服务器不需要侦听特定地址和端口上的UDP，因为它正在侦听同一地址和端口上的TCP。当然，服务器需要侦听特定地址和端口上的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”参数的值。如果“发送人”参数的主机部分包含域名，或者如果它包含与数据包源地址不同的IP地址，则服务器必须通过标头字段值向该部分添加“已接收”参数。此参数必须包含从中接收数据包的源地址。这是为了帮助服务器传输层发送响应，因为它必须发送到请求来自的源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
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:
接收请求时，源IP地址为192.0.2.4。在向上传递请求之前，传输会添加一个“received”参数，以便请求的部分外观如下：
INVITE sip:bob@Biloxi.com SIP/2.0
Via: SIP/2.0/UDP bobspc.biloxi.com:5060;received=192.0.2.4
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:
服务器传输使用top Via header字段的值来确定发送响应的位置。它必须遵循以下过程：
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地址的连接。如果该连接尝试失败，服务器应使用[4]中针对服务器的过程，以确定打开连接并向发送响应的IP地址和端口。
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”参数，则必须使用“发送人”中指示的端口或端口5060（如果不存在）将响应转发到此处列出的地址。如果地址是多播地址，则应使用“TTL”参数中指示的TTL发送响应，如果该参数不存在，则应使用1的TTL发送响应。
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 否则（对于不可靠的单播传输），如果顶部通孔具有“received”参数，则必须使用“sent by”值中指示的端口将响应发送到“received”参数中的地址，如果未明确指定，则使用端口5060。例如，如果此操作失败，导致ICMP“端口不可访问”响应，则应使用[4]第5节中的程序来确定将响应发送到何处。
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）的情况下，如果消息具有内容长度头字段，则假定消息体包含那么多字节。如果传输数据包中有超出正文末尾的额外字节，则必须丢弃这些字节。如果传输数据包在消息正文结束之前结束，则认为这是一个错误。如果消息是响应，则必须将其丢弃。如果消息是一个请求，那么元素应该生成一个400（错误请求）响应。如果消息没有内容长度报头字段，则假定消息正文在传输数据包的末尾结束。
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头字段指示主体的大小。内容长度标头字段必须与面向流的传输一起使用。
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错误的类型。主机、网络、端口或协议不可访问错误或参数问题错误应导致传输层通知传输用户发送失败。应忽略源猝灭和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.
如果传输用户要求通过可靠传输发送请求，结果导致连接失败，则传输层应通知传输用户发送失败。
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消息中的不同位置（有时在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可以放在网页、电子邮件或印刷文献中。它们包含足够的信息来启动和维护与资源的通信会话。
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资源通信，那么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消息体。这使得通过在网页或电子邮件中使用URI来指定会话的主题、媒体类型或紧急程度成为可能。SIP或SIPS URI的正式语法见第25节。对于SIP URI，其一般形式为：
sip:user:password@host:port;uri-parameters?headers
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的格式相同，只是方案是“SIPS”而不是sip。这些标记及其扩展中的一些标记具有以下含义：
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
用户：正在寻址的主机上特定资源的标识符。在此上下文中，术语“主机”通常指域。URI的“userinfo”由这个用户字段、密码字段和它们后面的@符号组成。URI的userinfo部分是可选的，当
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.
目标主机没有用户的概念，或者当主机本身是被标识的资源时，目标主机没有用户的概念。如果在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.
密码：与用户关联的密码。虽然SIP和SIPS URI语法允许显示此字段，但不建议使用此字段，因为以明文形式传递身份验证信息（如URI）已被证明在几乎所有使用过它的情况下都存在安全风险。例如，在该字段中传输管脚号会暴露管脚。
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.
主机：提供SIP资源的主机。主机部分包含完全限定的域名或数字IPv4或IPv6地址。建议尽可能使用完全限定的域名形式。
port: The port number where the request is to be sent.
端口：发送请求的端口号。
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参数，任何给定的参数名称也不能出现多次。
This extensible mechanism includes the transport, maddr, ttl, user, method and lr parameters.
该可扩展机制包括传输、maddr、ttl、用户、方法和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.
transport参数确定用于发送SIP消息的传输机制，如[4]中所述。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和主机端口的正确解释，以获取发送请求的目标地址、端口和传输。
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时，才必须使用该参数。例如，指定对的调用alice@atlanta.com使用ttl为15的多播到239.255.255.1，将使用以下URI：
sip:alice@atlanta.com;maddr=239.255.255.1;ttl=15
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.
可以使用method参数指定从URI构造的SIP请求的方法。
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参数（如果存在）表示负责此资源的元素实现了本文档中指定的路由机制。此参数将在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和rfc2543bis严格路由机制的系统的向后兼容性，直至bis-05。准备基于不包含此参数的URI发送请求的元素可以假定接收元素实现严格路由并重新格式化消息以保留请求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.
Headers：要包含在从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组件的使用。“外部”列描述出现在SIP消息之外任何位置的URI，例如网页或名片上。标有“m”的条目是强制性的，标有“o”的条目是可选的，标有“-”的条目是不允许的。处理URI的元素应该忽略任何不允许的组件（如果存在）。第二列指示可选元素（如果不存在）的默认值。“--”表示元素不是可选的，或者没有默认值。
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).
联系人标头字段中的URI具有不同的限制，具体取决于标头字段出现的上下文。一组适用于建立和维护对话框的消息（INVITE及其200（OK）响应）。另一种适用于注册和重定向消息（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
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:using 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头字段值、请求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]的要求和指导原则，并使用其“%”十六进制机制进行转义。来自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]。排除的US-ASCII字符（RFC 2396[5]），例如空格和控制字符以及用作URI分隔符的字符，也必须转义。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".
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".translate error, please retry
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节中的hname和hvalue标记可以看出，头字段名称和值中的所有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
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=周二”。上面定义的转义规则允许分号在此字段中显示为非转义。就本协议而言，该字段是不透明的。该值的结构仅对负责资源的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:
本规范中的某些操作需要确定两个SIP或SIPS URI是否等效。在本规范中，注册者需要在注册请求中比较联系人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的用户信息比较区分大小写。这包括包含密码或格式化为电话订户的用户信息。除非另有明确定义，否则URI的所有其他组件的比较不区分大小写。
o The ordering of parameters and header fields is not significant in comparing SIP and SIPS URIs.
o 在比较SIP和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]）之外的其他字符等效于其“%”十六进制编码。
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 要使两个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。URI sip：user@host可通过[4]中详述的DNS SRV机制解析到其他端口。
o URI uri-parameter components are compared as follows:
o URI参数组件的比较如下所示：
- 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.
- 仅出现在一个uri中的用户、ttl或方法uri参数永远不匹配，即使它包含默认值。
- 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时，将忽略仅在一个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和match中，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:%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: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: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
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: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 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 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: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: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)
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 抿：carol@chicago.com及sip:carol@chicago.com;security=on是等效的
o sip:carol@chicago.com and sip:carol@chicago.com;security=off are equivalent
o 抿：carol@chicago.com及sip:carol@chicago.com;安全=关闭是等效的
o sip:carol@chicago.com;security=on and sip:carol@chicago.com;security=off are not equivalent
o 抿：carol@chicago.com;安全性=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生成请求时，实现需要小心。来自名片、网页甚至协议内部源（如注册联系人）的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.
实现必须在所形成请求的请求URI中包含任何提供的传输、maddr、ttl或用户参数。如果URI包含方法参数，则其值必须用作请求的方法。方法参数不能放在请求URI中。消息的请求URI中必须放置未知的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中存在的任何头或主体部分视为希望将它们包含在消息中，并选择在每个组件的基础上满足请求。
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.
实现不应接受包含头字段的请求，这可能会导致它错误地公布其位置或功能。这些包括：接受、接受编码、接受语言、允许、联系人（在其对话框使用中）、组织、支持和用户代理。
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.
实现应验证任何请求的描述性标题字段的准确性，包括：内容配置、内容编码、内容语言、内容长度、内容类型、日期、Mime版本和时间戳。
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可能表示使用了未实现的传输或扩展。实现应该拒绝发送这些请求，而不是修改它们以匹配它们的功能。实现不能发送需要其不支持的扩展的请求。
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
Thus, tel:+358-555-1234567;postd=pp22 becomes
sip:+358-555-1234567;postd=pp22@foo.com;user=phone
sip:+358-555-1234567;postd=pp22@foo.com;user=phone
or
sips:+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
not
sip:+358-555-1234567@foo.com;postd=pp22;user=phone
or
或
sips:+358-555-1234567@foo.com;postd=pp22;user=phone
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的等效性，但会影响由它们形成的SIPURI的等效性。
For example,
例如
tel:+358-555-1234567;postd=pp22
tel:+358-555-1234567;POSTD=PP22
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
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
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
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子地址和后拨除外，先发生，然后按顺序发生。（tel URL的所有组件（未来扩展参数除外）都定义为不区分大小写进行比较。）
Following this suggestion, both
根据这一建议，双方
tel:+358-555-1234567;postd=pp22
tel:+358-555-1234567;POSTD=PP22
tel:+358-555-1234567;postd=pp22
tel:+358-555-1234567;POSTD=PP22
become
成为
sip:+358-555-1234567;postd=pp22@foo.com;user=phone
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
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
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表单中的头字段中显示为参数（有关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.
“tag”参数用于SIP消息的To和From头字段。它作为识别对话框的一般机制，是调用ID和两个标签的组合，每个标签来自对话框中的每个参与者。当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的From标头中放置与在同一INVITE响应的To标头中放置不同的标记。这是UA邀请自己参加会话所必需的，这是PSTN网关中呼叫“发夹”的常见情况。类似地，不同呼叫的两个邀请将具有不同的To标记，不同呼叫的两个响应将具有不同的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”列描述了可以使用header字段的请求和响应类型。此列中的值为：
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.
答：代理可以添加或连接标题字段（如果不存在）。
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:
接下来的六列与方法中是否存在标题字段有关：
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*：应该发送头字段，但是客户端/服务器需要准备好接收没有该头字段的消息。
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：应该发送头字段，但是客户端/服务器需要准备好接收没有该头字段的消息。
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 header字段）。请求中必须存在一个“必填”标题字段，并且接收请求的UAS必须理解该字段。响应中必须存在强制响应标头字段，并且处理响应的UAC必须理解标头字段。“不适用”表示请求中不得存在标题字段。如果一个错误地放入请求中，则接收请求的UAS必须忽略它。类似地，响应的标题字段标记为“不适用”，这意味着UAS不得在响应中放置标题字段，UAC必须忽略响应中的标题字段。
A UA SHOULD ignore extension header parameters that are not understood.
UA应忽略未理解的扩展标头参数。
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.
联系人、发件人和收件人标头字段包含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 header字段遵循[H14.1]中定义的语法。语义也相同，只是如果不存在Accept header字段，服务器应该采用默认值application/sdp。
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
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
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
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.
允许接受编码头字段为空。它相当于接受编码：identity，也就是说，只允许使用identity编码，即不允许使用编码。
If no Accept-Encoding header field is present, the server SHOULD assume a default value of identity.
如果不存在Accept Encoding标头字段，则服务器应采用默认值identity。
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定义指出，当不存在时，可以使用任何编码，但首选标识编码。
Example:
例子：
Accept-Encoding: gzip
接受编码：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 header字段用于请求中，以指示作为响应中消息体的原因短语、会话描述或状态响应的首选语言。如果不存在Accept Language标头字段，则服务器应假定客户端可以接受所有语言。
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 header字段遵循[H14.4]中定义的语法。基于“q”参数对语言进行排序的规则也适用于SIP。
Example:
例子：
Accept-Language: da, en-gb;q=0.8, en;q=0.7
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 header字段指定UAS的备选铃声。当出现在180（振铃）响应中时，Alert Info header（警报信息标题）字段指定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.
警报信息标题字段可能会引入安全风险。第20.9节讨论了这些风险及其处理方法，其中讨论了Call Info header字段，因为这些风险是相同的。
In addition, a user SHOULD be able to disable this feature selectively.
此外，用户应该能够有选择地禁用此功能。
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>
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 header字段列出生成消息的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.
UA理解的所有方法（包括ACK和CANCEL）都必须包含在允许标头字段中的方法列表中（如果存在）。如果没有Allow header字段，则不能解释为发送消息的UA不支持任何方法。相反，这意味着UA没有提供任何关于其支持的方法的信息。
Supplying an Allow header field in responses to methods other than OPTIONS reduces the number of messages needed.
在对选项以外的方法的响应中提供Allow header字段可以减少所需的消息数量。
Example:
例子：
Allow: 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 header字段提供与HTTP摘要的相互身份验证。UAS可以在2xx响应中包含此头字段，该响应使用基于授权头字段的摘要成功验证了请求。
Syntax and semantics follow those specified in RFC 2617 [17].
语法和语义遵循RFC 2617[17]中的规定。
Example:
例子：
Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c"
身份验证信息：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.
授权标头字段包含UA的身份验证凭据。第22.2节概述了Authorization header字段的使用，第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.
此标头字段以及代理授权打破了有关多个标头字段值的一般规则。尽管不是逗号分隔的列表，但此标题字段名称可能会出现多次，并且不得使用第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"
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 header字段唯一标识特定邀请或特定客户端的所有注册。一次多媒体会议可能会产生多个具有不同呼叫ID的呼叫，例如，如果用户多次邀请单个用户参加同一（长期）会议。调用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
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 header字段提供有关调用者或被调用者的附加信息，具体取决于在请求或响应中是否找到该信息。URI的用途由“purpose”参数描述。“icon”参数指定适合作为呼叫者或被呼叫者的图标表示的图像。“info”参数通常描述调用者或被调用者，例如，通过网页。“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 header字段可能会带来安全风险。如果被调用者获取恶意调用者提供的URI，则被调用者可能面临显示不适当或攻击性内容、危险或非法内容等风险。因此，建议UA仅在能够验证发起报头字段的元素的真实性并信任该元素的情况下呈现Call Info报头字段中的信息。这不需要是对等UA；代理可以将此标头字段插入到请求中。
Example:
例子：
Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon,
<http://www.example.com/alice/> ;purpose=info
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.
联系人标头字段值提供一个URI，其含义取决于它所处的请求或响应类型。
A Contact header field value can contain a display name, a URI with URI parameters, and header parameters.
联系人标头字段值可以包含显示名称、带有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.
本文件定义了触点参数“q”和“expires”。这些参数仅在联系人出现在寄存器请求或响应或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，也可能没有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参数以及头参数的规则也适用于发送和发送的头字段。
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.
联系人标头字段的角色类似于HTTP中的位置标头字段。但是，HTTP头字段只允许一个地址，不带引号。由于URI可以包含逗号和分号作为保留字符，因此它们可能分别被误认为是头分隔符或参数分隔符。
The compact form of the Contact header field is m (for "moved").
联系人标题字段的紧凑形式为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
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 header字段描述UAC或UAS如何解释消息正文或多部分消息的消息正文部分。此SIP头字段扩展MIME内容类型（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".
SIP定义了内容处置头的几个新的“处置类型”。值“session”表示主体部分描述了呼叫或早期（呼叫前）媒体的会话。值“render”表示身体部位应显示或以其他方式呈现给用户。请注意，使用值“render”而不是“inline”来避免MIME正文作为整个消息呈现的一部分显示的含义（因为SIP消息的MIME正文通常不会显示给用户）。为了向后兼容，如果缺少Content Disposition header字段，则服务器应假定Content Type application/sdp的主体为Disposition“session”，而其他内容类型为“render”。
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次响铃临时响应后，该警报主体可以被呈现为电话呼叫的铃声。
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].
handling参数handling param描述了当UAS接收到其不了解其内容类型或处置类型的消息正文时应如何反应。该参数定义了“可选”和“必需”的值。如果缺少处理参数，则应假定值为“必需”。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
内容处置：会话
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.
内容编码标题字段用作“媒体类型”的修饰符。当存在时，其值指示已将哪些附加内容编码应用于实体主体，因此必须应用哪些解码机制才能获得内容类型标头字段引用的媒体类型。内容编码主要用于允许压缩正文而不丢失其底层媒体类型的标识。
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.
所有内容编码值都不区分大小写。IANA充当内容编码值标记的注册表。有关内容编码语法的定义，请参见[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.
客户端可以对请求中的正文应用内容编码。服务器可以对响应中的主体应用内容编码。服务器只能使用请求中Accept Encoding header字段中列出的编码。
The compact form of the Content-Encoding header field is e. Examples:
内容编码头字段的紧凑形式是e。示例：
Content-Encoding: gzip e: tar
内容编码：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.
Content Length标头字段表示发送给收件人的邮件正文的大小，以十进制的八位字节数表示。应用程序应使用此字段指示要传输的消息正文的大小，而不考虑实体的媒体类型。如果使用基于流的协议（如TCP）作为传输，则必须使用header字段。
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。任何大于或等于零的内容长度都是有效值。如果消息中没有正文，则必须将内容长度标题字段值设置为零。
The ability to omit Content-Length simplifies the creation of cgi-like scripts that dynamically generate responses.
省略内容长度的功能简化了动态生成响应的类cgi脚本的创建。
The compact form of the header field is l.
标题字段的紧凑形式是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标头字段指示发送给收件人的邮件正文的媒体类型。[H3.7]中定义了“媒体类型”元素。如果正文不为空，则内容类型标题字段必须存在。如果正文为空，并且存在内容类型标题字段，则表示特定类型的正文长度为零（例如，空音频文件）。
The compact form of the header field is c.
标题字段的紧凑形式是c。
Examples:
示例：
Content-Type: application/sdp
c: text/html; charset=ISO-8859-4
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:
请求中的CSeq头字段包含单个十进制序列号和请求方法。序列号必须可以表示为32位无符号整数。CSeq的方法部分区分大小写。CSeq头字段用于在对话框中对事务进行排序，提供唯一标识事务的方法，并区分新请求和请求重新传输。如果序列号和请求方法相同，则认为两个CSeq头字段相等。例子：
CSeq: 4711 INVITE
CSeq:4711邀请
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.
日期标题字段包含日期和时间。与HTTP/1.1不同，SIP仅支持日期的最新RFC 1123[20]格式。与[H3.3]一样，SIP将SIP日期中的时区限制为“GMT”，而RFC 1123允许任何时区。RFC 1123日期区分大小写。
The Date header field reflects the time when the request or response is first sent.
Date header字段反映请求或响应首次发送的时间。
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 header字段来获取当前时间的概念。然而，在GMT格式中，它要求客户知道其与GMT的偏移量。
Example:
例子：
Date: Sat, 13 Nov 2010 23:29:00 GMT
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.
错误信息标题字段提供指向有关错误状态响应的其他信息的指针。
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 header字段允许两者都发送。然后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可以将错误信息头字段中的SIP或SIPS URI视为重定向中的联系人，并生成新的INVITE，从而建立记录的公告会话。可以向用户呈现非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>
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 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.
邀请中的过期时间不会影响邀请可能导致的实际会话的持续时间。然而，会话描述协议可以提供表示会话持续时间的时间限制的能力。
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之间的整数秒（十进制），从收到请求开始测量。
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标头字段指示请求的发起人。这可能与对话框的启动器不同。被调用者发送给调用者的请求使用发件人标头字段中被调用者的地址。
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”为空，如果“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.
如果两个From头字段的uri匹配且参数匹配，则它们是等效的。为了进行比较，将忽略一个标头字段中不存在的扩展参数。这意味着显示名称和尖括号的存在与否不会影响匹配。
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.
From头字段的紧凑形式是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
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.
In Reply To header字段枚举此调用引用或返回的调用ID。这些调用ID可能已被客户端缓存，然后包含在返回调用的此标头字段中。
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
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 header字段必须与任何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应插入一个最大转发头字段。
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.
Min Expires标头字段表示该服务器管理的软状态元素支持的最小刷新间隔。这包括由登记员存储的联系人标题字段。标头字段包含从0到（2**32）-1的十进制整数秒数。第10.2.8、10.3和21.4.17节描述了在423（间隔太短）响应中使用标题字段的情况。
Example:
例子：
Min-Expires: 60
最低有效期：60
See [H19.4.1].
见[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.
Organization header字段表示发出请求或响应的SIP元素所属的组织的名称。
The field MAY be used by client software to filter calls.
该字段可由客户端软件用于过滤呼叫。
Example:
例子：
Organization: Boxes by Bob
组织：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 header字段表示客户端感知到的请求的紧急程度。优先级标头字段描述SIP请求对接收人员或其代理应具有的优先级。例如，它可能被考虑到有关呼叫路由和接受的决策中。对于这些决定，不包含优先级标头字段的消息应被视为指定了“正常”优先级。优先级报头字段不影响通信资源的使用，例如路由器中的分组转发优先级或对PSTN网关中电路的访问。标题字段可以有值“非紧急”、“正常”、“紧急”和“紧急”，但其他值可以在别处定义。建议仅当生命、肢体或财产处于迫在眉睫的危险时，才使用“紧急情况”的值。否则，没有为此标题字段定义语义。
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.
代理身份验证标头字段值包含身份验证质询。
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
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.
Proxy Authorization header字段允许客户端向需要身份验证的代理标识其自身（或其用户）。代理授权字段值由凭据组成，其中包含所请求资源的代理和/或领域的用户代理的身份验证信息。
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.
此标题字段与授权一起，打破了有关多个标题字段名称的一般规则。尽管不是逗号分隔的列表，但此标题字段名称可能会出现多次，并且不得使用第7.3.1节中描述的常规规则组合成一个标题行。
Example:
例子：
Proxy-Authorization: Digest username="Alice", realm="atlanta.com",
nonce="c60f3082ee1212b402a21831ae",
response="245f23415f11432b3434341c022"
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
代理要求：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.
代理在请求中插入“记录路由头”字段，以强制对话框中的未来请求通过代理路由。
Examples of its use with the Route header field are described in Sections 16.12.1.
第16.12.1节描述了其与Route header字段一起使用的示例。
Example:
例子：
Record-Route: <sip:server10.biloxi.com;lr>,
<sip:bigbox3.site3.atlanta.com;lr>
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 header字段包含可能不同于from header字段的逻辑返回URI。例如，URI可用于返回未接来电或未建立的会话。如果用户希望保持匿名，则应该从请求中省略标题字段，或者以不泄露任何私人信息的方式填充标题字段。
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>
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使用Require header字段告诉UAS UAC希望UAS支持的选项，以便处理请求。尽管是可选的标题字段，但如果存在Require，则不能忽略它。
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.
Require header字段包含选项标签列表，如第19.2节所述。每个选项标记定义了一个SIP扩展，必须理解该扩展才能处理请求。通常，这表示需要理解一组特定的扩展头字段。符合本规范的UAC必须仅包括与标准跟踪RFC相对应的选项标签。
Example:
例子：
Require: 100rel
要求：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
Retry After header字段可与500（服务器内部错误）或503（服务不可用）响应一起使用，以指示服务预计对请求客户端不可用的时间，并与404（未找到）、413（请求实体太大）、480（暂时不可用）、486（此处忙）、600（忙）或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.
（拒绝）响应，指示被叫方预计何时再次可用。此字段的值是响应时间后的正整数秒数（十进制）。
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.
可选注释可用于指示有关回调时间的附加信息。可选的“duration”参数表示从可用性的初始时间开始，被叫方可以到达的时间。如果未给出持续时间参数，则假定服务无限期可用。
Examples:
示例：
Retry-After: 18000;duration=3600
Retry-After: 120 (I'm in a meeting)
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 header字段用于通过列出的代理集强制路由请求。第16.12.1节给出了使用路线标题字段的示例。
Example:
例子：
Route: <sip:bigbox3.site3.atlanta.com;lr>,
<sip:server10.biloxi.com;lr>
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.
服务器头字段包含有关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.
透露服务器的特定软件版本可能会使服务器更容易受到针对已知包含安全漏洞的软件的攻击。实现者应该将服务器头字段设置为可配置选项。
Example:
例子：
Server: HomeServer v2
服务器：主服务器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.
Subject header字段提供一个摘要或指示调用的性质，允许在不解析会话描述的情况下进行调用筛选。会话描述不必使用与邀请相同的主题指示。
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.
Supported header字段枚举UAC或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相对应的选项标签。如果为空，则表示不支持任何扩展。
The compact form of the Supported header field is k.
支持的标题字段的紧凑形式是k。
Example:
例子：
Supported: 100rel
支持：100rel
The Timestamp header field describes when the UAC sent the request to the UAS.
时间戳标头字段描述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.
有关如何对包含标头字段的请求生成响应的详细信息，请参见第8.2.6节。尽管这里没有定义使用报头的规范行为，但它允许扩展或SIP应用程序获得RTT估计值。
Example:
例子：
Timestamp: 54
时间戳：54
The To header field specifies the logical recipient of the request.
“收件人标头”字段指定请求的逻辑收件人。
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.
可选的“显示名称”是指由人机界面呈现。“tag”参数用作对话框标识的一般机制。
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.
比较到标头字段是否相等与比较从标头字段是否相等相同。有关解析显示名称、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: The Operator <sip:operator@cs.columbia.edu>;tag=287447
t: sip:+12125551212@server.phone2net.com
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.
Unsupported header字段列出了UAS不支持的功能。参见第20.32节了解动机。
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].
用户代理标头字段包含有关发起请求的UAC的信息。[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.
透露用户代理的特定软件版本可能会使用户代理更容易受到针对已知包含安全漏洞的软件的攻击。实现者应该将用户代理头字段设置为可配置选项。
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 header字段指示到目前为止请求所采用的路径，并指示路由响应中应遵循的路径。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
Via header字段值包含用于发送消息的传输协议、客户端的主机名或网络地址，以及它希望接收响应的端口号。Via头字段值还可以包含诸如“maddr”、“ttl”、“received”和“branch”等参数，其含义和用途如下所述
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.
在其他章节中。对于符合本规范的实现，分支参数的值必须以魔法cookie“z9hG4bK”开头，如第8.1.1.7节所述。
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”指TCP上的TLS。当向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
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.
在本例中，消息来自具有两个地址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:
主机或网络地址和端口号不需要遵循SIP URI语法。具体而言，允许在“：”或“/”的任一侧使用LWS，如下所示：
Via: SIP / 2.0 / UDP first.example.com: 4000;ttl=16
;maddr=224.2.0.1 ;branch=z9hG4bKa7c6a8dlze.1
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.
即使本规范要求在所有请求中都存在branch参数，但header字段的BNF表明它是可选的。这允许与RFC 2543元素进行互操作，而不必插入分支参数。
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.
如果两个Via头字段的“发送协议”和“发送方式”字段相等，则两个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.
警告标题字段用于携带有关响应状态的附加信息。警告标题字段值随响应一起发送，并包含三位数字的警告代码、主机名和警告文本。
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
“警告文本”应采用自然语言，最有可能让接收响应的人类用户理解。此决定可以基于任何可用的知识，例如用户的位置、请求中的Accept Language字段或
Content-Language field in a response. The default language is i-default [21].
响应中的内容语言字段。默认语言为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参数相关的警告，和390至399是不属于上述类别之一的杂项警告。
300 Incompatible network protocol: One or more network protocols contained in the session description are not available.
300不兼容的网络协议：会话描述中包含的一个或多个网络协议不可用。
301 Incompatible network address formats: One or more network address formats contained in the session description are not available.
301不兼容的网络地址格式：会话描述中包含的一个或多个网络地址格式不可用。
302 Incompatible transport protocol: One or more transport protocols described in the session description are not available.
302不兼容的传输协议：会话描述中描述的一个或多个传输协议不可用。
303 Incompatible bandwidth units: One or more bandwidth measurement units contained in the session description were not understood.
303不兼容的带宽单元：会话描述中包含的一个或多个带宽测量单元未被理解。
304 Media type not available: One or more media types contained in the session description are not available.
304媒体类型不可用：会话描述中包含的一个或多个媒体类型不可用。
305 Incompatible media format: One or more media formats contained in the session description are not available.
305不兼容的媒体格式：会话描述中包含的一种或多种媒体格式不可用。
306 Attribute not understood: One or more of the media attributes in the session description are not supported.
306属性不可理解：会话描述中的一个或多个媒体属性不受支持。
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单播不可用：用户所在的站点不支持单播通信（通常由于存在防火墙）。
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.
HTTP/1.1采用了1x和2xx。
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
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毫秒以上才能获得最终响应，则会发送1x响应。请注意，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.
接收到邀请的UA正在尝试提醒用户。此响应可用于启动本地回铃。
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.
被叫方暂时不可用，但服务器已决定对呼叫排队，而不是拒绝呼叫。当被调用方可用时，它将返回相应的最终状态响应。原因短语可能提供有关呼叫状态的更多详细信息，例如，“5个呼叫已排队；预期等待时间为15分钟”。服务器可发出若干182（排队）响应，以向呼叫者更新排队呼叫的状态。
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（会话进度）响应用于传达关于呼叫进度的信息，该信息未被分类。原因短语、标题字段或消息正文可用于传达有关呼叫进度的更多细节。
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.
响应可以包括消息正文，其中包含资源特征和位置的列表，如果接受请求报头字段允许，则用户或UA可以从中选择最合适的一个。但是，尚未为此邮件正文定义任何MIME类型。
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节）。与HTTP不同，SIP响应可能包含多个联系人字段或联系人字段中的地址列表。UAs可以使用联系人标头字段值进行自动重定向，也可以要求用户确认选择。然而，本规范并未定义此类自动选择的任何标准。
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.
在请求URI中的地址处再也找不到用户，请求客户端应在联系人标头字段给出的新地址处重试（第20.10节）。请求者应使用此新值更新任何本地目录、通讯簿和用户位置缓存，并将未来的请求重定向到列出的地址。
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.
请求客户端应在联系人标头字段（第20.10节）给出的新地址重试请求。新请求的请求URI使用响应中联系人标头字段的值。
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.
联系人URI的有效期可通过Expires（第20.19节）标题字段或Contact header字段中的Expires参数指示。代理和UAs都可以在到期时间内缓存此URI。如果没有明确的过期时间，则该地址对于递归仅有效一次，并且不能缓存以用于将来的事务。
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 header字段缓存的URI失败，则可以再次尝试重定向请求的请求URI。
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字段提供代理的URI。收件人应通过代理重复此单个请求。305（使用代理）响应只能由UAS生成。
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响应是特定服务器的明确故障响应。客户端不应在没有修改的情况下重试同一请求（例如，添加适当的授权）。但是，对不同服务器的相同请求可能会成功。
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".
由于语法错误，无法理解该请求。原因短语应该更详细地识别语法问题，例如，“缺少呼叫ID标头字段”。
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.
服务器具有用户在请求URI中指定的域中不存在的确定信息。如果请求URI中的域与请求收件人处理的任何域不匹配，也会返回此状态。
The method specified in the Request-Line is understood, but not allowed for the address identified by the Request-URI.
可以理解请求行中指定的方法，但请求URI标识的地址不允许使用该方法。
The response MUST include an Allow header field containing a list of valid methods for the indicated address.
响应必须包括一个Allow header字段，其中包含指定地址的有效方法列表。
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.
根据请求中发送的Accept header字段，由请求标识的资源只能生成具有不可接受内容特征的响应实体。
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（未经授权），但表示客户端必须首先向代理进行身份验证。第26节和第22.3节解释了SIP访问认证。
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（未找到）。
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.
服务器拒绝为请求提供服务，因为请求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标头字段返回可接受格式的列表。第8.1.3.5节描述了UAC对该响应的处理。
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.
服务器无法处理该请求，因为服务器不知道请求URI中URI的方案。第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.
服务器不理解代理请求（第20.29节）或请求（第20.32节）头字段中指定的协议扩展。服务器必须在响应中的不支持标头字段中包含不支持扩展的列表。第8.1.3.5节描述了UAC对该响应的处理。
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.
UAS需要一个特定的扩展来处理请求，但该扩展未列在请求中支持的标头字段中。具有此状态代码的响应必须包含一个Require header字段，其中列出了所需的扩展名。
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.
UAS不应使用此响应，除非它确实无法向客户端提供任何有用的服务。相反，如果所需的扩展未在Supported header字段中列出，则服务器应使用基线SIP功能和客户端支持的任何扩展来处理请求。
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.
服务器拒绝该请求，因为该请求刷新的资源的过期时间太短。注册官可以使用此响应拒绝联系人标头字段过期时间过短的注册。第10.2.8节、第10.3节和第20.23节介绍了该响应的使用和相关的Min Expires标头字段。
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.
已成功联系被叫方的终端系统，但被叫方当前不可用（例如，未登录、已登录但处于阻止与被叫方通信的状态，或已激活“请勿打扰”功能）。响应可能指示在重试后报头字段中调用的更好时间。用户也可以在其他地方使用（此服务器不知道）。“原因”短语应指明被呼叫方不可用的更确切原因。该值应由UA设置。状态486（此处忙）可用于更精确地指示呼叫失败的特定原因。
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.
此状态也由重定向或代理服务器返回，该服务器识别由请求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.
服务器收到的请求URI不完整。应在原因短语中提供其他信息。
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（地址不完整）状态响应。
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.
请求URI不明确。响应可能包含联系人标头字段中可能的明确地址列表。泄露备选方案可能会侵犯用户或组织的隐私。必须能够将服务器配置为以状态404（未找到）响应，或者禁止列出不明确请求URI的可能选项。
Example response to a request with the Request-URI sip:lee@example.com:
使用请求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>
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.
一些电子邮件和语音邮件系统提供此功能。由于语义不同，因此使用了与3xx分开的状态代码：对于300，假设所提供的选择将访问同一个人或服务。虽然自动选择或顺序搜索对3xx响应有意义，但485（不明确）响应需要用户干预。
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.
其他地方，如通过语音邮件服务。如果客户端知道没有其他终端系统能够接受此呼叫，则应使用状态600（到处忙）。
The request was terminated by a BYE or CANCEL request. This response is never returned for a CANCEL request itself.
请求被BYE或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相同的含义（不可接受），但仅适用于由请求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（或应用程序/sdp，如果不存在）中的Accept header字段进行格式化，与对OPTIONS请求的200（确定）响应中的消息体相同。
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.
服务器遇到意外情况，无法满足请求。客户端可能会显示特定的错误条件，并可能在几秒钟后重试请求。
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标头字段中指示客户端何时应重试请求。如果没有给出重试后，客户端必须像收到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（服务不可用）的客户端（代理或UAC）应尝试将请求转发到备用服务器。在头字段（如果存在）后重试中指定的持续时间内，它不应将任何其他请求转发到该服务器。
Servers MAY refuse the connection or drop the request instead of responding with 503 (Service Unavailable).
服务器可能会拒绝连接或丢弃请求，而不是使用503（服务不可用）进行响应。
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.
服务器在试图处理请求时未收到来自其访问的外部服务器的及时响应。如果在来自上游服务器的Expires标头字段中指定的时间段内没有响应，则应使用408（请求超时）。
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响应表示服务器具有关于特定用户的确定信息，而不仅仅是请求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.
已成功联系被叫方的终端系统，但被叫方正忙，此时不想接听电话。响应可能指示在重试后报头字段中调用的更好时间。如果被叫方不希望透露拒绝呼叫的原因，被叫方将使用状态代码603（拒绝）。只有当客户端知道没有其他端点（如语音邮件系统）将响应请求时，才会返回此状态响应。否则，应返回486（此处忙）。
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.
已成功联系被叫方的计算机，但用户明确不希望或无法参与。响应可能指示在重试后报头字段中调用的更好时间。只有当客户端知道没有其他端点将响应请求时，才会返回此状态响应。
The server has authoritative information that the user indicated in the Request-URI does not exist anywhere.
服务器具有权威信息，即请求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（不可接受）响应意味着用户希望通信，但不能充分支持所描述的会话。606（不可接受）响应可能在警告标头字段中包含原因列表，说明所述会话不受支持的原因。第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（或应用程序/sdp，如果不存在）中的Accept header字段进行格式化，与对OPTIONS请求的200（确定）响应中的消息体相同。
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（不可接受）响应采取行动。
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节中给出的例外情况除外），都可能向请求的发起人提出质疑，以确保其身份。一旦确定了发起人，请求接收人应确定该用户是否有权提出有问题的请求。本文件不建议或讨论授权系统。
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.
本节中描述的“摘要”身份验证机制仅提供消息身份验证和重播保护，而不提供消息完整性或机密性。需要采取高于Digest提供的保护措施，以防止主动攻击者修改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.
请注意，由于“基本”身份验证的安全性较差，因此已不推荐使用它。服务器不得接受使用“基本”授权方案的凭据，服务器也不得使用“基本”进行质询。这是对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)
SIP认证的框架与HTTP（RFC 2617[17]）的框架非常相似。特别是，auth scheme、auth param、challenge、realm、realm值和凭据的BNF是相同的（尽管不允许将“Basic”用作方案）。在SIP中，UAS使用401（未经授权）响应质疑UAC的身份。此外，注册器和重定向服务器可以使用401（未经授权）响应进行身份验证，但代理不能使用，而是可以使用407（需要代理身份验证）
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].
回答在各种消息中包含代理身份验证、代理授权、WWW身份验证和授权的要求与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中有不同的解释。领域字符串单独定义保护域。这是对RFC2543的更改，在RFC2543中，请求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发送的请求URI和质询服务器接收的请求URI可能不同，并且UAC可能不知道请求URI的最终形式，因此之前对保护域的定义造成了一定程度的混淆。此外，前面的定义取决于请求URI中是否存在SIPURI，并且似乎排除了其他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 领域字符串应提供可呈现给用户的可读标识符。
For example:
例如：
INVITE sip:bob@biloxi.com SIP/2.0
Authorization: Digest realm="biloxi.com", <...>
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认证对于特定领域（保护域）是有意义的。因此，对于摘要身份验证，每个这样的保护域都有自己的用户名和密码集。如果服务器不需要对特定请求进行身份验证，则可以接受默认用户名“匿名”，该用户名没有密码（密码为“”）。类似地，代表许多用户（如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请求，但本文档定义的两个请求需要对身份验证进行特殊处理：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.
在使用响应来携带用于计算nonce的值（例如摘要）的身份验证方案下，任何不接受响应的请求（包括ACK）都会出现一些问题。因此，服务器接受的INVITE中的任何凭据都必须被该服务器接受，以获得ACK。UACs创建ACK消息将复制ACK对应的INVITE中出现的所有授权和代理授权标头字段值。服务器不得尝试质询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请求，因为无法重新提交这些请求。通常，如果取消请求来自发送被取消请求的同一跳，则服务器应接受该取消请求（前提是存在某种传输或网络层安全关联，如第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身份验证标头字段或代理身份验证标头字段中）。使用其领域的凭据预配置UAs的服务提供商应该知道，当在预配置的设备上受到质询时，用户将没有机会为此领域提供自己的凭据。
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命令进行响应。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可以在处理该请求之前对发起人进行身份验证。如果请求中未提供凭证（在授权标头字段中），UAS可以通过使用401（未授权）状态代码拒绝请求来质询发起人提供凭证。
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（未经授权）响应消息中。字段值至少包含一个质询，该质询指示适用于领域的身份验证方案和参数。
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=“DCD98B7102DD2DF0E8B1D0F600BFB0C093”，不透明=“5CC069C403EBAF9F0171E9517F40E41”
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（未经授权）时，如果能够，它应该使用正确的凭据重新发起请求。UAC在继续之前可能需要原始用户的输入。一旦提供了身份验证凭据（由用户直接提供，或在内部密钥环中发现），UAs应缓存To头字段和“realm”的给定值的凭据，并尝试在下一次请求该目的地时重新使用这些值。UAs可以以任何方式缓存凭据。
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 "").
如果找不到域的凭据，UACs可能会尝试使用用户名“anonymous”和密码（密码为“”）重试请求。
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（未经授权）响应后）都可以通过在请求中包含授权标头字段来实现。授权字段值由包含所请求资源领域UA的身份验证信息的凭据以及支持身份验证和重播保护所需的参数组成。
An example of the Authorization header field is:
授权标头字段的一个示例是：
Authorization: Digest username="bob",
realm="biloxi.com",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="sip:bob@biloxi.com",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
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向代理服务器发送请求时，代理服务器可以在处理请求之前对发起人进行身份验证。如果请求中未提供凭据（在代理授权标头字段中），则代理可以通过使用407（需要代理身份验证）状态代码拒绝请求来质询发起人提供凭据。代理必须使用适用于所请求资源的代理的代理身份验证标头字段值填充407（需要代理身份验证）消息。
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.
代理身份验证和代理授权的使用与[17]中所述的并行，但有一个区别。代理不得向代理授权标头字段添加值。所有407（需要代理身份验证）响应必须按照任何其他响应的程序向上游转发到UAC。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.
如果代理要重新提交请求并添加代理授权标头字段值，则需要在新请求中增加CSeq。但是，这将导致提交原始请求的UAC放弃来自UAS的响应，因为CSeq值将不同。
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（需要代理身份验证）时，如果能够，它应该使用正确的凭据重新发起请求。它应该遵循上面为响应401而给出的显示“realm”参数的相同过程。
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 "").
如果找不到域的凭据，UACs可能会尝试使用用户名“anonymous”和密码（密码为“”）重试请求。
The UAC SHOULD also cache the credentials used in the re-originated request.
UAC还应该缓存重新发起的请求中使用的凭据。
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
如果UA在对具有特定呼叫ID的请求的401/407响应中收到代理身份验证标头字段值，则它应在包含相同呼叫ID的所有后续请求中包含该领域的凭据。这些凭据不得跨对话框缓存；但是，如果UA配置了其本地出站代理的域（如果存在），则UA可能会缓存
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.
跨对话框访问该领域的凭据。请注意，这确实意味着对话框中的未来请求可能包含路由头路径上任何代理都不需要的凭据。
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 Authorization request header（代理授权请求标头）字段允许客户端向需要身份验证的代理标识其自身（或其用户）。Proxy Authorization header（代理授权标头）字段值由凭据组成，其中包含所请求资源的代理和/或领域的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.
代理授权标头字段值仅适用于其域在“realm”参数中标识的代理（此代理以前可能使用代理身份验证字段要求进行身份验证）。当在一个链中使用多个代理时，代理授权标头字段值不得由其领域与该值中指定的“领域”参数不匹配的任何代理使用。
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.
请注意，如果在代理授权标头字段中使用不支持领域的身份验证方案，则代理服务器必须尝试解析所有代理授权标头字段值，以确定其中一个是否具有代理服务器认为有效的凭据。因为这在大型网络中可能非常耗时，所以代理服务器应该在代理授权标头字段中使用支持领域的身份验证方案。
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节所述），各种代理服务器和/或UAs可能希望挑战UAC。在这种情况下，分叉代理服务器负责将这些挑战聚合到单个响应中。在对分叉请求的响应中接收的每个WWW认证和代理认证值必须放入分叉代理发送给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
当代理服务器响应请求发出质询时，在UAC使用有效凭据重试该请求之前，它不会代理该请求。分叉代理可以同时将请求转发给需要身份验证的多个代理服务器，而每个代理服务器在发起UAC在各自的域中对自身进行身份验证之前不会转发请求。如果UAC未提供
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.
每次质询时，发出质询的代理服务器都不会将请求转发到目标用户可能所在的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身份验证值的授权值以及UAC希望为其提供凭证的每个代理身份验证值的代理授权值。如上所述，请求中的多个凭据应通过“realm”参数进行区分。
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（需要代理身份验证）中。例如，当分叉请求到达同一管理域中使用公共域的多个代理时，可能会发生这种情况。当UAC重试一个请求时，它可能因此在授权或代理授权头字段中提供具有相同“领域”参数值的多个凭证。同一领域应使用相同的凭据。
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
2. RFC 2617中的BNF有一个错误，HTTP摘要的授权标头字段的“uri”参数
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.
验证不包含在引号中。（RFC 2617第3.5节中的示例是正确的。）对于SIP，“uri”必须用引号括起来。
3. The BNF for digest-uri-value is:
3. 摘要uri的BNF值为：
digest-uri-value = Request-URI ; as defined in Section 25
摘要uri值=请求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和授权标头字段中包含的URI是否指向同一资源。在SIP上下文中，由于在某个代理上进行转发，这两个URI可能引用不同的用户。因此，在SIP中，服务器可以检查授权报头字段值中的请求URI是否对应于服务器愿意接受转发或直接请求的用户，但如果这两个字段不相等，则不一定是失败。
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"
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指令，则不得在授权（以及扩展代理授权）头字段中发送cnonce值。因此，任何依赖cnonce（包括“MD5 Sess”）的算法都需要发送qop指令。在RFC 2617中，为了向后兼容RFC 2069，可选择使用“qop”参数；由于RFC 2543基于RFC 2069，因此“qop”参数必须是可选的，以便客户端和服务器接收。但是，服务器必须始终在WWW 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不允许使用身份验证信息头字段（它有效地使用了RFC 2069）。但是，我们现在允许使用这个头字段，因为它提供了对主体的完整性检查并提供了相互身份验证。RFC 2617[17]使用请求中的qop属性定义向后兼容性机制。服务器必须使用这些机制来确定客户端是否支持RFC 2617中未在RFC 2069中指定的新机制。
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内容的机制，以确保完整性和机密性（包括“多部分/签名”和“应用程序/pkcs7 MIME”MIME类型，请参见RFC 1847[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的目的，用于识别最终用户的证书与服务器使用的证书在一个重要方面不同——这些证书不是断言持有者的身份对应于特定的主机名，而是断言持有者由最终用户地址识别。此地址由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头字段）时，他们应该使用相同的证书。
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.
任何依赖最终用户证书存在的机制都受到严重限制，因为目前几乎没有为最终用户应用程序提供证书的统一机构。但是，用户应该从已知的公共证书颁发机构获取证书。或者，用户可以创建自签名证书。第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.
除了获取最终用户证书的问题之外，几乎没有分发最终用户证书的著名集中式目录。但是，证书持有人应酌情在任何公共目录中发布其证书。类似地，UACs应该支持导入（手动或自动）在与SIP请求的目标URI相对应的公共目录中发现的证书的机制。
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.
每当在S/MIME for SIP中使用CMS SignedData消息时，它必须包含带有验证签名所需公钥的证书。
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“多部分/签名”CMS SignedData主体。如果所需的CMS服务是EnvelopedData（且目标用户的公钥已知），UAC应发送封装在SignedData消息中的EnvelopedData消息。
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
当UAS接收到包含S/MIME CMS正文（其中包含证书）的请求时，UAS应首先使用证书颁发机构的任何可用根证书（如果可能）验证证书。UAS还应确定证书的主题（对于S/MIME，SubjectAltName将包含适当的标识），并将此值与From标头字段进行比较
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.
请求的一部分。如果证书无法验证，因为它是自签名的，或者没有已知的权威机构签名，或者如果它是可验证的，但其主题与请求的From标头字段不一致，UAS必须通知其用户证书的状态（包括证书的主题、其签名者和任何密钥指纹信息）并在继续之前请求明确许可。如果证书已成功验证，且证书的主题对应于SIP请求的From标头字段，或者如果用户（在通知后）明确授权使用证书，则UAS应将该证书添加到本地密钥环，并根据证书持有人的记录地址进行索引。
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“多部分/签名”CMS SignedData正文。如果所需的CMS服务是EnvelopedData，UAS应发送封装在SignedData消息中的EnvelopedData消息。
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应首先使用任何适当的根证书（如果可能）验证该证书。UAC还应确定证书的主题，并将该值与响应的to字段进行比较；虽然两者可能非常不同，但这并不一定表明存在安全漏洞。如果证书由于自签名或由未知机构签名而无法验证，UAC必须通知其用户证书的状态（包括证书的主题、签名者和任何密钥指纹信息），并在继续之前请求明确的许可。如果证书已成功验证，并且证书的主题与响应中的“收件人”标题字段相对应，或者如果用户（在通知后）明确授权使用证书，UAC应将此证书添加到本地密钥环，并根据证书持有人的记录地址进行索引。如果UAC在之前的任何交易中没有向UAS传输自己的证书，则应在下一次请求或响应中使用CMS SignedData主体。
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
在将来的情况下，当UA接收到包含与其密钥环中的值相对应的From报头字段的请求或响应时，UA应将这些消息中提供的证书与其密钥环中的现有证书进行比较。如果存在差异，UA必须通知其用户证书的更改（最好是在表明这是潜在的安全违规的条款中），并在继续操作之前获得用户的许可
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.
处理信号。如果用户授权此证书，则应将其与此记录地址的任何先前值一起添加到密钥环中。
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正文已使用收件人未知的公钥加密，则必须以493（不可解密）响应拒绝该请求。此响应应包含MIME正文中响应者的有效证书（如果可能，对应于被拒绝请求的to标头字段中给出的任何记录地址），并带有“certs only”的“smime type”参数。
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.
请注意，如果未理解MIME类型，则接收包含非可选S/MIME正文（内容处置头“handling”参数为“required”）的请求的用户代理必须使用415不支持的媒体类型响应拒绝该请求。当发送S/MIME时接收到此类响应的用户代理应通知其用户远程设备不支持S/MIME，并且如果合适，可随后在不使用S/MIME的情况下重新发送请求；然而，该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应通知其用户会话无法安全。但是，如果支持S/MIME的用户代理接收到带有不安全正文的请求，则不应使用安全正文进行响应，但如果它期望来自发送方的S/MIME（例如，因为发送方的from header字段值对应于其密钥链上的标识），则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感兴趣的安全MIME主体有两种类型：这些主体的使用应遵循S/MIME规范[24]，但有一些变化。
o "multipart/signed" MUST be used only with CMS detached signatures.
o “多部分/签名”只能与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主体应具有内容处置头字段，“handling”参数的值应为“required”
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消息。UACs可发送初始请求，例如带有CMS分离签名的选项消息，以请求远程方的证书（签名应在第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"
o S/MIME主体的发送方应使用“SMIMECapabilities”（见[24]第2.5.2节）属性来表示其进一步通信的能力和首选项。请特别注意，发件人可以使用“preferSignedData”
capability to encourage receivers to respond with CMS SignedData messages (for example, when sending an OPTIONS request as described above).
鼓励接收者响应CMS SignedData消息的能力（例如，当发送如上所述的选项请求时）。
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正文应仅使用一个证书进行签名。如果UA收到具有多个签名的消息，则最外层的签名应被视为该主体的单个证书。不应使用并行签名。
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
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 *
*******************************************************
*******************************************************
* 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可以将整个SIP消息封装在类型为“message/SIP”的MIME主体内，然后以与典型SIP主体相同的方式将MIME安全性应用于这些主体。这些封装的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接收到包含隧道“message/sip”S/MIME正文的请求，它应该在响应中包含具有相同smime类型的隧道“message/sip”正文。
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）都应该附加到“内部”消息，这样它们也可以从S/MIME安全性中获益。请注意，如果在请求中还应传输任何不安全的MIME类型，则“message/sip”主体可以作为MIME“multipart/mixed”主体的一部分发送。
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消息都应该在“内部”和“外部”报头中包含一个日期报头。
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.
每当执行完整性检查时，应通过使用SIP的比较规则（如20所述）将签名正文中的头字段值与“外部”消息中的头字段值进行匹配来确定头字段的完整性。
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.
代理服务器可以合法修改的头字段有：请求URI、Via、记录路由、路由、最大转发和代理授权。如果这些头字段不是完整的端到端，则实现不应认为这是违反安全性的。对本文档中定义的任何其他标题字段的更改构成完整性冲突；必须将不符点通知用户。
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.
收件人、发件人、呼叫ID、CSeq、联系人。虽然为呼叫ID、CSeq或联系人提供加密的替代方案可能没有用处，但允许提供“外部”to或From中信息的替代方案。请注意，加密正文中的值不用于标识事务或对话框，它们只是信息性的。如果加密正文中的“发件人”标头字段与“外部”消息中的值不同，则应向用户显示加密正文中的值，但不得在任何未来消息的“外部”标头字段中使用。
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.
用户代理主要希望加密具有端到端语义的头字段，包括：主题、回复、组织、接受、接受编码、接受语言、警报信息、错误信息、身份验证信息、过期、回复中、要求、支持、不支持、重试后、用户代理、服务器和警告。如果这些头字段中的任何一个存在于加密的正文中，则应使用它们而不是任何“外部”头字段，无论这是否需要向用户显示头字段值或在UA中设置内部状态。但是，它们不应用于任何未来消息的“外部”标题中。
If present, the Date header field MUST always be the same in the "inner" and "outer" headers.
如果存在，则“内部”和“外部”标题中的日期标题字段必须始终相同。
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特定的头字段，包括：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
加密以下标头字段不是特别有用：Min Expires、Timestamp、Authorization、Priority和WWW Authenticate。此类别还包括可由代理服务器更改的标题字段（如前一节所述）。UAs不应该在“内部”消息中包含这些信息，如果它们不是
included in the "outer" message. UAs that receive any of these header fields in an encrypted body SHOULD ignore the encrypted values.
包含在“外部”消息中。在加密正文中接收任何这些头字段的UAs应忽略加密值。
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遇到完整性冲突的未知标头字段，则必须忽略该标头字段。
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.
如果发送方希望保护的头字段复制在使用CMS分离签名签名的“message/SIP”MIME主体中，则S/MIME主体内的隧道SIP消息可以为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.
如果“message/sip”主体至少包含基本的对话标识符（To、From、Call ID、CSeq），那么签名的MIME主体可以提供有限的身份验证。至少，如果收件人不知道用于签署正文的证书，并且无法对其进行验证，则可以使用该签名来确定对话中稍后的请求是否由发起对话的同一证书持有人发送。如果签名MIME主体的接收者有更强烈的动机信任证书（他们能够验证证书，他们从受信任的存储库获得证书，或者他们经常使用证书），那么签名可以被视为对证书主体身份的更有力的断言。
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.
如果带有签名正文的邮件中存在日期标头，则收件人应将标头字段值与其自己的内部时钟（如果适用）进行比较。如果检测到明显的时间差异（大约一小时或更长），用户代理应向用户发出异常警报，并注意这是一个潜在的安全漏洞。
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（禁止）响应，或者任何现有对话框可能会被终止。UAs应将这种情况通知用户，并要求提供关于如何进行的明确指导。
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
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
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
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
--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
Ghyhhhhhhhhhhhhhhhhhhjhjh77n8hghtrfvbnj756tb9hg4vqpfyf467ghighfyt6 4vqpfyf467ghighfyt6jhhhhhhhhhhhhhhhhhhhhhjhjh756tb9hgtrffbnj n8hghtrfvhhhhhhhhhhhhhj776bb9hg4vqbnj7567ghigfyfyfyfyfyf4 7ghigff
--boundary42-
--边界42-
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信封数据消息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). 但是，包含发起者的真实记录地址的第二个From头字段可以在“message/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密钥。必须首先对消息进行解密，并且必须将“inner”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".
为了提供端到端的完整性，加密的“message/sip”MIME主体应由发送方签名。这将创建一个“multipart/signed”MIME正文，其中包含一个加密正文和一个签名，两者均为“application/pkcs7 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
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
--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 *
***********************************************************
***********************************************************
* 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
--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
Ghyhhhhhhhhhhhhhhhhhhjhjh77n8hghtrfvbnj756tb9hg4vqpfyf467ghighfyt6 4vqpfyf467ghighfyt6jhhhhhhhhhhhhhhhhhhhhhjhjh756tb9hgtrffbnj n8hghtrfvhhhhhhhhhhhhhj776bb9hg4vqbnj7567ghigfyfyfyfyfyf4 7ghigff
--boundary42-
--边界42-
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.
在下面的示例中，为了简洁起见，我们通常省略消息体以及相应的内容长度和内容类型头字段。
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 |
|--------------->|
biloxi.com Bob's
registrar softphone
| |
| REGISTER F1 |
|<---------------|
| 200 OK F2 |
|--------------->|
Figure 9: SIP Registration Example
图9:SIP注册示例
F1 REGISTER Bob -> Registrar
F1注册Bob->REGISTER
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
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:
注册两小时后到期。注册器以200 OK响应：
F2 200 OK Registrar -> Bob
F2 200正常注册器->鲍勃
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
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邀请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
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)
（未显示Alice的SDP）
F2 100 Trying atlanta.com proxy -> Alice
F2100正在尝试atlanta.com代理->Alice
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
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邀请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
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)
（未显示Alice的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
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
F5邀请biloxi.com代理->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
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)
（未显示Alice的SDP）
F6 180 Ringing Bob -> biloxi.com proxy
F6 180振铃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
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代理->亚特兰大.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
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
F8 180响铃亚特兰大网站代理->爱丽丝
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
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 Bob->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
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
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)
（未显示鲍勃的SDP）
F11 200 OK atlanta.com proxy -> Alice
F11 200 OK atlanta.com代理->Alice
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
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 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
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.
Alice和Bob之间的媒体会话现已建立。
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.
鲍勃先挂断电话。请注意，Bob的SIP电话维护自己的CSeq编号空间，在本例中，该空间以231开头。由于Bob正在发出请求，往返URI和标记已交换。
F13 BYE Bob -> Alice
再见，鲍勃->爱丽丝
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
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
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
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
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替换任何线性空白。这与RFC 2616[8]中描述的HTTP/1.1完全相同。当线性空白是可选的时，通常在标记和分隔符之间使用SWS构造。
LWS = [*WSP CRLF] 1*WSP ; linear whitespace
SWS = [LWS] ; sep whitespace
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
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不同于HTTP，后者使用ISO 8859-1字符集。
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
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.
在TEXT-UTF8-TRIM的定义中，CRLF仅允许作为标题字段延续的一部分。在解释TEXT-UTF8-TRIM值之前，预计折叠LWS将替换为单个SP。
Hexadecimal numeric characters are used in several protocol elements. Some elements (authentication) force hex alphas to be lower case.
在几个协议元素中使用十六进制数字字符。某些元素（身份验证）强制十六进制字母为小写。
LHEX = DIGIT / %x61-66 ;lowercase a-f
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或特殊字符分隔的单词组成。除非另有说明，令牌不区分大小写。这些特殊字符必须位于带引号的字符串中，才能在参数值中使用。单词construct用于callid，以允许使用大多数分隔符。
token = 1*(alphanum / "-" / "." / "!" / "%" / "*"
/ "_" / "+" / "`" / "'" / "~" )
separators = "(" / ")" / "<" / ">" / "@" /
"," / ";" / ":" / "\" / DQUOTE /
"/" / "[" / "]" / "?" / "=" /
"{" / "}" / SP / HTAB
word = 1*(alphanum / "-" / "." / "!" / "%" / "*" /
"_" / "+" / "`" / "'" / "~" /
"(" / ")" / "<" / ">" /
":" / "\" / DQUOTE /
"/" / "[" / "]" / "?" /
"{" / "}" )
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
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
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包括除左、右括号和反斜杠以外的所有字符。如果使用双引号将文本字符串引用，则将其解析为单个单词。在带引号的字符串中，需要转义引号（“）和反斜杠（\）。
quoted-string = SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE
qdtext = LWS / %x21 / %x23-5B / %x5D-7E
/ UTF8-NONASCII
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)
带引号的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
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
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]中找到。但是，请注意，SIPURI的用户部分中不允许的任何允许的字符都必须转义。
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 = "[" / "]" / "/" / ":" / "&" / "+" / "$"
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 = "[" / "]" / "/" / "?" / ":" / "+" / "$"
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
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
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
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
/ 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 ]
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)
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
Informational = "100" ; Trying
/ "180" ; Ringing
/ "181" ; Call Is Being Forwarded
/ "182" ; Queued
/ "183" ; Session Progress
Success = "200" ; OK
Success=“200”；好啊
Redirection = "300" ; Multiple Choices
/ "301" ; Moved Permanently
/ "302" ; Moved Temporarily
/ "305" ; Use Proxy
/ "380" ; Alternative Service
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
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
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
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 = "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-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 ) ) / "*" )
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 )
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[方法*（逗号方法）]
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
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
cnonce=“cnonce”相等cnonce值cnonce值=nonce值nonce count=“nc”相等nc值nc值=8LHEX dresponse=“response”相等请求摘要请求摘要=LDQUOT 32LHEX RDQUOT auth param=auth param name EQUAL（令牌/引用字符串）auth param name=token其他响应=auth scheme LWS auth param*（逗号auth param）身份验证方案=令牌
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
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-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
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 = ("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
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
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-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
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*数字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"
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 Info=“Error Info”HCOLON错误uri*（逗号错误uri）
error-uri = LAQUOT absoluteURI RAQUOT *( SEMI generic-param )
错误uri=LAQUOT绝对uri RAQUOT*（半泛型参数）
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
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*（逗号callid）
Max-Forwards = "Max-Forwards" HCOLON 1*DIGIT
Max Forwards=“Max Forwards”HCOLON 1*位
MIME-Version = "MIME-Version" HCOLON 1*DIGIT "." 1*DIGIT
MIME-Version = "MIME-Version" HCOLON 1*DIGIT "." 1*DIGIT
Min-Expires = "Min-Expires" HCOLON delta-seconds
Min Expires=“Min Expires”HCOLON delta seconds
Organization = "Organization" HCOLON [TEXT-UTF8-TRIM]
Organization=“Organization”HCOLON[TEXT-UTF8-TRIM]
Priority = "Priority" HCOLON priority-value
priority-value = "emergency" / "urgent" / "normal"
/ "non-urgent" / other-priority
other-priority = token
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-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
代理授权=“代理授权”HCOLON凭据
Proxy-Require = "Proxy-Require" HCOLON option-tag *(COMMA option-tag) option-tag = token
Proxy Require=“Proxy Require”HCOLON选项标记*（逗号选项标记）选项标记=令牌
Record-Route = "Record-Route" HCOLON rec-route *(COMMA rec-route)
rec-route = name-addr *( SEMI rr-param )
rr-param = generic-param
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)
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[注释]*（半重试参数）
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 )
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
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]
Subject = ( "Subject" / "s" ) HCOLON [TEXT-UTF8-TRIM]
Supported = ( "Supported" / "k" ) HCOLON
[option-tag *(COMMA option-tag)]
Supported = ( "Supported" / "k" ) HCOLON
[option-tag *(COMMA option-tag)]
Timestamp = "Timestamp" HCOLON 1*(DIGIT)
[ "." *(DIGIT) ] [ LWS delay ]
delay = *(DIGIT) [ "." *(DIGIT) ]
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
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)
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
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
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
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信令本身的安全性与与SIP（如RTP）协同使用的协议的安全性无关，也与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注册机制允许用户代理向注册器标识自己是用户（由记录地址指定）所在的设备。注册员评估注册信息的From头字段中声明的身份，以确定此请求是否可以修改与to头字段中记录地址相关联的联系人地址。虽然这两个字段通常相同，但有许多有效的部署，其中第三方可以代表用户注册联系人。
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请求与传统电话呼叫交互的网关）都可能希望通过对接收到的请求进行身份验证来控制对其资源的访问。即使是最终用户UAs，例如SIP电话，也有兴趣确定请求发起人的身份。
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.
请求的目的地域通常在请求URI中指定。UAs通常直接联系该域中的服务器以传递请求。然而，攻击者总是有可能模拟远程服务器，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.
例如，考虑一个域中的重定向服务器CHIGAGOO在另一个域BIOXI.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.
这一系列威胁的成员众多，其中许多是至关重要的。作为注册劫持威胁的反击，考虑发送到BIOXICOM的注册被CHICAGOO截获的情况，它用伪造的301（移动永久）响应回复截获的注册。这一回应似乎来自biloxi.com，但指定chicago.com为合适的注册商。随后，来自发起UA的所有未来注册请求将转到chicago.com。
Prevention of this threat requires a means by which UAs can authenticate the servers to whom they send requests.
防止这种威胁需要一种手段，UAs可以通过这种手段对向其发送请求的服务器进行身份验证。
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 UAs通过受信任的代理服务器路由请求。无论该信任是如何建立的（代理的身份验证将在本节其他部分讨论），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中端到端承载的最可能的内容形式。这些可能包括应呈现给用户的MIME主体、SDP或封装的电话信号等。例如，攻击者可能试图修改SDP主体，以便将RTP媒体流指向窃听设备，以便窃听后续语音通信。
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。UAs可能会保护这些头字段以及主体（例如，恶意中介更改主题头字段可能会使重要请求看起来像垃圾邮件）。但是，由于在路由请求时，代理服务器会合法地检查或更改许多头字段，因此并非所有头字段都应该是端到端安全的。
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.
考虑一个第三方攻击者在两方共享的对话框中捕获一些初始消息的情况，以便学习会话的参数（标签、标签等），然后将再见请求插入会话中。攻击者可以选择伪造请求，使其看起来来自任一参与者。一旦目标接收到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).
类似的中间会话威胁包括传输伪造的重新邀请，从而改变会话（可能会降低会话安全性或将媒体流重定向为窃听攻击的一部分）。
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来自与之建立相应对话的同一方（而不是确定发送者的绝对身份）。此外，如果攻击者由于机密性而无法了解会话的参数，则不可能伪造会话。但是，一些中介机构（如代理服务器）需要在会话建立时检查这些参数。
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.
拒绝服务攻击的重点是使特定网络元素不可用，通常是通过在其接口上引导过多的网络流量。分布式拒绝服务攻击允许一个网络用户导致多个网络主机向目标主机发送大量网络流量。
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.
在许多体系结构中，SIP代理服务器面向公共Internet，以便接受来自全球IP端点的请求。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 UAs或代理生成针对目标的拒绝服务流量。
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.
当攻击者确信由请求发起的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.
如果注册者没有对注册请求进行正确的身份验证和授权，就会出现许多拒绝服务攻击。攻击者可以注销管理域中的部分或所有用户，从而阻止这些用户被邀请参加新会话。攻击者还可以注册为给定记录地址指定同一主机的大量联系人，以便在拒绝服务攻击中将注册器和任何相关代理服务器用作放大器。攻击者还可能试图通过注册大量绑定来耗尽注册器的可用内存和磁盘资源。
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
消息的完全加密提供了保护信令机密性的最佳方法—它还可以保证消息不会被任何恶意中介修改。然而，SIP请求和响应不能完全进行端到端的简单加密，因为在大多数网络体系结构中，消息字段（如请求URI、路由和Via）需要对代理可见，以便正确路由SIP请求。请注意，代理服务器还需要修改消息的某些功能（例如通过头字段值添加消息），以使SIP正常工作。因此，代理服务器必须在一定程度上受到SIP UAs的信任。为此，建议使用SIP的低层安全机制
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请求或响应进行逐跳加密，并允许端点验证向其发送请求的代理服务器的身份。
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或代理服务器断言其用户的身份时，该身份应以某种方式可验证。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].
在传输层和网络层提供安全性的两种常用替代方案分别是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（Internet协议）的安全替代品。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主机添加安全性的部署。与第一跳代理服务器具有预共享密钥关系的UAs也是使用IPSec的良好候选。任何针对SIP的IPSec部署都需要一个IPSec配置文件，描述保护SIP所需的协议工具。本文件中未提供此类资料。
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”（表示TCP上的tls）可以在Via标头字段值或SIP-URI中指定为所需的传输协议。TLS最适合于在没有预先存在的信任关联的主机之间需要逐跳安全性的体系结构。例如，Alice信任她的本地代理服务器，在证书交换后，该服务器决定信任Bob信任的本地代理服务器，因此Bob和Alice可以安全地通信。
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.
在SIP应用程序中使用TLS时，实施者必须至少支持TLS_RSA_和_AES_128_CBC_SHA密码套件[6]。为了向后兼容，代理服务器、重定向服务器和注册器应支持TLS_RSA_和_3DES_EDE_CBC_SHA。实现者还可以支持任何其他密码套件。
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所述），尽管方案字符串是“SIPS”而不是“SIP”。然而，SIP的语义与SIPURI非常不同。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标头字段中，在注册请求的To标头字段中）。当用作请求的请求URI时，SIPS方案表示在请求到达负责请求URI的域部分的SIP实体之前，转发请求的每个跃点都必须使用TLS进行保护；一旦它到达所讨论的域，它将根据本地安全和路由策略进行处理，很可能在到达UAS的任何最后一跳中使用TLS。当请求的发起者使用SIPS时（如果他们使用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
除了请求URI之外，SIPS方案还适用于SIP中使用SIP URI的许多其他方式，包括记录地址、联系人地址（联系人头的内容，包括注册方法的内容）和路由头。在每个实例中，SIPS URI方案都允许这些现有字段
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].
指定安全的资源。SIPS URI在这些上下文中被解除引用的方式有其自身的安全属性，详见[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.
SIP的使用尤其需要采用相互TLS认证，密码套件TLS_RSA_与_AES_128_CBC_SHA也应如此。身份验证过程中收到的证书应使用客户端持有的根证书进行验证；验证证书失败将导致请求失败。
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；传输=tcp“和”sips：alice@atlanta.com；transport=sctp“都是有效的（尽管请注意，UDP不是SIP的有效传输）。“transport=tls”的使用因此被弃用，部分原因是它特定于请求的单个跃点。这是自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.
第22节详细介绍了SIP中摘要认证的用法。
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消息进行端到端加密是不合适的，因为网络中介（如代理服务器）需要查看某些头字段以正确路由消息，并且如果这些中介被排除在安全关联之外，然后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 UAs在SIP中加密MIME主体，从而在不影响消息头的情况下端到端保护这些主体。S/MIME可以为消息体提供端到端的机密性和完整性，以及相互身份验证。还可以使用S/MIME通过SIP消息隧道为SIP头字段提供一种形式的完整性和机密性。
The usage of S/MIME in SIP is detailed in Section 23.
第23节详细介绍了S/MIME在SIP中的使用。
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，并且必须支持双向和单向身份验证。强烈建议UAs能够启动TLS；UAs还可以充当TLS服务器。代理服务器、重定向服务器和注册器应该拥有一个站点证书，其主题对应于它们的标准主机名。UAs可能有自己的证书，用于与TLS相互认证，但本文件中没有规定使用这些证书。支持TLS的所有SIP元素必须具有验证TLS协商期间收到的证书的机制；这需要拥有由证书颁发机构颁发的一个或多个根证书（最好是与为web浏览器颁发根证书的机构相当的站点证书的知名分销商）。
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.
代理服务器、重定向服务器、注册器和UAs也可以实现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应启动TLS连接，并通过该连接发送SIP消息。在某些体系结构中，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.
代理服务器、重定向服务器、注册器和UAs必须实现摘要授权，包括22中要求的所有方面。代理服务器、重定向服务器和注册器应至少配置一个摘要领域，并且给定服务器支持的至少一个“领域”字符串应对应于服务器的主机名或域名。
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.
如第23节所述，UAs可支持MIME主体的签名和加密，以及使用S/MIME传输凭证。如果UA持有一个或多个证书颁发机构的根证书，以便验证TLS或IPSec的证书，则它应该能够根据需要重用这些证书来验证S/MIME证书。UA可以持有专门用于验证S/MIME证书的根证书。
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.
注意，随着S/MIME实现的出现和问题空间得到更好的理解，预计未来的安全扩展可能会升级与S/MIME相关的规范强度。
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和电子邮件安全模型。在高层，UAs使用摘要用户名和密码向服务器（代理服务器、重定向服务器和注册器）进行身份验证；服务器通过TLS提供的站点证书向一跳之外的UAs或另一跳之外的服务器（反之亦然）进行身份验证。
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.
在点对点级别上，UAs通常信任网络来相互验证；但是，当网络不可信或网络本身不可信时，也可以使用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.
下面是一个示例，其中各种UAs和服务器使用这些安全机制来防止第26.1节中描述的各种威胁。虽然实施者和网络管理员可以遵循本节剩余部分中给出的规范性指南，但这些指南仅作为示例实施提供。
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提供一份证书，该证书所标识的站点必须与UA打算注册的域相对应；例如，如果UA打算注册记录的地址'alice@atlanta.com，则站点证书必须标识atlanta.com域（如sip.atlanta.com）中的主机。当收到TLS证书消息时，UA应验证证书并检查证书标识的站点。如果证书无效、被吊销或未识别适当的一方，UA不得发送注册信息，否则继续注册。
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.
UA然后创建一个注册请求，该注册请求应发送到与从注册器接收的站点证书相对应的请求URI。当UA通过现有TLS连接发送注册请求时，注册官应使用401（需要代理身份验证）响应质疑该请求。响应的Proxy Authenticate标头字段中的“realm”参数应与站点证书先前给定的域相对应。当UAC收到质询时，它应该提示用户提供凭据，或者从与质询中的“realm”参数对应的密钥环中获取适当的凭据。此凭证的用户名应与注册请求的To标头字段中URI的“userinfo”部分相对应。将摘要凭证插入适当的代理授权标头字段后，应将注册表重新提交给注册官。
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.
由于注册器要求用户代理进行自身身份验证，因此攻击者很难伪造用户记录地址的注册请求。还请注意，由于寄存器是通过机密TLS连接发送的，攻击者将无法拦截寄存器以记录任何可能的重播攻击的凭据。
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连接打开，前提是注册官还充当代理服务器，向该管理域中的用户发送请求。现有的TLS连接将被重新使用，以向刚刚完成注册的UA发送传入请求。
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.
现在让我们假设Alice的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
处理管理域的入站请求的代理服务器也可以充当本地出站代理；为了简单起见，我们假设atlanta.com就是这种情况（否则用户代理将在此时启动到单独服务器的新TLS连接）。假设客户机已完成注册
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.
在上一节描述的过程中，当它向另一个用户发送INVITE请求时，应该重用到本地代理服务器的TLS连接。UA应该重用INVITE中缓存的凭据，以避免不必要地提示用户。
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中提供的凭据后，它应该检查请求URI以确定消息应该如何路由（请参见[4]）。如果请求URI的“域名”部分对应于本地域（atlanta.com），而不是biloxi.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.
“有”alice@atlanta.com“一直试图联系，比如说，”alex@atlanta.com“，本地代理将代理Alex注册时与注册官建立的TLS连接请求。由于Alex将通过其经过身份验证的通道接收此请求，因此他将确信Alice的请求已由本地管理域的代理服务器授权。
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.
但是，在本例中，请求URI指定了一个远程域。因此，atlanta.com上的本地出站代理服务器应与biloxi.com上的远程代理服务器建立TLS连接。由于此TLS连接中的两个参与者都是拥有站点证书的服务器，因此应该进行相互TLS身份验证。连接的每一方都应该验证和检查另一方的证书，注意证书中出现的域名，以便与SIP消息的头字段进行比较。例如，atlanta.com代理服务器在此阶段应验证从远程端接收的证书是否与biloxi.com域对应。一旦完成，TLS协商完成，两个代理之间形成安全通道，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.
biloxi.com上的代理服务器应依次检查atlanta.com上代理服务器的证书，并将证书声明的域与INVITE请求中From标头字段的“domainname”部分进行比较。biloxi代理可能有一个严格的安全策略，要求它拒绝与代理的管理域不匹配的请求。
Such security policies could be instituted to prevent the SIP equivalent of SMTP 'open relays' that are frequently exploited to generate spam.
可以制定此类安全策略，以防止SIP等同于SMTP“开放中继”，经常被利用来生成垃圾邮件。
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的认证策略，它才有可能确定Alice是如何证明她的身份的。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.
biloxi代理批准INVITE后，代理服务器应识别与此请求所针对的用户相关联的现有TLS通道（如果有的话）（在本例中）bob@biloxi.com"). 应通过此通道将邀请代理给Bob。由于该请求是通过TLS连接接收的，该TLS连接之前已作为biloxi代理进行了身份验证，Bob知道From标头字段未被篡改，并且atlanta.com已验证Alice，但不一定确定是否信任Alice的身份。
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.
在转发请求之前，两个代理服务器都应该向请求添加记录路由头字段，以便此对话框中的所有未来请求都将通过代理服务器。因此，代理服务器可以在此对话框的生命周期内继续提供安全服务。如果代理服务器不将自己添加到记录路由，则将来的消息将在Alice和Bob之间直接端到端传递，而不提供任何安全服务（除非双方就一些独立的端到端安全性（如S/MIME）达成一致）。在这方面，SIP梯形模型可以提供良好的结构，其中站点代理之间的协议约定可以在Alice和Bob之间提供合理的安全通道。
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之间的信令流中，因为攻击者无法确定会话的参数，也因为完整性机制可传递地保护Alice和Bob之间的通信量。
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
或者，考虑一个声明身份的UA“carol@chicago.com“没有本地出站代理的。当Carol希望向“发送邀请时”bob@biloxi.com“，她的UA应该直接启动与biloxi代理的TLS连接（使用[4]中描述的机制来确定如何最好地到达给定的请求URI）。当UA收到来自biloxi代理的证书时，在通过TLS连接传递邀请之前，应该正常验证证书。然而，卡罗尔没有办法证明
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.
她在biloxi代理上的身份，但她在邀请中的“消息/sip”正文上有CMS分离签名。在这种情况下，Carol不太可能拥有biloxi.com领域的任何证书，因为她与biloxi.com没有正式关联。biloxi代理也可能有一个严格的策略，阻止它甚至费心质疑在from header字段的“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制定了一项策略，即所有未经身份验证的请求都应重定向到针对“”注册的相应联系人地址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.
Carol随后应与指定地址建立TCP连接，并发送一个新的INVITE，其请求URI包含收到的联系人地址（在请求准备就绪时重新计算正文中的签名）。Bob在一个不安全的接口上接收此邀请，但他的UA检查并在本例中识别请求的From标头字段，然后将本地缓存的证书与邀请正文签名中显示的证书进行匹配。他以同样的方式回答，向卡罗尔证实了自己的身份，一个安全的对话开始了。
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转发请求）将请求转发给UAs。
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代理服务器运行的主机可从公共Internet路由时，应使用防御操作策略（阻止源路由流量，最好过滤ping流量）将其部署在管理域中。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和代理服务器应仅使用一个401（未经授权）或407（需要代理身份验证）来挑战有问题的请求，放弃正常的响应重传算法，从而对未经身份验证的请求采取无状态行为。
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（未经授权）或407（需要代理身份验证）状态响应加剧了攻击者使用伪造的报头字段值（如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摘要的主要限制之一是摘要中的完整性机制在SIP中不能很好地工作。具体来说，它们提供对请求URI和消息方法的保护，但不提供对UAs最可能希望保护的任何头字段的保护。
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计数机制进行重播保护。
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
HTTP摘要的另一个限制是领域的范围。当用户想要对其具有预先存在的关联（如服务）的资源进行身份验证时，摘要很有价值
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.
用户是客户的提供者（这是一个非常常见的场景，因此摘要提供了一个非常有用的功能）。相比之下，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机制最大的突出缺陷是缺乏面向最终用户的通用公钥基础设施。如果使用自签名证书（或无法由对话中的一个参与者验证的证书），则第23.2节中描述的基于SIP的密钥交换机制容易受到中间人攻击，攻击者可以利用该攻击检查和修改S/MIME主体。攻击者需要在对话中拦截双方之间的首次密钥交换，从请求和响应中删除现有的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).
需要注意的是，攻击者只能在双方首次交换密钥时利用此漏洞-在随后的情况下，UAs会注意到密钥的更改。随着时间的推移（可能是几天、几周或几年过去），攻击者也很难在双方未来的所有对话中保持沉默。
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并不完美，但它确实提高了连接的安全性。密钥指纹的使用可以为SIP提供一些帮助，就像对SSH一样。例如，如果双方使用SIP建立语音通信会话，则各自可以读取从另一方收到的密钥的指纹，并将其与原始密钥进行比较。对于中间的人来说，模仿参与者的声音肯定比他们的信号更难（这种做法是在基于Clipper芯片的安全电话中使用的）。
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
S/MIME机制允许UAs在其密钥环上拥有记录的目标地址证书的情况下发送加密请求，而无需前导。然而，为记录地址注册的任何特定设备可能不会持有该设备的当前用户先前使用过的证书，因此它将无法处理记录
encrypted request properly, which could lead to some avoidable error signaling. This is especially likely when an encrypted request is forked.
正确加密请求，这可能会导致一些可避免的错误信号。这在加密请求被分叉时尤其可能。
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.
当与特定用户（记录地址）而不是设备（UA）关联时，与S/MIME关联的密钥最有用。当用户在设备之间移动时，可能很难在UAs之间安全地传输私钥；设备如何获取这些密钥超出了本文档的范围。
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机制的另一个更平淡无奇的困难是，它可能导致非常大的消息，特别是当使用第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.
对于本地出站代理服务器和/或注册器来说，与多个UAs同时保持多个长期TLS连接也可能很困难。这引入了一些有效的可伸缩性问题，特别是对于密集型密码套件。维护长寿命TLS连接的冗余，特别是当UA单独负责其建立时，也可能很麻烦。
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作为联系地址）。这是SIP的首选用途。然而，许多有效的体系结构都使用TLS来保护部分请求路径，但例如，最终跳到UAS时依赖于其他一些机制。因此，SIPS无法保证TLS的使用将真正实现端到端。请注意，由于许多UAs将不接受传入的TLS连接，因此，即使那些支持TLS的UAs也可能需要如上文TLS限制部分所述维护持久的TLS连接，以便作为UAs通过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将用于到目标域的所有请求段有些复杂。一路上经过加密验证的代理服务器如果不符合或受到损害，可能会选择忽略与SIP相关的转发规则（以及第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。因此，其请求URI使用SIPS URI方案的请求的接收者不能仅基于请求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.
为了解决这些问题，建议其请求URI包含SIP或SIPS URI的请求的接收者检查To标头字段值，以查看其是否包含SIPS URI（但请注意，如果此URI具有相同的方案，但不等同于To标头字段中的URI，则不构成违反安全性的行为）。尽管客户端可能会选择以不同方式填充请求的请求URI和to header字段，但当使用SIPS时，此差异可能会被解释为可能的安全冲突，因此请求可能会被其接收方拒绝。收件人还可以检查Via头链，以便在到达本地管理域之前，再次检查TLS是否用于整个请求路径。源UAC也可以使用S/MIME来帮助确保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有理由相信请求URI的方案在传输过程中被不当修改，则UA应通知其用户潜在的安全漏洞。
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.
最终用户无疑会识别SIP和SIPURI之间的差异，他们可能会根据刺激手动编辑它们。这可能有利于或降低安全性。例如，如果攻击者破坏DNS缓存，插入一个虚假记录集，有效地删除代理服务器的所有SIPS记录，则任何通过此代理服务器的SIPS请求都可能失败。但是，当用户看到对SIPS AOR的重复调用失败时，他们可以在某些设备上手动将方案从SIPS转换为SIP，然后重试。当然，有一些防范措施（如果目的地UA真的是偏执狂，它可以拒绝所有非SIPS请求），但这是一个值得注意的限制。从好的方面来看，用户可能还认为“SIP”是有效的，即使它们只显示了SIPURI。
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.
请注意，也有一些不太直接的方式可以泄露私人信息。如果一个用户或服务选择在一个可以从其姓名和组织隶属关系（描述了大多数记录地址）猜到的地址进行访问，那么通过拥有未列出的“电话号码”来确保隐私的传统方法就会受到损害。用户位置服务可以通过向呼叫者泄露会话邀请的接收者的具体下落来侵犯其隐私；因此，实现应该能够在每个用户的基础上限制向特定类别的呼叫者提供什么样的位置和可用性信息。这是一整类问题，预计将在正在进行的SIP工作中进一步研究。
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
在某些情况下，用户可能希望在传递身份的标题字段中隐藏个人信息。这不仅适用于代表请求发起人的From和相关标头，也适用于to-可能不适合向最终目的地传递一个快速拨号昵称或一组目标的未扩展标识符，当请求路由时，其中任何一个都将从请求URI中删除，但在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.
标题字段，如果两者最初相同。因此，出于隐私原因，可能需要创建与请求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: 选项标记、警告代码（警告代码）、方法和响应代码，添加到已存在的标题字段的子注册表中。
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.
选项标记用于头字段，如Require、Supported、Proxy Require和Unsupported，以支持扩展的SIP兼容机制（第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注意事项部分必须包括以下信息，这些信息与出版物的RFC编号一起出现在IANA注册表中。
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 选项标记的名称。名称可以是任意长度，但长度不得超过二十个字符。名称必须仅由alphanum（第25节）字符组成。
o Descriptive text that describes the extension.
o 描述扩展名的描述性文本。
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 并使用第20.43节中列出的警告代码启动其填充。其他警告代码由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”表示特定于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参数相关的警告，和390至399是不属于上述类别之一的杂项警告。
This obsoletes the IANA instructions about the header sub-registry under http://www.iana.org/assignments/sip-parameters.
这将废弃IANA关于下的头子注册表的说明http://www.iana.org/assignments/sip-parameters.
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.
一些常用和广泛使用的标题字段可以指定为一个字母的紧凑格式（第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 并按如下方式启动其人口。初始方法表为：
INVITE [RFC3261]
ACK [RFC3261]
BYE [RFC3261]
CANCEL [RFC3261]
REGISTER [RFC3261]
OPTIONS [RFC3261]
INFO [RFC2976]
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:
本文档注册“message/sip”MIME媒体类型，以便允许sip消息作为sip中的主体进行隧道传输，主要用于端到端安全目的。此媒体类型由以下信息定义：
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消息由8位报头（可选）和二进制MIME数据对象组成。因此，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.
安全注意事项：参见下面的动机，并在23.4中给出了与S/MIME配合使用的安全机制的示例。
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.
本文档还注册了四个新的内容处置标题“处置类型”：警报、图标、会话和渲染。作者要求将这些值记录在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
28对RFC 2543的更改
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.
本RFC修订了RFC 2543。它主要与RFC 2543向后兼容。此处描述的更改修复了RFC 2543中发现的许多错误，并提供了RFC 2543中未详细说明的场景信息。该协议在这里以一个更清晰的分层模型呈现。
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希望在应答之前终止呼叫时，它会发送CANCEL。如果原始邀请仍然返回2xx，UAC将发送BYE。BYE只能在现有的呼叫分支（现在在RFC中称为对话框）上发送，而它可以在RFC 2543中随时发送。
o The SIP BNF was converted to be RFC 2234 compliant.
o SIP BNF已转换为符合RFC 2234。
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 在RFC2543中，取消和邀请事务混合在一起。他们现在分开了。当用户发送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 类似地，取消和BYE交易混合在一起；RFC 2543允许UAS在收到BYE时不发送对INVITE的响应。这在这里是不允许的。原始邀请需要响应。
o In RFC 2543, UAs needed to support only UDP. In this RFC, UAs need to support both UDP and TCP.
o 在RFC2543中，UAs只需要支持UDP。在这个RFC中，UAs需要同时支持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 在RFC2543中，分叉代理仅在出现多个质询的情况下传递来自下游元素的一个质询。在这个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 在摘要凭证中，需要引用URI；这在RFC 2617和RFC 2069中是不清楚的，两者都不一致。
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进行有效的隧道传输。对于基线SIP实现，INVITE/200或200/ACK中允许SDP；RFC2543提到了在单个事务中在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 循环检测是可选的，被强制使用Max-Forwards取代。RFC2543中的循环检测过程有一个严重的错误，当“螺旋”不是错误时，它会报告为错误条件。此处更全面、更正确地指定了可选循环检测过程。
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 标签的使用现在是强制性的（在RFC2543中是可选的），因为它们现在是对话框标识的基本构建块。
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 添加了Supported header字段，允许客户端指示服务器支持哪些扩展，服务器可以将这些扩展应用于响应，并在响应中使用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 RFC 2543中对路线和记录路线施工的处理规定太少，也不是正确的方法。在本规范中对其进行了实质性的修改（并且大大简化了），这可以说是最大的更改。对于不使用“预加载路由”的部署，仍然提供了向后兼容性，其中初始请求具有一组在记录路由之外以某种方式获得的路由头字段值。在这些情况下，新机制无法互操作。
o In RFC 2543, lines in a message could be terminated with CR, LF, or CRLF. This specification only allows CRLF.
o 在RFC2543中，消息中的行可以用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 RFC 2543中未明确定义取消和确认中的路由用法。它现在已经很明确了；如果一个请求有一个路由头字段，则其对该请求的非2xx响应的取消或确认需要携带相同的路由头字段值。2xx响应的ACK使用从2xx响应的记录路由中学习的路由值。
o RFC 2543 allowed multiple requests in a single UDP packet. This usage has been removed.
o RFC2543允许在单个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 header字段值的分支参数现在是所有元素必须使用的参数。它现在扮演唯一事务标识符的角色。这避免了RFC 2543中复杂且充满bug的事务标识规则。参数值中使用了一个神奇的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 在RFC2543中，TCP连接的关闭相当于取消。代理之间的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是否可以在另一个事务正在进行时向对等方发起新事务。现在在这里指定。它允许非邀请请求，不允许邀请请求。
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不向后兼容。接收请求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 在RFC 2543中，不需要代理将临时响应从101转发到199上游。这已更改为必须。这很重要，因为许多后续特性取决于101到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 关于RFC2543中的503响应代码，很少有人提及。此后，它在指示代理中的故障或过载条件方面得到了实质性的应用。这需要一些特殊的处理。具体地说，收到503应该触发尝试联系DNS SRV查找结果中的下一个元素。此外，503响应仅在某些条件下由代理向上游转发。
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在收到初始邀请的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或代理在收到请求的临时响应之前，无法为事务发送取消。这在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 RFC2543对于多播有许多特殊情况。例如，某些响应被抑制，计时器被调整，等等。多播现在起着更有限的作用，协议操作不受多播（相对于单播）使用的影响。由此产生的限制已记录在案。
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没有解决请求合并的问题。当请求在代理上分叉，然后在元素上重新联接时，就会发生这种情况。合并处理仅在UA进行，定义了拒绝除第一个请求以外的所有请求的程序。
o Added the Alert-Info, Error-Info, and Call-Info header fields for optional content presentation to users.
o 添加了警报信息、错误信息和呼叫信息标题字段，用于向用户显示可选内容。
o Added the Content-Language, Content-Disposition and MIME-Version header fields.
o 添加了内容语言、内容配置和MIME版本头字段。
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 增加了“眩光处理”机制，以处理双方同时向对方发送重新邀请的情况。它使用新的491（请求挂起）错误代码。
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 header字段，以支持稍后返回未接来电或消息。
o Added TLS and SCTP as valid SIP transports.
o 添加TLS和SCTP作为有效的SIP传输。
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 在呼叫过程中的任何时候，都有各种各样的机制用于处理故障；现在这些基本上是统一的。发送“再见”以终止。
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。这是协议分层不足的产物。这里定义了一个更连贯的事务层，这就不再需要了。只有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 日期头字段用于寄存器响应中，以提供一种简单的方法来自动配置用户代理中的日期。
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响应代码，并且最小值为此目的过期。
29 Normative References
29规范性引用文件
[1] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[1] Handley，M.和V.Jacobson，“SDP：会话描述协议”，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.，“互联网信息格式”，RFC 2822，2001年4月。
[4] Rosenberg, J. and H. Schulzrinne, "SIP: Locating SIP Servers", RFC 3263, June 2002.
[4] Rosenberg，J.和H.Schulzrinne，“SIP：定位SIP服务器”，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，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[6] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002.
[6] Chown，P.，“用于传输层安全（TLS）的高级加密标准（AES）密码套件”，RFC 3268，2002年6月。
[7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[7] “UTF-8，ISO 10646的转换格式”，RFC 2279，1998年1月。
[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] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，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.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[12] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[12] Eastlake，D.，Crocker，S.和J.Schiller，“安全性的随机性建议”，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.，“国防部标准传输控制协议”，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] Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.和V.Paxson，“流控制传输协议”，RFC 29602000年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.，Lootonen，A.和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年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，“在互联网消息中传达呈现信息：内容处置标题字段”，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.和M.Zonoun，“ISUP和QSIG对象的MIME媒体类型”，RFC 32042001年12月。
[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字符集和语言政策”，BCP 18，RFC 2277，1998年1月。
[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.和N.Freed，“MIME的安全多部分：多部分/签名和多部分/加密”，RFC 1847，1995年10月。
[23] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[23] Housley，R.，“加密消息语法”，RFC 2630，1999年6月。
[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，“TLS协议1.0版”，RFC 2246，1999年1月。
[26] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[26] Kent，S.和R.Atkinson，“互联网协议的安全架构”，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通信杂志》，第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：实时应用的传输协议”，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，“实时流协议（RTSP）”，RFC2326，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协议版本1.0”，RFC 30152000年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.和J.Rosenberg，“SIP：会话启动协议”，RFC 25431999年3月。
[32] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL scheme", RFC 2368, July 1998.
[32] Hoffman，P.，Masinter，L.和J.Zawinski，“邮件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.，“SIP信息方法”，RFC 29762000年10月。
[35] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[35] Rivest，R.，“MD5消息摘要算法”，RFC1321，1992年4月。
[36] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, September 1998.
[36] Dawson，F.和T.Howes，“vCard MIME目录配置文件”，RFC24261998年9月。
[37] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical Specification", RFC 2849, June 2000.
[37] Good，G.，“LDAP数据交换格式（LDIF）-技术规范”，RFC 28492000年6月。
[38] Palme, J., "Common Internet Message Headers", RFC 2076, February 1997.
[38] Palme，J.，“通用互联网消息头”，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.，Lootonen，A.，Sink，E.和L.Stewart，“HTTP的扩展：摘要访问认证”，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呼叫流示例”，正在进行中。
[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，“案例研究：分组交换远程会议系统中的多媒体会议控制”，《互联网期刊：研究与经验》，第4卷，第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.Schulzrinne，“互联网多媒体服务的个人移动”，交互式分布式多媒体系统和服务（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
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
表4：计时器汇总表
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.
我们要感谢IETF MMUSIC和SIP工作组成员的意见和建议。奥菲尔·阿金、布赖恩·比杜洛克、吉姆·布勒、尼尔·迪森、戴夫·德瓦纳森、基思·德拉奇、比尔·芬纳、塞德里克·弗拉基格、雅隆·戈兰德、约翰·哈迪、伯尼·霍内森、乔·霍恩斯比、菲尔·霍费尔、克里斯蒂安·惠特马、希沙姆·哈塔比尔、让·杰维斯、加迪·卡米、彼得·克勒斯特德、安德斯·克里斯滕森、乔纳森·伦诺克斯提供了详细的评论，格钦·利德尔、埃里森·曼金、威廉·马歇尔、罗汉·马希、基思·摩尔、弗恩·帕克森、鲍勃·彭菲尔德、莫斯·J·桑波尔、奇普·夏普、伊戈尔·斯莱普钦、埃里克·特雷姆布雷和里克·沃克曼。
Brian Rosen provided the compiled BNF.
Brian Rosen提供了已编译的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.
作者地址按编辑、作者和RFC2543的原始作者的字母顺序列出。所有列出的作者都积极为本文件提供了大量文本。
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Ave East Hanover, NJ 07936 USA
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Ave East Hanover，NJ 07936美国
EMail: jdrosen@dynamicsoft.com
EMail: jdrosen@dynamicsoft.com
Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA
美国纽约州纽约市阿姆斯特丹大道1214号哥伦比亚大学计算机科学系
EMail: schulzrinne@cs.columbia.edu
EMail: schulzrinne@cs.columbia.edu
Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland
Gonzalo Camarillo Ericsson高级信号研究实验室FIN-02420 Jorvas芬兰
EMail: Gonzalo.Camarillo@ericsson.com
EMail: Gonzalo.Camarillo@ericsson.com
Alan Johnston WorldCom 100 South 4th Street St. Louis, MO 63102 USA
美国密苏里州圣路易斯南四街100号艾伦·约翰斯顿世界通讯公司，邮编63102
EMail: alan.johnston@wcom.com
EMail: alan.johnston@wcom.com
Jon Peterson NeuStar, Inc 1800 Sutter Street, Suite 570 Concord, CA 94520 USA
美国加利福尼亚州康科德市萨特街1800号570室Jon Peterson NeuStar，Inc.94520
EMail: jon.peterson@neustar.com
EMail: jon.peterson@neustar.com
Robert Sparks dynamicsoft, Inc. 5100 Tennyson Parkway Suite 1200 Plano, Texas 75024 USA
Robert Sparks dynamicsoft，Inc.美国德克萨斯州普莱诺市坦尼生大道1200号5100套房，邮编75024
EMail: rsparks@dynamicsoft.com
EMail: rsparks@dynamicsoft.com
Mark Handley International Computer Science Institute 1947 Center St, Suite 600 Berkeley, CA 94704 USA
美国加利福尼亚州伯克利中心大街1947号马克·汉德利国际计算机科学研究所，600室，邮编94704
EMail: mjh@icir.org
EMail: mjh@icir.org
Eve Schooler AT&T Labs-Research 75 Willow Road Menlo Park, CA 94025 USA
美国加利福尼亚州门罗公园柳树路75号Eve Schooler AT&T实验室研究室，邮编94025
EMail: schooler@research.att.com
EMail: schooler@research.att.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（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编辑功能的资金目前由互联网协会提供。