Network Working Group M. Handley
Request for Comments: 2543 ACIRI
Category: Standards Track H. Schulzrinne
Columbia U.
E. Schooler
Cal Tech
J. Rosenberg
Bell Labs
March 1999
Network Working Group M. Handley
Request for Comments: 2543 ACIRI
Category: Standards Track H. Schulzrinne
Columbia U.
E. Schooler
Cal Tech
J. Rosenberg
Bell Labs
March 1999
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 (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
IESG Note
IESG注释
The IESG intends to charter, in the near future, one or more working groups to produce standards for "name lookup", where such names would include electronic mail addresses and telephone numbers, and the result of such a lookup would be a list of attributes and characteristics of the user or terminal associated with the name. Groups which are in need of a "name lookup" protocol should follow the development of these new working groups rather than using SIP for this function. In addition it is anticipated that SIP will migrate towards using such protocols, and SIP implementors are advised to monitor these efforts.
IESG打算在不久的将来成立一个或多个工作组，以制定“名称查找”标准，其中此类名称将包括电子邮件地址和电话号码，此类查找的结果将是与该名称相关联的用户或终端的属性和特征列表。需要“名称查找”协议的组应遵循这些新工作组的开发，而不是使用SIP实现此功能。此外，预计SIP将向使用此类协议的方向迁移，建议SIP实施者监控这些工作。
Abstract
摘要
The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution. Members in a session can communicate via multicast or via a mesh of unicast relations, or a combination of these.
会话发起协议（SIP）是用于创建、修改和终止与一个或多个参与者的会话的应用层控制（信令）协议。这些会议包括因特网多媒体会议、因特网电话和多媒体分发。会话中的成员可以通过多播或单播关系的网格或这些关系的组合进行通信。
SIP invitations used to create sessions carry session descriptions which allow participants to agree on a set of compatible media types. SIP supports user mobility by proxying and redirecting requests to the user's current location. Users can register their current location. SIP is not tied to any particular conference control protocol. SIP is designed to be independent of the lower-layer transport protocol and can be extended with additional capabilities.
用于创建会话的SIP邀请包含会话描述，允许参与者就一组兼容的媒体类型达成一致。SIP通过代理和重定向请求到用户的当前位置来支持用户移动。用户可以注册其当前位置。SIP不与任何特定的会议控制协议绑定。SIP被设计为独立于较低层传输协议，并且可以通过附加功能进行扩展。
Table of Contents
目录
1 Introduction ........................................ 7
1.1 Overview of SIP Functionality ....................... 7
1.2 Terminology ......................................... 8
1.3 Definitions ......................................... 9
1.4 Overview of SIP Operation ........................... 12
1.4.1 SIP Addressing ...................................... 12
1.4.2 Locating a SIP Server ............................... 13
1.4.3 SIP Transaction ..................................... 14
1.4.4 SIP Invitation ...................................... 15
1.4.5 Locating a User ..................................... 17
1.4.6 Changing an Existing Session ........................ 18
1.4.7 Registration Services ............................... 18
1.5 Protocol Properties ................................. 18
1.5.1 Minimal State ....................................... 18
1.5.2 Lower-Layer-Protocol Neutral ........................ 18
1.5.3 Text-Based .......................................... 20
2 SIP Uniform Resource Locators ....................... 20
3 SIP Message Overview ................................ 24
4 Request ............................................. 26
4.1 Request-Line ........................................ 26
4.2 Methods ............................................. 27
4.2.1 INVITE .............................................. 28
4.2.2 ACK ................................................. 29
4.2.3 OPTIONS ............................................. 29
4.2.4 BYE ................................................. 30
4.2.5 CANCEL .............................................. 30
4.2.6 REGISTER ............................................ 31
4.3 Request-URI ......................................... 34
4.3.1 SIP Version ......................................... 35
4.4 Option Tags ......................................... 35
4.4.1 Registering New Option Tags with IANA ............... 35
5 Response ............................................ 36
5.1 Status-Line ......................................... 36
5.1.1 Status Codes and Reason Phrases ..................... 37
6 Header Field Definitions ............................ 39
6.1 General Header Fields ............................... 41
6.2 Entity Header Fields ................................ 42
6.3 Request Header Fields ............................... 43
1 Introduction ........................................ 7
1.1 Overview of SIP Functionality ....................... 7
1.2 Terminology ......................................... 8
1.3 Definitions ......................................... 9
1.4 Overview of SIP Operation ........................... 12
1.4.1 SIP Addressing ...................................... 12
1.4.2 Locating a SIP Server ............................... 13
1.4.3 SIP Transaction ..................................... 14
1.4.4 SIP Invitation ...................................... 15
1.4.5 Locating a User ..................................... 17
1.4.6 Changing an Existing Session ........................ 18
1.4.7 Registration Services ............................... 18
1.5 Protocol Properties ................................. 18
1.5.1 Minimal State ....................................... 18
1.5.2 Lower-Layer-Protocol Neutral ........................ 18
1.5.3 Text-Based .......................................... 20
2 SIP Uniform Resource Locators ....................... 20
3 SIP Message Overview ................................ 24
4 Request ............................................. 26
4.1 Request-Line ........................................ 26
4.2 Methods ............................................. 27
4.2.1 INVITE .............................................. 28
4.2.2 ACK ................................................. 29
4.2.3 OPTIONS ............................................. 29
4.2.4 BYE ................................................. 30
4.2.5 CANCEL .............................................. 30
4.2.6 REGISTER ............................................ 31
4.3 Request-URI ......................................... 34
4.3.1 SIP Version ......................................... 35
4.4 Option Tags ......................................... 35
4.4.1 Registering New Option Tags with IANA ............... 35
5 Response ............................................ 36
5.1 Status-Line ......................................... 36
5.1.1 Status Codes and Reason Phrases ..................... 37
6 Header Field Definitions ............................ 39
6.1 General Header Fields ............................... 41
6.2 Entity Header Fields ................................ 42
6.3 Request Header Fields ............................... 43
6.4 Response Header Fields .............................. 43
6.5 End-to-end and Hop-by-hop Headers ................... 43
6.6 Header Field Format ................................. 43
6.7 Accept .............................................. 44
6.8 Accept-Encoding ..................................... 44
6.9 Accept-Language ..................................... 45
6.10 Allow ............................................... 45
6.11 Authorization ....................................... 45
6.12 Call-ID ............................................. 46
6.13 Contact ............................................. 47
6.14 Content-Encoding .................................... 50
6.15 Content-Length ...................................... 51
6.16 Content-Type ........................................ 51
6.17 CSeq ................................................ 52
6.18 Date ................................................ 53
6.19 Encryption .......................................... 54
6.20 Expires ............................................. 55
6.21 From ................................................ 56
6.22 Hide ................................................ 57
6.23 Max-Forwards ........................................ 59
6.24 Organization ........................................ 59
6.25 Priority ............................................ 60
6.26 Proxy-Authenticate .................................. 60
6.27 Proxy-Authorization ................................. 61
6.28 Proxy-Require ....................................... 61
6.29 Record-Route ........................................ 62
6.30 Require ............................................. 63
6.31 Response-Key ........................................ 63
6.32 Retry-After ......................................... 64
6.33 Route ............................................... 65
6.34 Server .............................................. 65
6.35 Subject ............................................. 65
6.36 Timestamp ........................................... 66
6.37 To .................................................. 66
6.38 Unsupported ......................................... 68
6.39 User-Agent .......................................... 68
6.40 Via ................................................. 68
6.40.1 Requests ............................................ 68
6.40.2 Receiver-tagged Via Header Fields ................... 69
6.40.3 Responses ........................................... 70
6.40.4 User Agent and Redirect Servers ..................... 70
6.40.5 Syntax .............................................. 71
6.41 Warning ............................................. 72
6.42 WWW-Authenticate .................................... 74
7 Status Code Definitions ............................. 75
7.1 Informational 1xx ................................... 75
7.1.1 100 Trying .......................................... 75
7.1.2 180 Ringing ......................................... 75
6.4 Response Header Fields .............................. 43
6.5 End-to-end and Hop-by-hop Headers ................... 43
6.6 Header Field Format ................................. 43
6.7 Accept .............................................. 44
6.8 Accept-Encoding ..................................... 44
6.9 Accept-Language ..................................... 45
6.10 Allow ............................................... 45
6.11 Authorization ....................................... 45
6.12 Call-ID ............................................. 46
6.13 Contact ............................................. 47
6.14 Content-Encoding .................................... 50
6.15 Content-Length ...................................... 51
6.16 Content-Type ........................................ 51
6.17 CSeq ................................................ 52
6.18 Date ................................................ 53
6.19 Encryption .......................................... 54
6.20 Expires ............................................. 55
6.21 From ................................................ 56
6.22 Hide ................................................ 57
6.23 Max-Forwards ........................................ 59
6.24 Organization ........................................ 59
6.25 Priority ............................................ 60
6.26 Proxy-Authenticate .................................. 60
6.27 Proxy-Authorization ................................. 61
6.28 Proxy-Require ....................................... 61
6.29 Record-Route ........................................ 62
6.30 Require ............................................. 63
6.31 Response-Key ........................................ 63
6.32 Retry-After ......................................... 64
6.33 Route ............................................... 65
6.34 Server .............................................. 65
6.35 Subject ............................................. 65
6.36 Timestamp ........................................... 66
6.37 To .................................................. 66
6.38 Unsupported ......................................... 68
6.39 User-Agent .......................................... 68
6.40 Via ................................................. 68
6.40.1 Requests ............................................ 68
6.40.2 Receiver-tagged Via Header Fields ................... 69
6.40.3 Responses ........................................... 70
6.40.4 User Agent and Redirect Servers ..................... 70
6.40.5 Syntax .............................................. 71
6.41 Warning ............................................. 72
6.42 WWW-Authenticate .................................... 74
7 Status Code Definitions ............................. 75
7.1 Informational 1xx ................................... 75
7.1.1 100 Trying .......................................... 75
7.1.2 180 Ringing ......................................... 75
7.1.3 181 Call Is Being Forwarded ......................... 75
7.1.4 182 Queued .......................................... 76
7.2 Successful 2xx ...................................... 76
7.2.1 200 OK .............................................. 76
7.3 Redirection 3xx ..................................... 76
7.3.1 300 Multiple Choices ................................ 77
7.3.2 301 Moved Permanently ............................... 77
7.3.3 302 Moved Temporarily ............................... 77
7.3.4 305 Use Proxy ....................................... 77
7.3.5 380 Alternative Service ............................. 78
7.4 Request Failure 4xx ................................. 78
7.4.1 400 Bad Request ..................................... 78
7.4.2 401 Unauthorized .................................... 78
7.4.3 402 Payment Required ................................ 78
7.4.4 403 Forbidden ....................................... 78
7.4.5 404 Not Found ....................................... 78
7.4.6 405 Method Not Allowed .............................. 78
7.4.7 406 Not Acceptable .................................. 79
7.4.8 407 Proxy Authentication Required ................... 79
7.4.9 408 Request Timeout ................................. 79
7.4.10 409 Conflict ........................................ 79
7.4.11 410 Gone ............................................ 79
7.4.12 411 Length Required ................................. 79
7.4.13 413 Request Entity Too Large ........................ 80
7.4.14 414 Request-URI Too Long ............................ 80
7.4.15 415 Unsupported Media Type .......................... 80
7.4.16 420 Bad Extension ................................... 80
7.4.17 480 Temporarily Unavailable ......................... 80
7.4.18 481 Call Leg/Transaction Does Not Exist ............. 81
7.4.19 482 Loop Detected ................................... 81
7.4.20 483 Too Many Hops ................................... 81
7.4.21 484 Address Incomplete .............................. 81
7.4.22 485 Ambiguous ....................................... 81
7.4.23 486 Busy Here ....................................... 82
7.5 Server Failure 5xx .................................. 82
7.5.1 500 Server Internal Error ........................... 82
7.5.2 501 Not Implemented ................................. 82
7.5.3 502 Bad Gateway ..................................... 82
7.5.4 503 Service Unavailable ............................. 83
7.5.5 504 Gateway Time-out ................................ 83
7.5.6 505 Version Not Supported ........................... 83
7.6 Global Failures 6xx ................................. 83
7.6.1 600 Busy Everywhere ................................. 83
7.6.2 603 Decline ......................................... 84
7.6.3 604 Does Not Exist Anywhere ......................... 84
7.6.4 606 Not Acceptable .................................. 84
8 SIP Message Body .................................... 84
8.1 Body Inclusion ...................................... 84
7.1.3 181 Call Is Being Forwarded ......................... 75
7.1.4 182 Queued .......................................... 76
7.2 Successful 2xx ...................................... 76
7.2.1 200 OK .............................................. 76
7.3 Redirection 3xx ..................................... 76
7.3.1 300 Multiple Choices ................................ 77
7.3.2 301 Moved Permanently ............................... 77
7.3.3 302 Moved Temporarily ............................... 77
7.3.4 305 Use Proxy ....................................... 77
7.3.5 380 Alternative Service ............................. 78
7.4 Request Failure 4xx ................................. 78
7.4.1 400 Bad Request ..................................... 78
7.4.2 401 Unauthorized .................................... 78
7.4.3 402 Payment Required ................................ 78
7.4.4 403 Forbidden ....................................... 78
7.4.5 404 Not Found ....................................... 78
7.4.6 405 Method Not Allowed .............................. 78
7.4.7 406 Not Acceptable .................................. 79
7.4.8 407 Proxy Authentication Required ................... 79
7.4.9 408 Request Timeout ................................. 79
7.4.10 409 Conflict ........................................ 79
7.4.11 410 Gone ............................................ 79
7.4.12 411 Length Required ................................. 79
7.4.13 413 Request Entity Too Large ........................ 80
7.4.14 414 Request-URI Too Long ............................ 80
7.4.15 415 Unsupported Media Type .......................... 80
7.4.16 420 Bad Extension ................................... 80
7.4.17 480 Temporarily Unavailable ......................... 80
7.4.18 481 Call Leg/Transaction Does Not Exist ............. 81
7.4.19 482 Loop Detected ................................... 81
7.4.20 483 Too Many Hops ................................... 81
7.4.21 484 Address Incomplete .............................. 81
7.4.22 485 Ambiguous ....................................... 81
7.4.23 486 Busy Here ....................................... 82
7.5 Server Failure 5xx .................................. 82
7.5.1 500 Server Internal Error ........................... 82
7.5.2 501 Not Implemented ................................. 82
7.5.3 502 Bad Gateway ..................................... 82
7.5.4 503 Service Unavailable ............................. 83
7.5.5 504 Gateway Time-out ................................ 83
7.5.6 505 Version Not Supported ........................... 83
7.6 Global Failures 6xx ................................. 83
7.6.1 600 Busy Everywhere ................................. 83
7.6.2 603 Decline ......................................... 84
7.6.3 604 Does Not Exist Anywhere ......................... 84
7.6.4 606 Not Acceptable .................................. 84
8 SIP Message Body .................................... 84
8.1 Body Inclusion ...................................... 84
8.2 Message Body Type ................................... 85
8.3 Message Body Length ................................. 85
9 Compact Form ........................................ 85
10 Behavior of SIP Clients and Servers ................. 86
10.1 General Remarks ..................................... 86
10.1.1 Requests ............................................ 86
10.1.2 Responses ........................................... 87
10.2 Source Addresses, Destination Addresses and
Connections ......................................... 88
10.2.1 Unicast UDP ......................................... 88
10.2.2 Multicast UDP ....................................... 88
10.3 TCP ................................................. 89
10.4 Reliability for BYE, CANCEL, OPTIONS, REGISTER
Requests ............................................ 90
10.4.1 UDP ................................................. 90
10.4.2 TCP ................................................. 91
10.5 Reliability for INVITE Requests ..................... 91
10.5.1 UDP ................................................. 92
10.5.2 TCP ................................................. 95
10.6 Reliability for ACK Requests ........................ 95
10.7 ICMP Handling ....................................... 95
11 Behavior of SIP User Agents ......................... 95
11.1 Caller Issues Initial INVITE Request ................ 96
11.2 Callee Issues Response .............................. 96
11.3 Caller Receives Response to Initial Request ......... 96
11.4 Caller or Callee Generate Subsequent Requests ....... 97
11.5 Receiving Subsequent Requests ....................... 97
12 Behavior of SIP Proxy and Redirect Servers .......... 97
12.1 Redirect Server ..................................... 97
12.2 User Agent Server ................................... 98
12.3 Proxy Server ........................................ 98
12.3.1 Proxying Requests ................................... 98
12.3.2 Proxying Responses .................................. 99
12.3.3 Stateless Proxy: Proxying Responses ................. 99
12.3.4 Stateful Proxy: Receiving Requests .................. 99
12.3.5 Stateful Proxy: Receiving ACKs ...................... 99
12.3.6 Stateful Proxy: Receiving Responses ................. 100
12.3.7 Stateless, Non-Forking Proxy ........................ 100
12.4 Forking Proxy ....................................... 100
13 Security Considerations ............................. 104
13.1 Confidentiality and Privacy: Encryption ............. 104
13.1.1 End-to-End Encryption ............................... 104
13.1.2 Privacy of SIP Responses ............................ 107
13.1.3 Encryption by Proxies ............................... 108
13.1.4 Hop-by-Hop Encryption ............................... 108
13.1.5 Via field encryption ................................ 108
13.2 Message Integrity and Access Control:
Authentication ...................................... 109
8.2 Message Body Type ................................... 85
8.3 Message Body Length ................................. 85
9 Compact Form ........................................ 85
10 Behavior of SIP Clients and Servers ................. 86
10.1 General Remarks ..................................... 86
10.1.1 Requests ............................................ 86
10.1.2 Responses ........................................... 87
10.2 Source Addresses, Destination Addresses and
Connections ......................................... 88
10.2.1 Unicast UDP ......................................... 88
10.2.2 Multicast UDP ....................................... 88
10.3 TCP ................................................. 89
10.4 Reliability for BYE, CANCEL, OPTIONS, REGISTER
Requests ............................................ 90
10.4.1 UDP ................................................. 90
10.4.2 TCP ................................................. 91
10.5 Reliability for INVITE Requests ..................... 91
10.5.1 UDP ................................................. 92
10.5.2 TCP ................................................. 95
10.6 Reliability for ACK Requests ........................ 95
10.7 ICMP Handling ....................................... 95
11 Behavior of SIP User Agents ......................... 95
11.1 Caller Issues Initial INVITE Request ................ 96
11.2 Callee Issues Response .............................. 96
11.3 Caller Receives Response to Initial Request ......... 96
11.4 Caller or Callee Generate Subsequent Requests ....... 97
11.5 Receiving Subsequent Requests ....................... 97
12 Behavior of SIP Proxy and Redirect Servers .......... 97
12.1 Redirect Server ..................................... 97
12.2 User Agent Server ................................... 98
12.3 Proxy Server ........................................ 98
12.3.1 Proxying Requests ................................... 98
12.3.2 Proxying Responses .................................. 99
12.3.3 Stateless Proxy: Proxying Responses ................. 99
12.3.4 Stateful Proxy: Receiving Requests .................. 99
12.3.5 Stateful Proxy: Receiving ACKs ...................... 99
12.3.6 Stateful Proxy: Receiving Responses ................. 100
12.3.7 Stateless, Non-Forking Proxy ........................ 100
12.4 Forking Proxy ....................................... 100
13 Security Considerations ............................. 104
13.1 Confidentiality and Privacy: Encryption ............. 104
13.1.1 End-to-End Encryption ............................... 104
13.1.2 Privacy of SIP Responses ............................ 107
13.1.3 Encryption by Proxies ............................... 108
13.1.4 Hop-by-Hop Encryption ............................... 108
13.1.5 Via field encryption ................................ 108
13.2 Message Integrity and Access Control:
Authentication ...................................... 109
13.2.1 Trusting responses .................................. 112
13.3 Callee Privacy ...................................... 113
13.4 Known Security Problems ............................. 113
14 SIP Authentication using HTTP Basic and Digest
Schemes ............................................. 113
14.1 Framework ........................................... 113
14.2 Basic Authentication ................................ 114
14.3 Digest Authentication ............................... 114
14.4 Proxy-Authentication ................................ 115
15 SIP Security Using PGP .............................. 115
15.1 PGP Authentication Scheme ........................... 115
15.1.1 The WWW-Authenticate Response Header ................ 116
15.1.2 The Authorization Request Header .................... 117
15.2 PGP Encryption Scheme ............................... 118
15.3 Response-Key Header Field for PGP ................... 119
16 Examples ............................................ 119
16.1 Registration ........................................ 119
16.2 Invitation to a Multicast Conference ................ 121
16.2.1 Request ............................................. 121
16.2.2 Response ............................................ 122
16.3 Two-party Call ...................................... 123
16.4 Terminating a Call .................................. 125
16.5 Forking Proxy ....................................... 126
16.6 Redirects ........................................... 130
16.7 Negotiation ......................................... 131
16.8 OPTIONS Request ..................................... 132
A Minimal Implementation .............................. 134
A.1 Client .............................................. 134
A.2 Server .............................................. 135
A.3 Header Processing ................................... 135
B Usage of the Session Description Protocol (SDP)...... 136
B.1 Configuring Media Streams ........................... 136
B.2 Setting SDP Values for Unicast ...................... 138
B.3 Multicast Operation ................................. 139
B.4 Delayed Media Streams ............................... 139
B.5 Putting Media Streams on Hold ....................... 139
B.6 Subject and SDP "s=" Line ........................... 140
B.7 The SDP "o=" Line ................................... 140
C Summary of Augmented BNF ............................ 141
C.1 Basic Rules ......................................... 143
D Using SRV DNS Records ............................... 146
E IANA Considerations ................................. 148
F Acknowledgments ..................................... 149
G Authors' Addresses .................................. 149
H Bibliography ........................................ 150
I Full Copyright Statement ............................ 153
13.2.1 Trusting responses .................................. 112
13.3 Callee Privacy ...................................... 113
13.4 Known Security Problems ............................. 113
14 SIP Authentication using HTTP Basic and Digest
Schemes ............................................. 113
14.1 Framework ........................................... 113
14.2 Basic Authentication ................................ 114
14.3 Digest Authentication ............................... 114
14.4 Proxy-Authentication ................................ 115
15 SIP Security Using PGP .............................. 115
15.1 PGP Authentication Scheme ........................... 115
15.1.1 The WWW-Authenticate Response Header ................ 116
15.1.2 The Authorization Request Header .................... 117
15.2 PGP Encryption Scheme ............................... 118
15.3 Response-Key Header Field for PGP ................... 119
16 Examples ............................................ 119
16.1 Registration ........................................ 119
16.2 Invitation to a Multicast Conference ................ 121
16.2.1 Request ............................................. 121
16.2.2 Response ............................................ 122
16.3 Two-party Call ...................................... 123
16.4 Terminating a Call .................................. 125
16.5 Forking Proxy ....................................... 126
16.6 Redirects ........................................... 130
16.7 Negotiation ......................................... 131
16.8 OPTIONS Request ..................................... 132
A Minimal Implementation .............................. 134
A.1 Client .............................................. 134
A.2 Server .............................................. 135
A.3 Header Processing ................................... 135
B Usage of the Session Description Protocol (SDP)...... 136
B.1 Configuring Media Streams ........................... 136
B.2 Setting SDP Values for Unicast ...................... 138
B.3 Multicast Operation ................................. 139
B.4 Delayed Media Streams ............................... 139
B.5 Putting Media Streams on Hold ....................... 139
B.6 Subject and SDP "s=" Line ........................... 140
B.7 The SDP "o=" Line ................................... 140
C Summary of Augmented BNF ............................ 141
C.1 Basic Rules ......................................... 143
D Using SRV DNS Records ............................... 146
E IANA Considerations ................................. 148
F Acknowledgments ..................................... 149
G Authors' Addresses .................................. 149
H Bibliography ........................................ 150
I Full Copyright Statement ............................ 153
1 Introduction
1导言
The Session Initiation Protocol (SIP) is an application-layer control protocol that can establish, modify and terminate multimedia sessions or calls. These multimedia sessions include multimedia conferences, distance learning, Internet telephony and similar applications. SIP can invite both persons and "robots", such as a media storage service. SIP can invite parties to both unicast and multicast sessions; the initiator does not necessarily have to be a member of the session to which it is inviting. Media and participants can be added to an existing session.
会话发起协议（SIP）是一种应用层控制协议，可以建立、修改和终止多媒体会话或呼叫。这些多媒体会议包括多媒体会议、远程学习、互联网电话和类似应用。SIP可以邀请人和“机器人”，如媒体存储服务。SIP可以邀请各方参加单播和多播会话；发起人不一定必须是其邀请的会话的成员。可以将媒体和参与者添加到现有会话中。
SIP can be used to initiate sessions as well as invite members to sessions that have been advertised and established by other means. Sessions can be advertised using multicast protocols such as SAP, electronic mail, news groups, web pages or directories (LDAP), among others.
SIP可用于启动会话以及邀请成员参加已通过其他方式发布和建立的会话。可以使用多播协议（如SAP、电子邮件、新闻组、网页或目录（LDAP）等）发布会话。
SIP transparently supports name mapping and redirection services, allowing the implementation of ISDN and Intelligent Network telephony subscriber services. These facilities also enable personal mobility. In the parlance of telecommunications intelligent network services, this is defined as: "Personal mobility is the ability of end users to originate and receive calls and access subscribed telecommunication services on any terminal in any location, and the ability of the network to identify end users as they move. Personal mobility is based on the use of a unique personal identity (i.e., personal number)." [1]. Personal mobility complements terminal mobility, i.e., the ability to maintain communications when moving a single end system from one subnet to another.
SIP透明地支持名称映射和重定向服务，允许实现ISDN和智能网络电话用户服务。这些设施还可以实现个人移动。用电信智能网络服务的术语来说，这被定义为：“个人移动性是指最终用户在任何位置的任何终端上发起和接收呼叫并访问订阅的电信服务的能力，以及网络在最终用户移动时识别其身份的能力。个人移动基于使用唯一的个人身份（即个人号码）。“[1]。个人移动补充了终端移动，即在将单端系统从一个子网移动到另一个子网时保持通信的能力。
SIP supports five facets of establishing and terminating multimedia communications:
SIP支持建立和终止多媒体通信的五个方面：
User location: determination of the end system to be used for communication;
用户位置：确定用于通信的终端系统；
User capabilities: determination of the media and media parameters to be used;
用户能力：确定要使用的介质和介质参数；
User availability: determination of the willingness of the called party to engage in communications;
用户可用性：确定被叫方参与通信的意愿；
Call setup: "ringing", establishment of call parameters at both called and calling party;
呼叫设置：“振铃”，在被叫方和主叫方建立呼叫参数；
Call handling: including transfer and termination of calls.
呼叫处理：包括呼叫转移和终止。
SIP can also initiate multi-party calls using a multipoint control unit (MCU) or fully-meshed interconnection instead of multicast. Internet telephony gateways that connect Public Switched Telephone Network (PSTN) parties can also use SIP to set up calls between them.
SIP还可以使用多点控制单元（MCU）或全网状互连而不是多播来发起多方呼叫。连接公共交换电话网（PSTN）各方的Internet电话网关也可以使用SIP在它们之间建立呼叫。
SIP is designed as part of the overall IETF multimedia data and control architecture currently incorporating protocols such as RSVP (RFC 2205 [2]) for reserving network resources, the real-time transport protocol (RTP) (RFC 1889 [3]) for transporting real-time data and providing QOS feedback, the real-time streaming protocol (RTSP) (RFC 2326 [4]) for controlling delivery of streaming media, the session announcement protocol (SAP) [5] for advertising multimedia sessions via multicast and the session description protocol (SDP) (RFC 2327 [6]) for describing multimedia sessions. However, the functionality and operation of SIP does not depend on any of these protocols.
SIP被设计为整个IETF多媒体数据和控制体系结构的一部分，目前包括用于保留网络资源的RSVP（RFC 2205[2]）、用于传输实时数据和提供QOS反馈的实时传输协议（RTP）（RFC 1889[3]）、实时流协议（RTSP）（RFC 2326[4]）等协议为了控制流媒体的交付，会话公告协议（SAP）[5]用于通过多播广播多媒体会话，会话描述协议（SDP）（RFC 2327[6]）用于描述多媒体会话。然而，SIP的功能和操作并不依赖于这些协议中的任何一个。
SIP can also be used in conjunction with other call setup and signaling protocols. In that mode, an end system uses SIP exchanges to determine the appropriate end system address and protocol from a given address that is protocol-independent. For example, SIP could be used to determine that the party can be reached via H.323 [7], obtain the H.245 [8] gateway and user address and then use H.225.0 [9] to establish the call.
SIP还可以与其他呼叫设置和信令协议结合使用。在该模式下，终端系统使用SIP交换从协议独立的给定地址确定适当的终端系统地址和协议。例如，SIP可用于确定可通过H.323[7]到达该方，获得H.245[8]网关和用户地址，然后使用H.225.0[9]建立呼叫。
In another example, SIP might be used to determine that the callee is reachable via the PSTN and indicate the phone number to be called, possibly suggesting an Internet-to-PSTN gateway to be used.
在另一示例中，SIP可用于确定被呼叫方可经由PSTN到达，并指示要呼叫的电话号码，可能建议使用因特网到PSTN网关。
SIP does not offer conference control services such as floor control or voting and does not prescribe how a conference is to be managed, but SIP can be used to introduce conference control protocols. SIP does not allocate multicast addresses.
SIP不提供会议控制服务，如楼层控制或投票，也不规定如何管理会议，但SIP可用于引入会议控制协议。SIP不分配多播地址。
SIP can invite users to sessions with and without resource reservation. SIP does not reserve resources, but can convey to the invited system the information necessary to do this.
SIP可以邀请用户参加有或无资源保留的会话。SIP不保留资源，但可以向被邀请的系统传递执行此操作所需的信息。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [10] and indicate requirement levels for compliant SIP implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”将按照RFC 2119[10]中的描述进行解释，并表示符合SIP实施的要求级别。
This specification uses a number of terms to refer to the roles played by participants in SIP communications. The definitions of client, server and proxy are similar to those used by the Hypertext Transport Protocol (HTTP) (RFC 2068 [11]). The terms and generic syntax of URI and URL are defined in RFC 2396 [12]. The following terms have special significance for SIP.
本规范使用许多术语来表示SIP通信中参与者所扮演的角色。客户机、服务器和代理的定义类似于超文本传输协议（HTTP）（RFC 2068[11]）所使用的定义。URI和URL的术语和通用语法在RFC 2396[12]中定义。以下术语对SIP具有特殊意义。
Call: A call consists of all participants in a conference invited by a common source. A SIP call is identified by a globally unique call-id (Section 6.12). Thus, if a user is, for example, invited to the same multicast session by several people, each of these invitations will be a unique call. A point-to-point Internet telephony conversation maps into a single SIP call. In a multiparty conference unit (MCU) based call-in conference, each participant uses a separate call to invite himself to the MCU.
通话：通话由共同来源邀请的会议的所有参与者组成。SIP呼叫由全局唯一的呼叫id标识（第6.12节）。因此，例如，如果一个用户被几个人邀请到同一个多播会话，那么这些邀请中的每一个都将是唯一的呼叫。点对点Internet电话对话映射为单个SIP呼叫。在基于多方会议单元（MCU）的呼叫入式会议中，每个参与者使用单独的呼叫邀请自己加入MCU。
Call leg: A call leg is identified by the combination of Call-ID, To and From.
呼叫分支：呼叫分支由呼叫ID、To和From的组合标识。
Client: An application program that sends SIP requests. Clients may or may not interact directly with a human user. User agents and proxies contain clients (and servers).
客户端：发送SIP请求的应用程序。客户端可能直接与人类用户交互，也可能不直接与人类用户交互。用户代理和代理包含客户端（和服务器）。
Conference: A multimedia session (see below), identified by a common session description. A conference can have zero or more members and includes the cases of a multicast conference, a full-mesh conference and a two-party "telephone call", as well as combinations of these. Any number of calls can be used to create a conference.
会议：一个多媒体会议（见下文），由一个通用的会议描述标识。一个会议可以有零个或多个成员，包括多播会议、全网会议和双方“电话呼叫”以及这些会议的组合。可以使用任意数量的呼叫创建会议。
Downstream: Requests sent in the direction from the caller to the callee (i.e., 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响应均为最终响应。
Initiator, calling party, caller: The party initiating a conference invitation. Note that the calling party does not have to be the same as the one creating the conference.
发起人、呼叫方、呼叫者：发起会议邀请的一方。请注意，呼叫方不必与创建会议的呼叫方相同。
Invitation: A request sent to a user (or service) requesting participation in a session. A successful SIP invitation consists of two transactions: an INVITE request followed by an ACK request.
邀请：发送给用户（或服务）的请求，请求参与会话。成功的SIP邀请由两个事务组成：一个INVITE请求，后跟一个ACK请求。
Invitee, invited user, called party, callee: The person or service that the calling party is trying to invite to a conference.
被邀请方、被邀请用户、被叫方、被叫方：主叫方试图邀请参加会议的人员或服务。
Isomorphic request or response: Two requests or responses are defined to be isomorphic for the purposes of this document if they have the same values for the Call-ID, To, From and CSeq header fields. In addition, isomorphic requests have to have the same Request-URI.
同构请求或响应：如果两个请求或响应具有相同的调用ID、to、From和CSeq头字段值，则在本文档中定义为同构。此外，同构请求必须具有相同的请求URI。
Location server: See location service.
位置服务器：请参阅位置服务。
Location service: A location service is used by a SIP redirect or proxy server to obtain information about a callee's possible location(s). Location services are offered by location servers. Location servers MAY be co-located with a SIP server, but the manner in which a SIP server requests location services is beyond the scope of this document.
位置服务：SIP重定向或代理服务器使用位置服务来获取有关被叫方可能位置的信息。定位服务由定位服务器提供。位置服务器可以与SIP服务器位于同一位置，但是SIP服务器请求位置服务的方式超出了本文档的范围。
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 program that acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them on, possibly after translation, to other servers. A proxy interprets, and, if necessary, rewrites a request message before forwarding it.
代理，代理服务器：一种中间程序，既充当服务器又充当客户端，用于代表其他客户端发出请求。请求可以在内部提供服务，也可以在转换后传递给其他服务器。代理在转发请求消息之前解释请求消息，并在必要时重写请求消息。
Redirect server: A redirect server is a server that accepts a SIP request, maps the address into zero or more new addresses and returns these addresses to the client. Unlike a proxy server , it does not initiate its own SIP request. Unlike a user agent server , it does not accept calls.
重定向服务器：重定向服务器是一个服务器，它接受SIP请求，将地址映射为零个或多个新地址，并将这些地址返回给客户端。与代理服务器不同，它不会启动自己的SIP请求。与用户代理服务器不同，它不接受调用。
Registrar: A registrar is a server that accepts REGISTER requests. A registrar is typically co-located with a proxy or redirect server and MAY offer location services.
注册器：注册器是接受注册请求的服务器。注册器通常与代理服务器或重定向服务器位于同一位置，并可提供定位服务。
Ringback: Ringback is the signaling tone produced by the calling client's application indicating that a called party is being alerted (ringing).
Ringback：Ringback是呼叫客户端的应用程序产生的信号音，表示被叫方正在收到警报（振铃）。
Server: A server is an application program that accepts requests in order to service requests and sends back responses to those requests. Servers are either proxy, redirect or user agent servers or registrars.
服务器：服务器是一个应用程序，它接受请求以便为请求提供服务，并将响应发送回这些请求。服务器可以是代理、重定向或用户代理服务器或注册器。
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 [6]) (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 user name , session id , network type , address type and address elements in the origin field.
会话：来自SDP规范：“多媒体会话是一组多媒体发送方和接收方以及从发送方流向接收方的数据流。多媒体会议是多媒体会话的一个示例。”（RFC 2327[6]）（SDP定义的会话可以包括一个或多个RTP会话。）如定义，可以通过不同的呼叫多次邀请被叫方参加同一会话。如果使用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 sent from the server to the client. A transaction is identified by the CSeq sequence number (Section 6.17) within a single call leg. The ACK request has the same CSeq number as the corresponding INVITE request, but comprises a transaction of its own.
（SIP）事务：SIP事务发生在客户端和服务器之间，包括从客户端发送到服务器的第一个请求到从服务器发送到客户端的最终（非1xx）响应的所有消息。交易由单个呼叫分支内的CSeq序列号（第6.17节）标识。ACK请求与相应的INVITE请求具有相同的CSeq号，但包含自己的事务。
Upstream: Responses sent in the direction from the user agent server to the user agent client.
上游：从用户代理服务器向用户代理客户端发送的响应。
URL-encoded: A character string encoded according to RFC 1738, Section 2.2 [13].
URL编码：根据RFC 1738第2.2节[13]编码的字符串。
User agent client (UAC), calling user agent: A user agent client is a client application that initiates the SIP request.
用户代理客户端（UAC），调用用户代理：用户代理客户端是发起SIP请求的客户端应用程序。
User agent server (UAS), called user agent: A user agent server is a server application that contacts the user when a SIP request is received and that returns a response on behalf of the user. The response accepts, rejects or redirects the request.
用户代理服务器（UAS），称为用户代理：用户代理服务器是一个服务器应用程序，在收到SIP请求时与用户联系，并代表用户返回响应。响应接受、拒绝或重定向请求。
User agent (UA): An application which contains both a user agent client and user agent server.
用户代理（UA）：包含用户代理客户端和用户代理服务器的应用程序。
An application program MAY be capable of acting both as a client and a server. For example, a typical multimedia conference control application would act as a user agent client to initiate calls or to
应用程序可以同时充当客户端和服务器。例如，典型的多媒体会议控制应用程序将充当用户代理客户端来发起呼叫或
invite others to conferences and as a user agent server to accept invitations. The properties of the different SIP server types are summarized in Table 1.
邀请其他人参加会议，并作为用户代理服务器接受邀请。表1总结了不同SIP服务器类型的属性。
property redirect proxy user agent registrar
server server server
__________________________________________________________________
also acts as a SIP client no yes no no
returns 1xx status yes yes yes yes
returns 2xx status no yes yes yes
returns 3xx status yes yes yes yes
returns 4xx status yes yes yes yes
returns 5xx status yes yes yes yes
returns 6xx status no yes yes yes
inserts Via header no yes no no
accepts ACK yes yes yes no
property redirect proxy user agent registrar
server server server
__________________________________________________________________
also acts as a SIP client no yes no no
returns 1xx status yes yes yes yes
returns 2xx status no yes yes yes
returns 3xx status yes yes yes yes
returns 4xx status yes yes yes yes
returns 5xx status yes yes yes yes
returns 6xx status no yes yes yes
inserts Via header no yes no no
accepts ACK yes yes yes no
Table 1: Properties of the different SIP server types
表1：不同SIP服务器类型的属性
This section explains the basic protocol functionality and operation. Callers and callees are identified by SIP addresses, described in Section 1.4.1. When making a SIP call, a caller first locates the appropriate server (Section 1.4.2) and then sends a SIP request (Section 1.4.3). The most common SIP operation is the invitation (Section 1.4.4). Instead of directly reaching the intended callee, a SIP request may be redirected or may trigger a chain of new SIP requests by proxies (Section 1.4.5). Users can register their location(s) with SIP servers (Section 4.2.6).
本节介绍基本协议功能和操作。呼叫者和被呼叫者由SIP地址标识，如第1.4.1节所述。进行SIP呼叫时，呼叫者首先定位适当的服务器（第1.4.2节），然后发送SIP请求（第1.4.3节）。最常见的SIP操作是邀请（第1.4.4节）。SIP请求可以被重定向，也可以通过代理触发一系列新的SIP请求，而不是直接到达预定的被叫方（第1.4.5节）。用户可以向SIP服务器注册其位置（第4.2.6节）。
The "objects" addressed by SIP are users at hosts, identified by a SIP URL. The SIP URL takes a form similar to a mailto or telnet URL, i.e., user@host. The user part is a user name or a telephone number. The host part is either a domain name or a numeric network address. See section 2 for a detailed discussion of SIP URL's.
SIP寻址的“对象”是主机上的用户，由SIPURL标识。SIP URL采用类似于mailto或telnet URL的形式，即。，user@host. 用户部分是用户名或电话号码。主机部分是域名或数字网络地址。有关SIPURL的详细讨论，请参见第2节。
A user's SIP address can be obtained out-of-band, can be learned via existing media agents, can be included in some mailers' message headers, or can be recorded during previous invitation interactions. In many cases, a user's SIP URL can be guessed from their email address.
用户的SIP地址可以在带外获得，可以通过现有的媒体代理了解，可以包含在某些邮件发送者的消息头中，或者可以在以前的邀请交互过程中记录。在许多情况下，可以从用户的电子邮件地址猜出用户的SIPURL。
A SIP URL address can designate an individual (possibly located at one of several end systems), the first available person from a group of individuals or a whole group. The form of the address, for example, sip:sales@example.com , is not sufficient, in general, to determine the intent of the caller.
SIPURL地址可以指定一个人（可能位于多个终端系统之一）、一组个人或整个组中第一个可用的人。地址的形式，例如sip：sales@example.com，通常不足以确定调用方的意图。
If a user or service chooses to be reachable at an address that is guessable from the person's name and organizational affiliation, the traditional method of ensuring privacy by having an unlisted "phone" number is compromised. However, unlike traditional telephony, SIP offers authentication and access control mechanisms and can avail itself of lower-layer security mechanisms, so that client software can reject unauthorized or undesired call attempts.
如果用户或服务选择在一个可以从其姓名和组织隶属关系猜到的地址进行访问，则通过拥有未列出的“电话”号码来确保隐私的传统方法将受到损害。然而，与传统电话不同，SIP提供身份验证和访问控制机制，并且可以利用较低层的安全机制，因此客户端软件可以拒绝未经授权或不希望的呼叫尝试。
When a client wishes to send a request, the client either sends it to a locally configured SIP proxy server (as in HTTP), independent of the Request-URI, or sends it to the IP address and port corresponding to the Request-URI.
当客户机希望发送请求时，客户机要么将其发送到本地配置的SIP代理服务器（如HTTP），与请求URI无关，要么将其发送到与请求URI对应的IP地址和端口。
For the latter case, the client must determine the protocol, port and IP address of a server to which to send the request. A client SHOULD follow the steps below to obtain this information, but MAY follow the alternative, optional procedure defined in Appendix D. At each step, unless stated otherwise, the client SHOULD try to contact a server at the port number listed in the Request-URI. If no port number is present in the Request-URI, the client uses port 5060. If the Request-URI specifies a protocol (TCP or UDP), the client contacts the server using that protocol. If no protocol is specified, the client tries UDP (if UDP is supported). If the attempt fails, or if the client doesn't support UDP but supports TCP, it then tries TCP.
对于后一种情况，客户端必须确定要向其发送请求的服务器的协议、端口和IP地址。客户机应遵循以下步骤获取此信息，但也可以遵循附录D中定义的可选过程。在每个步骤中，除非另有说明，否则客户机应尝试通过请求URI中列出的端口号联系服务器。如果请求URI中不存在端口号，则客户端使用端口5060。如果请求URI指定了协议（TCP或UDP），客户端将使用该协议与服务器联系。如果未指定协议，客户端将尝试UDP（如果支持UDP）。如果尝试失败，或者客户端不支持UDP但支持TCP，则会尝试TCP。
A client SHOULD be able to interpret explicit network notifications (such as ICMP messages) which indicate that a server is not reachable, rather than relying solely on timeouts. (For socket-based programs: For TCP, connect() returns ECONNREFUSED if the client could not connect to a server at that address. For UDP, the socket needs to be bound to the destination address using connect() rather than sendto() or similar so that a second write() fails with ECONNREFUSED if there is no server listening) If the client finds the server is not reachable at a particular address, it SHOULD behave as if it had received a 400-class error response to that request.
客户端应该能够解释明确的网络通知（如ICMP消息），这些通知指示无法访问服务器，而不仅仅依赖超时。（对于基于套接字的程序：对于TCP，如果客户端无法连接到该地址的服务器，则connect（）返回EconRefused。对于UDP，需要使用connect（）而不是sendto（）或类似方法将套接字绑定到目标地址，以便在没有服务器侦听的情况下，使用EconRefused进行第二次写入（）失败）如果客户机发现服务器在某个特定地址无法访问，则其行为应与收到该请求的400类错误响应类似。
The client tries to find one or more addresses for the SIP server by querying DNS. The procedure is as follows:
客户端尝试通过查询DNS来查找SIP服务器的一个或多个地址。程序如下：
1. If the host portion of the Request-URI is an IP address, the client contacts the server at the given address. Otherwise, the client proceeds to the next step.
1. 如果请求URI的主机部分是IP地址，则客户机将在给定地址与服务器联系。否则，客户端将进入下一步。
2. The client queries the DNS server for address records for the host portion of the Request-URI. If the DNS server returns no address records, the client stops, as it has been unable to locate a server. By address record, we mean A RR's, AAAA RR's, or other similar address records, chosen according to the client's network protocol capabilities.
2. 客户端向DNS服务器查询请求URI的主机部分的地址记录。如果DNS服务器未返回任何地址记录，则客户端将停止，因为它无法找到服务器。地址记录是指根据客户端的网络协议功能选择的RR、AAAA RR或其他类似地址记录。
There are no mandatory rules on how to select a host name for a SIP server. Users are encouraged to name their SIP servers using the sip.domainname (i.e., sip.example.com) convention, as specified in RFC 2219 [16]. Users may only know an email address instead of a full SIP URL for a callee, however. In that case, implementations may be able to increase the likelihood of reaching a SIP server for that domain by constructing a SIP URL from that email address by prefixing the host name with "sip.". In the future, this mechanism is likely to become unnecessary as better DNS techniques, such as the one in Appendix D, become widely available.
没有关于如何为SIP服务器选择主机名的强制性规则。鼓励用户使用RFC 2219[16]中规定的SIP.domainname（即SIP.example.com）约定命名其SIP服务器。然而，用户可能只知道被呼叫方的电子邮件地址，而不知道完整的SIPURL。在这种情况下，通过在主机名前面加上“SIP”，实现可以通过从该电子邮件地址构造SIP URL来增加到达该域的SIP服务器的可能性。将来，随着更好的DNS技术（如附录D中的技术）的广泛应用，这种机制可能变得不必要。
A client MAY cache a successful DNS query result. A successful query is one which contained records in the answer, and a server was contacted at one of the addresses from the answer. When the client wishes to send a request to the same host, it MUST start the search as if it had just received this answer from the name server. The client MUST follow the procedures in RFC1035 [15] regarding DNS cache invalidation when the DNS time-to-live expires.
客户端可以缓存成功的DNS查询结果。成功的查询包含答案中的记录，并且通过答案中的一个地址与服务器联系。当客户机希望向同一主机发送请求时，它必须启动搜索，就像它刚刚从名称服务器收到此答复一样。当DNS生存时间到期时，客户端必须遵循RFC1035[15]中有关DNS缓存失效的程序。
Once the host part has been resolved to a SIP server, the client sends one or more SIP requests to that server and receives one or more responses from the server. A request (and its retransmissions) together with the responses triggered by that request make up a SIP transaction. All responses to a request contain the same values in the Call-ID, CSeq, To, and From fields (with the possible addition of a tag in the To field (section 6.37)). This allows responses to be matched with requests. The ACK request following an INVITE is not part of the transaction since it may traverse a different set of hosts.
一旦将主机部分解析为SIP服务器，客户端将向该服务器发送一个或多个SIP请求，并从服务器接收一个或多个响应。请求（及其重传）与该请求触发的响应一起构成SIP事务。对请求的所有响应在Call ID、CSeq、to和From字段中包含相同的值（可能在to字段中添加标记（第6.37节））。这允许响应与请求匹配。INVITE之后的ACK请求不是事务的一部分，因为它可能会遍历不同的主机集。
If TCP is used, request and responses within a single SIP transaction are carried over the same TCP connection (see Section 10). Several SIP requests from the same client to the same server MAY use the same TCP connection or MAY use a new connection for each request.
如果使用TCP，单个SIP事务中的请求和响应将通过相同的TCP连接进行（请参阅第10节）。从同一客户机到同一服务器的多个SIP请求可能使用相同的TCP连接，也可能为每个请求使用新的连接。
If the client sent the request via unicast UDP, the response is sent to the address contained in the next Via header field (Section 6.40) of the response. If the request is sent via multicast UDP, the response is directed to the same multicast address and destination port. For UDP, reliability is achieved using retransmission (Section 10).
如果客户端通过单播UDP发送请求，则响应将发送到响应的下一个via头字段（第6.40节）中包含的地址。如果请求通过多播UDP发送，则响应将定向到相同的多播地址和目标端口。对于UDP，可靠性是通过重传实现的（第10节）。
The SIP message format and operation is independent of the transport protocol.
SIP消息格式和操作独立于传输协议。
A successful SIP invitation consists of two requests, INVITE followed by ACK. The INVITE (Section 4.2.1) request asks the callee to join a particular conference or establish a two-party conversation. After the callee has agreed to participate in the call, the caller confirms that it has received that response by sending an ACK (Section 4.2.2) request. If the caller no longer wants to participate in the call, it sends a BYE request instead of an ACK.
成功的SIP邀请包含两个请求，INVITE后接ACK。邀请请求（第4.2.1节）要求被叫方参加特定会议或建立双方对话。被呼叫方同意参与呼叫后，呼叫方通过发送ACK（第4.2.2节）请求确认其已收到该响应。如果呼叫者不再想参与呼叫，它将发送BYE请求而不是ACK。
The INVITE request typically contains a session description, for example written in SDP (RFC 2327 [6]) format, that provides the called party with enough information to join the session. For multicast sessions, the session description enumerates the media types and formats that are allowed to be distributed to that session. For a unicast session, the session description enumerates the media types and formats that the caller is willing to use and where it wishes the media data to be sent. In either case, if the callee wishes to accept the call, it responds to the invitation by returning a similar description listing the media it wishes to use. For a multicast session, the callee SHOULD only return a session description if it is unable to receive the media indicated in the caller's description or wants to receive data via unicast.
INVITE请求通常包含会话描述，例如以SDP（RFC 2327[6]）格式编写的会话描述，该会话描述为被叫方提供足够的信息以加入会话。对于多播会话，“会话描述”枚举允许分发到该会话的媒体类型和格式。对于单播会话，会话描述列举调用者愿意使用的媒体类型和格式，以及希望将媒体数据发送到的位置。在这两种情况下，如果被叫方希望接受呼叫，它会返回一个类似的描述，列出它希望使用的媒体，以响应邀请。对于多播会话，被呼叫方只有在无法接收呼叫方描述中指示的媒体或希望通过单播接收数据时，才应返回会话描述。
The protocol exchanges for the INVITE method are shown in Fig. 1 for a proxy server and in Fig. 2 for a redirect server. (Note that the messages shown in the figures have been abbreviated slightly.) In Fig. 1, the proxy server accepts the INVITE request (step 1), contacts the location service with all or parts of the address (step 2) and obtains a more precise location (step 3). The proxy server then issues a SIP INVITE request to the address(es) returned by the location service (step 4). The user agent server alerts the user (step 5) and returns a success indication to the proxy server (step
图1中显示了针对代理服务器的INVITE方法的协议交换，图2中显示了针对重定向服务器的协议交换。（注意，图中所示的消息已略为缩写。）在图1中，代理服务器接受INVITE请求（步骤1），使用地址的全部或部分联系位置服务（步骤2），并获得更精确的位置（步骤3）。然后，代理服务器向位置服务返回的地址发出SIP INVITE请求（步骤4）。用户代理服务器向用户发出警报（步骤5），并向代理服务器返回成功指示（步骤5）
6). The proxy server then returns the success result to the original caller (step 7). The receipt of this message is confirmed by the caller using an ACK request, which is forwarded to the callee (steps 8 and 9). Note that an ACK can also be sent directly to the callee, bypassing the proxy. All requests and responses have the same Call-ID.
6). 然后，代理服务器将成功结果返回给原始调用方（步骤7）。调用者使用ACK请求确认收到该消息，该请求被转发给被调用者（步骤8和9）。请注意，ACK也可以绕过代理直接发送给被叫方。所有请求和响应都具有相同的Call-ID。
+....... cs.columbia.edu .......+
: :
: (~~~~~~~~~~) :
: ( location ) :
: ( service ) :
: (~~~~~~~~~~) :
: ^ | :
: | hgs@lab :
: 2| 3| :
: | | :
: henning | :
+.. cs.tu-berlin.de ..+ 1: INVITE : | | :
: : henning@cs.col: | \/ 4: INVITE 5: ring :
: cz@cs.tu-berlin.de ========================>(~~~~~~)=========>(~~~~~~) :
: <........................( )<.........( ) :
: : 7: 200 OK : ( )6: 200 OK ( ) :
: : : ( work ) ( lab ) :
: : 8: ACK : ( )9: ACK ( ) :
: ========================>(~~~~~~)=========>(~~~~~~) :
+.....................+ +...............................+
+....... cs.columbia.edu .......+
: :
: (~~~~~~~~~~) :
: ( location ) :
: ( service ) :
: (~~~~~~~~~~) :
: ^ | :
: | hgs@lab :
: 2| 3| :
: | | :
: henning | :
+.. cs.tu-berlin.de ..+ 1: INVITE : | | :
: : henning@cs.col: | \/ 4: INVITE 5: ring :
: cz@cs.tu-berlin.de ========================>(~~~~~~)=========>(~~~~~~) :
: <........................( )<.........( ) :
: : 7: 200 OK : ( )6: 200 OK ( ) :
: : : ( work ) ( lab ) :
: : 8: ACK : ( )9: ACK ( ) :
: ========================>(~~~~~~)=========>(~~~~~~) :
+.....................+ +...............................+
====> SIP request
....> SIP response
====> SIP request
....> SIP response
^ | non-SIP protocols |
^|非SIP协议|
Figure 1: Example of SIP proxy server
图1:SIP代理服务器的示例
The redirect server shown in Fig. 2 accepts the INVITE request (step 1), contacts the location service as before (steps 2 and 3) and, instead of contacting the newly found address itself, returns the address to the caller (step 4), which is then acknowledged via an ACK
图2所示的重定向服务器接受INVITE请求（步骤1），与之前一样联系位置服务（步骤2和3），并且，代替联系新找到的地址本身，将地址返回给调用者（步骤4），然后通过ACK确认该地址
request (step 5). The caller issues a new request, with the same call-ID but a higher CSeq, to the address returned by the first server (step 6). In the example, the call succeeds (step 7). The caller and callee complete the handshake with an ACK (step 8).
请求（步骤5）。调用者向第一台服务器返回的地址发出一个新请求，该请求具有相同的呼叫ID，但具有更高的CSeq（步骤6）。在本例中，调用成功（步骤7）。呼叫者和被呼叫者通过ACK完成握手（步骤8）。
The next section discusses what happens if the location service returns more than one possible alternative.
下一节将讨论如果位置服务返回多个可能的备选方案会发生什么情况。
A callee may move between a number of different end systems over time. These locations can be dynamically registered with the SIP server (Sections 1.4.7, 4.2.6). A location server MAY also use one or more other protocols, such as finger (RFC 1288 [17]), rwhois (RFC 2167 [18]), LDAP (RFC 1777 [19]), multicast-based protocols [20] or operating-system dependent mechanisms to actively determine the end system where a user might be reachable. A location server MAY return several locations because the user is logged in at several hosts simultaneously or because the location server has (temporarily) inaccurate information. The SIP server combines the results to yield a list of a zero or more locations.
被叫方可以随时间在多个不同的终端系统之间移动。这些位置可以在SIP服务器上动态注册（第1.4.7、4.2.6节）。位置服务器还可以使用一个或多个其他协议，例如finger（RFC 1288[17]）、rwhois（RFC 2167[18]）、LDAP（RFC 1777[19]）、基于多播的协议[20]或依赖于操作系统的机制来主动地确定可到达用户的终端系统。位置服务器可能会返回多个位置，因为用户同时在多个主机上登录，或者因为位置服务器（暂时）有不准确的信息。SIP服务器组合结果以生成零个或多个位置的列表。
The action taken on receiving a list of locations varies with the type of SIP server. A SIP redirect server returns the list to the client as Contact headers (Section 6.13). A SIP proxy server can sequentially or in parallel try the addresses until the call is successful (2xx response) or the callee has declined the call (6xx response). With sequential attempts, a proxy server can implement an "anycast" service.
接收位置列表时所采取的操作因SIP服务器的类型而异。SIP重定向服务器将列表作为联系人头返回给客户端（第6.13节）。SIP代理服务器可以顺序或并行尝试地址，直到呼叫成功（2xx响应）或被呼叫方拒绝呼叫（6xx响应）。通过连续尝试，代理服务器可以实现“选播”服务。
If a proxy server forwards a SIP request, it MUST add itself to the beginning of the list of forwarders noted in the Via (Section 6.40) headers. The Via trace ensures that replies can take the same path back, ensuring correct operation through compliant firewalls and avoiding request loops. On the response path, each host MUST remove its Via, so that routing internal information is hidden from the callee and outside networks. A proxy server MUST check that it does not generate a request to a host listed in the Via sent-by, via-received or via-maddr parameters (Section 6.40). (Note: If a host has several names or network addresses, this does not always work. Thus, each host also checks if it is part of the Via list.)
如果代理服务器转发SIP请求，它必须将自己添加到Via（第6.40节）标题中注明的转发器列表的开头。Via跟踪确保回复可以采用相同的路径返回，从而确保通过兼容防火墙进行正确操作，并避免请求循环。在响应路径上，每个主机必须删除其Via，以便对被叫方和外部网络隐藏路由内部信息。代理服务器必须检查是否未向Via发送、接收或通过maddr参数（第6.40节）中列出的主机生成请求。（注意：如果一台主机有多个名称或网络地址，这并不总是有效的。因此，每台主机也会检查它是否是Via列表的一部分。）
A SIP invitation may traverse more than one SIP proxy server. If one of these "forks" the request, i.e., issues more than one request in response to receiving the invitation request, it is possible that a client is reached, independently, by more than one copy of the
SIP邀请可以遍历多个SIP代理服务器。如果其中一个“分叉”请求，即发出多个请求以响应收到邀请请求，则可能会有多个副本独立地与客户联系
invitation request. Each of these copies bears the same Call-ID. The user agent MUST return the same status response returned in the first response. Duplicate requests are not an error.
邀请请求。每个副本都具有相同的Call-ID。用户代理必须返回第一个响应中返回的相同状态响应。重复的请求不是错误。
In some circumstances, it is desirable to change the parameters of an existing session. This is done by re-issuing the INVITE, using the same Call-ID, but a new or different body or header fields to convey the new information. This re INVITE MUST have a higher CSeq than any previous request from the client to the server.
在某些情况下，最好更改现有会话的参数。这是通过使用相同的调用ID重新发出INVITE来完成的，但使用新的或不同的正文或标题字段来传递新信息。此重新邀请的CSeq必须高于以前从客户端到服务器的任何请求。
For example, two parties may have been conversing and then want to add a third party, switching to multicast for efficiency. One of the participants invites the third party with the new multicast address and simultaneously sends an INVITE to the second party, with the new multicast session description, but with the old call identifier.
例如，两方可能已经进行了对话，然后想要添加第三方，为了提高效率而切换到多播。其中一个参与者使用新的多播地址邀请第三方，同时使用新的多播会话描述，但使用旧的呼叫标识符向第二方发送邀请。
The REGISTER request allows a client to let a proxy or redirect server know at which address(es) it can be reached. A client MAY also use it to install call handling features at the server.
注册请求允许客户端让代理或重定向服务器知道可以到达哪个地址。客户端还可以使用它在服务器上安装呼叫处理功能。
A single conference session or call involves one or more SIP request-response transactions. Proxy servers do not have to keep state for a particular call, however, they MAY maintain state for a single SIP transaction, as discussed in Section 12. For efficiency, a server MAY cache the results of location service requests.
单个会议会话或呼叫涉及一个或多个SIP请求-响应事务。代理服务器不必为特定呼叫保持状态，但是，它们可以为单个SIP事务保持状态，如第12节所述。为了提高效率，服务器可以缓存位置服务请求的结果。
SIP makes minimal assumptions about the underlying transport and network-layer protocols. The lower-layer can provide either a packet or a byte stream service, with reliable or unreliable service.
SIP对底层传输和网络层协议进行了最低限度的假设。较低层可以提供分组或字节流服务，具有可靠或不可靠的服务。
In an Internet context, SIP is able to utilize both UDP and TCP as transport protocols, among others. UDP allows the application to more carefully control the timing of messages and their retransmission, to perform parallel searches without requiring TCP connection state for each outstanding request, and to use multicast. Routers can more readily snoop SIP UDP packets. TCP allows easier passage through existing firewalls.
在Internet环境中，SIP能够利用UDP和TCP作为传输协议。UDP允许应用程序更仔细地控制消息及其重新传输的时间，执行并行搜索而不需要每个未完成请求的TCP连接状态，并使用多播。路由器可以更容易地嗅探SIPUDP数据包。TCP允许更轻松地通过现有防火墙。
+....... cs.columbia.edu .......+
: :
: (~~~~~~~~~~) :
: ( location ) :
: ( service ) :
: (~~~~~~~~~~) :
: ^ | :
: | hgs@lab :
: 2| 3| :
: | | :
: henning| :
+.. cs.tu-berlin.de ..+ 1: INVITE : | | :
: : henning@cs.col: | \/ :
: cz@cs.tu-berlin.de =======================>(~~~~~~) :
: | ^ | <.......................( ) :
: | . | : 4: 302 Moved : ( ) :
: | . | : hgs@lab : ( work ) :
: | . | : : ( ) :
: | . | : 5: ACK : ( ) :
: | . | =======================>(~~~~~~) :
: | . | : : :
+.......|...|.........+ : :
| . | : :
| . | : :
| . | : :
| . | : :
| . | 6: INVITE hgs@lab.cs.columbia.edu (~~~~~~) :
| . ==================================================> ( ) :
| ..................................................... ( ) :
| 7: 200 OK : ( lab ) :
| : ( ) :
| 8: ACK : ( ) :
======================================================> (~~~~~~) :
+...............................+
+....... cs.columbia.edu .......+
: :
: (~~~~~~~~~~) :
: ( location ) :
: ( service ) :
: (~~~~~~~~~~) :
: ^ | :
: | hgs@lab :
: 2| 3| :
: | | :
: henning| :
+.. cs.tu-berlin.de ..+ 1: INVITE : | | :
: : henning@cs.col: | \/ :
: cz@cs.tu-berlin.de =======================>(~~~~~~) :
: | ^ | <.......................( ) :
: | . | : 4: 302 Moved : ( ) :
: | . | : hgs@lab : ( work ) :
: | . | : : ( ) :
: | . | : 5: ACK : ( ) :
: | . | =======================>(~~~~~~) :
: | . | : : :
+.......|...|.........+ : :
| . | : :
| . | : :
| . | : :
| . | : :
| . | 6: INVITE hgs@lab.cs.columbia.edu (~~~~~~) :
| . ==================================================> ( ) :
| ..................................................... ( ) :
| 7: 200 OK : ( lab ) :
| : ( ) :
| 8: ACK : ( ) :
======================================================> (~~~~~~) :
+...............................+
====> SIP request
....> SIP response
====> SIP request
....> SIP response
^ | non-SIP protocols |
^|非SIP协议|
Figure 2: Example of SIP redirect server
图2:SIP重定向服务器的示例
When TCP is used, SIP can use one or more connections to attempt to contact a user or to modify parameters of an existing conference. Different SIP requests for the same SIP call MAY use different TCP connections or a single persistent connection, as appropriate.
使用TCP时，SIP可以使用一个或多个连接来尝试联系用户或修改现有会议的参数。针对同一SIP呼叫的不同SIP请求可以使用不同的TCP连接或单个持久连接（视情况而定）。
For concreteness, this document will only refer to Internet protocols. However, SIP MAY also be used directly with protocols such as ATM AAL5, IPX, frame relay or X.25. The necessary naming conventions are beyond the scope of this document. User agents SHOULD implement both UDP and TCP transport. Proxy, registrar, and redirect servers MUST implement both UDP and TCP transport.
具体而言，本文件仅涉及互联网协议。然而，SIP也可以直接与诸如ATM AAL5、IPX、帧中继或X.25等协议一起使用。必要的命名约定超出了本文档的范围。用户代理应实现UDP和TCP传输。代理服务器、注册服务器和重定向服务器必须同时实现UDP和TCP传输。
SIP is text-based, using ISO 10646 in UTF-8 encoding throughout. This allows easy implementation in languages such as Java, Tcl and Perl, allows easy debugging, and most importantly, makes SIP flexible and extensible. As SIP is used for initiating multimedia conferences rather than delivering media data, it is believed that the additional overhead of using a text-based protocol is not significant.
SIP是基于文本的，在UTF-8编码中始终使用ISO10646。这使得可以用Java、Tcl和Perl等语言轻松实现，允许轻松调试，最重要的是，使SIP具有灵活性和可扩展性。由于SIP用于发起多媒体会议而不是传送媒体数据，因此人们认为使用基于文本的协议的额外开销并不显著。
2 SIP Uniform Resource Locators
2个SIP统一资源定位器
SIP URLs are used within SIP messages to indicate the originator (From), current destination (Request-URI) and final recipient (To) of a SIP request, and to specify redirection addresses (Contact). A SIP URL can also be embedded in web pages or other hyperlinks to indicate that a particular user or service can be called via SIP. When used as a hyperlink, the SIP URL indicates the use of the INVITE method.
SIP URL在SIP消息中用于指示SIP请求的发起人（发件人）、当前目的地（请求URI）和最终收件人（收件人），并指定重定向地址（联系人）。SIPURL还可以嵌入到网页或其他超链接中，以指示可以通过SIP调用特定的用户或服务。当用作超链接时，SIPURL指示INVITE方法的使用。
The SIP URL scheme is defined to allow setting SIP request-header fields and the SIP message-body.
SIPURL方案被定义为允许设置SIP请求头字段和SIP消息体。
This corresponds to the use of mailto: URLs. It makes it possible, for example, to specify the subject, urgency or media types of calls initiated through a web page or as part of an email message.
这对应于mailto:url的使用。例如，它可以指定通过网页或电子邮件发起的呼叫的主题、紧急程度或媒体类型。
A SIP URL follows the guidelines of RFC 2396 [12] and has the syntax shown in Fig. 3. The syntax is described using Augmented Backus-Naur Form (See Section C). Note that reserved characters have to be escaped and that the "set of characters 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" [12].
SIPURL遵循RFC 2396[12]的指导原则，并具有图3所示的语法。语法使用扩展的Backus-Naur形式描述（见C节）。请注意，保留字符必须转义，并且“任何给定URI组件内保留的字符集由该组件定义。通常，如果用转义US-ASCII编码替换字符，则如果URI的语义发生变化，则该字符将被保留”[12]。
SIP-URL = "sip:" [ userinfo "@" ] hostport
url-parameters [ headers ]
userinfo = user [ ":" password ]
user = *( unreserved | escaped
| "&" | "=" | "+" | "$" | "," )
password = *( unreserved | escaped
| "&" | "=" | "+" | "$" | "," )
hostport = host [ ":" port ]
host = hostname | IPv4address
hostname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum
toplabel = alpha | alpha *( alphanum | "-" ) alphanum
IPv4address = 1*digit "." 1*digit "." 1*digit "." 1*digit
port = *digit
url-parameters = *( ";" url-parameter )
url-parameter = transport-param | user-param | method-param
| ttl-param | maddr-param | other-param
transport-param = "transport=" ( "udp" | "tcp" )
ttl-param = "ttl=" ttl
ttl = 1*3DIGIT ; 0 to 255
maddr-param = "maddr=" host
user-param = "user=" ( "phone" | "ip" )
method-param = "method=" Method
tag-param = "tag=" UUID
UUID = 1*( hex | "-" )
other-param = ( token | ( token "=" ( token | quoted-string )))
headers = "?" header *( "&" header )
header = hname "=" hvalue
hname = 1*uric
hvalue = *uric
uric = reserved | unreserved | escaped
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
"$" | ","
digits = 1*DIGIT
SIP-URL = "sip:" [ userinfo "@" ] hostport
url-parameters [ headers ]
userinfo = user [ ":" password ]
user = *( unreserved | escaped
| "&" | "=" | "+" | "$" | "," )
password = *( unreserved | escaped
| "&" | "=" | "+" | "$" | "," )
hostport = host [ ":" port ]
host = hostname | IPv4address
hostname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum
toplabel = alpha | alpha *( alphanum | "-" ) alphanum
IPv4address = 1*digit "." 1*digit "." 1*digit "." 1*digit
port = *digit
url-parameters = *( ";" url-parameter )
url-parameter = transport-param | user-param | method-param
| ttl-param | maddr-param | other-param
transport-param = "transport=" ( "udp" | "tcp" )
ttl-param = "ttl=" ttl
ttl = 1*3DIGIT ; 0 to 255
maddr-param = "maddr=" host
user-param = "user=" ( "phone" | "ip" )
method-param = "method=" Method
tag-param = "tag=" UUID
UUID = 1*( hex | "-" )
other-param = ( token | ( token "=" ( token | quoted-string )))
headers = "?" header *( "&" header )
header = hname "=" hvalue
hname = 1*uric
hvalue = *uric
uric = reserved | unreserved | escaped
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
"$" | ","
digits = 1*DIGIT
Figure 3: SIP URL syntax
图3:SIPURL语法
The URI character classes referenced above are described in Appendix C.
上面提到的URI字符类在附录C中描述。
The components of the SIP URI have the following meanings.
SIPURI的组件具有以下含义。
telephone-subscriber = global-phone-number | local-phone-number
global-phone-number = "+" 1*phonedigit [isdn-subaddress]
[post-dial]
local-phone-number = 1*(phonedigit | dtmf-digit |
pause-character) [isdn-subaddress]
[post-dial]
isdn-subaddress = ";isub=" 1*phonedigit
post-dial = ";postd=" 1*(phonedigit | dtmf-digit
| pause-character)
phonedigit = DIGIT | visual-separator
visual-separator = "-" | "."
pause-character = one-second-pause | wait-for-dial-tone
one-second-pause = "p"
wait-for-dial-tone = "w"
dtmf-digit = "*" | "#" | "A" | "B" | "C" | "D"
telephone-subscriber = global-phone-number | local-phone-number
global-phone-number = "+" 1*phonedigit [isdn-subaddress]
[post-dial]
local-phone-number = 1*(phonedigit | dtmf-digit |
pause-character) [isdn-subaddress]
[post-dial]
isdn-subaddress = ";isub=" 1*phonedigit
post-dial = ";postd=" 1*(phonedigit | dtmf-digit
| pause-character)
phonedigit = DIGIT | visual-separator
visual-separator = "-" | "."
pause-character = one-second-pause | wait-for-dial-tone
one-second-pause = "p"
wait-for-dial-tone = "w"
dtmf-digit = "*" | "#" | "A" | "B" | "C" | "D"
Figure 4: SIP URL syntax; telephone subscriber
图4:SIPURL语法；电话用户
user: If the host is an Internet telephony gateway, the user field MAY also encode a telephone number using the notation of telephone-subscriber (Fig. 4). The telephone number is a special case of a user name and cannot be distinguished by a BNF. Thus, a URL parameter, user, is added to distinguish telephone numbers from user names. The phone identifier is to be used when connecting to a telephony gateway. Even without this parameter, recipients of SIP URLs MAY interpret the pre-@ part as a phone number if local restrictions on the name space for user name allow it.
用户：如果主机是Internet电话网关，则用户字段还可以使用电话订户符号对电话号码进行编码（图4）。电话号码是用户名的特例，不能用BNF来区分。因此，添加了URL参数user，以区分电话号码和用户名。连接到电话网关时将使用电话标识符。即使没有此参数，SIP URL的收件人也可以将pre-@部分解释为电话号码，前提是用户名的名称空间受到本地限制。
password: The SIP scheme MAY use the format "user:password" in the userinfo field. The use of passwords in the userinfo 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.
密码：SIP方案可以在userinfo字段中使用格式“user:password”。不建议在userinfo中使用密码，因为在几乎所有使用过密码的情况下，以明文（如uri）形式传递身份验证信息已被证明是一种安全风险。
host: The mailto: URL and RFC 822 email addresses require that numeric host addresses ("host numbers") are enclosed in square brackets (presumably, since host names might be numeric), while host numbers without brackets are used for all other URLs. The SIP URL requires the latter form, without brackets.
主机：mailto:URL和rfc822电子邮件地址要求数字主机地址（“主机号”）用方括号括起来（大概是因为主机名可能是数字的），而没有括号的主机号用于所有其他URL。SIPURL需要后一种形式，不带括号。
The issue of IPv6 literal addresses in URLs is being looked at elsewhere in the IETF. SIP implementers are advised to keep up to date on that activity.
IETF的其他地方正在研究URL中IPv6文本地址的问题。建议SIP实施者及时了解该活动的最新情况。
port: The port number to send a request to. If not present, the procedures outlined in Section 1.4.2 are used to determine the port number to send a request to.
端口：向其发送请求的端口号。如果不存在，则使用第1.4.2节中概述的程序确定发送请求的端口号。
URL parameters: SIP URLs can define specific parameters of the request. URL parameters are added after the host component and are separated by semi-colons. The transport parameter determines the the transport mechanism (UDP or TCP). UDP is to be assumed when no explicit transport parameter is included. The maddr parameter provides the server address to be contacted for this user, overriding the address supplied in the host field. This address is typically a multicast address, but could also be the address of a backup server. 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. The user parameter was described above. For example, to specify to call j.doe@big.com using multicast to 239.255.255.1 with a ttl of 15, the following URL would be used:
URL参数：SIPURL可以定义请求的特定参数。URL参数添加在主机组件之后，并用分号分隔。transport参数确定传输机制（UDP或TCP）的优先级。当不包含显式传输参数时，将假定为UDP。maddr参数提供此用户要联系的服务器地址，覆盖主机字段中提供的地址。此地址通常是多播地址，但也可以是备份服务器的地址。ttl参数确定UDP多播数据包的生存时间值，仅当maddr是多播地址且传输协议为UDP时，才必须使用该参数。用户参数如上所述。例如，指定调用j。doe@big.com使用ttl为15的多播到239.255.255.1，将使用以下URL：
sip:j.doe@big.com;maddr=239.255.255.1;ttl=15
sip:j.doe@big.com;maddr=239.255.255.1;ttl=15
The transport, maddr, and ttl parameters MUST NOT be used in the From and To header fields and the Request-URI; they are ignored if present.
传输、maddr和ttl参数不得在From和To头字段以及请求URI中使用；如果存在，则忽略它们。
Headers: Headers of the SIP request can be defined with the "?" mechanism within a SIP URL. The special hname "body" indicates that the associated hvalue is the message-body of the SIP INVITE request. Headers MUST NOT be used in the From and To header fields and the Request-URI; they are ignored if present. hname and hvalue are encodings of a SIP header name and value, respectively. All URL reserved characters in the header names and values MUST be escaped.
头：SIP请求的头可以通过SIPURL中的“？”机制定义。特殊的hname“body”表示关联的hvalue是SIP INVITE请求的消息体。不得在“发件人”和“收件人”标头字段以及请求URI中使用标头；如果存在，则忽略它们。hname和hvalue分别是SIP头名称和值的编码。必须转义头名称和值中的所有URL保留字符。
Method: The method of the SIP request can be specified with the method parameter. This parameter MUST NOT be used in the From and To header fields and the Request-URI; they are ignored if present.
方法：可以使用Method参数指定SIP请求的方法。此参数不得用于From和To标头字段以及请求URI；如果存在，则忽略它们。
Table 2 summarizes where the components of the SIP URL can be used and what default values they assume if not present.
表2总结了SIPURL的组件可以在何处使用，以及如果不存在这些组件，它们会假定哪些默认值。
Examples of SIP URLs are:
SIP URL的示例包括：
default Req.-URI To From Contact external user -- x x x x x password -- x x x x host mandatory x x x x x port 5060 x x x x x user-param ip x x x x x method INVITE x x maddr-param -- x x ttl-param 1 x x transp.-param -- x x headers -- x x
默认请求。-URI来自联系人外部用户--x x x密码--x x x主机强制x x x端口5060 x x x x用户参数ip x x x x方法邀请x maddr参数--x ttl参数1 x传输。-param--x头文件--x x
Table 2: Use and default values of URL components for SIP headers, Request-URI and references
表2:SIP头、请求URI和引用的URL组件的使用和默认值
sip:j.doe@big.com
sip:j.doe:secret@big.com;transport=tcp
sip:j.doe@big.com?subject=project
sip:+1-212-555-1212:1234@gateway.com;user=phone
sip:1212@gateway.com
sip:alice@10.1.2.3
sip:alice@example.com
sip:alice%40example.com@gateway.com
sip:alice@registrar.com;method=REGISTER
sip:j.doe@big.com
sip:j.doe:secret@big.com;transport=tcp
sip:j.doe@big.com?subject=project
sip:+1-212-555-1212:1234@gateway.com;user=phone
sip:1212@gateway.com
sip:alice@10.1.2.3
sip:alice@example.com
sip:alice%40example.com@gateway.com
sip:alice@registrar.com;method=REGISTER
Within a SIP message, URLs are used to indicate the source and intended destination of a request, redirection addresses and the current destination of a request. Normally all these fields will contain SIP URLs.
在SIP消息中，URL用于指示请求的源和预期目的地、重定向地址和请求的当前目的地。通常，所有这些字段都将包含SIPURL。
SIP URLs are case-insensitive, so that for example the two URLs sip:j.doe@example.com and SIP:J.Doe@Example.com are equivalent. All URL parameters are included when comparing SIP URLs for equality.
SIPURL不区分大小写，因此，例如，两个URL SIP:j。doe@example.com和SIP:J。Doe@Example.com它们是等价的。在比较SIP URL是否相等时，将包括所有URL参数。
SIP header fields MAY contain non-SIP URLs. As an example, if a call from a telephone is relayed to the Internet via SIP, the SIP From header field might contain a phone URL.
SIP头字段可能包含非SIP URL。例如，如果来自电话的呼叫通过SIP中继到Internet，则SIP from标头字段可能包含电话URL。
3 SIP Message Overview
3 SIP消息概述
SIP is a text-based protocol and uses the ISO 10646 character set in UTF-8 encoding (RFC 2279 [21]). Senders MUST terminate lines with a CRLF, but receivers MUST also interpret CR and LF by themselves as line terminators.
SIP是一种基于文本的协议，在UTF-8编码（RFC 2279[21]）中使用ISO10646字符集。发送方必须使用CRLF终止线路，但接收方也必须将CR和LF本身解释为线路终止符。
Except for the above difference in character sets, much of the message syntax is and header fields are 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 2068 [11]). In addition, we describe SIP in both prose and an augmented Backus-Naur form (ABNF). See section C for an overview of ABNF.
除了上述字符集的差异外，大部分消息语法和头字段与HTTP/1.1相同；我们使用[HX.Y]来参考当前HTTP/1.1规范（RFC 2068[11]）的第X.Y节，而不是重复此处的语法和语义。此外，我们还用散文和增广的巴科斯诺尔形式（ABNF）描述了SIP。有关ABNF的概述，请参见第C节。
Note, however, that SIP is not an extension of HTTP.
但是，请注意，SIP不是HTTP的扩展。
Unlike HTTP, SIP MAY use UDP. When sent over TCP or UDP, multiple SIP transactions can be carried in a single TCP connection or UDP datagram. UDP datagrams, including all headers, SHOULD NOT be larger than the path maximum transmission unit (MTU) if the MTU is known, or 1500 bytes if the MTU is unknown.
与HTTP不同，SIP可以使用UDP。通过TCP或UDP发送时，可以在单个TCP连接或UDP数据报中承载多个SIP事务。UDP数据报，包括所有报头，如果MTU已知，则不应大于路径最大传输单位（MTU），如果MTU未知，则不应大于1500字节。
The 1500 bytes accommodates encapsulation within the "typical" ethernet MTU without IP fragmentation. Recent studies [22] indicate that an MTU of 1500 bytes is a reasonable assumption. The next lower common MTU values are 1006 bytes for SLIP and 296 for low-delay PPP (RFC 1191 [23]). Thus, another reasonable value would be a message size of 950 bytes, to accommodate packet headers within the SLIP MTU without fragmentation.
1500字节可容纳“典型”以太网MTU内的封装，无IP碎片。最近的研究[22]表明，1500字节的MTU是一个合理的假设。下一个较低的公共MTU值是1006字节的SLIP和296字节的低延迟PPP（RFC 1191[23]）。因此，另一个合理的值将是950字节的消息大小，以适应SLIP MTU内的分组报头，而不会出现碎片。
A SIP message is either a request from a client to a server, or a response from a server to a client.
SIP消息是从客户端到服务器的请求，或者是从服务器到客户端的响应。
SIP-message = Request | Response
SIP消息=请求|响应
Both Request (section 4) and Response (section 5) messages use the generic-message format of RFC 822 [24] for transferring entities (the body of the message). Both types of messages consist of a start-line, one or more header fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the carriage-return line-feed (CRLF)) indicating the end of the header fields, and an optional message-body. To avoid confusion with similar-named headers in HTTP, we refer to the headers describing the message body as entity headers. These components are described in detail in the upcoming sections.
请求（第4节）和响应（第5节）消息都使用RFC 822[24]的通用消息格式传输实体（消息正文）。这两种类型的消息都包括一个起始行、一个或多个报头字段（也称为“报头”）、一个空行（即，在回车换行符（CRLF）之前没有任何内容的行）和一个可选的消息正文。为了避免与HTTP中类似的命名头混淆，我们将描述消息体的头称为实体头。这些组件将在接下来的部分中详细描述。
generic-message = start-line *message-header
通用消息=起始行*消息头
CRLF [ message-body ]
CRLF[消息正文]
start-line = Request-Line | ;Section 4.1 Status-Line ;Section 5.1
起始行=请求行|；第4.1节状态行；第5.1节
message-header = ( general-header
| request-header
| response-header
| entity-header )
message-header = ( general-header
| request-header
| response-header
| entity-header )
In the interest of robustness, any leading empty line(s) MUST be ignored. In other words, if the Request or Response message begins with one or more CRLF, CR, or LFs, these characters MUST be ignored.
为了保证健壮性，必须忽略任何前导空行。换句话说，如果请求或响应消息以一个或多个CRLF、CR或LFs开头，则必须忽略这些字符。
4 Request
4请求
The Request message format is shown below:
请求消息格式如下所示：
Request = Request-Line ; Section 4.1 *( general-header | request-header | entity-header ) CRLF [ message-body ] ; Section 8
请求=请求行；第4.1节*（一般标题|请求标题|实体标题）CRLF[消息正文]；第8节
The Request-Line begins with a method token, followed by the Request-URI and the protocol version, and ending with CRLF. The elements are separated by SP characters. No CR or LF are allowed except in the final CRLF sequence.
请求行以方法令牌开始，然后是请求URI和协议版本，最后是CRLF。元素由SP字符分隔。除最终CRLF序列外，不允许使用CR或LF。
Request-Line = Method SP Request-URI SP SIP-Version CRLF
请求行=方法SP请求URI SP SIP版本CRLF
general-header = Accept ; Section 6.7
| Accept-Encoding ; Section 6.8
| Accept-Language ; Section 6.9
| Call-ID ; Section 6.12
| Contact ; Section 6.13
| CSeq ; Section 6.17
| Date ; Section 6.18
| Encryption ; Section 6.19
| Expires ; Section 6.20
| From ; Section 6.21
| Record-Route ; Section 6.29
| Timestamp ; Section 6.36
| To ; Section 6.37
| Via ; Section 6.40
entity-header = Content-Encoding ; Section 6.14
| Content-Length ; Section 6.15
| Content-Type ; Section 6.16
request-header = Authorization ; Section 6.11
| Contact ; Section 6.13
| Hide ; Section 6.22
| Max-Forwards ; Section 6.23
| Organization ; Section 6.24
| Priority ; Section 6.25
| Proxy-Authorization ; Section 6.27
| Proxy-Require ; Section 6.28
| Route ; Section 6.33
| Require ; Section 6.30
| Response-Key ; Section 6.31
| Subject ; Section 6.35
| User-Agent ; Section 6.39
response-header = Allow ; Section 6.10
| Proxy-Authenticate ; Section 6.26
| Retry-After ; Section 6.32
| Server ; Section 6.34
| Unsupported ; Section 6.38
| Warning ; Section 6.41
| WWW-Authenticate ; Section 6.42
general-header = Accept ; Section 6.7
| Accept-Encoding ; Section 6.8
| Accept-Language ; Section 6.9
| Call-ID ; Section 6.12
| Contact ; Section 6.13
| CSeq ; Section 6.17
| Date ; Section 6.18
| Encryption ; Section 6.19
| Expires ; Section 6.20
| From ; Section 6.21
| Record-Route ; Section 6.29
| Timestamp ; Section 6.36
| To ; Section 6.37
| Via ; Section 6.40
entity-header = Content-Encoding ; Section 6.14
| Content-Length ; Section 6.15
| Content-Type ; Section 6.16
request-header = Authorization ; Section 6.11
| Contact ; Section 6.13
| Hide ; Section 6.22
| Max-Forwards ; Section 6.23
| Organization ; Section 6.24
| Priority ; Section 6.25
| Proxy-Authorization ; Section 6.27
| Proxy-Require ; Section 6.28
| Route ; Section 6.33
| Require ; Section 6.30
| Response-Key ; Section 6.31
| Subject ; Section 6.35
| User-Agent ; Section 6.39
response-header = Allow ; Section 6.10
| Proxy-Authenticate ; Section 6.26
| Retry-After ; Section 6.32
| Server ; Section 6.34
| Unsupported ; Section 6.38
| Warning ; Section 6.41
| WWW-Authenticate ; Section 6.42
Table 3: SIP headers
表3:SIP头
The methods are defined below. Methods that are not supported by a proxy or redirect server are treated by that server as if they were an OPTIONS method and forwarded accordingly. Methods that are not
这些方法定义如下。代理服务器或重定向服务器不支持的方法将被该服务器视为选项方法，并相应地转发。不可用的方法
supported by a user agent server or registrar cause a 501 (Not Implemented) response to be returned (Section 7). As in HTTP, the Method token is case-sensitive.
由用户代理服务器或注册器支持，导致返回501（未实现）响应（第7节）。与HTTP一样，方法令牌区分大小写。
Method = "INVITE" | "ACK" | "OPTIONS" | "BYE"
| "CANCEL" | "REGISTER"
Method = "INVITE" | "ACK" | "OPTIONS" | "BYE"
| "CANCEL" | "REGISTER"
The INVITE method indicates that the user or service is being invited to participate in a session. The message body contains a description of the session to which the callee is being invited. For two-party calls, the caller indicates the type of media it is able to receive and possibly the media it is willing to send as well as their parameters such as network destination. A success response MUST indicate in its message body which media the callee wishes to receive and MAY indicate the media the callee is going to send.
INVITE方法表示正在邀请用户或服务参与会话。消息正文包含被调用方被邀请参加的会话的描述。对于两方呼叫，呼叫者指出它能够接收的媒体类型，可能是它愿意发送的媒体，以及它们的参数，如网络目的地。成功响应必须在其消息正文中指明被叫方希望接收的媒体，并可能指明被叫方将要发送的媒体。
Not all session description formats have the ability to indicate sending media.
并非所有会话描述格式都能够指示发送介质。
A server MAY automatically respond to an invitation for a conference the user is already participating in, identified either by the SIP Call-ID or a globally unique identifier within the session description, with a 200 (OK) response.
服务器可以使用200（OK）响应自动响应用户已经参与的会议的邀请，该邀请由SIP呼叫ID或会话描述中的全局唯一标识符标识。
If a user agent receives an INVITE request for an existing call leg with a higher CSeq sequence number than any previous INVITE for the same Call-ID, 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. It MUST also inspect any other header fields for changes. If there is a change, the user agent MUST update any internal state or information generated as a result of that header. If the session description has changed, the user agent server MUST adjust the session parameters accordingly, possibly after asking the user for confirmation. (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.)
如果用户代理接收到现有呼叫分支的INVITE请求，且CSeq序列号高于相同呼叫ID的任何先前INVITE，则必须检查会话描述中的任何版本标识符，如果没有版本标识符，则检查会话描述的内容，以查看其是否已更改。它还必须检查任何其他标题字段的更改。如果有更改，用户代理必须更新由于该标头而生成的任何内部状态或信息。如果会话描述已更改，则用户代理服务器必须相应地调整会话参数，可能是在请求用户确认之后。（会话描述的版本控制可用于适应新到会议、添加或删除媒体或从单播会议更改为多播会议的能力。）
This method MUST be supported by SIP proxy, redirect and user agent servers as well as clients.
SIP代理、重定向和用户代理服务器以及客户端必须支持此方法。
The ACK request confirms that the client has received a final response to an INVITE request. (ACK is used only with INVITE requests.) 2xx responses are acknowledged by client user agents, all other final responses by the first proxy or client user agent to receive the response. The Via is always initialized to the host that originates the ACK request, i.e., the client user agent after a 2xx response or the first proxy to receive a non-2xx final response. The ACK request is forwarded as the corresponding INVITE request, based on its Request-URI. See Section 10 for details.
ACK请求确认客户端已收到对INVITE请求的最终响应。（ACK仅用于INVITE请求。）2xx响应由客户端用户代理确认，所有其他最终响应由接收响应的第一个代理或客户端用户代理确认。Via始终初始化为发起ACK请求的主机，即2xx响应后的客户端用户代理或接收非2xx最终响应的第一个代理。ACK请求根据其请求URI作为相应的INVITE请求转发。详见第10节。
The ACK request MAY contain a message body with the final session description to be used by the callee. If the ACK message body is empty, the callee uses the session description in the INVITE request.
ACK请求可以包含具有被呼叫方使用的最终会话描述的消息正文。如果ACK消息正文为空，则被调用方在INVITE请求中使用会话描述。
A proxy server receiving an ACK request after having sent a 3xx, 4xx, 5xx, or 6xx response must make a determination about whether the ACK is for it, or for some user agent or proxy server further downstream. This determination is made by examining the tag in the To field. If the tag in the ACK To header field matches the tag in the To header field of the response, and the From, CSeq and Call-ID header fields in the response match those in the ACK, the ACK is meant for the proxy server. Otherwise, the ACK SHOULD be proxied downstream as any other request.
在发送3xx、4xx、5xx或6xx响应后接收ACK请求的代理服务器必须确定ACK是针对它，还是针对更下游的某个用户代理或代理服务器。通过检查“收件人”字段中的标签来确定。如果ACK To header字段中的标记与响应的To header字段中的标记匹配，并且响应中的From、CSeq和Call ID header字段与ACK中的字段匹配，则ACK用于代理服务器。否则，ACK应该作为任何其他请求被代理到下游。
It is possible for a user agent client or proxy server to receive multiple 3xx, 4xx, 5xx, and 6xx responses to a request along a single branch. This can happen under various error conditions, typically when a forking proxy transitions from stateful to stateless before receiving all responses. The various responses will all be identical, except for the tag in the To field, which is different for each one. It can therefore be used as a means to disambiguate them.
用户代理客户端或代理服务器可以沿单个分支接收对请求的多个3xx、4xx、5xx和6xx响应。这可能发生在各种错误条件下，通常是当分叉代理在接收所有响应之前从有状态转换为无状态时。各种响应都是相同的，除了To字段中的标记，每个响应都不同。因此，它可以作为消除歧义的一种手段。
This method MUST be supported by SIP proxy, redirect and user agent servers as well as clients.
SIP代理、重定向和用户代理服务器以及客户端必须支持此方法。
The server is being queried as to its capabilities. A server that believes it can contact the user, such as a user agent where the user is logged in and has been recently active, MAY respond to this request with a capability set. A called user agent MAY return a status reflecting how it would have responded to an invitation, e.g.,
正在查询服务器的功能。相信自己可以联系用户的服务器（例如用户登录且最近处于活动状态的用户代理）可以使用功能集响应此请求。被调用的用户代理可能返回反映其将如何响应邀请的状态，例如。，
600 (Busy). Such a server SHOULD return an Allow header field indicating the methods that it supports. Proxy and redirect servers simply forward the request without indicating their capabilities.
600（忙）。这样的服务器应该返回一个Allow header字段，指示它支持的方法。代理服务器和重定向服务器只是转发请求，而不显示它们的功能。
This method MUST be supported by SIP proxy, redirect and user agent servers, registrars and clients.
SIP代理、重定向和用户代理服务器、注册器和客户端必须支持此方法。
The user agent client uses BYE to indicate to the server that it wishes to release the call. A BYE request is forwarded like an INVITE request and MAY be issued by either caller or callee. A party to a call SHOULD issue a BYE request before releasing a call ("hanging up"). A party receiving a BYE request MUST cease transmitting media streams specifically directed at the party issuing the BYE request.
用户代理客户端使用BYE向服务器指示它希望释放呼叫。BYE请求像INVITE请求一样被转发，可以由呼叫者或被呼叫者发出。通话一方应在释放通话前发出BYE请求（“挂断”）。接收BYE请求的一方必须停止发送专门针对发出BYE请求的一方的媒体流。
If the INVITE request contained a Contact header, the callee SHOULD send a BYE request to that address rather than the From address.
如果INVITE请求包含联系人标头，则被叫方应向该地址而不是发件人地址发送BYE请求。
This method MUST be supported by proxy servers and SHOULD be supported by redirect and user agent SIP servers.
代理服务器必须支持此方法，重定向和用户代理SIP服务器也应支持此方法。
The CANCEL request cancels a pending request with the same Call-ID, To, From and CSeq (sequence number only) header field values, but does not affect a completed request. (A request is considered completed if the server has returned a final status response.)
取消请求取消具有相同呼叫ID、To、From和CSeq（仅序列号）头字段值的挂起请求，但不影响已完成的请求。（如果服务器已返回最终状态响应，则认为请求已完成。）
A user agent client or proxy client MAY issue a CANCEL request at any time. A proxy, in particular, MAY choose to send a CANCEL to destinations that have not yet returned a final response after it has received a 2xx or 6xx response for one or more of the parallel-search requests. A proxy that receives a CANCEL request forwards the request to all destinations with pending requests.
用户代理客户端或代理客户端可随时发出取消请求。特别是，代理在收到一个或多个并行搜索请求的2xx或6xx响应后，可以选择向尚未返回最终响应的目的地发送取消。接收取消请求的代理将请求转发到所有具有挂起请求的目标。
The Call-ID, To, the numeric part of CSeq and From headers in the CANCEL request are identical to those in the original request. This allows a CANCEL request to be matched with the request it cancels. However, to allow the client to distinguish responses to the CANCEL from those to the original request, the CSeq Method component is set to CANCEL. The Via header field is initialized to the proxy issuing the CANCEL request. (Thus, responses to this CANCEL request only reach the issuing proxy.)
CANCEL请求中的调用ID、To、CSeq和From头的数字部分与原始请求中的相同。这允许取消请求与其取消的请求相匹配。但是，为了允许客户端区分对取消的响应和对原始请求的响应，CSeq方法组件被设置为CANCEL。Via标头字段初始化为发出取消请求的代理。（因此，对此取消请求的响应仅到达发出请求的代理。）
Once a user agent server has received a CANCEL, it MUST NOT issue a 2xx response for the cancelled original request.
一旦用户代理服务器收到取消，它就不能对取消的原始请求发出2xx响应。
A redirect or user agent server receiving a CANCEL request responds with a status of 200 (OK) if the transaction exists and a status of 481 (Transaction Does Not Exist) if not, but takes no further action. In particular, any existing call is unaffected.
如果事务存在，接收取消请求的重定向或用户代理服务器将以200（确定）的状态响应，如果不存在，则以481（事务不存在）的状态响应，但不采取进一步的操作。特别是，任何现有呼叫都不受影响。
The BYE request cannot be used to cancel branches of a parallel search, since several branches may, through intermediate proxies, find the same user agent server and then terminate the call. To terminate a call instead of just pending searches, the UAC must use BYE instead of or in addition to CANCEL. While CANCEL can terminate any pending request other than ACK or CANCEL, it is typically useful only for INVITE. 200 responses to INVITE and 200 responses to CANCEL are distinguished by the method in the Cseq header field, so there is no ambiguity.
BYE请求不能用于取消并行搜索的分支，因为几个分支可以通过中间代理找到同一个用户代理服务器，然后终止调用。要终止呼叫而不仅仅是挂起的搜索，UAC必须使用BYE而不是CANCEL或CANCEL。虽然CANCEL可以终止除ACK或CANCEL之外的任何挂起请求，但它通常仅对INVITE有用。通过Cseq头字段中的方法区分200个INVITE响应和200个CANCEL响应，因此没有歧义。
This method MUST be supported by proxy servers and SHOULD be supported by all other SIP server types.
代理服务器必须支持此方法，并且所有其他SIP服务器类型都应支持此方法。
A client uses the REGISTER method to register the address listed in the To header field with a SIP server.
客户端使用REGISTER方法向SIP服务器注册to标头字段中列出的地址。
A user agent MAY register with a local server on startup by sending a REGISTER request to the well-known "all SIP servers" multicast address "sip.mcast.net" (224.0.1.75). This request SHOULD be scoped to ensure it is not forwarded beyond the boundaries of the administrative system. This MAY be done with either TTL or administrative scopes [25], depending on what is implemented in the network. SIP user agents MAY listen to that address and use it to become aware of the location of other local users [20]; however, they do not respond to the request. A user agent MAY also be configured with the address of a registrar server to which it sends a REGISTER request upon startup.
用户代理可以在启动时通过向众所周知的“所有SIP服务器”多播地址“SIP.mcast.net”（224.0.1.75）发送注册请求向本地服务器注册。此请求的范围应确保其转发不超出管理系统的边界。这可以通过TTL或管理作用域[25]实现，具体取决于网络中实现的内容。SIP用户代理可以监听该地址并使用它来了解其他本地用户的位置[20]；但是，他们没有对请求作出回应。用户代理还可以配置有注册服务器的地址，该注册服务器在启动时向其发送注册请求。
Requests are processed in the order received. Clients SHOULD avoid sending a new registration (as opposed to a retransmission) until they have received the response from the server for the previous one.
请求按收到的顺序进行处理。客户端应避免发送新的注册（而不是重新传输），直到收到服务器对上一个注册的响应。
Clients may register from different locations, by necessity using different Call-ID values. Thus, the CSeq value cannot be used to enforce ordering. Since registrations are additive, ordering is less of a problem than if each REGISTER request completely replaced all earlier ones.
客户端可以从不同的位置注册，必要时使用不同的调用ID值。因此，CSeq值不能用于强制排序。由于注册是累加的，所以排序问题比每个注册请求完全替换所有以前的注册请求的问题要小。
The meaning of the REGISTER request-header fields is defined as follows. We define "address-of-record" as the SIP address that the registry knows the registrand, typically of the form "user@domain" rather than "user@host". In third-party registration, the entity issuing the request is different from the entity being registered.
寄存器请求头字段的含义定义如下。我们将“记录地址”定义为注册中心知道的注册人的SIP地址，通常为user@domain“而不是”user@host". 在第三方注册中，发出请求的实体与正在注册的实体不同。
To: The To header field contains the address-of-record whose registration is to be created or updated.
收件人：收件人标题字段包含要创建或更新其注册的记录的地址。
From: The From header field contains the address-of-record of the person responsible for the registration. For first-party registration, it is identical to the To header field value.
发件人：发件人标题字段包含负责注册的人员的记录地址。对于第一方注册，它与“收件人标头”字段值相同。
Request-URI: The Request-URI names the destination of the registration request, i.e., the domain of the registrar. The user name MUST be empty. Generally, the domains in the Request-URI and the To header field have the same value; however, it is possible to register as a "visitor", while maintaining one's name. For example, a traveler sip:alice@acme.com (To) might register under the Request-URI sip:atlanta.hiayh.org , with the former as the To header field and the latter as the Request-URI. The REGISTER request is no longer forwarded once it has reached the server whose authoritative domain is the one listed in the Request-URI.
请求URI：请求URI命名注册请求的目的地，即注册者的域。用户名必须为空。通常，请求URI和To头字段中的域具有相同的值；但是，可以注册为“访客”，同时保留自己的姓名。例如，旅行者sip：alice@acme.com（To）可以在请求URI sip:atlanta.hiayh.org下注册，前者作为To头字段，后者作为请求URI。一旦注册请求到达服务器（其权威域是请求URI中列出的域），它就不再被转发。
Call-ID: All registrations from a client SHOULD use the same Call-ID header value, at least within the same reboot cycle.
调用ID：来自客户端的所有注册应使用相同的调用ID头值，至少在相同的重新启动周期内。
Cseq: Registrations with the same Call-ID MUST have increasing CSeq header values. However, the server does not reject out-of-order requests.
Cseq：具有相同呼叫ID的注册必须具有递增的Cseq头值。但是，服务器不会拒绝无序请求。
Contact: The request MAY contain a Contact header field; future non-REGISTER requests for the URI given in the To header field SHOULD be directed to the address(es) given in the Contact header.
联系人：请求可能包含联系人标头字段；对于To标头字段中给定的URI的未来非注册请求应定向到Contact标头中给定的地址。
If the request does not contain a Contact header, the registration remains unchanged.
如果请求不包含联系人标头，则注册保持不变。
This is useful to obtain the current list of registrations in the response. Registrations using SIP URIs that differ in one or more of host, port, transport-param or maddr-param (see Figure 3) from an existing registration are added to the list of registrations. Other URI types are compared according to the standard URI equivalency rules for the URI schema. If the URIs are equivalent to that of an existing registration, the new registration replaces the
这对于获取响应中的当前注册列表非常有用。使用SIPURI的注册与现有注册在主机、端口、传输参数或maddr参数（见图3）中的一个或多个方面不同，将添加到注册列表中。其他URI类型根据URI模式的标准URI等效规则进行比较。如果URI等同于现有注册的URI，则新注册将替换
old one if it has a higher q value or, for the same value of q, if the ttl value is higher. All current registrations MUST share the same action value. Registrations that have a different action than current registrations for the same user MUST be rejected with status of 409 (Conflict).
如果q值较高，或对于相同的q值，如果ttl值较高，则为旧的。所有当前注册必须共享相同的操作值。与同一用户的当前注册具有不同操作的注册必须被拒绝，状态为409（冲突）。
A proxy server ignores the q parameter when processing non-REGISTER requests, while a redirect server simply returns that parameter in its Contact response header field.
代理服务器在处理非注册请求时忽略q参数，而重定向服务器只是在其联系人响应头字段中返回该参数。
Having the proxy server interpret the q parameter is not sufficient to guide proxy behavior, as it is not clear, for example, how long it is supposed to wait between trying addresses.
让代理服务器解释q参数不足以指导代理行为，因为它不清楚，例如，在尝试地址之间应该等待多长时间。
If the registration is changed while a user agent or proxy server processes an invitation, the new information SHOULD be used.
如果在用户代理或代理服务器处理邀请时更改了注册，则应使用新信息。
This allows a service known as "directed pick-up". In the telephone network, directed pickup permits a user at a remote station who hears his own phone ringing to pick up at that station, dial an access code, and be connected to the calling user as if he had answered his own phone.
这允许一种称为“定向提货”的服务。在电话网络中，定向接听允许远程站的用户在听到自己的电话铃声时在该站接听电话，拨打接入码，并连接到呼叫用户，就好像他接听了自己的电话一样。
A server MAY choose any duration for the registration lifetime. Registrations not refreshed after this amount of time SHOULD be silently discarded. Responses to a registration SHOULD include an Expires header (Section 6.20) or expires Contact parameters (Section 6.13), indicating the time at which the server will drop the registration. If none is present, one hour is assumed. Clients MAY request a registration lifetime by indicating the time in an Expires header in the request. A server SHOULD NOT use a higher lifetime than the one requested, but MAY use a lower one. A single address (if host-independent) MAY be registered from several different clients.
服务器可以选择注册生存期的任何持续时间。在这段时间后未刷新的注册应被静默放弃。对注册的响应应包括Expires标头（第6.20节）或Expires联系人参数（第6.13节），指示服务器将放弃注册的时间。如果不存在，则假定为一小时。客户端可以通过在请求的Expires头中指示时间来请求注册生存期。服务器使用的生存期不应高于请求的生存期，但可以使用较低的生存期。可以从多个不同的客户端注册单个地址（如果独立于主机）。
A client cancels an existing registration by sending a REGISTER request with an expiration time (Expires) of zero seconds for a particular Contact or the wildcard Contact designated by a "*" for all registrations. Registrations are matched based on the user, host, port and maddr parameters.
客户机通过发送一个注册请求来取消现有的注册，该注册请求的过期时间（Expires）为零秒，对于特定联系人或所有注册，由“*”指定的通配符联系人。根据用户、主机、端口和maddr参数匹配注册。
The server SHOULD return the current list of registrations in the 200 response as Contact header fields.
服务器应将200响应中的当前注册列表作为联系人标头字段返回。
It is particularly important that REGISTER requests are authenticated since they allow to redirect future requests (see Section 13.2).
对注册请求进行身份验证尤其重要，因为它们允许重定向未来的请求（见第13.2节）。
Beyond its use as a simple location service, this method is needed if there are several SIP servers on a single host. In that case, only one of the servers can use the default port number.
除了用作简单的位置服务外，如果一台主机上有多个SIP服务器，则需要此方法。在这种情况下，只有一台服务器可以使用默认端口号。
Support of this method is RECOMMENDED.
建议支持此方法。
The Request-URI is a SIP URL as described in Section 2 or a general URI. It indicates the user or service to which this request is being addressed. Unlike the To field, the Request-URI MAY be re-written by proxies.
请求URI是第2节中描述的SIPURL或通用URI。它指示此请求所针对的用户或服务。与To字段不同，请求URI可以由代理重新写入。
When used as a Request-URI, a SIP-URL MUST NOT contain the transport-param, maddr-param, ttl-param, or headers elements. A server that receives a SIP-URL with these elements removes them before further processing.
当用作请求URI时，SIP-URL不得包含传输参数、maddr参数、ttl参数或标头元素。接收包含这些元素的SIP-URL的服务器将在进一步处理之前删除这些元素。
Typically, the UAC sets the Request-URI and To to the same SIP URL, presumed to remain unchanged over long time periods. However, if the UAC has cached a more direct path to the callee, e.g., from the Contact header field of a response to a previous request, the To would still contain the long-term, "public" address, while the Request-URI would be set to the cached address.
通常，UAC将请求URI和To设置为相同的SIP URL，假定长时间内保持不变。然而，如果UAC缓存了到被调用方的更直接的路径，例如，从对先前请求的响应的联系人头部字段，则to将仍然包含长期“公共”地址，而请求URI将被设置为缓存地址。
Proxy and redirect servers MAY use the information in the Request-URI and request header fields to handle the request and possibly rewrite the Request-URI. For example, a request addressed to the generic address sip:sales@acme.com is proxied to the particular person, e.g., sip:bob@ny.acme.com , with the To field remaining as sip:sales@acme.com. At ny.acme.com , Bob then designates Alice as the temporary substitute.
代理服务器和重定向服务器可以使用请求URI和请求头字段中的信息来处理请求，并可能重写请求URI。例如，发往通用地址sip的请求：sales@acme.com代表特定人员，例如sip：bob@ny.acme.com，To字段保留为sip：sales@acme.com. 在ny.acme.com，Bob随后指定Alice作为临时替代者。
The host part of the Request-URI typically agrees with one of the host names of the receiving server. If it does not, the server SHOULD proxy the request to the address indicated or return a 404 (Not Found) response if it is unwilling or unable to do so. For example, the Request-URI and server host name can disagree in the case of a firewall proxy that handles outgoing calls. This mode of operation is similar to that of HTTP proxies.
请求URI的主机部分通常与接收服务器的主机名之一一致。如果没有，服务器应将请求代理到指定的地址，或者如果不愿意或无法这样做，则返回404（未找到）响应。例如，对于处理传出呼叫的防火墙代理，请求URI和服务器主机名可能不一致。此操作模式类似于HTTP代理的操作模式。
If a SIP server receives a request with a URI indicating a scheme other than SIP which that server does not understand, the server MUST return a 400 (Bad Request) response. It MUST do this even if the To
如果SIP服务器接收到一个URI指示该服务器不理解的SIP以外的方案的请求，则该服务器必须返回400（错误请求）响应。它必须这样做，即使
header field contains a scheme it does understand. This is because proxies are responsible for processing the Request-URI; the To field is of end-to-end significance.
header字段包含一个它不理解的方案。这是因为代理负责处理请求URI；To字段具有端到端的重要性。
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".
请求和响应消息都包括正在使用的SIP版本，并遵循[H3.1]（HTTP替换为SIP，HTTP/1.1替换为SIP/2.0）中有关版本排序、合规性要求和版本号升级的规定。为了符合本规范，发送SIP消息的应用程序必须包括SIP版本的“SIP/2.0”。
Option tags are unique identifiers used to designate new options in SIP. These tags are used in Require (Section 6.30) and Unsupported (Section 6.38) fields.
选项标记是用于在SIP中指定新选项的唯一标识符。这些标签用于Require（第6.30节）和Unsupported（第6.38节）字段。
Syntax:
语法：
option-tag = token
option-tag = token
See Section C for a definition of token. The creator of a new SIP option MUST either prefix the option with their reverse domain name or register the new option with the Internet Assigned Numbers Authority (IANA). For example, "com.foo.mynewfeature" is an apt name for a feature whose inventor can be reached at "foo.com". Individual organizations are then responsible for ensuring that option names don't collide. Options registered with IANA have the prefix "org.iana.sip.", options described in RFCs have the prefix "org.ietf.rfc.N", where N is the RFC number. Option tags are case-insensitive.
有关令牌的定义，请参见第C节。新SIP选项的创建者必须以其反向域名作为该选项的前缀，或向互联网分配号码管理局（IANA）注册新选项。例如，“com.foo.mynewfeature”是一个功能的恰当名称，可以通过“foo.com”联系到该功能的发明人。然后，各个组织负责确保选项名称不会发生冲突。在IANA注册的选项具有前缀“org.IANA.sip.”，RFCs中描述的选项具有前缀“org.ietf.rfc.N”，其中N是rfc编号。选项标记不区分大小写。
When registering a new SIP option, the following information MUST be provided:
注册新SIP选项时，必须提供以下信息：
o Name and description of option. The name MAY be of any length, but SHOULD be no more than twenty characters long. The name MUST consist of alphanum (See Figure 3) characters only;
o 选项的名称和说明。名称可以是任意长度，但长度不得超过二十个字符。名称必须仅由alphanum（见图3）字符组成；
o Indication of who has change control over the option (for example, IETF, ISO, ITU-T, other international standardization bodies, a consortium or a particular company or group of companies);
o 说明谁对该方案具有变更控制权（例如，IETF、ISO、ITU-T、其他国际标准化机构、联合体或特定公司或公司集团）；
o A reference to a further description, if available, for example (in order of preference) an RFC, a published paper, a patent filing, a technical report, documented source code or a computer manual;
o 参考进一步的描述（如有），例如（按优先顺序）RFC、已发表论文、专利申请、技术报告、记录的源代码或计算机手册；
o Contact information (postal and email address);
o 联系信息（邮政和电子邮件地址）；
Registrations should be sent to iana@iana.org
注册应发送至iana@iana.org
This procedure has been borrowed from RTSP [4] and the RTP AVP [26].
本程序借鉴了RTSP[4]和RTP AVP[26]。
5 Response
5答复
After receiving and interpreting a request message, the recipient responds with a SIP response message. The response message format is shown below:
在接收并解释请求消息之后，接收者用SIP响应消息进行响应。响应消息格式如下所示：
Response = Status-Line ; Section 5.1 *( general-header | response-header | entity-header ) CRLF [ message-body ] ; Section 8
响应=状态行；第5.1节*（一般标题|响应标题|实体标题）CRLF[消息正文]；第8节
SIP's structure of responses is similar to [H6], but is defined explicitly here.
SIP的响应结构与[H6]类似，但在此处明确定义。
The first line of a Response message is the Status-Line, consisting of the protocol version (Section 4.3.1) followed by a numeric Status-Code and its associated textual phrase, with each element separated by SP characters. No CR or LF is allowed except in the final CRLF sequence.
响应消息的第一行是状态行，由协议版本（第4.3.1节）和数字状态代码及其相关文本短语组成，每个元素由SP字符分隔。除最终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 the attempt to understand and satisfy the 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. The client is not required to examine or display the Reason-Phrase.
状态代码是一个3位整数结果代码，表示尝试理解和满足请求的结果。原因短语旨在对状态代码进行简短的文本描述。状态代码用于自动机，而原因短语用于人类用户。客户端不需要检查或显示原因短语。
Status-Code = Informational ;Fig. 5
| Success ;Fig. 5
| Redirection ;Fig. 6
| Client-Error ;Fig. 7
| Server-Error ;Fig. 8
| Global-Failure ;Fig. 9
| extension-code
extension-code = 3DIGIT
Reason-Phrase = *<TEXT-UTF8, excluding CR, LF>
Status-Code = Informational ;Fig. 5
| Success ;Fig. 5
| Redirection ;Fig. 6
| Client-Error ;Fig. 7
| Server-Error ;Fig. 8
| Global-Failure ;Fig. 9
| extension-code
extension-code = 3DIGIT
Reason-Phrase = *<TEXT-UTF8, excluding CR, LF>
We provide an overview of the Status-Code below, and provide full definitions in Section 7. The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. SIP/2.0 allows 6 values for the first digit:
我们在下面概述了状态代码，并在第7节中提供了完整的定义。状态代码的第一位数字定义了响应的类别。最后两位数字没有任何分类角色。SIP/2.0允许第一个数字有6个值：
1xx: Informational -- 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:全局失败--无法在任何服务器上满足请求。
Figures 5 through 9 present the individual values of the numeric response codes, and an example set of corresponding reason phrases for SIP/2.0. These reason phrases are only recommended; they may be replaced by local equivalents without affecting the protocol. Note
图5至图9显示了数字响应代码的各个值，以及SIP/2.0对应原因短语的示例集。仅推荐使用这些原因短语；它们可以在不影响协议的情况下由本地等效物替换。笔记
that SIP adopts many HTTP/1.1 response codes. SIP/2.0 adds response codes in the range starting at x80 to avoid conflicts with newly defined HTTP response codes, and adds a new class, 6xx, of response codes.
该SIP采用了许多HTTP/1.1响应代码。SIP/2.0添加了从x80开始的范围内的响应代码，以避免与新定义的HTTP响应代码冲突，并添加了一个新的响应代码类6xx。
SIP response codes are extensible. SIP applications are not required to understand the meaning of all registered response codes, though such understanding is obviously desirable. However, applications MUST understand the class of any response code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 response code of that class, with the exception that an unrecognized response MUST NOT be cached. For example, if a client 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. In such cases, user agents SHOULD present to the user the message body returned with the response, since that message body is likely to include human-readable information which will explain the unusual status.
SIP响应代码是可扩展的。SIP应用程序不需要理解所有注册响应代码的含义，尽管这种理解显然是可取的。但是，应用程序必须理解任何响应代码的类别（如第一位数字所示），并将任何未识别的响应视为等同于该类别的x00响应代码，但不能缓存未识别的响应除外。例如，如果客户端接收到无法识别的响应代码431，它可以安全地假设其请求有问题，并将响应视为收到400（错误请求）响应代码。在这种情况下，用户代理应该向用户呈现随响应返回的消息体，因为该消息体可能包括将解释异常状态的人类可读信息。
Informational = "100" ; Trying
| "180" ; Ringing
| "181" ; Call Is Being Forwarded
| "182" ; Queued
Success = "200" ; OK
Informational = "100" ; Trying
| "180" ; Ringing
| "181" ; Call Is Being Forwarded
| "182" ; Queued
Success = "200" ; OK
Figure 5: Informational and success status codes
图5：信息和成功状态代码
Redirection = "300" ; Multiple Choices
| "301" ; Moved Permanently
| "302" ; Moved Temporarily
| "303" ; See Other
| "305" ; Use Proxy
| "380" ; Alternative Service
Redirection = "300" ; Multiple Choices
| "301" ; Moved Permanently
| "302" ; Moved Temporarily
| "303" ; See Other
| "305" ; Use Proxy
| "380" ; Alternative Service
Figure 6: Redirection status codes
图6：重定向状态代码
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
| "409" ; Conflict
| "410" ; Gone
| "411" ; Length Required
| "413" ; Request Entity Too Large
| "414" ; Request-URI Too Large
| "415" ; Unsupported Media Type
| "420" ; Bad Extension
| "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
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
| "409" ; Conflict
| "410" ; Gone
| "411" ; Length Required
| "413" ; Request Entity Too Large
| "414" ; Request-URI Too Large
| "415" ; Unsupported Media Type
| "420" ; Bad Extension
| "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
Figure 7: Client error status codes
图7：客户端错误状态代码
Server-Error = "500" ; Internal Server Error
| "501" ; Not Implemented
| "502" ; Bad Gateway
| "503" ; Service Unavailable
| "504" ; Gateway Time-out
| "505" ; SIP Version not supported
Server-Error = "500" ; Internal Server Error
| "501" ; Not Implemented
| "502" ; Bad Gateway
| "503" ; Service Unavailable
| "504" ; Gateway Time-out
| "505" ; SIP Version not supported
Figure 8: Server error status codes
图8：服务器错误状态代码
6 Header Field Definitions
6标题字段定义
SIP header fields are similar to HTTP header fields in both syntax and semantics. In particular, SIP header fields follow the syntax for message-header as described in [H4.2]. The rules for extending header fields over multiple lines, and use of multiple message-header fields with the same field-name, described in [H4.2] also apply to SIP. The
SIP头字段在语法和语义上与HTTP头字段类似。特别是，SIP头字段遵循[H4.2]中描述的消息头语法。[H4.2]中描述的将头字段扩展到多行以及使用具有相同字段名的多个消息头字段的规则也适用于SIP。这个
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
Figure 9: Global failure status codes
图9：全局故障状态代码
rules in [H4.2] regarding ordering of header fields apply to SIP, with the exception of Via fields, see below, whose order matters. Additionally, header fields which are hop-by-hop MUST appear before any header fields which are end-to-end. Proxies SHOULD NOT reorder header fields. Proxies add Via header fields and MAY add other hop-by-hop header fields. They can modify certain header fields, such as Max-Forwards (Section 6.23) and "fix up" the Via header fields with "received" parameters as described in Section 6.40.1. Proxies MUST NOT alter any fields that are authenticated (see Section 13.2).
[H4.2]中关于标题字段顺序的规则适用于SIP，但Via字段除外，见下文，其顺序很重要。此外，逐跳的标头字段必须显示在端到端的任何标头字段之前。代理不应重新排序标题字段。代理通过头字段添加，也可以添加其他逐跳头字段。他们可以修改某些报头字段，如最大转发（第6.23节）和使用第6.40.1节所述的“已接收”参数“修复”Via报头字段。代理不得更改任何经过身份验证的字段（见第13.2节）。
The header fields required, optional and not applicable for each method are listed in Table 4 and Table 5. The table uses "o" to indicate optional, "m" mandatory and "-" for not applicable. A "*" indicates that the header fields are needed only if message body is not empty. See sections 6.15, 6.16 and 8 for details.
表4和表5列出了每种方法所需、可选和不适用的标题字段。该表使用“o”表示可选，“m”表示强制，“-”表示不适用。“*”表示仅当消息正文不为空时才需要标头字段。详见第6.15、6.16和8节。
The "where" column describes the request and response types with which the header field can be used. "R" refers to header fields that can be used in requests (that is, request and general header fields). "r" designates a response or general-header field as applicable to all responses, while a list of numeric values indicates the status codes with which the header field can be used. "g" and "e" designate general (Section 6.1) and entity header (Section 6.2) fields, respectively. If a header field is marked "c", it is copied from the request to the response.
“where”列描述了头字段可用于的请求和响应类型。“R”是指可以在请求中使用的头字段（即请求和常规头字段）。“r”表示适用于所有响应的响应或一般标题字段，而数值列表表示可以使用标题字段的状态代码。“g”和“e”分别表示一般字段（第6.1节）和实体标题字段（第6.2节）。如果标题字段标记为“c”，则会将其从请求复制到响应。
The "enc." column describes whether this message header field MAY be encrypted end-to-end. A "n" designates fields that MUST NOT be encrypted, while "c" designates fields that SHOULD be encrypted if encryption is used.
“enc.”列描述此消息头字段是否可以端到端加密。“n”表示不能加密的字段，“c”表示使用加密时应加密的字段。
The "e-e" column has a value of "e" for end-to-end and a value of "h" for hop-by-hop header fields.
“e-e”列的端到端值为“e”，逐跳标头字段值为“h”。
where enc. e-e ACK BYE CAN INV OPT REG
__________________________________________________________
Accept R e - - - o o o
Accept 415 e - - - o o o
Accept-Encoding R e - - - o o o
Accept-Encoding 415 e - - - o o o
Accept-Language R e - o o o o o
Accept-Language 415 e - o o o o o
Allow 200 e - - - - m -
Allow 405 e o o o o o o
Authorization R e o o o o o o
Call-ID gc n e m m m m m m
Contact R e o - - o o o
Contact 1xx e - - - o o -
Contact 2xx e - - - o o o
Contact 3xx e - o - o o o
Contact 485 e - o - o o o
Content-Encoding e e o - - o o o
Content-Length e e o - - o o o
Content-Type e e * - - * * *
CSeq gc n e m m m m m m
Date g e o o o o o o
Encryption g n e o o o o o o
Expires g e - - - o - o
From gc n e m m m m m m
Hide R n h o o o o o o
Max-Forwards R n e o o o o o o
Organization g c h - - - o o o
where enc. e-e ACK BYE CAN INV OPT REG
__________________________________________________________
Accept R e - - - o o o
Accept 415 e - - - o o o
Accept-Encoding R e - - - o o o
Accept-Encoding 415 e - - - o o o
Accept-Language R e - o o o o o
Accept-Language 415 e - o o o o o
Allow 200 e - - - - m -
Allow 405 e o o o o o o
Authorization R e o o o o o o
Call-ID gc n e m m m m m m
Contact R e o - - o o o
Contact 1xx e - - - o o -
Contact 2xx e - - - o o o
Contact 3xx e - o - o o o
Contact 485 e - o - o o o
Content-Encoding e e o - - o o o
Content-Length e e o - - o o o
Content-Type e e * - - * * *
CSeq gc n e m m m m m m
Date g e o o o o o o
Encryption g n e o o o o o o
Expires g e - - - o - o
From gc n e m m m m m m
Hide R n h o o o o o o
Max-Forwards R n e o o o o o o
Organization g c h - - - o o o
Table 4: Summary of header fields, A--O
表4：标题字段摘要，A--O
Other header fields can be added as required; a server MUST ignore header fields not defined in this specification that it does not understand. A proxy MUST NOT remove or modify header fields not defined in this specification that it does not understand. A compact form of these header fields is also defined in Section 9 for use over UDP when the request has to fit into a single packet and size is an issue.
可根据需要添加其他表头字段；服务器必须忽略本规范中未定义的、它不理解的头字段。代理不得删除或修改未在本规范中定义且其不理解的标题字段。第9节还定义了这些头字段的紧凑形式，以便在请求必须装入单个数据包且大小存在问题时通过UDP使用。
Table 6 in Appendix A lists those header fields that different client and server types MUST be able to parse.
附录A中的表6列出了不同客户端和服务器类型必须能够解析的头字段。
General header fields apply to both request and response messages. The "general-header" field names can be extended reliably only in combination with a change in the protocol version. However, new or
常规标头字段同时适用于请求和响应消息。“general header”字段名只有在协议版本发生变化的情况下才能可靠地扩展。然而，新的或
where enc. e-e ACK BYE CAN INV OPT REG
___________________________________________________________________
Proxy-Authenticate 407 n h o o o o o o
Proxy-Authorization R n h o o o o o o
Proxy-Require R n h o o o o o o
Priority R c e - - - o - -
Require R e o o o o o o
Retry-After R c e - - - - - o
Retry-After 404,480,486 c e o o o o o o
503 c e o o o o o o
600,603 c e o o o o o o
Response-Key R c e - o o o o o
Record-Route R h o o o o o o
Record-Route 2xx h o o o o o o
Route R h o o o o o o
Server r c e o o o o o o
Subject R c e - - - o - -
Timestamp g e o o o o o o
To gc(1) n e m m m m m m
Unsupported 420 e o o o o o o
User-Agent g c e o o o o o o
Via gc(2) n e m m m m m m
Warning r e o o o o o o
WWW-Authenticate 401 c e o o o o o o
where enc. e-e ACK BYE CAN INV OPT REG
___________________________________________________________________
Proxy-Authenticate 407 n h o o o o o o
Proxy-Authorization R n h o o o o o o
Proxy-Require R n h o o o o o o
Priority R c e - - - o - -
Require R e o o o o o o
Retry-After R c e - - - - - o
Retry-After 404,480,486 c e o o o o o o
503 c e o o o o o o
600,603 c e o o o o o o
Response-Key R c e - o o o o o
Record-Route R h o o o o o o
Record-Route 2xx h o o o o o o
Route R h o o o o o o
Server r c e o o o o o o
Subject R c e - - - o - -
Timestamp g e o o o o o o
To gc(1) n e m m m m m m
Unsupported 420 e o o o o o o
User-Agent g c e o o o o o o
Via gc(2) n e m m m m m m
Warning r e o o o o o o
WWW-Authenticate 401 c e o o o o o o
Table 5: Summary of header fields, P--Z; (1): copied with possible
addition of tag; (2): UAS removes first Via header field
Table 5: Summary of header fields, P--Z; (1): copied with possible
addition of tag; (2): UAS removes first Via header field
experimental header fields MAY be given the semantics of general header fields if all parties in the communication recognize them to be "general-header" fields. Unrecognized header fields are treated as "entity-header" fields.
如果通信中的所有各方都将实验头字段识别为“一般头”字段，则可以为实验头字段赋予一般头字段的语义。无法识别的标题字段被视为“实体标题”字段。
The "entity-header" fields define meta-information about the message-body or, if no body is present, about the resource identified by the request. The term "entity header" is an HTTP 1.1 term where the response body can contain a transformed version of the message body. The original message body is referred to as the "entity". We retain the same terminology for header fields but usually refer to the "message body" rather then the entity as the two are the same in SIP.
“entity header”字段定义关于消息正文的元信息，或者，如果没有正文，则定义关于请求标识的资源的元信息。术语“实体头”是HTTP 1.1术语，其中响应主体可以包含消息主体的转换版本。原始消息体称为“实体”。我们对报头字段保留相同的术语，但通常指的是“消息体”，而不是实体，因为在SIP中两者是相同的。
The "request-header" fields allow the client to pass additional information about the request, and about the client itself, to the server. These fields act as request modifiers, with semantics equivalent to the parameters of a programming language method invocation.
“请求头”字段允许客户端向服务器传递有关请求和客户端本身的附加信息。这些字段充当请求修饰符，语义相当于编程语言方法调用的参数。
The "request-header" field names can be extended reliably only in combination with a change in the protocol version. However, new or experimental header fields MAY be given the semantics of "request-header" fields if all parties in the communication recognize them to be request-header fields. Unrecognized header fields are treated as "entity-header" fields.
“请求头”字段名只能在协议版本更改的情况下可靠地扩展。然而，如果通信中的所有各方都认识到新的或实验性的报头字段是请求报头字段，则可以赋予它们“请求报头”字段的语义。无法识别的标题字段被视为“实体标题”字段。
The "response-header" fields allow the server to pass additional information about the response which cannot be placed in the Status-Line. These header fields give information about the server and about further access to the resource identified by the Request-URI.
“response header”字段允许服务器传递有关响应的附加信息，这些信息不能放在状态行中。这些头字段提供有关服务器的信息，以及关于进一步访问由请求URI标识的资源的信息。
Response-header field names can be extended reliably only in combination with a change in the protocol version. However, new or experimental header fields MAY be given the semantics of "response-header" fields if all parties in the communication recognize them to be "response-header" fields. Unrecognized header fields are treated as "entity-header" fields.
只有结合协议版本的更改，才能可靠地扩展响应头字段名称。然而，如果通信中的所有各方都将新的或实验性的报头字段识别为“响应报头”字段，则可以赋予它们“响应报头”字段的语义。无法识别的标题字段被视为“实体标题”字段。
End-to-end headers MUST be transmitted unmodified across all proxies, while hop-by-hop headers MAY be modified or added by proxies.
端到端头必须在所有代理之间不经修改地传输，而逐跳头可以由代理修改或添加。
Header fields ("general-header", "request-header", "response-header", and "entity-header") follow the same generic header format as that given in Section 3.1 of RFC 822 [24]. Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive. The field value MAY be preceded by any amount of leading white space (LWS), though a single space (SP) is preferred. Header fields can be extended over multiple lines by preceding each extra line with at least one SP or horizontal tab (HT). Applications MUST follow HTTP "common form" when generating these constructs, since there might exist some implementations that fail to accept anything beyond the common forms.
标题字段（“通用标题”、“请求标题”、“响应标题”和“实体标题”）遵循RFC 822[24]第3.1节中给出的通用标题格式。每个标题字段由一个名称，后跟一个冒号（“：”）和字段值组成。字段名不区分大小写。字段值前面可以有任意数量的前导空格（LWS），但最好是单个空格（SP）。通过在每一额外行之前至少添加一个SP或水平制表符（HT），可以将标题字段扩展到多行。应用程序在生成这些结构时必须遵循HTTP“公共表单”，因为可能存在一些无法接受公共表单之外的任何内容的实现。
message-header = field-name ":" [ field-value ] CRLF
field-name = token
field-value = *( field-content | LWS )
field-content = < the OCTETs making up the field-value
and consisting of either *TEXT-UTF8
or combinations of token,
separators, and quoted-string>
message-header = field-name ":" [ field-value ] CRLF
field-name = token
field-value = *( field-content | LWS )
field-content = < the OCTETs making up the field-value
and consisting of either *TEXT-UTF8
or combinations of token,
separators, and quoted-string>
The relative order of header fields with different field names is not significant. Multiple header fields 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 (i.e., #(values)). It MUST be possible to combine the multiple header fields 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 order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy MUST NOT change the order of these field values when a message is forwarded.
具有不同字段名的标题字段的相对顺序不重要。当且仅当消息头字段的整个字段值定义为逗号分隔列表（即#（值））时，消息中可能存在具有相同字段名的多个标题字段。必须能够将多个标题字段合并为一个“字段名称：字段值”对，而不改变消息的语义，方法是将每个后续字段值附加到第一个字段值，每个字段值用逗号分隔。因此，具有相同字段名的标题字段的接收顺序对于组合字段值的解释非常重要，因此，在转发消息时，代理不得更改这些字段值的顺序。
Field names are not case-sensitive, although their values may be.
字段名不区分大小写，尽管其值可能不区分大小写。
The Accept header follows the syntax defined in [H14.1]. The semantics are also identical, with the exception that if no Accept header is present, the server SHOULD assume a default value of application/sdp.
Accept标头遵循[H14.1]中定义的语法。语义也完全相同，只是如果不存在Accept头，服务器应该采用默认值application/sdp。
This request-header field is used only with the INVITE, OPTIONS and REGISTER request methods to indicate what media types are acceptable in the response.
此请求标头字段仅用于INVITE、OPTIONS和REGISTER请求方法，以指示响应中可接受的媒体类型。
Example:
例子：
Accept: application/sdp;level=1, application/x-private, text/html
Accept: application/sdp;level=1, application/x-private, text/html
The Accept-Encoding request-header field is similar to Accept, but restricts the content-codings [H3.4.1] that are acceptable in the response. See [H14.3]. The syntax of this header is defined in [H14.3]. The semantics in SIP are identical to those defined in [H14.3].
Accept Encoding request header字段类似于Accept，但限制响应中可接受的内容编码[H3.4.1]。见[H14.3]。[H14.3]中定义了此标题的语法。SIP中的语义与[H14.3]中定义的语义相同。
The Accept-Language header follows the syntax defined in [H14.4]. The rules for ordering the languages based on the q parameter apply to SIP as well. When used in SIP, the Accept-Language request-header field can be used to allow the client to indicate to the server in which language it would prefer to receive reason phrases, session descriptions or status responses carried as message bodies. A proxy MAY use this field to help select the destination for the call, for example, a human operator conversant in a language spoken by the caller.
Accept Language标头遵循[H14.4]中定义的语法。基于q参数对语言进行排序的规则也适用于SIP。当在SIP中使用时，Accept Language request header字段可用于允许客户端向服务器指示它希望以哪种语言接收作为消息体携带的原因短语、会话描述或状态响应。代理可以使用此字段来帮助选择呼叫的目的地，例如，熟悉呼叫方所说语言的人工操作员。
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
The Allow entity-header field lists the set of methods supported by the resource identified by the Request-URI. The purpose of this field is strictly to inform the recipient of valid methods associated with the resource. An Allow header field MUST be present in a 405 (Method Not Allowed) response and SHOULD be present in an OPTIONS response.
Allow entity header字段列出由请求URI标识的资源支持的方法集。此字段的用途严格来说是通知收件人与资源关联的有效方法。Allow header字段必须出现在405（不允许使用方法）响应中，并且应该出现在OPTIONS响应中。
Allow = "Allow" ":" 1#Method
Allow = "Allow" ":" 1#Method
A user agent that wishes to authenticate itself with a server -- usually, but not necessarily, after receiving a 401 response -- MAY do so by including an Authorization request-header field with the request. The Authorization field value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested.
希望向服务器验证自身身份的用户代理（通常，但不一定，在收到401响应后）可以通过在请求中包含授权请求头字段来实现。Authorization字段值由包含所请求资源领域的用户代理的身份验证信息的凭据组成。
Section 13.2 overviews the use of the Authorization header, and section 15 describes the syntax and semantics when used with PGP based authentication.
第13.2节概述了授权标头的使用，第15节描述了与基于PGP的身份验证一起使用时的语法和语义。
The Call-ID general-header field uniquely identifies a particular invitation or all registrations of a particular client. Note that a single multimedia conference can give rise to several calls with different Call-IDs, e.g., if a user invites a single individual several times to the same (long-running) conference.
Call ID general header字段唯一标识特定邀请或特定客户端的所有注册。请注意，单个多媒体会议可能会产生多个具有不同呼叫ID的呼叫，例如，如果用户多次邀请单个个人参加同一（长时间运行的）会议。
For an INVITE request, a callee user agent server SHOULD NOT alert the user if the user has responded previously to the Call-ID in the INVITE request. If the user is already a member of the conference and the conference parameters contained in the session description have not changed, a callee user agent server MAY silently accept the call, regardless of the Call-ID. An invitation for an existing Call-ID or session can change the parameters of the conference. A client application MAY decide to simply indicate to the user that the conference parameters have been changed and accept the invitation automatically or it MAY require user confirmation.
对于INVITE请求，如果用户先前已响应INVITE请求中的呼叫ID，则被叫用户代理服务器不应向用户发出警报。如果用户已经是会议的成员，并且会话描述中包含的会议参数没有更改，则被叫用户代理服务器可以静默地接受呼叫，而不管呼叫ID如何。对现有呼叫ID或会话的邀请可以更改会议的参数。客户端应用程序可以决定简单地向用户指示会议参数已经更改并自动接受邀请，或者可能需要用户确认。
A user may be invited to the same conference or call using several different Call-IDs. If desired, the client MAY use identifiers within the session description to detect this duplication. For example, SDP contains a session id and version number in the origin (o) field.
可以使用多个不同的呼叫ID邀请用户参加相同的会议或呼叫。如果需要，客户端可以使用会话描述中的标识符来检测该重复。例如，SDP在源（o）字段中包含会话id和版本号。
The REGISTER and OPTIONS methods use the Call-ID value to unambiguously match requests and responses. All REGISTER requests issued by a single client SHOULD use the same Call-ID, at least within the same boot cycle.
REGISTER和OPTIONS方法使用callid值来明确匹配请求和响应。单个客户机发出的所有注册请求应使用相同的调用ID，至少在相同的启动周期内。
Since the Call-ID is generated by and for SIP, there is no reason to deal with the complexity of URL-encoding and case-ignoring string comparison.
由于调用ID是由SIP和为SIP生成的，因此没有理由处理URL编码和大小写忽略字符串比较的复杂性。
Call-ID = ( "Call-ID" | "i" ) ":" local-id "@" host
local-id = 1*uric
Call-ID = ( "Call-ID" | "i" ) ":" local-id "@" host
local-id = 1*uric
"host" SHOULD be either a fully qualified domain name or a globally routable IP address. If this is the case, the "local-id" SHOULD be an identifier consisting of URI characters that is unique within "host". Use of cryptographically random identifiers [27] is RECOMMENDED. If, however, host is not an FQDN or globally routable IP address (such as a net 10 address), the local-id MUST be globally unique, as opposed
“主机”应该是完全限定的域名或全局可路由的IP地址。如果是这种情况，“本地id”应该是由“主机”中唯一的URI字符组成的标识符。建议使用加密随机标识符[27]。但是，如果主机不是FQDN或全局可路由IP地址（如net 10地址），则本地id必须是全局唯一的，反之亦然
to unique within host. These rules guarantee overall global uniqueness of the Call-ID. The value for Call-ID MUST NOT be reused for a different call. Call-IDs are case-sensitive.
要在主机中唯一。这些规则保证Call-ID的全局唯一性。Call-ID的值不能用于其他调用。呼叫ID区分大小写。
Using cryptographically random identifiers provides some protection against session hijacking. Call-ID, To and From are needed to identify a call leg. The distinction between call and call leg matters in calls with third-party control.
使用加密随机标识符可以提供一些防止会话劫持的保护。需要呼叫ID、收件人和发件人来识别呼叫分支。在具有第三方控制的呼叫中，呼叫和呼叫分支之间的区别很重要。
For systems which have tight bandwidth constraints, many of the mandatory SIP headers have a compact form, as discussed in Section 9. These are alternate names for the headers which occupy less space in the message. In the case of Call-ID, the compact form is i.
对于具有严格带宽限制的系统，许多强制SIP头具有紧凑的形式，如第9节所述。这些是在消息中占用较少空间的标题的替代名称。在调用ID的情况下，紧凑形式是i。
For example, both of the following are valid:
例如，以下两项均有效：
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com
呼叫ID:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com
or
或
i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com
i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com
The Contact general-header field can appear in INVITE, ACK, and REGISTER requests, and in 1xx, 2xx, 3xx, and 485 responses. In general, it provides a URL where the user can be reached for further communications.
Contact general header字段可以出现在INVITE、ACK和REGISTER请求中，也可以出现在1x、2xx、3xx和485响应中。一般来说，它提供了一个URL，用户可以通过该URL进行进一步的通信。
INVITE and ACK requests: INVITE and ACK requests MAY contain Contact headers indicating from which location the request is originating.
INVITE和ACK请求：INVITE和ACK请求可能包含联系人头，指示请求来自哪个位置。
This allows the callee to send future requests, such as BYE, directly to the caller instead of through a series of proxies. The Via header is not sufficient since the desired address may be that of a proxy.
这允许被调用者直接向调用者发送未来的请求，例如BYE，而不是通过一系列代理。由于所需地址可能是代理的地址，因此Via标头不够。
INVITE 2xx responses: A user agent server sending a definitive, positive response (2xx) MAY insert a Contact response header field indicating the SIP address under which it is reachable most directly for future SIP requests, such as ACK, within the
INVITE 2xx responses（邀请2xx响应）：发送确定肯定响应（2xx）的用户代理服务器可以插入一个Contact response header字段，该字段指示SIP地址，在该地址下，未来SIP请求（如ACK）可以最直接地访问该地址
same Call-ID. The Contact header field contains the address of the server itself or that of a proxy, e.g., if the host is behind a firewall. The value of this Contact header is copied into the Request-URI of subsequent requests for this call if the response did not also contain a Record-Route header. If the response also contains a Record-Route header field, the address in the Contact header field is added as the last item in the Route header field. See Section 6.29 for details.
相同的呼叫ID。联系人标头字段包含服务器本身的地址或代理的地址，例如，如果主机位于防火墙后面。如果响应不包含记录路由标头，则此联系人标头的值将复制到此调用的后续请求的请求URI中。如果响应还包含记录路由标头字段，则联系人标头字段中的地址将添加为路由标头字段中的最后一项。详见第6.29节。
The Contact value SHOULD NOT be cached across calls, as it may not represent the most desirable location for a particular destination address.
联系人值不应跨调用缓存，因为它可能不代表特定目标地址的最理想位置。
INVITE 1xx responses: A UAS sending a provisional response (1xx) MAY insert a Contact response header. It has the same semantics in a 1xx response as a 2xx INVITE response. Note that CANCEL requests MUST NOT be sent to that address, but rather follow the same path as the original request.
邀请1xx响应：发送临时响应（1xx）的UAS可以插入联系人响应头。它在1xx响应中的语义与2xx INVITE响应中的语义相同。请注意，取消请求不能发送到该地址，而是遵循与原始请求相同的路径。
REGISTER requests: REGISTER requests MAY contain a Contact header field indicating at which locations the user is reachable. The REGISTER request defines a wildcard Contact field, "*", which MUST only be used with Expires: 0 to remove all registrations for a particular user. An optional "expires" parameter indicates the desired expiration time of the registration. If a Contact entry does not have an "expires" parameter, the Expires header field is used as the default value. If neither of these mechanisms is used, SIP URIs are assumed to expire after one hour. Other URI schemes have no expiration times.
注册请求：注册请求可能包含一个联系人标题字段，指示用户可以访问的位置。注册请求定义了通配符联系人字段“*”，该字段只能与Expires:0一起使用，以删除特定用户的所有注册。可选的“expires”参数表示所需的注册过期时间。如果联系人条目没有“expires”参数，则expires标头字段将用作默认值。如果没有使用这两种机制，则假定SIPURI在一小时后过期。其他URI方案没有过期时间。
REGISTER 2xx responses: A REGISTER response MAY return all locations at which the user is currently reachable. An optional "expires" parameter indicates the expiration time of the registration. If a Contact entry does not have an "expires" parameter, the value of the Expires header field indicates the expiration time. If neither mechanism is used, the expiration time specified in the request, explicitly or by default, is used.
寄存器2xx响应：寄存器响应可能返回用户当前可访问的所有位置。可选的“expires”参数表示注册的过期时间。如果联系人条目没有“expires”参数，则expires标头字段的值表示过期时间。如果两种机制均未使用，则使用请求中明确或默认指定的过期时间。
3xx and 485 responses: The Contact response-header field can be used with a 3xx or 485 (Ambiguous) response codes to indicate one or more alternate addresses to try. It can appear in responses to BYE, INVITE and OPTIONS methods. The Contact header field contains URIs giving the new locations or user names to try, or may simply specify additional transport parameters. A 300 (Multiple Choices), 301 (Moved Permanently), 302 (Moved Temporarily) or 485 (Ambiguous) response SHOULD contain a Contact field containing URIs of new addresses to be tried. A
3xx和485响应：联系人响应标题字段可与3xx或485（不明确）响应代码一起使用，以指示一个或多个要尝试的备用地址。它可以出现在对BYE、INVITE和OPTIONS方法的响应中。Contact header字段包含URI，这些URI提供了要尝试的新位置或用户名，或者可以简单地指定其他传输参数。300（多选）、301（永久移动）、302（临时移动）或485（不明确）响应应包含联系人字段，其中包含要尝试的新地址的URI。A.
301 or 302 response may also give the same location and username that was being tried 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. The client copies the "user", "password", "host", "port" and "user-param" elements of the Contact URI into the Request-URI of the redirected request and directs the request to the address specified by the "maddr" and "port" parameters, using the transport protocol given in the "transport" parameter. If "maddr" is a multicast address, the value of "ttl" is used as the time-to-live value.
301或302响应也可能给出与尝试相同的位置和用户名，但指定其他传输参数，如要尝试的不同服务器或多播地址，或将SIP传输从UDP更改为TCP，反之亦然。客户端将联系人URI的“用户”、“密码”、“主机”、“端口”和“用户参数”元素复制到重定向请求的请求URI中，并使用“传输”参数中给出的传输协议将请求定向到“maddr”和“port”参数指定的地址。如果“maddr”是多播地址，“ttl”的值用作生存时间值。
Note that the Contact header field MAY also refer to a different entity than the one originally called. For example, a SIP call connected to GSTN gateway may need to deliver a special information announcement such as "The number you have dialed has been changed."
请注意，Contact header字段也可能引用与最初调用的实体不同的实体。例如，连接到GSTN网关的SIP呼叫可能需要发送特殊信息公告，如“您拨打的号码已更改”
A Contact response header field can contain any suitable URI indicating where the called party can be reached, not limited to SIP URLs. For example, it could contain URL's for phones, fax, or irc (if they were defined) or a mailto: (RFC 2368, [28]) URL.
Contact response header字段可以包含任何适当的URI，指示可以到达被叫方的位置，而不限于SIPURL。例如，它可以包含电话、传真或irc（如果已定义）的URL或mailto:（RFC 2368，[28]）URL。
The following parameters are defined. Additional parameters may be defined in other specifications.
定义了以下参数。其他参数可在其他规范中定义。
q: The "qvalue" indicates the relative preference among the locations given. "qvalue" values are decimal numbers from 0 to 1, with higher values indicating higher preference.
q：“qvalue”表示给定位置之间的相对偏好。“qvalue”值是从0到1的十进制数，值越大表示偏好越高。
action: The "action" parameter is used only when registering with the REGISTER request. It indicates whether the client wishes that the server proxy or redirect future requests intended for the client. If this parameter is not specified the action taken depends on server configuration. In its response, the registrar SHOULD indicate the mode used. This parameter is ignored for other requests.
操作：“操作”参数仅在注册注册请求时使用。它指示客户端是否希望服务器代理或重定向将来针对客户端的请求。如果未指定此参数，则所采取的操作取决于服务器配置。书记官长在答复中应说明所采用的方式。其他请求将忽略此参数。
expires: The "expires" parameter indicates how long the URI is valid. The parameter is either a number indicating seconds or a quoted string containing a SIP-date. If this parameter is not provided, the value of the Expires header field determines how long the URI is valid. Implementations MAY treat values larger than 2**32-1 (4294967295 seconds or 136 years) as equivalent to 2**32-1.
expires：“expires”参数指示URI的有效期。参数可以是表示秒数的数字，也可以是包含SIP日期的带引号的字符串。如果未提供此参数，则Expires标头字段的值确定URI的有效期。实施可能将大于2**32-1（4294967295秒或136年）的值视为等同于2**32-1。
Contact = ( "Contact" | "m" ) ":"
("*" | (1# (( name-addr | addr-spec )
[ *( ";" contact-params ) ] [ comment ] )))
Contact = ( "Contact" | "m" ) ":"
("*" | (1# (( name-addr | addr-spec )
[ *( ";" contact-params ) ] [ comment ] )))
name-addr = [ display-name ] "<" addr-spec ">"
addr-spec = SIP-URL | URI
display-name = *token | quoted-string
name-addr = [ display-name ] "<" addr-spec ">"
addr-spec = SIP-URL | URI
display-name = *token | quoted-string
contact-params = "q" "=" qvalue
| "action" "=" "proxy" | "redirect"
| "expires" "=" delta-seconds | <"> SIP-date <">
| extension-attribute
contact-params = "q" "=" qvalue
| "action" "=" "proxy" | "redirect"
| "expires" "=" delta-seconds | <"> SIP-date <">
| extension-attribute
extension-attribute = extension-name [ "=" extension-value ]
扩展属性=扩展名[“=”扩展值]
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. The current syntax corresponds to that for the To and From header, which also allows the use of display names.
只允许一个地址，不带引号。由于URI可以包含逗号和分号作为保留字符，因此它们可能分别被误认为是头分隔符或参数分隔符。当前语法与to和From标题对应，这也允许使用显示名称。
Example:
例子：
Contact: "Mr. Watson" <sip:watson@worcester.bell-telephone.com>
;q=0.7; expires=3600,
"Mr. Watson" <mailto:watson@bell-telephone.com> ;q=0.1
Contact: "Mr. Watson" <sip:watson@worcester.bell-telephone.com>
;q=0.7; expires=3600,
"Mr. Watson" <mailto:watson@bell-telephone.com> ;q=0.1
Content-Encoding = ( "Content-Encoding" | "e" ) ":"
1#content-coding
Content-Encoding = ( "Content-Encoding" | "e" ) ":"
1#content-coding
The Content-Encoding entity-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, the content codings MUST be listed in the order in which they were applied.
如果对一个实体应用了多个编码，则必须按应用顺序列出内容编码。
All content-coding values are case-insensitive. The Internet Assigned Numbers Authority (IANA) acts as a registry for content-coding value tokens. See [3.5] for a definition of the syntax for content-coding.
所有内容编码值都不区分大小写。Internet分配号码管理局（IANA）充当内容编码值令牌的注册表。有关内容编码语法的定义，请参见[3.5]。
Clients MAY apply content encodings to the body in requests. If the server is not capable of decoding the body, or does not recognize any of the content-coding values, it MUST send a 415 "Unsupported Media Type" response, listing acceptable encodings in the Accept-Encoding
客户端可以对请求中的正文应用内容编码。如果服务器不能解码主体，或者不识别任何内容编码值，则它必须发送415“不支持的媒体类型”响应，在接受编码中列出可接受的编码
header. A server MAY apply content encodings to the bodies in responses. The server MUST only use encodings listed in the Accept-Encoding header in the request.
标题。服务器可以对响应中的主体应用内容编码。服务器只能使用请求中Accept Encoding标头中列出的编码。
The Content-Length entity-header field indicates the size of the message-body, in decimal number of octets, sent to the recipient.
Content Length entity标头字段表示发送给收件人的邮件正文的大小，以十进制的八位字节数表示。
Content-Length = ( "Content-Length" | "l" ) ":" 1*DIGIT
Content-Length = ( "Content-Length" | "l" ) ":" 1*DIGIT
An example is
例如
Content-Length: 3495
内容长度：3495
Applications SHOULD use this field to indicate the size of the message-body to be transferred, regardless of the media type of the entity. 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 MUST be set to zero. If a server receives a UDP request without Content-Length, it MUST assume that the request encompasses the remainder of the packet. If a server receives a UDP request with a Content-Length, but the value is larger than the size of the body sent in the request, the client SHOULD generate a 400 class response. If there is additional data in the UDP packet after the last byte of the body has been read, the server MUST treat the remaining data as a separate message. This allows several messages to be placed in a single UDP packet.
应用程序应使用此字段指示要传输的消息正文的大小，而不考虑实体的媒体类型。任何大于或等于零的内容长度都是有效值。如果消息中没有正文，则必须将内容长度标题字段设置为零。如果服务器接收到没有内容长度的UDP请求，则必须假定该请求包含数据包的其余部分。如果服务器接收到具有内容长度的UDP请求，但该值大于请求中发送的正文的大小，则客户端应生成400类响应。如果在读取正文的最后一个字节后，UDP数据包中还有其他数据，则服务器必须将其余数据作为单独的消息处理。这允许在单个UDP数据包中放置多条消息。
If a response does not contain a Content-Length, the client assumes that it encompasses the remainder of the UDP packet or the data until the TCP connection is closed, as applicable. Section 8 describes how to determine the length of the message body.
如果响应不包含内容长度，客户机将假定它包含UDP数据包或数据的其余部分，直到TCP连接关闭（如适用）。第8节描述了如何确定消息正文的长度。
The Content-Type entity-header field indicates the media type of the message-body sent to the recipient. The "media-type" element is defined in [H3.7].
Content Type entity header字段指示发送给收件人的邮件正文的媒体类型。[H3.7]中定义了“媒体类型”元素。
Content-Type = ( "Content-Type" | "c" ) ":" media-type
Content-Type = ( "Content-Type" | "c" ) ":" media-type
Examples of this header field are
此标题字段的示例包括
Content-Type: application/sdp
Content-Type: text/html; charset=ISO-8859-4
Content-Type: application/sdp
Content-Type: text/html; charset=ISO-8859-4
Clients MUST add the CSeq (command sequence) general-header field to every request. A CSeq header field in a request contains the request method and a single decimal sequence number chosen by the requesting client, unique within a single value of Call-ID. The sequence number MUST be expressible as a 32-bit unsigned integer. The initial value of the sequence number is arbitrary, but MUST be less than 2**31. Consecutive requests that differ in request method, headers or body, but have the same Call-ID MUST contain strictly monotonically increasing and contiguous sequence numbers; sequence numbers do not wrap around. Retransmissions of the same request carry the same sequence number, but an INVITE with a different message body or different header fields (a "re-invitation") acquires a new, higher sequence number. A server MUST echo the CSeq value from the request in its response. If the Method value is missing in the received CSeq header field, the server fills it in appropriately.
客户端必须向每个请求添加CSeq（命令序列）常规头字段。请求中的CSeq头字段包含请求方法和请求客户端选择的单个十进制序列号，在Call-ID的单个值内唯一。序列号必须可表示为32位无符号整数。序列号的初始值是任意的，但必须小于2**31。请求方法、标头或正文不同但具有相同调用ID的连续请求必须包含严格单调递增且连续的序列号；序列号不环绕。同一请求的重新传输具有相同的序列号，但具有不同消息正文或不同头字段的INVITE（“重新邀请”）会获得新的、更高的序列号。服务器必须在其响应中回显请求中的CSeq值。如果received CSeq header字段中缺少Method值，则服务器会适当地填充该值。
The ACK and CANCEL requests MUST contain the same CSeq value as the INVITE request that it refers to, while a BYE request cancelling an invitation MUST have a higher sequence number. A BYE request with a CSeq that is not higher should cause a 400 response to be generated.
ACK和CANCEL请求必须包含与其引用的INVITE请求相同的CSeq值，而取消邀请的BYE请求必须具有更高的序列号。具有不高于CSeq的BYE请求应导致生成400响应。
A user agent server MUST remember the highest sequence number for any INVITE request with the same Call-ID value. The server MUST respond to, and then discard, any INVITE request with a lower sequence number.
用户代理服务器必须记住具有相同呼叫ID值的任何INVITE请求的最高序列号。服务器必须响应并放弃任何序列号较低的INVITE请求。
All requests spawned in a parallel search have the same CSeq value as the request triggering the parallel search.
在并行搜索中生成的所有请求与触发并行搜索的请求具有相同的CSeq值。
CSeq = "CSeq" ":" 1*DIGIT Method
CSeq = "CSeq" ":" 1*DIGIT Method
Strictly speaking, CSeq header fields are needed for any SIP request that can be cancelled by a BYE or CANCEL request or where a client can issue several requests for the same Call-ID in close succession. Without a sequence
严格来说，任何SIP请求都需要CSeq头字段，这些请求可以通过BYE或CANCEL请求取消，或者客户端可以连续发出多个相同呼叫ID的请求。没有顺序
number, the response to an INVITE could be mistaken for the response to the cancellation (BYE or CANCEL). Also, if the network duplicates packets or if an ACK is delayed until the server has sent an additional response, the client could interpret an old response as the response to a re-invitation issued shortly thereafter. Using CSeq also makes it easy for the server to distinguish different versions of an invitation, without comparing the message body.
号码，对邀请的响应可能会被误认为是对取消的响应（拜拜或取消）。此外，如果网络复制了数据包，或者如果ACK延迟到服务器发送了附加响应，则客户端可以将旧响应解释为对随后不久发出的重新邀请的响应。使用CSeq还可以让服务器轻松区分邀请的不同版本，而无需比较消息正文。
The Method value allows the client to distinguish the response to an INVITE request from that of a CANCEL response. CANCEL requests can be generated by proxies; if they were to increase the sequence number, it might conflict with a later request issued by the user agent for the same call.
方法值允许客户端区分对INVITE请求的响应和对CANCEL响应的响应。取消请求可以由代理生成；如果要增加序列号，则可能会与用户代理稍后针对同一呼叫发出的请求冲突。
With a length of 32 bits, a server 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 to use a time-based initial sequence number, if the client desires. 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个最高有效位作为初始序列号。
Forked requests MUST have the same CSeq as there would be ambiguity otherwise between these forked requests and later BYE issued by the client user agent.
分叉请求必须具有相同的CSeq，否则这些分叉请求与客户端用户代理稍后发出的BYE之间会存在歧义。
Example:
例子：
CSeq: 4711 INVITE
CSeq:4711邀请
Date is a general-header field. Its syntax is:
日期是一个常规标题字段。其语法是：
SIP-date = rfc1123-date
SIP-date = rfc1123-date
See [H14.19] for a definition of rfc1123-date. Note that unlike HTTP/1.1, SIP only supports the most recent RFC1123 [29] formatting for dates.
rfc1123日期的定义见[H14.19]。请注意，与HTTP/1.1不同，SIP仅支持日期的最新RFC1123[29]格式。
The Date header field reflects the time when the request or response is first sent. Thus, retransmissions have the same Date header field value as the original.
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.
没有电池供电时钟的简单终端系统可以使用Date header字段来获取当前时间的概念。
The Encryption general-header field specifies that the content has been encrypted. Section 13 describes the overall SIP security architecture and algorithms. This header field is intended for end-to-end encryption of requests and responses. Requests are encrypted based on the public key belonging to the entity named in the To header field. Responses are encrypted based on the public key conveyed in the Response-Key header field. Note that the public keys themselves may not be used for the encryption. This depends on the particular algorithms used.
Encryption general标头字段指定内容已加密。第13节描述了整个SIP安全体系结构和算法。此标头字段用于对请求和响应进行端到端加密。请求根据属于“收件人”标头字段中指定的实体的公钥进行加密。响应根据响应密钥头字段中传递的公钥进行加密。请注意，公钥本身可能不会用于加密。这取决于使用的特定算法。
For any encrypted message, at least the message body and possibly other message header fields are encrypted. An application receiving a request or response containing an Encryption header field decrypts the body and then concatenates the plaintext to the request line and headers of the original message. Message headers in the decrypted part completely replace those with the same field name in the plaintext part. (Note: If only the body of the message is to be encrypted, the body has to be prefixed with CRLF to allow proper concatenation.) Note that the request method and Request-URI cannot be encrypted.
对于任何加密的消息，至少对消息正文和可能的其他消息头字段进行加密。接收包含加密头字段的请求或响应的应用程序对正文进行解密，然后将明文连接到原始消息的请求行和头。解密部分中的消息头完全替换明文部分中具有相同字段名的消息头。（注意：如果只对消息的正文进行加密，则正文必须以CRLF作为前缀，以允许正确的连接。）注意，不能对请求方法和请求URI进行加密。
Encryption only provides privacy; the recipient has no guarantee that the request or response came from the party listed in the From message header, only that the sender used the recipient's public key. However, proxies will not be able to modify the request or response.
加密只提供隐私；收件人不保证请求或响应来自发件人消息头中列出的一方，只保证发件人使用了收件人的公钥。但是，代理将无法修改请求或响应。
Encryption = "Encryption" ":" encryption-scheme 1*SP
#encryption-params
encryption-scheme = token
encryption-params = token "=" ( token | quoted-string )
Encryption = "Encryption" ":" encryption-scheme 1*SP
#encryption-params
encryption-scheme = token
encryption-params = token "=" ( token | quoted-string )
The token indicates the form of encryption used; it is described in section 13.
令牌表示使用的加密形式；第13节对此进行了描述。
The example in Figure 10 shows a message encrypted with ASCII-armored PGP that was generated by applying "pgp -ea" to the payload to be encrypted.
图10中的示例显示了使用ASCII铠装PGP加密的消息，该消息是通过对要加密的有效负载应用“PGP-ea”生成的。
INVITE sip:watson@boston.bell-telephone.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
From: <sip:a.g.bell@bell-telephone.com>
To: T. A. Watson <sip:watson@bell-telephone.com>
Call-ID: 187602141351@worcester.bell-telephone.com
Content-Length: 885
Encryption: PGP version=2.6.2,encoding=ascii
INVITE sip:watson@boston.bell-telephone.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
From: <sip:a.g.bell@bell-telephone.com>
To: T. A. Watson <sip:watson@bell-telephone.com>
Call-ID: 187602141351@worcester.bell-telephone.com
Content-Length: 885
Encryption: PGP version=2.6.2,encoding=ascii
hQEMAxkp5GPd+j5xAQf/ZDIfGD/PDOM1wayvwdQAKgGgjmZWe+MTy9NEX8O25Red
h0/pyrd/+DV5C2BYs7yzSOSXaj1C/tTK/4do6rtjhP8QA3vbDdVdaFciwEVAcuXs
ODxlNAVqyDi1RqFC28BJIvQ5KfEkPuACKTK7WlRSBc7vNPEA3nyqZGBTwhxRSbIR
RuFEsHSVojdCam4htcqxGnFwD9sksqs6LIyCFaiTAhWtwcCaN437G7mUYzy2KLcA
zPVGq1VQg83b99zPzIxRdlZ+K7+bAnu8Rtu+ohOCMLV3TPXbyp+err1YiThCZHIu
X9dOVj3CMjCP66RSHa/ea0wYTRRNYA/G+kdP8DSUcqYAAAE/hZPX6nFIqk7AVnf6
IpWHUPTelNUJpzUp5Ou+q/5P7ZAsn+cSAuF2YWtVjCf+SQmBR13p2EYYWHoxlA2/
GgKADYe4M3JSwOtqwU8zUJF3FIfk7vsxmSqtUQrRQaiIhqNyG7KxJt4YjWnEjF5E
WUIPhvyGFMJaeQXIyGRYZAYvKKklyAJcm29zLACxU5alX4M25lHQd9FR9Zmq6Jed
wbWvia6cAIfsvlZ9JGocmQYF7pcuz5pnczqP+/yvRqFJtDGD/v3s++G2R+ViVYJO
z/lxGUZaM4IWBCf+4DUjNanZM0oxAE28NjaIZ0rrldDQmO8V9FtPKdHxkqA5iJP+
6vGOFti1Ak4kmEz0vM/Nsv7kkubTFhRl05OiJIGr9S1UhenlZv9l6RuXsOY/EwH2
z8X9N4MhMyXEVuC9rt8/AUhmVQ==
=bOW+
hQEMAxkp5GPd+j5xAQf/ZDIfGD/PDOM1wayvwdQAKgGgjmZWe+MTy9NEX8O25Red
h0/pyrd/+DV5C2BYs7yzSOSXaj1C/tTK/4do6rtjhP8QA3vbDdVdaFciwEVAcuXs
ODxlNAVqyDi1RqFC28BJIvQ5KfEkPuACKTK7WlRSBc7vNPEA3nyqZGBTwhxRSbIR
RuFEsHSVojdCam4htcqxGnFwD9sksqs6LIyCFaiTAhWtwcCaN437G7mUYzy2KLcA
zPVGq1VQg83b99zPzIxRdlZ+K7+bAnu8Rtu+ohOCMLV3TPXbyp+err1YiThCZHIu
X9dOVj3CMjCP66RSHa/ea0wYTRRNYA/G+kdP8DSUcqYAAAE/hZPX6nFIqk7AVnf6
IpWHUPTelNUJpzUp5Ou+q/5P7ZAsn+cSAuF2YWtVjCf+SQmBR13p2EYYWHoxlA2/
GgKADYe4M3JSwOtqwU8zUJF3FIfk7vsxmSqtUQrRQaiIhqNyG7KxJt4YjWnEjF5E
WUIPhvyGFMJaeQXIyGRYZAYvKKklyAJcm29zLACxU5alX4M25lHQd9FR9Zmq6Jed
wbWvia6cAIfsvlZ9JGocmQYF7pcuz5pnczqP+/yvRqFJtDGD/v3s++G2R+ViVYJO
z/lxGUZaM4IWBCf+4DUjNanZM0oxAE28NjaIZ0rrldDQmO8V9FtPKdHxkqA5iJP+
6vGOFti1Ak4kmEz0vM/Nsv7kkubTFhRl05OiJIGr9S1UhenlZv9l6RuXsOY/EwH2
z8X9N4MhMyXEVuC9rt8/AUhmVQ==
=bOW+
Figure 10: PGP Encryption Example
图10:PGP加密示例
Since proxies can base their forwarding decision on any combination of SIP header fields, there is no guarantee that an encrypted request "hiding" header fields will reach the same destination as an otherwise identical un-encrypted request.
由于代理可以根据SIP头字段的任何组合做出转发决定，因此不能保证加密请求“隐藏”头字段将到达与其他相同的未加密请求相同的目的地。
The Expires entity-header field gives the date and time after which the message content expires.
Expires entity标头字段提供消息内容过期的日期和时间。
This header field is currently defined only for the REGISTER and INVITE methods. For REGISTER, it is a request and response-header field. In a REGISTER request, the client indicates how long it wishes the registration to be valid. In the response, the server indicates
此标头字段当前仅为REGISTER和INVITE方法定义。对于寄存器，它是一个请求和响应头字段。在注册请求中，客户端指示其希望注册有效的时间。在响应中，服务器指示
the earliest expiration time of all registrations. The server MAY choose a shorter time interval than that requested by the client, but SHOULD NOT choose a longer one.
所有注册的最早到期时间。服务器可以选择比客户端请求的时间间隔更短的时间间隔，但不应选择更长的时间间隔。
For INVITE requests, it is a request and response-header field. In a request, the caller can limit the validity of an invitation, for example, if a client wants to limit the time duration of a search or a conference invitation. A user interface MAY take this as a hint to leave the invitation window on the screen even if the user is not currently at the workstation. This also limits the duration of a search. If the request expires before the search completes, the proxy returns a 408 (Request Timeout) status. In a 302 (Moved Temporarily) response, a server can advise the client of the maximal duration of the redirection.
对于INVITE请求，它是一个请求和响应头字段。在请求中，调用方可以限制邀请的有效性，例如，如果客户端希望限制搜索或会议邀请的持续时间。即使用户当前不在工作站上，用户界面也可能会将此视为将邀请窗口留在屏幕上的提示。这也限制了搜索的持续时间。如果请求在搜索完成之前过期，则代理返回408（请求超时）状态。在302（临时移动）响应中，服务器可以通知客户端重定向的最大持续时间。
The value of this field can be either a SIP-date or an integer number of seconds (in decimal), measured from the receipt of the request. The latter approach is preferable for short durations, as it does not depend on clients and servers sharing a synchronized clock. Implementations MAY treat values larger than 2**32-1 (4294967295 or 136 years) as equivalent to 2**32-1.
此字段的值可以是SIP日期，也可以是从接收请求开始测量的整数秒数（十进制）。后一种方法更适合于短持续时间，因为它不依赖于共享同步时钟的客户端和服务器。实施可能将大于2**32-1（4294967295或136年）的值视为等于2**32-1。
Expires = "Expires" ":" ( SIP-date | delta-seconds )
Expires=“Expires”“：“（SIP日期|增量秒）
Two examples of its use are
使用它的两个例子是
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Expires: 5
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Expires: 5
Requests and responses MUST contain a From general-header field, indicating the initiator of the request. The From field MAY contain the "tag" parameter. The server copies the From header field from the request to the response. 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.
请求和响应必须包含From general标头字段，指示请求的发起人。From字段可能包含“tag”参数。服务器将From头字段从请求复制到响应。可选的“显示名称”是指由人机界面呈现。如果要隐藏客户端的身份，系统应使用显示名称“匿名”。
The SIP-URL MUST NOT contain the "transport-param", "maddr-param", "ttl-param", or "headers" elements. A server that receives a SIP-URL with these elements removes them before further processing.
SIP-URL不得包含“传输参数”、“maddr参数”、“ttl参数”或“标头”元素。接收包含这些元素的SIP-URL的服务器将在进一步处理之前删除这些元素。
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.
即使“display name”为空，如果“addr spec”包含逗号、问号或分号，也必须使用“name addr”表单。
From = ( "From" | "f" ) ":" ( name-addr | addr-spec )
*( ";" addr-params )
addr-params = tag-param
tag-param = "tag=" UUID
UUID = 1*( hex | "-" )
From = ( "From" | "f" ) ":" ( name-addr | addr-spec )
*( ";" addr-params )
addr-params = tag-param
tag-param = "tag=" UUID
UUID = 1*( hex | "-" )
Examples:
示例：
From: "A. G. Bell" <sip:agb@bell-telephone.com>
From: sip:+12125551212@server.phone2net.com
From: Anonymous <sip:c8oqz84zk7z@privacy.org>
From: "A. G. Bell" <sip:agb@bell-telephone.com>
From: sip:+12125551212@server.phone2net.com
From: Anonymous <sip:c8oqz84zk7z@privacy.org>
The "tag" MAY appear in the From field of a request. It MUST be present when it is possible that two instances of a user sharing a SIP address can make call invitations with the same Call-ID.
“标记”可能出现在请求的“发件人”字段中。当共享SIP地址的用户的两个实例可能使用相同的call-ID发出呼叫邀请时，必须存在该消息。
The "tag" value MUST be globally unique and cryptographically random with at least 32 bits of randomness. A single user maintains the same tag throughout the call identified by the Call-ID.
“标记”值必须是全局唯一的，并且以密码方式随机，至少具有32位随机性。单个用户在call-ID标识的整个通话中维护相同的标签。
Call-ID, To and From are needed to identify a call leg. The distinction between call and call leg matters in calls with multiple responses to a forked request. The format is similar to the equivalent RFC 822 [24] header, but with a URI instead of just an email address.
需要呼叫ID、收件人和发件人来识别呼叫分支。在对分叉请求有多个响应的调用中，调用和调用分支之间的区别很重要。该格式类似于等效的RFC 822[24]头，但使用URI而不仅仅是电子邮件地址。
A client uses the Hide request header field to indicate that it wants the path comprised of the Via header fields (Section 6.40) to be hidden from subsequent proxies and user agents. It can take two forms: Hide: route and Hide: hop. Hide header fields are typically added by the client user agent, but MAY be added by any proxy along the path.
客户端使用Hide request header（隐藏请求头）字段表示它希望对后续代理和用户代理隐藏由Via头字段（第6.40节）组成的路径。它可以有两种形式：Hide:route和Hide:hop。隐藏头字段通常由客户端用户代理添加，但也可以由路径上的任何代理添加。
If a request contains the "Hide: route" header field, all following proxies SHOULD hide their previous hop. If a request contains the "Hide: hop" header field, only the next proxy SHOULD hide the previous hop and then remove the Hide option unless it also wants to remain anonymous.
如果请求包含“Hide:route”头字段，则以下所有代理都应隐藏其上一个跃点。如果请求包含“Hide:hop”头字段，则只有下一个代理应该隐藏上一个hop，然后删除Hide选项，除非它还希望保持匿名。
A server hides the previous hop by encrypting the "host" and "port" parts of the top-most Via header field with an algorithm of its choice. Servers SHOULD add additional "salt" to the "host" and "port" information prior to encryption to prevent malicious downstream proxies from guessing earlier parts of the path based on seeing identical encrypted Via headers. Hidden Via fields are marked with the "hidden" Via option, as described in Section 6.40.
服务器通过使用其选择的算法加密最顶端的Via头字段的“主机”和“端口”部分来隐藏前一跳。在加密之前，服务器应在“主机”和“端口”信息中添加额外的“salt”，以防止恶意下游代理基于看到相同的加密Via头猜测路径的早期部分。隐藏通孔字段用“隐藏”通孔选项标记，如第6.40节所述。
A server that is capable of hiding Via headers MUST attempt to decrypt all Via headers marked as "hidden" to perform loop detection. Servers that are not capable of hiding can ignore hidden Via fields in their loop detection algorithm.
能够隐藏Via头的服务器必须尝试解密标记为“隐藏”的所有Via头以执行循环检测。无法隐藏的服务器可以在其循环检测算法中忽略隐藏的Via字段。
If hidden headers were not marked, a proxy would have to decrypt all headers to detect loops, just in case one was encrypted, as the Hide: Hop option may have been removed along the way.
如果未标记隐藏的头，代理将必须解密所有头以检测循环，以防其中一个被加密，因为Hide:Hop选项可能已经被删除。
A host MUST NOT add such a "Hide: hop" header field unless it can guarantee it will only send a request for this destination to the same next hop. The reason for this is that it is possible that the request will loop back through this same hop from a downstream proxy. The loop will be detected by the next hop if the choice of next hop is fixed, but could loop an arbitrary number of times otherwise.
主机不得添加这样的“Hide:hop”头字段，除非它能保证只向同一下一个跃点发送此目的地的请求。这样做的原因是，请求可能会从下游代理通过同一跳返回。如果下一跳的选择是固定的，则下一跳将检测到循环，否则可能循环任意次数。
A client requesting "Hide: route" can only rely on keeping the request path private if it sends the request to a trusted proxy. Hiding the route of a SIP request is of limited value if the request results in data packets being exchanged directly between the calling and called user agent.
如果请求“隐藏：路由”的客户端将请求发送到受信任的代理，则它只能依赖于将请求路径保持私有。如果SIP请求导致数据包在主叫和被叫用户代理之间直接交换，则隐藏SIP请求的路由的价值有限。
The use of Hide header fields is discouraged unless path privacy is truly needed; Hide fields impose extra processing costs and restrictions for proxies and can cause requests to generate 482 (Loop Detected) responses that could otherwise be avoided.
除非确实需要路径隐私，否则不鼓励使用隐藏头字段；隐藏字段会对代理施加额外的处理成本和限制，并可能导致请求生成482（循环检测）响应，否则这些响应是可以避免的。
The encryption of Via header fields is described in more detail in Section 13.
第13节更详细地描述了Via报头字段的加密。
The Hide header field has the following syntax:
“隐藏标头”字段具有以下语法：
Hide = "Hide" ":" ( "route" | "hop" )
Hide = "Hide" ":" ( "route" | "hop" )
The Max-Forwards request-header field may 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 which appears to be failing or looping in mid-chain.
Max Forwards request header字段可与任何SIP方法一起使用，以限制可将请求转发到下一个下游服务器的代理或网关的数量。当客户机试图跟踪一个似乎失败或在中间链中循环的请求链时，这也很有用。
Max-Forwards = "Max-Forwards" ":" 1*DIGIT
Max-Forwards = "Max-Forwards" ":" 1*DIGIT
The Max-Forwards value is a decimal integer indicating the remaining number of times this request message is allowed to be forwarded.
Max Forwards值是一个十进制整数，表示允许转发此请求消息的剩余次数。
Each proxy or gateway recipient of a request containing a Max-Forwards header field MUST check and update its value prior to forwarding the request. If the received value is zero (0), the recipient MUST NOT forward the request. Instead, for the OPTIONS and REGISTER methods, it MUST respond as the final recipient. For all other methods, the server returns 483 (Too many hops).
包含Max Forwards标头字段的请求的每个代理或网关收件人必须在转发请求之前检查并更新其值。如果收到的值为零（0），则收件人不得转发请求。相反，对于选项和注册方法，它必须作为最终接收者响应。对于所有其他方法，服务器返回483（跳数太多）。
If the received Max-Forwards value is greater than zero, then the forwarded message MUST contain an updated Max-Forwards field with a value decremented by one (1).
如果接收到的最大转发值大于零，则转发消息必须包含一个值递减一（1）的更新最大转发字段。
Example:
例子：
Max-Forwards: 6
最大前锋数：6
The Organization general-header field conveys the name of the organization to which the entity issuing the request or response belongs. It MAY also be inserted by proxies at the boundary of an organization.
Organization general header字段表示发出请求或响应的实体所属的组织的名称。也可以由代理在组织边界插入。
The field MAY be used by client software to filter calls.
该字段可由客户端软件用于过滤呼叫。
Organization = "Organization" ":" *TEXT-UTF8
Organization = "Organization" ":" *TEXT-UTF8
The Priority request-header field indicates the urgency of the request as perceived by the client.
Priority request header（优先级请求标头）字段指示客户端感知到的请求的紧急程度。
Priority = "Priority" ":" priority-value
priority-value = "emergency" | "urgent" | "normal"
| "non-urgent"
Priority = "Priority" ":" priority-value
priority-value = "emergency" | "urgent" | "normal"
| "non-urgent"
It is RECOMMENDED that the value of "emergency" only be used when life, limb or property are in imminent danger.
建议仅当生命、肢体或财产处于迫在眉睫的危险时，才使用“紧急情况”的值。
Examples:
示例：
Subject: A tornado is heading our way! Priority: emergency
主题：龙卷风正向我们走来！紧急程度：紧急
Subject: Weekend plans Priority: non-urgent
主题：周末计划优先事项：非紧急
These are the values of RFC 2076 [30], with the addition of "emergency".
这些是RFC 2076[30]的值，并添加了“紧急情况”。
The Proxy-Authenticate response-header field MUST be included as part of a 407 (Proxy Authentication Required) response. The field value consists of a challenge that indicates the authentication scheme and parameters applicable to the proxy for this Request-URI.
代理身份验证响应头字段必须作为407（需要代理身份验证）响应的一部分包含。字段值由一个质询组成，该质询指示适用于此请求URI的代理的身份验证方案和参数。
Unlike its usage within HTTP, the Proxy-Authenticate header MUST be passed upstream in the response to the UAC. In SIP, only UAC's can authenticate themselves to proxies.
与HTTP中的用法不同，代理身份验证头必须在UAC的响应中向上游传递。在SIP中，只有UAC可以向代理进行身份验证。
The syntax for this header is defined in [H14.33]. See 14 for further details on its usage.
[H14.33]中定义了此标头的语法。有关其用法的更多详细信息，请参见14。
A client SHOULD cache the credentials used for a particular proxy server and realm for the next request to that server. Credentials are, in general, valid for a specific value of the Request-URI at a particular proxy server. If a client contacts a proxy server that has required authentication in the past, but the client does not have credentials for the particular Request-URI, it MAY attempt to use the most-recently used credential. The server responds with 401 (Unauthorized) if the client guessed wrong.
客户端应该缓存用于特定代理服务器的凭据，并为下一个对该服务器的请求缓存域。通常，凭据对于特定代理服务器上请求URI的特定值有效。如果客户端与过去需要身份验证的代理服务器联系，但该客户端没有特定请求URI的凭据，则它可能会尝试使用最近使用的凭据。如果客户端猜错了，服务器将以401（未经授权）响应。
This suggested caching behavior is motivated by proxies restricting phone calls to authenticated users. It seems likely that in most cases, all destinations require the same password. Note that end-to-end authentication is likely to be destination-specific.
这种建议的缓存行为的动机是代理将电话呼叫限制为经过身份验证的用户。似乎在大多数情况下，所有目的地都需要相同的密码。请注意，端到端身份验证可能是特定于目的地的。
The Proxy-Authorization request-header field allows the client to identify itself (or its user) to a proxy which requires authentication. The 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 request header（代理授权请求标头）字段允许客户端向需要身份验证的代理标识其自身（或其用户）。Proxy Authorization（代理授权）字段值由凭据组成，其中包含所请求资源的代理和/或领域的用户代理的身份验证信息。
Unlike Authorization, the Proxy-Authorization header field applies only to the next outbound proxy that demanded authentication using the Proxy- Authenticate field. When multiple proxies are used in a chain, the Proxy-Authorization header field is consumed by the first outbound proxy that was expecting to receive credentials. A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request.
与授权不同，Proxy Authorization header字段仅适用于要求使用Proxy-Authenticate字段进行身份验证的下一个出站代理。当在一个链中使用多个代理时，代理授权标头字段将由第一个希望接收凭据的出站代理使用。代理可以将来自客户端请求的凭据中继到下一个代理，如果这是代理协同验证给定请求的机制。
See [H14.34] for a definition of the syntax, and section 14 for a discussion of its usage.
有关语法的定义，请参见[H14.34]，有关其用法的讨论，请参见第14节。
The Proxy-Require header field is used to indicate proxy-sensitive features that MUST be supported by the proxy. Any Proxy-Require header field features that are not supported by the proxy MUST be negatively acknowledged by the proxy to the client if not supported. Proxy servers treat this field identically to the Require field.
Proxy Require标头字段用于指示代理必须支持的代理敏感功能。如果代理不支持任何代理要求标头字段功能，则代理必须向客户端否定地确认这些功能。代理服务器对该字段的处理与对Require字段的处理相同。
See Section 6.30 for more details on the mechanics of this message and a usage example.
有关此消息的机制和用法示例的更多详细信息，请参见第6.30节。
The Record-Route request and response header field is added to a request by any proxy that insists on being in the path of subsequent requests for the same call leg. It contains a globally reachable Request-URI that identifies the proxy server. Each proxy server adds its Request-URI to the beginning of the list.
Record Route request and response header（记录路由请求和响应头）字段由坚持位于同一呼叫分支的后续请求路径中的任何代理添加到请求中。它包含标识代理服务器的全局可访问请求URI。每个代理服务器将其请求URI添加到列表的开头。
The server copies the Record-Route header field unchanged into the response. (Record-Route is only relevant for 2xx responses.)
服务器会将记录路由头字段复制到响应中，但不会更改。（记录路线仅与2xx响应相关。）
The calling user agent client copies the Record-Route header into a Route header field of subsequent requests within the same call leg, reversing the order of requests, so that the first entry is closest to the user agent client. If the response contained a Contact header field, the calling user agent adds its content as the last Route header. Unless this would cause a loop, any client MUST send any subsequent requests for this call leg to the first Request-URI in the Route request header field and remove that entry.
呼叫用户代理客户端将记录路由头复制到同一呼叫分支内后续请求的路由头字段中，颠倒请求顺序，以便第一个条目最接近用户代理客户端。如果响应包含联系人标头字段，则调用用户代理将其内容添加为最后一个路由标头。除非这会导致循环，否则任何客户端都必须将此调用分支的任何后续请求发送到Route Request header字段中的第一个请求URI，并删除该条目。
The calling user agent MUST NOT use the Record-Route header field in requests that contain Route header fields.
呼叫用户代理不能在包含路由头字段的请求中使用记录路由头字段。
Some proxies, such as those controlling firewalls or in an automatic call distribution (ACD) system, need to maintain call state and thus need to receive any BYE and ACK packets for the call.
一些代理，如控制防火墙或自动呼叫分配（ACD）系统中的代理，需要保持呼叫状态，因此需要接收呼叫的任何BYE和ACK数据包。
The Record-Route header field has the following syntax:
记录路由标头字段具有以下语法：
Record-Route = "Record-Route" ":" 1# name-addr
Record-Route = "Record-Route" ":" 1# name-addr
Proxy servers SHOULD use the "maddr" URL parameter containing their address to ensure that subsequent requests are guaranteed to reach exactly the same server.
代理服务器应使用包含其地址的“maddr”URL参数，以确保后续请求能够到达完全相同的服务器。
Example for a request that has traversed the hosts ieee.org and bell-telephone.com , in that order:
按照以下顺序遍历主机ieee.org和bell-telephone.com的请求示例：
Record-Route: <sip:a.g.bell@bell-telephone.com>,
<sip:a.bell@ieee.org>
Record-Route: <sip:a.g.bell@bell-telephone.com>,
<sip:a.bell@ieee.org>
The Require request-header field is used by clients to tell user agent servers about options that the client expects the server to support in order to properly process the request. If a server does not understand the option, it MUST respond by returning status code 420 (Bad Extension) and list those options it does not understand in the Unsupported header.
客户机使用Require request header字段告知用户代理服务器客户机希望服务器支持的选项，以便正确处理请求。如果服务器不理解该选项，它必须通过返回状态代码420（错误扩展）进行响应，并在不支持的标头中列出它不理解的选项。
Require = "Require" ":" 1#option-tag
Require = "Require" ":" 1#option-tag
Example:
例子：
C->S: INVITE sip:watson@bell-telephone.com SIP/2.0
Require: com.example.billing
Payment: sheep_skins, conch_shells
C->S: INVITE sip:watson@bell-telephone.com SIP/2.0
Require: com.example.billing
Payment: sheep_skins, conch_shells
S->C: SIP/2.0 420 Bad Extension
Unsupported: com.example.billing
S->C: SIP/2.0 420 Bad Extension
Unsupported: com.example.billing
This is to make sure 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.
这是为了确保当双方都理解所有选项时，客户机-服务器交互将毫不延迟地进行，并且只有在不理解选项时（如上面的示例所示）才会减慢。对于匹配良好的客户机-服务器对，交互进行得很快，节省了协商机制通常需要的往返时间。此外，当客户端需要服务器不理解的功能时，它还消除了歧义。某些功能（如呼叫处理字段）仅对终端系统感兴趣。
Proxy and redirect servers MUST ignore features that are not understood. If a particular extension requires that intermediate devices support it, the extension MUST be tagged in the Proxy-Require field as well (see Section 6.28).
代理服务器和重定向服务器必须忽略未理解的功能。如果特定扩展需要中间设备支持，则必须在代理要求字段中标记该扩展（参见第6.28节）。
The Response-Key request-header field can be used by a client to request the key that the called user agent SHOULD use to encrypt the response with. The syntax is:
客户端可以使用Response Key request header字段请求被调用的用户代理用于加密响应的密钥。语法是：
Response-Key = "Response-Key" ":" key-scheme 1*SP #key-param
key-scheme = token
key-param = token "=" ( token | quoted-string )
Response-Key = "Response-Key" ":" key-scheme 1*SP #key-param
key-scheme = token
key-param = token "=" ( token | quoted-string )
The "key-scheme" gives the type of encryption to be used for the response. Section 13 describes security schemes.
“密钥方案”给出了用于响应的加密类型。第13节描述了安全方案。
If the client insists that the server return an encrypted response, it includes a
如果客户机坚持要求服务器返回加密响应，则会包含
Require: org.ietf.sip.encrypt-response
要求：org.ietf.sip.encrypt-response
header field in its request. If the server cannot encrypt for whatever reason, it MUST follow normal Require header field procedures and return a 420 (Bad Extension) response. If this Require header field is not present, a server SHOULD still encrypt if it can.
请求中的标头字段。如果服务器由于任何原因无法加密，它必须遵循正常的Require头字段过程并返回420（错误扩展）响应。如果此Require头字段不存在，服务器仍应加密（如果可以）。
The Retry-After general-header field can be used with a 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), 600 (Busy), or 603 (Decline) response to indicate when the called party anticipates being available again. The value of this field can be either an SIP-date or an integer number of seconds (in decimal) after the time of the response.
一般报头后重试字段可与503（服务不可用）响应一起使用，以指示该服务预期对请求客户端不可用的时间，并与404（未找到）、600（忙）或603（拒绝）响应一起使用，以指示被叫方预期何时再次可用。此字段的值可以是SIP日期，也可以是响应时间后的整数秒数（十进制）。
A REGISTER request MAY include this header field when deleting registrations with "Contact: * ;expires: 0". The Retry-After value then indicates when the user might again be reachable. The registrar MAY then include this information in responses to future calls.
当删除带有“联系人：*；过期：0”的注册时，注册请求可能包括此标题字段。然后，Retry After值指示何时可以再次访问用户。然后，注册官可将该信息包括在对未来呼叫的响应中。
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”参数表示从可用性的初始时间开始，被叫方可以到达的时间。如果未给出持续时间参数，则假定服务无限期可用。
Retry-After = "Retry-After" ":" ( SIP-date | delta-seconds )
[ comment ] [ ";" "duration" "=" delta-seconds ]
Retry-After = "Retry-After" ":" ( SIP-date | delta-seconds )
[ comment ] [ ";" "duration" "=" delta-seconds ]
Examples of its use are
其使用示例如下：
Retry-After: Mon, 21 Jul 1997 18:48:34 GMT (I'm in a meeting)
Retry-After: Mon, 21 Jul 1997 18:48:34 GMT (I'm in a meeting)
Retry-After: Mon, 01 Jan 9999 00:00:00 GMT
(Dear John: Don't call me back, ever)
Retry-After: Fri, 26 Sep 1997 21:00:00 GMT;duration=3600
Retry-After: 120
Retry-After: Mon, 01 Jan 9999 00:00:00 GMT
(Dear John: Don't call me back, ever)
Retry-After: Fri, 26 Sep 1997 21:00:00 GMT;duration=3600
Retry-After: 120
In the third example, the callee is reachable for one hour starting at 21:00 GMT. In the last example, the delay is 2 minutes.
在第三个示例中，从格林威治标准时间21:00开始，被叫方在一个小时内是可到达的。在最后一个示例中，延迟为2分钟。
The Route request-header field determines the route taken by a request. Each host removes the first entry and then proxies the request to the host listed in that entry, also using it as the Request-URI. The operation is further described in Section 6.29.
Route request header字段确定请求采用的路由。每个主机删除第一个条目，然后将请求代理给该条目中列出的主机，并将其用作请求URI。第6.29节进一步描述了该操作。
The Route header field has the following syntax:
Route header字段具有以下语法：
Route = "Route" ":" 1# name-addr
Route = "Route" ":" 1# name-addr
The Server response-header field contains information about the software used by the user agent server to handle the request. The syntax for this field is defined in [H14.39].
服务器响应标头字段包含有关用户代理服务器用于处理请求的软件的信息。[H14.39]中定义了此字段的语法。
This is intended to provide a summary, or to indicate the nature, of the call, allowing call filtering without having to parse the session description. (Also, the session description does not have to use the same subject indication as the invitation.)
这旨在提供呼叫的摘要或指示呼叫的性质，从而允许在不必解析会话描述的情况下进行呼叫过滤。（此外，会话描述不必使用与邀请相同的主题指示。）
Subject = ( "Subject" | "s" ) ":" *TEXT-UTF8
Subject = ( "Subject" | "s" ) ":" *TEXT-UTF8
Example:
例子：
Subject: Tune in - they are talking about your work!
Subject: Tune in - they are talking about your work!
The timestamp general-header field describes when the client sent the request to the server. The value of the timestamp is of significance only to the client and it MAY use any timescale. The server MUST echo the exact same value and MAY, if it has accurate information about this, add a floating point number indicating the number of seconds that have elapsed since it has received the request. The timestamp is used by the client to compute the round-trip time to the server so that it can adjust the timeout value for retransmissions.
timestamp general header字段描述客户端何时向服务器发送请求。时间戳的值仅对客户端有意义，它可以使用任何时间刻度。服务器必须回显完全相同的值，并且如果有关于该值的准确信息，可以添加一个浮点数，指示自收到请求以来经过的秒数。客户机使用时间戳来计算到服务器的往返时间，以便调整重传的超时值。
Timestamp = "Timestamp" ":" *(DIGIT) [ "." *(DIGIT) ] [ delay ]
delay = *(DIGIT) [ "." *(DIGIT) ]
Timestamp = "Timestamp" ":" *(DIGIT) [ "." *(DIGIT) ] [ delay ]
delay = *(DIGIT) [ "." *(DIGIT) ]
Note that there MUST NOT be any LWS between a DIGIT and the decimal point.
请注意，数字和小数点之间不得有任何LWS。
The To general-header field specifies recipient of the request, with the same SIP URL syntax as the From field.
To general标头字段指定请求的收件人，其SIP URL语法与From字段相同。
To = ( "To" | "t" ) ":" ( name-addr | addr-spec )
*( ";" addr-params )
To = ( "To" | "t" ) ":" ( name-addr | addr-spec )
*( ";" addr-params )
Requests and responses MUST contain a To general-header field, indicating the desired recipient of the request. The optional "display-name" is meant to be rendered by a human-user interface. The UAS or redirect server copies the To header field into its response, and MUST add a "tag" parameter if the request contained more than one Via header field.
请求和响应必须包含To general标头字段，指示请求的所需收件人。可选的“显示名称”是指由人机界面呈现。UAS或重定向服务器将To头字段复制到其响应中，如果请求包含多个Via头字段，则必须添加“tag”参数。
If there was more than one Via header field, the request was handled by at least one proxy server. Since the receiver cannot know whether any of the proxy servers forked the request, it is safest to assume that they might have.
如果存在多个Via标头字段，则请求至少由一个代理服务器处理。由于接收方无法知道是否有任何代理服务器分叉了请求，因此最安全的做法是假设它们可能分叉了请求。
The SIP-URL MUST NOT contain the "transport-param", "maddr-param", "ttl-param", or "headers" elements. A server that receives a SIP-URL with these elements removes them before further processing.
SIP-URL不得包含“传输参数”、“maddr参数”、“ttl参数”或“标头”元素。接收包含这些元素的SIP-URL的服务器将在进一步处理之前删除这些元素。
The "tag" parameter serves as a general mechanism to distinguish multiple instances of a user identified by a single SIP URL. As proxies can fork requests, the same request can reach multiple instances of a user (mobile and home phones, for example). As each can respond, there needs to be a means to distinguish the responses from each at the caller. The situation also arises with multicast requests. The tag in the To header field serves to distinguish responses at the UAC. It MUST be placed in the To field of the response by each instance when there is a possibility that the request was forked at an intermediate proxy. The "tag" MUST be added by UAS, registrars and redirect servers, but MUST NOT be inserted into responses forwarded upstream by proxies. The "tag" is added for all definitive responses for all methods, and MAY be added for informational responses from a UAS or redirect server. All subsequent transactions between two entities MUST include the "tag" parameter, as described in Section 11.
“tag”参数用作区分由单个SIP URL标识的用户的多个实例的通用机制。由于代理可以分叉请求，同一请求可以到达用户的多个实例（例如，移动电话和家用电话）。由于每个人都可以响应，因此需要有一种方法来区分呼叫者的响应。多播请求也会出现这种情况。To header字段中的标记用于区分UAC上的响应。当请求可能在中间代理处分叉时，每个实例都必须将其放在响应的To字段中。“标签”必须由UAS、注册器和重定向服务器添加，但不得插入到代理向上游转发的响应中。为所有方法的所有最终响应添加“标记”，并且可以为来自UAS或重定向服务器的信息性响应添加“标记”。如第11节所述，两个实体之间的所有后续交易必须包括“标记”参数。
See Section 6.21 for details of the "tag" parameter.
有关“标记”参数的详细信息，请参见第6.21节。
The "tag" parameter in To headers is ignored when matching responses to requests that did not contain a "tag" in their To header.
当将响应与在其To标头中不包含“标记”的请求进行匹配时，将忽略To标头中的“标记”参数。
A SIP server returns a 400 (Bad Request) response if it receives a request with a To header field containing a URI with a scheme it does not recognize.
如果SIP服务器接收到一个带有To头字段的请求，该字段包含一个URI，该URI包含一个它无法识别的方案，则它将返回400（错误请求）响应。
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.
即使“display name”为空，如果“addr spec”包含逗号、问号或分号，也必须使用“name addr”表单。
The following are examples of valid To headers:
以下是有效到标题的示例：
To: The Operator <sip:operator@cs.columbia.edu>;tag=287447
To: sip:+12125551212@server.phone2net.com
To: The Operator <sip:operator@cs.columbia.edu>;tag=287447
To: sip:+12125551212@server.phone2net.com
Call-ID, To and From are needed to identify a call leg. The distinction between call and call leg matters in calls with multiple responses from a forked request. The "tag" is added to the To header field in the response to allow forking of future requests for the same call by proxies, while addressing only one of the possibly several responding user agent servers. It also allows several instances of the callee to send requests that can be distinguished.
需要呼叫ID、收件人和发件人来识别呼叫分支。在一个分支请求中有多个响应的调用中，调用和调用分支之间的区别很重要。“tag”被添加到响应中的to header字段中，以允许代理将来对同一调用的请求进行分叉，同时只对可能几个响应的用户代理服务器中的一个进行寻址。它还允许被叫方的多个实例发送可以区分的请求。
The Unsupported response-header field lists the features not supported by the server. See Section 6.30 for a usage example and motivation.
Unsupported response header字段列出了服务器不支持的功能。有关使用示例和动机，请参见第6.30节。
Syntax:
语法：
Unsupported = "Unsupported" ":" 1#option-tag
Unsupported = "Unsupported" ":" 1#option-tag
The User-Agent general-header field contains information about the client user agent originating the request. The syntax and semantics are defined in [H14.42].
User Agent general标头字段包含有关发起请求的客户端用户代理的信息。[H14.42]中定义了语法和语义。
The Via field indicates the path taken by the request so far. This prevents request looping and ensures replies take the same path as the requests, which assists in firewall traversal and other unusual routing situations.
Via字段指示到目前为止请求所采用的路径。这可以防止请求循环，并确保回复与请求采用相同的路径，这有助于防火墙穿越和其他异常路由情况。
The client originating the request MUST insert into the request a Via field containing its host name or network address and, if not the default port number, the port number at which it wishes to receive responses. (Note that this port number can differ from the UDP source port number of the request.) A fully-qualified domain name is RECOMMENDED. Each subsequent proxy server that sends the request onwards MUST add its own additional Via field before any existing Via fields. A proxy that receives a redirection (3xx) response and then searches recursively, MUST use the same Via headers as on the original proxied request.
发起请求的客户端必须在请求中插入一个Via字段，该字段包含其主机名或网络地址，如果不是默认端口号，则包含希望接收响应的端口号。（请注意，此端口号可能不同于请求的UDP源端口号。）建议使用完全限定的域名。随后发送请求的每个代理服务器必须在任何现有的Via字段之前添加自己的附加Via字段。接收重定向（3xx）响应然后递归搜索的代理必须使用与原始代理请求相同的Via头。
A proxy SHOULD check the top-most Via header field to ensure that it contains the sender's correct network address, as seen from that proxy. If the sender's address is incorrect, the proxy MUST add an additional "received" attribute, as described 6.40.2.
代理应检查最顶端的“通过头”字段，以确保它包含发件人的正确网络地址，从该代理中可以看到。如果发件人地址不正确，则代理必须添加额外的“已接收”属性，如6.40.2所述。
A host behind a network address translator (NAT) or firewall may not be able to insert a network address into the Via header that can be reached by the next hop beyond
网络地址转换器（NAT）或防火墙后面的主机可能无法将网络地址插入到下一个跃点可以到达的Via头中
the NAT. Use of the received attribute allows SIP requests to traverse NAT's which only modify the source IP address. NAT's which modify port numbers, called Network Address Port Translator's (NAPT) will not properly pass SIP when transported on UDP, in which case an application layer gateway is required. When run over TCP, SIP stands a better chance of traversing NAT's, since its behavior is similar to HTTP in this case (but of course on different ports).
纳特。使用received属性允许SIP请求遍历仅修改源IP地址的NAT。修改端口号的NAT（称为网络地址端口转换器（NAPT））在UDP上传输时将无法正确通过SIP，在这种情况下，需要一个应用层网关。在TCP上运行时，SIP更有可能遍历NAT，因为在这种情况下，它的行为类似于HTTP（当然是在不同的端口上）。
A proxy sending a request to a multicast address MUST add the "maddr" parameter to its Via header field, and SHOULD add the "ttl" parameter. If a server receives a request which contained an "maddr" parameter in the topmost Via field, it SHOULD send the response to the multicast address listed in the "maddr" parameter.
向多播地址发送请求的代理必须将“maddr”参数添加到其Via标头字段中，并应添加“ttl”参数。如果服务器接收到的请求在最顶端的Via字段中包含“maddr”参数，则应将响应发送到“maddr”参数中列出的多播地址。
If a proxy server receives a request which contains its own address in the Via header value, it MUST respond with a 482 (Loop Detected) status code.
如果代理服务器接收到在Via标头值中包含其自身地址的请求，则必须使用482（检测到循环）状态代码进行响应。
A proxy server MUST NOT forward a request to a multicast group which already appears in any of the Via headers.
代理服务器不得将请求转发到已出现在任何Via标头中的多播组。
This prevents a malfunctioning proxy server from causing loops. Also, it cannot be guaranteed that a proxy server can always detect that the address returned by a location service refers to a host listed in the Via list, as a single host may have aliases or several network interfaces.
这可以防止出现故障的代理服务器导致循环。此外，无法保证代理服务器始终能够检测到位置服务返回的地址引用Via列表中列出的主机，因为单个主机可能具有别名或多个网络接口。
Normally, every host that sends or forwards a SIP message adds a Via field indicating the path traversed. However, it is possible that Network Address Translators (NATs) changes the source address and port of the request (e.g., from net-10 to a globally routable address), in which case the Via header field cannot be relied on to route replies. To prevent this, a proxy SHOULD check the top-most Via header field to ensure that it contains the sender's correct network address, as seen from that proxy. If the sender's address is incorrect, the proxy MUST add a "received" parameter to the Via header field inserted by the previous hop. Such a modified Via header field is known as a receiver-tagged Via header field. An example is:
通常，发送或转发SIP消息的每个主机都会添加一个Via字段，指示所经过的路径。但是，网络地址转换器（NAT）可能会更改请求的源地址和端口（例如，从net-10更改为全局可路由地址），在这种情况下，无法依赖Via标头字段来路由回复。为了防止出现这种情况，代理应该检查最顶端的Via头字段，以确保它包含发件人的正确网络地址，如从该代理看到的那样。如果发送方地址不正确，则代理必须将“received”参数添加到上一跳插入的Via标头字段中。这种修改过的Via报头字段称为经报头字段标记的接收器。例如：
Via: SIP/2.0/UDP erlang.bell-telephone.com:5060
Via: SIP/2.0/UDP 10.0.0.1:5060 ;received=199.172.136.3
Via: SIP/2.0/UDP erlang.bell-telephone.com:5060
Via: SIP/2.0/UDP 10.0.0.1:5060 ;received=199.172.136.3
In this example, the message originated from 10.0.0.1 and traversed a NAT with the external address border.ieee.org (199.172.136.3) to reach erlang.bell-telephone.com. The latter noticed the mismatch, and added a parameter to the previous hop's Via header field, containing the address that the packet actually came from. (Note that the NAT border.ieee.org is not a SIP server.)
在本例中，消息源于10.0.0.1，并通过外部地址border.ieee.org（199.172.136.3）的NAT到达erlang.bell-telephone.com。后者注意到不匹配，并在前一跳的Via头字段中添加了一个参数，其中包含数据包实际来自的地址。（请注意，NAT border.ieee.org不是SIP服务器。）
Via header fields in responses are processed by a proxy or UAC according to the following rules:
代理或UAC根据以下规则处理响应中的Via标头字段：
1. The first Via header field should indicate the proxy or client processing this response. If it does not, discard the message. Otherwise, remove this Via field.
1. 第一个Via标头字段应指示处理此响应的代理或客户端。如果没有，则丢弃该消息。否则，请删除此Via字段。
2. If there is no second Via header field, this response is destined for this client. Otherwise, the processing depends on whether the Via field contains a "maddr" parameter or is a receiver-tagged field:
2. 如果没有第二个Via头字段，则此响应将发送到此客户端。否则，处理取决于Via字段是否包含“maddr”参数或是否为接收器标记字段：
- If the second Via header field contains a "maddr" parameter, send the response to the multicast address listed there, using the port indicated in "sent-by", or port 5060 if none is present. 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. For robustness, responses MUST be sent to the address indicated in the "maddr" parameter even if it is not a multicast address.
- 如果第二个Via标头字段包含“maddr”参数，则使用“发送人”中指示的端口或端口5060（如果不存在）将响应发送到此处列出的多播地址。应使用“TTL”参数中指示的TTL发送响应，如果该参数不存在，则应使用1的TTL发送响应。为了健壮性，响应必须发送到“maddr”参数中指示的地址，即使它不是多播地址。
- If the second Via header field does not contain a "maddr" parameter and is a receiver-tagged field (Section 6.40.2), send the message to the address in the "received" parameter, using the port indicated in the "sent-by" value, or using port 5060 if none is present.
- 如果第二个Via标头字段不包含“maddr”参数，并且是一个带接收器标签的字段（第6.40.2节），则使用“发送人”值中指示的端口，或使用端口5060（如果不存在）将消息发送到“接收”参数中的地址。
- If neither of the previous cases apply, send the message to the address indicated by the "sent-by" value in the second Via header field.
- 如果上述两种情况均不适用，则将消息发送至第二个Via标头字段中“发送人”值指示的地址。
A UAS or redirect server sends a response based on one of the following rules:
UAS或重定向服务器根据以下规则之一发送响应：
o If the first Via header field in the request contains a "maddr" parameter, send the response to the multicast address
o 如果请求中的第一个Via头字段包含“maddr”参数，则将响应发送到多播地址
listed there, using the port indicated in "sent-by", or port 5060 if none is present. 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. For robustness, responses MUST be sent to the address indicated in the "maddr" parameter even if it is not a multicast address.
此处列出，使用“发送人”中指示的端口，或如果不存在端口5060。应使用“TTL”参数中指示的TTL发送响应，如果该参数不存在，则应使用1的TTL发送响应。为了健壮性，响应必须发送到“maddr”参数中指示的地址，即使它不是多播地址。
o If the address in the "sent-by" value of the first Via field differs from the source address of the packet, send the response to the actual packet source address, similar to the treatment for receiver-tagged Via header fields (Section 6.40.2).
o 如果第一个Via字段“发送人”值中的地址与数据包的源地址不同，则将响应发送到实际数据包源地址，类似于对通过报头字段标记的接收器的处理（第6.40.2节）。
o If neither of these conditions is true, send the response to the address contained in the "sent-by" value. If the request was sent using TCP, use the existing TCP connection if available.
o 如果这两个条件都不成立，则将响应发送到“发送人”值中包含的地址。如果请求是使用TCP发送的，请使用现有的TCP连接（如果可用）。
The format for a Via header field is shown in Fig. 11. The defaults for "protocol-name" and "transport" are "SIP" and "UDP", respectively. The "maddr" parameter, designating the multicast address, and the "ttl" parameter, designating the time-to-live (TTL) value, are included only if the request was sent via multicast. The "received" parameter is added only for receiver-added Via fields (Section 6.40.2). For reasons of privacy, a client or proxy may wish to hide its Via information by encrypting it (see Section 6.22). The "hidden" parameter is included if this header field was hidden by the upstream proxy (see 6.22). Note that privacy of the proxy relies on the cooperation of the next hop, as the next-hop proxy will, by necessity, know the IP address and port number of the source host.
Via报头字段的格式如图11所示。“协议名称”和“传输”的默认值分别为“SIP”和“UDP”。仅当请求通过多播发送时，才包括指定多播地址的“maddr”参数和指定生存时间（ttl）值的“ttl”参数。“received”（接收）参数仅针对通过字段添加的接收器添加（第6.40.2节）。出于隐私考虑，客户或代理可能希望通过加密来隐藏其Via信息（参见第6.22节）。如果上游代理隐藏了此标题字段，则包含“隐藏”参数（见6.22）。请注意，代理的隐私依赖于下一跳的合作，因为下一跳代理需要知道源主机的IP地址和端口号。
The "branch" parameter is included by every forking proxy. The token MUST be unique for each distinct request generated when a proxy forks. CANCEL requests MUST have the same branch value as the corresponding forked request. When a response arrives at the proxy it can use the branch value to figure out which branch the response corresponds to. A proxy which generates a single request (non-forking) MAY also insert the "branch" parameter. The identifier has to be unique only within a set of isomorphic requests.
每个分叉代理都包含“branch”参数。对于代理分叉时生成的每个不同请求，令牌必须是唯一的。取消请求必须与相应的分叉请求具有相同的分支值。当响应到达代理时，它可以使用分支值来确定响应对应于哪个分支。生成单个请求（非分叉）的代理也可以插入“分支”参数。标识符必须仅在一组同构请求中是唯一的。
Via: SIP/2.0/UDP first.example.com:4000;ttl=16
;maddr=224.2.0.1 ;branch=a7c6a8dlze (Example)
Via: SIP/2.0/UDP adk8
Via: SIP/2.0/UDP first.example.com:4000;ttl=16
;maddr=224.2.0.1 ;branch=a7c6a8dlze (Example)
Via: SIP/2.0/UDP adk8
Via = ( "Via" | "v") ":" 1#( sent-protocol sent-by
*( ";" via-params ) [ comment ] )
via-params = via-hidden | via-ttl | via-maddr
| via-received | via-branch
via-hidden = "hidden"
via-ttl = "ttl" "=" ttl
via-maddr = "maddr" "=" maddr
via-received = "received" "=" host
via-branch = "branch" "=" token
sent-protocol = protocol-name "/" protocol-version "/" transport
protocol-name = "SIP" | token
protocol-version = token
transport = "UDP" | "TCP" | token
sent-by = ( host [ ":" port ] ) | ( concealed-host )
concealed-host = token
ttl = 1*3DIGIT ; 0 to 255
Via = ( "Via" | "v") ":" 1#( sent-protocol sent-by
*( ";" via-params ) [ comment ] )
via-params = via-hidden | via-ttl | via-maddr
| via-received | via-branch
via-hidden = "hidden"
via-ttl = "ttl" "=" ttl
via-maddr = "maddr" "=" maddr
via-received = "received" "=" host
via-branch = "branch" "=" token
sent-protocol = protocol-name "/" protocol-version "/" transport
protocol-name = "SIP" | token
protocol-version = token
transport = "UDP" | "TCP" | token
sent-by = ( host [ ":" port ] ) | ( concealed-host )
concealed-host = token
ttl = 1*3DIGIT ; 0 to 255
Figure 11: Syntax of Via header field
图11:Via头字段的语法
The Warning response-header field is used to carry additional information about the status of a response. Warning headers are sent with responses and have the following format:
警告响应标题字段用于携带有关响应状态的附加信息。警告标题随响应一起发送，格式如下：
Warning = "Warning" ":" 1#warning-value
warning-value = warn-code SP warn-agent SP warn-text
warn-code = 3DIGIT
warn-agent = ( host [ ":" port ] ) | pseudonym
; the name or pseudonym of the server adding
; the Warning header, for use in debugging
warn-text = quoted-string
Warning = "Warning" ":" 1#warning-value
warning-value = warn-code SP warn-agent SP warn-text
warn-code = 3DIGIT
warn-agent = ( host [ ":" port ] ) | pseudonym
; the name or pseudonym of the server adding
; the Warning header, for use in debugging
warn-text = quoted-string
A response MAY carry more than one Warning header.
一个响应可能包含多个警告标题。
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 cache or user, the Accept-Language field in a request, or the Content-Language field in a response. The default language is i-default [31].
“警告文本”应采用自然语言，最有可能让接收响应的人类用户理解。此决定可以基于任何可用的知识，例如缓存或用户的位置、请求中的接受语言字段或响应中的内容语言字段。默认语言为i-default[31]。
Any server MAY add Warning headers to a response. Proxy servers MUST place additional Warning headers before any Authorization headers. Within that constraint, Warning headers MUST be added after any existing Warning headers not covered by a signature. A proxy server MUST NOT delete any Warning header field that it received with a response.
任何服务器都可以向响应中添加警告标头。代理服务器必须在任何授权标头之前放置其他警告标头。在该约束范围内，必须在签名未包含的任何现有警告标头之后添加警告标头。代理服务器不得删除其在响应中收到的任何警告标头字段。
When multiple Warning headers are attached to a response, the user agent SHOULD display as many of them as possible, in the order that they appear in the response. If it is not possible to display all of the warnings, the user agent first displays warnings that appear early in the response.
当多个警告标题附加到响应时，用户代理应按照它们在响应中出现的顺序显示尽可能多的警告标题。如果无法显示所有警告，用户代理将首先显示响应早期出现的警告。
The warn-code consists of three digits. A first digit of "3" indicates warnings specific to SIP.
警告代码由三位数字组成。第一位数字“3”表示特定于SIP的警告。
This is a list of the currently-defined "warn-code"s, each with a recommended warn-text in English, and a description of its meaning. Note that these warnings describe failures induced by the session description.
这是一个当前定义的“警告代码”列表，每个代码都有一个推荐的英文警告文本及其含义说明。请注意，这些警告描述了会话描述导致的故障。
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是不属于上述类别之一的杂项警告。
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, as in the example below, can be defined through IANA.
可以通过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'”
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 Request-URI. See [H14.46] for a definition of the syntax, and section 14 for an overview of usage.
WWW Authenticate响应头字段必须包含在401（未经授权）响应消息中。字段值由至少一个质询组成，该质询指示认证方案和适用于请求URI的参数。参见[H14.46]了解语法定义，参见第14节了解用法概述。
The content of the "realm" parameter SHOULD be displayed to the user. A user agent SHOULD cache the authorization credentials for a given value of the destination (To header) and "realm" and attempt to re-use these values on the next request for that destination.
“realm”参数的内容应该显示给用户。用户代理应缓存目标（To标头）和“领域”的给定值的授权凭据，并在下一个目标请求时尝试重新使用这些值。
In addition to the "basic" and "digest" authentication schemes defined in the specifications cited above, SIP defines a new scheme, PGP (RFC 2015, [32]), Section 15. Other schemes, such as S/MIME, are for further study.
除了上述规范中定义的“基本”和“摘要”认证方案外，SIP还定义了一个新方案，即PGP（RFC 2015，[32]），第15节。其他方案，如S/MIME，有待进一步研究。
7 Status Code Definitions
7状态代码定义
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. Response codes not defined by HTTP/1.1 have codes x80 upwards to avoid clashes with future HTTP response codes. Also, SIP defines a new class, 6xx. The default behavior for unknown response codes is given for each category of codes.
响应代码与HTTP/1.1响应代码一致并扩展。并非所有HTTP/1.1响应代码都是适当的，这里只给出了适当的代码。不应使用其他HTTP/1.1响应代码。HTTP/1.1未定义的响应代码的代码向上为x80，以避免与将来的HTTP响应代码发生冲突。此外，SIP定义了一个新类6xx。对于每种类型的代码，都给出了未知响应代码的默认行为。
Informational responses indicate that the server or proxy contacted is performing some further action and does not yet have a definitive response. The client SHOULD wait for a further response from the server, and the server SHOULD send such a response without further prompting. A server SHOULD send a 1xx response if it expects to take more than 200 ms to obtain a final response. A server MAY issue zero or more 1xx responses, with no restriction on their ordering or uniqueness. Note that 1xx responses are not transmitted reliably, that is, they do not cause the client to send an ACK. Servers are free to retransmit informational responses and clients can inquire about the current state of call processing by re-sending the request.
信息性响应表示所联系的服务器或代理正在执行某些进一步的操作，并且尚未得到确定的响应。客户端应该等待来自服务器的进一步响应，服务器应该在没有进一步提示的情况下发送这样的响应。如果服务器预计需要200毫秒以上才能获得最终响应，则应发送1x响应。服务器可能会发出零个或多个1xx响应，对其顺序或唯一性没有限制。请注意，1xx响应不会可靠地传输，也就是说，它们不会导致客户端发送ACK。服务器可以自由地重新传输信息响应，客户端可以通过重新发送请求来查询当前的呼叫处理状态。
Some unspecified action is being taken on behalf of this call (e.g., a database is being consulted), but the user has not yet been located.
正在为此呼叫采取一些未指明的操作（例如，正在咨询数据库），但尚未找到用户。
The called user agent has located a possible location where the user has registered recently and is trying to alert the user.
被调用的用户代理已找到一个可能的位置，用户最近已在该位置注册，并且正在尝试向用户发出警报。
A proxy 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 callee 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, e.g., "5 calls queued; expected waiting time is 15 minutes". The server MAY issue several 182 responses to update the caller about the status of the queued call.
被叫方暂时不可用，但被叫方已决定将呼叫排队，而不是拒绝呼叫。当被调用方可用时，它将返回相应的最终状态响应。原因短语可能提供有关呼叫状态的更多详细信息，例如，“5个呼叫已排队；预期等待时间为15分钟”。服务器可以发出若干响应来更新呼叫者关于排队呼叫的状态。
The request was successful and MUST terminate a search.
请求成功，必须终止搜索。
The request has succeeded. The information returned with the response depends on the method used in the request, for example:
请求已成功。随响应返回的信息取决于请求中使用的方法，例如：
BYE: The call has been terminated. The message body is empty.
再见：电话已被终止。消息正文为空。
CANCEL: The search has been cancelled. The message body is empty.
取消：已取消搜索。消息正文为空。
INVITE: The callee has agreed to participate; the message body indicates the callee's capabilities.
邀请：被呼叫方已同意参与；消息正文指示被调用方的功能。
OPTIONS: The callee has agreed to share its capabilities, included in the message body.
选项：被调用方已同意共享其功能，包括在消息正文中。
REGISTER: The registration has succeeded. The client treats the message body according to its Content-Type.
注册：注册已成功。客户端根据消息的内容类型处理消息体。
3xx responses give information about the user's new location, or about alternative services that might be able to satisfy the call. They SHOULD terminate an existing search, and MAY cause the initiator to begin a new search if appropriate.
3xx响应提供有关用户新位置的信息，或关于可能满足呼叫的替代服务的信息。它们应该终止现有的搜索，并可能导致启动器在适当的情况下开始新的搜索。
Any redirection (3xx) response MUST NOT suggest any of the addresses in the Via (Section 6.40) path of the request in the Contact header field. (Addresses match if their host and port number match.)
任何重定向（3xx）响应不得在Contact header字段中建议请求的Via（第6.40节）路径中的任何地址。（如果其主机号和端口号匹配，则地址匹配。）
To avoid forwarding loops, a user agent client or proxy MUST check whether the address returned by a redirect server equals an address tried earlier.
为了避免转发循环，用户代理客户端或代理必须检查重定向服务器返回的地址是否等于先前尝试的地址。
The address in the request resolved to several choices, each with its own specific location, and the user (or user agent) can select a preferred communication end point and redirect its request to that location.
请求中的地址解析为多个选项，每个选项都有自己的特定位置，用户（或用户代理）可以选择首选通信端点并将其请求重定向到该位置。
The response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate, if allowed by the Accept request header. The entity format is specified by the media type given in the Content-Type header field. The choices SHOULD also be listed as Contact fields (Section 6.13). Unlike HTTP, the SIP response MAY contain several Contact fields or a list of addresses in a Contact field. User agents 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.
响应应包括一个实体，该实体包含资源特征和位置列表，用户或用户代理可以从中选择最合适的一个（如果Accept请求标头允许）。实体格式由内容类型标题字段中给定的媒体类型指定。这些选项也应列为联系人字段（第6.13节）。与HTTP不同，SIP响应可能包含多个联系人字段或联系人字段中的地址列表。用户代理可以使用Contact header字段值进行自动重定向，也可以要求用户确认选择。然而，本规范并未定义此类自动选择的任何标准。
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 6.13). The caller 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中的地址处找不到用户，请求客户端应在联系人标头字段给出的新地址处重试（第6.13节）。调用方应使用此新值更新任何本地目录、通讯簿和用户位置缓存，并将未来的请求重定向到列出的地址。
The requesting client SHOULD retry the request at the new address(es) given by the Contact header field (Section 6.13). The duration of the redirection can be indicated through an Expires (Section 6.20) header. If there is no explicit expiration time, the address is only valid for this call and MUST NOT be cached for future calls.
请求客户端应在联系人标头字段（第6.13节）给出的新地址重试请求。重定向的持续时间可以通过Expires（第6.20节）标题指示。如果没有明确的过期时间，则该地址仅对此调用有效，并且不能缓存以供将来调用。
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 responses MUST only be generated by user agent servers.
必须通过联系人字段提供的代理访问请求的资源。Contact字段提供代理的URI。收件人应通过代理重复此单个请求。305响应只能由用户代理服务器生成。
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 (e.g., 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 request requires user authentication.
请求需要用户身份验证。
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 not allowed for the address identified by the Request-URI. The response MUST include an Allow header field containing a list of valid methods for the indicated address.
请求行中指定的方法不允许用于请求URI标识的地址。响应必须包括一个Allow header字段，其中包含指定地址的有效方法列表。
The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request.
根据请求中发送的accept标头，由请求标识的资源只能生成具有不可接受内容特征的响应实体。
This code is similar to 401 (Unauthorized), but indicates that the client MUST first authenticate itself with the proxy. The proxy MUST return a Proxy-Authenticate header field (section 6.26) containing a challenge applicable to the proxy for the requested resource. The client MAY repeat the request with a suitable Proxy-Authorization header field (section 6.27). SIP access authentication is explained in section 13.2 and 14.
此代码类似于401（未经授权），但表示客户端必须首先向代理进行身份验证。代理必须返回一个代理身份验证标头字段（第6.26节），其中包含适用于所请求资源的代理的质询。客户可以使用合适的代理授权标头字段重复请求（第6.27节）。第13.2节和第14节解释了SIP访问认证。
This status code is used for applications where access to the communication channel (e.g., a telephony gateway) rather than the callee requires authentication.
此状态码用于需要身份验证而不是被叫方访问通信信道（例如，电话网关）的应用程序。
The server could not produce a response, e.g., a user location, within the time indicated in the Expires request-header field. The client MAY repeat the request without modifications at any later time.
服务器无法在Expires请求标头字段中指示的时间内生成响应，例如用户位置。客户端可以在以后任何时候重复请求而不进行修改。
The request could not be completed due to a conflict with the current state of the resource. This response is returned if the action parameter in a REGISTER request conflicts with existing registrations.
由于与资源的当前状态冲突，无法完成请求。如果注册请求中的操作参数与现有注册冲突，则返回此响应。
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 refuses to accept the request without a defined Content-Length. The client MAY repeat the request if it adds a valid Content-Length header field containing the length of the message-body in the request message.
服务器拒绝接受没有定义内容长度的请求。如果客户端在请求消息中添加了包含消息正文长度的有效内容长度头字段，则客户端可能会重复该请求。
The server is refusing to process a request because the request entity 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 requested resource for the requested method. The server SHOULD return a list of acceptable formats using the Accept, Accept-Encoding and Accept-Language header fields.
服务器拒绝为请求提供服务，因为请求的消息体的格式不受请求方法的请求资源支持。服务器应使用Accept、Accept Encoding和Accept Language标头字段返回可接受格式的列表。
The server did not understand the protocol extension specified in a Require (Section 6.30) header field.
服务器不理解Require（第6.30节）头字段中指定的协议扩展。
The callee's end system was contacted successfully but the callee is currently unavailable (e.g., not logged in or logged in in such a manner as to preclude communication with the callee). The response MAY indicate a better time to call in the Retry-After header. The user could also be available elsewhere (unbeknownst to this host), thus, this response does not terminate any searches. The reason phrase SHOULD indicate a more precise cause as to why the callee is unavailable. This value SHOULD be setable by the user agent. Status 486 (Busy Here) MAY be used to more precisely indicate a particular reason for the call failure.
已成功联系被叫方的终端系统，但被叫方当前不可用（例如，未登录或登录方式会妨碍与被叫方的通信）。响应可能指示在重试后报头中调用的更好时间。用户也可以在其他地方使用（此主机不知道），因此，此响应不会终止任何搜索。“原因”短语应指明被呼叫方不可用的更确切原因。此值应由用户代理设置。状态486（此处忙）可用于更精确地指示呼叫失败的特定原因。
This status is also returned by a redirect 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 is returned under two conditions: The server received a BYE request that does not match any existing call leg or the server received a CANCEL request that does not match any existing transaction. (A server simply discards an ACK referring to an unknown transaction.)
此状态在两种情况下返回：服务器收到与任何现有呼叫分支不匹配的BYE请求，或服务器收到与任何现有事务不匹配的取消请求。（服务器只是丢弃引用未知事务的ACK。）
The server received a request with a Via (Section 6.40) path containing itself.
服务器接收到一个请求，该请求具有包含其自身的Via（第6.40节）路径。
The server received a request that contains more Via entries (hops) (Section 6.40) than allowed by the Max-Forwards (Section 6.23) header field.
服务器收到的请求包含的Via条目（跃点）（第6.40节）比Max FORWARD（第6.23节）头字段允许的多。
The server received a request with a To (Section 6.37) address or Request-URI that was incomplete. Additional information SHOULD be provided.
服务器接收到一个带有To（第6.37节）地址或请求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 status response.
此状态代码允许重叠拨号。对于重叠拨号，客户端不知道拨号字符串的长度。它发送长度不断增加的字符串，提示用户进行更多输入，直到不再收到484状态响应。
The callee address provided in the request was ambiguous. The response MAY contain a listing of possible unambiguous addresses in Contact headers.
请求中提供的被叫方地址不明确。响应可能包含联系人头中可能的明确地址列表。
Revealing alternatives can infringe on privacy concerns 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 if the request address was ambiguous.
泄露备选方案可能会侵犯用户或组织的隐私问题。必须能够配置服务器以响应状态404（未找到），或者在请求地址不明确时禁止列出可能的选项。
Example response to a request with the URL lee@example.com :
使用URL响应请求的示例lee@example.com :
485 Ambiguous SIP/2.0
Contact: Carol Lee <sip:carol.lee@example.com>
485 Ambiguous SIP/2.0
Contact: Carol Lee <sip:carol.lee@example.com>
Contact: Ping Lee <sip:p.lee@example.com>
Contact: Lee M. Foote <sip:lee.foote@example.com>
Contact: Ping Lee <sip:p.lee@example.com>
Contact: Lee M. Foote <sip: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 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. The response MAY indicate a better time to call in the Retry-After header. The user could also be available elsewhere, such as through a voice mail service, thus, this response does not terminate any searches. Status 600 (Busy Everywhere) SHOULD be used if the client knows that no other end system will be able to accept this call.
已成功联系被叫方的终端系统，但被叫方当前不愿意或无法接听其他电话。响应可能指示在重试后报头中调用的更好时间。用户也可以在其他地方使用，例如通过语音邮件服务，因此，此响应不会终止任何搜索。如果客户端知道没有其他终端系统能够接受此呼叫，则应使用状态600（到处忙）。
5xx responses are failure responses given when a server itself has erred. They are not definitive failures, and MUST NOT terminate a search if other possible locations remain untried.
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.
服务器遇到意外情况，无法满足请求。客户端可能会显示特定的错误条件，并可能在几秒钟后重试该请求。
The server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any user.
服务器不支持满足请求所需的功能。当服务器无法识别请求方法并且无法为任何用户支持该方法时，这是适当的响应。
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 currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the client MUST handle the response as it would for a 500 response.
由于服务器临时过载或维护，服务器当前无法处理请求。这意味着，这是一种暂时的情况，延迟一段时间后会得到缓解。如果已知，延迟的长度可以在Retry After标头中指示。如果没有在之后重试，客户端必须像处理500响应一样处理响应。
Note: The existence of the 503 status code does not imply that a server has to use it when becoming overloaded. Some servers MAY wish to simply refuse the connection.
注意：503状态代码的存在并不意味着服务器在过载时必须使用它。有些服务器可能希望简单地拒绝连接。
The server, while acting as a gateway, did not receive a timely response from the server (e.g., a location server) it accessed in attempting to complete the request.
服务器在充当网关时，在尝试完成请求时未收到来自其访问的服务器（例如位置服务器）的及时响应。
The server does not support, or refuses to support, the SIP protocol version that was used in the request message. 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. The response MAY contain an entity describing why that version is not supported and what other protocols are supported by that server. The format for such an entity is not defined here and may be the subject of future standardization.
服务器不支持或拒绝支持请求消息中使用的SIP协议版本。服务器指示它无法或不愿意使用与客户端相同的主版本完成请求，除了此错误消息。响应可能包含一个实体，描述该版本不受支持的原因以及该服务器支持的其他协议。此处未定义此类实体的格式，可能是未来标准化的主题。
6xx responses indicate that a server has definitive information about a particular user, not just the particular instance indicated in the Request-URI. All further searches for this user are doomed to failure and pending searches SHOULD be terminated.
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. 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.
已成功联系被叫方的计算机，但用户明确不希望或无法参与。响应可能指示在重试后报头中调用的更好时间。
The server has authoritative information that the user indicated in the To request field does not exist anywhere. Searching for the user elsewhere will not yield any results.
服务器具有权威信息，即“收件人请求”字段中指示的用户在任何地方都不存在。在别处搜索用户不会产生任何结果。
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. Reasons are listed in Section 6.41. 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（不可接受）响应意味着用户希望通信，但不能充分支持所描述的会话。606（不可接受）响应可能在警告标头字段中包含原因列表，说明所述会话不受支持的原因。第6.41节列出了原因。希望不会经常需要协商，并且当邀请新用户加入现有会议时，协商可能不可能。由邀请发起人决定是否对606（不可接受）响应采取行动。
8 SIP Message Body
8 SIP消息体
Requests MAY contain message bodies unless otherwise noted. Within this specification, the BYE request MUST NOT contain a message body. For ACK, INVITE and OPTIONS, the message body is always a session description. The use of message bodies for REGISTER requests is for further study.
除非另有说明，否则请求可能包含消息正文。在此规范中，BYE请求不得包含消息正文。对于ACK、INVITE和OPTIONS，消息正文始终是会话描述。将消息体用于注册请求有待进一步研究。
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. Message bodies for 1xx responses contain advisory information about the progress of the request. 2xx responses to INVITE requests contain session descriptions. In 3xx responses, the message body MAY contain the description of alternative destinations or services, as described in Section 7.3. For responses with status 400 or greater, the message body MAY
对于响应消息，请求方法和响应状态代码确定任何消息体的类型和解释。所有响应可能包括一个主体。1xx响应的消息正文包含有关请求进度的咨询信息。INVITE请求的2xx响应包含会话描述。在3xx响应中，消息正文可能包含替代目的地或服务的描述，如第7.3节所述。对于状态为400或更高的响应，消息正文可以
contain additional, human-readable information about the reasons for failure. It is RECOMMENDED that information in 1xx and 300 and greater responses be of type text/plain or text/html
包含有关故障原因的其他可读信息。建议1xx和300及以上回复中的信息类型为text/plain或text/html
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 body length in bytes SHOULD be given by the Content-Length header field. Section 6.15 describes the behavior in detail.
正文长度（以字节为单位）应由Content length标头字段给出。第6.15节详细描述了该行为。
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。（注意：分块编码修改消息体，以便将其作为一系列分块传输，每个分块都有自己的大小指示符。）
9 Compact Form
9紧凑型
When SIP is carried over UDP with authentication and a complex session description, it may be possible that the size of a request or response is larger than the MTU. To address this problem, a more compact form of SIP is also defined by using abbreviations for the common header fields listed below:
当SIP通过UDP进行身份验证和复杂的会话描述时，请求或响应的大小可能大于MTU。为了解决这个问题，还通过使用以下列出的常用标题字段的缩写来定义更紧凑的SIP形式：
short field name long field name note c Content-Type e Content-Encoding f From i Call-ID m Contact from "moved" l Content-Length s Subject t To v Via
短字段名长字段名注释c内容类型e内容编码f来自我呼叫ID m联系人来自“移动”l内容长度s主题t到v通过
Thus, the message in section 16.2 could also be written:
因此，第16.2节中的信息也可以写成：
INVITE sip:schooler@vlsi.caltech.edu SIP/2.0
v:SIP/2.0/UDP 131.215.131.131;maddr=239.128.16.254;ttl=16
v:SIP/2.0/UDP 128.16.64.19
f:sip:mjh@isi.edu
t:sip:schooler@cs.caltech.edu
i:62729-27@128.16.64.19
c:application/sdp
CSeq: 4711 INVITE
l:187
INVITE sip:schooler@vlsi.caltech.edu SIP/2.0
v:SIP/2.0/UDP 131.215.131.131;maddr=239.128.16.254;ttl=16
v:SIP/2.0/UDP 128.16.64.19
f:sip:mjh@isi.edu
t:sip:schooler@cs.caltech.edu
i:62729-27@128.16.64.19
c:application/sdp
CSeq: 4711 INVITE
l:187
v=0
o=user1 53655765 2353687637 IN IP4 128.3.4.5
s=Mbone Audio
i=Discussion of Mbone Engineering Issues
e=mbone@somewhere.com
c=IN IP4 224.2.0.1/127
t=0 0
m=audio 3456 RTP/AVP 0
v=0
o=user1 53655765 2353687637 IN IP4 128.3.4.5
s=Mbone Audio
i=Discussion of Mbone Engineering Issues
e=mbone@somewhere.com
c=IN IP4 224.2.0.1/127
t=0 0
m=audio 3456 RTP/AVP 0
Clients MAY mix short field names and long field names within the same request. Servers MUST accept both short and long field names for requests. Proxies MAY change header fields between their long and short forms, but this MUST NOT be done to fields following an Authorization header.
客户端可以在同一请求中混合使用短字段名和长字段名。服务器必须接受请求的短字段名和长字段名。代理可以在长格式和短格式之间更改标题字段，但不能对授权标题后面的字段执行此操作。
10 Behavior of SIP Clients and Servers
10 SIP客户端和服务器的行为
SIP is defined so it can use either UDP (unicast or multicast) or TCP as a transport protocol; it provides its own reliability mechanism.
SIP的定义使其可以使用UDP（单播或多播）或TCP作为传输协议；它提供了自己的可靠性机制。
Servers discard isomorphic requests, but first retransmit the appropriate response. (SIP requests are said to be idempotent , i.e., receiving more than one copy of a request does not change the server state.)
服务器丢弃同构请求，但首先重新传输相应的响应。（SIP请求被称为幂等，即，接收一个请求的多个副本不会改变服务器状态。）
After receiving a CANCEL request from an upstream client, a stateful proxy server MAY send a CANCEL on all branches where it has not yet received a final response.
在收到来自上游客户端的取消请求后，有状态代理服务器可以在尚未收到最终响应的所有分支上发送取消。
When a user agent receives a request, it checks the Call-ID against those of in-progress calls. If the Call-ID was found, it compares the tag value of To with the user's tag and rejects the request if the
当用户代理收到请求时，它会将呼叫ID与正在进行的呼叫的ID进行检查。如果找到调用ID，它会将到的标记值与用户的标记进行比较，如果
two do not match. If the From header, including any tag value, matches the value for an existing call leg, the server compares the CSeq header field value. If less than or equal to the current sequence number, the request is a retransmission. Otherwise, it is a new request. If the From header does not match an existing call leg, a new call leg is created.
两个不匹配。如果From标头（包括任何标记值）与现有呼叫分支的值匹配，则服务器将比较CSeq标头字段值。如果小于或等于当前序列号，则请求为重传。否则，这是一个新的请求。如果From标头与现有呼叫分支不匹配，则会创建一个新的呼叫分支。
If the Call-ID was not found, a new call leg is created, with entries for the To, From and Call-ID headers. In this case, the To header field should not have contained a tag. The server returns a response containing the same To value, but with a unique tag added. The tag MAY be omitted if the request contained only one Via header field.
如果找不到呼叫ID，将创建一个新的呼叫分支，其中包含To、From和Call ID头的条目。在这种情况下，“收件人标头”字段不应包含标记。服务器返回一个响应，该响应包含相同的To值，但添加了唯一的标记。如果请求仅包含一个Via头字段，则可以省略标记。
A server MAY issue one or more provisional responses at any time before sending a final response. If a stateful proxy, user agent server, redirect server or registrar cannot respond to a request with a final response within 200 ms, it SHOULD issue a provisional (1xx) response as soon as possible. Stateless proxies MUST NOT issue provisional responses on their own.
在发送最终响应之前，服务器可以随时发出一个或多个临时响应。如果有状态代理、用户代理服务器、重定向服务器或注册器无法在200毫秒内以最终响应响应响应请求，则应尽快发出临时（1xx）响应。无状态代理不得自行发出临时响应。
Responses are mapped to requests by the matching To, From, Call-ID, CSeq headers and the branch parameter of the first Via header. Responses terminate request retransmissions even if they have Via headers that cause them to be delivered to an upstream client.
响应通过匹配到、来自、调用ID、CSeq头和第一个Via头的分支参数映射到请求。响应终止请求重传，即使它们具有导致它们被传递到上游客户端的Via头。
A stateful proxy may receive a response that it does not have state for, that is, where it has no a record of an associated request. If the Via header field indicates that the upstream server used TCP, the proxy actively opens a TCP connection to that address. Thus, proxies have to be prepared to receive responses on the incoming side of passive TCP connections, even though most responses will arrive on the incoming side of an active connection. (An active connection is a TCP connection initiated by the proxy, a passive connection is one accepted by the proxy, but initiated by another entity.)
有状态代理可以接收其没有状态的响应，也就是说，它没有关联请求的记录。如果Via标头字段指示上游服务器使用TCP，则代理会主动打开到该地址的TCP连接。因此，代理必须准备好在被动TCP连接的传入端接收响应，即使大多数响应将到达主动连接的传入端。（主动连接是由代理启动的TCP连接，被动连接是由代理接受但由其他实体启动的连接。）
100 responses SHOULD NOT be forwarded, other 1xx responses MAY be forwarded, possibly after the server eliminates responses with status codes that had already been sent earlier. 2xx responses are forwarded according to the Via header. Once a stateful proxy has received a 2xx response, it MUST NOT forward non-2xx final responses. Responses with status 300 and higher are retransmitted by each stateful proxy until the next upstream proxy sends an ACK (see below for timing details) or CANCEL.
100个响应不应转发，其他1xx响应可能会转发，这可能是在服务器消除带有先前已发送状态代码的响应之后。2xx响应根据Via标头转发。有状态代理收到2xx响应后，不得转发非2xx最终响应。状态为300或更高的响应由每个有状态代理重新传输，直到下一个上游代理发送ACK（有关定时详细信息，请参阅下文）或取消。
A stateful proxy SHOULD maintain state for at least 32 seconds after the receipt of the first definitive non-200 response, in order to handle retransmissions of the response.
有状态代理应在收到第一个确定的非200响应后保持状态至少32秒，以便处理响应的重新传输。
The 32 second window is given by the maximum retransmission duration of 200-class responses using the default timers, in case the ACK is lost somewhere on the way to the called user agent or the next stateful proxy.
如果ACK在发送到被调用的用户代理或下一个有状态代理的过程中丢失，则32秒窗口由使用默认计时器的200个类响应的最大重传持续时间给出。
Responses are returned to the address listed in the Via header field (Section 6.40), not the source address of the request.
响应返回到Via标头字段（第6.40节）中列出的地址，而不是请求的源地址。
Recall that responses are not generated by the next-hop stateless server, but generated by either a proxy server or the user agent server. Thus, the stateless proxy can only use the Via header field to forward the response.
回想一下，响应不是由下一跳无状态服务器生成的，而是由代理服务器或用户代理服务器生成的。因此，无状态代理只能使用Via header字段转发响应。
Requests MAY be multicast; multicast requests likely feature a host-independent Request-URI. This request SHOULD be scoped to ensure it is not forwarded beyond the boundaries of the administrative system. This MAY be done with either TTL or administrative scopes[25], depending on what is implemented in the network.
请求可以是多播的；多播请求可能具有独立于主机的请求URI。此请求的范围应确保其转发不超出管理系统的边界。这可以通过TTL或管理作用域[25]实现，具体取决于网络中实现的内容。
A client receiving a multicast query does not have to check whether the host part of the Request-URI matches its own host or domain name. If the request was received via multicast, the response is also returned via multicast. Responses to multicast requests are multicast with the same TTL as the request, where the TTL is derived from the ttl parameter in the Via header (Section 6.40).
接收多播查询的客户端不必检查请求URI的主机部分是否与其自己的主机或域名匹配。如果请求是通过多播接收的，那么响应也会通过多播返回。对多播请求的响应是与请求具有相同TTL的多播，其中TTL来自Via头中的TTL参数（第6.40节）。
To avoid response implosion, servers MUST NOT answer multicast requests with a status code other than 2xx or 6xx. The server delays its response by a random interval uniformly distributed between zero and one second. Servers MAY suppress responses if they hear a lower-numbered or 6xx response from another group member prior to sending. Servers do not respond to CANCEL requests received via multicast to avoid request implosion. A proxy or UAC SHOULD send a CANCEL on receiving the first 2xx or 6xx response to a multicast request.
为避免响应内爆，服务器不得以2xx或6xx以外的状态代码响应多播请求。服务器延迟响应的时间间隔为随机的，均匀分布在0到1秒之间。如果服务器在发送之前听到另一个组成员的编号较低或6xx的响应，则服务器可能会抑制响应。服务器不响应通过多播接收的取消请求，以避免请求内爆。代理或UAC应在收到对多播请求的第一个2xx或6xx响应时发送取消。
Server response suppression is a MAY since it requires a server to violate some basic message processing rules. Lets say A sends a multicast request, and it is received by B,C, and D. B sends a 200 response. The topmost Via field in the response will contain the address of A. C will also receive this response, and could use it to suppress its own response. However, C would normally not examine this response, as the topmost Via is not its own. Normally, a response received with an incorrect topmost Via MUST be dropped, but not in this case. To distinguish this packet from a misrouted or multicast looped packet is fairly complex, and for this reason the procedure is a MAY. The CANCEL, instead, provides a simpler and more standard way to perform response suppression. It is for this reason that the use of CANCEL here is a SHOULD
服务器响应抑制是一种可能，因为它要求服务器违反一些基本的消息处理规则。假设A发送一个多播请求，B、C和D接收到该请求。B发送一个200响应。响应中最顶端的Via字段将包含A.C的地址。C也将接收此响应，并可以使用它来抑制自己的响应。然而，C通常不会检查这个响应，因为最上面的通孔不是它自己的。通常情况下，必须丢弃使用不正确的最顶部通孔接收的响应，但在这种情况下不能。要将此数据包与路由错误或多播循环数据包区分开来相当复杂，因此，此过程可能会比较复杂。相反，CANCEL提供了一种更简单、更标准的执行响应抑制的方法。正是由于这个原因，在这里使用CANCEL是一个很好的选择
A single TCP connection can serve one or more SIP transactions. A transaction contains zero or more provisional responses followed by one or more final responses. (Typically, transactions contain exactly one final response, but there are exceptional circumstances, where, for example, multiple 200 responses can be generated.)
单个TCP连接可以服务于一个或多个SIP事务。事务包含零个或多个临时响应，后跟一个或多个最终响应。（通常，事务只包含一个最终响应，但也有例外情况，例如，可以生成多个200响应。）
The client SHOULD keep the connection open at least until the first final response arrives. If the client closes or resets the TCP connection prior to receiving the first final response, the server treats this action as equivalent to a CANCEL request.
客户端应至少在第一个最终响应到达之前保持连接打开。如果客户端在收到第一个最终响应之前关闭或重置TCP连接，则服务器将此操作视为等同于取消请求。
This behavior makes it less likely that malfunctioning clients cause a proxy server to keep connection state indefinitely.
这种行为减少了出现故障的客户端导致代理服务器无限期保持连接状态的可能性。
The server SHOULD NOT close the TCP connection until it has sent its final response, at which point it MAY close the TCP connection if it wishes to. However, normally it is the client's responsibility to close the connection.
在发送最终响应之前，服务器不应关闭TCP连接，如果愿意，可以在该点关闭TCP连接。但是，通常情况下，关闭连接是客户的责任。
If the server leaves the connection open, and if the client so desires it MAY re-use the connection for further SIP requests or for requests from the same family of protocols (such as HTTP or stream control commands).
如果服务器使连接保持打开状态，并且如果客户端希望，它可以将连接重新用于进一步的SIP请求或来自相同协议系列的请求（例如HTTP或流控制命令）。
If a server needs to return a response to a client and no longer has a connection open to that client, it MAY open a connection to the address listed in the Via header. Thus, a proxy or user agent MUST be prepared to receive both requests and responses on a "passive" connection.
如果服务器需要向客户机返回响应，并且不再有与该客户机的连接打开，则可能会打开与Via标头中列出的地址的连接。因此，代理或用户代理必须准备好在“被动”连接上接收请求和响应。
A SIP client using UDP SHOULD retransmit a BYE, CANCEL, OPTIONS, or REGISTER request with an exponential backoff, starting at a T1 second interval, doubling the interval for each packet, and capping off at a T2 second interval. This means that after the first packet is sent, the second is sent T1 seconds later, the next 2*T1 seconds after that, the next 4*T1 seconds after that, and so on, until the interval hits T2. Subsequent retransmissions are spaced by T2 seconds. If the client receives a provisional response, it continues to retransmit the request, but with an interval of T2 seconds. Retransmissions cease when the client has sent a total of eleven packets, or receives a definitive response. Default values for T1 and T2 are 500 ms and 4 s, respectively. Clients MAY use larger values, but SHOULD NOT use smaller ones. Servers retransmit the response upon receipt of a request retransmission. After the server sends a final response, it cannot be sure the client has received the response, and thus SHOULD cache the results for at least 10*T2 seconds to avoid having to, for example, contact the user or location server again upon receiving a request retransmission.
使用UDP的SIP客户端应以指数退避的方式重新传输BYE、CANCEL、OPTIONS或REGISTER请求，从T1秒开始，将每个数据包的间隔加倍，并以T2秒的间隔结束。这意味着在发送第一个数据包之后，第二个数据包将在T1秒后发送，之后的下一个2*T1秒，之后的下一个4*T1秒，依此类推，直到间隔到达T2。随后的重传间隔为T2秒。如果客户端收到临时响应，它将继续重新传输请求，但间隔为T2秒。当客户端总共发送了11个数据包或收到最终响应时，重传停止。T1和T2的默认值分别为500 ms和4 s。客户端可以使用较大的值，但不应使用较小的值。服务器在收到请求重新传输时重新传输响应。服务器发送最终响应后，无法确定客户端是否已收到响应，因此应将结果缓存至少10*T2秒，以避免在接收到请求重新传输时再次联系用户或位置服务器。
Use of the exponential backoff is for congestion control purposes. However, the back-off must cap off, since request retransmissions are used to trigger response retransmissions at the server. Without a cap, the loss of a single response could significantly increase transaction latencies.
指数退避用于拥塞控制目的。但是，回退必须结束，因为请求重传用于触发服务器上的响应重传。如果没有上限，单个响应的丢失可能会显著增加事务延迟。
The value of the initial retransmission timer is smaller than that that for TCP since it is expected that network paths suitable for interactive communications have round-trip times smaller than 500 ms. For congestion control purposes, the retransmission count has to be bounded. Given that most transactions are expected to consist of one request and a few responses, round-trip time estimation is not likely to be very useful. If RTT estimation is desired to more quickly discover a missing final response, each request retransmission needs to be labeled with its own Timestamp (Section 6.36), returned in the response. The server caches the result until it can be sure that the client will not retransmit the same request again.
初始重传计时器的值小于TCP的值，因为适用于交互通信的网络路径的往返时间预计小于500 ms。出于拥塞控制目的，重传计数必须有界。考虑到大多数事务预期由一个请求和几个响应组成，往返时间估计不太可能有用。如果需要RTT估计以更快地发现丢失的最终响应，则每个请求重传都需要标记其自己的时间戳（第6.36节），并在响应中返回。服务器缓存结果，直到可以确保客户端不再重新传输相同的请求为止。
Each server in a proxy chain generates its own final response to a CANCEL request. The server responds immediately upon receipt of the CANCEL request rather than waiting until it has received final responses from the CANCEL requests it generates.
代理链中的每台服务器都会生成自己对取消请求的最终响应。服务器在收到CANCEL请求后立即响应，而不是等到收到来自其生成的CANCEL请求的最终响应。
BYE and OPTIONS final responses are generated by redirect and user agent servers; REGISTER final responses are generated by registrars. Note that in contrast to the reliability mechanism described in Section 10.5, responses to these requests are not retransmitted periodically and not acknowledged via ACK.
BYE和OPTIONS最终响应由重定向和用户代理服务器生成；登记员最终回复由登记员生成。请注意，与第10.5节中描述的可靠性机制不同，对这些请求的响应不会定期重新传输，也不会通过ACK确认。
Clients using TCP do not need to retransmit requests.
使用TCP的客户端不需要重新传输请求。
Special considerations apply for the INVITE method.
特殊注意事项适用于INVITE方法。
1. After receiving an invitation, considerable time can elapse before the server can determine the outcome. For example, if the called party is "rung" or extensive searches are performed, delays between the request and a definitive response can reach several tens of seconds. If either caller or callee are automated servers not directly controlled by a human being, a call attempt could be unbounded in time.
1. 在收到邀请后，服务器可能需要相当长的时间才能确定结果。例如，如果被叫方处于“rung”状态或执行了大量搜索，则请求和最终响应之间的延迟可能达到几十秒。如果呼叫者或被呼叫者都是不受人直接控制的自动服务器，则呼叫尝试可能在时间上没有限制。
2. If a telephony user interface is modeled or if we need to interface to the PSTN, the caller's user interface will provide "ringback", a signal that the callee is being alerted. (The status response 180 (Ringing) MAY be used to initiate ringback.) Once the callee picks up, the caller needs to know so that it can enable the voice path and stop ringback. The callee's response to the invitation could get lost. Unless the response is transmitted reliably, the caller will continue to hear ringback while the callee assumes that the call exists.
2. 如果对电话用户界面进行了建模，或者如果我们需要与PSTN进行接口，则呼叫者的用户界面将提供“回响”，即被呼叫者收到警报的信号。（状态响应180（振铃）可用于启动回铃。）一旦被叫方接听，呼叫者需要知道，以便能够启用语音路径并停止回铃。被调用方对邀请的响应可能会丢失。除非响应被可靠地传输，否则呼叫者将继续听到回音，而被呼叫者认为呼叫存在。
3. The client has to be able to terminate an on-going request, e.g., because it is no longer willing to wait for the connection or search to succeed. The server will have to wait several retransmission intervals to interpret the lack of request retransmissions as the end of a call. If the call succeeds shortly after the caller has given up, the callee will "pick up the phone" and not be "connected".
3. 客户端必须能够终止正在进行的请求，例如，因为它不再愿意等待连接或搜索成功。服务器必须等待几个重传间隔，才能将缺少请求重传解释为呼叫结束。如果在呼叫者放弃后不久呼叫成功，被呼叫者将“拿起电话”而不“连接”。
For UDP, A SIP client SHOULD retransmit a SIP INVITE request with an interval that starts at T1 seconds, and doubles after each packet transmission. The client ceases retransmissions if it receives a provisional or definitive response, or once it has sent a total of 7 request packets.
对于UDP，SIP客户端应以T1秒开始的间隔重新传输SIP INVITE请求，并在每次数据包传输后加倍。如果客户端接收到临时或最终响应，或者发送了总共7个请求数据包，则客户端将停止重新传输。
A server which transmits a provisional response should retransmit it upon reception of a duplicate request. A server which transmits a final response should retransmit it with an interval that starts at T1 seconds, and doubles for each subsequent packet. Response retransmissions cease when any one of the following occurs:
发送临时响应的服务器应在接收到重复请求时重新发送该响应。传输最终响应的服务器应以T1秒开始的间隔重新传输该响应，并为每个后续数据包加倍。发生以下任一情况时，响应重传停止：
1. An ACK request for the same transaction is received;
1. 接收到相同事务的ACK请求；
2. a BYE request for the same call leg is received;
2. 接收到同一呼叫段的BYE请求；
3. a CANCEL request for the same call leg is received and the final response status was equal or greater to 300;
3. 接收到同一呼叫段的取消请求，且最终响应状态等于或大于300；
4. the response has been transmitted 7 times.
4. 该响应已传输7次。
Only the user agent client generates an ACK for 2xx final responses, If the response contained a Contact header field, the ACK MAY be sent to the address listed in that Contact header field. If the response did not contain a Contact header, the client uses the same To header field and Request-URI as for the INVITE request and sends the ACK to the same destination as the original INVITE request. ACKs for final responses other than 2xx are sent to the same server that the original request was sent to, using the same Request-URI as the original request. Note, however, that the To header field in the ACK is copied from the response being acknowledged, not the request, and thus MAY additionally contain the tag parameter. Also note than unlike 2xx final responses, a proxy generates an ACK for non-2xx final responses.
只有用户代理客户端为2xx最终响应生成ACK，如果响应包含联系人标头字段，则可以将ACK发送到该联系人标头字段中列出的地址。如果响应不包含联系人标头，则客户端将使用与INVITE请求相同的To标头字段和请求URI，并将ACK发送到与原始INVITE请求相同的目标。使用与原始请求相同的请求URI，将2xx以外的最终响应的ACK发送到原始请求发送到的同一服务器。然而，请注意，ACK中的To header字段是从正在确认的响应而不是请求复制的，因此可能还包含tag参数。还请注意，与2xx最终响应不同，代理为非2xx最终响应生成ACK。
The ACK request MUST NOT be acknowledged to prevent a response-ACK feedback loop. Fig. 12 and 13 show the client and server state diagram for invitations.
不得确认ACK请求以防止响应ACK反馈循环。图12和13显示了邀请的客户端和服务器状态图。
The mechanism in Sec. 10.4 would not work well for INVITE because of the long delays between INVITE and a final response. If the 200 response were to get lost, the callee would believe the call to exist, but the voice path would
证券交易委员会的机制。10.4不适用于INVITE，因为INVITE和最终响应之间存在长时间延迟。如果200响应丢失，被叫方会相信呼叫存在，但语音路径会丢失
+===========+
* *
...........>* Initial *<;;;;;;;;;;
: 7 INVITE * * ;
: sent +===========+ ;
: | ;
: | - ;
: | INVITE ;
: | ;
: v ;
: ************* ;
: T1*2^n <--* * ;
: INVITE -->* Calling *--------+ ;
: * * | ;
: ************* | ;
: : | | ;
:.............: | 1xx xxx | ;
| - ACK | ;
| | ;
v | ;
************* | ;
* * | ;
* Ringing *<->1xx | ;
* * | ;
************* | ;
| | ;
|<-------------+ ;
| ;
v ;
************* ;
xxx <--* * ;
ACK -->* Completed * ;
* * ;
************* ;
; 32s (for proxy);
;;;;;;;;;;;;;;;;;;
+===========+
* *
...........>* Initial *<;;;;;;;;;;
: 7 INVITE * * ;
: sent +===========+ ;
: | ;
: | - ;
: | INVITE ;
: | ;
: v ;
: ************* ;
: T1*2^n <--* * ;
: INVITE -->* Calling *--------+ ;
: * * | ;
: ************* | ;
: : | | ;
:.............: | 1xx xxx | ;
| - ACK | ;
| | ;
v | ;
************* | ;
* * | ;
* Ringing *<->1xx | ;
* * | ;
************* | ;
| | ;
|<-------------+ ;
| ;
v ;
************* ;
xxx <--* * ;
ACK -->* Completed * ;
* * ;
************* ;
; 32s (for proxy);
;;;;;;;;;;;;;;;;;;
event (xxx=status) message
事件（xxx=状态）消息
Figure 12: State transition diagram of client for INVITE method
图12:INVITE方法的客户端状态转换图
7 pkts sent +===============+
+-------------->* *
| * Initial *<...............
|;;;;;;;;;;;;;;>* * :
|; +===============+ :
|; CANCEL ! :
|; 200 ! INVITE :
|; ! 1xx :
|; ! :
|; v :
|; ***************** BYE :
|; INVITE -->* * 200 :
|; 1xx <--* Call proceed. *..............>:
|; * * :
|;;;;;;;;;;;;;;;***************** :
|; ! ! :
|: ! ! :
|; failure ! ! picks up :
|; >= 300 ! ! 200 :
|; +-------+ +-------+ :
|; v v :
|; *********** *********** :
|;INVITE<* *<T1*2^n->* *>INVITE :
|;status>* failure *>status<-* success *<status :
|; * * * * :
|;;;;;;;;*********** *********** :
| ! : | | ! : :
| ! : | | ! : :
+-------------!-:-+------------+ ! : :
! :.................!..:.........>:
! ! BYE :
+---------+---------+ 200 :
event ! ACK :
message sent v :
***************** :
V---* * :
ACK * Confirmed * :
|-->* * :
***************** .
:......................>:
7 pkts sent +===============+
+-------------->* *
| * Initial *<...............
|;;;;;;;;;;;;;;>* * :
|; +===============+ :
|; CANCEL ! :
|; 200 ! INVITE :
|; ! 1xx :
|; ! :
|; v :
|; ***************** BYE :
|; INVITE -->* * 200 :
|; 1xx <--* Call proceed. *..............>:
|; * * :
|;;;;;;;;;;;;;;;***************** :
|; ! ! :
|: ! ! :
|; failure ! ! picks up :
|; >= 300 ! ! 200 :
|; +-------+ +-------+ :
|; v v :
|; *********** *********** :
|;INVITE<* *<T1*2^n->* *>INVITE :
|;status>* failure *>status<-* success *<status :
|; * * * * :
|;;;;;;;;*********** *********** :
| ! : | | ! : :
| ! : | | ! : :
+-------------!-:-+------------+ ! : :
! :.................!..:.........>:
! ! BYE :
+---------+---------+ 200 :
event ! ACK :
message sent v :
***************** :
V---* * :
ACK * Confirmed * :
|-->* * :
***************** .
:......................>:
Figure 13: State transition diagram of server for INVITE method
图13:INVITE方法的服务器状态转换图
be dead since the caller does not know that the callee has picked up. Thus, the INVITE retransmission interval would have to be on the order of a second or two to limit the duration of this state confusion. Retransmitting the response with an exponential back-off helps ensure that the response is received, without placing an undue burden on the network.
因为打电话的人不知道被叫人接了电话，所以他可能已经死了。因此，INVITE重传间隔必须为一秒或两秒，以限制这种状态混乱的持续时间。通过指数回退重新传输响应有助于确保接收到响应，而不会给网络带来不必要的负担。
A user agent using TCP MUST NOT retransmit requests, but uses the same algorithm as for UDP (Section 10.5.1) to retransmit responses until it receives an ACK.
使用TCP的用户代理不得重新传输请求，而是使用与UDP相同的算法（第10.5.1节）重新传输响应，直到收到ACK。
It is necessary to retransmit 2xx responses as their reliability is assured end-to-end only. If the chain of proxies has a UDP link in the middle, it could lose the response, with no possibility of recovery. For simplicity, we also retransmit non-2xx responses, although that is not strictly necessary.
有必要重新传输2xx响应，因为它们的可靠性仅得到端到端的保证。如果代理链在中间有一个UDP链接，它可能会丢失响应，不可能恢复。为简单起见，我们还重新传输非2xx响应，尽管这不是严格必要的。
The ACK request does not generate responses. It is only generated when a response to an INVITE request arrives (see Section 10.5). This behavior is independent of the transport protocol. Note that the ACK request MAY take a different path than the original INVITE request, and MAY even cause a new TCP connection to be opened in order to send it.
ACK请求不生成响应。它仅在收到对INVITE请求的响应时生成（参见第10.5节）。此行为独立于传输协议。请注意，ACK请求可能采用与原始INVITE请求不同的路径，甚至可能导致打开新的TCP连接以发送它。
Handling of ICMP messages in the case of UDP messages is straightforward. For requests, a host, network, port, or protocol unreachable error SHOULD be treated as if a 400-class response was received. For responses, these errors SHOULD cause the server to cease retransmitting the response.
UDP消息中ICMP消息的处理非常简单。对于请求，主机、网络、端口或协议不可访问错误应视为收到400类响应。对于响应，这些错误将导致服务器停止重新传输响应。
Source quench ICMP messages SHOULD be ignored. TTL exceeded errors SHOULD be ignored. Parameter problem errors SHOULD be treated as if a 400-class response was received.
应忽略源猝灭ICMP消息。应忽略TTL超出的错误。参数问题错误应视为收到400类响应。
11 Behavior of SIP User Agents
11 SIP用户代理的行为
This section describes the rules for user agent client and servers for generating and processing requests and responses.
本节介绍用于生成和处理请求和响应的用户代理客户端和服务器的规则。
When a user agent client desires to initiate a call, it formulates an INVITE request. The To field in the request contains the address of the callee. The Request-URI contains the same address. The From field contains the address of the caller. If the From address can appear in requests generated by other user agent clients for the same call, the caller MUST insert the tag parameter in the From field. A UAC MAY optionally add a Contact header containing an address where it would like to be contacted for transactions from the callee back to the caller.
当用户代理客户端希望发起呼叫时，它会制定一个INVITE请求。请求中的“收件人”字段包含被调用方的地址。请求URI包含相同的地址。“发件人”字段包含调用方的地址。如果发件人地址可以出现在其他用户代理客户端为同一呼叫生成的请求中，则调用者必须在“发件人”字段中插入标记参数。UAC可以选择性地添加一个联系人头，其中包含一个地址，在该地址中，它希望被联系以进行从被叫方返回到呼叫者的事务。
When the initial INVITE request is received at the callee, the callee can accept, redirect, or reject the call. In all of these cases, it formulates a response. The response MUST copy the To, From, Call-ID, CSeq and Via fields from the request. Additionally, the responding UAS MUST add the tag parameter to the To field in the response if the request contained more than one Via header field. Since a request from a UAC may fork and arrive at multiple hosts, the tag parameter serves to distinguish, at the UAC, multiple responses from different UAS's. The UAS MAY add a Contact header field in the response. It contains an address where the callee would like to be contacted for subsequent transactions, including the ACK for the current INVITE. The UAS stores the values of the To and From field, including any tags. These become the local and remote addresses of the call leg, respectively.
当被叫方收到初始INVITE请求时，被叫方可以接受、重定向或拒绝呼叫。在所有这些情况下，它都会作出反应。响应必须从请求中复制To、From、Call ID、CSeq和Via字段。此外，如果请求包含多个Via标头字段，则响应UAS必须将tag参数添加到响应中的to字段。由于来自UAC的请求可能分叉并到达多个主机，因此标记参数用于在UAC区分来自不同UAS的多个响应。UAS可以在响应中添加联系人标题字段。它包含一个地址，被呼叫方希望在该地址进行后续交易，包括当前邀请的确认。UAS存储To和From字段的值，包括任何标记。它们分别成为呼叫分支的本地和远程地址。
Multiple 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 call leg. The caller MAY choose to acknowledge or terminate the call with each responding UAS. To acknowledge, it sends an ACK request, and to terminate it sends a BYE request. The To header field in the ACK or BYE MUST be the same as the To field in the 200 response, including any tag. The From header field MUST be the same as the From header field in the 200 (OK) response, including any tag. The Request-URI of the ACK or BYE request MAY be set to whatever address was found in the Contact header field in the 200 (OK) response, if present. Alternately, a UAC may copy the address from the To header field into the Request-URI. The UAC also notes the value of the To and From header fields in each response. For each call leg, the To header field becomes the remote address, and the From header field becomes the local address.
由于分叉代理，单个INVITE请求的多个响应可能会到达UAC。每个响应都由To header字段中的“tag”参数来区分，每个响应都表示一个不同的调用分支。呼叫者可以通过每个响应UAS选择确认或终止呼叫。为了确认，它发送一个ACK请求，为了终止，它发送一个BYE请求。ACK或BYE中的To报头字段必须与200响应中的To字段相同，包括任何标记。From标头字段必须与200（OK）响应中的From标头字段相同，包括任何标记。ACK或BYE请求的请求URI可以设置为在200（OK）响应的联系人报头字段中找到的任何地址（如果存在）。或者，UAC可以将地址从To头字段复制到请求URI中。UAC还记录每个响应中的“收件人”和“发件人”头字段的值。对于每个呼叫分支，To头字段成为远程地址，From头字段成为本地地址。
Once the call has been established, either the caller or callee MAY generate INVITE or BYE requests to change or terminate the call. Regardless of whether the caller or callee is generating the new request, the header fields in the request are set as follows. For the desired call leg, the To header field is set to the remote address, and the From header field is set to the local address (both including any tags). The Contact header field MAY be different than the Contact header field sent in a previous response or request. The Request-URI MAY be set to the value of the Contact header field received in a previous request or response from the remote party, or to the value of the remote address.
呼叫建立后，呼叫者或被呼叫者可以生成INVITE或BYE请求来更改或终止呼叫。无论调用方还是被调用方正在生成新请求，请求中的头字段设置如下。对于所需的呼叫分支，To header字段设置为远程地址，From header字段设置为本地地址（两者都包括任何标记）。联系人标头字段可能不同于先前响应或请求中发送的联系人标头字段。请求URI可以设置为在来自远程方的先前请求或响应中接收的联系人报头字段的值，或者设置为远程地址的值。
When a request is received subsequently, the following checks are made:
当随后收到请求时，将进行以下检查：
1. If the Call-ID is new, the request is for a new call, regardless of the values of the To and From header fields.
1. 如果调用ID是新的，则无论“到”和“从”标头字段的值如何，都会请求新的调用。
2. If the Call-ID exists, the request is for an existing call. If the To, From, Call-ID, and CSeq values exactly match (including tags) those of any requests received previously, the request is a retransmission.
2. 如果呼叫ID存在，则请求是针对现有呼叫的。如果To、From、Call ID和CSeq值与之前接收到的任何请求的值完全匹配（包括标记），则该请求为重传。
3. If there was no match to the previous step, the To and From fields are compared against existing call leg local and remote addresses. If there is a match, and the CSeq in the request is higher than the last CSeq received on that leg, the request is a new transaction for an existing call leg.
3. 如果与上一步不匹配，则将to和From字段与现有的呼叫分支本地和远程地址进行比较。如果存在匹配，并且请求中的CSeq高于该分支上接收到的最后一个CSeq，则该请求是现有呼叫分支的新事务。
12 Behavior of SIP Proxy and Redirect Servers
12 SIP代理和重定向服务器的行为
This section describes behavior of SIP redirect and proxy servers in detail. Proxy servers can "fork" connections, i.e., a single incoming request spawns several outgoing (client) requests.
本节详细描述SIP重定向和代理服务器的行为。代理服务器可以“分叉”连接，也就是说，一个传入请求生成多个传出（客户端）请求。
A redirect server does not issue any SIP requests of its own. After receiving a request other than CANCEL, the server gathers the list of alternative locations and returns a final response of class 3xx or it refuses the request. For well-formed CANCEL requests, it SHOULD return a 2xx response. This response ends the SIP transaction. The
重定向服务器不会发出自己的任何SIP请求。在接收到除CANCEL之外的请求后，服务器收集替代位置列表，并返回3xx类的最终响应，或者拒绝该请求。对于格式正确的取消请求，它应该返回2xx响应。此响应结束SIP事务。这个
redirect server maintains transaction state for the whole SIP transaction. It is up to the client to detect forwarding loops between redirect servers.
重定向服务器维护整个SIP事务的事务状态。由客户端检测重定向服务器之间的转发循环。
User agent servers behave similarly to redirect servers, except that they also accept requests and can return a response of class 2xx.
用户代理服务器的行为与重定向服务器类似，只是它们也接受请求并可以返回2xx类的响应。
This section outlines processing rules for proxy servers. A proxy server can either be stateful or stateless. When stateful, a proxy remembers the incoming request which generated outgoing requests, and the outgoing requests. A stateless proxy forgets all information once an outgoing request is generated. A forking proxy SHOULD be stateful. Proxies that accept TCP connections MUST be stateful.
本节概述代理服务器的处理规则。代理服务器可以是有状态的，也可以是无状态的。当有状态时，代理会记住生成传出请求的传入请求和传出请求。一旦生成传出请求，无状态代理就会忘记所有信息。分叉代理应该是有状态的。接受TCP连接的代理必须是有状态的。
Otherwise, if the proxy were to lose a request, the TCP client would never retransmit it.
否则，如果代理丢失一个请求，TCP客户端将永远不会重新传输它。
A stateful proxy SHOULD NOT become stateless until after it sends a definitive response upstream, and at least 32 seconds after it received a definitive response.
有状态代理在向上游发送最终响应之前，以及在收到最终响应后至少32秒，不应变为无状态。
A stateful proxy acts as a virtual UAS/UAC. It implements the server state machine when receiving requests, and the client state machine for generating outgoing requests, with the exception of receiving a 2xx response to an INVITE. Instead of generating an ACK, the 2xx response is always forwarded upstream towards the caller. Furthermore, ACK's for 200 responses to INVITE's are always proxied downstream towards the UAS, as they would be for a stateless proxy.
有状态代理充当虚拟UAS/UAC。它在接收请求时实现服务器状态机，在生成传出请求时实现客户机状态机，但接收对INVITE的2xx响应除外。2xx响应总是向上游转发到调用方，而不是生成ACK。此外，INVITE的200个响应的ACK总是向UAS下游代理，就像无状态代理一样。
A stateless proxy does not act as a virtual UAS/UAC (as this would require state). Rather, a stateless proxy forwards every request it receives downstream, and every response it receives upstream.
无状态代理不充当虚拟UAS/UAC（因为这需要状态）。相反，无状态代理转发它在下游收到的每个请求，以及它在上游收到的每个响应。
To prevent loops, a server MUST check if its own address is already contained in the Via header field of the incoming request.
为了防止循环，服务器必须检查其自己的地址是否已包含在传入请求的Via标头字段中。
The To, From, Call-ID, and Contact tags are copied exactly from the original request. The proxy SHOULD change the Request-URI to indicate the server where it intends to send the request.
To、From、Call ID和Contact标记完全从原始请求复制。代理应该更改请求URI，以指示它打算发送请求的服务器。
A proxy server always inserts a Via header field containing its own address into those requests that are caused by an incoming request. Each proxy MUST insert a "branch" parameter (Section 6.40).
代理服务器总是将包含其自身地址的Via标头字段插入由传入请求引起的请求中。每个代理必须插入一个“分支”参数（第6.40节）。
A proxy only processes a response if the topmost Via field matches one of its addresses. A response with a non-matching top Via field MUST be dropped.
只有当最顶端的Via字段与其地址之一匹配时，代理才会处理响应。必须删除具有不匹配顶部通孔字段的响应。
A stateless proxy removes its own Via field, and checks the address in the next Via field. In the case of UDP, the response is sent to the address listed in the "maddr" tag if present, otherwise to the "received" tag if present, and finally to the address in the "sent-by" field. A proxy MUST remain stateful when handling requests received via TCP.
无状态代理删除自己的Via字段，并在next Via字段中检查地址。对于UDP，响应发送到“maddr”标记中列出的地址（如果存在），否则发送到“已接收”标记（如果存在），最后发送到“发送人”字段中的地址。在处理通过TCP接收的请求时，代理必须保持有状态。
A stateless proxy MUST NOT generate its own provisional responses.
无状态代理不能生成自己的临时响应。
When a stateful proxy receives a request, it checks the To, From (including tags), Call-ID and CSeq against existing request records. If the tuple exists, the request is a retransmission. The provisional or final response sent previously is retransmitted, as per the server state machine. If the tuple does not exist, the request corresponds to a new transaction, and the request should be proxied.
当有状态代理收到请求时，它会根据现有的请求记录检查To、From（包括标记）、Call ID和CSeq。如果元组存在，则请求是重传。根据服务器状态机重新传输先前发送的临时或最终响应。如果元组不存在，则请求对应于一个新事务，并且应该代理该请求。
A stateful proxy server MAY generate its own provisional (1xx) responses.
有状态代理服务器可以生成自己的临时（1xx）响应。
When an ACK request is received, it is either processed locally or proxied. To make this determination, the To, From, CSeq and Call-ID fields are compared against those in previous requests. If there is no match, the ACK request is proxied as if it were an INVITE request. If there is a match, and if the server had ever sent a 200 response upstream, the ACK is proxied. If the server had never sent any responses upstream, the ACK is also proxied. If the server had sent a 3xx, 4xx, 5xx or 6xx response, but no 2xx response, the ACK is processed locally if the tag in the To field of the ACK matches the tag sent by the proxy in the response.
当接收到ACK请求时，它要么在本地处理，要么被代理。要进行此确定，将To、From、CSeq和Call ID字段与以前请求中的字段进行比较。如果不存在匹配项，则将ACK请求作为INVITE请求进行代理。如果存在匹配，并且服务器曾向上游发送过200响应，则会代理ACK。如果服务器从未向上游发送过任何响应，则ACK也会被代理。如果服务器发送了3xx、4xx、5xx或6xx响应，但没有2xx响应，则如果ACK的To字段中的标记与响应中代理发送的标记匹配，则本地处理ACK。
When a proxy server receives a response that has passed the Via checks, the proxy server checks the To (without the tag), From (including the tag), Call-ID and CSeq against values seen in previous requests. If there is no match, the response is forwarded upstream to the address listed in the Via field. If there is a match, the "branch" tag in the Via field is examined. If it matches a known branch identifier, the response is for the given branch, and processed by the virtual client for the given branch. Otherwise, the response is dropped.
当代理服务器接收到已通过Via检查的响应时，代理服务器将根据以前请求中看到的值检查To（不带标记）、From（包括标记）、Call ID和CSeq。如果不匹配，则将响应转发到“通过”字段中列出的地址的上游。如果存在匹配项，则检查过孔字段中的“分支”标记。如果它与已知的分支标识符匹配，则响应针对给定的分支，并由虚拟客户端针对给定的分支进行处理。否则，将丢弃响应。
A stateful proxy should obey the rules in Section 12.4 to determine if the response should be proxied upstream. If it is to be proxied, the same rules for stateless proxies above are followed, with the following addition for TCP. If a request was received via TCP (indicated by the protocol in the top Via header), the proxy checks to see if it has a connection currently open to that address. If so, the response is sent on that connection. Otherwise, a new TCP connection is opened to the address and port in the Via field, and the response is sent there. Note that this implies that a UAC or proxy MUST be prepared to receive responses on the incoming side of a TCP connection. Definitive non 200-class responses MUST be retransmitted by the proxy, even over a TCP connection.
有状态代理应遵守第12.4节中的规则，以确定是否应向上游代理响应。如果要代理，则遵循上述无状态代理的相同规则，并为TCP添加以下内容。如果通过TCP接收到请求（由顶部via头中的协议指示），则代理将检查当前是否有与该地址的连接。如果是，则在该连接上发送响应。否则，将打开到Via字段中地址和端口的新TCP连接，并将响应发送到该地址和端口。注意，这意味着UAC或代理必须准备好在TCP连接的传入端接收响应。最终的非200类响应必须由代理重新传输，即使是通过TCP连接。
Proxies in this category issue at most a single unicast request for each incoming SIP request, that is, they do not "fork" requests. However, servers MAY choose to always operate in a mode that allows issuing of several requests, as described in Section 12.4.
这类代理最多为每个传入SIP请求发出一个单播请求，也就是说，它们不“分叉”请求。但是，服务器可以选择始终以允许发出多个请求的模式运行，如第12.4节所述。
The server can forward the request and any responses. It does not have to maintain any state for the SIP transaction. Reliability is assured by the next redirect or stateful proxy server in the server chain.
服务器可以转发请求和任何响应。它不必维护SIP事务的任何状态。可靠性由服务器链中的下一个重定向或有状态代理服务器来保证。
A proxy server SHOULD cache the result of any address translations and the response to speed forwarding of retransmissions. After the cache entry has been expired, the server cannot tell whether an incoming request is actually a retransmission of an older request. The server will treat it as a new request and commence another search.
代理服务器应缓存任何地址转换的结果和响应，以加快重传的转发速度。缓存项过期后，服务器无法判断传入请求是否实际上是旧请求的重新传输。服务器会将其视为一个新请求，并开始另一次搜索。
The server MUST respond to the request immediately with a 100 (Trying) response.
服务器必须立即以100（尝试）响应响应请求。
Successful responses to an INVITE request MAY contain a Contact header field so that the following ACK or BYE bypasses the proxy search mechanism. If the proxy requires future requests to be routed through it, it adds a Record-Route header to the request (Section 6.29).
对INVITE请求的成功响应可能包含联系人标头字段，以便以下ACK或BYE绕过代理搜索机制。如果代理要求将来的请求通过它路由，它会向请求添加一个记录路由头（第6.29节）。
The following C-code describes the behavior of a proxy server issuing several requests in response to an incoming INVITE request. The function request(r, a, b) sends a SIP request of type r to address a, with branch id b. await_response() waits until a response is received and returns the response. close(a) closes the TCP connection to client with address a. response(r) sends a response to the client. ismulticast() returns 1 if the location is a multicast address and zero otherwise. The variable timeleft indicates the amount of time left until the maximum response time has expired. The variable recurse indicates whether the server will recursively try addresses returned through a 3xx response. A server MAY decide to recursively try only certain addresses, e.g., those which are within the same domain as the proxy server. Thus, an initial multicast request can trigger additional unicast requests.
下面的C代码描述代理服务器发出多个请求以响应传入的INVITE请求的行为。功能请求（r、a、b）向地址a发送类型为r的SIP请求，分支id为b。wait_response（）等待直到收到响应并返回响应。关闭（a）关闭与地址为a的客户端的TCP连接。响应（r）向客户端发送响应。ismulticast（）如果位置是多播地址，则返回1，否则返回0。变量timeleft表示最长响应时间到期前剩余的时间量。变量recurse指示服务器是否将递归地尝试通过3xx响应返回的地址。服务器可能决定仅递归地尝试某些地址，例如，与代理服务器位于同一域中的地址。因此，初始多播请求可以触发额外的单播请求。
/* request type */
typedef enum {INVITE, ACK, BYE, OPTIONS, CANCEL, REGISTER} Method;
/* request type */
typedef enum {INVITE, ACK, BYE, OPTIONS, CANCEL, REGISTER} Method;
process_request(Method R, int N, address_t address[])
{
struct {
int branch; /* branch id */
int done; /* has responded */
} outgoing[];
int done[]; /* address has responded */
char *location[]; /* list of locations */
int heard = 0; /* number of sites heard from */
int class; /* class of status code */
int timeleft = 120; /* sample timeout value */
int loc = 0; /* number of locations */
struct { /* response */
int status; /* response: CANCEL=-1 */
int locations; /* number of redirect locations */
char *location[]; /* redirect locations */
address_t a; /* address of respondent */
int branch; /* branch identifier */
} r, best; /* response, best response */
int i;
process_request(Method R, int N, address_t address[])
{
struct {
int branch; /* branch id */
int done; /* has responded */
} outgoing[];
int done[]; /* address has responded */
char *location[]; /* list of locations */
int heard = 0; /* number of sites heard from */
int class; /* class of status code */
int timeleft = 120; /* sample timeout value */
int loc = 0; /* number of locations */
struct { /* response */
int status; /* response: CANCEL=-1 */
int locations; /* number of redirect locations */
char *location[]; /* redirect locations */
address_t a; /* address of respondent */
int branch; /* branch identifier */
} r, best; /* response, best response */
int i;
best.status = 1000;
for (i = 0; i < N; i++) {
best.status = 1000;
for (i = 0; i < N; i++) {
request(R, address[i], i);
outgoing[i].done = 0;
outgoing[i].branch = i;
}
request(R, address[i], i);
outgoing[i].done = 0;
outgoing[i].branch = i;
}
while (timeleft > 0 && heard < N) {
r = await_response();
class = r.status / 100;
while (timeleft > 0 && heard < N) {
r = await_response();
class = r.status / 100;
/* If final response, mark branch as done. */
if (class >= 2) {
heard++;
for (i = 0; i < N; i++) {
if (r.branch == outgoing[i].branch) {
outgoing[i].done = 1;
break;
}
}
}
/* CANCEL: respond, fork and wait for responses */
else if (class < 0) {
best.status = 200;
response(best);
for (i = 0; i < N; i++) {
if (!outgoing[i].done)
request(CANCEL, address[i], outgoing[i].branch);
}
best.status = -1;
}
/* If final response, mark branch as done. */
if (class >= 2) {
heard++;
for (i = 0; i < N; i++) {
if (r.branch == outgoing[i].branch) {
outgoing[i].done = 1;
break;
}
}
}
/* CANCEL: respond, fork and wait for responses */
else if (class < 0) {
best.status = 200;
response(best);
for (i = 0; i < N; i++) {
if (!outgoing[i].done)
request(CANCEL, address[i], outgoing[i].branch);
}
best.status = -1;
}
/* Send an ACK */
/* Send an ACK */
if (class != 2) {
if (R == INVITE) request(ACK, r.a, r.branch);
}
if (class != 2) {
if (R == INVITE) request(ACK, r.a, r.branch);
}
if (class == 2) {
if (r.status < best.status) best = r;
break;
}
else if (class == 3) {
/* A server MAY optionally recurse. The server MUST check
* whether it has tried this location before and whether
* the location is part of the Via path of the incoming
* request. This check is omitted here for brevity.
* Multicast locations MUST NOT be returned to the client if
* the server is not recursing.
if (class == 2) {
if (r.status < best.status) best = r;
break;
}
else if (class == 3) {
/* A server MAY optionally recurse. The server MUST check
* whether it has tried this location before and whether
* the location is part of the Via path of the incoming
* request. This check is omitted here for brevity.
* Multicast locations MUST NOT be returned to the client if
* the server is not recursing.
*/
if (recurse) {
multicast = 0;
N += r.locations;
for (i = 0; i < r.locations; i++) {
request(R, r.location[i]);
}
} else if (!ismulticast(r.location)) {
best = r;
}
}
else if (class == 4) {
if (best.status >= 400) best = r;
}
else if (class == 5) {
if (best.status >= 500) best = r;
}
else if (class == 6) {
best = r;
break;
}
}
*/
if (recurse) {
multicast = 0;
N += r.locations;
for (i = 0; i < r.locations; i++) {
request(R, r.location[i]);
}
} else if (!ismulticast(r.location)) {
best = r;
}
}
else if (class == 4) {
if (best.status >= 400) best = r;
}
else if (class == 5) {
if (best.status >= 500) best = r;
}
else if (class == 6) {
best = r;
break;
}
}
/* We haven't heard anything useful from anybody. */
if (best.status == 1000) {
best.status = 404;
}
if (best.status/100 != 3) loc = 0;
response(best);
}
/* We haven't heard anything useful from anybody. */
if (best.status == 1000) {
best.status = 404;
}
if (best.status/100 != 3) loc = 0;
response(best);
}
Responses are processed as follows. The process completes (and state can be freed) when all requests have been answered by final status responses (for unicast) or 60 seconds have elapsed (for multicast). A proxy MAY send a CANCEL to all branches and return a 408 (Timeout) to the client after 60 seconds or more.
答复的处理如下。当所有请求都已由最终状态响应（对于单播）响应或已过60秒（对于多播）时，该过程完成（并且可以释放状态）。代理可以向所有分支发送取消，并在60秒或更长时间后向客户端返回408（超时）。
1xx: The proxy MAY forward the response upstream towards the client.
1xx：代理可以将响应向上游转发给客户端。
2xx: The proxy MUST forward the response upstream towards the client, without sending an ACK downstream. After receiving a 2xx, the server MAY terminate all other pending requests by sending a CANCEL request and closing the TCP connection, if applicable. (Terminating pending requests is advisable as searches consume resources. Also, INVITE requests could "ring" on a number of workstations if the callee is currently logged in more than once.)
2xx：代理必须将响应向上游转发到客户端，而不向下游发送ACK。在收到2xx后，服务器可以通过发送取消请求并关闭TCP连接（如果适用）来终止所有其他挂起的请求。（建议终止挂起的请求，因为搜索会消耗资源。此外，如果被叫方当前登录不止一次，INVITE请求可能会在多个工作站上“响起”。）
3xx: The proxy MUST send an ACK and MAY recurse on the listed Contact addresses. Otherwise, the lowest-numbered response is returned if there were no 2xx responses.
3xx：代理必须发送ACK，并且可能会在列出的联系人地址上递归。否则，如果没有2xx响应，则返回编号最低的响应。
Location lists are not merged as that would prevent forwarding of authenticated responses. Also, responses can have message bodies, so that merging is not feasible.
不会合并位置列表，因为这将阻止转发经过身份验证的响应。此外，响应可以有消息体，因此合并是不可行的。
4xx, 5xx: The proxy MUST send an ACK and remember the response if it has a lower status code than any previous 4xx and 5xx responses. On completion, the lowest-numbered response is returned if there were no 2xx or 3xx responses.
4xx、5xx：如果代理的状态代码低于之前的任何4xx和5xx响应，则代理必须发送ACK并记住响应。完成时，如果没有2xx或3xx响应，则返回编号最低的响应。
6xx: The proxy MUST forward the response to the client and send an ACK. Other pending requests MAY be terminated with CANCEL as described for 2xx responses.
6xx:代理必须将响应转发给客户端并发送ACK。如2xx响应所述，其他未决请求可通过取消终止。
A proxy server forwards any response for Call-IDs for which it does not have a pending transaction according to the response's Via header. User agent servers respond to BYE requests for unknown call legs with status code 481 (Transaction Does Not Exist); they drop ACK requests with unknown call legs silently.
代理服务器根据响应的Via标头转发其没有挂起事务的呼叫ID的任何响应。用户代理服务器响应未知呼叫分支的BYE请求，状态代码为481（事务不存在）；他们无声地丢弃带有未知呼叫分支的ACK请求。
Special considerations apply for choosing forwarding destinations for ACK and BYE requests. In most cases, these requests will bypass proxies and reach the desired party directly, keeping proxies from having to make forwarding decisions.
选择ACK和BYE请求的转发目的地时需要特别考虑。在大多数情况下，这些请求将绕过代理并直接到达所需方，从而使代理不必做出转发决定。
A proxy MAY maintain call state for a period of its choosing. If a proxy still has list of destinations that it forwarded the last INVITE to, it SHOULD direct ACK requests only to those downstream servers.
代理可以在其选择的一段时间内保持调用状态。如果代理仍然有它将上一次邀请转发到的目的地列表，它应该只将ACK请求定向到那些下游服务器。
13 Security Considerations
13安全考虑
SIP requests and responses can contain sensitive information about the communication patterns and communication content of individuals. The SIP message body MAY also contain encryption keys for the session itself. SIP supports three complementary forms of encryption to protect privacy:
SIP请求和响应可能包含有关个人通信模式和通信内容的敏感信息。SIP消息体还可以包含会话本身的加密密钥。SIP支持三种互补的加密形式以保护隐私：
o End-to-end encryption of the SIP message body and certain sensitive header fields;
o SIP消息体和某些敏感头字段的端到端加密；
o hop-by-hop encryption to prevent eavesdropping that tracks who is calling whom;
o 逐跳加密，防止窃听跟踪谁在呼叫谁；
o hop-by-hop encryption of Via fields to hide the route a request has taken.
o 逐跳加密Via字段，以隐藏请求采取的路由。
Not all of the SIP request or response can be encrypted end-to-end because header fields such as To and Via need to be visible to proxies so that the SIP request can be routed correctly. Hop-by-hop encryption encrypts the entire SIP request or response on the wire so that packet sniffers or other eavesdroppers cannot see who is calling whom. Hop-by-hop encryption can also encrypt requests and responses that have been end-to-end encrypted. Note that proxies can still see who is calling whom, and this information is also deducible by performing a network traffic analysis, so this provides a very limited but still worthwhile degree of protection.
并非所有SIP请求或响应都可以端到端加密，因为头字段（如to和Via）需要对代理可见，以便SIP请求可以正确路由。逐跳加密加密线路上的整个SIP请求或响应，以便数据包嗅探器或其他窃听器无法看到谁在呼叫谁。逐跳加密还可以加密已端到端加密的请求和响应。请注意，代理仍然可以看到谁在呼叫谁，并且此信息也可以通过执行网络流量分析来推断，因此这提供了非常有限但仍然值得保护的程度。
SIP Via fields are used to route a response back along the path taken by the request and to prevent infinite request loops. However, the information given by them can also provide useful information to an attacker. Section 6.22 describes how a sender can request that Via fields be encrypted by cooperating proxies without compromising the purpose of the Via field.
SIP Via字段用于沿请求所采用的路径将响应路由回，并防止无限请求循环。但是，它们提供的信息也可以为攻击者提供有用的信息。第6.22节描述了发送方如何通过合作代理请求对Via字段进行加密，而不影响Via字段的用途。
End-to-end encryption relies on keys shared by the two user agents involved in the request. Typically, the message is sent encrypted with the public key of the recipient, so that only that recipient can read the message. All implementations SHOULD support PGP-based encryption [33] and MAY implement other schemes.
端到端加密依赖于请求中涉及的两个用户代理共享的密钥。通常，邮件是用收件人的公钥加密发送的，因此只有该收件人才能读取邮件。所有实现都应支持基于PGP的加密[33]，并可能实现其他方案。
A SIP request (or response) is end-to-end encrypted by splitting the message to be sent into a part to be encrypted and a short header that will remain in the clear. Some parts of the SIP message, namely the request line, the response line and certain header fields marked with "n" in the "enc." column in Table 4 and 5 need to be read and returned by proxies and thus MUST NOT be encrypted end-to-end. Possibly sensitive information that needs to be made available as plaintext include destination address (To) and the forwarding path (Via) of the call. The Authorization header field MUST remain in the clear if it contains a digital signature as the signature is generated after encryption, but MAY be encrypted if it contains "basic" or "digest" authentication. The From header field SHOULD normally remain in the clear, but MAY be encrypted if required, in which case some proxies MAY return a 401 (Unauthorized) status if they require a From field.
SIP请求（或响应）通过将要发送的消息拆分为要加密的部分和保留在clear中的短头来进行端到端加密。SIP消息的某些部分，即请求行、响应行和表4和表5中“enc.”列中标记为“n”的某些头字段，需要由代理读取和返回，因此不能进行端到端加密。可能需要以明文形式提供的敏感信息包括呼叫的目标地址（to）和转发路径（Via）。如果授权标头字段包含加密后生成的数字签名，则该字段必须保持空白，但如果它包含“基本”或“摘要”身份验证，则可以对其进行加密。From标头字段通常应保持为clear（清除），但如果需要，可以进行加密。在这种情况下，如果某些代理需要From字段，则可能会返回401（未经授权）状态。
Other header fields MAY be encrypted or MAY travel in the clear as desired by the sender. The Subject, Allow and Content-Type header fields will typically be encrypted. The Accept, Accept-Language, Date, Expires, Priority, Require, Call-ID, Cseq, and Timestamp header fields will remain in the clear.
根据发送方的需要，其他标题字段可以加密或以明文形式传输。主题、允许和内容类型标题字段通常会加密。Accept、Accept Language、Date、Expires、Priority、Require、Call ID、Cseq和Timestamp头字段将保留在clear中。
All fields that will remain in the clear MUST precede those that will be encrypted. The message is encrypted starting with the first character of the first header field that will be encrypted and continuing through to the end of the message body. If no header fields are to be encrypted, encrypting starts with the second CRLF pair after the last header field, as shown below. Carriage return and line feed characters have been made visible as "$", and the encrypted part of the message is outlined.
将保留在清除中的所有字段必须位于将被加密的字段之前。该消息从将被加密的第一个标头字段的第一个字符开始加密，一直到消息正文的结尾。如果没有要加密的头字段，加密将从最后一个头字段后的第二个CRLF对开始，如下所示。回车符和换行符已显示为“$”，并概述了消息的加密部分。
INVITE sip:watson@boston.bell-telephone.com SIP/2.0$
Via: SIP/2.0/UDP 169.130.12.5$
To: T. A. Watson <sip:watson@bell-telephone.com>$
From: A. Bell <sip:a.g.bell@bell-telephone.com>$
Encryption: PGP version=5.0$
Content-Length: 224$
Call-ID: 187602141351@worcester.bell-telephone.com$
CSeq: 488$
$
*******************************************************
* Subject: Mr. Watson, come here.$ *
* Content-Type: application/sdp$ *
* $ *
* v=0$ *
* o=bell 53655765 2353687637 IN IP4 128.3.4.5$ *
* c=IN IP4 135.180.144.94$ *
* m=audio 3456 RTP/AVP 0 3 4 5$ *
*******************************************************
INVITE sip:watson@boston.bell-telephone.com SIP/2.0$
Via: SIP/2.0/UDP 169.130.12.5$
To: T. A. Watson <sip:watson@bell-telephone.com>$
From: A. Bell <sip:a.g.bell@bell-telephone.com>$
Encryption: PGP version=5.0$
Content-Length: 224$
Call-ID: 187602141351@worcester.bell-telephone.com$
CSeq: 488$
$
*******************************************************
* Subject: Mr. Watson, come here.$ *
* Content-Type: application/sdp$ *
* $ *
* v=0$ *
* o=bell 53655765 2353687637 IN IP4 128.3.4.5$ *
* c=IN IP4 135.180.144.94$ *
* m=audio 3456 RTP/AVP 0 3 4 5$ *
*******************************************************
An Encryption header field MUST be added to indicate the encryption mechanism used. A Content-Length field is added that indicates the length of the encrypted body. The encrypted body is preceded by a blank line as a normal SIP message body would be.
必须添加加密头字段以指示所使用的加密机制。添加了一个内容长度字段，指示加密正文的长度。与普通SIP消息正文一样，加密正文前面有一个空行。
Upon receipt by the called user agent possessing the correct decryption key, the message body as indicated by the Content-Length field is decrypted, and the now-decrypted body is appended to the clear-text header fields. There is no need for an additional Content-Length header field within the encrypted body because the length of the actual message body is unambiguous after decryption.
在被调用的用户代理收到具有正确解密密钥的消息后，将对内容长度字段指示的消息体进行解密，并将现在解密的消息体附加到明文头字段。加密正文中不需要额外的内容长度头字段，因为解密后实际消息正文的长度是明确的。
Had no SIP header fields required encryption, the message would have been as below. Note that the encrypted body MUST then include a blank line (start with CRLF) to disambiguate between any possible SIP header fields that might have been present and the SIP message body.
如果没有需要加密的SIP头字段，消息将如下所示。请注意，加密的正文必须包含一个空行（以CRLF开头），以消除可能存在的任何可能的SIP头字段与SIP消息正文之间的歧义。
INVITE sip:watson@boston.bell-telephone.com SIP/2.0$
Via: SIP/2.0/UDP 169.130.12.5$
To: T. A. Watson <sip:watson@bell-telephone.com>$
From: A. Bell <a.g.bell@bell-telephone.com>$
Encryption: PGP version=5.0$
Content-Type: application/sdp$
Content-Length: 107$
$
*************************************************
* $ *
* v=0$ *
* o=bell 53655765 2353687637 IN IP4 128.3.4.5$ *
* c=IN IP4 135.180.144.94$ *
* m=audio 3456 RTP/AVP 0 3 4 5$ *
*************************************************
INVITE sip:watson@boston.bell-telephone.com SIP/2.0$
Via: SIP/2.0/UDP 169.130.12.5$
To: T. A. Watson <sip:watson@bell-telephone.com>$
From: A. Bell <a.g.bell@bell-telephone.com>$
Encryption: PGP version=5.0$
Content-Type: application/sdp$
Content-Length: 107$
$
*************************************************
* $ *
* v=0$ *
* o=bell 53655765 2353687637 IN IP4 128.3.4.5$ *
* c=IN IP4 135.180.144.94$ *
* m=audio 3456 RTP/AVP 0 3 4 5$ *
*************************************************
SIP requests can be sent securely using end-to-end encryption and authentication to a called user agent that sends an insecure response. This is allowed by the SIP security model, but is not a good idea. However, unless the correct behavior is explicit, it would not always be possible for the called user agent to infer what a reasonable behavior was. Thus when end-to-end encryption is used by the request originator, the encryption key to be used for the response SHOULD be specified in the request. If this were not done, it might be possible for the called user agent to incorrectly infer an appropriate key to use in the response. Thus, to prevent key-guessing becoming an acceptable strategy, we specify that a called user agent receiving a request that does not specify a key to be used for the response SHOULD send that response unencrypted.
SIP请求可以使用端到端加密和身份验证安全地发送到发送不安全响应的被叫用户代理。这是SIP安全模型允许的，但不是一个好主意。然而，除非正确的行为是明确的，否则被调用的用户代理并不总是能够推断出合理的行为是什么。因此，当请求发起人使用端到端加密时，应在请求中指定用于响应的加密密钥。如果不这样做，则被调用的用户代理可能会错误地推断出响应中要使用的适当密钥。因此，为了防止密钥猜测成为一种可接受的策略，我们指定接收到未指定用于响应的密钥的请求的被调用用户代理应未加密地发送该响应。
Any SIP header fields that were encrypted in a request SHOULD also be encrypted in an encrypted response. Contact response fields MAY be encrypted if the information they contain is sensitive, or MAY be left in the clear to permit proxies more scope for localized searches.
在请求中加密的任何SIP头字段也应在加密响应中加密。如果联系人响应字段中包含的信息是敏感的，则可以对其进行加密，或者可以将其保留在空白处，以允许代理在更大范围内进行本地化搜索。
Normally, proxies are not allowed to alter end-to-end header fields and message bodies. Proxies MAY, however, encrypt an unsigned request or response with the key of the call recipient.
通常，不允许代理更改端到端头字段和消息正文。然而，代理可以使用呼叫接收者的密钥对未签名的请求或响应进行加密。
Proxies need to encrypt a SIP request if the end system cannot perform encryption or to enforce organizational security policies.
如果终端系统无法执行加密或强制执行组织安全策略，则代理需要加密SIP请求。
SIP requests and responses MAY also be protected by security mechanisms at the transport or network layer. No particular mechanism is defined or recommended here. Two possibilities are IPSEC [34] or TLS [35]. The use of a particular mechanism will generally need to be specified out of band, through manual configuration, for example.
SIP请求和响应也可以由传输层或网络层的安全机制进行保护。此处未定义或推荐任何特定机制。两种可能性是IPSEC[34]或TLS[35]。特定机构的使用通常需要在带外指定，例如通过手动配置。
When Via header fields are to be hidden, a proxy that receives a request containing an appropriate "Hide: hop" header field (as specified in section 6.22) SHOULD encrypt the header field. As only the proxy that encrypts the field will decrypt it, the algorithm chosen is entirely up to the proxy implementor. Two methods satisfy these requirements:
当Via头字段要隐藏时，接收包含适当“Hide:hop”头字段（如第6.22节所述）请求的代理应加密头字段。由于只有对字段进行加密的代理才能对其进行解密，因此选择的算法完全取决于代理实现者。有两种方法满足这些要求：
o The server keeps a cache of Via header fields and the associated To header field, and replaces the Via header field with an index into the cache. On the reverse path, take the Via header field from the cache rather than the message.
o 服务器保留Via标头字段和关联到标头字段的缓存，并使用缓存中的索引替换Via标头字段。在反向路径上，从缓存中获取Via标头字段，而不是消息。
This is insufficient to prevent message looping, and so an additional ID MUST be added so that the proxy can detect loops. This SHOULD NOT normally be the address of the proxy as the goal is to hide the route, so instead a sufficiently large random number SHOULD be used by the proxy and maintained in the cache.
这不足以防止消息循环，因此必须添加额外的ID，以便代理可以检测循环。这通常不应该是代理的地址，因为目标是隐藏路由，因此代理应该使用足够大的随机数并在缓存中维护。
It is possible for replies to get directed to the wrong originator if the cache entry gets reused, so great care needs to be taken to ensure this does not happen.
如果缓存项被重用，则回复可能被定向到错误的发起人，因此需要非常小心以确保不会发生这种情况。
o The server MAY use a secret key to encrypt the Via field, a timestamp and an appropriate checksum in any such message with the same secret key. The checksum is needed to detect whether successful decoding has occurred, and the timestamp is
o 服务器可以使用密钥来用相同的密钥加密任何此类消息中的Via字段、时间戳和适当的校验和。需要校验和来检测是否已成功解码，并且时间戳为
required to prevent possible replay attacks and to ensure that no two requests from the same previous hop have the same encrypted Via field. This is the preferred solution.
需要防止可能的重播攻击，并确保来自同一前一跳的两个请求没有相同的加密Via字段。这是首选的解决方案。
Protective measures need to be taken to prevent an active attacker from modifying and replaying SIP requests and responses. The same cryptographic measures that are used to ensure the authenticity of the SIP message also serve to authenticate the originator of the message. However, the "basic" and "digest" authentication mechanism offer authentication only, without message integrity.
需要采取保护措施，防止主动攻击者修改和重播SIP请求和响应。用于确保SIP消息真实性的相同加密措施也用于验证消息的发起人。但是，“基本”和“摘要”身份验证机制只提供身份验证，没有消息完整性。
Transport-layer or network-layer authentication MAY be used for hop-by-hop authentication. SIP also extends the HTTP WWW-Authenticate (Section 6.42) and Authorization (Section 6.11) header field and their Proxy counterparts to include cryptographically strong signatures. SIP also supports the HTTP "basic" and "digest" schemes (see Section 14) and other HTTP authentication schemes to be defined that offer a rudimentary mechanism of ascertaining the identity of the caller.
传输层或网络层身份验证可用于逐跳身份验证。SIP还扩展了HTTP WWW认证（第6.42节）和授权（第6.11节）头字段及其代理对应项，以包括加密强签名。SIP还支持HTTP“基本”和“摘要”方案（见第14节）以及其他待定义的HTTP认证方案，这些方案提供了确定调用方身份的基本机制。
Since SIP requests are often sent to parties with which no prior communication relationship has existed, we do not specify authentication based on shared secrets.
由于SIP请求通常发送给不存在事先通信关系的各方，因此我们不指定基于共享机密的身份验证。
SIP requests MAY be authenticated using the Authorization header field to include a digital signature of certain header fields, the request method and version number and the payload, none of which are modified between client and called user agent. The Authorization header field is used in requests to authenticate the request originator end-to-end to proxies and the called user agent, and in responses to authenticate the called user agent or proxies returning their own failure codes. If required, hop-by-hop authentication can be provided, for example, by the IPSEC Authentication Header.
SIP请求可以使用授权报头字段进行身份验证，以包括特定报头字段的数字签名、请求方法和版本号以及有效载荷，在客户端和被调用的用户代理之间不修改这些字段。Authorization header字段用于在请求中向代理和被叫用户代理端到端验证请求发起人，以及在响应中验证被叫用户代理或返回其自身故障代码的代理。如果需要，可以提供逐跳身份验证，例如，通过IPSEC身份验证头。
SIP does not dictate which digital signature scheme is used for authentication, but does define how to provide authentication using PGP in Section 15. As indicated above, SIP implementations MAY also use "basic" and "digest" authentication and other authentication mechanisms defined for HTTP. Note that "basic" authentication has severe security limitations. The following does not apply to these schemes.
SIP没有规定使用哪个数字签名方案进行身份验证，但在第15节中定义了如何使用PGP提供身份验证。如上所述，SIP实现还可以使用“基本”和“摘要”身份验证以及为HTTP定义的其他身份验证机制。请注意，“基本”身份验证具有严重的安全限制。以下内容不适用于这些计划。
To cryptographically sign a SIP request, the order of the SIP header fields is important. When an Authorization header field is present, it indicates that all header fields following the Authorization
要对SIP请求进行加密签名，SIP头字段的顺序很重要。当存在授权标头字段时，表示授权之后的所有标头字段
header field have been included in the signature. Therefore, hop-by-hop header fields which MUST or SHOULD be modified by proxies MUST precede the Authorization header field as they will generally be modified or added-to by proxy servers. Hop-by-hop header fields which MAY be modified by a proxy MAY appear before or after the Authorization header. When they appear before, they MAY be modified by a proxy. When they appear after, they MUST NOT be modified by a proxy. To sign a request, a client constructs a message from the request method (in upper case) followed, without LWS, by the SIP version number, followed, again without LWS, by the request headers to be signed and the message body. The message thus constructed is then signed.
签名中已包含标题字段。因此，必须或应该由代理修改的逐跳标头字段必须位于授权标头字段之前，因为代理服务器通常会修改或添加这些字段。可由代理修改的逐跳标头字段可能出现在授权标头之前或之后。当它们出现在前面时，可能会被代理修改。当它们出现在后面时，不得由代理修改。为了对请求进行签名，客户机从请求方法（大写）构造一条消息，后跟SIP版本号（不带LWS），后跟要签名的请求头和消息体（同样不带LWS）。然后对这样构造的消息进行签名。
For example, if the SIP request is to be:
例如，如果SIP请求是：
INVITE sip:watson@boston.bell-telephone.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
Authorization: PGP version=5.0, signature=...
From: A. Bell <sip:a.g.bell@bell-telephone.com>
To: T. A. Watson <sip:watson@bell-telephone.com>
Call-ID: 187602141351@worcester.bell-telephone.com
Subject: Mr. Watson, come here.
Content-Type: application/sdp
Content-Length: ...
INVITE sip:watson@boston.bell-telephone.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
Authorization: PGP version=5.0, signature=...
From: A. Bell <sip:a.g.bell@bell-telephone.com>
To: T. A. Watson <sip:watson@bell-telephone.com>
Call-ID: 187602141351@worcester.bell-telephone.com
Subject: Mr. Watson, come here.
Content-Type: application/sdp
Content-Length: ...
v=0 o=bell 53655765 2353687637 IN IP4 128.3.4.5 c=IN IP4 135.180.144.94 m=audio 3456 RTP/AVP 0 3 4 5
v=0 o=IP4 128.3.4.5中的贝尔53655765 2353687637 c=IP4 135.180.144.94 m=audio 3456 RTP/AVP 0 3 4 5
Then the data block that is signed is:
那么签名的数据块是：
INVITESIP/2.0From: A. Bell <sip:a.g.bell@bell-telephone.com>
To: T. A. Watson <sip:watson@bell-telephone.com>
Call-ID: 187602141351@worcester.bell-telephone.com
Subject: Mr. Watson, come here.
Content-Type: application/sdp
Content-Length: ...
INVITESIP/2.0From: A. Bell <sip:a.g.bell@bell-telephone.com>
To: T. A. Watson <sip:watson@bell-telephone.com>
Call-ID: 187602141351@worcester.bell-telephone.com
Subject: Mr. Watson, come here.
Content-Type: application/sdp
Content-Length: ...
v=0 o=bell 53655765 2353687637 IN IP4 128.3.4.5 c=IN IP4 135.180.144.94 m=audio 3456 RTP/AVP 0 3 4 5
v=0 o=IP4 128.3.4.5中的贝尔53655765 2353687637 c=IP4 135.180.144.94 m=audio 3456 RTP/AVP 0 3 4 5
Clients wishing to authenticate requests MUST construct the portion of the message below the Authorization header using a canonical form. This allows a proxy to parse the message, take it apart, and reconstruct it, without causing an authentication failure due to extra white space, for example. Canonical form consists of the following rules:
希望对请求进行身份验证的客户端必须使用规范形式构造授权标头下方的消息部分。例如，这允许代理解析消息、将其拆分并重新构建，而不会由于额外的空白而导致身份验证失败。规范形式由以下规则组成：
o No short form header fields
o 没有短格式标题字段
o Header field names are capitalized as shown in this document
o 标题字段名称大写，如本文档所示
o No white space between the header name and the colon
o 标题名称和冒号之间没有空格
o A single space after the colon
o 冒号后的单个空格
o Line termination with a CRLF
o 带CRLF的线路终端
o No line folding
o 无折线
o No comma separated lists of header values; each must appear as a separate header
o 没有逗号分隔的标题值列表；每个标题必须显示为单独的标题
o Only a single SP between tokens, between tokens and quoted strings, and between quoted strings; no SP after last token or quoted string
o 令牌之间、令牌和带引号的字符串之间以及带引号的字符串之间只有一个SP；最后一个标记或带引号的字符串后没有SP
o No LWS between tokens and separators, except as described above for after the colon in header fields
o 标记和分隔符之间不存在LW，除非上文描述了标头字段中冒号后的LW
Note that if a message is encrypted and authenticated using a digital signature, when the message is generated encryption is performed before the digital signature is generated. On receipt, the digital signature is checked before decryption.
请注意，如果使用数字签名对消息进行加密和身份验证，则在生成消息时，将在生成数字签名之前执行加密。收到后，在解密之前检查数字签名。
A client MAY require that a server sign its response by including a Require: org.ietf.sip.signed-response request header field. The client indicates the desired authentication method via the WWW-Authenticate header.
客户端可能要求服务器通过包含require:org.ietf.sip.signed-response请求头字段对其响应进行签名。客户端通过WWW Authenticate标头指示所需的身份验证方法。
The correct behavior in handling unauthenticated responses to a request that requires authenticated responses is described in section 13.2.1.
第13.2.1节描述了对需要认证响应的请求处理未经认证响应的正确行为。
There is the possibility that an eavesdropper listens to requests and then injects unauthenticated responses that terminate, redirect or otherwise interfere with a call. (Even encrypted requests contain enough information to fake a response.)
窃听者可能会监听请求，然后注入未经验证的响应，这些响应会终止、重定向或以其他方式干扰呼叫。（即使是加密的请求也包含足够的信息来伪造响应。）
Clients need to be particularly careful with 3xx redirection responses. Thus a client receiving, for example, a 301 (Moved Permanently) which was not authenticated when the public key of the called user agent is known to the client, and authentication was requested in the request SHOULD be treated as suspicious. The correct behavior in such a case would be for the called-user to form a dated response containing the Contact field to be used, to sign it, and give this signed stub response to the proxy that will provide the redirection. Thus the response can be authenticated correctly. A client SHOULD NOT automatically redirect such a request to the new location without alerting the user to the authentication failure before doing so.
客户端需要特别小心3xx重定向响应。因此，例如，当客户端知道被调用用户代理的公钥并且在请求中请求了认证时，接收到未经认证的301（永久移动）的客户端应被视为可疑。在这种情况下，正确的行为是被调用的用户形成包含要使用的联系人字段的带日期响应，对其进行签名，并将此签名存根响应提供给将提供重定向的代理。因此，可以正确地对响应进行身份验证。客户机不应在未提醒用户身份验证失败之前自动将此类请求重定向到新位置。
Another problem might be responses such as 6xx failure responses which would simply terminate a search, or "4xx" and "5xx" response failures.
另一个问题可能是响应，例如6xx失败响应，它将简单地终止搜索，或者“4xx”和“5xx”响应失败。
If TCP is being used, a proxy SHOULD treat 4xx and 5xx responses as valid, as they will not terminate a search. However, fake 6xx responses from a rogue proxy terminate a search incorrectly. 6xx responses SHOULD be authenticated if requested by the client, and failure to do so SHOULD cause such a client to ignore the 6xx response and continue a search.
如果使用TCP，代理应将4xx和5xx响应视为有效响应，因为它们不会终止搜索。但是，来自恶意代理的虚假6xx响应会错误地终止搜索。如果客户机请求，应对6xx响应进行身份验证，否则会导致该客户机忽略6xx响应并继续搜索。
With UDP, the same problem with 6xx responses exists, but also an active eavesdropper can generate 4xx and 5xx responses that might cause a proxy or client to believe a failure occurred when in fact it did not. Typically 4xx and 5xx responses will not be signed by the called user agent, and so there is no simple way to detect these rogue responses. This problem is best prevented by using hop-by-hop encryption of the SIP request, which removes any additional problems that UDP might have over TCP.
使用UDP时，6xx响应也存在同样的问题，但活动窃听者也可以生成4xx和5xx响应，这可能会导致代理或客户端认为发生了故障，而实际上并没有。通常4xx和5xx响应不会由被调用的用户代理签名，因此没有简单的方法来检测这些恶意响应。最好通过使用SIP请求的逐跳加密来防止此问题，这样可以消除UDP在TCP上可能存在的任何其他问题。
These attacks are prevented by having the client require response authentication and dropping unauthenticated responses. A server user agent that cannot perform response authentication responds using the normal Require response of 420 (Bad Extension).
通过让客户端要求响应身份验证并删除未经身份验证的响应，可以防止这些攻击。无法执行响应身份验证的服务器用户代理使用正常的Require响应420（错误扩展）进行响应。
User location and SIP-initiated calls can violate a callee's privacy. An implementation 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.
用户位置和SIP发起的呼叫可能会侵犯被叫方的隐私。实现应该能够在每个用户的基础上限制向特定类别的呼叫者提供何种位置和可用性信息。
With either TCP or UDP, a denial of service attack exists by a rogue proxy sending 6xx responses. Although a client SHOULD choose to ignore such responses if it requested authentication, a proxy cannot do so. It is obliged to forward the 6xx response back to the client. The client can then ignore the response, but if it repeats the request it will probably reach the same rogue proxy again, and the process will repeat.
对于TCP或UDP，恶意代理发送6xx响应时存在拒绝服务攻击。虽然客户端在请求身份验证时应该选择忽略这些响应，但代理不能这样做。它有义务将6xx回复转发回客户。然后，客户端可以忽略响应，但如果它重复请求，它可能会再次到达同一个恶意代理，并且该过程将重复。
14 SIP Authentication using HTTP Basic and Digest Schemes
14使用HTTP基本和摘要方案的SIP身份验证
SIP implementations MAY use HTTP's basic and digest authentication mechanisms to provide a rudimentary form of security. This section overviews usage of these mechanisms in SIP. The basic operation is almost completely identical to that for HTTP [36]. This section outlines this operation, pointing to [36] for details, and noting the differences when used in SIP.
SIP实现可以使用HTTP的基本和摘要身份验证机制来提供基本形式的安全性。本节概述了这些机制在SIP中的使用。基本操作几乎与HTTP完全相同[36]。本节概述了此操作，详细信息请参考[36]，并注意在SIP中使用时的差异。
The framework for SIP authentication parallels that for HTTP [36]. In particular, the BNF for auth-scheme, auth-param, challenge, realm, realm-value, and credentials is identical. The 401 response is used by user agent servers in SIP to challenge the authorization of a user agent client. Additionally, registrars and redirect servers MAY make use of 401 responses for authorization, but proxies MUST NOT, and instead MAY use the 407 response. The requirements for inclusion of the Proxy-Authenticate, Proxy-Authorization, WWW-Authenticate, and Authorization in the various messages is identical to [36].
SIP认证的框架与HTTP的框架类似[36]。特别是，身份验证方案、身份验证参数、质询、领域、领域值和凭据的BNF是相同的。401响应由SIP中的用户代理服务器用于质疑用户代理客户端的授权。此外，注册器和重定向服务器可以使用401响应进行授权，但代理不能使用401响应，而是可以使用407响应。在各种消息中包含代理身份验证、代理授权、WWW身份验证和授权的要求与[36]相同。
Since SIP does not have the concept of a canonical root URL, the notion of protections spaces are interpreted differently for SIP. The realm is a protection domain for all SIP URIs with the same value for the userinfo, host and port part of the SIP Request-URI. For example:
由于SIP没有规范根URL的概念，因此保护空间的概念对SIP的解释不同。域是所有SIP URI的保护域，对于SIP请求URI的userinfo、host和port部分具有相同的值。例如：
INVITE sip:alice.wonderland@example.com SIP/2.0
WWW-Authenticate: Basic realm="business"
INVITE sip:alice.wonderland@example.com SIP/2.0
WWW-Authenticate: Basic realm="business"
and
和
INVITE sip:aw@example.com SIP/2.0
WWW-Authenticate: Basic realm="business"
INVITE sip:aw@example.com SIP/2.0
WWW-Authenticate: Basic realm="business"
define different protection realms according to this rule.
根据此规则定义不同的保护领域。
When a UAC resubmits a request with its credentials after receiving a 401 or 407 response, it MUST increment the CSeq header field as it would normally do when sending an updated request.
当UAC在收到401或407响应后使用其凭据重新提交请求时，它必须像发送更新的请求时通常那样增加CSeq头字段。
The rules for basic authentication follow those defined in [36], but with the words "origin server" replaced with "user agent server, redirect server , or registrar".
基本身份验证的规则遵循[36]中定义的规则，但将“原始服务器”替换为“用户代理服务器、重定向服务器或注册器”。
Since SIP URIs are not hierarchical, the paragraph in [36] that states that "all paths at or deeper than the depth of the last symbolic element in the path field of the Request-URI also are within the protection space specified by the Basic realm value of the current challenge" does not apply for SIP. SIP clients MAY preemptively send the corresponding Authorization header with requests for SIP URIs within the same protection realm (as defined above) without receipt of another challenge from the server.
由于SIP URI不是分层的，[36]中的段落指出“位于请求URI路径字段中最后一个符号元素深度或更深的所有路径也在当前质询的基本领域值指定的保护空间内”，该段落不适用于SIP。SIP客户端可以在不接收来自服务器的另一个质询的情况下，先发制人地发送相应的授权报头以及对相同保护域（如上所述）内的SIP URI的请求。
The rules for digest authentication follow those defined in [36], with "HTTP 1.1" replaced by "SIP/2.0" in addition to the following differences:
摘要身份验证的规则遵循[36]中定义的规则，除以下区别外，“HTTP 1.1”替换为“SIP/2.0”：
1. The URI included in the challenge has the following BNF:
1. 质询中包含的URI具有以下BNF：
URI = SIP-URL
URI = SIP-URL
2. The BNF for digest-uri-value is:
2. 摘要uri的BNF值为：
digest-uri-value = Request-URI ; a defined in Section 4.3
摘要uri值=请求uri；a在第4.3节中定义
3. The example procedure for choosing a nonce based on Etag does not work for SIP.
3. 基于Etag选择nonce的示例过程不适用于SIP。
4. The Authentication-Info and Proxy-Authentication-Info fields are not used in SIP.
4. 身份验证信息和代理身份验证信息字段不在SIP中使用。
5. The text in [36] regarding cache operation does not apply to SIP.
5. [36]中关于缓存操作的文本不适用于SIP。
6. [36] requires that a server check that the URI in the request line, and the URI included in the Authorization header, point to the same resource. In a SIP context, these two URI's may actually 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 corresponds to a user that the server is willing to accept forwarded or direct calls for.
6. [36]要求服务器检查请求行中的URI和授权标头中包含的URI是否指向同一资源。在SIP上下文中，由于在某个代理上进行转发，这两个URI实际上可能引用不同的用户。因此，在SIP中，服务器可以检查授权报头中的请求uri是否对应于服务器愿意接受转发或直接呼叫的用户。
The use of the Proxy-Authentication and Proxy-Authorization parallel that as described in [36], with one difference. Proxies MUST NOT add the Proxy-Authorization header. 407 responses MUST be forwarded upstream towards the client following the procedures for any other response. It is the client's responsibility to add the Proxy-Authorization header containing credentials for the proxy which has asked for authentication.
代理身份验证和代理授权的使用与[36]中所述的相同，但有一个区别。代理不得添加代理授权标头。407响应必须按照任何其他响应的程序向上游转发给客户。客户端负责添加代理授权标头，该标头包含请求身份验证的代理的凭据。
If a proxy were to resubmit a request with a Proxy-Authorization header field, it would need to increment the CSeq in the new request. However, this would mean that the UAC which submitted the original request would discard a response from the UAS, as the CSeq value would be different.
如果代理要使用代理授权标头字段重新提交请求，则需要在新请求中增加CSeq。然而，这意味着提交原始请求的UAC将放弃来自UAS的响应，因为CSeq值将不同。
See sections 6.26 and 6.27 for additional information on usage of these fields as they apply to SIP.
有关这些字段应用于SIP时的用法的更多信息，请参见第6.26节和第6.27节。
15 SIP Security Using PGP
15使用PGP的SIP安全性
The "pgp" authentication scheme is based on the model that the client authenticates itself with a request signed with the client's private key. The server can then ascertain the origin of the request if it has access to the public key, preferably signed by a trusted third party.
“pgp”身份验证方案基于这样一种模型，即客户端通过使用客户端私钥签名的请求对自己进行身份验证。然后，如果服务器可以访问公钥（最好由可信的第三方签名），则服务器可以确定请求的来源。
WWW-Authenticate = "WWW-Authenticate" ":" "pgp" pgp-challenge
pgp-challenge = * (";" pgp-params )
pgp-params = realm | pgp-version | pgp-algorithm | nonce
realm = "realm" "=" realm-value
realm-value = quoted-string
pgp-version = "version" "="
<"> digit *( "." digit ) *letter <">
pgp-algorithm = "algorithm" "=" ( "md5" | "sha1" | token )
nonce = "nonce" "=" nonce-value
nonce-value = quoted-string
WWW-Authenticate = "WWW-Authenticate" ":" "pgp" pgp-challenge
pgp-challenge = * (";" pgp-params )
pgp-params = realm | pgp-version | pgp-algorithm | nonce
realm = "realm" "=" realm-value
realm-value = quoted-string
pgp-version = "version" "="
<"> digit *( "." digit ) *letter <">
pgp-algorithm = "algorithm" "=" ( "md5" | "sha1" | token )
nonce = "nonce" "=" nonce-value
nonce-value = quoted-string
The meanings of the values of the parameters used above are as follows:
上述参数值的含义如下：
realm: A string to be displayed to users so they know which identity to use. This string SHOULD contain at least the name of the host performing the authentication and MAY additionally indicate the collection of users who might have access. An example might be " Users with call-out privileges ".
领域：向用户显示的字符串，以便他们知道使用哪个标识。此字符串应至少包含执行身份验证的主机的名称，并可另外指示可能具有访问权限的用户集合。例如，“具有调出权限的用户”。
pgp-algorithm: The value of this parameter indicates the PGP message integrity check (MIC) to be used to produce the signature. If this not present it is assumed to be "md5". The currently defined values are "md5" for the MD5 checksum, and "sha1" for the SHA.1 algorithm.
pgp算法：此参数的值表示用于生成签名的pgp消息完整性检查（MIC）。如果不存在，则假定为“md5”。当前定义的值是md5校验和的“md5”，以及SHA.1算法的“sha1”。
pgp-version: The version of PGP that the client MUST use. Common values are "2.6.2" and "5.0". The default is 5.0.
pgp版本：客户端必须使用的pgp版本。常用值为“2.6.2”和“5.0”。默认值为5.0。
nonce: A server-specified data string which should be uniquely generated each time a 401 response is made. It is RECOMMENDED that this string be base64 or hexadecimal data. Specifically, since the string is passed in the header lines as a quoted string, the double-quote character is not allowed. The contents of the nonce are implementation dependent. The quality of the implementation depends on a good choice. Since the nonce is used only to prevent replay attacks and is signed, a time stamp in units convenient to the server is sufficient.
nonce：服务器指定的数据字符串，每次401响应时应唯一生成该字符串。建议此字符串为base64或十六进制数据。特别是，由于字符串作为带引号的字符串在标题行中传递，因此不允许使用双引号字符。nonce的内容取决于实现。实施的质量取决于一个好的选择。由于nonce仅用于防止重播攻击，并且已签名，因此以便于服务器使用的单位表示的时间戳就足够了。
Replay attacks within the duration of the call setup are of limited interest, so that timestamps with a resolution of a few seconds are often should be sufficient. In that case, the server does not have to keep a record of the nonces.
呼叫设置持续时间内的重播攻击是有限的，因此分辨率为几秒钟的时间戳通常就足够了。在这种情况下，服务器不必保留nonce的记录。
Example:
例子：
WWW-Authenticate: pgp ;version="5.0"
;realm="Your Startrek identity, please" ;algorithm=md5
;nonce="913082051"
WWW-Authenticate: pgp ;version="5.0"
;realm="Your Startrek identity, please" ;algorithm=md5
;nonce="913082051"
The client is expected to retry the request, passing an Authorization header line, which is defined as follows.
客户机将重试该请求，并传递授权头行，其定义如下。
Authorization = "Authorization" ":" "pgp" *( ";" pgp-response )
pgp-response = realm | pgp-version | pgp-signature
| signed-by | nonce
pgp-signature = "signature" "=" quoted-string
signed-by = "signed-by" "=" <"> URI <">
Authorization = "Authorization" ":" "pgp" *( ";" pgp-response )
pgp-response = realm | pgp-version | pgp-signature
| signed-by | nonce
pgp-signature = "signature" "=" quoted-string
signed-by = "signed-by" "=" <"> URI <">
The client MUST increment the CSeq header before resubmitting the request. The signature MUST correspond to the From header of the request unless the signed-by parameter is provided.
客户端必须在重新提交请求之前增加CSeq头。除非提供了signed by参数，否则签名必须与请求的From标头相对应。
pgp-signature: The PGP ASCII-armored signature [33], as it appears between the "BEGIN PGP MESSAGE" and "END PGP MESSAGE" delimiters, without the version indication. The signature is included without any linebreaks.
pgp签名：pgp ASCII铠装签名[33]，出现在“开始pgp消息”和“结束pgp消息”分隔符之间，没有版本指示。签名包含在内，没有任何换行符。
The signature is computed across the nonce (if present), request method, request version and header fields following the Authorization header and the message body, in the same order as they appear in the message. The request method and version are prepended to the header fields without any white space. The signature is computed across the headers as sent, and the terminating CRLF. The CRLF following the Authorization header is NOT included in the signature.
签名是在授权标头和消息正文之后的nonce（如果存在）、请求方法、请求版本和标头字段中计算的，其顺序与它们在消息中出现的顺序相同。请求方法和版本在标题字段前加前缀，不带任何空格。签名是通过发送的头和终止的CRLF计算的。签名中不包括授权标头后面的CRLF。
A server MAY be configured not to generate nonces only if replay attacks are not a concern.
服务器可能被配置为仅在重播攻击不受关注时才不生成nonce。
Not generating nonces avoids the additional set of request, 401 response and possibly ACK messages and reduces delay by one round-trip time.
不生成nonce避免了额外的请求、401响应和可能的ACK消息集，并将延迟减少了一个往返时间。
Using the ASCII-armored version is about 25% less space-efficient than including the binary signature, but it is significantly easier for the receiver to piece together. Versions of the PGP program always include the full (compressed) signed text in their output unless ASCII-armored mode ( -sta ) is specified. Typical signatures are about 200 bytes long. -- The PGP signature mechanism allows the client to simply pass the request to an external PGP program. This relies on the requirement that proxy servers are not allowed to reorder or change header fields.
使用ASCII铠装版本比包含二进制签名节省大约25%的空间，但接收器更容易拼凑。除非指定了ASCII铠装模式（-sta），否则PGP程序版本的输出中始终包含完整（压缩）有符号文本。典型的签名大约有200字节长PGP签名机制允许客户端简单地将请求传递给外部PGP程序。这取决于代理服务器不允许重新排序或更改标题字段的要求。
realm: The realm is copied from the corresponding WWW-Authenticate header field parameter.
领域：领域是从相应的WWW Authenticate标头字段参数复制的。
signed-by: If and only if the request was not signed by the entity listed in the From header, the signed-by header indicates the name of the signing entity, expressed as a URI.
signed by：当且仅当请求未由From头中列出的实体签名时，signed by头指示签名实体的名称，表示为URI。
Receivers of signed SIP messages SHOULD discard any end-to-end header fields above the Authorization header, as they may have been maliciously added en route by a proxy.
签名SIP消息的接收者应丢弃授权标头上方的任何端到端标头字段，因为它们可能是在路由过程中由代理恶意添加的。
Example:
例子：
Authorization: pgp version="5.0"
;realm="Your Startrek identity, please"
;nonce="913082051"
;signature="iQB1AwUBNNJiUaYBnHmiiQh1AQFYsgL/Wt3dk6TWK81/b0gcNDf
VAUGU4rhEBW972IPxFSOZ94L1qhCLInTPaqhHFw1cb3lB01rA0RhpV4t5yCdUt
SRYBSkOK29o5e1KlFeW23EzYPVUm2TlDAhbcjbMdfC+KLFX
=aIrx"
Authorization: pgp version="5.0"
;realm="Your Startrek identity, please"
;nonce="913082051"
;signature="iQB1AwUBNNJiUaYBnHmiiQh1AQFYsgL/Wt3dk6TWK81/b0gcNDf
VAUGU4rhEBW972IPxFSOZ94L1qhCLInTPaqhHFw1cb3lB01rA0RhpV4t5yCdUt
SRYBSkOK29o5e1KlFeW23EzYPVUm2TlDAhbcjbMdfC+KLFX
=aIrx"
The PGP encryption scheme uses the following syntax:
PGP加密方案使用以下语法：
Encryption = "Encryption" ":" "pgp" pgp-eparams
pgp-eparams = 1# ( pgp-version | pgp-encoding )
pgp-encoding = "encoding" "=" "ascii" | token
Encryption = "Encryption" ":" "pgp" pgp-eparams
pgp-eparams = 1# ( pgp-version | pgp-encoding )
pgp-encoding = "encoding" "=" "ascii" | token
encoding: Describes the encoding or "armor" used by PGP. The value "ascii" refers to the standard PGP ASCII armor, without the lines containing "BEGIN PGP MESSAGE" and "END PGP MESSAGE" and without the version identifier. By default, the encrypted part is included as binary.
编码：描述PGP使用的编码或“装甲”。值“ascii”指的是标准PGP ascii铠装，没有包含“开始PGP消息”和“结束PGP消息”的行，也没有版本标识符。默认情况下，加密部分包含为二进制。
Example:
例子：
Encryption: pgp version="2.6.2", encoding="ascii"
Encryption: pgp version="2.6.2", encoding="ascii"
Response-Key = "Response-Key" ":" "pgp" pgp-eparams
pgp-eparams = 1# ( pgp-version | pgp-encoding | pgp-key)
pgp-key = "key" "=" quoted-string
Response-Key = "Response-Key" ":" "pgp" pgp-eparams
pgp-eparams = 1# ( pgp-version | pgp-encoding | pgp-key)
pgp-key = "key" "=" quoted-string
If ASCII encoding has been requested via the encoding parameter, the key parameter contains the user's public key as extracted from the pgp key ring with the "pgp -kxa user ".
如果已通过编码参数请求ASCII编码，则密钥参数包含从带有“pgp-kxa user”的pgp密钥环中提取的用户公钥。
Example:
例子：
Response-Key: pgp version="2.6.2", encoding="ascii",
key="mQBtAzNWHNYAAAEDAL7QvAdK2utY05wuUG+ItYK5tCF8HNJM60sU4rLaV+eUnkMk
mOmJWtc2wXcZx1XaXb2lkydTQOesrUR75IwNXBuZXPEIMThEa5WLsT7VLme7njnx
sE86SgWmAZx5ookIdQAFEbQxSGVubmluZyBTY2h1bHpyaW5uZSA8c2NodWx6cmlu
bmVAY3MuY29sdW1iaWEuZWR1Pg==
=+y19"
Response-Key: pgp version="2.6.2", encoding="ascii",
key="mQBtAzNWHNYAAAEDAL7QvAdK2utY05wuUG+ItYK5tCF8HNJM60sU4rLaV+eUnkMk
mOmJWtc2wXcZx1XaXb2lkydTQOesrUR75IwNXBuZXPEIMThEa5WLsT7VLme7njnx
sE86SgWmAZx5ookIdQAFEbQxSGVubmluZyBTY2h1bHpyaW5uZSA8c2NodWx6cmlu
bmVAY3MuY29sdW1iaWEuZWR1Pg==
=+y19"
16 Examples
16例
In the following examples, we often omit the message body and the corresponding Content-Length and Content-Type headers for brevity.
在下面的示例中，为了简洁起见，我们通常省略消息体以及相应的内容长度和内容类型头。
A user at host saturn.bell-tel.com registers on start-up, via multicast, with the local SIP server named bell-tel.com. In the example, the user agent on saturn expects to receive SIP requests on UDP port 3890.
主机saturn.bell-tel.com上的用户通过多播向名为bell-tel.com的本地SIP服务器注册启动。在本例中，saturn上的用户代理希望在UDP端口3890上接收SIP请求。
C->S: REGISTER sip:bell-tel.com SIP/2.0
Via: SIP/2.0/UDP saturn.bell-tel.com
From: sip:watson@bell-tel.com
To: sip:watson@bell-tel.com
Call-ID: 70710@saturn.bell-tel.com
CSeq: 1 REGISTER
Contact: <sip:watson@saturn.bell-tel.com:3890;transport=udp>
Expires: 7200
C->S: REGISTER sip:bell-tel.com SIP/2.0
Via: SIP/2.0/UDP saturn.bell-tel.com
From: sip:watson@bell-tel.com
To: sip:watson@bell-tel.com
Call-ID: 70710@saturn.bell-tel.com
CSeq: 1 REGISTER
Contact: <sip:watson@saturn.bell-tel.com:3890;transport=udp>
Expires: 7200
The registration expires after two hours. Any future invitations for watson@bell-tel.com arriving at sip.bell-tel.com will now be redirected to watson@saturn.bell-tel.com, UDP port 3890.
注册两小时后到期。今后有没有邀请我参加watson@bell-到达sip.bell-tel.com的tel.com现在将重定向到watson@saturn.bell-电话，UDP端口3890。
If Watson wants to be reached elsewhere, say, an on-line service he uses while traveling, he updates his reservation after first cancelling any existing locations:
如果沃森想在其他地方联系到他，比如说他旅行时使用的在线服务，他会在取消任何现有地点后更新他的预订：
C->S: REGISTER sip:bell-tel.com SIP/2.0
Via: SIP/2.0/UDP saturn.bell-tel.com
From: sip:watson@bell-tel.com
To: sip:watson@bell-tel.com
Call-ID: 70710@saturn.bell-tel.com
CSeq: 2 REGISTER
Contact: *
Expires: 0
C->S: REGISTER sip:bell-tel.com SIP/2.0
Via: SIP/2.0/UDP saturn.bell-tel.com
From: sip:watson@bell-tel.com
To: sip:watson@bell-tel.com
Call-ID: 70710@saturn.bell-tel.com
CSeq: 2 REGISTER
Contact: *
Expires: 0
C->S: REGISTER sip:bell-tel.com SIP/2.0
Via: SIP/2.0/UDP saturn.bell-tel.com
From: sip:watson@bell-tel.com
To: sip:watson@bell-tel.com
Call-ID: 70710@saturn.bell-tel.com
CSeq: 3 REGISTER
Contact: sip:tawatson@example.com
C->S: REGISTER sip:bell-tel.com SIP/2.0
Via: SIP/2.0/UDP saturn.bell-tel.com
From: sip:watson@bell-tel.com
To: sip:watson@bell-tel.com
Call-ID: 70710@saturn.bell-tel.com
CSeq: 3 REGISTER
Contact: sip:tawatson@example.com
Now, the server will forward any request for Watson to the server at example.com, using the Request-URI tawatson@example.com. For the server at example.com to reach Watson, he will need to send a REGISTER there, or inform the server of his current location through some other means.
现在，服务器将使用请求URI将对Watson的任何请求转发到example.com上的服务器tawatson@example.com. 为了让example.com上的服务器联系到Watson，他需要在那里发送一个注册，或者通过其他方式通知服务器他的当前位置。
It is possible to use third-party registration. Here, the secretary jon.diligent registers his boss, T. Watson:
可以使用第三方注册。在这里，秘书jon.diligent登记了他的老板T.Watson：
C->S: REGISTER sip:bell-tel.com SIP/2.0
Via: SIP/2.0/UDP pluto.bell-tel.com
From: sip:jon.diligent@bell-tel.com
To: sip:watson@bell-tel.com
Call-ID: 17320@pluto.bell-tel.com
CSeq: 1 REGISTER
Contact: sip:tawatson@example.com
C->S: REGISTER sip:bell-tel.com SIP/2.0
Via: SIP/2.0/UDP pluto.bell-tel.com
From: sip:jon.diligent@bell-tel.com
To: sip:watson@bell-tel.com
Call-ID: 17320@pluto.bell-tel.com
CSeq: 1 REGISTER
Contact: sip:tawatson@example.com
The request could be sent to either the registrar at bell-tel.com or the server at example.com. In the latter case, the server at example.com would proxy the request to the address indicated in the Request-URI. Then, Max-Forwards header could be used to restrict the registration to that server.
请求可以发送给bell-tel.com上的注册官或example.com上的服务器。在后一种情况下，example.com上的服务器将把请求代理到请求URI中指示的地址。然后，可以使用Max Forwards标头将注册限制到该服务器。
The first example invites schooler@vlsi.cs.caltech.edu to a multicast session. All examples use the Session Description Protocol (SDP) (RFC 2327 [6]) as the session description format.
第一个例子邀请schooler@vlsi.cs.caltech.edu到多播会话。所有示例都使用会话描述协议（SDP）（RFC 2327[6]）作为会话描述格式。
C->S: INVITE sip:schooler@cs.caltech.edu SIP/2.0
Via: SIP/2.0/UDP csvax.cs.caltech.edu;branch=8348
;maddr=239.128.16.254;ttl=16
Via: SIP/2.0/UDP north.east.isi.edu
From: Mark Handley <sip:mjh@isi.edu>
To: Eve Schooler <sip:schooler@caltech.edu>
Call-ID: 2963313058@north.east.isi.edu
CSeq: 1 INVITE
Subject: SIP will be discussed, too
Content-Type: application/sdp
Content-Length: 187
C->S: INVITE sip:schooler@cs.caltech.edu SIP/2.0
Via: SIP/2.0/UDP csvax.cs.caltech.edu;branch=8348
;maddr=239.128.16.254;ttl=16
Via: SIP/2.0/UDP north.east.isi.edu
From: Mark Handley <sip:mjh@isi.edu>
To: Eve Schooler <sip:schooler@caltech.edu>
Call-ID: 2963313058@north.east.isi.edu
CSeq: 1 INVITE
Subject: SIP will be discussed, too
Content-Type: application/sdp
Content-Length: 187
v=0
o=user1 53655765 2353687637 IN IP4 128.3.4.5
s=Mbone Audio
i=Discussion of Mbone Engineering Issues
e=mbone@somewhere.com
c=IN IP4 224.2.0.1/127
t=0 0
m=audio 3456 RTP/AVP 0
v=0
o=user1 53655765 2353687637 IN IP4 128.3.4.5
s=Mbone Audio
i=Discussion of Mbone Engineering Issues
e=mbone@somewhere.com
c=IN IP4 224.2.0.1/127
t=0 0
m=audio 3456 RTP/AVP 0
The From request header above states that the request was initiated by mjh@isi.edu and addressed to schooler@caltech.edu (From header fields). The Via fields list the hosts along the path from invitation initiator (the last element of the list) towards the callee. In the example above, the message was last multicast to the administratively scoped group 239.128.16.254 with a ttl of 16 from the host csvax.cs.caltech.edu. The second Via header field indicates that it was originally sent from the host north.east.isi.edu. The Request-URI indicates that the request is currently being being addressed to schooler@cs.caltech.edu, the local address that csvax looked up for the callee.
上面的From请求标头声明请求是由mjh@isi.edu致schooler@caltech.edu（来自标题字段）。Via字段列出从邀请发起方（列表的最后一个元素）到被调用方的路径上的主机。在上面的示例中，该消息是来自主机csvax.cs.caltech.edu的最后一个多播到管理作用域组239.128.16.254，ttl为16。第二个Via标头字段表示它最初是从主机north.east.isi.edu发送的。请求URI表示当前正在向其发送请求schooler@cs.caltech.edu，csvax查找被叫方的本地地址。
In this case, the session description is using the Session Description Protocol (SDP), as stated in the Content-Type header.
在这种情况下，会话描述使用会话描述协议（SDP），如内容类型标头中所述。
The header is terminated by an empty line and is followed by a message body containing the session description.
标头以空行结尾，后面是包含会话描述的消息正文。
The called user agent, directly or indirectly through proxy servers, indicates that it is alerting ("ringing") the called party:
被叫用户代理直接或间接通过代理服务器表示它正在向被叫方发出警报（“振铃”）：
S->C: SIP/2.0 180 Ringing
Via: SIP/2.0/UDP csvax.cs.caltech.edu;branch=8348
;maddr=239.128.16.254;ttl=16
Via: SIP/2.0/UDP north.east.isi.edu
From: Mark Handley <sip:mjh@isi.edu>
To: Eve Schooler <sip:schooler@caltech.edu> ;tag=9883472
Call-ID: 2963313058@north.east.isi.edu
CSeq: 1 INVITE
S->C: SIP/2.0 180 Ringing
Via: SIP/2.0/UDP csvax.cs.caltech.edu;branch=8348
;maddr=239.128.16.254;ttl=16
Via: SIP/2.0/UDP north.east.isi.edu
From: Mark Handley <sip:mjh@isi.edu>
To: Eve Schooler <sip:schooler@caltech.edu> ;tag=9883472
Call-ID: 2963313058@north.east.isi.edu
CSeq: 1 INVITE
A sample response to the invitation is given below. The first line of the response states the SIP version number, that it is a 200 (OK) response, which means the request was successful. The Via headers are taken from the request, and entries are removed hop by hop as the response retraces the path of the request. A new authentication field MAY be added by the invited user's agent if required. The Call-ID is taken directly from the original request, along with the remaining fields of the request message. The original sense of From field is preserved (i.e., it is the session initiator).
下面给出了对邀请的回复示例。响应的第一行表示SIP版本号，这是一个200（OK）响应，这意味着请求成功。从请求中获取Via头，并在响应返回请求路径时逐跳删除条目。如果需要，受邀请用户的代理可以添加新的身份验证字段。调用ID直接取自原始请求以及请求消息的其余字段。原始意义上的From字段被保留（即，它是会话发起方）。
In addition, the Contact header gives details of the host where the user was located, or alternatively the relevant proxy contact point which should be reachable from the caller's host.
此外，联系人标头提供了用户所在主机的详细信息，或者可以从调用方主机访问的相关代理联系人。
S->C: SIP/2.0 200 OK
Via: SIP/2.0/UDP csvax.cs.caltech.edu;branch=8348
;maddr=239.128.16.254;ttl=16
Via: SIP/2.0/UDP north.east.isi.edu
From: Mark Handley <sip:mjh@isi.edu>
To: Eve Schooler <sip:schooler@caltech.edu> ;tag=9883472
Call-ID: 2963313058@north.east.isi.edu
CSeq: 1 INVITE
Contact: sip:es@jove.cs.caltech.edu
S->C: SIP/2.0 200 OK
Via: SIP/2.0/UDP csvax.cs.caltech.edu;branch=8348
;maddr=239.128.16.254;ttl=16
Via: SIP/2.0/UDP north.east.isi.edu
From: Mark Handley <sip:mjh@isi.edu>
To: Eve Schooler <sip:schooler@caltech.edu> ;tag=9883472
Call-ID: 2963313058@north.east.isi.edu
CSeq: 1 INVITE
Contact: sip:es@jove.cs.caltech.edu
The caller confirms the invitation by sending an ACK request to the location named in the Contact header:
呼叫者通过向联系人标头中指定的位置发送ACK请求来确认邀请：
C->S: ACK sip:es@jove.cs.caltech.edu SIP/2.0
Via: SIP/2.0/UDP north.east.isi.edu
From: Mark Handley <sip:mjh@isi.edu>
To: Eve Schooler <sip:schooler@caltech.edu> ;tag=9883472
Call-ID: 2963313058@north.east.isi.edu
CSeq: 1 ACK
C->S: ACK sip:es@jove.cs.caltech.edu SIP/2.0
Via: SIP/2.0/UDP north.east.isi.edu
From: Mark Handley <sip:mjh@isi.edu>
To: Eve Schooler <sip:schooler@caltech.edu> ;tag=9883472
Call-ID: 2963313058@north.east.isi.edu
CSeq: 1 ACK
For two-party Internet phone calls, the response must contain a description of where to send the data. In the example below, Bell calls Watson. Bell indicates that he can receive RTP audio codings 0 (PCMU), 3 (GSM), 4 (G.723) and 5 (DVI4).
对于两方互联网电话，响应必须包含数据发送位置的说明。在下面的例子中，贝尔打电话给沃森。贝尔表示他可以接收RTP音频编码0（PCMU）、3（GSM）、4（G.723）和5（DVI4）。
C->S: INVITE sip:watson@boston.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:watson@bell-tel.com>
Call-ID: 3298420296@kton.bell-tel.com
CSeq: 1 INVITE
Subject: Mr. Watson, come here.
Content-Type: application/sdp
Content-Length: ...
C->S: INVITE sip:watson@boston.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:watson@bell-tel.com>
Call-ID: 3298420296@kton.bell-tel.com
CSeq: 1 INVITE
Subject: Mr. Watson, come here.
Content-Type: application/sdp
Content-Length: ...
v=0 o=bell 53655765 2353687637 IN IP4 128.3.4.5 s=Mr. Watson, come here. c=IN IP4 kton.bell-tel.com m=audio 3456 RTP/AVP 0 3 4 5
v=0 o=IP4128.3.4.5中的贝尔53655765 2353687637 s=Watson先生，过来。c=在IP4 kton.bell-tel.com中m=音频3456 RTP/AVP 0 3 4 5
S->C: SIP/2.0 100 Trying
Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311
Call-ID: 3298420296@kton.bell-tel.com
CSeq: 1 INVITE
Content-Length: 0
S->C: SIP/2.0 100 Trying
Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311
Call-ID: 3298420296@kton.bell-tel.com
CSeq: 1 INVITE
Content-Length: 0
S->C: SIP/2.0 180 Ringing
Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311
Call-ID: 3298420296@kton.bell-tel.com
CSeq: 1 INVITE
Content-Length: 0
S->C: SIP/2.0 180 Ringing
Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311
Call-ID: 3298420296@kton.bell-tel.com
CSeq: 1 INVITE
Content-Length: 0
S->C: SIP/2.0 182 Queued, 2 callers ahead
Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311
Call-ID: 3298420296@kton.bell-tel.com
CSeq: 1 INVITE
Content-Length: 0
S->C: SIP/2.0 182 Queued, 2 callers ahead
Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311
Call-ID: 3298420296@kton.bell-tel.com
CSeq: 1 INVITE
Content-Length: 0
S->C: SIP/2.0 182 Queued, 1 caller ahead
Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311
Call-ID: 3298420296@kton.bell-tel.com
CSeq: 1 INVITE
Content-Length: 0
S->C: SIP/2.0 182 Queued, 1 caller ahead
Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311
Call-ID: 3298420296@kton.bell-tel.com
CSeq: 1 INVITE
Content-Length: 0
S->C: SIP/2.0 200 OK
Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: <sip:watson@bell-tel.com> ;tag=37462311
Call-ID: 3298420296@kton.bell-tel.com
CSeq: 1 INVITE
Contact: sip:watson@boston.bell-tel.com
Content-Type: application/sdp
Content-Length: ...
S->C: SIP/2.0 200 OK
Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: <sip:watson@bell-tel.com> ;tag=37462311
Call-ID: 3298420296@kton.bell-tel.com
CSeq: 1 INVITE
Contact: sip:watson@boston.bell-tel.com
Content-Type: application/sdp
Content-Length: ...
v=0 o=watson 4858949 4858949 IN IP4 192.1.2.3 s=I'm on my way c=IN IP4 boston.bell-tel.com m=audio 5004 RTP/AVP 0 3
v=0 o=watson 4858949 4858949在IP4 192.1.2.3中s=我在路上c=在IP4 boston.bell-tel.com中m=音频5004 RTP/AVP 0 3
The example illustrates the use of informational status responses. Here, the reception of the call is confirmed immediately (100), then, possibly after some database mapping delay, the call rings (180) and is then queued, with periodic status updates.
该示例演示了信息状态响应的使用。这里，立即确认呼叫的接收（100），然后，可能在一些数据库映射延迟之后，呼叫响起（180），然后排队，并定期进行状态更新。
Watson can only receive PCMU and GSM. Note that Watson's list of codecs may or may not be a subset of the one offered by Bell, as each party indicates the data types it is willing to receive. Watson will send audio data to port 3456 at c.bell-tel.com, Bell will send to port 5004 at boston.bell-tel.com.
沃森只能接收PCMU和GSM。请注意，Watson的编解码器列表可能是也可能不是Bell提供的编解码器列表的子集，因为各方都表示愿意接收的数据类型。沃森将音频数据发送到c.bell-tel.com的3456端口，贝尔将发送到boston.bell-tel.com的5004端口。
By default, the media session is one RTP session. Watson will receive RTCP packets on port 5005, while Bell will receive them on port 3457.
默认情况下，媒体会话是一个RTP会话。Watson将在端口5005接收RTCP数据包，而Bell将在端口3457接收RTCP数据包。
Since the two sides have agreed on the set of media, Bell confirms the call without enclosing another session description:
由于双方已就媒体设置达成一致意见，贝尔确认了这一呼吁，但未附上另一个会议说明：
C->S: ACK sip:watson@boston.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311
Call-ID: 3298420296@kton.bell-tel.com
CSeq: 1 ACK
C->S: ACK sip:watson@boston.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311
Call-ID: 3298420296@kton.bell-tel.com
CSeq: 1 ACK
To terminate a call, caller or callee can send a BYE request:
要终止呼叫，呼叫者或被呼叫者可以发送BYE请求：
C->S: BYE sip:watson@boston.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. A. Watson <sip:watson@bell-tel.com> ;tag=37462311
Call-ID: 3298420296@kton.bell-tel.com
CSeq: 2 BYE
C->S: BYE sip:watson@boston.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. A. Watson <sip:watson@bell-tel.com> ;tag=37462311
Call-ID: 3298420296@kton.bell-tel.com
CSeq: 2 BYE
If the callee wants to abort the call, it simply reverses the To and From fields. Note that it is unlikely that a BYE from the callee will traverse the same proxies as the original INVITE.
如果被调用方想要中止调用，它只需反转“收件人”和“发件人”字段。请注意，被调用方的BYE不太可能遍历与原始INVITE相同的代理。
In this example, Bell (a.g.bell@bell-tel.com) (C), currently seated at host c.bell-tel.com wants to call Watson (t.watson@ieee.org). At the time of the call, Watson is logged in at two workstations, t.watson@x.bell-tel.com (X) and watson@y.bell-tel.com (Y), and has registered with the IEEE proxy server (P) called sip.ieee.org. The IEEE server also has a registration for the home machine of Watson, at watson@h.bell-tel.com (H), as well as a permanent registration at watson@acm.org (A). For brevity, the examples omit the session description and Via header fields.
在本例中，Bell（a.g。bell@bell-目前坐在C.bell-tel.com主机上的tel.com（C）想打电话给沃森（t。watson@ieee.org). 通话时，Watson在两个工作站t登录。watson@x.bell-电话（X）及watson@y.bell-并已在名为sip.IEEE.org的IEEE代理服务器（P）上注册。IEEE服务器还注册了Watson的家用计算机，位于watson@h.bell-电话（H），以及在watson@acm.org(一)。为简洁起见，这些示例省略了会话描述和Via头字段。
Bell's user agent sends the invitation to the SIP server for the ieee.org domain:
Bell的用户代理向ieee.org域的SIP服务器发送邀请：
C->P: INVITE sip:t.watson@ieee.org SIP/2.0
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>
Call-ID: 31415@c.bell-tel.com
CSeq: 1 INVITE
C->P: INVITE sip:t.watson@ieee.org SIP/2.0
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>
Call-ID: 31415@c.bell-tel.com
CSeq: 1 INVITE
The SIP server at ieee.org tries the four addresses in parallel. It sends the following message to the home machine:
ieee.org上的SIP服务器并行尝试这四个地址。它将以下消息发送到主计算机：
P->H: INVITE sip:watson@h.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP sip.ieee.org ;branch=1
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>
Call-ID: 31415@c.bell-tel.com
CSeq: 1 INVITE
P->H: INVITE sip:watson@h.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP sip.ieee.org ;branch=1
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>
Call-ID: 31415@c.bell-tel.com
CSeq: 1 INVITE
This request immediately yields a 404 (Not Found) response, since Watson is not currently logged in at home:
此请求立即产生404（未找到）响应，因为Watson当前未在家登录：
H->P: SIP/2.0 404 Not Found
Via: SIP/2.0/UDP sip.ieee.org ;branch=1
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>;tag=87454273
H->P: SIP/2.0 404 Not Found
Via: SIP/2.0/UDP sip.ieee.org ;branch=1
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>;tag=87454273
Call-ID: 31415@c.bell-tel.com CSeq: 1 INVITE
呼叫ID:31415@c.bell-电话：CSeq:1邀请
The proxy ACKs the response so that host H can stop retransmitting it:
代理确认响应，以便主机H可以停止重新传输该响应：
P->H: ACK sip:watson@h.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP sip.ieee.org ;branch=1
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>;tag=87454273
Call-ID: 31415@c.bell-tel.com
CSeq: 1 ACK
P->H: ACK sip:watson@h.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP sip.ieee.org ;branch=1
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>;tag=87454273
Call-ID: 31415@c.bell-tel.com
CSeq: 1 ACK
Also, P attempts to reach Watson through the ACM server:
此外，P试图通过ACM服务器联系Watson：
P->A: INVITE sip:watson@acm.org SIP/2.0
Via: SIP/2.0/UDP sip.ieee.org ;branch=2
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>
Call-ID: 31415@c.bell-tel.com
CSeq: 1 INVITE
P->A: INVITE sip:watson@acm.org SIP/2.0
Via: SIP/2.0/UDP sip.ieee.org ;branch=2
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>
Call-ID: 31415@c.bell-tel.com
CSeq: 1 INVITE
In parallel, the next attempt proceeds, with an INVITE to X and Y:
同时，下一次尝试继续进行，邀请X和Y：
P->X: INVITE sip:t.watson@x.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP sip.ieee.org ;branch=3
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>
Call-ID: 31415@c.bell-tel.com
CSeq: 1 INVITE
P->X: INVITE sip:t.watson@x.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP sip.ieee.org ;branch=3
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>
Call-ID: 31415@c.bell-tel.com
CSeq: 1 INVITE
P->Y: INVITE sip:watson@y.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP sip.ieee.org ;branch=4
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>
Call-ID: 31415@c.bell-tel.com
CSeq: 1 INVITE
P->Y: INVITE sip:watson@y.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP sip.ieee.org ;branch=4
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>
Call-ID: 31415@c.bell-tel.com
CSeq: 1 INVITE
As it happens, both Watson at X and a colleague in the other lab at host Y hear the phones ringing and pick up. Both X and Y return 200s via the proxy to Bell.
碰巧的是，X的沃森和Y主机另一个实验室的一位同事都听到了电话铃响并接了电话。X和Y都通过代理将200s返回给Bell。
X->P: SIP/2.0 200 OK
Via: SIP/2.0/UDP sip.ieee.org ;branch=3
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org> ;tag=192137601
Call-ID: 31415@c.bell-tel.com
CSeq: 1 INVITE
Contact: sip:t.watson@x.bell-tel.com
X->P: SIP/2.0 200 OK
Via: SIP/2.0/UDP sip.ieee.org ;branch=3
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org> ;tag=192137601
Call-ID: 31415@c.bell-tel.com
CSeq: 1 INVITE
Contact: sip:t.watson@x.bell-tel.com
Y->P: SIP/2.0 200 OK
Via: SIP/2.0/UDP sip.ieee.org ;branch=4
Via: SIP/2.0/UDP c.bell-tel.com
Contact: sip:t.watson@y.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org> ;tag=35253448
Call-ID: 31415@c.bell-tel.com
CSeq: 1 INVITE
Y->P: SIP/2.0 200 OK
Via: SIP/2.0/UDP sip.ieee.org ;branch=4
Via: SIP/2.0/UDP c.bell-tel.com
Contact: sip:t.watson@y.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org> ;tag=35253448
Call-ID: 31415@c.bell-tel.com
CSeq: 1 INVITE
Both responses are forwarded to Bell, using the Via information. At this point, the ACM server is still searching its database. P can now cancel this attempt:
这两个响应都使用Via信息转发给Bell。此时，ACM服务器仍在搜索其数据库。P现在可以取消此尝试：
P->A: CANCEL sip:watson@acm.org SIP/2.0
Via: SIP/2.0/UDP sip.ieee.org ;branch=2
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>
Call-ID: 31415@c.bell-tel.com
CSeq: 1 CANCEL
P->A: CANCEL sip:watson@acm.org SIP/2.0
Via: SIP/2.0/UDP sip.ieee.org ;branch=2
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>
Call-ID: 31415@c.bell-tel.com
CSeq: 1 CANCEL
The ACM server gladly stops its neural-network database search and responds with a 200. The 200 will not travel any further, since P is the last Via stop.
ACM服务器欣然停止其神经网络数据库搜索，并以200的响应。由于P是最后一个过孔止点，200将不再行驶。
A->P: SIP/2.0 200 OK
Via: SIP/2.0/UDP sip.ieee.org ;branch=2
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>
A->P: SIP/2.0 200 OK
Via: SIP/2.0/UDP sip.ieee.org ;branch=2
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>
Call-ID: 31415@c.bell-tel.com CSeq: 1 CANCEL
呼叫ID:31415@c.bell-电话：CSeq:1取消
Bell gets the two 200 responses from X and Y in short order. Bell's reaction now depends on his software. He can either send an ACK to both if human intelligence is needed to determine who he wants to talk to or he can automatically reject one of the two calls. Here, he acknowledges both, separately and directly to the final destination:
Bell在短时间内得到X和Y的两个200响应。贝尔的反应现在取决于他的软件。如果需要人类智能来确定他想与谁通话，他可以向双方发送ACK，也可以自动拒绝两个电话中的一个。在此，他分别和直接向最终目的地承认：
C->X: ACK sip:t.watson@x.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>;tag=192137601
Call-ID: 31415@c.bell-tel.com
CSeq: 1 ACK
C->X: ACK sip:t.watson@x.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>;tag=192137601
Call-ID: 31415@c.bell-tel.com
CSeq: 1 ACK
C->Y: ACK sip:watson@y.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>;tag=35253448
Call-ID: 31415@c.bell-tel.com
CSeq: 1 ACK
C->Y: ACK sip:watson@y.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>;tag=35253448
Call-ID: 31415@c.bell-tel.com
CSeq: 1 ACK
After a brief discussion between Bell with X and Y, it becomes clear that Watson is at X. (Note that this is not a three-way call; only Bell can talk to X and Y, but X and Y cannot talk to each other.) Thus, Bell sends a BYE to Y, which is replied to:
在贝尔与X和Y进行简短讨论后，很明显沃森在X。（注意，这不是一个三方通话；只有贝尔可以与X和Y通话，但X和Y不能相互通话。）因此，贝尔向Y发送了一个拜拜，Y回复为：
C->Y: BYE sip:watson@y.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>;tag=35253448
Call-ID: 31415@c.bell-tel.com
CSeq: 2 BYE
C->Y: BYE sip:watson@y.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>;tag=35253448
Call-ID: 31415@c.bell-tel.com
CSeq: 2 BYE
Y->C: SIP/2.0 200 OK
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>;tag=35253448
Call-ID: 31415@c.bell-tel.com
CSeq: 2 BYE
Y->C: SIP/2.0 200 OK
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>;tag=35253448
Call-ID: 31415@c.bell-tel.com
CSeq: 2 BYE
Replies with status codes 301 (Moved Permanently) or 302 (Moved Temporarily) specify another location using the Contact field. Continuing our earlier example, the server P at ieee.org decides to redirect rather than proxy the request:
状态代码为301（永久移动）或302（临时移动）的回复使用联系人字段指定其他位置。继续前面的示例，ieee.org上的服务器P决定重定向而不是代理请求：
P->C: SIP/2.0 302 Moved temporarily
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>;tag=72538263
Call-ID: 31415@c.bell-tel.com
CSeq: 1 INVITE
Contact: sip:watson@h.bell-tel.com,
sip:watson@acm.org, sip:t.watson@x.bell-tel.com,
sip:watson@y.bell-tel.com
CSeq: 1 INVITE
P->C: SIP/2.0 302 Moved temporarily
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>;tag=72538263
Call-ID: 31415@c.bell-tel.com
CSeq: 1 INVITE
Contact: sip:watson@h.bell-tel.com,
sip:watson@acm.org, sip:t.watson@x.bell-tel.com,
sip:watson@y.bell-tel.com
CSeq: 1 INVITE
As another example, assume Alice (A) wants to delegate her calls to Bob (B) while she is on vacation until July 29th, 1998. Any calls meant for her will reach Bob with Alice's To field, indicating to him what role he is to play. Charlie (C) calls Alice (A), whose server returns:
再举一个例子，假设Alice（A）想在1998年7月29日之前休假期间将电话委托给Bob（B）。任何关于她的电话都会传到鲍勃的电话亭，告诉他该扮演什么角色。Charlie（C）调用Alice（A），其服务器返回：
A->C: SIP/2.0 302 Moved temporarily
From: Charlie <sip:charlie@caller.com>
To: Alice <sip:alice@anywhere.com> ;tag=2332462
Call-ID: 27182@caller.com
Contact: sip:bob@anywhere.com
Expires: Wed, 29 Jul 1998 9:00:00 GMT
CSeq: 1 INVITE
A->C: SIP/2.0 302 Moved temporarily
From: Charlie <sip:charlie@caller.com>
To: Alice <sip:alice@anywhere.com> ;tag=2332462
Call-ID: 27182@caller.com
Contact: sip:bob@anywhere.com
Expires: Wed, 29 Jul 1998 9:00:00 GMT
CSeq: 1 INVITE
Charlie then sends the following request to the SIP server of the anywhere.com domain. Note that the server at anywhere.com forwards the request to Bob based on the Request-URI.
Charlie然后向anywhere.com域的SIP服务器发送以下请求。注意，anywhere.com上的服务器根据请求URI将请求转发给Bob。
C->B: INVITE sip:bob@anywhere.com SIP/2.0
From: sip:charlie@caller.com
To: sip:alice@anywhere.com
Call-ID: 27182@caller.com
CSeq: 2 INVITE
C->B: INVITE sip:bob@anywhere.com SIP/2.0
From: sip:charlie@caller.com
To: sip:alice@anywhere.com
Call-ID: 27182@caller.com
CSeq: 2 INVITE
In the third redirection example, we assume that all outgoing requests are directed through a local firewall F at caller.com, with Charlie again inviting Alice:
在第三个重定向示例中，我们假设所有传出请求都通过caller.com上的本地防火墙F进行定向，Charlie再次邀请Alice：
C->F: INVITE sip:alice@anywhere.com SIP/2.0
From: sip:charlie@caller.com
To: Alice <sip:alice@anywhere.com>
Call-ID: 27182@caller.com
CSeq: 1 INVITE
C->F: INVITE sip:alice@anywhere.com SIP/2.0
From: sip:charlie@caller.com
To: Alice <sip:alice@anywhere.com>
Call-ID: 27182@caller.com
CSeq: 1 INVITE
The local firewall at caller.com happens to be overloaded and thus redirects the call from Charlie to a secondary server S:
caller.com上的本地防火墙碰巧过载，因此将呼叫从Charlie重定向到辅助服务器S:
F->C: SIP/2.0 302 Moved temporarily
From: sip:charlie@caller.com
To: Alice <sip:alice@anywhere.com>
Call-ID: 27182@caller.com
CSeq: 1 INVITE
Contact: <sip:alice@anywhere.com:5080;maddr=spare.caller.com>
F->C: SIP/2.0 302 Moved temporarily
From: sip:charlie@caller.com
To: Alice <sip:alice@anywhere.com>
Call-ID: 27182@caller.com
CSeq: 1 INVITE
Contact: <sip:alice@anywhere.com:5080;maddr=spare.caller.com>
Based on this response, Charlie directs the same invitation to the secondary server spare.caller.com at port 5080, but maintains the same Request-URI as before:
根据此响应，Charlie将相同的邀请发送到端口5080处的备用服务器spare.caller.com，但保持与之前相同的请求URI：
C->S: INVITE sip:alice@anywhere.com SIP/2.0
From: sip:charlie@caller.com
To: Alice <sip:alice@anywhere.com>
Call-ID: 27182@caller.com
CSeq: 2 INVITE
C->S: INVITE sip:alice@anywhere.com SIP/2.0
From: sip:charlie@caller.com
To: Alice <sip:alice@anywhere.com>
Call-ID: 27182@caller.com
CSeq: 2 INVITE
An example of a 606 (Not Acceptable) response is:
606（不可接受）响应的一个示例是：
S->C: SIP/2.0 606 Not Acceptable
From: sip:mjh@isi.edu
To: <sip:schooler@cs.caltech.edu> ;tag=7434264
Call-ID: 14142@north.east.isi.edu
S->C: SIP/2.0 606 Not Acceptable
From: sip:mjh@isi.edu
To: <sip:schooler@cs.caltech.edu> ;tag=7434264
Call-ID: 14142@north.east.isi.edu
CSeq: 1 INVITE
Contact: sip:mjh@north.east.isi.edu
Warning: 370 "Insufficient bandwidth (only have ISDN)",
305 "Incompatible media format",
330 "Multicast not available"
Content-Type: application/sdp
Content-Length: 50
CSeq: 1 INVITE
Contact: sip:mjh@north.east.isi.edu
Warning: 370 "Insufficient bandwidth (only have ISDN)",
305 "Incompatible media format",
330 "Multicast not available"
Content-Type: application/sdp
Content-Length: 50
v=0
s=Let's talk
b=CT:128
c=IN IP4 north.east.isi.edu
m=audio 3456 RTP/AVP 5 0 7
m=video 2232 RTP/AVP 31
v=0
s=Let's talk
b=CT:128
c=IN IP4 north.east.isi.edu
m=audio 3456 RTP/AVP 5 0 7
m=video 2232 RTP/AVP 31
In this example, the original request specified a bandwidth that was higher than the access link could support, requested multicast, and requested a set of media encodings. The response states that only 128 kb/s is available and that (only) DVI, PCM or LPC audio could be supported in order of preference.
在此示例中，原始请求指定的带宽高于访问链路可以支持的带宽，请求多播，并请求一组媒体编码。响应指出，只有128 kb/s可用，并且（仅）DVI、PCM或LPC音频可以按优先顺序支持。
The response also states that multicast is not available. In such a case, it might be appropriate to set up a transcoding gateway and re-invite the user.
响应还表示多播不可用。在这种情况下，可能适合设置转码网关并重新邀请用户。
A caller Alice can use an OPTIONS request to find out the capabilities of a potential callee Bob, without "ringing" the designated address. Bob returns a description indicating that he is capable of receiving audio encodings PCM Ulaw (payload type 0), 1016 (payload type 1), GSM (payload type 3), and SX7300/8000 (dynamic payload type 99), and video encodings H.261 (payload type 31) and H.263 (payload type 34).
呼叫方Alice可以使用选项请求查找潜在被呼叫方Bob的功能，而无需“拨打”指定地址。Bob返回一个说明，表明他能够接收音频编码PCM Ulaw（有效负载类型0）、1016（有效负载类型1）、GSM（有效负载类型3）和SX7300/8000（动态有效负载类型99）以及视频编码H.261（有效负载类型31）和H.263（有效负载类型34）。
C->S: OPTIONS sip:bob@example.com SIP/2.0
From: Alice <sip:alice@anywhere.org>
To: Bob <sip:bob@example.com>
Call-ID: 6378@host.anywhere.org
CSeq: 1 OPTIONS
Accept: application/sdp
C->S: OPTIONS sip:bob@example.com SIP/2.0
From: Alice <sip:alice@anywhere.org>
To: Bob <sip:bob@example.com>
Call-ID: 6378@host.anywhere.org
CSeq: 1 OPTIONS
Accept: application/sdp
S->C: SIP/2.0 200 OK
From: Alice <sip:alice@anywhere.org>
To: Bob <sip:bob@example.com> ;tag=376364382
S->C: SIP/2.0 200 OK
From: Alice <sip:alice@anywhere.org>
To: Bob <sip:bob@example.com> ;tag=376364382
Call-ID: 6378@host.anywhere.org
Content-Length: 81
Content-Type: application/sdp
Call-ID: 6378@host.anywhere.org
Content-Length: 81
Content-Type: application/sdp
v=0
m=audio 0 RTP/AVP 0 1 3 99
m=video 0 RTP/AVP 31 34
a=rtpmap:99 SX7300/8000
v=0
m=audio 0 RTP/AVP 0 1 3 99
m=video 0 RTP/AVP 31 34
a=rtpmap:99 SX7300/8000
A Minimal Implementation
最低限度的实现
All clients MUST be able to generate the INVITE and ACK requests. Clients MUST generate and parse the Call-ID, Content-Length, Content-Type, CSeq, From and To headers. Clients MUST also parse the Require header. A minimal implementation MUST understand SDP (RFC 2327, [6]). It MUST be able to recognize the status code classes 1 through 6 and act accordingly.
所有客户端必须能够生成INVITE和ACK请求。客户端必须生成和解析调用ID、内容长度、内容类型、CSeq、From和To头。客户端还必须解析Require头。最低限度的实现必须理解SDP（RFC 2327[6]）。它必须能够识别状态代码类别1到6，并相应地采取行动。
The following capability sets build on top of the minimal implementation described in the previous paragraph. In general, each capability listed below builds on the ones above it:
以下功能集构建在上一段中描述的最小实现之上。通常，下面列出的每个功能都是基于上面的功能构建的：
Basic: A basic implementation adds support for the BYE method to allow the interruption of a pending call attempt. It includes a User-Agent header in its requests and indicates its preferred language in the Accept-Language header.
Basic：基本实现增加了对BYE方法的支持，以允许中断挂起的调用尝试。它在其请求中包含用户代理标头，并在接受语言标头中指示其首选语言。
Redirection: To support call forwarding, a client needs to be able to understand the Contact header, but only the SIP-URL part, not the parameters.
重定向：为了支持呼叫转移，客户端需要能够理解联系人头，但只能理解SIP-URL部分，而不能理解参数。
Firewall-friendly: A firewall-friendly client understands the Route and Record-Route header fields and can be configured to use a local proxy for all outgoing requests.
防火墙友好型：防火墙友好型客户端了解路由和记录路由头字段，可以配置为对所有传出请求使用本地代理。
Negotiation: A client MUST be able to request the OPTIONS method and understand the 380 (Alternative Service) status and the Contact parameters to participate in terminal and media negotiation. It SHOULD be able to parse the Warning response header to provide useful feedback to the caller.
协商：客户必须能够请求选项方法并了解380（替代服务）状态和联系参数，才能参与终端和媒体协商。它应该能够解析警告响应头，以便向调用者提供有用的反馈。
Authentication: If a client wishes to invite callees that require caller authentication, it MUST be able to recognize the 401 (Unauthorized) status code, MUST be able to generate the Authorization request header and MUST understand the WWW-Authenticate response header.
身份验证：如果客户端希望邀请需要呼叫者身份验证的被呼叫者，它必须能够识别401（未授权）状态码，必须能够生成授权请求标头，并且必须理解WWW Authenticate响应标头。
If a client wishes to use proxies that require caller authentication, it MUST be able to recognize the 407 (Proxy Authentication Required) status code, MUST be able to generate the Proxy-Authorization request header and understand the Proxy-Authenticate response header.
如果客户端希望使用需要呼叫者身份验证的代理，则它必须能够识别407（需要代理身份验证）状态代码，必须能够生成代理授权请求标头并理解代理身份验证响应标头。
A minimally compliant server implementation MUST understand the INVITE, ACK, OPTIONS and BYE requests. A proxy server MUST also understand CANCEL. It MUST parse and generate, as appropriate, the Call-ID, Content-Length, Content-Type, CSeq, Expires, From, Max-Forwards, Require, To and Via headers. It MUST echo the CSeq and Timestamp headers in the response. It SHOULD include the Server header in its responses.
最低限度兼容的服务器实现必须理解INVITE、ACK、选项和BYE请求。代理服务器还必须理解“取消”。它必须酌情解析和生成调用ID、内容长度、内容类型、CSeq、Expires、From、Max Forwards、Require、To和Via头。它必须在响应中回显CSeq和时间戳头。它应该在响应中包含服务器头。
Table 6 lists the headers that different implementations support. UAC refers to a user-agent client (calling user agent), UAS to a user-agent server (called user-agent).
表6列出了不同实现支持的头文件。UAC指用户代理客户端（调用用户代理），UAS指用户代理服务器（称为用户代理）。
The fields in the table have the following meaning. Type is as in Table 4 and 5. "-" indicates the field is not meaningful to this system (although it might be generated by it). "m" indicates the field MUST be understood. "b" indicates the field SHOULD be understood by a Basic implementation. "r" indicates the field SHOULD be understood if the system claims to understand redirection. "a" indicates the field SHOULD be understood if the system claims to support authentication. "e" indicates the field SHOULD be understood if the system claims to support encryption. "o" indicates support of the field is purely optional. Headers whose support is optional for all implementations are not shown.
表中的字段具有以下含义。类型如表4和表5所示。“-”表示该字段对此系统没有意义（尽管它可能是由它生成的）。“m”表示必须理解该字段。“b”表示该字段应为基本实现所理解。“r”表示如果系统声称理解重定向，则应理解该字段。“a”表示如果系统声称支持身份验证，则应理解该字段。“e”表示如果系统声称支持加密，则应理解该字段。“o”表示对字段的支持完全是可选的。未显示支持所有实现的可选标题。
type UAC proxy UAS registrar
_____________________________________________________
Accept R - o m m
Accept-Encoding R - - m m
Accept-Language R - b b b
Allow 405 o - - -
Authorization R a o a a
Call-ID g m m m m
Content-Encoding g m - m m
Content-Length g m m m m
Content-Type g m - m m
CSeq g m m m m
Encryption g e - e e
Expires g - o o m
From g m o m m
Hide R - m - -
Contact R - - - m
Contact r r r - -
Max-Forwards R - b - -
Proxy-Authenticate 407 a - - -
Proxy-Authorization R - a - -
Proxy-Require R - m - -
Require R m - m m
Response-Key R - - e e
Route R - m - -
Timestamp g o o m m
To g m m m m
Unsupported r b b - -
User-Agent g b - b -
Via g m m m m
WWW-Authenticate 401 a - - -
type UAC proxy UAS registrar
_____________________________________________________
Accept R - o m m
Accept-Encoding R - - m m
Accept-Language R - b b b
Allow 405 o - - -
Authorization R a o a a
Call-ID g m m m m
Content-Encoding g m - m m
Content-Length g m m m m
Content-Type g m - m m
CSeq g m m m m
Encryption g e - e e
Expires g - o o m
From g m o m m
Hide R - m - -
Contact R - - - m
Contact r r r - -
Max-Forwards R - b - -
Proxy-Authenticate 407 a - - -
Proxy-Authorization R - a - -
Proxy-Require R - m - -
Require R m - m m
Response-Key R - - e e
Route R - m - -
Timestamp g o o m m
To g m m m m
Unsupported r b b - -
User-Agent g b - b -
Via g m m m m
WWW-Authenticate 401 a - - -
Table 6: Header Field Processing Requirements
表6：标题字段处理要求
B Usage of the Session Description Protocol (SDP)
B会话描述协议（SDP）的使用
This section describes the use of the Session Description Protocol (SDP) (RFC 2327 [6]).
本节介绍会话描述协议（SDP）（RFC 2327[6]）的使用。
The caller and callee align their media descriptions so that the nth media stream ("m=" line) in the caller's session description corresponds to the nth media stream in the callee's description.
调用者和被调用者对齐其媒体描述，以便调用者会话描述中的第n个媒体流（“m=”line）对应于被调用者描述中的第n个媒体流。
All media descriptions SHOULD contain "a=rtpmap" mappings from RTP payload types to encodings.
所有媒体描述都应包含从RTP有效负载类型到编码的“a=rtpmap”映射。
This allows easier migration away from static payload types.
这使得从静态有效负载类型迁移更容易。
If the callee wants to neither send nor receive a stream offered by the caller, the callee sets the port number of that stream to zero in its media description.
如果被调用者既不想发送也不想接收调用者提供的流，则被调用者在其媒体描述中将该流的端口号设置为零。
There currently is no other way than port zero for the callee to refuse a bidirectional stream offered by the caller. Both caller and callee need to be aware what media tools are to be started.
当前，除了端口0之外，被调用方没有其他方法可以拒绝调用方提供的双向流。呼叫者和被呼叫者都需要知道要启动哪些媒体工具。
For example, assume that the caller Alice has included the following description in her INVITE request. It includes an audio stream and two bidirectional video streams, using H.261 (payload type 31) and MPEG (payload type 32).
例如，假设调用方Alice在她的INVITE请求中包含以下描述。它包括一个音频流和两个双向视频流，使用H.261（负载类型31）和MPEG（负载类型32）。
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
c=IN IP4 host.anywhere.com
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
c=IN IP4 host.anywhere.com
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
The callee, Bob, does not want to receive or send the first video stream, so it returns the media description below:
被叫方Bob不想接收或发送第一个视频流，因此返回以下媒体描述：
v=0
o=bob 2890844730 2890844730 IN IP4 host.example.com
c=IN IP4 host.example.com
m=audio 47920 RTP/AVP 0 1
a=rtpmap:0 PCMU/8000
a=rtpmap:1 1016/8000
m=video 0 RTP/AVP 31
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
v=0
o=bob 2890844730 2890844730 IN IP4 host.example.com
c=IN IP4 host.example.com
m=audio 47920 RTP/AVP 0 1
a=rtpmap:0 PCMU/8000
a=rtpmap:1 1016/8000
m=video 0 RTP/AVP 31
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
If a session description from a caller contains a media stream which is listed as send (receive) only, it means that the caller is only willing to send (receive) this stream, not receive (send). The same is true for the callee.
如果来自调用者的会话描述包含列为仅发送（接收）的媒体流，则表示调用者只愿意发送（接收）该流，而不愿意接收（发送）。被调用方也是如此。
For receive-only and send-or-receive streams, the port number and address in the session description indicate where the media stream should be sent to by the recipient of the session description, either caller or callee. For send-only streams, the address and port number have no significance and SHOULD be set to zero.
对于仅接收和发送或接收流，会话描述中的端口号和地址指示会话描述的接收者（呼叫者或被呼叫者）应将媒体流发送到的位置。对于仅发送流，地址和端口号没有意义，应设置为零。
The list of payload types for each media stream conveys two pieces of information, namely the set of codecs that the caller or callee is capable of sending or receiving, and the RTP payload type numbers used to identify those codecs. For receive-only or send-and-receive media streams, a caller SHOULD list all of the codecs it is capable of supporting in the session description in an INVITE or ACK. For send-only streams, the caller SHOULD indicate only those it wishes to send for this session. For receive-only streams, the payload type numbers indicate the value of the payload type field in RTP packets the caller is expecting to receive for that codec type. For send-only streams, the payload type numbers indicate the value of the payload type field in RTP packets the caller is planning to send for that codec type. For send-and-receive streams, the payload type numbers indicate the value of the payload type field the caller expects to both send and receive.
每个媒体流的有效负载类型列表传递两条信息，即调用者或被调用者能够发送或接收的编解码器集，以及用于识别这些编解码器的RTP有效负载类型号。对于仅接收或发送和接收媒体流，调用者应在INVITE或ACK中的会话描述中列出其能够支持的所有编解码器。对于仅发送流，调用者应仅指示其希望为此会话发送的流。对于仅接收流，有效负载类型编号表示调用者期望接收该编解码器类型的RTP数据包中有效负载类型字段的值。对于仅发送的流，有效负载类型编号表示调用者计划为该编解码器类型发送的RTP数据包中的有效负载类型字段的值。对于发送和接收流，有效负载类型编号指示调用者希望发送和接收的有效负载类型字段的值。
If a media stream is listed as receive-only by the caller, the callee lists, in the response, those codecs it intends to use from among the ones listed in the request. If a media stream is listed as send-only by the caller, the callee lists, in the response, those codecs it is willing to receive among the ones listed in the the request. If the media stream is listed as both send and receive, the callee lists those codecs it is capable of sending or receiving among the ones listed by the caller in the INVITE. The actual payload type numbers in the callee's session description corresponding to a particular codec MUST be the same as the caller's session description.
如果媒体流被列为仅由调用者接收，则被调用者在响应中从请求中列出的编解码器中列出其打算使用的编解码器。如果媒体流被列为仅由调用者发送，则被调用者将在响应中列出请求中列出的编解码器中它愿意接收的编解码器。如果媒体流同时被列为发送和接收，则被呼叫方将在邀请中列出其能够发送或接收的编解码器。与特定编解码器对应的被叫方会话描述中的实际有效负载类型号必须与被叫方会话描述相同。
If caller and callee have no media formats in common for a particular stream, the callee MUST return a session description containing the particular "m=" line, but with the port number set to zero, and no payload types listed.
如果调用者和被调用者对于特定流没有共同的媒体格式，则被调用者必须返回包含特定“m=”行的会话描述，但端口号设置为零，并且未列出有效负载类型。
If there are no media formats in common for all streams, the callee SHOULD return a 400 response, with a 304 Warning header field.
如果所有流没有共同的媒体格式，被叫方应返回400响应，带有304警告标头字段。
The interpretation of send-only and receive-only for multicast media sessions differs from that for unicast sessions. For multicast, send-only means that the recipient of the session description (caller or callee) SHOULD only send media streams to the address and port indicated. Receive-only means that the recipient of the session description SHOULD only receive media on the address and port indicated.
对于多播媒体会话，仅发送和仅接收的解释不同于单播会话。对于多播，仅发送意味着会话描述的接收者（呼叫者或被呼叫者）只应将媒体流发送到指定的地址和端口。Receive only（仅接收）表示会话描述的收件人应仅接收指定地址和端口上的媒体。
For multicast, receive and send multicast addresses are the same and all parties use the same port numbers to receive media data. If the session description provided by the caller is acceptable to the callee, the callee can choose not to include a session description or MAY echo the description in the response.
对于多播，接收和发送多播地址相同，各方使用相同的端口号来接收媒体数据。如果调用者提供的会话描述为被调用者所接受，则被调用者可以选择不包括会话描述，或者可以在响应中回显该描述。
A callee MAY, in the response, return a session description with some of the payload types removed, or port numbers set to zero (but no other value). This indicates to the caller that the callee does not support the given stream or media types which were removed. A callee MUST NOT change whether a given stream is send-only, receive-only, or send-and-receive.
被叫方可以在响应中返回会话描述，其中删除了一些有效负载类型，或者将端口号设置为零（但没有其他值）。这向调用者表明被调用者不支持已删除的给定流或媒体类型。被调用方不得更改给定流是仅发送、仅接收还是发送和接收。
If a callee does not support multicast at all, it SHOULD return a 400 status response and include a 330 Warning.
如果被叫方根本不支持多播，它应该返回400状态响应并包含330警告。
In some cases, a caller may not know the set of media formats which it can support at the time it would like to issue an invitation. This is the case when the caller is actually a gateway to another protocol which performs media format negotiation after call setup. When this occurs, a caller MAY issue an INVITE with a session description that contains no media lines. The callee SHOULD interpret this to mean that the caller wishes to participate in a multimedia session described by the session description, but that the media streams are not yet known. The callee SHOULD return a session description indicating the streams and media formats it is willing to support, however. The caller MAY update the session description either in the ACK request or in a re-INVITE at a later time, once the streams are known.
在某些情况下，调用方可能不知道在发出邀请时可以支持的媒体格式集。当调用方实际上是另一个协议的网关，该协议在调用设置后执行媒体格式协商时就是这种情况。发生这种情况时，调用方可能会发出一个包含会话描述的INVITE，该会话描述不包含媒体行。被呼叫方应将其解释为呼叫方希望参与由会话描述所描述的多媒体会话，但媒体流尚未知。然而，被叫方应该返回一个会话描述，指示它愿意支持的流和媒体格式。一旦流已知，调用者可以在稍后的时间在ACK请求或重新邀请中更新会话描述。
If a party in a call wants to put the other party "on hold", i.e., request that it temporarily stops sending one or more media streams, a party re-invites the other by sending an INVITE request with a modified session description. The session description is the same as
如果通话中的一方想让另一方“暂停”，即请求其暂时停止发送一个或多个媒体流，则一方通过发送带有修改会话描述的INVITE请求来重新邀请另一方。会话描述与相同
in the original invitation (or response), but the "c" destination addresses for the media streams to be put on hold are set to zero (0.0.0.0).
在原始邀请（或响应）中，但要挂起的媒体流的“c”目标地址设置为零（0.0.0.0）。
The SDP "s=" line and the SIP Subject header field have different meanings when inviting to a multicast session. The session description line describes the subject of the multicast session, while the SIP Subject header field describes the reason for the invitation. The example in Section 16.2 illustrates this point. For invitations to two-party sessions, the SDP "s=" line MAY be left empty.
SDP“s=”行和SIP主题标题字段在邀请多播会话时具有不同的含义。会话描述行描述多播会话的主题，而SIP主题标头字段描述邀请的原因。第16.2节中的示例说明了这一点。对于两党会议的邀请，SDP“s=”行可能为空。
The "o=" line is not strictly necessary for two-party sessions, but MUST be present to allow re-use of SDP-based tools.
“o=”行对于两党会议来说并非绝对必要，但必须存在，以允许重复使用基于SDP的工具。
C Summary of Augmented BNF
C增广BNF概述
All of the mechanisms specified in this document are described in both prose and an augmented Backus-Naur Form (BNF) similar to that used by RFC 822 [9]. Implementors will need to be familiar with the notation in order to understand this specification. The augmented BNF includes the following constructs:
本文件中规定的所有机制均以散文和类似于RFC 822[9]所用的增广巴科斯-诺尔形式（BNF）进行了描述。为了理解这个规范，实现者需要熟悉这个符号。扩充BNF包括以下结构：
name = definition
name = definition
The name of a rule is simply the name itself (without any enclosing "<" and ">") and is separated from its definition by the equal "=" character. White space is only significant in that indentation of continuation lines is used to indicate a rule definition that spans more than one line. Certain basic rules are in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle brackets are used within definitions whenever their presence will facilitate discerning the use of rule names.
规则的名称只是名称本身（没有任何封闭的“<”和“>”），并由相等的“=”字符与其定义分开。只有在连续行的缩进用于指示跨越多行的规则定义时，空格才有意义。某些基本规则是大写的，如SP、LWS、HT、CRLF、DIGIT、ALPHA等。如果有角括号，则在定义中使用角括号，以便于识别规则名称的使用。
"literal"
“文字”
Quotation marks surround literal text. Unless stated otherwise, the text is case-insensitive.
引号围绕文字。除非另有说明，否则文本不区分大小写。
rule1 | rule2
规则1 |规则2
Elements separated by a bar ("|") are alternatives, e.g., "yes | no" will accept yes or no.
由条（“|”）分隔的元素是可选的，例如，“是|否”将接受是或否。
(rule1 rule2)
（规则1规则2）
Elements enclosed in parentheses are treated as a single element. Thus, "(elem (foo | bar) elem)" allows the token sequences "elem foo elem" and "elem bar elem".
括号中的元素被视为单个元素。因此，“（elem（foo | bar）elem）”允许令牌序列“elem foo elem”和“elem bar elem”。
*rule
*统治
The character "*" preceding an element indicates repetition. The full form is "<n>*<m>element" indicating at least <n> and at most <m> occurrences of element. Default values are 0 and infinity so that "*(element)" allows any number, including zero; "1*element" requires at least one; and "1*2element" allows one or two.
元素前面的字符“*”表示重复。完整形式为“<n>*<m>元素”，表示元素至少出现<n>次，最多出现<m>次。默认值为0和无穷大，因此“*（元素）”允许任何数字，包括零；“1*元素”至少需要一个；“1*2元素”允许一个或两个。
[rule]
[规则]
Square brackets enclose optional elements; "[foo bar]" is equivalent to "*1(foo bar)".
方括号内包含可选元素；“[foo-bar]”相当于“*1（foo-bar）”。
N rule
规则
Specific repetition: "<n>(element)" is equivalent to "<n>*<n>(element)"; that is, exactly <n> occurrences of (element). Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three alphabetic characters.
具体重复：“<n>（元素）”相当于“<n>*<n>（元素）”；也就是说，正好<n>出现（元素）。因此，2DIGIT是一个2位数字，3ALPHA是一个由三个字母组成的字符串。
#rule
#统治
A construct "#" is defined, similar to "*", for defining lists of
elements. The full form is "<n>#<m> element" indicating at least <n>
and at most <m> elements, each separated by one or more commas (",")
and OPTIONAL linear white space (LWS). This makes the usual form of
lists very easy; a rule such as
A construct "#" is defined, similar to "*", for defining lists of
elements. The full form is "<n>#<m> element" indicating at least <n>
and at most <m> elements, each separated by one or more commas (",")
and OPTIONAL linear white space (LWS). This makes the usual form of
lists very easy; a rule such as
( *LWS element *( *LWS "," *LWS element ))
( *LWS element *( *LWS "," *LWS element ))
can be shown as 1# element. Wherever this construct is used, null elements are allowed, but do not contribute to the count of elements present. That is, "(element), , (element)" is permitted, but counts as only two elements. Therefore, where at least one element is required, at least one non-null element MUST be present. Default values are 0 and infinity so that "#element" allows any number, including zero; "1#element" requires at least one; and "1#2element" allows one or two.
可以显示为1#元素。无论在何处使用此构造，都允许使用null元素，但不影响当前元素的计数。也就是说，允许使用“（元素），（元素）”，但仅计为两个元素。因此，当至少需要一个元素时，必须至少存在一个非空元素。默认值为0和无穷大，因此“#元素”允许任何数字，包括零；“1#元素”至少需要一个；“1#2element”允许一个或两个。
; comment
; 议论
A semi-colon, set off some distance to the right of rule text, starts a comment that continues to the end of line. This is a simple way of including useful notes in parallel with the specifications.
分号在规则文本的右侧留出一定距离，开始一条注释，该注释一直延续到行尾。这是一种简单的方法，可以在规范中同时包含有用的注释。
implied *LWS
隐含*LWS
The grammar described by this specification is word-based. Except where noted otherwise, linear white space (LWS) can be included between any two adjacent words (token or quoted-string), and between adjacent tokens and separators, without changing the interpretation of a field. At least one delimiter (LWS and/or separators) MUST exist between any two tokens (for the definition of "token" below), since they would otherwise be interpreted as a single token.
本规范描述的语法是基于单词的。除非另有说明，线性空白（LWS）可以包括在任意两个相邻单词（标记或带引号的字符串）之间，以及相邻标记和分隔符之间，而不改变字段的解释。任何两个令牌（对于下面的“令牌”定义）之间必须至少存在一个分隔符（LW和/或分隔符），否则它们将被解释为单个令牌。
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定义。
OCTET = <any 8-bit sequence of data>
CHAR = <any US-ASCII character (octets 0 - 127)>
upalpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |
"J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" |
"S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"
lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" |
"j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" |
"s" | "t" | "u" | "v" | "w" | "x" | "y" | "z"
alpha = lowalpha | upalpha
digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
"8" | "9"
alphanum = alpha | digit
CTL = <any US-ASCII control character
(octets 0 -- 31) and DEL (127)>
CR = %d13 ; US-ASCII CR, carriage return character
LF = %d10 ; US-ASCII LF, line feed character
SP = %d32 ; US-ASCII SP, space character
HT = %d09 ; US-ASCII HT, horizontal tab character
CRLF = CR LF ; typically the end of a line
OCTET = <any 8-bit sequence of data>
CHAR = <any US-ASCII character (octets 0 - 127)>
upalpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |
"J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" |
"S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"
lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" |
"j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" |
"s" | "t" | "u" | "v" | "w" | "x" | "y" | "z"
alpha = lowalpha | upalpha
digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
"8" | "9"
alphanum = alpha | digit
CTL = <any US-ASCII control character
(octets 0 -- 31) and DEL (127)>
CR = %d13 ; US-ASCII CR, carriage return character
LF = %d10 ; US-ASCII LF, line feed character
SP = %d32 ; US-ASCII SP, space character
HT = %d09 ; US-ASCII HT, horizontal tab character
CRLF = CR LF ; typically the end of a line
The following are defined in RFC 2396 [12] for the SIP URI:
RFC 2396[12]中为SIP URI定义了以下内容：
unreserved = alphanum | mark
mark = "-" | "_" | "." | "!" | "~" | "*" | "'"
| "(" | ")"
escaped = "%" hex hex
unreserved = alphanum | mark
mark = "-" | "_" | "." | "!" | "~" | "*" | "'"
| "(" | ")"
escaped = "%" hex hex
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.
如果延续行以空格或水平制表符开头，则SIP标头字段值可以折叠到多行。所有线性空白（包括折叠）与SP具有相同的语义。在解释字段值或向下游转发消息之前，收件人可以用单个SP替换任何线性空白。
LWS = [CRLF] 1*( SP | HT ) ; linear whitespace
LWS = [CRLF] 1*( SP | HT ) ; linear whitespace
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 character set (RFC 2279 [21]). In this regard, SIP differs from HTTP, which uses the ISO 8859-1 character set.
TEXT-UTF8规则仅用于描述性字段内容和值，这些内容和值不打算由消息解析器解释。*TEXT-UTF8的单词包含UTF-8字符集（RFC 2279[21]）中的字符。在这方面，SIP不同于HTTP，后者使用ISO 8859-1字符集。
TEXT-UTF8 = <any UTF-8 character encoding, except CTLs,
but including LWS>
TEXT-UTF8 = <any UTF-8 character encoding, except CTLs,
but including LWS>
A CRLF is allowed in the definition of TEXT-UTF8 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 value.
在TEXT-UTF8的定义中，CRLF仅允许作为标题字段延续的一部分。预计在解释TEXT-UTF8值之前，折叠LWS将替换为单个SP。
Hexadecimal numeric characters are used in several protocol elements.
在几个协议元素中使用十六进制数字字符。
hex = "A" | "B" | "C" | "D" | "E" | "F"
| "a" | "b" | "c" | "d" | "e" | "f" | digit
hex = "A" | "B" | "C" | "D" | "E" | "F"
| "a" | "b" | "c" | "d" | "e" | "f" | digit
Many SIP header field values consist of words separated by LWS or special characters. These special characters MUST be in a quoted string to be used within a parameter value.
许多SIP头字段值由LWS或特殊字符分隔的单词组成。这些特殊字符必须位于带引号的字符串中，才能在参数值中使用。
token = 1*< any CHAR except CTL's or separators>
separators = "(" | ")" | "<" | ">" | "@" |
"," | ";" | ":" | "\" | <"> |
"/" | "[" | "]" | "?" | "=" |
"{" | "}" | SP | HT
token = 1*< any CHAR except CTL's or separators>
separators = "(" | ")" | "<" | ">" | "@" |
"," | ";" | ":" | "\" | <"> |
"/" | "[" | "]" | "?" | "=" |
"{" | "}" | SP | HT
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 = "(" *(ctext | quoted-pair | comment) ")"
ctext = < any TEXT-UTF8 excluding "(" and ")">
comment = "(" *(ctext | quoted-pair | comment) ")"
ctext = < any TEXT-UTF8 excluding "(" and ")">
A string of text is parsed as a single word if it is quoted using double-quote marks.
如果使用双引号将文本字符串引用，则将其解析为单个单词。
quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
qdtext = <any TEXT-UTF8 except <">>
quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
qdtext = <any TEXT-UTF8 except <">>
The backslash character ("\") MAY be used as a single-character quoting mechanism only within quoted-string and comment constructs.
反斜杠字符（\）只能在带引号的字符串和注释结构中用作单字符引用机制。
quoted-pair = " \ " CHAR
quoted pair=“\”字符
D Using SRV DNS Records
D使用SRV DNS记录
The following procedure is experimental and relies on DNS SRV records (RFC 2052 [14]). The steps listed below are used in place of the two steps in section 1.4.2.
以下程序是实验性的，依赖于DNS SRV记录（RFC 2052[14]）。以下列出的步骤用于代替第1.4.2节中的两个步骤。
If a step elicits no addresses, the client continues to the next step. However if a step elicits one or more addresses, but no SIP server at any of those addresses responds, then the client concludes the server is down and doesn't continue on to the next step.
如果一个步骤没有得到地址，客户端将继续下一步。但是，如果一个步骤引出一个或多个地址，但这些地址中的任何一个都没有SIP服务器响应，那么客户机就认为服务器已关闭，不会继续下一步。
When SRV records are to be used, the protocol to use when querying for the SRV record is "sip". SRV records contain port numbers for servers, in addition to IP addresses; the client always uses this port number when contacting the SIP server. Otherwise, the port number in the SIP URI is used, if present. If there is no port number in the URI, the default port, 5060, is used.
当要使用SRV记录时，查询SRV记录时使用的协议是“sip”。SRV记录包含服务器的端口号以及IP地址；客户端在联系SIP服务器时始终使用此端口号。否则，将使用SIPURI中的端口号（如果存在）。如果URI中没有端口号，则使用默认端口5060。
1. If the host portion of the Request-URI is an IP address, the client contacts the server at the given address. If the host portion of the Request-URI is not an IP address, the client proceeds to the next step.
1. 如果请求URI的主机部分是IP地址，则客户机将在给定地址与服务器联系。如果请求URI的主机部分不是IP地址，则客户机进入下一步。
2. The Request-URI is examined. If it contains an explicit port number, the next two steps are skipped.
2. 将检查请求URI。如果它包含显式端口号，则跳过接下来的两个步骤。
3. The Request-URI is examined. If it does not specify a protocol (TCP or UDP), the client queries the name server for SRV records for both UDP (if supported by the client) and TCP (if supported by the client) SIP servers. The format of these queries is defined in RFC 2052 [14]. The results of the query or queries are merged together and ordered based on priority. Then, the searching technique outlined in RFC 2052 [14] is used to select servers in order. If DNS doesn't return any records, the user goes to the last step. Otherwise, the user attempts to contact each server in the order listed. If no server is contacted, the user gives up.
3. 将检查请求URI。如果未指定协议（TCP或UDP），客户机将向名称服务器查询UDP（如果客户机支持）和TCP（如果客户机支持）SIP服务器的SRV记录。RFC 2052[14]中定义了这些查询的格式。一个或多个查询的结果合并在一起，并根据优先级排序。然后，使用RFC 2052[14]中概述的搜索技术按顺序选择服务器。如果DNS没有返回任何记录，用户将转到最后一步。否则，用户将尝试按列出的顺序联系每台服务器。如果没有联系到服务器，用户将放弃。
4. If the Request-URI specifies a protocol (TCP or UDP) that is supported by the client, the client queries the name server for SRV records for SIP servers of that protocol type only. If the client does not support the protocol specified in the Request-URI, it gives up. The searching technique outlined in RFC 2052 [14] is used to select servers from the DNS response in order. If DNS doesn't
4. 如果请求URI指定了客户端支持的协议（TCP或UDP），则客户端将向名称服务器查询该协议类型的SIP服务器的SRV记录。如果客户端不支持请求URI中指定的协议，它将放弃。RFC 2052[14]中概述的搜索技术用于按顺序从DNS响应中选择服务器。如果DNS没有
return any records, the user goes to the last step. Otherwise, the user attempts to contact each server in the order listed. If no server is contacted, the user gives up.
返回任何记录，用户进入最后一步。否则，用户将尝试按列出的顺序联系每台服务器。如果没有联系到服务器，用户将放弃。
5. The client queries the name server for address records for the host portion of the Request-URI. If there were no address records, the client stops, as it has been unable to locate a server. By address record, we mean A RR's, AAAA RR's, or their most modern equivalent.
5. 客户机向名称服务器查询请求URI的主机部分的地址记录。如果没有地址记录，客户端将停止，因为它无法找到服务器。我们所说的地址记录是指RR、AAAA RR或它们最现代的等价物。
A client MAY cache a successful DNS query result. A successful query is one which contained records in the answer, and a server was contacted at one of the addresses from the answer. When the client wishes to send a request to the same host, it starts the search as if it had just received this answer from the name server. The server uses the procedures specified in RFC1035 [15] regarding cache invalidation when the time-to-live of the DNS result expires. If the client does not find a SIP server among the addresses listed in the cached answer, it starts the search at the beginning of the sequence described above.
客户端可以缓存成功的DNS查询结果。成功的查询包含答案中的记录，并且通过答案中的一个地址与服务器联系。当客户机希望向同一主机发送请求时，它将启动搜索，就像它刚刚从名称服务器收到此答复一样。服务器使用RFC1035[15]中指定的有关DNS结果有效期到期时缓存失效的过程。如果客户端在缓存的应答中列出的地址中没有找到SIP服务器，它将在上述序列的开头开始搜索。
For example, consider a client that wishes to send a SIP request. The Request-URI for the destination is sip:user@company.com. The client only supports UDP. It would follow these steps:
例如，考虑一个希望发送SIP请求的客户端。目标的请求URI为sip:user@company.com. 客户端仅支持UDP。它将遵循以下步骤：
1. The host portion is not an IP address, so the client goes to step 2 above.
1. 主机部分不是IP地址，因此客户端转到上面的步骤2。
2. The client does a DNS query of QNAME="sip.udp.company.com", QCLASS=IN, QTYPE=SRV. Since it doesn't support TCP, it omits the TCP query. There were no addresses in the DNS response, so the client goes to the next step.
2. 客户端执行QNAME=“sip.udp.company.com”的DNS查询，QCLASS=IN，QTYPE=SRV。因为它不支持TCP，所以省略了TCP查询。DNS响应中没有地址，因此客户端进入下一步。
3. The client does a DNS query for A records for "company.com". An address is found, so that client attempts to contact a server at that address at port 5060.
3. 客户端对“company.com”的记录进行DNS查询。找到一个地址，以便客户端尝试联系端口5060处该地址的服务器。
E IANA Considerations
E.对IANA的考虑
Section 4.4 describes a name space and mechanism for registering SIP options.
第4.4节描述了用于注册SIP选项的名称空间和机制。
Section 6.41 describes the name space for registering SIP warn-codes.
第6.41节描述了注册SIP警告代码的名称空间。
F Acknowledgments
F致谢
We wish to thank the members of the IETF MMUSIC WG for their comments and suggestions. Detailed comments were provided by Anders Kristensen, Jim Buller, Dave Devanathan, Yaron Goland, Christian Huitema, Gadi Karmi, Jonathan Lennox, Keith Moore, Vern Paxson, Moshe J. Sambol, and Eric Tremblay.
我们要感谢IETF MMUSIC工作组成员的意见和建议。Anders Kristensen、Jim Buller、Dave Devanathan、Yaron Goland、Christian Huitema、Gadi Karmi、Jonathan Lennox、Keith Moore、Vern Paxson、Moshe J.Sambol和Eric Tremblay提供了详细的评论。
This work is based, inter alia, on [37,38].
除其他外，这项工作基于[37,38]。
G Authors' Addresses
G.作者地址
Mark Handley AT&T Center for Internet Research at ISCI (ACIRI) 1947 Center St., Suite 600 Berkeley, CA 94704-119 USA Email: mjh@aciri.org
美国加利福尼亚州伯克利1947中心街600号套房ISCI（ACIRI）互联网研究马克·汉德利AT&T中心，邮编：94704-119电子邮件：mjh@aciri.org
Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA Email: schulzrinne@cs.columbia.edu
美国纽约州纽约市阿姆斯特丹大道1214号哥伦比亚大学计算机科学系Henning Schulzrinne 10027电子邮件：schulzrinne@cs.columbia.edu
Eve Schooler Computer Science Department 256-80 California Institute of Technology Pasadena, CA 91125 USA Email: schooler@cs.caltech.edu
Eve Schooler计算机科学系256-80加利福尼亚理工学院帕萨迪纳，加利福尼亚91125美国电子邮件：schooler@cs.caltech.edu
Jonathan Rosenberg Lucent Technologies, Bell Laboratories Rm. 4C-526 101 Crawfords Corner Road Holmdel, NJ 07733 USA Email: jdrosen@bell-labs.com
Jonathan Rosenberg-Lucent Technologies，贝尔实验室Rm。美国新泽西州霍姆代尔克劳福德角路101号4C-526 07733电子邮件：jdrosen@bell-实验室网站
H Bibliography
H参考书目
[1] Pandya, R., "Emerging mobile and personal communication systems," IEEE Communications Magazine , vol. 33, pp. 44--52, June 1995.
[1] 潘迪亚，R.，“新兴移动和个人通信系统”，《IEEE通信杂志》，第33卷，第44-52页，1995年6月。
[2] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation protocol (RSVP) -- version 1 functional specification", RFC 2205, October 1997.
[2] Braden，B.，Zhang，L.，Berson，S.，Herzog，S.和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年10月。
[3] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: a transport protocol for real-time applications", RFC 1889, Internet Engineering Task Force, Jan. 1996.
[3] Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 1889，互联网工程任务组，1996年1月。
[4] Schulzrinne, H., Lanphier, R. and A. Rao, "Real time streaming protocol (RTSP)", RFC 2326, April 1998.
[4] Schulzrinne，H.，Lanphier，R.和A.Rao，“实时流协议（RTSP）”，RFC2326，1998年4月。
[5] Handley, M., "SAP: Session announcement protocol," Internet Draft, Internet Engineering Task Force, Nov. 1996. Work in progress.
[5] 汉德利，M.，“SAP：会话公告协议”，互联网草案，互联网工程任务组，1996年11月。正在进行的工作。
[6] Handley, M. and V. Jacobson, "SDP: session description protocol", RFC 2327, April 1998.
[6] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[7] International Telecommunication Union, "Visual telephone systems and equipment for local area networks which provide a non-guaranteed quality of service," Recommendation H.323, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, May 1996.
[7] 国际电信联盟，“提供非保证服务质量的局域网可视电话系统和设备”，建议H.323，国际电联电信标准化部门，瑞士日内瓦，1996年5月。
[8] International Telecommunication Union, "Control protocol for multimedia communication," Recommendation H.245, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998.
[8] 国际电信联盟，“多媒体通信控制协议”，建议H.245，国际电联电信标准化部门，瑞士日内瓦，1998年2月。
[9] International Telecommunication Union, "Media stream packetization and synchronization on non-guaranteed quality of service LANs," Recommendation H.225.0, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Nov. 1996.
[9] 国际电信联盟，“非保证服务质量局域网上的媒体流打包和同步”，建议H.225.0，国际电联电信标准化部门，瑞士日内瓦，1996年11月。
[10] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, Mardch 1997.
[10] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，Mardch 1997。
[11] Fielding, R., Gettys, J., Mogul, J., Nielsen, H. and T. Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1", RFC 2068, January 1997.
[11] 菲尔丁，R.，盖蒂斯，J.，莫格尔，J.，尼尔森，H.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2068，1997年1月。
[12] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform resource identifiers (URI): generic syntax", RFC 2396, August 1998.
[12] Berners Lee，T.，Fielding，R.和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[13] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform resource locators (URL)", RFC 1738, December 1994.
[13] Berners Lee，T.，Masinter，L.和M.McCahill，“统一资源定位器（URL）”，RFC 17381994年12月。
[14] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, October 1996.
[14] Gulbrandsen，A.和P.Vixie，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2052，1996年10月。
[15] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, Noveberm 1997.
[15] Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1997年11月。
[16] Hamilton, M. and R. Wright, "Use of DNS aliases for network services", RFC 2219, October 1997.
[16] Hamilton，M.和R.Wright，“网络服务中DNS别名的使用”，RFC2219，1997年10月。
[17] Zimmerman, D., "The finger user information protocol", RFC 1288, December 1991.
[17] Zimmerman，D.，“手指用户信息协议”，RFC 12881991年12月。
[18] Williamson, S., Kosters, M., Blacka, D., Singh, J. and K. Zeilstra, "Referral whois (rwhois) protocol V1.5", RFC 2167, June 1997.
[18] Williamson，S.，Kosters，M.，Blacka，D.，Singh，J.和K.Zeilstra，“转诊whois（rwhois）协议V1.5”，RFC 2167，1997年6月。
[19] Yeong, W., Howes, T. and S. Kille, "Lightweight directory access protocol", RFC 1777, March 1995.
[19] Yeong，W.，Howes，T.和S.Kille，“轻量级目录访问协议”，RFC 17771995年3月。
[20] Schooler, E., "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.
[20] Schooler，E.，“同步会合的多播用户目录服务”，硕士论文CS-TR-96-18，加利福尼亚理工学院计算机科学系，加利福尼亚州帕萨迪纳，1996年8月。
[21] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[21] “UTF-8，ISO 10646的转换格式”，RFC 2279，1998年1月。
[22] Stevens, W., TCP/IP illustrated: the protocols , vol. 1. Reading, Massachusetts: Addison-Wesley, 1994.
[22] Stevens，W.，TCP/IP图解：协议，第1卷。雷丁，马萨诸塞州：艾迪生·韦斯利，1994年。
[23] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[23] Mogul，J.和S.Deering，“MTU发现路径”，RFC191990年11月。
[24] Crocker, D., "Standard for the format of ARPA internet text messages", RFC STD 11, RFC 822, August 1982.
[24] Crocker，D.，“ARPA互联网文本信息格式标准”，RFC STD 11，RFC 822，1982年8月。
[25] Meyer, D., "Administratively scoped IP multicast", RFC 2365, July 1998.
[25] Meyer，D.，“管理范围的IP多播”，RFC 2365，1998年7月。
[26] Schulzrinne, H., "RTP profile for audio and video conferences with minimal control", RFC 1890, January 1996
[26] Schulzrinne，H.，“具有最小控制的音频和视频会议的RTP配置文件”，RFC 1890，1996年1月
[27] Eastlake, D., Crocker, S. and J. Schiller, "Randomness recommendations for security", RFC 1750, December 1994.
[27] Eastlake，D.，Crocker，S.和J.Schiller，“安全性的随机性建议”，RFC 1750，1994年12月。
[28] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL scheme", RFC 2368, July 1998.
[28] Hoffman，P.，Masinter，L.和J.Zawinski，“邮件URL方案”，RFC 2368，1998年7月。
[29] Braden, B., "Requirements for internet hosts - application and support", STD 3, RFC 1123, October 1989.
[29] Braden，B.“互联网主机的要求——应用和支持”，STD 3，RFC 1123，1989年10月。
[30] Palme, J., "Common internet message headers", RFC 2076, February 1997.
[30] Palme，J.，“通用互联网消息头”，RFC 2076，1997年2月。
[31] Alvestrand, H., "IETF policy on character sets and languages", RFC 2277, January 1998.
[31] Alvestrand，H.，“IETF字符集和语言政策”，RFC 22771998年1月。
[32] Elkins, M., "MIME security with pretty good privacy (PGP)", RFC 2015, October 1996.
[32] Elkins，M.，“具有良好隐私的MIME安全性（PGP）”，RFC 2015，1996年10月。
[33] Atkins, D., Stallings, W. and P. Zimmermann, "PGP message exchange formats", RFC 1991, August 1996.
[33] Atkins，D.，Stallings，W.和P.Zimmermann，“PGP消息交换格式”，RFC 1991，1996年8月。
[34] Atkinson, R., "Security architecture for the internet protocol", RFC 2401, November 1998.
[34] 阿特金森，R.，“互联网协议的安全架构”，RFC 2401，1998年11月。
[35] Allen, C. and T. Dierks, "The TLS protocol version 1.0," RFC 2246, January 1999.
[35] Allen，C.和T.Dierks，“TLS协议1.0版”，RFC 2246，1999年1月。
[36] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, "HTTP authentication: Basic and digest access authentication," Internet Draft, Internet Engineering Task Force, Sept. 1998. Work in progress.
[36] Franks，J.，Hallam Baker，P.，Hostetler，J.，Lawrence，S.，Leach，P.，Lootonen，A.和L.Stewart，“HTTP认证：基本和摘要访问认证”，互联网草案，互联网工程任务组，1998年9月。正在进行的工作。
[37] Schooler, E., "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.
[37] Schooler，E.，“案例研究：分组交换远程会议系统中的多媒体会议控制”，《互联网期刊：研究与经验》，第4卷，第99-120页，1993年6月。ISI重印系列ISI/RS-93-359。
[38] Schulzrinne, H., "Personal mobility for multimedia services in the Internet," in European Workshop on Interactive Distributed Multimedia Systems and Services (IDMS) , (Berlin, Germany), Mar. 1996.
[38] Schulzrinne，H.，“互联网中多媒体服务的个人移动”，交互式分布式多媒体系统和服务（IDMS）欧洲研讨会，（德国柏林），1996年3月。
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。