RFC5389
看文档时顺便记录的翻译（部分），仅仅作为参考，码字不易，如有转载，请注明出处，多谢！
5. Definitions
STUN Agent: A STUN agent is an entity that implements the STUN
protocol. The entity can be either a STUN client or a STUN
server.
STUN Agent: 实现了 STUN 协议的实体。这个实体不是一个 STUN 客户端 就是一个 STUN 服务器
6. STUN Message Structure
The message length MUST contain the size, in bytes, of the message
not including the 20-byte STUN header. Since all STUN attributes are
padded to a multiple of 4 bytes, the last 2 bits of this field are
always zero. This provides another way to distinguish STUN packets
from packets of other protocols
消息的长度必须包含一个大小，单位是 字节，不包含 20个字节的 STUN 头。因为所有的 STUN 属性按 4 字节填充，消息头的最后2个bit永远是 0（意思是 message type 字段最高位 2个 byte）。这个可以用来区分不同协议的数据包。
7.3. Receiving a STUN Message
This section specifies the processing of a STUN message. The processing specified here is for STUN messages as defined in this specification; additional rules for backwards compatibility are defined in Section 12. Those additional procedures are optional, and usages can elect to utilize them. First, a set of processing operations is applied that is independent of the class. This is followed by class-specific processing, described in the subsections that follow.
本章节描述了 STUN 消息的处理过程。这里的处理过程只是针对定义在本规范的 STUN 消息；向后兼容的附加规则定义在 Section 12.这些附加流程是可选的，可以选择性的使用他们。首先，应用一系列不依赖于类的处理操作。接下来是 指定类的 处理流程，在下面章节描述。
When a STUN agent receives a STUN message, it first checks that the message obeys the rules of Section 6. It checks that the first two bits are 0, that the magic cookie field has the correct value, that the message length is sensible, and that the method value is a supported method. It checks that the message class is allowed for the particular method. If the message class is "Success Response" or "Error Response", the agent checks that the transaction ID matches a transaction that is still in progress. If the FINGERPRINT extension is being used, the agent checks that the FINGERPRINT attribute is present and contains the correct value. If any errors are detected, the message is silently discarded. In the case when STUN is being multiplexed with another protocol, an error may indicate that this is not really a STUN message; in this case, the agent should try to parse the message as a different protocol.
当 agent 收到一个 STUN 消息，首先按照 Section 6 的格则检查消息。检查 最开始的 2个bit 是 0，magic cookie 是正确的值，STUN 消息的长度正确，方法值是一个支持的方法。检查 STUN 消息的 class 和 method 是正确的。如果 STUN 消息的 class is ”Success Response“ 或者 ”Error Response“，agent 检查 Transaction id 匹配的仍在进行的消息。如果用了 FINGERPRINT 扩展，agent 要检查 FINGERPRINT 属性值是否正确。如果发现有错误，这个 STUN 消息就会被抛弃。在 STUN 消息和其他协议多路复用的情况下，可能会有一个错误指出当前不是一个 STUN 消息；这种情况下，agent 应该尝试用其他协议去解析。
The STUN agent then does any checks that are required by a authentication mechanism that the usage has specified (see Section 10).
agent 应该可以通过一个指定的 认证机制 去做检测。see Section 10
Once the authentication checks are done, the STUN agent checks for
unknown attributes and known-but-unexpected attributes in the
message. Unknown comprehension-optional attributes MUST be ignored
by the agent. Known-but-unexpected attributes SHOULD be ignored by
the agent. Unknown comprehension-required attributes cause
processing that depends on the message class and is described below.
一旦认证检测完成，agent 开始检测消息中 不知道的属性 和 知道-但不是期望的属性。agent 应该忽略 不知道的 能理解的 可选属性。agent 应该忽略 知道-但不是期望的属性。不知道 能理解的-必要 属性的处理应该依据消息的 class 和 下面的描述。
At this point, further processing depends on the message class of the
request.
此时，以后的处理依赖请求消息的 class。
8. FINGERPRINT Mechanism
This section describes an optional mechanism for STUN that aids in distinguishing STUN messages from packets of other protocols when the two are multiplexed on the same transport address. This mechanism is optional, and a STUN usage must describe if and when it is used. The FINGERPRINT mechanism is not backwards compatible with RFC 3489, and cannot be used in environments where such compatibility is required.
这段描述了一个 STUN 的可选机制，这个机制可以处理：当相同的传输地址上多路复用的时候，可以区分 STUN 消息和其他协议包。这个机制是可选的，STUN 用法必须描述是否使用以及如何使用。FINGERPRINT 机制不向后兼容 RFC 3489，不能用在需要兼容的情况下。
In some usages, STUN messages are multiplexed on the same transport address as other protocols, such as the Real Time Transport Protocol (RTP). In order to apply the processing described in Section 7, STUN messages must first be separated from the application packets.
有一些使用方式，在相同传输地址 STUN 消息和其他协议多路复用，比如 Real Time Transport Protocol。为了可以处理 Section 7 中描述的内容，STUN 消息必须首先和其他应用数据包分离。
Section 6 describes three fixed fields in the STUN header that can be used for this purpose. However, in some cases, these three fixed fields may not be sufficient.
Section 6 中描述的 STUN 消息头中的 3个域就是用来达到这个目的的。无论如何，有一些情况下这个3个域也可能不够，不能达到区分的目的。
When the FINGERPRINT extension is used, an agent includes the FINGERPRINT attribute in messages it sends to another agent. Section 15.5 describes the placement and value of this attribute. When the agent receives what it believes is a STUN message, then, in addition to other basic checks, the agent also checks that the message contains a FINGERPRINT attribute and that the attribute contains the correct value. Section 7.3 describes when in the overall processing of a STUN message the FINGERPRINT check is performed. This additional check helps the agent detect messages of other protocols that might otherwise seem to be STUN messages.
当 FINGERPRINT 扩展被使用，agent 发送到另外一个 agent 的 STUN 消息中要包含 FINGERPRIN 属性。Section 15.5 描述了 FINGERPRINT 的位置和值。当 agent 接收到一个自己认为是 STUN 消息的时候，除了基本的检测，agent 还要检测消息中的 FINGERPRINT 属性值是否正确。Section 7.3 描述了 FINGERPRINT 检测执行的大概过程。这个附加的检测能帮助 agent 检测其他看起来像 STUN 消息的数据。
10.2. Long-Term Credential Mechanism
The long-term credential mechanism relies on a long-term credential, in the form of a username and password that are shared between client and server. The credential is considered long-term since it is assumed that it is provisioned for a user, and remains in effect until the user is no longer a subscriber of the system, or is changed. This is basically a traditional "log-in" username and password given to users.
long-term 凭证机制依赖 long-term 凭证，在客户端和服务器之间以用户名和密码的形式存在。凭证被认为一个 long-term 是因为我们假设这个是提供给用户的，它一致有效直到用户不在关注这个系统，或者改变了。这就是给到用户一个传统的 'log-in‘ 的用户名和密码。（估计是登录的意思）
Because these usernames and passwords are expected to be valid for
extended periods of time, replay prevention is provided in the form
of a digest challenge. In this mechanism, the client initially sends
a request, without offering any credentials or any integrity checks.
The server rejects this request, providing the user a realm (used to
guide the user or agent in selection of a username and password) and
a nonce. The nonce provides the replay protection. It is a cookie,
selected by the server, and encoded in such a way as to indicate a
duration of validity or client identity from which it is valid. The
client retries the request, this time including its username and the
realm, and echoing the nonce provided by the server. The client also
includes a message-integrity, which provides an HMAC over the entire
request, including the nonce. The server validates the nonce and
checks the message integrity. If they match, the request is
authenticated. If the nonce is no longer valid, it is considered
"stale", and the server rejects the request, providing a new nonce.
因为用户名和密码在一段时间内被期望是有效的，所以要用摘要挑战防止多次的（relay）重试攻击。按照这种机制，客户端开始发送一个请求，这个请求没有凭证没有完整性检测。服务器拒绝这个请求，然后回复中提供一个 realm（用来引导用户或者 agent 选择用户名和密码）和 nonce。nonce 提供了 relay 保护。这个是一个 cookie，由服务器选择的，以某种编码表示合法的有效期或者客户端身份。客户端尝试再次发送请求，这次请求里包含 username 和 ream，还有服务器提供的 nonce。客户端也包含一个 message-integerity，这个就是整个请求使用 HMAC 编码，还有 nonce。服务器验证 once 和 检测 message integrity。如果匹配成功，请求就认证通过。如果 nonce 不再合法，就被认为是 ‘stale’（过期），服务器拒绝请求，并且再提供一个新的 nonce。
In subsequent requests to the same server, the client reuses the
nonce, username, realm, and password it used previously. In this
way, subsequent requests are not rejected until the nonce becomes
invalid by the server, in which case the rejection provides a new
nonce to the client.
后续发给相同服务器的请求，客户端可以重用 它上一次用的 nonce，username，realm，和 password。按照这个方式，后续请求不会被服务器拒绝，除非 nonce 变成不合法的，这个情况下服务器会提供一个新的 nonce 给客户端。
Note that the long-term credential mechanism cannot be used to
protect indications, since indications cannot be challenged. Usages
utilizing indications must either use a short-term credential or omit
authentication and message integrity for them.
注意 long-term 凭证机制不能用在 indications，因为 indications 不能被挑战。indications 必须用 short-term 凭证 或者 omit 认证 和 message inttegrity。
Since the long-term credential mechanism is susceptible to offline
dictionary attacks, deployments SHOULD utilize passwords that are
difficult to guess. In cases where the credentials are not entered
by the user, but are rather placed on a client device during device
provisioning, the password SHOULD have at least 128 bits of
randomness. In cases where the credentials are entered by the user,
they should follow best current practices around password structure
因为 long-term 凭证机制容易受到 字典攻击 影响，部署人员应该给游客不同的密码。在 凭证 不是用户输入的情况下，而是在一个客户端设备上的时候，password 应该至少有 128 bits 的随机性，如果凭证是用户输入的，密码最好有一定的强度。
10.2.1. Forming a Request
There are two cases when forming a request. In the first case, this is the first request from the client to the server (as identified by its IP address and port). In the second case, the client is submitting a subsequent request once a previous request/response transaction has completed successfully. Forming a request as a consequence of a 401 or 438 error response is covered in Section 10.2.3 and is not considered a "subsequent request" and thus does not utilize the rules described in Section 10.2.1.2.
生成一个请求有两种情况，第一种，客户端发送第一个请求到客户端（用 ip 和 port 作为身份认证）。第二种，一旦上一次请求完成，客户端会提交后续的请求。一个请求产生 401 或者 438 响应这种情况在 secion 10.2.3 中，并且这种情况下后面的请求不是 ‘subsequent request’，因此不能使用 section 10.2.1.2 中的规则。
10.2.1.1. First Request
If the client has not completed a successful request/response transaction with the server (as identified by hostname, if the DNS procedures of Section 9 are used, else IP address if not), it SHOULD omit the USERNAME, MESSAGE-INTEGRITY, REALM, and NONCE attributes. In other words, the very first request is sent as if there were no authentication or message integrity applied.
如果客户端没有和服务器完成一个成功的 请求/响应 传输事务，客户端应该忽略 username， message-ingerity，realm，nonce 属性。换句话说，第一个请求就当成没有认证或者消息完整性要求发送。
10.2.1.2. Subsequent Requests
Once a request/response transaction has completed successfully, the client will have been presented a realm and nonce by the server, and selected a username and password with which it authenticated. The client SHOULD cache the username, password, realm, and nonce for subsequent communications with the server. When the client sends a subsequent request, it SHOULD include the USERNAME, REALM, and NONCE attributes with these cached values. It SHOULD include a MESSAGE- INTEGRITY attribute, computed as described in Section 15.4 using the cached password.
一旦一个 请求/响应 事务成功完成，客户端就有拿到服务器提供的 realm 和 nonce，并且选择 username 和 password 去认证。客户端因该保存 username，password，realm 和 nonce 以便后续的请求使用。当客户端发送一个后续请求，客户端应该包含 username，realm，nonce 属性。也应该包含一个 message-integrity 属性，根据 passord 按照 section 15.4 计算。
15. STUN Attributes
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (variable) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Format of STUN Attributes
The value in the length field MUST contain the length of the Value
part of the attribute, prior to padding, measured in bytes. Since
STUN aligns attributes on 32-bit boundaries, attributes whose content
is not a multiple of 4 bytes are padded with 1, 2, or 3 bytes of
padding so that its value contains a multiple of 4 bytes. The
padding bits are ignored, and may be any value.
属性长度域的值必须包含属性部分的长度，在填充之前，以字节为单位。因为 stun 属性要 32bit 对齐，如果属性内容长度不是 4 bytes 的倍数，就需要填充 1，2，3 字节的数据。填充的数据要被忽略，任何值都可以。
15.4. MESSAGE-INTEGRITY
The MESSAGE-INTEGRITY attribute contains an HMAC-SHA1 [RFC2104] of the STUN message. The MESSAGE-INTEGRITY attribute can be present in any STUN message type. Since it uses the SHA1 hash, the HMAC will be 20 bytes. The text used as input to HMAC is the STUN message, including the header, up to and including the attribute preceding the MESSAGE-INTEGRITY attribute. With the exception of the FINGERPRINT attribute, which appears after MESSAGE-INTEGRITY, agents MUST ignore all other attributes that follow MESSAGE-INTEGRITY.
MESSAGE-INTEGRITY 属性就是 STUN 消息的 HMAC-SHA1。MESSAGE-INTEGRITY 属性可以用在任何 STUN 消息中。因为它用 SHA1 的 hash，HMAC 应该是 20 bytes。STUN 消息作为 HMAC 的输入内容，包含 stun 头，并且头已经更新到包含 MESSAGE-INTEGRITY 属性长度，但是实际数据只包括 MESSAGE-INTEGRITY 属性之前的内容 。除了 FINGERPINT 属性，MESSAGE-INTEGRITY 之后的所有属性 agent 都要忽略。
（MESSAGE-INTEGRITY 计算方式：经过代码验证
用 MESSAGE-INTEGRITY 属性之前所有的数据去计算 hmac，也就是说，计算 hmac 的数据长度就是从 stun 消息开始 到 MESSAGE-INTEGRITY 属性之前的长度（length_for_hmac），但是 stun length 的值 需要加上 24 个字节，也就是 整个 MESSAGE-INTEGRITY 属性的长度（2 bytes attr + 2 bytes length + 20 bytes hmac），这样才能计算正确。
|++++++++++ stun type ++++++++|+++++++++++++++++stun length ++++++++++++| <-------------------
|+++++++++++++++++++++++++ magic +++++++++++++++++++++++++++++++++++ |
|++++++++++++++++ transacation id +++++++++++++++++++++++++++++++++++++ | 这个区域就是 length_for_hmac
|+++++++++++++++++++++++ attr +++++++++++++++++++++++++++++++++++++++|
|+++++++++++++++ ....................................................................................+++++++++++| <--------------------
|+++++++++++++++ attr MESSAGE-INTEGRITY +++++++++++++++++++++++++++++|
|+++++++++++++++ attr other ++++++++++++++ +++++++++++++++++++++++++++++|
|+++++++++++++++ ....................................................................................+++++++++++|
）
The key for the HMAC depends on whether long-term or short-term
credentials are in use. For long-term credentials, the key is 16
bytes:
key = MD5(username ":" realm ":" SASLprep(password))
That is, the 16-byte key is formed by taking the MD5 hash of the
result of concatenating the following five fields: (1) the username,
with any quotes and trailing nulls removed, as taken from the
USERNAME attribute (in which case SASLprep has already been applied);
(2) a single colon; (3) the realm, with any quotes and trailing nulls
removed; (4) a single colon; and (5) the password, with any trailing
nulls removed and after processing using SASLprep. For example, if
the username was 'user', the realm was 'realm', and the password was
'pass', then the 16-byte HMAC key would be the result of performing
an MD5 hash on the string 'user:realm:pass', the resulting hash being
0x8493fbc53ba582fb4c044c456bdc40eb.
HMAC 的 key 值要看凭证是 long-term 还是 short-term。如果是 long-term 凭证，key 就是 16个字节：
16个字节的 key 是由 5个部分组成的内容计算出来的 MD5 值。（1）username，不带任何引号并且不带字符串尾部的结束符，这个值可以从 USERNAME 属性拿到。（2）一个冒号；（3）realm，不带任何引号并且不带字符串尾部的结束符；（4）一个冒号；（5）password，不带尾部任何的结束符 并且 还需要用 SASLprep 处理（如果是英文，不用管这个 SASLprep）。比如：如果 username is ‘user’，realm 是 ‘realm’，password 是 ‘pass’，16个字节的 HMAC 用的 key 就是 字符串 ‘user:realm:pass’ 的 MD5 值，hash 结果就是 0x8493fbc53ba582fb4c044c456bdc40eb
For short-term credentials:
key = SASLprep(password)
where MD5 is defined in RFC 1321 [RFC1321] and SASLprep() is defined in RFC 4013 [RFC4013].
MD5 定义在 RFC 1321，SASLprep 定义在 RFC 4013
The structure of the key when used with long-term credentials
facilitates deployment in systems that also utilize SIP. Typically,
SIP systems utilizing SIP's digest authentication mechanism do not
actually store the password in the database. Rather, they store a
value called H(A1), which is equal to the key defined above.
当和 long-term 凭证 一起使用的密钥结构可以促 SIP 系统部署。通常 SIP 系统使用 SIP 的数字认证机制，但是实际不在数据库中存储密码。他们会存储一个叫做 H(A1) 的值，这个值就是上边定义的 KEY。（这个不重要，和 P2P 没啥关系）
Based on the rules above, the hash used to construct MESSAGE-
INTEGRITY includes the length field from the STUN message header.
Prior to performing the hash, the MESSAGE-INTEGRITY attribute MUST be
inserted into the message (with dummy content). The length MUST then
be set to point to the length of the message up to, and including,
the MESSAGE-INTEGRITY attribute itself, but excluding any attributes
after it. Once the computation is performed, the value of the
MESSAGE-INTEGRITY attribute can be filled in, and the value of the
length in the STUN header can be set to its correct value -- the
length of the entire message. Similarly, when validating the
MESSAGE-INTEGRITY, the length field should be adjusted to point to
the end of the MESSAGE-INTEGRITY attribute prior to calculating the
HMAC. Such adjustment is necessary when attributes, such as
FINGERPRINT, appear after MESSAGE-INTEGRITY.
基于上述原则，用来构造 MESSAGE-INTEGRITY 的 hash 计算时从 STUN 消息头开始并且要包括 长度域。计算 hash 之前，MESSAGE-INTEGRITY 属性必须插入到 STUN 消息中（属性可以是任意值，只是占个位置）。STUN 消息的 长度区域 必需要更新到包含 MESSAGE-INTEGRITY 属性的长度，MESSAGE-INTEGRITY 以后的属性长度不要包含进来。一旦计算执行，MESSAGE-INTEGRITY 属性的值就可以填入真实的值，STUN 消息头的长度可以更新到正确的值 - 整个 STUN 消息的长度。类似的，当校验 MESSAGE-INTEGRITY 时，在计算 hmac 之前，STUN 消息的长度域要修改成 到 MESSAGE-INTEGRITY 属性的末尾。比如当 FINGERPRINT 属性出现在 MESSAGE-INTEGRITY 之后，这些修改是必须的。
（这段就是说计算 hmac 的时候要注意 STUN 消息长度域的值，只能到 MESSAGE-INTEGRITY 属性之后，因为可能 MESSAGE-INTEGRITY 之后还有其他属性）
15.5. FINGERPRINT
The FINGERPRINT attribute MAY be present in all STUN messages. The value of the attribute is computed as the CRC-32 of the STUN message up to (but excluding) the FINGERPRINT attribute itself, XOR'ed with the 32-bit value 0x5354554e (the XOR helps in cases where an application packet is also using CRC-32 in it). The 32-bit CRC is the one defined in ITU V.42 [ITU.V42.2002], which has a generator polynomial of x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1. When present, the FINGERPRINT attribute MUST be the last attribute in the message, and thus will appear after MESSAGE-INTEGRITY.
FINGERPRINT 属性可以出现在所有的 STUN 消息里。这个属性的值是计算 STUN 消息的 CRC32，计算 CRC32 的 STUN 消息中的 长度域 要把 FINGERPRINT 属性长度包含进去。计算得到的 CRC 32 bit 值要和 0x5354554e 异或（异或可以帮忙我们区分应用本身也用了 CRC32）。32 bit CRC 定义在 ITU V.42，它有一个生成器 polynomial of x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1。当出现FINGERPRINT 的时候，这个属性必须是 STUN 消息里的最后一个属性，因此 FINGERPRINT 在 MESSAGE-INTEGRITY 属性的后面。
The FINGERPRINT attribute can aid in distinguishing STUN packets from packets of other protocols. See Section 8.
FINGERPRINT 属性可以帮助我们其他协议的 STUN 包
As with MESSAGE-INTEGRITY, the CRC used in the FINGERPRINT attribute
covers the length field from the STUN message header. Therefore,
this value must be correct and include the CRC attribute as part of
the message length, prior to computation of the CRC. When using the
FINGERPRINT attribute in a message, the attribute is first placed
into the message with a dummy value, then the CRC is computed, and
then the value of the attribute is updated. If the MESSAGE-INTEGRITY
attribute is also present, then it must be present with the correct
message-integrity value before the CRC is computed, since the CRC is
done over the value of the MESSAGE-INTEGRITY attribute as well.
当 STUN 消息中带有 MESSAGE-INTEGRITY，计算 CRC 时，STUN 消息中的 长度域 要包含 FINGERPRINT 属性的长度。因此，在计算 CRC 之前，MESSAGE-INTEGRITY 属性的值要正确，并且 STUN 消息中的 长度域 一定要包含 FINGERPRINT 属性长度，当一个 STUN 消息中使用 FINGERPRINT 属性的时候，FINGERPRINT 属性首先要填充一些假的数据，当 CRC 计算完成，再更新这个属性。再 CRC 计算完成之前，如果 STUN 消息中有 MESSAGE-INTEGRITY 属性，那么 MESSAGE-INTEGRITY 属性值一定要正确，因为 CRC 计算也包含 MESSAGE-INTEGRITY 属性。
（FINGERPRINT 计算和 MESSAGE-INTEGRITY 计算类似，FINGERPRINT 实际计算的数据长度就是从 STUN 消息开始 到 FINGERPRINT 属性之前，但是 STUN 消息中的 长度域 必须包含 FINGERPRINT 属性的长度）
15.6. ERROR-CODE
The ERROR-CODE attribute is used in error response messages. It contains a numeric error code value in the range of 300 to 699 plus a textual reason phrase encoded in UTF-8 [RFC3629], and is consistent in its code assignments and semantics with SIP [RFC3261] and HTTP [RFC2616]. The reason phrase is meant for user consumption, and can be anything appropriate for the error code. Recommended reason phrases for the defined error codes are included in the IANA registry for error codes. The reason phrase MUST be a UTF-8 [RFC3629] encoded sequence of less than 128 characters (which can be as long as 763 bytes).
ERROR-CODE 属性表示响应里的错误码。它包含一个数字的错误码，范围是 300-699，还有一个 UTF-8 编码的文字错误原因，并且它的代码分配和语义都和 SIP 和 HTTP一致。错误原因是方便给用户理解的，并且可以适应任何的错误码。推荐错误原因用 IANA 注册的错误码。错误原因必须是UTF-8编码的，并且要小于 128 个字符，最长可以是 763 个字节。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved, should be 0 |Class| Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason Phrase (variable) ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: ERROR-CODE Attribute
To facilitate processing, the class of the error code (the hundreds
digit) is encoded separately from the rest of the code, as shown in
Figure 7.
为了便于处理，错误码的 class （百位上的数字）和 错误码剩余的是分开的。
The Reserved bits SHOULD be 0, and are for alignment on 32-bit
boundaries. Receivers MUST ignore these bits. The Class represents
the hundreds digit of the error code. The value MUST be between 3
and 6. The Number represents the error code modulo 100, and its
value MUST be between 0 and 99.
Reserved bits 应该都是 0， 按 32位 边界对齐。接收者必须忽略这些位。class 表示错误百位上的数字。值必须是 3-6 之间，Number 表示错误码 mod 100 之后的值，它的值必须是 0-99.