Network Working Group R. Sparks, Ed.
Request for Comments: 4475 Estacado Systems
Category: Informational A. Hawrylyshen
Ditech Networks
A. Johnston
Avaya
J. Rosenberg
Cisco Systems
H. Schulzrinne
Columbia University
May 2006
Network Working Group R. Sparks, Ed.
Request for Comments: 4475 Estacado Systems
Category: Informational A. Hawrylyshen
Ditech Networks
A. Johnston
Avaya
J. Rosenberg
Cisco Systems
H. Schulzrinne
Columbia University
May 2006
Session Initiation Protocol (SIP) Torture Test Messages
会话启动协议（SIP）测试消息
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This informational document gives examples of Session Initiation Protocol (SIP) test messages designed to exercise and "torture" a SIP implementation.
本信息性文档给出了会话启动协议（SIP）测试消息的示例，这些消息旨在练习和“折磨”SIP实现。
Table of Contents
目录
1. Overview ........................................................3
2. Document Conventions ............................................3
2.1. Representing Long Lines ....................................4
2.2. Representing Non-printable Characters ......................4
2.3. Representing Long Repeating Strings ........................5
3. SIP Test Messages ...............................................5
3.1. Parser Tests (syntax) ......................................5
3.1.1. Valid Messages ......................................5
3.1.1.1. A Short Tortuous INVITE ....................5
3.1.1.2. Wide Range of Valid Characters .............8
3.1.1.3. Valid Use of the % Escaping Mechanism ......9
3.1.1.4. Escaped Nulls in URIs .....................11
3.1.1.5. Use of % When It Is Not an Escape .........11
3.1.1.6. Message with No LWS between
Display Name and < ........................12
1. Overview ........................................................3
2. Document Conventions ............................................3
2.1. Representing Long Lines ....................................4
2.2. Representing Non-printable Characters ......................4
2.3. Representing Long Repeating Strings ........................5
3. SIP Test Messages ...............................................5
3.1. Parser Tests (syntax) ......................................5
3.1.1. Valid Messages ......................................5
3.1.1.1. A Short Tortuous INVITE ....................5
3.1.1.2. Wide Range of Valid Characters .............8
3.1.1.3. Valid Use of the % Escaping Mechanism ......9
3.1.1.4. Escaped Nulls in URIs .....................11
3.1.1.5. Use of % When It Is Not an Escape .........11
3.1.1.6. Message with No LWS between
Display Name and < ........................12
3.1.1.7. Long Values in Header Fields ..............12
3.1.1.8. Extra Trailing Octets in a UDP Datagram ...14
3.1.1.9. Semicolon-Separated Parameters in
URI User Part .............................16
3.1.1.10. Varied and Unknown Transport Types .......16
3.1.1.11. Multipart MIME Message ...................17
3.1.1.12. Unusual Reason Phrase ....................18
3.1.1.13. Empty Reason Phrase ......................19
3.1.2. Invalid Messages ...................................20
3.1.2.1. Extraneous Header Field Separators ........20
3.1.2.2. Content Length Larger Than Message ........20
3.1.2.3. Negative Content-Length ...................21
3.1.2.4. Request Scalar Fields with
Overlarge Values ..........................22
3.1.2.5. Response Scalar Fields with
Overlarge Values ..........................23
3.1.2.6. Unterminated Quoted String in
Display Name ..............................24
3.1.2.7. <> Enclosing Request-URI ..................25
3.1.2.8. Malformed SIP Request-URI (embedded LWS) ..26
3.1.2.9. Multiple SP Separating
Request-Line Elements .....................27
3.1.2.10. SP Characters at End of Request-Line .....28
3.1.2.11. Escaped Headers in SIP Request-URI .......29
3.1.2.12. Invalid Timezone in Date Header Field ....30
3.1.2.13. Failure to Enclose name-addr URI in <> ...31
3.1.2.14. Spaces within addr-spec ..................31
3.1.2.15. Non-token Characters in Display Name .....32
3.1.2.16. Unknown Protocol Version .................32
3.1.2.17. Start Line and CSeq Method Mismatch ......33
3.1.2.18. Unknown Method with CSeq Method Mismatch .33
3.1.2.19. Overlarge Response Code ..................34
3.2. Transaction Layer Semantics ...............................34
3.2.1. Missing Transaction Identifier .....................34
3.3. Application-Layer Semantics ...............................35
3.3.1. Missing Required Header Fields .....................35
3.3.2. Request-URI with Unknown Scheme ....................36
3.3.3. Request-URI with Known but Atypical Scheme .........36
3.3.4. Unknown URI Schemes in Header Fields ...............37
3.3.5. Proxy-Require and Require ..........................37
3.3.6. Unknown Content-Type ...............................38
3.3.7. Unknown Authorization Scheme .......................38
3.3.8. Multiple Values in Single Value Required Fields ....39
3.3.9. Multiple Content-Length Values .....................40
3.3.10. 200 OK Response with Broadcast Via Header
Field Value .......................................40
3.3.11. Max-Forwards of Zero ..............................41
3.3.12. REGISTER with a Contact Header Parameter ..........42
3.1.1.7. Long Values in Header Fields ..............12
3.1.1.8. Extra Trailing Octets in a UDP Datagram ...14
3.1.1.9. Semicolon-Separated Parameters in
URI User Part .............................16
3.1.1.10. Varied and Unknown Transport Types .......16
3.1.1.11. Multipart MIME Message ...................17
3.1.1.12. Unusual Reason Phrase ....................18
3.1.1.13. Empty Reason Phrase ......................19
3.1.2. Invalid Messages ...................................20
3.1.2.1. Extraneous Header Field Separators ........20
3.1.2.2. Content Length Larger Than Message ........20
3.1.2.3. Negative Content-Length ...................21
3.1.2.4. Request Scalar Fields with
Overlarge Values ..........................22
3.1.2.5. Response Scalar Fields with
Overlarge Values ..........................23
3.1.2.6. Unterminated Quoted String in
Display Name ..............................24
3.1.2.7. <> Enclosing Request-URI ..................25
3.1.2.8. Malformed SIP Request-URI (embedded LWS) ..26
3.1.2.9. Multiple SP Separating
Request-Line Elements .....................27
3.1.2.10. SP Characters at End of Request-Line .....28
3.1.2.11. Escaped Headers in SIP Request-URI .......29
3.1.2.12. Invalid Timezone in Date Header Field ....30
3.1.2.13. Failure to Enclose name-addr URI in <> ...31
3.1.2.14. Spaces within addr-spec ..................31
3.1.2.15. Non-token Characters in Display Name .....32
3.1.2.16. Unknown Protocol Version .................32
3.1.2.17. Start Line and CSeq Method Mismatch ......33
3.1.2.18. Unknown Method with CSeq Method Mismatch .33
3.1.2.19. Overlarge Response Code ..................34
3.2. Transaction Layer Semantics ...............................34
3.2.1. Missing Transaction Identifier .....................34
3.3. Application-Layer Semantics ...............................35
3.3.1. Missing Required Header Fields .....................35
3.3.2. Request-URI with Unknown Scheme ....................36
3.3.3. Request-URI with Known but Atypical Scheme .........36
3.3.4. Unknown URI Schemes in Header Fields ...............37
3.3.5. Proxy-Require and Require ..........................37
3.3.6. Unknown Content-Type ...............................38
3.3.7. Unknown Authorization Scheme .......................38
3.3.8. Multiple Values in Single Value Required Fields ....39
3.3.9. Multiple Content-Length Values .....................40
3.3.10. 200 OK Response with Broadcast Via Header
Field Value .......................................40
3.3.11. Max-Forwards of Zero ..............................41
3.3.12. REGISTER with a Contact Header Parameter ..........42
3.3.13. REGISTER with a url-parameter .....................42
3.3.14. REGISTER with a URL Escaped Header ................43
3.3.15. Unacceptable Accept Offering ......................44
3.4. Backward Compatibility ....................................44
3.4.1. INVITE with RFC 2543 Syntax ........................44
4. Security Considerations ........................................45
5. Acknowledgements ...............................................46
6. Informative References .........................................46
Appendix A. Bit-Exact Archive of Each Test Message ................47
A.1. Encoded Reference Messages ................................48
3.3.13. REGISTER with a url-parameter .....................42
3.3.14. REGISTER with a URL Escaped Header ................43
3.3.15. Unacceptable Accept Offering ......................44
3.4. Backward Compatibility ....................................44
3.4.1. INVITE with RFC 2543 Syntax ........................44
4. Security Considerations ........................................45
5. Acknowledgements ...............................................46
6. Informative References .........................................46
Appendix A. Bit-Exact Archive of Each Test Message ................47
A.1. Encoded Reference Messages ................................48
This document is informational and is NOT NORMATIVE on any aspect of SIP.
本文件仅供参考，在SIP的任何方面均不规范。
This document contains test messages based on the current version (2.0) of the Session Initiation Protocol as, defined in [RFC3261]. Some messages exercise SIP's use of the Session Description Protocol (SDP), as described in [RFC3264].
本文档包含基于[RFC3261]中定义的会话启动协议当前版本（2.0）的测试消息。一些消息练习SIP对会话描述协议（SDP）的使用，如[RFC3264]中所述。
These messages were developed and refined at the SIPIt interoperability test events.
这些信息是在SIPIt互操作性测试活动中开发和完善的。
The test messages are organized into several sections. Some stress only a SIP parser, and others stress both the parser and the application above it. Some messages are valid, and some are not. Each example clearly calls out what makes any invalid messages incorrect.
测试消息被组织成几个部分。有些只强调SIP解析器，而另一些则强调解析器及其上面的应用程序。有些消息有效，有些则无效。每个示例都清楚地指出了是什么导致任何无效消息不正确。
This document does not attempt to catalog every way to make an invalid message, nor does it attempt to be comprehensive in exploring unusual, but valid, messages. Instead, it tries to focus on areas that have caused interoperability problems or that have particularly unfavorable characteristics if they are handled improperly. This document is a seed for a test plan, not a test plan in itself.
本文档不会尝试对生成无效消息的所有方法进行分类，也不会尝试全面地探索不寻常但有效的消息。相反，它试图将重点放在导致互操作性问题的领域，或者在处理不当时具有特别不利特征的领域。本文档是测试计划的种子，而不是测试计划本身。
The messages are presented in the text using a set of markup conventions to avoid ambiguity and meet Internet-Draft layout requirements. To resolve any remaining ambiguity, a bit-accurate version of each message is encapsulated in an appendix.
这些消息在文本中使用一组标记约定来表示，以避免歧义并满足Internet草稿布局要求。为了解决任何剩余的歧义，每个消息的精确版本都封装在附录中。
This document contains many example SIP messages. Although SIP is a text-based protocol, many of these examples cannot be unambiguously rendered without additional markup due to the constraints placed on the formatting of RFCs. This document defines and uses the markup
本文档包含许多示例SIP消息。尽管SIP是一种基于文本的协议，但由于RFC格式上的限制，在没有附加标记的情况下，这些示例中的许多无法明确呈现。本文档定义并使用标记
defined in this section to remove that ambiguity. This markup uses the start and end tag conventions of XML but does not define any XML document type.
在本节中定义，以消除这种歧义。此标记使用XML的开始和结束标记约定，但不定义任何XML文档类型。
The appendix contains an encoded binary form of all the messages and the algorithm needed to decode them into files.
附录包含所有消息的编码二进制形式以及将其解码为文件所需的算法。
Several of these examples contain unfolded lines longer than 72 characters. These are captured between <allOneLine/> tags. The single unfolded line is reconstructed by directly concatenating all lines appearing between the tags (discarding any line feeds or carriage returns). There will be no whitespace at the end of lines. Any whitespace appearing at a fold-point will appear at the beginning of a line.
其中一些示例包含长度超过72个字符的展开行。这些在<allOneLine/>标记之间捕获。通过直接连接标签之间出现的所有行（丢弃任何换行或回车），可以重建单个展开行。行尾将没有空格。任何出现在折叠点的空白都将出现在一行的开头。
The following represent the same string of bits:
以下表示相同的位串：
Header-name: first value, reallylongsecondvalue, third value
标题名称：第一个值、reallylongsecondvalue、第三个值
<allOneLine> Header-name: first value, reallylongsecondvalue , third value </allOneLine>
<allOneLine>标题名称：第一个值、reallylongsecondvalue、第三个值
<allOneLine> Header-name: first value, reallylong second value, third value </allOneLine>
<allOneLine>标题名称：第一个值、reallylong第二个值、第三个值
Note that this is NOT SIP header-line folding, where different strings of bits have equivalent meaning.
请注意，这不是SIP头行折叠，不同的位串具有相同的含义。
Several examples contain binary message bodies or header field values containing non-ascii range UTF-8 encoded characters. These are rendered here as a pair of hexadecimal digits per octet between <hex/> tags. This rendering applies even inside quoted-strings.
一些示例包含二进制消息正文或包含非ascii范围UTF-8编码字符的标题字段值。这些在这里表示为<hex/>标记之间每八位字节的一对十六进制数字。此呈现甚至应用于带引号的字符串内部。
The following represent the same string of bits:
以下表示相同的位串：
Header-name: value one
Header-name: value<hex>206F6E</hex>e
Header-name: value one
Header-name: value<hex>206F6E</hex>e
The following is a Subject header field containing the euro symbol:
以下是包含欧元符号的主题标题字段：
Subject: <hex>E282AC</hex>
Subject: <hex>E282AC</hex>
Several examples contain very large data values created with repeating bit strings. Those will be rendered here using <repeat count=some_integer>value</repeat>. As with <hex>, this rendering applies even inside quoted strings.
几个示例包含使用重复位字符串创建的非常大的数据值。这些将在这里使用<repeat count=some\u integer>值进行渲染。与<hex>一样，此呈现即使在带引号的字符串中也适用。
For example, the value "abcabcabc" can be rendered as <repeat
count=3>abc</repeat>. A display name of "1000000 bottles of beer"
could be rendered as
For example, the value "abcabcabc" can be rendered as <repeat
count=3>abc</repeat>. A display name of "1000000 bottles of beer"
could be rendered as
To: "1<repeat count=6><hex>30</hex></repeat> bottles of beer"
<sip:beer.example.com>
To: "1<repeat count=6><hex>30</hex></repeat> bottles of beer"
<sip:beer.example.com>
A Max-Forwards header field with a value of one google will be rendered here as
值为1 google的Max Forwards标头字段将在此处呈现为
Max-Forwards: 1<repeat count=100>0</repeat>
Max-Forwards: 1<repeat count=100>0</repeat>
This short, relatively human-readable message contains:
这条简短、相对易懂的信息包含：
o line folding all over.
o 折线。
o escaped characters within quotes.
o 引号内的转义字符。
o an empty subject.
o 空洞的话题。
o LWS between colons, semicolons, header field values, and other fields.
o 冒号、分号、标题字段值和其他字段之间的LWS。
o both comma separated and separately listed header field values.
o 逗号分隔和单独列出的标题字段值。
o a mix of short and long form for the same header field name.
o 同一标题字段名的短格式和长格式的混合。
o unknown Request-URI parameter.
o 未知的请求URI参数。
o unknown header fields.
o 未知的标题字段。
o an unknown header field with a value that would be syntactically invalid if it were defined in terms of generic-param.
o 未知标头字段，其值在语法上无效，如果它是根据泛型参数定义的。
o unusual header field ordering.
o 不寻常的标题字段排序。
o unusual header field name character case.
o 不寻常的标题字段名称字符大小写。
o unknown parameters of a known header field.
o 已知标头字段的未知参数。
o a uri parameter with no value.
o 没有uri参数的值。
o a header parameter with no value.
o 没有值的标头参数。
o integer fields (Max-Forwards and CSeq) with leading zeros.
o 带前导零的整数字段（最大转发和CSeq）。
All elements should treat this as a well-formed request.
所有元素都应将此视为格式良好的请求。
The UnknownHeaderWithUnusualValue header field deserves special attention. If this header field were defined in terms of comma-separated values with semicolon-separated parameters (as would many of the existing defined header fields), this would be invalid. However, since the receiving element does not know the definition of the syntax for this field, it must parse it as a header value. Proxies would forward this header field unchanged. Endpoints would ignore the header field.
UnknownHeaderWithunsualValue标头字段值得特别注意。如果此标题字段是根据逗号分隔的值和分号分隔的参数定义的（与许多现有定义的标题字段一样），则此字段将无效。但是，由于接收元素不知道该字段的语法定义，因此必须将其作为头值进行解析。代理将不加更改地转发此标头字段。端点将忽略标头字段。
Message Details : wsinv
消息详细信息：wsinv
INVITE sip:vivekg@chair-dnrc.example.com;unknownparam SIP/2.0
TO :
sip:vivekg@chair-dnrc.example.com ; tag = 1918181833n
from : "J Rosenberg \\\"" <sip:jdrosen@example.com>
;
tag = 98asjd8
MaX-fOrWaRdS: 0068
Call-ID: wsinv.ndaksdj@192.0.2.1
Content-Length : 150
cseq: 0009
INVITE
Via : SIP / 2.0
/UDP
192.0.2.2;branch=390skdjuw
s :
NewFangledHeader: newfangled value
continued newfangled value
UnknownHeaderWithUnusualValue: ;;,,;;,;
Content-Type: application/sdp
Route:
<sip:services.example.com;lr;unknownwith=value;unknown-no-value>
v: SIP / 2.0 / TCP spindle.example.com ;
branch = z9hG4bK9ikj8 ,
SIP / 2.0 / UDP 192.168.255.111 ; branch=
z9hG4bK30239
m:"Quoted string \"\"" <sip:jdrosen@example.com> ; newparam =
newvalue ;
secondparam ; q = 0.33
INVITE sip:vivekg@chair-dnrc.example.com;unknownparam SIP/2.0
TO :
sip:vivekg@chair-dnrc.example.com ; tag = 1918181833n
from : "J Rosenberg \\\"" <sip:jdrosen@example.com>
;
tag = 98asjd8
MaX-fOrWaRdS: 0068
Call-ID: wsinv.ndaksdj@192.0.2.1
Content-Length : 150
cseq: 0009
INVITE
Via : SIP / 2.0
/UDP
192.0.2.2;branch=390skdjuw
s :
NewFangledHeader: newfangled value
continued newfangled value
UnknownHeaderWithUnusualValue: ;;,,;;,;
Content-Type: application/sdp
Route:
<sip:services.example.com;lr;unknownwith=value;unknown-no-value>
v: SIP / 2.0 / TCP spindle.example.com ;
branch = z9hG4bK9ikj8 ,
SIP / 2.0 / UDP 192.168.255.111 ; branch=
z9hG4bK30239
m:"Quoted string \"\"" <sip:jdrosen@example.com> ; newparam =
newvalue ;
secondparam ; q = 0.33
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.3
s=-
c=IN IP4 192.0.2.4
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.3
s=-
c=IN IP4 192.0.2.4
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
This message exercises a wider range of characters in several key syntactic elements than implementations usually see. In particular, note the following:
这个消息在几个关键的语法元素中使用了比实现通常看到的更广泛的字符范围。特别要注意以下几点：
o The Method contains non-alpha characters from token. Note that % is not an escape character for this field. A method of IN%56ITE is an unknown method. It is not the same as a method of INVITE.
o 该方法包含来自令牌的非alpha字符。请注意，%不是此字段的转义字符。%56ITE中的方法是未知方法。它与INVITE的方法不同。
o The Request-URI contains unusual, but legal, characters.
o 请求URI包含异常但合法的字符。
o A branch parameter contains all non-alphanum characters from token.
o 分支参数包含令牌中的所有非字母数字字符。
o The To header field value's quoted string contains quoted-pair expansions, including a quoted NULL character.
o To标头字段值的带引号的字符串包含带引号的对扩展，包括带引号的空字符。
o The name part of name-addr in the From header field value contains multiple tokens (instead of a quoted string) with all non-alphanum characters from the token production rule. That value also has an unknown header parameter whose name contains the non-alphanum token characters and whose value is a non-ascii range UTF-8 encoded string. The tag parameter on this value contains the non-alphanum token characters.
o From header字段值中name addr的name部分包含多个令牌（而不是带引号的字符串），其中包含令牌生成规则中的所有非字母数字字符。该值还有一个未知的头参数，其名称包含非alphanum标记字符，其值为非ascii范围的UTF-8编码字符串。此值上的标记参数包含非alphanum标记字符。
o The Call-ID header field value contains the non-alphanum characters from word. Notice that in this production:
o Call ID header字段值包含word中的非字母数字字符。请注意，在本制作中：
* % is not an escape character. It is only an escape character in productions matching the rule "escaped".
* %不是转义字符。它只是与规则“转义”匹配的产品中的转义字符。
* " does not start a quoted string. None of ',` or " imply that there will be a matching symbol later in the string.
* “不以带引号的字符串开头，”、`或“中的任何一个都不表示字符串中稍后将有匹配的符号。”。
* The characters []{}()<> do not have any grouping semantics. They are not required to appear in balanced pairs.
* 字符[]{}（）<>没有任何分组语义。它们不需要成对出现。
o There is an unknown header field (matching extension-header) with non-alphanum token characters in its name and a UTF8-NONASCII value.
o 有一个名称中包含非alphanum标记字符和UTF8-NONASCII值的未知标题字段（匹配扩展标题）。
If this unusual URI has been defined at a proxy, the proxy will forward this request normally. Otherwise, a proxy will generate a 404. Endpoints will generate a 501 listing the methods they understand in an Allow header field.
如果已在代理上定义了此异常URI，则代理将正常转发此请求。否则，代理将生成404。端点将在Allow header字段中生成一个501列表，列出他们理解的方法。
Message Details : intmeth
消息详细信息：intmeth
<allOneLine>
!interesting-Method0123456789_*+`.%indeed'~
sip:1_unusual.URI~(to-be!sure)&isn't+it$/crazy?,/;;*
:&it+has=1,weird!*pas$wo~d_too.(doesn't-it)
@example.com SIP/2.0
</allOneLine>
Via: SIP/2.0/TCP host1.example.com;branch=z9hG4bK-.!%66*_+`'~
<allOneLine>
To: "BEL:\<hex>07</hex> NUL:\<hex>00</hex> DEL:\<hex>7F</hex>"
<sip:1_unusual.URI~(to-be!sure)&isn't+it$/crazy?,/;;*
@example.com>
</allOneLine>
<allOneLine>
From: token1~` token2'+_ token3*%!.- <sip:mundane@example.com>
;fromParam''~+*_!.-%=
"<hex>D180D0B0D0B1D0BED182D0B0D18ED189D0B8D0B9</hex>"
;tag=_token~1'+`*%!-.
</allOneLine>
Call-ID: intmeth.word%ZK-!.*_+'@word`~)(><:\/"][?}{
CSeq: 139122385 !interesting-Method0123456789_*+`.%indeed'~
Max-Forwards: 255
<allOneLine>
extensionHeader-!.%*+_`'~:
<hex>EFBBBFE5A4A7E5819CE99BBB</hex>
</allOneLine>
Content-Length: 0
<allOneLine>
!interesting-Method0123456789_*+`.%indeed'~
sip:1_unusual.URI~(to-be!sure)&isn't+it$/crazy?,/;;*
:&it+has=1,weird!*pas$wo~d_too.(doesn't-it)
@example.com SIP/2.0
</allOneLine>
Via: SIP/2.0/TCP host1.example.com;branch=z9hG4bK-.!%66*_+`'~
<allOneLine>
To: "BEL:\<hex>07</hex> NUL:\<hex>00</hex> DEL:\<hex>7F</hex>"
<sip:1_unusual.URI~(to-be!sure)&isn't+it$/crazy?,/;;*
@example.com>
</allOneLine>
<allOneLine>
From: token1~` token2'+_ token3*%!.- <sip:mundane@example.com>
;fromParam''~+*_!.-%=
"<hex>D180D0B0D0B1D0BED182D0B0D18ED189D0B8D0B9</hex>"
;tag=_token~1'+`*%!-.
</allOneLine>
Call-ID: intmeth.word%ZK-!.*_+'@word`~)(><:\/"][?}{
CSeq: 139122385 !interesting-Method0123456789_*+`.%indeed'~
Max-Forwards: 255
<allOneLine>
extensionHeader-!.%*+_`'~:
<hex>EFBBBFE5A4A7E5819CE99BBB</hex>
</allOneLine>
Content-Length: 0
This INVITE exercises the % HEX HEX escaping mechanism in several places. The request is syntactically valid. Interesting features include the following:
此INVITE在多个位置练习%HEX转义机制。请求在语法上是有效的。有趣的功能包括：
o The request-URI has sips:user@example.com embedded in its userpart. What that might mean to example.net is beyond the scope of this document.
o 请求URI具有SIP：user@example.com嵌入到它的用户部分。这对example.net可能意味着什么超出了本文档的范围。
o The From and To URIs have escaped characters in their userparts.
o From和To URI在其用户部分中有转义字符。
o The Contact URI has escaped characters in the URI parameters. Note that the "name" uri-parameter has a value of "value%41", which is NOT equivalent to "valueA". Per [RFC3986], unescaping URI components is never performed recursively.
o 联系人URI在URI参数中包含转义字符。请注意，“name”uri参数的值为“value%41”，这与“valueA”不同。根据[RFC3986]，永远不会递归地执行取消URI组件。
A parser must accept this as a well-formed message. The application using the message must treat the % HEX HEX expansions as equivalent to the character being encoded. The application must not try to interpret % as an escape character in those places where % HEX HEX ("escaped" in the grammar) is not a valid part of the construction. In [RFC3261], "escaped" only occurs in the expansions of SIP-URI, SIPS-URI, and Reason-Phrase.
解析器必须将其作为格式良好的消息接受。使用消息的应用程序必须将%HEX扩展视为与正在编码的字符等效。在%HEX HEX（“语法中的转义”）不是构造的有效部分的地方，应用程序不得尝试将%解释为转义字符。在[RFC3261]中，“转义”仅出现在SIP-URI、SIPS-URI和原因短语的扩展中。
Message Details : esc01
信息详情：esc01
INVITE sip:sips%3Auser%40example.com@example.net SIP/2.0
To: sip:%75se%72@example.com
From: <sip:I%20have%20spaces@example.net>;tag=938
Max-Forwards: 87
i: esc01.239409asdfakjkn23onasd0-3234
CSeq: 234234 INVITE
Via: SIP/2.0/UDP host5.example.net;branch=z9hG4bKkdjuw
C: application/sdp
Contact:
<sip:cal%6Cer@host5.example.net;%6C%72;n%61me=v%61lue%25%34%31>
Content-Length: 150
INVITE sip:sips%3Auser%40example.com@example.net SIP/2.0
To: sip:%75se%72@example.com
From: <sip:I%20have%20spaces@example.net>;tag=938
Max-Forwards: 87
i: esc01.239409asdfakjkn23onasd0-3234
CSeq: 234234 INVITE
Via: SIP/2.0/UDP host5.example.net;branch=z9hG4bKkdjuw
C: application/sdp
Contact:
<sip:cal%6Cer@host5.example.net;%6C%72;n%61me=v%61lue%25%34%31>
Content-Length: 150
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
This register request contains several URIs with nulls in the userpart. The message is well formed - parsers must accept this message. Implementations must take special care when unescaping the Address-of-Record (AOR) in this request so as to not prematurely shorten the username. This request registers two distinct contact URIs.
此注册请求包含多个URI，userpart中的URI为空。消息格式正确-解析器必须接受此消息。在取消此请求中的记录地址（AOR）时，实现必须特别小心，以免过早缩短用户名。此请求注册两个不同的联系人URI。
Message Details : escnull
消息详细信息：escnull
REGISTER sip:example.com SIP/2.0
To: sip:null-%00-null@example.com
From: sip:null-%00-null@example.com;tag=839923423
Max-Forwards: 70
Call-ID: escnull.39203ndfvkjdasfkq3w4otrq0adsfdfnavd
CSeq: 14398234 REGISTER
Via: SIP/2.0/UDP host5.example.com;branch=z9hG4bKkdjuw
Contact: <sip:%00@host5.example.com>
Contact: <sip:%00%00@host5.example.com>
L:0
REGISTER sip:example.com SIP/2.0
To: sip:null-%00-null@example.com
From: sip:null-%00-null@example.com;tag=839923423
Max-Forwards: 70
Call-ID: escnull.39203ndfvkjdasfkq3w4otrq0adsfdfnavd
CSeq: 14398234 REGISTER
Via: SIP/2.0/UDP host5.example.com;branch=z9hG4bKkdjuw
Contact: <sip:%00@host5.example.com>
Contact: <sip:%00%00@host5.example.com>
L:0
In most of the places % can appear in a SIP message, it is not an escape character. This can surprise the unwary implementor. The following well-formed request has these properties:
在SIP消息中出现%的大多数位置，它不是转义字符。这可能会让粗心的实现者感到惊讶。以下格式良好的请求具有以下属性：
o The request method is unknown. It is NOT equivalent to REGISTER.
o 请求方法未知。它不等同于注册。
o The display name portion of the To and From header fields is "%Z%45". Note that this is not the same as %ZE.
o “收件人”和“发件人”标题字段的显示名称部分为“%Z%45”。请注意，这与%ZE不同。
o This message has two Contact header field values, not three. <sip:alias2@host2.example.com> is a C%6Fntact header field value.
o 此消息有两个联系人标头字段值，而不是三个<抿：alias2@host2.example.com>是一个C%6Fntact标头字段值。
A parser should accept this message as well formed. A proxy would forward or reject the message depending on what the Request-URI meant to it. An endpoint would reject this message with a 501.
解析器应该接受格式良好的消息。代理将转发或拒绝消息，具体取决于请求URI对其意味着什么。端点将以501拒绝此消息。
Message Details : esc02
信息详情：esc02
RE%47IST%45R sip:registrar.example.com SIP/2.0
To: "%Z%45" <sip:resource@example.com>
From: "%Z%45" <sip:resource@example.com>;tag=f232jadfj23
Call-ID: esc02.asdfnqwo34rq23i34jrjasdcnl23nrlknsdf
Via: SIP/2.0/TCP host.example.com;branch=z9hG4bK209%fzsnel234
CSeq: 29344 RE%47IST%45R
Max-Forwards: 70
Contact: <sip:alias1@host1.example.com>
C%6Fntact: <sip:alias2@host2.example.com>
Contact: <sip:alias3@host3.example.com>
l: 0
RE%47IST%45R sip:registrar.example.com SIP/2.0
To: "%Z%45" <sip:resource@example.com>
From: "%Z%45" <sip:resource@example.com>;tag=f232jadfj23
Call-ID: esc02.asdfnqwo34rq23i34jrjasdcnl23nrlknsdf
Via: SIP/2.0/TCP host.example.com;branch=z9hG4bK209%fzsnel234
CSeq: 29344 RE%47IST%45R
Max-Forwards: 70
Contact: <sip:alias1@host1.example.com>
C%6Fntact: <sip:alias2@host2.example.com>
Contact: <sip:alias3@host3.example.com>
l: 0
This OPTIONS request is not valid per the grammar in RFC 3261 since there is no LWS between the token in the display name and < in the From header field value. This has been identified as a specification bug that will be removed when RFC 3261 is revised. Elements should accept this request as well formed.
根据RFC 3261中的语法，此选项请求无效，因为显示名称中的标记和From标头字段值中的<之间没有LWS。这已被确定为一个规范缺陷，将在修订RFC 3261时删除。元素应该接受这个格式良好的请求。
Message Details : lwsdisp
信息详情：lwsdisp
OPTIONS sip:user@example.com SIP/2.0
To: sip:user@example.com
From: caller<sip:caller@example.com>;tag=323
Max-Forwards: 70
Call-ID: lwsdisp.1234abcd@funky.example.com
CSeq: 60 OPTIONS
Via: SIP/2.0/UDP funky.example.com;branch=z9hG4bKkdjuw
l: 0
OPTIONS sip:user@example.com SIP/2.0
To: sip:user@example.com
From: caller<sip:caller@example.com>;tag=323
Max-Forwards: 70
Call-ID: lwsdisp.1234abcd@funky.example.com
CSeq: 60 OPTIONS
Via: SIP/2.0/UDP funky.example.com;branch=z9hG4bKkdjuw
l: 0
This well-formed request contains header fields with many values and values that are very long. Features include the following:
此格式良好的请求包含具有许多值和非常长的值的标题字段。其特点包括：
o The To header field has a long display name, and long uri parameter names and values.
o “收件人标头”字段有一个长的显示名称，以及长的uri参数名称和值。
o The From header field has long header parameter names and values, in particular, a very long tag.
o From header字段有很长的头参数名称和值，特别是很长的标记。
o The Call-ID is one long token.
o 呼叫ID是一个长令牌。
Message Details : longreq
消息详细信息：longreq
INVITE sip:user@example.com SIP/2.0
<allOneLine>
To: "I have a user name of
<repeat count=10>extreme</repeat> proportion"
<sip:user@example.com:6000;
unknownparam1=very<repeat count=20>long</repeat>value;
longparam<repeat count=25>name</repeat>=shortvalue;
very<repeat count=25>long</repeat>ParameterNameWithNoValue>
</allOneLine>
<allOneLine>
F: sip:
<repeat count=5>amazinglylongcallername</repeat>@example.net
;tag=12<repeat count=50>982</repeat>424
;unknownheaderparam<repeat count=20>name</repeat>=
unknowheaderparam<repeat count=15>value</repeat>
;unknownValueless<repeat count=10>paramname</repeat>
</allOneLine>
Call-ID: longreq.one<repeat count=20>really</repeat>longcallid
CSeq: 3882340 INVITE
<allOneLine>
Unknown-<repeat count=20>Long</repeat>-Name:
unknown-<repeat count=20>long</repeat>-value;
unknown-<repeat count=20>long</repeat>-parameter-name =
unknown-<repeat count=20>long</repeat>-parameter-value
</allOneLine>
Via: SIP/2.0/TCP sip33.example.com
v: SIP/2.0/TCP sip32.example.com
V: SIP/2.0/TCP sip31.example.com
Via: SIP/2.0/TCP sip30.example.com
ViA: SIP/2.0/TCP sip29.example.com
VIa: SIP/2.0/TCP sip28.example.com
VIA: SIP/2.0/TCP sip27.example.com
via: SIP/2.0/TCP sip26.example.com
viA: SIP/2.0/TCP sip25.example.com
vIa: SIP/2.0/TCP sip24.example.com
vIA: SIP/2.0/TCP sip23.example.com
V : SIP/2.0/TCP sip22.example.com
v : SIP/2.0/TCP sip21.example.com
V : SIP/2.0/TCP sip20.example.com
v : SIP/2.0/TCP sip19.example.com
Via : SIP/2.0/TCP sip18.example.com
Via : SIP/2.0/TCP sip17.example.com
Via: SIP/2.0/TCP sip16.example.com
Via: SIP/2.0/TCP sip15.example.com
Via: SIP/2.0/TCP sip14.example.com
Via: SIP/2.0/TCP sip13.example.com
INVITE sip:user@example.com SIP/2.0
<allOneLine>
To: "I have a user name of
<repeat count=10>extreme</repeat> proportion"
<sip:user@example.com:6000;
unknownparam1=very<repeat count=20>long</repeat>value;
longparam<repeat count=25>name</repeat>=shortvalue;
very<repeat count=25>long</repeat>ParameterNameWithNoValue>
</allOneLine>
<allOneLine>
F: sip:
<repeat count=5>amazinglylongcallername</repeat>@example.net
;tag=12<repeat count=50>982</repeat>424
;unknownheaderparam<repeat count=20>name</repeat>=
unknowheaderparam<repeat count=15>value</repeat>
;unknownValueless<repeat count=10>paramname</repeat>
</allOneLine>
Call-ID: longreq.one<repeat count=20>really</repeat>longcallid
CSeq: 3882340 INVITE
<allOneLine>
Unknown-<repeat count=20>Long</repeat>-Name:
unknown-<repeat count=20>long</repeat>-value;
unknown-<repeat count=20>long</repeat>-parameter-name =
unknown-<repeat count=20>long</repeat>-parameter-value
</allOneLine>
Via: SIP/2.0/TCP sip33.example.com
v: SIP/2.0/TCP sip32.example.com
V: SIP/2.0/TCP sip31.example.com
Via: SIP/2.0/TCP sip30.example.com
ViA: SIP/2.0/TCP sip29.example.com
VIa: SIP/2.0/TCP sip28.example.com
VIA: SIP/2.0/TCP sip27.example.com
via: SIP/2.0/TCP sip26.example.com
viA: SIP/2.0/TCP sip25.example.com
vIa: SIP/2.0/TCP sip24.example.com
vIA: SIP/2.0/TCP sip23.example.com
V : SIP/2.0/TCP sip22.example.com
v : SIP/2.0/TCP sip21.example.com
V : SIP/2.0/TCP sip20.example.com
v : SIP/2.0/TCP sip19.example.com
Via : SIP/2.0/TCP sip18.example.com
Via : SIP/2.0/TCP sip17.example.com
Via: SIP/2.0/TCP sip16.example.com
Via: SIP/2.0/TCP sip15.example.com
Via: SIP/2.0/TCP sip14.example.com
Via: SIP/2.0/TCP sip13.example.com
Via: SIP/2.0/TCP sip12.example.com
Via: SIP/2.0/TCP sip11.example.com
Via: SIP/2.0/TCP sip10.example.com
Via: SIP/2.0/TCP sip9.example.com
Via: SIP/2.0/TCP sip8.example.com
Via: SIP/2.0/TCP sip7.example.com
Via: SIP/2.0/TCP sip6.example.com
Via: SIP/2.0/TCP sip5.example.com
Via: SIP/2.0/TCP sip4.example.com
Via: SIP/2.0/TCP sip3.example.com
Via: SIP/2.0/TCP sip2.example.com
Via: SIP/2.0/TCP sip1.example.com
<allOneLine>
Via: SIP/2.0/TCP
host.example.com;received=192.0.2.5;
branch=very<repeat count=50>long</repeat>branchvalue
</allOneLine>
Max-Forwards: 70
<allOneLine>
Contact: <sip:
<repeat count=5>amazinglylongcallername</repeat>
@host5.example.net>
</allOneLine>
Content-Type: application/sdp
l: 150
Via: SIP/2.0/TCP sip12.example.com
Via: SIP/2.0/TCP sip11.example.com
Via: SIP/2.0/TCP sip10.example.com
Via: SIP/2.0/TCP sip9.example.com
Via: SIP/2.0/TCP sip8.example.com
Via: SIP/2.0/TCP sip7.example.com
Via: SIP/2.0/TCP sip6.example.com
Via: SIP/2.0/TCP sip5.example.com
Via: SIP/2.0/TCP sip4.example.com
Via: SIP/2.0/TCP sip3.example.com
Via: SIP/2.0/TCP sip2.example.com
Via: SIP/2.0/TCP sip1.example.com
<allOneLine>
Via: SIP/2.0/TCP
host.example.com;received=192.0.2.5;
branch=very<repeat count=50>long</repeat>branchvalue
</allOneLine>
Max-Forwards: 70
<allOneLine>
Contact: <sip:
<repeat count=5>amazinglylongcallername</repeat>
@host5.example.net>
</allOneLine>
Content-Type: application/sdp
l: 150
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
This message contains a single SIP REGISTER request, which ostensibly arrived over UDP in a single datagram. The packet contains extra octets after the body (which in this case has zero length). The extra octets happen to look like a SIP INVITE request, but (per section 18.3 of [RFC3261]) they are just spurious noise that must be ignored.
此消息包含一个SIP注册请求，该请求表面上是通过UDP在单个数据报中到达的。数据包在正文之后包含额外的八位字节（在本例中为零长度）。额外的八位字节看起来像SIP INVITE请求，但是（根据[RFC3261]第18.3节），它们只是杂散噪声，必须忽略。
A SIP element receiving this datagram would handle the REGISTER request normally and ignore the extra bits that look like an INVITE request. If the element is a proxy choosing to forward the REGISTER, the INVITE octets would not appear in the forwarded request.
接收此数据报的SIP元素将正常处理注册请求，并忽略看起来像INVITE请求的额外位。如果元素是选择转发寄存器的代理，则INVITE八位字节将不会出现在转发的请求中。
Message Details : dblreq
消息详细信息：dblreq
REGISTER sip:example.com SIP/2.0
To: sip:j.user@example.com
From: sip:j.user@example.com;tag=43251j3j324
Max-Forwards: 8
I: dblreq.0ha0isndaksdj99sdfafnl3lk233412
Contact: sip:j.user@host.example.com
CSeq: 8 REGISTER
Via: SIP/2.0/UDP 192.0.2.125;branch=z9hG4bKkdjuw23492
Content-Length: 0
REGISTER sip:example.com SIP/2.0
To: sip:j.user@example.com
From: sip:j.user@example.com;tag=43251j3j324
Max-Forwards: 8
I: dblreq.0ha0isndaksdj99sdfafnl3lk233412
Contact: sip:j.user@host.example.com
CSeq: 8 REGISTER
Via: SIP/2.0/UDP 192.0.2.125;branch=z9hG4bKkdjuw23492
Content-Length: 0
INVITE sip:joe@example.com SIP/2.0
t: sip:joe@example.com
From: sip:caller@example.net;tag=141334
Max-Forwards: 8
Call-ID: dblreq.0ha0isnda977644900765@192.0.2.15
CSeq: 8 INVITE
Via: SIP/2.0/UDP 192.0.2.15;branch=z9hG4bKkdjuw380234
Content-Type: application/sdp
Content-Length: 150
INVITE sip:joe@example.com SIP/2.0
t: sip:joe@example.com
From: sip:caller@example.net;tag=141334
Max-Forwards: 8
Call-ID: dblreq.0ha0isnda977644900765@192.0.2.15
CSeq: 8 INVITE
Via: SIP/2.0/UDP 192.0.2.15;branch=z9hG4bKkdjuw380234
Content-Type: application/sdp
Content-Length: 150
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.15
s=-
c=IN IP4 192.0.2.15
t=0 0
m=audio 49217 RTP/AVP 0 12
m =video 3227 RTP/AVP 31
a=rtpmap:31 LPC
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.15
s=-
c=IN IP4 192.0.2.15
t=0 0
m=audio 49217 RTP/AVP 0 12
m =video 3227 RTP/AVP 31
a=rtpmap:31 LPC
This request has a semicolon-separated parameter contained in the "user" part of the Request-URI (whose value contains an escaped @ symbol). Receiving elements will accept this as a well-formed message. The Request-URI will parse so that the user part is "user;par=u@example.net".
此请求在请求URI的“用户”部分包含一个分号分隔的参数（其值包含转义的@符号）。接收元素将接受这一格式良好的消息。请求URI将进行解析，以便用户部分为“user；par”=u@example.net".
Message Details : semiuri
消息详细信息：semiuri
OPTIONS sip:user;par=u%40example.net@example.com SIP/2.0
To: sip:j_user@example.com
From: sip:caller@example.org;tag=33242
Max-Forwards: 3
Call-ID: semiuri.0ha0isndaksdj
CSeq: 8 OPTIONS
Accept: application/sdp, application/pkcs7-mime,
multipart/mixed, multipart/signed,
message/sip, message/sipfrag
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKkdjuw
l: 0
OPTIONS sip:user;par=u%40example.net@example.com SIP/2.0
To: sip:j_user@example.com
From: sip:caller@example.org;tag=33242
Max-Forwards: 3
Call-ID: semiuri.0ha0isndaksdj
CSeq: 8 OPTIONS
Accept: application/sdp, application/pkcs7-mime,
multipart/mixed, multipart/signed,
message/sip, message/sipfrag
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKkdjuw
l: 0
This request contains Via header field values with all known transport types and exercises the transport extension mechanism. Parsers must accept this message as well formed. Elements receiving this message would process it exactly as if the 2nd and subsequent header field values specified UDP (or other transport).
此请求包含所有已知传输类型的Via标头字段值，并执行传输扩展机制。解析器必须接受格式正确的消息。接收此消息的元素将完全按照第二个和后续头字段值指定UDP（或其他传输）的方式对其进行处理。
Message Details : transports
消息详细信息：传输
OPTIONS sip:user@example.com SIP/2.0
To: sip:user@example.com
From: <sip:caller@example.com>;tag=323
Max-Forwards: 70
Call-ID: transports.kijh4akdnaqjkwendsasfdj
Accept: application/sdp
CSeq: 60 OPTIONS
Via: SIP/2.0/UDP t1.example.com;branch=z9hG4bKkdjuw
Via: SIP/2.0/SCTP t2.example.com;branch=z9hG4bKklasjdhf
Via: SIP/2.0/TLS t3.example.com;branch=z9hG4bK2980unddj
Via: SIP/2.0/UNKNOWN t4.example.com;branch=z9hG4bKasd0f3en
Via: SIP/2.0/TCP t5.example.com;branch=z9hG4bK0a9idfnee
l: 0
OPTIONS sip:user@example.com SIP/2.0
To: sip:user@example.com
From: <sip:caller@example.com>;tag=323
Max-Forwards: 70
Call-ID: transports.kijh4akdnaqjkwendsasfdj
Accept: application/sdp
CSeq: 60 OPTIONS
Via: SIP/2.0/UDP t1.example.com;branch=z9hG4bKkdjuw
Via: SIP/2.0/SCTP t2.example.com;branch=z9hG4bKklasjdhf
Via: SIP/2.0/TLS t3.example.com;branch=z9hG4bK2980unddj
Via: SIP/2.0/UNKNOWN t4.example.com;branch=z9hG4bKasd0f3en
Via: SIP/2.0/TCP t5.example.com;branch=z9hG4bK0a9idfnee
l: 0
This MESSAGE request contains two body parts. The second part is binary encoded and contains null (0x00) characters. Receivers must take care to frame the received message properly.
此消息请求包含两个正文部分。第二部分是二进制编码的，包含空（0x00）字符。接收者必须注意对接收到的消息进行适当的帧处理。
Parsers must accept this message as well formed, even if the application above the parser does not support multipart/signed.
解析器必须接受格式良好的消息，即使解析器上面的应用程序不支持多部分/签名。
Additional examples of multipart/mime messages, in particular S/MIME messages, are available in the security call flow examples document [SIP-SEC].
安全调用流示例文档[SIP-SEC]中提供了多部分/mime消息的其他示例，特别是S/mime消息。
Message Details : mpart01
信息详情：mpart01
MESSAGE sip:kumiko@example.org SIP/2.0
<allOneLine>
Via: SIP/2.0/UDP 127.0.0.1:5070
;branch=z9hG4bK-d87543-4dade06d0bdb11ee-1--d87543-;rport
</allOneLine>
Max-Forwards: 70
Route: <sip:127.0.0.1:5080>
<allOneLine>
Identity: r5mwreLuyDRYBi/0TiPwEsY3rEVsk/G2WxhgTV1PF7hHuL
IK0YWVKZhKv9Mj8UeXqkMVbnVq37CD+813gvYjcBUaZngQmXc9WNZSDN
GCzA+fWl9MEUHWIZo1CeJebdY/XlgKeTa0Olvq0rt70Q5jiSfbqMJmQF
teeivUhkMWYUA=
</allOneLine>
Contact: <sip:fluffy@127.0.0.1:5070>
To: <sip:kumiko@example.org>
From: <sip:fluffy@example.com>;tag=2fb0dcc9
Call-ID: 3d9485ad0c49859b@Zmx1ZmZ5LW1hYy0xNi5sb2NhbA..
CSeq: 1 MESSAGE
Content-Transfer-Encoding: binary
Content-Type: multipart/mixed;boundary=7a9cbec02ceef655
Date: Sat, 15 Oct 2005 04:44:56 GMT
User-Agent: SIPimp.org/0.2.5 (curses)
Content-Length: 553
MESSAGE sip:kumiko@example.org SIP/2.0
<allOneLine>
Via: SIP/2.0/UDP 127.0.0.1:5070
;branch=z9hG4bK-d87543-4dade06d0bdb11ee-1--d87543-;rport
</allOneLine>
Max-Forwards: 70
Route: <sip:127.0.0.1:5080>
<allOneLine>
Identity: r5mwreLuyDRYBi/0TiPwEsY3rEVsk/G2WxhgTV1PF7hHuL
IK0YWVKZhKv9Mj8UeXqkMVbnVq37CD+813gvYjcBUaZngQmXc9WNZSDN
GCzA+fWl9MEUHWIZo1CeJebdY/XlgKeTa0Olvq0rt70Q5jiSfbqMJmQF
teeivUhkMWYUA=
</allOneLine>
Contact: <sip:fluffy@127.0.0.1:5070>
To: <sip:kumiko@example.org>
From: <sip:fluffy@example.com>;tag=2fb0dcc9
Call-ID: 3d9485ad0c49859b@Zmx1ZmZ5LW1hYy0xNi5sb2NhbA..
CSeq: 1 MESSAGE
Content-Transfer-Encoding: binary
Content-Type: multipart/mixed;boundary=7a9cbec02ceef655
Date: Sat, 15 Oct 2005 04:44:56 GMT
User-Agent: SIPimp.org/0.2.5 (curses)
Content-Length: 553
--7a9cbec02ceef655
Content-Type: text/plain
Content-Transfer-Encoding: binary
--7a9cbec02ceef655
Content-Type: text/plain
Content-Transfer-Encoding: binary
Hello --7a9cbec02ceef655 Content-Type: application/octet-stream Content-Transfer-Encoding: binary
您好--7a9cbec02ceef655内容类型：应用程序/八位字节流内容传输编码：二进制
<hex> 3082015206092A86 4886F70D010702A08201433082013F02 01013109300706052B0E03021A300B06 092A864886F70D010701318201203082 011C020101307C3070310B3009060355 04061302555331133011060355040813 0A43616C69666F726E69613111300F06 03550407130853616E204A6F7365310E 300C060355040A130573697069743129 3027060355040B132053697069742054 65737420436572746966696361746520 417574686F7269747902080195007102 330113300706052B0E03021A300D0609 2A864886F70D01010105000481808EF4 66F948F0522DD2E5978E9D95AAE9F2FE 15A06659716292E8DA2AA8D8350A68CE FFAE3CBD2BFF1675DDD5648E593DD647 28F26220F7E941749E330D9A15EDABDB 93D10C42102E7B7289D29CC0C9AE2EFB C7C0CFF9172F3B027E4FC027E1546DE4 B6AA3ABB3E66CCCB5DD6C64B8383149C B8E6FF182D944FE57B65BC99D005 </hex> --7a9cbec02ceef655--
<hex>3082015206092A86 4886F70D010702A0820143308202013F02 01013109300706052B0E03021A300B06 092A864886F70D01070118201203082 011C0200101307C3070310B3009060355 04066130255533113301060355 04616C69666F726E696111300F06 035504071308516E204A6F7367365310E 300C060355040A1305736970690693129 3027060340B132069546573742043657274746696361746520 417574686F72697747902080195007102 330113300706052B00E03021A300D0609 2A864886F70D01010105000481808EF4 66F948F0522DD2E5978E9E9E9D95AAE9FE 15A066597162E8D8D8350A68CE FFE32BF1675DDD5648E593DD647 28F26220F7E949E949E330D9EA15EDABDB 930CE42727B9E9E9E9E40CF72727B9E9E9E9E9E7CF02727B9E9E9E9E9E9E9E9E9E9E9E9E9E9E7B9E7B9E9E9E9E7B7CFB6AA3ABB3E66CCCB5DD6C64B83149C B8E6FF182D944FE57B65BC99D005</hex>--7a9cbec02ceef655--
This 200 response contains a reason phrase other than "OK". The reason phrase is intended for human consumption and may contain any string produced by
此200响应包含除“OK”之外的原因短语。原因短语用于人类消费，可能包含由
Reason-Phrase = *(reserved / unreserved / escaped
/ UTF8-NONASCII / UTF8-CONT / SP / HTAB)
Reason-Phrase = *(reserved / unreserved / escaped
/ UTF8-NONASCII / UTF8-CONT / SP / HTAB)
This particular response contains unreserved and non-ascii UTF-8 characters. This response is well formed. A parser must accept this message.
此特定响应包含无保留和非ascii UTF-8字符。这一反应是有条理的。解析器必须接受此消息。
Message Details : unreason
消息详细信息：未读
<allOneLine>
SIP/2.0 200 = 2**3 * 5**2 <hex>D0BDD0BE20D181D182
D0BE20D0B4D0B5D0B2D18FD0BDD0BED181D182D0BE20D0B4
D0B5D0B2D18FD182D18C202D20D0BFD180D0BED181D182D0
BED0B5</hex>
</allOneLine>
Via: SIP/2.0/UDP 192.0.2.198;branch=z9hG4bK1324923
Call-ID: unreason.1234ksdfak3j2erwedfsASdf
CSeq: 35 INVITE
From: sip:user@example.com;tag=11141343
To: sip:user@example.edu;tag=2229
Content-Length: 154
Content-Type: application/sdp
Contact: <sip:user@host198.example.com>
<allOneLine>
SIP/2.0 200 = 2**3 * 5**2 <hex>D0BDD0BE20D181D182
D0BE20D0B4D0B5D0B2D18FD0BDD0BED181D182D0BE20D0B4
D0B5D0B2D18FD182D18C202D20D0BFD180D0BED181D182D0
BED0B5</hex>
</allOneLine>
Via: SIP/2.0/UDP 192.0.2.198;branch=z9hG4bK1324923
Call-ID: unreason.1234ksdfak3j2erwedfsASdf
CSeq: 35 INVITE
From: sip:user@example.com;tag=11141343
To: sip:user@example.edu;tag=2229
Content-Length: 154
Content-Type: application/sdp
Contact: <sip:user@host198.example.com>
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.198
s=-
c=IN IP4 192.0.2.198
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.198
s=-
c=IN IP4 192.0.2.198
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
This well-formed response contains no reason phrase. A parser must accept this message. The space character after the reason code is required. If it were not present, this message could be rejected as invalid (a liberal receiver would accept it anyway).
这个结构良好的回答不包含理由短语。解析器必须接受此消息。原因代码后的空格字符是必需的。如果该消息不存在，则该消息可能会被视为无效而拒绝（自由接收者无论如何都会接受该消息）。
Message Details : noreason
留言详情：noreason
SIP/2.0 100<hex>20</hex>
Via: SIP/2.0/UDP 192.0.2.105;branch=z9hG4bK2398ndaoe
Call-ID: noreason.asndj203insdf99223ndf
CSeq: 35 INVITE
From: <sip:user@example.com>;tag=39ansfi3
To: <sip:user@example.edu>;tag=902jndnke3
Content-Length: 0
Contact: <sip:user@host105.example.com>
SIP/2.0 100<hex>20</hex>
Via: SIP/2.0/UDP 192.0.2.105;branch=z9hG4bK2398ndaoe
Call-ID: noreason.asndj203insdf99223ndf
CSeq: 35 INVITE
From: <sip:user@example.com>;tag=39ansfi3
To: <sip:user@example.edu>;tag=902jndnke3
Content-Length: 0
Contact: <sip:user@host105.example.com>
This section contains several invalid messages reflecting errors seen at interoperability events and exploring important edge conditions that can be induced through malformed messages. This section does not attempt to be a comprehensive list of all types of invalid messages.
本节包含几个无效消息，这些消息反映了互操作性事件中出现的错误，并探讨了可能由格式错误的消息引起的重要边缘条件。本节并不试图全面列出所有类型的无效消息。
The Via header field of this request contains additional semicolons and commas without parameters or values. The Contact header field contains additional semicolons without parameters. This message is syntactically invalid.
此请求的Via标头字段包含其他分号和逗号，不带参数或值。联系人标题字段包含不带参数的其他分号。此消息在语法上无效。
An element receiving this request should respond with a 400 Bad Request error.
接收此请求的元素应响应400错误请求错误。
Message Details : badinv01
信息详情：badinv01
INVITE sip:user@example.com SIP/2.0
To: sip:j.user@example.com
From: sip:caller@example.net;tag=134161461246
Max-Forwards: 7
Call-ID: badinv01.0ha0isndaksdjasdf3234nas
CSeq: 8 INVITE
Via: SIP/2.0/UDP 192.0.2.15;;,;,,
Contact: "Joe" <sip:joe@example.org>;;;;
Content-Length: 152
Content-Type: application/sdp
INVITE sip:user@example.com SIP/2.0
To: sip:j.user@example.com
From: sip:caller@example.net;tag=134161461246
Max-Forwards: 7
Call-ID: badinv01.0ha0isndaksdjasdf3234nas
CSeq: 8 INVITE
Via: SIP/2.0/UDP 192.0.2.15;;,;,,
Contact: "Joe" <sip:joe@example.org>;;;;
Content-Length: 152
Content-Type: application/sdp
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.15
s=-
c=IN IP4 192.0.2.15
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.15
s=-
c=IN IP4 192.0.2.15
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
This is a request message with a Content Length that is larger than the actual length of the body.
这是一条内容长度大于正文实际长度的请求消息。
When sent over UDP (as this message ostensibly was), the receiving element should respond with a 400 Bad Request error. If this message arrived over a stream-based transport, such as TCP, there's not much
当通过UDP发送时（这条消息表面上是这样），接收元素应该响应400错误请求错误。如果此消息通过基于流的传输（如TCP）到达，则不会有太多
the receiving party could do but wait for more data on the stream and close the connection if none is forthcoming within a reasonable period of time.
接收方只能等待流上的更多数据，如果在合理的时间段内没有数据，则关闭连接。
Message Details : clerr
留言详情：clerr
INVITE sip:user@example.com SIP/2.0
Max-Forwards: 80
To: sip:j.user@example.com
From: sip:caller@example.net;tag=93942939o2
Contact: <sip:caller@hungry.example.net>
Call-ID: clerr.0ha0isndaksdjweiafasdk3
CSeq: 8 INVITE
Via: SIP/2.0/UDP host5.example.com;branch=z9hG4bK-39234-23523
Content-Type: application/sdp
Content-Length: 9999
INVITE sip:user@example.com SIP/2.0
Max-Forwards: 80
To: sip:j.user@example.com
From: sip:caller@example.net;tag=93942939o2
Contact: <sip:caller@hungry.example.net>
Call-ID: clerr.0ha0isndaksdjweiafasdk3
CSeq: 8 INVITE
Via: SIP/2.0/UDP host5.example.com;branch=z9hG4bK-39234-23523
Content-Type: application/sdp
Content-Length: 9999
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.155
s=-
c=IN IP4 192.0.2.155
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.155
s=-
c=IN IP4 192.0.2.155
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
This request has a negative value for Content-Length.
此请求的内容长度为负值。
An element receiving this message should respond with an error. This request appeared over UDP, so the remainder of the datagram can simply be discarded. If a request like this arrives over TCP, the framing error is not recoverable, and the connection should be closed. The same behavior is appropriate for messages that arrive without a numeric value in the Content-Length header field, such as the following:
接收此消息的元素应以错误响应。此请求是通过UDP出现的，因此可以简单地丢弃数据报的其余部分。如果这样的请求通过TCP到达，则帧错误是不可恢复的，连接应该关闭。同样的行为也适用于到达时内容长度标头字段中没有数字值的邮件，例如：
Content-Length: five
内容长度：5
Implementors should take extra precautions if the technique they choose for converting this ascii field into an integral form can return a negative value. In particular, the result must not be used as a counter or array index.
如果他们选择的将此ascii字段转换为整数形式的技术可能返回负值，那么实现者应该采取额外的预防措施。特别是，结果不能用作计数器或数组索引。
Message Details : ncl
信息详情：ncl
INVITE sip:user@example.com SIP/2.0
Max-Forwards: 254
To: sip:j.user@example.com
From: sip:caller@example.net;tag=32394234
Call-ID: ncl.0ha0isndaksdj2193423r542w35
CSeq: 0 INVITE
Via: SIP/2.0/UDP 192.0.2.53;branch=z9hG4bKkdjuw
Contact: <sip:caller@example53.example.net>
Content-Type: application/sdp
Content-Length: -999
INVITE sip:user@example.com SIP/2.0
Max-Forwards: 254
To: sip:j.user@example.com
From: sip:caller@example.net;tag=32394234
Call-ID: ncl.0ha0isndaksdj2193423r542w35
CSeq: 0 INVITE
Via: SIP/2.0/UDP 192.0.2.53;branch=z9hG4bKkdjuw
Contact: <sip:caller@example53.example.net>
Content-Type: application/sdp
Content-Length: -999
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.53
s=-
c=IN IP4 192.0.2.53
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.53
s=-
c=IN IP4 192.0.2.53
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
This request contains several scalar header field values outside their legal range.
此请求包含几个超出其合法范围的标量头字段值。
o The CSeq sequence number is >2**32-1.
o CSeq序列号大于2**32-1。
o The Max-Forwards value is >255.
o 最大转发值大于255。
o The Expires value is >2**32-1.
o Expires值大于2**32-1。
o The Contact expires parameter value is >2**32-1.
o 触点过期参数值大于2**32-1。
An element receiving this request should respond with a 400 Bad Request due to the CSeq error. If only the Max-Forwards field were in error, the element could choose to process the request as if the field were absent. If only the expiry values were in error, the element could treat them as if they contained the default values for expiration (3600 in this case).
由于CSeq错误，接收此请求的元素应响应400错误请求。如果只有Max-Forwards字段出错，那么元素可以选择像不存在字段一样处理请求。如果只有到期值出错，元素可以将其视为包含到期的默认值（本例中为3600）。
Other scalar request fields that may contain aberrant values include, but are not limited to, the Contact q value, the Timestamp value, and the Via ttl parameter.
可能包含异常值的其他标量请求字段包括但不限于触点q值、时间戳值和Via ttl参数。
Message Details : scalar02
消息详细信息：scalar02
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TCP host129.example.com;branch=z9hG4bK342sdfoi3
To: <sip:user@example.com>
From: <sip:user@example.com>;tag=239232jh3
CSeq: 36893488147419103232 REGISTER
Call-ID: scalar02.23o0pd9vanlq3wnrlnewofjas9ui32
Max-Forwards: 300
Expires: 1<repeat count=100>0</repeat>
Contact: <sip:user@host129.example.com>
;expires=280297596632815
Content-Length: 0
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TCP host129.example.com;branch=z9hG4bK342sdfoi3
To: <sip:user@example.com>
From: <sip:user@example.com>;tag=239232jh3
CSeq: 36893488147419103232 REGISTER
Call-ID: scalar02.23o0pd9vanlq3wnrlnewofjas9ui32
Max-Forwards: 300
Expires: 1<repeat count=100>0</repeat>
Contact: <sip:user@host129.example.com>
;expires=280297596632815
Content-Length: 0
This response contains several scalar header field values outside their legal range.
此响应包含几个超出其合法范围的标量头字段值。
o The CSeq sequence number is >2**32-1.
o CSeq序列号大于2**32-1。
o The Retry-After field is unreasonably large (note that RFC 3261 does not define a legal range for this field).
o “重试时间”字段过大（请注意，RFC 3261没有为此字段定义合法范围）。
o The Warning field has a warning-value with more than 3 digits.
o 警告字段的警告值超过3位。
An element receiving this response will simply discard it.
接收此响应的元素将直接丢弃它。
Message Details : scalarlg
消息详细信息：scalarlg
SIP/2.0 503 Service Unavailable
<allOneLine>
Via: SIP/2.0/TCP host129.example.com
;branch=z9hG4bKzzxdiwo34sw
;received=192.0.2.129
</allOneLine>
To: <sip:user@example.com>
From: <sip:other@example.net>;tag=2easdjfejw
CSeq: 9292394834772304023312 OPTIONS
Call-ID: scalarlg.noase0of0234hn2qofoaf0232aewf2394r
Retry-After: 949302838503028349304023988
Warning: 1812 overture "In Progress"
Content-Length: 0
SIP/2.0 503 Service Unavailable
<allOneLine>
Via: SIP/2.0/TCP host129.example.com
;branch=z9hG4bKzzxdiwo34sw
;received=192.0.2.129
</allOneLine>
To: <sip:user@example.com>
From: <sip:other@example.net>;tag=2easdjfejw
CSeq: 9292394834772304023312 OPTIONS
Call-ID: scalarlg.noase0of0234hn2qofoaf0232aewf2394r
Retry-After: 949302838503028349304023988
Warning: 1812 overture "In Progress"
Content-Length: 0
This is a request with an unterminated quote in the display name of the To field. An element receiving this request should return a 400 Bad Request error.
这是一个请求，在“收件人”字段的显示名称中有一个未终止的引号。接收此请求的元素应返回400错误请求错误。
An element could attempt to infer a terminating quote and accept the message. Such an element needs to take care that it makes a reasonable inference when it encounters
元素可以尝试推断终止引号并接受消息。这样的元素需要注意，当它遇到
To: "Mr J. User <sip:j.user@example.com> <sip:realj@example.net>
To: "Mr J. User <sip:j.user@example.com> <sip:realj@example.net>
Message Details : quotbal
留言详情：quotbal
INVITE sip:user@example.com SIP/2.0
To: "Mr. J. User <sip:j.user@example.com>
From: sip:caller@example.net;tag=93334
Max-Forwards: 10
Call-ID: quotbal.aksdj
Contact: <sip:caller@host59.example.net>
CSeq: 8 INVITE
Via: SIP/2.0/UDP 192.0.2.59:5050;branch=z9hG4bKkdjuw39234
Content-Type: application/sdp
Content-Length: 152
INVITE sip:user@example.com SIP/2.0
To: "Mr. J. User <sip:j.user@example.com>
From: sip:caller@example.net;tag=93334
Max-Forwards: 10
Call-ID: quotbal.aksdj
Contact: <sip:caller@host59.example.net>
CSeq: 8 INVITE
Via: SIP/2.0/UDP 192.0.2.59:5050;branch=z9hG4bKkdjuw39234
Content-Type: application/sdp
Content-Length: 152
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.15
s=-
c=IN IP4 192.0.2.15
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.15
s=-
c=IN IP4 192.0.2.15
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
This INVITE request is invalid because the Request-URI has been enclosed within in "<>".
此INVITE请求无效，因为请求URI已包含在“<>”中。
It is reasonable always to reject a request with this error with a 400 Bad Request. Elements attempting to be liberal with what they accept may choose to ignore the brackets. If the element forwards the request, it must not include the brackets in the messages it sends.
总是可以用400个错误请求拒绝带有此错误的请求。试图对其所接受的内容持开放态度的元素可能会选择忽略括号。如果元素转发请求，则它发送的消息中不得包含括号。
Message Details : ltgtruri
消息详细信息：ltgtruri
INVITE <sip:user@example.com> SIP/2.0
To: sip:user@example.com
From: sip:caller@example.net;tag=39291
Max-Forwards: 23
Call-ID: ltgtruri.1@192.0.2.5
CSeq: 1 INVITE
Via: SIP/2.0/UDP 192.0.2.5
Contact: <sip:caller@host5.example.net>
Content-Type: application/sdp
Content-Length: 159
INVITE <sip:user@example.com> SIP/2.0
To: sip:user@example.com
From: sip:caller@example.net;tag=39291
Max-Forwards: 23
Call-ID: ltgtruri.1@192.0.2.5
CSeq: 1 INVITE
Via: SIP/2.0/UDP 192.0.2.5
Contact: <sip:caller@host5.example.net>
Content-Type: application/sdp
Content-Length: 159
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.5
s=-
c=IN IP4 192.0.2.5
t=3149328700 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.5
s=-
c=IN IP4 192.0.2.5
t=3149328700 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
This INVITE has illegal LWS within the Request-URI.
此邀请在请求URI中包含非法LW。
An element receiving this request should respond with a 400 Bad Request.
接收此请求的元素应响应400个错误请求。
An element could attempt to ignore the embedded LWS for those schemes (like SIP) where doing so would not introduce ambiguity.
元素可以尝试忽略那些方案（如SIP）的嵌入式LW，这样做不会引起歧义。
Message Details : lwsruri
消息详细信息：LWSURI
INVITE sip:user@example.com; lr SIP/2.0
To: sip:user@example.com;tag=3xfe-9921883-z9f
From: sip:caller@example.net;tag=231413434
Max-Forwards: 5
Call-ID: lwsruri.asdfasdoeoi2323-asdfwrn23-asd834rk423
CSeq: 2130706432 INVITE
Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKkdjuw2395
Contact: <sip:caller@host1.example.net>
Content-Type: application/sdp
Content-Length: 159
INVITE sip:user@example.com; lr SIP/2.0
To: sip:user@example.com;tag=3xfe-9921883-z9f
From: sip:caller@example.net;tag=231413434
Max-Forwards: 5
Call-ID: lwsruri.asdfasdoeoi2323-asdfwrn23-asd834rk423
CSeq: 2130706432 INVITE
Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKkdjuw2395
Contact: <sip:caller@host1.example.net>
Content-Type: application/sdp
Content-Length: 159
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=3149328700 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=3149328700 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
This INVITE has illegal multiple SP characters between elements of the start line.
此INVITE在起始行元素之间具有非法的多个SP字符。
It is acceptable to reject this request as malformed. An element that is liberal in what it accepts may ignore these extra SP characters when processing the request. If the element forwards the request, it must not include these extra SP characters in the messages it sends.
可以接受以格式不正确为由拒绝此请求。处理请求时，在接受内容上自由的元素可能会忽略这些额外的SP字符。如果元素转发请求，则它发送的消息中不得包含这些额外的SP字符。
Message Details : lwsstart
消息详细信息：lwsstart
INVITE sip:user@example.com SIP/2.0
Max-Forwards: 8
To: sip:user@example.com
From: sip:caller@example.net;tag=8814
Call-ID: lwsstart.dfknq234oi243099adsdfnawe3@example.com
CSeq: 1893884 INVITE
Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bKkdjuw3923
Contact: <sip:caller@host1.example.net>
Content-Type: application/sdp
Content-Length: 150
INVITE sip:user@example.com SIP/2.0
Max-Forwards: 8
To: sip:user@example.com
From: sip:caller@example.net;tag=8814
Call-ID: lwsstart.dfknq234oi243099adsdfnawe3@example.com
CSeq: 1893884 INVITE
Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bKkdjuw3923
Contact: <sip:caller@host1.example.net>
Content-Type: application/sdp
Content-Length: 150
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
This OPTIONS request contains SP characters between the SIP-Version field and the CRLF terminating the Request-Line.
此选项请求包含SIP版本字段和终止请求行的CRLF之间的SP字符。
It is acceptable to reject this request as malformed. An element that is liberal in what it accepts may ignore these extra SP characters when processing the request. If the element forwards the request, it must not include these extra SP characters in the messages it sends.
可以接受以格式不正确为由拒绝此请求。处理请求时，在接受内容上自由的元素可能会忽略这些额外的SP字符。如果元素转发请求，则它发送的消息中不得包含这些额外的SP字符。
Message Details : trws
消息详细信息：trws
OPTIONS sip:remote-target@example.com SIP/2.0<hex>2020</hex>
Via: SIP/2.0/TCP host1.example.com;branch=z9hG4bK299342093
To: <sip:remote-target@example.com>
From: <sip:local-resource@example.com>;tag=329429089
Call-ID: trws.oicu34958239neffasdhr2345r
Accept: application/sdp
CSeq: 238923 OPTIONS
Max-Forwards: 70
Content-Length: 0
OPTIONS sip:remote-target@example.com SIP/2.0<hex>2020</hex>
Via: SIP/2.0/TCP host1.example.com;branch=z9hG4bK299342093
To: <sip:remote-target@example.com>
From: <sip:local-resource@example.com>;tag=329429089
Call-ID: trws.oicu34958239neffasdhr2345r
Accept: application/sdp
CSeq: 238923 OPTIONS
Max-Forwards: 70
Content-Length: 0
This INVITE is malformed, as the SIP Request-URI contains escaped headers.
此INVITE的格式不正确，因为SIP请求URI包含转义头。
It is acceptable for an element to reject this request with a 400 Bad Request. An element could choose to be liberal in what it accepts and ignore the escaped headers. If the element is a proxy, the escaped headers must not appear in the Request-URI of the forwarded request (and most certainly must not be translated into the actual header of the forwarded request).
元素以400错误请求拒绝此请求是可以接受的。元素可以选择在它接受的内容上自由，并忽略转义的头。如果元素是代理，则转义的头不能出现在转发请求的请求URI中（并且最肯定的是不能转换为转发请求的实际头）。
Message Details : escruri
信息详情：escruri
INVITE sip:user@example.com?Route=%3Csip:example.com%3E SIP/2.0
To: sip:user@example.com
From: sip:caller@example.net;tag=341518
Max-Forwards: 7
Contact: <sip:caller@host39923.example.net>
Call-ID: escruri.23940-asdfhj-aje3br-234q098w-fawerh2q-h4n5
CSeq: 149209342 INVITE
Via: SIP/2.0/UDP host-of-the-hour.example.com;branch=z9hG4bKkdjuw
Content-Type: application/sdp
Content-Length: 150
INVITE sip:user@example.com?Route=%3Csip:example.com%3E SIP/2.0
To: sip:user@example.com
From: sip:caller@example.net;tag=341518
Max-Forwards: 7
Contact: <sip:caller@host39923.example.net>
Call-ID: escruri.23940-asdfhj-aje3br-234q098w-fawerh2q-h4n5
CSeq: 149209342 INVITE
Via: SIP/2.0/UDP host-of-the-hour.example.com;branch=z9hG4bKkdjuw
Content-Type: application/sdp
Content-Length: 150
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
This INVITE is invalid, as it contains a non-GMT time zone in the SIP Date header field.
此邀请无效，因为它在SIP日期标头字段中包含非GMT时区。
It is acceptable to reject this request as malformed (though an element shouldn't do that unless the contents of the Date header field were actually important to its processing). An element wishing to be liberal in what it accepts could ignore this value altogether if it wasn't going to use the Date header field anyway. Otherwise, it could attempt to interpret this date and adjust it to GMT.
可以将此请求视为格式错误而拒绝（尽管元素不应该这样做，除非日期头字段的内容对其处理非常重要）。如果一个元素不打算使用日期头字段，那么它可以完全忽略这个值。否则，它可能会试图解释该日期并将其调整为GMT。
RFC 3261 explicitly defines the only acceptable time zone designation as "GMT". "UT", while synonymous with GMT per [RFC2822], is not valid. "UTC" and "UCT" are also invalid.
RFC 3261明确将唯一可接受的时区名称定义为“GMT”。“UT”与[RFC2822]规定的GMT同义，但无效。“UTC”和“UCT”也无效。
Message Details : baddate
消息详细信息：baddate
INVITE sip:user@example.com SIP/2.0
To: sip:user@example.com
From: sip:caller@example.net;tag=2234923
Max-Forwards: 70
Call-ID: baddate.239423mnsadf3j23lj42--sedfnm234
CSeq: 1392934 INVITE
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKkdjuw
Date: Fri, 01 Jan 2010 16:00:00 EST
Contact: <sip:caller@host5.example.net>
Content-Type: application/sdp
Content-Length: 150
INVITE sip:user@example.com SIP/2.0
To: sip:user@example.com
From: sip:caller@example.net;tag=2234923
Max-Forwards: 70
Call-ID: baddate.239423mnsadf3j23lj42--sedfnm234
CSeq: 1392934 INVITE
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKkdjuw
Date: Fri, 01 Jan 2010 16:00:00 EST
Contact: <sip:caller@host5.example.net>
Content-Type: application/sdp
Content-Length: 150
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.5
s=-
c=IN IP4 192.0.2.5
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.5
s=-
c=IN IP4 192.0.2.5
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
This REGISTER request is malformed. The SIP URI contained in the Contact Header field has an escaped header, so the field must be in name-addr form (which implies that the URI must be enclosed in <>).
此注册请求的格式不正确。Contact Header字段中包含的SIP URI有一个转义头，因此该字段必须采用name addr格式（这意味着URI必须包含在<>中）。
It is reasonable for an element receiving this request to respond with a 400 Bad Request. An element choosing to be liberal in what it accepts could infer the angle brackets since there is no ambiguity in this example. In general, that won't be possible.
接收此请求的元素响应400个错误请求是合理的。一个元素选择在它所接受的内容上是自由的，可以推断出尖括号，因为在这个例子中没有歧义。一般来说，这是不可能的。
Message Details : regbadct
消息详细信息：regbadct
REGISTER sip:example.com SIP/2.0
To: sip:user@example.com
From: sip:user@example.com;tag=998332
Max-Forwards: 70
Call-ID: regbadct.k345asrl3fdbv@10.0.0.1
CSeq: 1 REGISTER
Via: SIP/2.0/UDP 135.180.130.133:5060;branch=z9hG4bKkdjuw
Contact: sip:user@example.com?Route=%3Csip:sip.example.com%3E
l: 0
REGISTER sip:example.com SIP/2.0
To: sip:user@example.com
From: sip:user@example.com;tag=998332
Max-Forwards: 70
Call-ID: regbadct.k345asrl3fdbv@10.0.0.1
CSeq: 1 REGISTER
Via: SIP/2.0/UDP 135.180.130.133:5060;branch=z9hG4bKkdjuw
Contact: sip:user@example.com?Route=%3Csip:sip.example.com%3E
l: 0
This request is malformed, since the addr-spec in the To header field contains spaces. Parsers receiving this request must not break. It is reasonable to reject this request with a 400 Bad Request response. Elements attempting to be liberal may ignore the spaces.
此请求的格式不正确，因为“收件人”标题字段中的addr spec包含空格。接收此请求的解析器不得中断。用400个错误的请求响应拒绝此请求是合理的。试图自由的元素可能会忽略空格。
Message Details : badaspec
消息详细信息：badaspec
OPTIONS sip:user@example.org SIP/2.0
Via: SIP/2.0/UDP host4.example.com:5060;branch=z9hG4bKkdju43234
Max-Forwards: 70
From: "Bell, Alexander" <sip:a.g.bell@example.com>;tag=433423
To: "Watson, Thomas" < sip:t.watson@example.org >
Call-ID: badaspec.sdf0234n2nds0a099u23h3hnnw009cdkne3
Accept: application/sdp
CSeq: 3923239 OPTIONS
l: 0
OPTIONS sip:user@example.org SIP/2.0
Via: SIP/2.0/UDP host4.example.com:5060;branch=z9hG4bKkdju43234
Max-Forwards: 70
From: "Bell, Alexander" <sip:a.g.bell@example.com>;tag=433423
To: "Watson, Thomas" < sip:t.watson@example.org >
Call-ID: badaspec.sdf0234n2nds0a099u23h3hnnw009cdkne3
Accept: application/sdp
CSeq: 3923239 OPTIONS
l: 0
This OPTIONS request is malformed, since the display names in the To and From header fields contain non-token characters but are unquoted.
此选项请求的格式不正确，因为“收件人”和“发件人”标题字段中的显示名称包含非标记字符，但没有引号。
It is reasonable always to reject this kind of error with a 400 Bad Request response.
用400个错误的请求-响应拒绝此类错误总是合理的。
An element may attempt to be liberal in what it receives and infer the missing quotes. If this element were a proxy, it must not propagate the error into the request it forwards. As a consequence, if the fields are covered by a signature, there's not much point in trying to be liberal - the message should simply be rejected.
一个元素可能会尝试在它接收到的内容上自由，并推断出缺少的引号。如果此元素是代理，则它不能将错误传播到它转发的请求中。因此，如果字段被签名覆盖，那么尝试自由就没有多大意义了——应该简单地拒绝消息。
Message Details : baddn
消息详细信息：baddn
OPTIONS sip:t.watson@example.org SIP/2.0
Via: SIP/2.0/UDP c.example.com:5060;branch=z9hG4bKkdjuw
Max-Forwards: 70
From: Bell, Alexander <sip:a.g.bell@example.com>;tag=43
To: Watson, Thomas <sip:t.watson@example.org>
Call-ID: baddn.31415@c.example.com
Accept: application/sdp
CSeq: 3923239 OPTIONS
l: 0
OPTIONS sip:t.watson@example.org SIP/2.0
Via: SIP/2.0/UDP c.example.com:5060;branch=z9hG4bKkdjuw
Max-Forwards: 70
From: Bell, Alexander <sip:a.g.bell@example.com>;tag=43
To: Watson, Thomas <sip:t.watson@example.org>
Call-ID: baddn.31415@c.example.com
Accept: application/sdp
CSeq: 3923239 OPTIONS
l: 0
To an element implementing [RFC3261], this request is malformed due to its high version number.
对于实现[RFC3261]的元素，由于其版本号较高，此请求的格式不正确。
The element should respond to the request with a 505 Version Not Supported error.
元素应使用505版本不支持的错误响应请求。
Message Details : badvers
留言详情：badvers
OPTIONS sip:t.watson@example.org SIP/7.0
Via: SIP/7.0/UDP c.example.com;branch=z9hG4bKkdjuw
Max-Forwards: 70
From: A. Bell <sip:a.g.bell@example.com>;tag=qweoiqpe
To: T. Watson <sip:t.watson@example.org>
Call-ID: badvers.31417@c.example.com
CSeq: 1 OPTIONS
l: 0
OPTIONS sip:t.watson@example.org SIP/7.0
Via: SIP/7.0/UDP c.example.com;branch=z9hG4bKkdjuw
Max-Forwards: 70
From: A. Bell <sip:a.g.bell@example.com>;tag=qweoiqpe
To: T. Watson <sip:t.watson@example.org>
Call-ID: badvers.31417@c.example.com
CSeq: 1 OPTIONS
l: 0
This request has mismatching values for the method in the start line and the CSeq header field. Any element receiving this request will respond with a 400 Bad Request.
此请求的起始行和CSeq标头字段中的方法值不匹配。任何接收到该请求的元素都将响应400个错误请求。
Message Details : mismatch01
消息详细信息：不匹配01
OPTIONS sip:user@example.com SIP/2.0
To: sip:j.user@example.com
From: sip:caller@example.net;tag=34525
Max-Forwards: 6
Call-ID: mismatch01.dj0234sxdfl3
CSeq: 8 INVITE
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKkdjuw
l: 0
OPTIONS sip:user@example.com SIP/2.0
To: sip:j.user@example.com
From: sip:caller@example.net;tag=34525
Max-Forwards: 6
Call-ID: mismatch01.dj0234sxdfl3
CSeq: 8 INVITE
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKkdjuw
l: 0
This message has an unknown method in the start line, and a CSeq method tag that does not match.
此消息的起始行中有未知方法，并且CSeq方法标记不匹配。
Any element receiving this response should respond with a 501 Not Implemented. A 400 Bad Request is also acceptable, but choosing a 501 (particularly at proxies) has better future-proof characteristics.
任何接收到该响应的元素都应以501未实现来响应。400错误请求也是可以接受的，但选择501（特别是在代理服务器上）具有更好的未来证明特性。
Message Details : mismatch02
消息详细信息：不匹配02
NEWMETHOD sip:user@example.com SIP/2.0
To: sip:j.user@example.com
From: sip:caller@example.net;tag=34525
Max-Forwards: 6
Call-ID: mismatch02.dj0234sxdfl3
CSeq: 8 INVITE
Contact: <sip:caller@host.example.net>
Via: SIP/2.0/UDP host.example.net;branch=z9hG4bKkdjuw
Content-Type: application/sdp
l: 138
NEWMETHOD sip:user@example.com SIP/2.0
To: sip:j.user@example.com
From: sip:caller@example.net;tag=34525
Max-Forwards: 6
Call-ID: mismatch02.dj0234sxdfl3
CSeq: 8 INVITE
Contact: <sip:caller@host.example.net>
Via: SIP/2.0/UDP host.example.net;branch=z9hG4bKkdjuw
Content-Type: application/sdp
l: 138
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.1
c=IN IP4 192.0.2.1
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.1
c=IN IP4 192.0.2.1
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
This response has a response code larger than 699. An element receiving this response should simply drop it.
此响应的响应代码大于699。接收此响应的元素应该简单地删除它。
Message Details : bigcode
消息详细信息：bigcode
SIP/2.0 4294967301 better not break the receiver
Via: SIP/2.0/UDP 192.0.2.105;branch=z9hG4bK2398ndaoe
Call-ID: bigcode.asdof3uj203asdnf3429uasdhfas3ehjasdfas9i
CSeq: 353494 INVITE
From: <sip:user@example.com>;tag=39ansfi3
To: <sip:user@example.edu>;tag=902jndnke3
Content-Length: 0
Contact: <sip:user@host105.example.com>
SIP/2.0 4294967301 better not break the receiver
Via: SIP/2.0/UDP 192.0.2.105;branch=z9hG4bK2398ndaoe
Call-ID: bigcode.asdof3uj203asdnf3429uasdhfas3ehjasdfas9i
CSeq: 353494 INVITE
From: <sip:user@example.com>;tag=39ansfi3
To: <sip:user@example.edu>;tag=902jndnke3
Content-Length: 0
Contact: <sip:user@host105.example.com>
This section contains tests that exercise an implementation's parser and transaction-layer logic.
本节包含执行实现的解析器和事务层逻辑的测试。
This request indicates support for RFC 3261-style transaction identifiers by providing the z9hG4bK prefix to the branch parameter, but it provides no identifier. A parser must not break when receiving this message. An element receiving this request could reject the request with a 400 Response (preferably statelessly, as other requests from the source are likely also to have a malformed branch parameter), or it could fall back to the RFC 2543-style transaction identifier.
此请求通过向分支参数提供z9hG4bK前缀来表示对RFC 3261样式事务标识符的支持，但它不提供标识符。解析器在接收此消息时不得中断。接收该请求的元素可以使用400响应拒绝该请求（最好是无状态的，因为来自源的其他请求也可能具有格式错误的分支参数），或者它可以回退到RFC 2543样式的事务标识符。
Message Details : badbranch
留言详情：badbranch
OPTIONS sip:user@example.com SIP/2.0
To: sip:user@example.com
From: sip:caller@example.org;tag=33242
Max-Forwards: 3
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bK
Accept: application/sdp
Call-ID: badbranch.sadonfo23i420jv0as0derf3j3n
CSeq: 8 OPTIONS
l: 0
OPTIONS sip:user@example.com SIP/2.0
To: sip:user@example.com
From: sip:caller@example.org;tag=33242
Max-Forwards: 3
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bK
Accept: application/sdp
Call-ID: badbranch.sadonfo23i420jv0as0derf3j3n
CSeq: 8 OPTIONS
l: 0
This section contains tests that exercise an implementation's parser and application-layer logic.
本节包含测试实现的解析器和应用程序层逻辑。
This request contains no Call-ID, From, or To header fields.
此请求不包含呼叫ID、发件人或收件人标头字段。
An element receiving this message must not break because of the missing information. Ideally, it will respond with a 400 Bad Request error.
接收此消息的元素不能因为缺少信息而中断。理想情况下，它将以400个错误请求响应。
Message Details : insuf
信息详情：insuf
INVITE sip:user@example.com SIP/2.0
CSeq: 193942 INVITE
Via: SIP/2.0/UDP 192.0.2.95;branch=z9hG4bKkdj.insuf
Content-Type: application/sdp
l: 152
INVITE sip:user@example.com SIP/2.0
CSeq: 193942 INVITE
Via: SIP/2.0/UDP 192.0.2.95;branch=z9hG4bKkdj.insuf
Content-Type: application/sdp
l: 152
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.95
s=-
c=IN IP4 192.0.2.95
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.95
s=-
c=IN IP4 192.0.2.95
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
This OPTIONS contains an unknown URI scheme in the Request-URI. A parser must accept this as a well-formed SIP request.
此选项在请求URI中包含未知的URI方案。解析器必须将其作为格式良好的SIP请求接受。
An element receiving this request will reject it with a 416 Unsupported URI Scheme response.
接收此请求的元素将使用416不支持的URI方案响应拒绝它。
Some early implementations attempt to look at the contents of the To header field to determine how to route this kind of request. That is an error. Despite the fact that the To header field and the Request URI frequently look alike in simplistic first-hop messages, the To header field contains no routing information.
一些早期的实现试图查看to header字段的内容，以确定如何路由此类请求。这是一个错误。尽管在简单的第一跳消息中，To header字段和请求URI通常看起来很相似，但是To header字段不包含路由信息。
Message Details : unkscm
消息详细信息：unkscm
OPTIONS nobodyKnowsThisScheme:totallyopaquecontent SIP/2.0
To: sip:user@example.com
From: sip:caller@example.net;tag=384
Max-Forwards: 3
Call-ID: unkscm.nasdfasser0q239nwsdfasdkl34
CSeq: 3923423 OPTIONS
Via: SIP/2.0/TCP host9.example.com;branch=z9hG4bKkdjuw39234
Content-Length: 0
OPTIONS nobodyKnowsThisScheme:totallyopaquecontent SIP/2.0
To: sip:user@example.com
From: sip:caller@example.net;tag=384
Max-Forwards: 3
Call-ID: unkscm.nasdfasser0q239nwsdfasdkl34
CSeq: 3923423 OPTIONS
Via: SIP/2.0/TCP host9.example.com;branch=z9hG4bKkdjuw39234
Content-Length: 0
This OPTIONS contains an Request-URI with an IANA-registered scheme that does not commonly appear in Request-URIs of SIP requests. A parser must accept this as a well-formed SIP request.
此选项包含具有IANA注册方案的请求URI，该方案通常不会出现在SIP请求的请求URI中。解析器必须将其作为格式良好的SIP请求接受。
If an element will never accept this scheme as meaningful in a Request-URI, it is appropriate to treat it as unknown and return a 416 Unsupported URI Scheme response. If the element might accept some URIs with this scheme, then a 404 Not Found is appropriate for those URIs it doesn't accept.
如果一个元素永远不会接受这个方案在请求URI中是有意义的，那么应该将它视为未知的，并返回416不支持的URI方案响应。如果元素可能接受此方案中的某些URI，那么404NotFound适合于它不接受的那些URI。
Message Details : novelsc
信息详情：novelsc
OPTIONS soap.beep://192.0.2.103:3002 SIP/2.0
To: sip:user@example.com
From: sip:caller@example.net;tag=384
Max-Forwards: 3
Call-ID: novelsc.asdfasser0q239nwsdfasdkl34
CSeq: 3923423 OPTIONS
Via: SIP/2.0/TCP host9.example.com;branch=z9hG4bKkdjuw39234
Content-Length: 0
OPTIONS soap.beep://192.0.2.103:3002 SIP/2.0
To: sip:user@example.com
From: sip:caller@example.net;tag=384
Max-Forwards: 3
Call-ID: novelsc.asdfasser0q239nwsdfasdkl34
CSeq: 3923423 OPTIONS
Via: SIP/2.0/TCP host9.example.com;branch=z9hG4bKkdjuw39234
Content-Length: 0
This message contains registered schemes in the To, From, and Contact header fields of a request. The message is syntactically valid. Parsers must not fail when receiving this message.
此消息在请求的收件人、发件人和联系人标头字段中包含已注册的方案。该消息在语法上是有效的。解析器在接收此消息时不得失败。
Proxies should treat this message as they would any other request for this URI. A registrar would reject this request with a 400 Bad Request response, since the To: header field is required to contain a SIP or SIPS URI as an AOR.
代理应将此消息视为对此URI的任何其他请求。注册器将以400错误的请求响应拒绝此请求，因为To:header字段需要包含作为AOR的SIP或SIPS URI。
Message Details : unksm2
信息详情：unksm2
REGISTER sip:example.com SIP/2.0
To: isbn:2983792873
From: <http://www.example.com>;tag=3234233
Call-ID: unksm2.daksdj@hyphenated-host.example.com
CSeq: 234902 REGISTER
Max-Forwards: 70
Via: SIP/2.0/UDP 192.0.2.21:5060;branch=z9hG4bKkdjuw
Contact: <name:John_Smith>
l: 0
REGISTER sip:example.com SIP/2.0
To: isbn:2983792873
From: <http://www.example.com>;tag=3234233
Call-ID: unksm2.daksdj@hyphenated-host.example.com
CSeq: 234902 REGISTER
Max-Forwards: 70
Via: SIP/2.0/UDP 192.0.2.21:5060;branch=z9hG4bKkdjuw
Contact: <name:John_Smith>
l: 0
This request tests proper implementation of SIP's Proxy-Require and Require extension mechanisms.
此请求测试SIP的代理请求和请求扩展机制的正确实现。
Any element receiving this request will respond with a 420 Bad Extension response, containing an Unsupported header field listing these features from either the Require or Proxy-Require header field, depending on the role in which the element is responding.
收到此请求的任何元素都将响应420错误扩展响应，其中包含一个不受支持的标头字段，该字段从Require或Proxy Require标头字段中列出这些功能，具体取决于元素响应的角色。
Message Details : bext01
留言：bext01详情
OPTIONS sip:user@example.com SIP/2.0
To: sip:j_user@example.com
From: sip:caller@example.net;tag=242etr
Max-Forwards: 6
Call-ID: bext01.0ha0isndaksdj
Require: nothingSupportsThis, nothingSupportsThisEither
Proxy-Require: noProxiesSupportThis, norDoAnyProxiesSupportThis
CSeq: 8 OPTIONS
Via: SIP/2.0/TLS fold-and-staple.example.com;branch=z9hG4bKkdjuw
Content-Length: 0
OPTIONS sip:user@example.com SIP/2.0
To: sip:j_user@example.com
From: sip:caller@example.net;tag=242etr
Max-Forwards: 6
Call-ID: bext01.0ha0isndaksdj
Require: nothingSupportsThis, nothingSupportsThisEither
Proxy-Require: noProxiesSupportThis, norDoAnyProxiesSupportThis
CSeq: 8 OPTIONS
Via: SIP/2.0/TLS fold-and-staple.example.com;branch=z9hG4bKkdjuw
Content-Length: 0
This INVITE request contains a body of unknown type. It is syntactically valid. A parser must not fail when receiving it.
此INVITE请求包含未知类型的正文。它在语法上是有效的。解析器在接收时不能失败。
A proxy receiving this request would process it just as it would any other INVITE. An endpoint receiving this request would reject it with a 415 Unsupported Media Type error.
接收此请求的代理将像处理任何其他邀请一样对其进行处理。接收此请求的端点将以415不支持的媒体类型错误拒绝该请求。
Message Details : invut
信息详情：invut
INVITE sip:user@example.com SIP/2.0
Contact: <sip:caller@host5.example.net>
To: sip:j.user@example.com
From: sip:caller@example.net;tag=8392034
Max-Forwards: 70
Call-ID: invut.0ha0isndaksdjadsfij34n23d
CSeq: 235448 INVITE
Via: SIP/2.0/UDP somehost.example.com;branch=z9hG4bKkdjuw
Content-Type: application/unknownformat
Content-Length: 40
INVITE sip:user@example.com SIP/2.0
Contact: <sip:caller@host5.example.net>
To: sip:j.user@example.com
From: sip:caller@example.net;tag=8392034
Max-Forwards: 70
Call-ID: invut.0ha0isndaksdjadsfij34n23d
CSeq: 235448 INVITE
Via: SIP/2.0/UDP somehost.example.com;branch=z9hG4bKkdjuw
Content-Type: application/unknownformat
Content-Length: 40
<audio>
<pcmu port="443"/>
</audio>
<audio>
<pcmu port="443"/>
</audio>
This REGISTER request contains an Authorization header field with an unknown scheme. The request is well formed. A parser must not fail when receiving it.
此注册请求包含具有未知方案的授权标头字段。请求的格式很好。解析器在接收时不能失败。
A proxy will treat this request as it would any other REGISTER. If it forwards the request, it will include this Authorization header field unmodified in the forwarded messages.
代理将像对待任何其他注册一样对待此请求。如果它转发请求，它将在转发的消息中包含此未修改的授权标头字段。
A registrar that does not care about challenge-response authentication will simply ignore the Authorization header field, processing this registration as if the field were not present. A registrar that does care about challenge-response authentication will reject this request with a 401, issuing a new challenge with a scheme it understands.
不关心质询-响应身份验证的注册器只会忽略授权标头字段，将该字段视为不存在来处理该注册。关心质询-响应身份验证的注册器将使用401拒绝此请求，并使用其理解的方案发出新质询。
Endpoints choosing not to act as registrars will simply reject the request. A 405 Method Not Allowed is appropriate.
选择不作为注册者的端点将简单地拒绝请求。不允许使用405方法是合适的。
Message Details : regaut01
信息详情：regaut01
REGISTER sip:example.com SIP/2.0
To: sip:j.user@example.com
From: sip:j.user@example.com;tag=87321hj23128
Max-Forwards: 8
Call-ID: regaut01.0ha0isndaksdj
CSeq: 9338 REGISTER
Via: SIP/2.0/TCP 192.0.2.253;branch=z9hG4bKkdjuw
Authorization: NoOneKnowsThisScheme opaque-data=here
Content-Length:0
REGISTER sip:example.com SIP/2.0
To: sip:j.user@example.com
From: sip:j.user@example.com;tag=87321hj23128
Max-Forwards: 8
Call-ID: regaut01.0ha0isndaksdj
CSeq: 9338 REGISTER
Via: SIP/2.0/TCP 192.0.2.253;branch=z9hG4bKkdjuw
Authorization: NoOneKnowsThisScheme opaque-data=here
Content-Length:0
The message contains a request with multiple Call-ID, To, From, Max-Forwards, and CSeq values. An element receiving this request must not break.
消息包含具有多个呼叫ID、To、From、Max FORWARD和CSeq值的请求。接收此请求的元素不得中断。
An element receiving this request would respond with a 400 Bad Request error.
接收此请求的元素将响应400错误请求错误。
Message Details : multi01
信息详情：multi01
INVITE sip:user@company.com SIP/2.0
Contact: <sip:caller@host25.example.net>
Via: SIP/2.0/UDP 192.0.2.25;branch=z9hG4bKkdjuw
Max-Forwards: 70
CSeq: 5 INVITE
Call-ID: multi01.98asdh@192.0.2.1
CSeq: 59 INVITE
Call-ID: multi01.98asdh@192.0.2.2
From: sip:caller@example.com;tag=3413415
To: sip:user@example.com
To: sip:other@example.net
From: sip:caller@example.net;tag=2923420123
Content-Type: application/sdp
l: 154
Contact: <sip:caller@host36.example.net>
Max-Forwards: 5
INVITE sip:user@company.com SIP/2.0
Contact: <sip:caller@host25.example.net>
Via: SIP/2.0/UDP 192.0.2.25;branch=z9hG4bKkdjuw
Max-Forwards: 70
CSeq: 5 INVITE
Call-ID: multi01.98asdh@192.0.2.1
CSeq: 59 INVITE
Call-ID: multi01.98asdh@192.0.2.2
From: sip:caller@example.com;tag=3413415
To: sip:user@example.com
To: sip:other@example.net
From: sip:caller@example.net;tag=2923420123
Content-Type: application/sdp
l: 154
Contact: <sip:caller@host36.example.net>
Max-Forwards: 5
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.25
s=-
c=IN IP4 192.0.2.25
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.25
s=-
c=IN IP4 192.0.2.25
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
Multiple conflicting Content-Length header field values appear in this request.
此请求中出现多个冲突的内容长度标头字段值。
From a framing perspective, this situation is equivalent to an invalid Content-Length value (or no value at all).
从框架的角度来看，这种情况相当于无效的内容长度值（或者根本没有值）。
An element receiving this message should respond with an error. This request appeared over UDP, so the remainder of the datagram can simply be discarded. If a request like this arrives over TCP, the framing error is not recoverable, and the connection should be closed.
接收此消息的元素应以错误响应。此请求是通过UDP出现的，因此可以简单地丢弃数据报的其余部分。如果这样的请求通过TCP到达，则帧错误是不可恢复的，连接应该关闭。
Message Details : mcl01
信息详情：mcl01
OPTIONS sip:user@example.com SIP/2.0
Via: SIP/2.0/UDP host5.example.net;branch=z9hG4bK293423
To: sip:user@example.com
From: sip:other@example.net;tag=3923942
Call-ID: mcl01.fhn2323orihawfdoa3o4r52o3irsdf
CSeq: 15932 OPTIONS
Content-Length: 13
Max-Forwards: 60
Content-Length: 5
Content-Type: text/plain
OPTIONS sip:user@example.com SIP/2.0
Via: SIP/2.0/UDP host5.example.net;branch=z9hG4bK293423
To: sip:user@example.com
From: sip:other@example.net;tag=3923942
Call-ID: mcl01.fhn2323orihawfdoa3o4r52o3irsdf
CSeq: 15932 OPTIONS
Content-Length: 13
Max-Forwards: 60
Content-Length: 5
Content-Type: text/plain
There's no way to know how many octets are supposed to be here.
没有办法知道这里应该有多少个八位组。
This message is a response with a 2nd Via header field value's sent-by containing 255.255.255.255. The message is well formed; parsers must not fail when receiving it.
此消息是包含255.255.255.255的第二个Via头字段值的响应。信息格式正确；解析器在接收时不能失败。
Per [RFC3261], an endpoint receiving this message should simply discard it.
根据[RFC3261]，接收此消息的端点只需丢弃它即可。
If a proxy followed normal response processing rules blindly, it would forward this response to the broadcast address. To protect against this as an avenue of attack, proxies should drop such responses.
如果代理盲目遵循正常的响应处理规则，它会将此响应转发到广播地址。为了防止这种攻击，代理应该放弃这种响应。
Message Details : bcast
消息详细信息：bcast
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.198;branch=z9hG4bK1324923
Via: SIP/2.0/UDP 255.255.255.255;branch=z9hG4bK1saber23
Call-ID: bcast.0384840201234ksdfak3j2erwedfsASdf
CSeq: 35 INVITE
From: sip:user@example.com;tag=11141343
To: sip:user@example.edu;tag=2229
Content-Length: 154
Content-Type: application/sdp
Contact: <sip:user@host28.example.com>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.198;branch=z9hG4bK1324923
Via: SIP/2.0/UDP 255.255.255.255;branch=z9hG4bK1saber23
Call-ID: bcast.0384840201234ksdfak3j2erwedfsASdf
CSeq: 35 INVITE
From: sip:user@example.com;tag=11141343
To: sip:user@example.edu;tag=2229
Content-Length: 154
Content-Type: application/sdp
Contact: <sip:user@host28.example.com>
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.198
s=-
c=IN IP4 192.0.2.198
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.198
s=-
c=IN IP4 192.0.2.198
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
This is a legal SIP request with the Max-Forwards header field value set to zero.
这是一个合法的SIP请求，最大转发头字段值设置为零。
A proxy should not forward the request and should respond 483 (Too Many Hops). An endpoint should process the request as if the Max-Forwards field value were still positive.
代理不应转发请求，而应响应483（跳数过多）。如果请求端点仍为正值，则“最大值”字段仍为“转发”。
Message Details : zeromf
信息详情：zeromf
OPTIONS sip:user@example.com SIP/2.0
To: sip:user@example.com
From: sip:caller@example.net;tag=3ghsd41
Call-ID: zeromf.jfasdlfnm2o2l43r5u0asdfas
CSeq: 39234321 OPTIONS
Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bKkdjuw2349i
Max-Forwards: 0
Content-Length: 0
OPTIONS sip:user@example.com SIP/2.0
To: sip:user@example.com
From: sip:caller@example.net;tag=3ghsd41
Call-ID: zeromf.jfasdlfnm2o2l43r5u0asdfas
CSeq: 39234321 OPTIONS
Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bKkdjuw2349i
Max-Forwards: 0
Content-Length: 0
This register request contains a contact where the 'unknownparam' parameter must be interpreted as a contact-param and not a url-param.
此注册请求包含一个联系人，其中“unknownparam”参数必须解释为联系人参数，而不是url参数。
This REGISTER should succeed. The response must not include "unknownparam" as a url-parameter for this binding. Likewise, "unknownparam" must not appear as a url-parameter in any binding during subsequent fetches.
这次登记应该成功。响应不能包含“unknownparam”作为此绑定的url参数。同样，“unknownparam”在后续获取期间不得作为url参数出现在任何绑定中。
Behavior is the same, of course, for any known contact-param parameter names.
当然，对于任何已知的contact param参数名称，行为都是相同的。
Message Details : cparam01
消息详细信息：cparam01
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP saturn.example.com:5060;branch=z9hG4bKkdjuw
Max-Forwards: 70
From: sip:watson@example.com;tag=DkfVgjkrtMwaerKKpe
To: sip:watson@example.com
Call-ID: cparam01.70710@saturn.example.com
CSeq: 2 REGISTER
Contact: sip:+19725552222@gw1.example.net;unknownparam
l: 0
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP saturn.example.com:5060;branch=z9hG4bKkdjuw
Max-Forwards: 70
From: sip:watson@example.com;tag=DkfVgjkrtMwaerKKpe
To: sip:watson@example.com
Call-ID: cparam01.70710@saturn.example.com
CSeq: 2 REGISTER
Contact: sip:+19725552222@gw1.example.net;unknownparam
l: 0
This register request contains a contact where the URI has an unknown parameter.
此注册请求包含URI具有未知参数的联系人。
The register should succeed, and a subsequent retrieval of the registration must include "unknownparam" as a url-parameter.
注册应该成功，后续的注册检索必须包含“unknownparam”作为url参数。
Behavior is the same, of course, for any known url-parameter names.
当然，对于任何已知的url参数名称，行为都是相同的。
Message Details : cparam02
消息详情：cparam02
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP saturn.example.com:5060;branch=z9hG4bKkdjuw
Max-Forwards: 70
From: sip:watson@example.com;tag=838293
To: sip:watson@example.com
Call-ID: cparam02.70710@saturn.example.com
CSeq: 3 REGISTER
Contact: <sip:+19725552222@gw1.example.net;unknownparam>
l: 0
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP saturn.example.com:5060;branch=z9hG4bKkdjuw
Max-Forwards: 70
From: sip:watson@example.com;tag=838293
To: sip:watson@example.com
Call-ID: cparam02.70710@saturn.example.com
CSeq: 3 REGISTER
Contact: <sip:+19725552222@gw1.example.net;unknownparam>
l: 0
This register request contains a contact where the URI has an escaped header.
此注册请求包含URI具有转义头的联系人。
The register should succeed, and a subsequent retrieval of the registration must include the escaped Route header in the contact URI for this binding.
注册应该成功，并且注册的后续检索必须在该绑定的联系人URI中包含转义路由头。
Message Details : regescrt
消息详细信息：regescrt
REGISTER sip:example.com SIP/2.0
To: sip:user@example.com
From: sip:user@example.com;tag=8
Max-Forwards: 70
Call-ID: regescrt.k345asrl3fdbv@192.0.2.1
CSeq: 14398234 REGISTER
Via: SIP/2.0/UDP host5.example.com;branch=z9hG4bKkdjuw
M: <sip:user@example.com?Route=%3Csip:sip.example.com%3E>
L:0
REGISTER sip:example.com SIP/2.0
To: sip:user@example.com
From: sip:user@example.com;tag=8
Max-Forwards: 70
Call-ID: regescrt.k345asrl3fdbv@192.0.2.1
CSeq: 14398234 REGISTER
Via: SIP/2.0/UDP host5.example.com;branch=z9hG4bKkdjuw
M: <sip:user@example.com?Route=%3Csip:sip.example.com%3E>
L:0
This request indicates that the response must contain a body in an unknown type. In particular, since the Accept header field does not contain application/sdp, the response may not contain an SDP body. The recipient of this request could respond with a 406 Not Acceptable, with a Warning/399 indicating that a response cannot be formulated in the formats offered in the Accept header field. It is also appropriate to respond with a 400 Bad Request, since all SIP User-Agents (UAs) supporting INVITE are required to support application/sdp.
此请求表示响应必须包含未知类型的正文。特别是，由于Accept header字段不包含application/sdp，因此响应可能不包含sdp正文。此请求的接收者可以使用“406不可接受”进行响应，并显示一条警告/399，指示无法按照“接受标头”字段中提供的格式制定响应。由于支持INVITE的所有SIP用户代理（UAs）都需要支持应用程序/sdp，因此使用400错误请求进行响应也是合适的。
Message Details : sdp01
信息详情：sdp01
INVITE sip:user@example.com SIP/2.0
To: sip:j_user@example.com
Contact: <sip:caller@host15.example.net>
From: sip:caller@example.net;tag=234
Max-Forwards: 5
Call-ID: sdp01.ndaksdj9342dasdd
Accept: text/nobodyKnowsThis
CSeq: 8 INVITE
Via: SIP/2.0/UDP 192.0.2.15;branch=z9hG4bKkdjuw
Content-Length: 150
Content-Type: application/sdp
INVITE sip:user@example.com SIP/2.0
To: sip:j_user@example.com
Contact: <sip:caller@host15.example.net>
From: sip:caller@example.net;tag=234
Max-Forwards: 5
Call-ID: sdp01.ndaksdj9342dasdd
Accept: text/nobodyKnowsThis
CSeq: 8 INVITE
Via: SIP/2.0/UDP 192.0.2.15;branch=z9hG4bKkdjuw
Content-Length: 150
Content-Type: application/sdp
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.5
s=-
c=IN IP4 192.0.2.5
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.5
s=-
c=IN IP4 192.0.2.5
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
This is a legal message per RFC 2543 (and several bis versions) that should be accepted by RFC 3261 elements that want to maintain backwards compatibility.
这是一条符合RFC 2543（和几个bis版本）的法律消息，希望保持向后兼容性的RFC 3261元素应接受该消息。
o There is no branch parameter at all on the Via header field value.
o Via标头字段值上根本没有分支参数。
o There is no From tag.
o 没有来自标签。
o There is no explicit Content-Length. (The body is assumed to be all octets in the datagram after the null-line.)
o 没有明确的内容长度。（假设主体是空行之后数据报中的所有八位字节。）
o There is no Max-Forwards header field.
o 没有“最大转发头”字段。
Message Details : inv2543
信息详情：inv2543
INVITE sip:UserB@example.com SIP/2.0
Via: SIP/2.0/UDP iftgw.example.com
From: <sip:+13035551111@ift.client.example.net;user=phone>
Record-Route: <sip:UserB@example.com;maddr=ss1.example.com>
To: sip:+16505552222@ss1.example.net;user=phone
Call-ID: inv2543.1717@ift.client.example.com
CSeq: 56 INVITE
Content-Type: application/sdp
INVITE sip:UserB@example.com SIP/2.0
Via: SIP/2.0/UDP iftgw.example.com
From: <sip:+13035551111@ift.client.example.net;user=phone>
Record-Route: <sip:UserB@example.com;maddr=ss1.example.com>
To: sip:+16505552222@ss1.example.net;user=phone
Call-ID: inv2543.1717@ift.client.example.com
CSeq: 56 INVITE
Content-Type: application/sdp
v=0 o=mhandley 29739 7272939 IN IP4 192.0.2.5 s=- c=IN IP4 192.0.2.5 t=0 0 m=audio 49217 RTP/AVP 0
v=0 o=mhandley 29739 7272939在IP4 192.0.2.5中s=-c=IP4 192.0.2.5中t=0 0 m=音频49217 RTP/AVP 0
This document presents NON-NORMATIVE examples of SIP session establishment. The security considerations in [RFC3261] apply.
本文件介绍了SIP会话建立的非规范性示例。[RFC3261]中的安全注意事项适用。
Parsers must carefully consider edge conditions and malicious input as part of their design. Attacks on many Internet systems use crafted input to cause implementations to behave in undesirable ways. Many of the messages in this document are designed to stress a parser implementation at points traditionally used for such attacks. However, this document does not attempt to be comprehensive. It should be considered a seed to stimulate thinking and planning, not simply a set of tests to be passed.
解析器必须仔细考虑边缘条件和恶意输入作为其设计的一部分。对许多Internet系统的攻击使用精心编制的输入，导致实现以不希望的方式运行。本文档中的许多消息旨在强调传统上用于此类攻击的解析器实现。然而，本文件并不试图全面。它应该被视为激发思考和计划的种子，而不仅仅是要通过的一系列测试。
The final detailed review of this document was performed by Diego Besprosvan, Vijay Gurbani, Shashi Kumar, Derek MacDonald, Gautham Narasimhan, Nils Ohlmeier, Bob Penfield, Reinaldo Penno, Marc Petit-Huguenin, Richard Sugarman, and Venkatesh Venkataramanan.
本文件的最终详细审查由迭戈·贝斯普洛斯万、维杰·古巴尼、沙希·库马尔、德里克·麦克唐纳、高塔姆·纳拉西姆汉、尼尔斯·奥尔梅尔、鲍勃·彭菲尔德、雷纳尔多·佩诺、马克·佩蒂特·胡格宁、理查德·苏格曼和文卡特什·文卡塔拉马南执行。
Earlier versions of this document were reviewed by Aseem Agarwal, Rafi Assadi, Gonzalo Camarillo, Ben Campbell, Cullen Jennings, Vijay Gurbani, Sunitha Kumar, Rohan Mahy, Jon Peterson, Marc Petit-Huguenin, Vidhi Rastogi, Adam Roach, Bodgey Yin Shaohua, and Tom Taylor.
阿塞姆·阿加瓦尔（Aseem Agarwal）、拉菲·阿萨迪（Rafi Assadi）、冈萨洛·卡马里洛（Gonzalo Camarillo）、本·坎贝尔（Ben Campbell）、卡伦·詹宁斯（Cullen Jennings）、维杰·古巴尼（Vijay Gurbani）、苏尼莎·库马尔（Sunitha Kumar）、罗汉·马伊（Rohan Mahy）、乔恩·彼得森（Jon Peterson）、马克·佩蒂·胡格宁（。
Thanks to Cullen Jennings and Eric Rescorla for their contribution to the multipart/mime sections of this document and their work constructing S/MIME examples in [SIP-SEC]. Thanks to Neil Deason for contributing several messages and to Kundan Singh for performing parser validation of messages in earlier versions.
感谢Cullen Jennings和Eric Rescorla对本文档多部分/mime部分的贡献，以及他们在[SIP-SEC]中构建S/mime示例的工作。感谢Neil Deason贡献了几条消息，感谢Kundan Singh在早期版本中对消息执行解析器验证。
The following individuals provided significant comments during the early phases of the development of this document: Jean-Francois Mule, Hemant Agrawal, Henry Sinnreich, David Devanatham, Joe Pizzimenti, Matt Cannon, John Hearty, the whole MCI IPOP Design team, Scott Orton, Greg Osterhout, Pat Sollee, Doug Weisenberg, Danny Mistry, Steve McKinnon, and Denise Ingram, Denise Caballero, Tom Redman, Ilya Slain, Pat Sollee, John Truetken, and others from MCI, 3Com, Cisco, Lucent, and Nortel.
以下人员在本文件编制的早期阶段提供了重要意见：Jean-Francois Mule、Hemant Agrawal、Henry Sinnreich、David Devanatham、Joe Pizzimenti、Matt Cannon、John Hardy、整个MCI IPOP设计团队、Scott Orton、Greg Osterhout、Pat Sollee、Doug Weisenberg、Danny Mistry、Steve McKinnon、，丹尼斯·英格拉姆、丹尼斯·卡巴莱罗、汤姆·雷德曼、伊利亚·斯莱恩、帕特·索尔利、约翰·特鲁特肯以及来自MCI、3Com、思科、朗讯和北电的其他人。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[SIP-SEC] Jennings, C. and K. Ono, "Example call flows using SIP security mechanisms", Work in Progress, July 2005.
[SIP-SEC]Jennings，C.和K.Ono，“使用SIP安全机制的示例呼叫流”，正在进行的工作，2005年7月。
The following text block is an encoded, gzip-compressed TAR archive of files that represent each of the example messages discussed in Section 3.
下面的文本块是一个编码的、gzip压缩的TAR归档文件，表示第3节中讨论的每个示例消息。
To recover the compressed archive file intact, the text of this document may be passed as input to the following Perl script (the output should be redirected to a file or piped to "tar -xzvf -").
要完整地恢复压缩的归档文件，可以将本文档的文本作为输入传递给以下Perl脚本（输出应重定向到文件或通过管道传输到“tar-xzvf-”）。
#!/usr/bin/perl
use strict;
my $bdata = "";
use MIME::Base64;
while(<>) {
if (/-- BEGIN MESSAGE ARCHIVE --/ .. /-- END MESSAGE ARCHIVE --/) {
if ( m/^\s*[^\s]+\s*$/) {
$bdata = $bdata . $_;
}
}
}
print decode_base64($bdata);
#!/usr/bin/perl
use strict;
my $bdata = "";
use MIME::Base64;
while(<>) {
if (/-- BEGIN MESSAGE ARCHIVE --/ .. /-- END MESSAGE ARCHIVE --/) {
if ( m/^\s*[^\s]+\s*$/) {
$bdata = $bdata . $_;
}
}
}
print decode_base64($bdata);
Figure 58
图58
Alternatively, the base-64 encoded block can be edited by hand to remove document structure lines and fed as input to any base-64 decoding utility.
或者，可以手动编辑base-64编码块以移除文档结构行，并将其作为输入馈送到任何base-64解码实用程序。
-- BEGIN MESSAGE ARCHIVE --
H4sIAEDwcEMCA+xdW2zc2Hm2nexNG6UN3LRF0QfaiKJdyxwdnkMOhyOPVrIt
27It22tdvHYTeM8MDzWc4ZAjkqORvK2bbIAAedmHtEHRdlvkoUCLFAjSlyLF
9rJPLYoWrTdAg6JFHwp0i+5D0SIoEAQFuj2HnAuH5GgoW3PxmgcazYU/b4f/
//3Xc04Rq9ipk1JGxe6xITVAW1YUvXc5K/W8syYheEygP0lIECWJ0gkSkMAx
DhwbQWs4LrY57phdcerYrjr96AZtb91L5/0paTdvbazevLHOOXo933CIvUT2
cK1ukIxlb3Prq7fmYQZMT23pON/+Nr958RZXthxXzLRpS1YtL4EsWCja2CyV
Cw+U8mWxeK2qVhoigkicnlrDe/wly25iW3XynEwPecmmO3GnzxPDOMstG/RQ
pkrs09w5diU4s50p0i1LgTMsLrh4uyAiJEI0PbVh0Z3vYNexzLPcRtmqYYfu
692Gm2l6v/fcyuL01AVsGPzqxTxXbPO8o2qAXp4JTdUBGChKA6IyKptmEwCl
pFZNQs+0XCqRupvncL1u6CXs6pY576h1erx1spPnkALpLSpcqyOnp4w8R29v
eurpeP60L/yHNkQAGCT/IsiG5R8KMJX/sco/lbiu/DNpi6NoizHbVqLi1Ysf
nsAiBEUYBgAUAymCQj9lYEYIochBEhiQ6BYXO1i1TM2CSBchqOwC7AAKKxqq
ILMtsbmnVVaHJP9U8Mkw1f8g+RcAFI+xf6IIBJRFVP7FbDbV/yNpqze2VjdW
jl78TeJ64g+pflWYwo5aAEHp9XiQqlGq22smlWEqsBAZFRHyvENUzax5VoQv
vwJVuQoSOf/S+xgnQdskxixpTk9dpKfMc5ds/SwHBO4qNjlIWZETsnkA6B+3
sr5Bz2iZLi5R7DkXuEd2fCkTuNNFn5CYLr+xXydxSNXafJ2Y226Z3oPk4c5u
gb5ZhVqZGj8G2eegIlNTQoYyvUGF3iC3ekvsAKM0PeUU+OmpUiG6wS0AhmS1
Am6ousXRLhdk7vbGrfnlrVscvSnItu3qKrE4BGF3ExKmp3DBdus1XM8jgbt+
68KzjIbPJv6bQ0X/BP6fgEL2n4gkKcX/Udt/sY5Trw/IWhBqS0l8wGYY/b3W
dQJpC7mBg71AXyl5rdcL9HeNu5WQC0jZnvKbIC313MNAf4+2Pi7f0yr/urkL
hHHGf2QEwvafDFAq/xNn/1Uyj2EBCkgUstSiF6CYjZiBvSLpcyIoY6A7poqr
jlrBDrUFWYwGO13/ra/l1/EhpYWFswtnzwYMuNNXLdKKLlUs0oMLC7TFmWhw
oFl3SAtO6GvCCeOy4Wiv7xLbGaf/B0QxqP8lT/5RNpX/idH/ckT/y3H6P6nq
79H8yxlP+Q/S+DtNYuk7dRLQ+xuZlupPrPI9TmdKXw4r/Y5uF56x4FCxhKmz
PFb7n4p+JP6Dsqn8j6S1tCcHAeBuXjtIpSq5kHwLCPqhncg+UJIygVd4PwcX
ic127Mqmx4UA5cScCCAQqMKnyl/DVVSBxG4SVXOW11Wtk3OROiZA1/wImya+
8SFQaUdtdyFCRtRGK0oFlTgLQEwU2OkGiLyDs/AQzAXxZfHwloKS62sqsE1p
vCdtR4P/ZM8drveXIP4jS2H7T4RCiv+Tl/+r3H+cFIAIiWuHDcFsEP59Juxx
/KanbpOdhm5T0DUtt6yb2+uNet2yXWejrDtn435c0d0yoSe6ZVt7+3xgd/aD
TpwWbXt/+6K1bO5Ht8XkCXs03Mb1dU6zDJWnQM5T7vEUySArOKxbJsWyLOrb
JUsda/4PSIIY8f/S+M9o7T8RKqKSlREQqDS6LrGZgHFFm+AqR6WKs0mJ6LtM
uvpbiCBs6UGk5Kg4WyQo6y2Gw45qaahRgQDRj6aG6BU06Keyhh1Eyl7gBzuK
3rX5kKiIIbvvXBxs+Q4jUrDpaHrL8jsXZ/r5hAqAFVM1q6zWJ0ZK+xh49GYj
Ft7TqP9LFLHtMed/5CwM+3/UaE/lf2Liv72aO/ekEWGF5fnpPwv2S7A3zG17
P5xhbyOIz7I9xkKT6JiihVpFCYLEven7qMbmWX5H5CGSIDp0Yl+h7THiwgcE
hocbGS5Rpsa18eZ/JCBE9b+cyv8o2u2Vy6vrGyu3PXmNFf6I/DjYbdjmYyV+
u5FfdrpQvLYds7lY1ba2K1XbXWtiYl+71g76xu8SBIY2L1PuEcBS9Drb4AC5
9m0HAIgdfk5QZEhZENK2tN0UghC00DCrptU0vZN8YqLDrT6D45R/MStH5B+m
+v9Zlf8cylEleTiZhwNlHsXJ/LlDCf3iJzAnpBYNm+yMNf4nICkbtv+ltP5r
UuQ/makf3doq1IKSUEEVBCODgHLTU6t5rsV/Pda8ojDfXzMNZFQhQqIAQ2q6
dbJwnW/X9u+Kev9oBZTiEMsrV+4TrqMX3PWWgkUkPf3Vvsbe7UkKZajTi+K6
qQN24c5SZJnKleJJ01KwlOQwhTIxnYBywK+3Hn5R85OXxHCJPZ800xVtxCkN
O/0zOP+P5DD+wzT+M/L4D305M2iZQeuMCALYFUSqqF6YkSWHzMgwDu08+2p1
BlLE2iX0jXZhiTjB47VisCgXwT15ekrPcz5/spEhQPFCwtVK1YTIMukXwKPA
sBDIBoaKScM+DHTjEzUHJPmnp7hOnGomeyFuKMgC/Z12xoI5kxVqpLBL34wG
-- BEGIN MESSAGE ARCHIVE --
H4sIAEDwcEMCA+xdW2zc2Hm2nexNG6UN3LRF0QfaiKJdyxwdnkMOhyOPVrIt
27It22tdvHYTeM8MDzWc4ZAjkqORvK2bbIAAedmHtEHRdlvkoUCLFAjSlyLF
9rJPLYoWrTdAg6JFHwp0i+5D0SIoEAQFuj2HnAuH5GgoW3PxmgcazYU/b4f/
//3Xc04Rq9ipk1JGxe6xITVAW1YUvXc5K/W8syYheEygP0lIECWJ0gkSkMAx
DhwbQWs4LrY57phdcerYrjr96AZtb91L5/0paTdvbazevLHOOXo933CIvUT2
cK1ukIxlb3Prq7fmYQZMT23pON/+Nr958RZXthxXzLRpS1YtL4EsWCja2CyV
Cw+U8mWxeK2qVhoigkicnlrDe/wly25iW3XynEwPecmmO3GnzxPDOMstG/RQ
pkrs09w5diU4s50p0i1LgTMsLrh4uyAiJEI0PbVh0Z3vYNexzLPcRtmqYYfu
692Gm2l6v/fcyuL01AVsGPzqxTxXbPO8o2qAXp4JTdUBGChKA6IyKptmEwCl
pFZNQs+0XCqRupvncL1u6CXs6pY576h1erx1spPnkALpLSpcqyOnp4w8R29v
eurpeP60L/yHNkQAGCT/IsiG5R8KMJX/sco/lbiu/DNpi6NoizHbVqLi1Ysf
nsAiBEUYBgAUAymCQj9lYEYIochBEhiQ6BYXO1i1TM2CSBchqOwC7AAKKxqq
ILMtsbmnVVaHJP9U8Mkw1f8g+RcAFI+xf6IIBJRFVP7FbDbV/yNpqze2VjdW
jl78TeJ64g+pflWYwo5aAEHp9XiQqlGq22smlWEqsBAZFRHyvENUzax5VoQv
vwJVuQoSOf/S+xgnQdskxixpTk9dpKfMc5ds/SwHBO4qNjlIWZETsnkA6B+3
sr5Bz2iZLi5R7DkXuEd2fCkTuNNFn5CYLr+xXydxSNXafJ2Y226Z3oPk4c5u
gb5ZhVqZGj8G2eegIlNTQoYyvUGF3iC3ekvsAKM0PeUU+OmpUiG6wS0AhmS1
Am6ousXRLhdk7vbGrfnlrVscvSnItu3qKrE4BGF3ExKmp3DBdus1XM8jgbt+
68KzjIbPJv6bQ0X/BP6fgEL2n4gkKcX/Udt/sY5Trw/IWhBqS0l8wGYY/b3W
dQJpC7mBg71AXyl5rdcL9HeNu5WQC0jZnvKbIC313MNAf4+2Pi7f0yr/urkL
hHHGf2QEwvafDFAq/xNn/1Uyj2EBCkgUstSiF6CYjZiBvSLpcyIoY6A7poqr
jlrBDrUFWYwGO13/ra/l1/EhpYWFswtnzwYMuNNXLdKKLlUs0oMLC7TFmWhw
oFl3SAtO6GvCCeOy4Wiv7xLbGaf/B0QxqP8lT/5RNpX/idH/ckT/y3H6P6nq
79H8yxlP+Q/S+DtNYuk7dRLQ+xuZlupPrPI9TmdKXw4r/Y5uF56x4FCxhKmz
PFb7n4p+JP6Dsqn8j6S1tCcHAeBuXjtIpSq5kHwLCPqhncg+UJIygVd4PwcX
ic127Mqmx4UA5cScCCAQqMKnyl/DVVSBxG4SVXOW11Wtk3OROiZA1/wImya+
8SFQaUdtdyFCRtRGK0oFlTgLQEwU2OkGiLyDs/AQzAXxZfHwloKS62sqsE1p
vCdtR4P/ZM8drveXIP4jS2H7T4RCiv+Tl/+r3H+cFIAIiWuHDcFsEP59Juxx
/KanbpOdhm5T0DUtt6yb2+uNet2yXWejrDtn435c0d0yoSe6ZVt7+3xgd/aD
TpwWbXt/+6K1bO5Ht8XkCXs03Mb1dU6zDJWnQM5T7vEUySArOKxbJsWyLOrb
JUsda/4PSIIY8f/S+M9o7T8RKqKSlREQqDS6LrGZgHFFm+AqR6WKs0mJ6LtM
uvpbiCBs6UGk5Kg4WyQo6y2Gw45qaahRgQDRj6aG6BU06Keyhh1Eyl7gBzuK
3rX5kKiIIbvvXBxs+Q4jUrDpaHrL8jsXZ/r5hAqAFVM1q6zWJ0ZK+xh49GYj
Ft7TqP9LFLHtMed/5CwM+3/UaE/lf2Liv72aO/ekEWGF5fnpPwv2S7A3zG17
P5xhbyOIz7I9xkKT6JiihVpFCYLEven7qMbmWX5H5CGSIDp0Yl+h7THiwgcE
hocbGS5Rpsa18eZ/JCBE9b+cyv8o2u2Vy6vrGyu3PXmNFf6I/DjYbdjmYyV+
u5FfdrpQvLYds7lY1ba2K1XbXWtiYl+71g76xu8SBIY2L1PuEcBS9Drb4AC5
9m0HAIgdfk5QZEhZENK2tN0UghC00DCrptU0vZN8YqLDrT6D45R/MStH5B+m
+v9Zlf8cylEleTiZhwNlHsXJ/LlDCf3iJzAnpBYNm+yMNf4nICkbtv+ltP5r
UuQ/makf3doq1IKSUEEVBCODgHLTU6t5rsV/Pda8ojDfXzMNZFQhQqIAQ2q6
dbJwnW/X9u+Kev9oBZTiEMsrV+4TrqMX3PWWgkUkPf3Vvsbe7UkKZajTi+K6
qQN24c5SZJnKleJJ01KwlOQwhTIxnYBywK+3Hn5R85OXxHCJPZ800xVtxCkN
O/0zOP+P5DD+wzT+M/L4D305M2iZQeuMCALYFUSqqF6YkSWHzMgwDu08+2p1
BlLE2iX0jXZhiTjB47VisCgXwT15ekrPcz5/spEhQPFCwtVK1YTIMukXwKPA
sBDIBoaKScM+DHTjEzUHJPmnp7hOnGomeyFuKMgC/Z12xoI5kxVqpLBL34wG
vXVpBokzSFg8ItTsC5ppaUDaDov/cMzx/2zU/6eSnOL/aOz/GVGmtvKMKPk+
gE22dce1sZ3p6w2cnrlHyVvF1DZxrIZd6jF2FzvD+wdSevCvQQQrWNUqPUVh
Pmsy0Dd3mhYS7R2IdCRWbJYbLJkGRKZtVE2H1YX1JugvDBwDCIEyoz1wTGIE
NYiCRJEL9kjssMWe4AE2dOwIfkowlBC8MJO9FCGFfnlYmDR6TOQRohDhkccf
aCebDcMYb/5fjMb/sun4/wnz/xmb8DMA8OxDP9e2L1Ersqco0J+/44DhwG2W
RAoEyFS13WpFxY5W3UFN0XLtHYBVR6OggHfVzpBgESk5Zv0d4PgPSvsFCnW6
okhvZSmy42IMVT/C6/nJjhfSzrYbtj7e8f9iJP4nS6n+H7X/Fw7gvXbbarik
MIMuhLBhBq0cydwASBQkIRc3JqzfqHsPP/rVBbRZ2XMWeWY3lCs8rhBUtHmK
DTtAyTV5DTeJXYY7fFk0pS58UKihyh8e7D3ylsa7ZcKXqRmTvOJvmMGz1A1M
25M13XQa2pj9PzEbGf8rpvnfseN/F+NbKOnVbQ3OKSgxOYWMx2cDQdFoDbs9
JA4qfZMISjo3yiD5d2vELY/V/oM99V9Z3/5L/b+RtFOUAYhNHFc3t/k1ygmW
6g2/k7JyTrl/Zu7NzIxuqoSosw89kBDuN8yG08BGZvP26sNXXIsvklNOwyav
flF3zFl3Tne/MF+y8YP9187OLyycyX9Rd+fK2CkIZ5tEt9VTZ+rY+ULTeqje
dy0r84pqEbYbr7uvLg0uP2lHdoSDyjczp2ay2TP3596cfdiKV51fuZ7/0gvc
jU36doy7yL79aisoddj7iQ1zuVaVmMLDN/0PcHbuvv8JnZk5leH9E9UaporN
UPBLo7vfYqUls7MP587cp8QzhdMffOXR9x790aM//+DtR9/74J0PvvHo+4/+
5LRnMN/3jvpQmJ17kx6ZzwSM37YcNy1bnbl3jT+VoT0wu8S+vvnw1VcWz+W/
NH/6y7/02q+8FZhGS4AQ5STuEDwQNtYhK08lexTTHQriVwhWiU3PPXNm7j7t
/vx/vfcXH/7e73/41Xc/+u33JncMzLNt/+1CSURjjf9lvfF/IfsvHf83avtv
k9p/55eS1QDqmrvdzPTL+M4JCCBJkgTalihppmToVPB7C+vo2Qr1smWSRTbU
r0SBivcCDq1jRK5moYZV1S44TjjO3o5AzAlZCbTr+IJkvafrAU2f+QVZkOOu
M1BTJGU7hu/Rzgnz+LP6HQl20i5ouOPO/wE5bP+J6fyfk+T/JZ0F84mGBeW8
gL94YG7AZ9feGaJUR9MrbBZvpHZrQSRRPKD8zbFqJNksof2FvVUZrFl2DbtR
40b0rJtznuTSnuHO1Uu1BsfGGBdOiyI6PU9/PDff3jy2529Y5vawC4AHyH82
K6NI/D/N/02Q/HtO1CrHirg4zDE6zsQ1wlkaR21/m9TIE75xddtiokHl6nTs
mN58lvZpTzG+UNgl9j5j36N87WKjQRbYJ+8k7C6H/So4ZXrn/omHcUtxL8/n
JNTpu0Hf7uhu+Ya1xS6AebQ+RuMafkDdQcO7HB+w2cUO8+doQTRUcpP4J0Kx
zYplz+MdCq8U/FMEzuDxyNH8a1+/99QN4jidWzjyDwHt3VY21Aq3Cf1xf/T/
2yynd2wFlGOVA6BjLGz6PcNfp5RH+eKZrOW5VsfzRy3SvP9ch3f8ehszeA/7
C6M4k3dPMTFAilAI9bppu1EK2EuxFaUQQhRx5wFhmuUIDVRCNKvR4/TOCMZo
Yo4jh+4p5npgNkwTcxwpRBN3PWKYJuY4oT7e4vJchCbUy7txNOF+5rjouUD4
OFEaQYk8rxiiXJQohkoe/OiFbAIaKQGNmIAGJaCBCWgSsLQABtMog0lyg0kS
dHKCPk7QxQl6OEEHJ+nfASQRr7I1cY5a6MR12o7mqIy9Ubz8W2rB9cCa2THY
lo+xZofxLBTlGO62O+wCwIHz/0Tmf5WEtP5vpP5//ERaR1Plp0BFiOQNg4X+
HR4UlgLB71aWcnC9iTTMZXqUIw7oI0FUEMzJYEKAwGg6qu7Ux5r/QzKL/7OB
3jKbDNqP/6X1XyNpR7P+ny9x52JQoDsf34Cq/zYjssIDXCypSxr1L/fjUnFZ
0GdiTgYKkb3iw/rpwn9d+R9//T8K5/8lANL5P8Yd/1/gDHswBPjCvacRXqFK
LJdD/ANFSzIrMPJnZo/k+6ReUPC4058MVLWIpbOll7zi/qZt+p9ySLSr3qCi
VvJPQNSkzIooQa2q0HfqIoiUgwwLYfSGxcGOxaQZFml7WvCfAaA7Vv9PhhH/
T07rP0aJ//H2X98ZYJ/IIczlBLEX41scqFXNHWr9UYwXEVAUrLKh37hJ0FKM
FSjkFJTLDZjvQxhkCSKlPcfrcFB+4sNHtZIx7vl/gCRnw/Vf6fwPE+X/HXoy
HTaVAkTJYMJiqzbEhY3YcKMAUPisqpVNZgJatl7GTU21MLJEW4IW0m2nu0IQ
ta+o+ddxEyOCGfFFsyBKJYUF3iV77nzdwLrJxHqDXjaZdTjT4pp4n3MtjuVD
adc0uRo29zmr5BLX4bBNOIetLuEQlREVCcd2zEyG+1nTnRp2S+VhgsDA+I8k
huRfgmn95yTGfx6rrhOJEpQOWv4lyIMVNvOgs6dqRtKp3NNgz5HIPxyf/Mve
+L8e+59+SeV/FO3Gyp21lY0rNy9OBgLAAQjQ11IPGeoHI0X/yf8GZ4TZTIWH
N+njrPmJiNHUKFMPewG4AfIPRYH5/wjK9Mkj4M3/JKX6fzRtbWV9ffmyHwCu
Nmp61Yqs/hvvAQhQpowMvAiqHI6g8mpOlkTEiypWCciqoKgWBYEQXuDbmxZs
vXVpBokzSFg8ItTsC5ppaUDaDov/cMzx/2zU/6eSnOL/aOz/GVGmtvKMKPk+
gE22dce1sZ3p6w2cnrlHyVvF1DZxrIZd6jF2FzvD+wdSevCvQQQrWNUqPUVh
Pmsy0Dd3mhYS7R2IdCRWbJYbLJkGRKZtVE2H1YX1JugvDBwDCIEyoz1wTGIE
NYiCRJEL9kjssMWe4AE2dOwIfkowlBC8MJO9FCGFfnlYmDR6TOQRohDhkccf
aCebDcMYb/5fjMb/sun4/wnz/xmb8DMA8OxDP9e2L1Ersqco0J+/44DhwG2W
RAoEyFS13WpFxY5W3UFN0XLtHYBVR6OggHfVzpBgESk5Zv0d4PgPSvsFCnW6
okhvZSmy42IMVT/C6/nJjhfSzrYbtj7e8f9iJP4nS6n+H7X/Fw7gvXbbarik
MIMuhLBhBq0cydwASBQkIRc3JqzfqHsPP/rVBbRZ2XMWeWY3lCs8rhBUtHmK
DTtAyTV5DTeJXYY7fFk0pS58UKihyh8e7D3ylsa7ZcKXqRmTvOJvmMGz1A1M
25M13XQa2pj9PzEbGf8rpvnfseN/F+NbKOnVbQ3OKSgxOYWMx2cDQdFoDbs9
JA4qfZMISjo3yiD5d2vELY/V/oM99V9Z3/5L/b+RtFOUAYhNHFc3t/k1ygmW
6g2/k7JyTrl/Zu7NzIxuqoSosw89kBDuN8yG08BGZvP26sNXXIsvklNOwyav
flF3zFl3Tne/MF+y8YP9187OLyycyX9Rd+fK2CkIZ5tEt9VTZ+rY+ULTeqje
dy0r84pqEbYbr7uvLg0uP2lHdoSDyjczp2ay2TP3596cfdiKV51fuZ7/0gvc
jU36doy7yL79aisoddj7iQ1zuVaVmMLDN/0PcHbuvv8JnZk5leH9E9UaporN
UPBLo7vfYqUls7MP587cp8QzhdMffOXR9x790aM//+DtR9/74J0PvvHo+4/+
5LRnMN/3jvpQmJ17kx6ZzwSM37YcNy1bnbl3jT+VoT0wu8S+vvnw1VcWz+W/
NH/6y7/02q+8FZhGS4AQ5STuEDwQNtYhK08lexTTHQriVwhWiU3PPXNm7j7t
/vx/vfcXH/7e73/41Xc/+u33JncMzLNt/+1CSURjjf9lvfF/IfsvHf83avtv
k9p/55eS1QDqmrvdzPTL+M4JCCBJkgTalihppmToVPB7C+vo2Qr1smWSRTbU
r0SBivcCDq1jRK5moYZV1S44TjjO3o5AzAlZCbTr+IJkvafrAU2f+QVZkOOu
M1BTJGU7hu/Rzgnz+LP6HQl20i5ouOPO/wE5bP+J6fyfk+T/JZ0F84mGBeW8
gL94YG7AZ9feGaJUR9MrbBZvpHZrQSRRPKD8zbFqJNksof2FvVUZrFl2DbtR
40b0rJtznuTSnuHO1Uu1BsfGGBdOiyI6PU9/PDff3jy2529Y5vawC4AHyH82
K6NI/D/N/02Q/HtO1CrHirg4zDE6zsQ1wlkaR21/m9TIE75xddtiokHl6nTs
mN58lvZpTzG+UNgl9j5j36N87WKjQRbYJ+8k7C6H/So4ZXrn/omHcUtxL8/n
JNTpu0Hf7uhu+Ya1xS6AebQ+RuMafkDdQcO7HB+w2cUO8+doQTRUcpP4J0Kx
zYplz+MdCq8U/FMEzuDxyNH8a1+/99QN4jidWzjyDwHt3VY21Aq3Cf1xf/T/
2yynd2wFlGOVA6BjLGz6PcNfp5RH+eKZrOW5VsfzRy3SvP9ch3f8ehszeA/7
C6M4k3dPMTFAilAI9bppu1EK2EuxFaUQQhRx5wFhmuUIDVRCNKvR4/TOCMZo
Yo4jh+4p5npgNkwTcxwpRBN3PWKYJuY4oT7e4vJchCbUy7txNOF+5rjouUD4
OFEaQYk8rxiiXJQohkoe/OiFbAIaKQGNmIAGJaCBCWgSsLQABtMog0lyg0kS
dHKCPk7QxQl6OEEHJ+nfASQRr7I1cY5a6MR12o7mqIy9Ubz8W2rB9cCa2THY
lo+xZofxLBTlGO62O+wCwIHz/0Tmf5WEtP5vpP5//ERaR1Plp0BFiOQNg4X+
HR4UlgLB71aWcnC9iTTMZXqUIw7oI0FUEMzJYEKAwGg6qu7Ux5r/QzKL/7OB
3jKbDNqP/6X1XyNpR7P+ny9x52JQoDsf34Cq/zYjssIDXCypSxr1L/fjUnFZ
0GdiTgYKkb3iw/rpwn9d+R9//T8K5/8lANL5P8Yd/1/gDHswBPjCvacRXqFK
LJdD/ANFSzIrMPJnZo/k+6ReUPC4058MVLWIpbOll7zi/qZt+p9ySLSr3qCi
VvJPQNSkzIooQa2q0HfqIoiUgwwLYfSGxcGOxaQZFml7WvCfAaA7Vv9PhhH/
T07rP0aJ//H2X98ZYJ/IIczlBLEX41scqFXNHWr9UYwXEVAUrLKh37hJ0FKM
FSjkFJTLDZjvQxhkCSKlPcfrcFB+4sNHtZIx7vl/gCRnw/Vf6fwPE+X/HXoy
HTaVAkTJYMJiqzbEhY3YcKMAUPisqpVNZgJatl7GTU21MLJEW4IW0m2nu0IQ
ta+o+ddxEyOCGfFFsyBKJYUF3iV77nzdwLrJxHqDXjaZdTjT4pp4n3MtjuVD
adc0uRo29zmr5BLX4bBNOIetLuEQlREVCcd2zEyG+1nTnRp2S+VhgsDA+I8k
huRfgmn95yTGfx6rrhOJEpQOWv4lyIMVNvOgs6dqRtKp3NNgz5HIPxyf/Mve
+L8e+59+SeV/FO3Gyp21lY0rNy9OBgLAAQjQ11IPGeoHI0X/yf8GZ4TZTIWH
N+njrPmJiNHUKFMPewG4AfIPRYH5/wjK9Mkj4M3/JKX6fzRtbWV9ffmyHwCu
Nmp61Yqs/hvvAQhQpowMvAiqHI6g8mpOlkTEiypWCciqoKgWBYEQXuDbmxZs
VvAdlxIKjgILniUHqGCvqlQ+dXc/z9lSrWmT6439i7fvntfnwYZ+q7ni3EX2
ypZTnb8M7+yVtze2hFuX5PKVxvXVa+Duna1r98rXdpW1Sm6TvLFTXdsqmls7
SL5wcS4noO3du5XS+U18z9x+vfZGSblz4976xRuXLzxYntPuGMrayuaVO6v3
LOECuUqK6t35N4zta2QDg5vG7g6wXRm8LlX0da24s3a19vollxB9d7NcXbtz
d3O5EAYuzWho2v5Sbx8uBpaqij6KxZ4Rdq0DRLJsUCsCtVRSAtiKVEXMSVgF
JVHJSUpx6V5tT7hXuyddvyOU7+6DvRu65BThjXJxOZPppt1bjBHARJstqEVs
fsUsWapubrO1vExs74dhs9YwXJ3BynxN3yPqQtFiQ5/t/YKMlVKRlAAsEaJl
2cjhi5g96XXsnqUeG3ez5LJ1aCUOiHlRzEtZ7vLaxvQUGwnIL2/TE3gcqNfq
rD/mvZQ690qpYTvEeTXGe5MQQ2qej562v1eX4Ganp64Qw7CSHDmoQDxvkHdc
m7DVQxKdB7x9/PbzL535+pWv/3j6+Asnvv328Qv0p9dOHD8uvAReeP65uc9+
6sQvgJe7JMeFt49zlOQXKQn4ZVAXXgYvPf+pzU8/f/LE5rpwEnyOfXnxJOMN
XbNsU8fC58BPsR9fOPniOja5q9RJFT4LPsN+mjr5HOU03RVeBbPs+8snuXX2
ndsgjstdILara+zmCLfccMvUH3f3T7x4/FvHdk6g4ye7lzfdubzjx5879umv
fuWd/9F+cuW/b/M/+PA33vmdb33nox/93+e/rd3dKX7zP/7pzB/8ozRV/ruP
v3vuz+Y+/tnGv/yD+s7dwg8vv/KjIvfjj5bd30XTv/X5//zDf/61Dz5z/qcz
b9nf+MG77//1dzP/+1fv//1Pfm5+4cTDm+/P/utG7d/++Dv59xa1v/2bL//w
L6997Ws/8+73//3jn+d//eaHb5E//c1Hz8U9OJ5/Vr0DT1jHq/8FCILjv0Rf
/6frP40l/0s1SR2b+wnHf0JpkN3dtnfjV1uIrQjxx1t3Tf6Ok9BiVSXHlolc
CljSrV2UxPvAA5yWTk6bpafZIgT9Y5jtLZEIZpL8tzcTJptnI1khqnjQtHjZ
0GOIZNQP6bHAvkVs8KgnVErDMmNtZskYcvYnQfynZ/5PD/9BWv83HvxPsP4n
ZFj0ZPEgL7WDgllgxoc9w/qh4KWQbEmETdQpBwYJyoFRkol9e69MQk+W6OUf
Z9VP5p/0qRRGIxsqYFrUIXEsc6zr/0EYyP/IXv0HSuV/JK29/jftf+6J1/bu
MBOmUsxW9tbZ7PyKAiGbx7u7kne6ivfk6H9rlxhOaaz1/yKUQvKf1v+PPP9r
4XqmSEg9Pz/fFXqURwDAoxkGlItU+qIe6PD50K/0pYcHOxRhzKZf+Fs1uqt0
IH8JgT5jANpjMJUklV9iOifhTsNyi3i863/IohS2/+V0/c8Jsv+9+X/W7Ax3
NcOxaLyvRaOm/2ICHFBQzCKXQnAkUJslPTfgoLF9SthoT7rqpaTkJSCBBLCQ
uNATjmHly6PIEdtkGzeGnABONv97r/4X0/k/R9KGvP5vTkZQKFcgEmDuoJVt
O2zYEwNoizTFjL5r+jKF3w1O9vH9WxmqB54I57kb1k2TXDOtprNR1p31UplN
QWbV8U6D8FQOcIEVaEak/BNpGtCOL2K15I5X/lHY/wdp/mfS5P8g6Y+VfUXJ
IQQPHPTb4b4qEiXs2AbS1OLukgD8sohuNcJBC3ojKSPkKDViL9R3QF9oDfGD
Vzuir0zvikef0DJS+gTYuknjlX8pG43/pfWfT7v85waJvs94IdEPZ3X/v72j
2W3bBt8L9B2IALsEcUqRki05c9Fi2LB2a7I169JDgUKxKFv+oRxSspqctp4H
7F2G9bjtFZI3Gj9RdiXZlpN2tZNVbFLHlCjJ9Pf/+x+29nu2wtS4DvXvQBu/
Dx5SKVSu+LQtgNfq/9RckP9Jjf+3BP+XN2AhVQY2ahLp+eFqs33eVlBh/Seg
jZNBfx4ITpu2Q01IIFUKogMxw5TkCMOcuMyhmtAQTzxn6vLRGU24GHGWhP7A
lU4cLMomFKvP+/WbSSBYapTYwFjtmijuMJQQRwdMP1uH2Jg4LctpNimxDesj
zJh6p0a9beJ/U+d/ENLEoCim8n9t/9us/8/CFB0zMQ26DL3g7tQNRu7piH0Q
+l9cvPEC6Ngtk8Xyh2rptanCQlxVRhaYK72BzwbJ3EBA0mxRm5qtFqHYhEQC
I5//WSQMCtx56EqGQx+STfqcnIV+6MIb4rLEh2sJ6EoSifPGYz9iQt3CdCgm
NrXVTsErvIX7OLaSc05cwdPgXcNWtw2nTESxYGjnCUc/iLCnUFbu3E5fg/Qm
W8//blkL8T+E1vr/7bL/p0a+14tKwOraCeXY0GuUBKosBqRBNTMNQnCQp8iA
d//e426XTaIsjp+Hp6F3Prft3cApYFjVOWGFog63pQfQRzsCJBsHW67/ha1W
Tv5vZvX/mjX+b2KU878P1IfsxF+YOIecNycKK1E9FD0dDUCJSariAWZwudQf
YL/n7DPkL6HgXmFiMuzKVmMcjNkeiNF6lNKU9nITMuhxNZM7VzFwt8fUAXXl
3BtfuL0qknL789EjJj91+6/19r98/ReN/6RV+/82zf+VZMwfKdU4HAdZesMR
UohVntW4LdzRpF9E+mfuy4Z/JE7c596xgnDczDv4UjgrIHPe1Pfy/OLivEHU
aYpnI/WjBH/E4/EpE2olRzpCQJ9F23Nenk4UFHX1FMzVorgfhuhUfbXqa4On
DkN4I9KXJUzdvi5Pj3Sf1E6auHH37X8RJCBCJq7cYv2HZquE/5ZV2/+3w/8/
VvAdlxIKjgILniUHqGCvqlQ+dXc/z9lSrWmT6439i7fvntfnwYZ+q7ni3EX2
ypZTnb8M7+yVtze2hFuX5PKVxvXVa+Duna1r98rXdpW1Sm6TvLFTXdsqmls7
SL5wcS4noO3du5XS+U18z9x+vfZGSblz4976xRuXLzxYntPuGMrayuaVO6v3
LOECuUqK6t35N4zta2QDg5vG7g6wXRm8LlX0da24s3a19vollxB9d7NcXbtz
d3O5EAYuzWho2v5Sbx8uBpaqij6KxZ4Rdq0DRLJsUCsCtVRSAtiKVEXMSVgF
JVHJSUpx6V5tT7hXuyddvyOU7+6DvRu65BThjXJxOZPppt1bjBHARJstqEVs
fsUsWapubrO1vExs74dhs9YwXJ3BynxN3yPqQtFiQ5/t/YKMlVKRlAAsEaJl
2cjhi5g96XXsnqUeG3ez5LJ1aCUOiHlRzEtZ7vLaxvQUGwnIL2/TE3gcqNfq
rD/mvZQ690qpYTvEeTXGe5MQQ2qej562v1eX4Ganp64Qw7CSHDmoQDxvkHdc
m7DVQxKdB7x9/PbzL535+pWv/3j6+Asnvv328Qv0p9dOHD8uvAReeP65uc9+
6sQvgJe7JMeFt49zlOQXKQn4ZVAXXgYvPf+pzU8/f/LE5rpwEnyOfXnxJOMN
XbNsU8fC58BPsR9fOPniOja5q9RJFT4LPsN+mjr5HOU03RVeBbPs+8snuXX2
ndsgjstdILara+zmCLfccMvUH3f3T7x4/FvHdk6g4ye7lzfdubzjx5879umv
fuWd/9F+cuW/b/M/+PA33vmdb33nox/93+e/rd3dKX7zP/7pzB/8ozRV/ruP
v3vuz+Y+/tnGv/yD+s7dwg8vv/KjIvfjj5bd30XTv/X5//zDf/61Dz5z/qcz
b9nf+MG77//1dzP/+1fv//1Pfm5+4cTDm+/P/utG7d/++Dv59xa1v/2bL//w
L6997Ws/8+73//3jn+d//eaHb5E//c1Hz8U9OJ5/Vr0DT1jHq/8FCILjv0Rf
/6frP40l/0s1SR2b+wnHf0JpkN3dtnfjV1uIrQjxx1t3Tf6Ok9BiVSXHlolc
CljSrV2UxPvAA5yWTk6bpafZIgT9Y5jtLZEIZpL8tzcTJptnI1khqnjQtHjZ
0GOIZNQP6bHAvkVs8KgnVErDMmNtZskYcvYnQfynZ/5PD/9BWv83HvxPsP4n
ZFj0ZPEgL7WDgllgxoc9w/qh4KWQbEmETdQpBwYJyoFRkol9e69MQk+W6OUf
Z9VP5p/0qRRGIxsqYFrUIXEsc6zr/0EYyP/IXv0HSuV/JK29/jftf+6J1/bu
MBOmUsxW9tbZ7PyKAiGbx7u7kne6ivfk6H9rlxhOaaz1/yKUQvKf1v+PPP9r
4XqmSEg9Pz/fFXqURwDAoxkGlItU+qIe6PD50K/0pYcHOxRhzKZf+Fs1uqt0
IH8JgT5jANpjMJUklV9iOifhTsNyi3i863/IohS2/+V0/c8Jsv+9+X/W7Ax3
NcOxaLyvRaOm/2ICHFBQzCKXQnAkUJslPTfgoLF9SthoT7rqpaTkJSCBBLCQ
uNATjmHly6PIEdtkGzeGnABONv97r/4X0/k/R9KGvP5vTkZQKFcgEmDuoJVt
O2zYEwNoizTFjL5r+jKF3w1O9vH9WxmqB54I57kb1k2TXDOtprNR1p31UplN
QWbV8U6D8FQOcIEVaEak/BNpGtCOL2K15I5X/lHY/wdp/mfS5P8g6Y+VfUXJ
IQQPHPTb4b4qEiXs2AbS1OLukgD8sohuNcJBC3ojKSPkKDViL9R3QF9oDfGD
Vzuir0zvikef0DJS+gTYuknjlX8pG43/pfWfT7v85waJvs94IdEPZ3X/v72j
2W3bBt8L9B2IALsEcUqRki05c9Fi2LB2a7I169JDgUKxKFv+oRxSspqctp4H
7F2G9bjtFZI3Gj9RdiXZlpN2tZNVbFLHlCjJ9Pf/+x+29nu2wtS4DvXvQBu/
Dx5SKVSu+LQtgNfq/9RckP9Jjf+3BP+XN2AhVQY2ahLp+eFqs33eVlBh/Seg
jZNBfx4ITpu2Q01IIFUKogMxw5TkCMOcuMyhmtAQTzxn6vLRGU24GHGWhP7A
lU4cLMomFKvP+/WbSSBYapTYwFjtmijuMJQQRwdMP1uH2Jg4LctpNimxDesj
zJh6p0a9beJ/U+d/ENLEoCim8n9t/9us/8/CFB0zMQ26DL3g7tQNRu7piH0Q
+l9cvPEC6Ngtk8Xyh2rptanCQlxVRhaYK72BzwbJ3EBA0mxRm5qtFqHYhEQC
I5//WSQMCtx56EqGQx+STfqcnIV+6MIb4rLEh2sJ6EoSifPGYz9iQt3CdCgm
NrXVTsErvIX7OLaSc05cwdPgXcNWtw2nTESxYGjnCUc/iLCnUFbu3E5fg/Qm
W8//blkL8T+E1vr/7bL/p0a+14tKwOraCeXY0GuUBKosBqRBNTMNQnCQp8iA
d//e426XTaIsjp+Hp6F3Prft3cApYFjVOWGFog63pQfQRzsCJBsHW67/ha1W
Tv5vZvX/mjX+b2KU878P1IfsxF+YOIecNycKK1E9FD0dDUCJSariAWZwudQf
YL/n7DPkL6HgXmFiMuzKVmMcjNkeiNF6lNKU9nITMuhxNZM7VzFwt8fUAXXl
3BtfuL0qknL789EjJj91+6/19r98/ReN/6RV+/82zf+VZMwfKdU4HAdZesMR
UohVntW4LdzRpF9E+mfuy4Z/JE7c596xgnDczDv4UjgrIHPe1Pfy/OLivEHU
aYpnI/WjBH/E4/EpE2olRzpCQJ9F23Nenk4UFHX1FMzVorgfhuhUfbXqa4On
DkN4I9KXJUzdvi5Pj3Sf1E6auHH37X8RJCBCJq7cYv2HZquE/5ZV2/+3w/8/
rP7vR1X+RTkYHAaDvukOPe6eDYYJ4550pQ+MfwWfv1ZN4PVl4EqLjr/6Sa0i
VatGrhx4fb9sH/n+GEW0Yh1xbBxzDz5R8TEPvzs8OjlEkVmxWKk72KeMLzHK
VLo/sOsEns8ZWyJ6RCKR2+b/Fi7jv0lxjf8bx3/BxmHEGmo/esuFfoQq+7Gv
gHhQ1bGT9wWsvFHR/DcKFUlpCCbDWHTZMsLimMTBdr7aQQrPYdCNqelYNoQQ
Mx8iiPsCGpqLtYSEUNvJBxcv72Xy/4kYjvlQdseflgKslf9NWsb/Zo3/m8X/
kt1Mx8S1ozCCpnk6NK6rAX8T2QAZVPI6G2AT+D8mW8Z/Ssr4b5Fa/78l/n/A
8kCe8raSXWnLIXaLzrl0P4ogYShJkv1lYr9CzDJWp7CWqv/980mfcTdiXqNc
xvE9MzYdnHfwL3Lj1QUnjOtEAn4JzcHaT8M+f308DqL+w8+tWmTMt57/a2Cj
7P+zDFrXf9vImEn2BGPUQWR3l6JdZO3uEnT51+Xf6OrXq7fq5fLPy3eXf1z9
DnOlqau3V7+hBrr85+qX2bHLd1U2cccu4aRBiemQIqHIgBKaAQ2B6Q/pgDCR
MM+Xj48rUolXBiMahm43skJqYV6sXZAEwhMWXX7XSwlaFsbj2AsZxjdLE3Ls
lXlCcOj2tRSsxx0aiQz4dLvxH0bLMsrxH0oArOn/hv0/02DKhr1H3b4biIbH
RbegNGXdvtPe3Dnh8Ai1799bvxwdIIQUgQVnakcRMMOGf5Ty+/d8AZ1GUBvt
PEXPQ8n4KRM99OrVq52dzPuqs009AQcfLcREwn9w5Q6CIl8Dz17jidIQv8QJ
VaT66SOlsR5dmVaewdiBW+XiSLK20gg9UCen24GA1Wm38VwOnXE76mCZiZ8S
Nu2QJd+4vDdi3rfM9SDEDCHOEl/PoayXLgKtO+Cxmlk8mLWq1+tPlPj6gscy
dkc/w+E2OjjY21O/B2t5l664qm6W7rTUYYCy8PWPxAwCEnWfjm42P+sAz0Pd
qf1h2oZ9tiepwfABAh0chpwEwO4KUJF9fXqHADIQyoQCJxgObITABz/fYn1F
9SfIE+kGG017n1jWvuLucK3sQh21aBaJDBF6igO2d36MQ6VqIBmJgCvw2gHw
WglY6lJqtzWsd2ZhAGom/ZT6mSXYQzx9ygE6U8+O9ym9MXtfWQPI3Axrv2AK
/fwt6/8EL9r/av3/Dvn/qix9vb70TCNHgDOQG4Apb+TzMQnJyKTCirE29xVM
e5QYFZ69a/V4AitCULYd4Lr0Rz3qUY/PfPwLcaRGXQDwAAA=
-- END MESSAGE ARCHIVE --
rP7vR1X+RTkYHAaDvukOPe6eDYYJ4550pQ+MfwWfv1ZN4PVl4EqLjr/6Sa0i
VatGrhx4fb9sH/n+GEW0Yh1xbBxzDz5R8TEPvzs8OjlEkVmxWKk72KeMLzHK
VLo/sOsEns8ZWyJ6RCKR2+b/Fi7jv0lxjf8bx3/BxmHEGmo/esuFfoQq+7Gv
gHhQ1bGT9wWsvFHR/DcKFUlpCCbDWHTZMsLimMTBdr7aQQrPYdCNqelYNoQQ
Mx8iiPsCGpqLtYSEUNvJBxcv72Xy/4kYjvlQdseflgKslf9NWsb/Zo3/m8X/
kt1Mx8S1ozCCpnk6NK6rAX8T2QAZVPI6G2AT+D8mW8Z/Ssr4b5Fa/78l/n/A
8kCe8raSXWnLIXaLzrl0P4ogYShJkv1lYr9CzDJWp7CWqv/980mfcTdiXqNc
xvE9MzYdnHfwL3Lj1QUnjOtEAn4JzcHaT8M+f308DqL+w8+tWmTMt57/a2Cj
7P+zDFrXf9vImEn2BGPUQWR3l6JdZO3uEnT51+Xf6OrXq7fq5fLPy3eXf1z9
DnOlqau3V7+hBrr85+qX2bHLd1U2cccu4aRBiemQIqHIgBKaAQ2B6Q/pgDCR
MM+Xj48rUolXBiMahm43skJqYV6sXZAEwhMWXX7XSwlaFsbj2AsZxjdLE3Ls
lXlCcOj2tRSsxx0aiQz4dLvxH0bLMsrxH0oArOn/hv0/02DKhr1H3b4biIbH
RbegNGXdvtPe3Dnh8Ai1799bvxwdIIQUgQVnakcRMMOGf5Ty+/d8AZ1GUBvt
PEXPQ8n4KRM99OrVq52dzPuqs009AQcfLcREwn9w5Q6CIl8Dz17jidIQv8QJ
VaT66SOlsR5dmVaewdiBW+XiSLK20gg9UCen24GA1Wm38VwOnXE76mCZiZ8S
Nu2QJd+4vDdi3rfM9SDEDCHOEl/PoayXLgKtO+Cxmlk8mLWq1+tPlPj6gscy
dkc/w+E2OjjY21O/B2t5l664qm6W7rTUYYCy8PWPxAwCEnWfjm42P+sAz0Pd
qf1h2oZ9tiepwfABAh0chpwEwO4KUJF9fXqHADIQyoQCJxgObITABz/fYn1F
9SfIE+kGG017n1jWvuLucK3sQh21aBaJDBF6igO2d36MQ6VqIBmJgCvw2gHw
WglY6lJqtzWsd2ZhAGom/ZT6mSXYQzx9ygE6U8+O9ym9MXtfWQPI3Axrv2AK
/fwt6/8EL9r/av3/Dvn/qix9vb70TCNHgDOQG4Apb+TzMQnJyKTCirE29xVM
e5QYFZ69a/V4AitCULYd4Lr0Rz3qUY/PfPwLcaRGXQDwAAA=
-- END MESSAGE ARCHIVE --
Authors' Addresses
作者地址
Robert J. Sparks (editor) Estacado Systems
Robert J.Sparks（编辑）Estacado系统
EMail: RjS@estacado.net
EMail: RjS@estacado.net
Alan Hawrylyshen Ditech Networks 200 - 1167 Kensington Cr. NW Calgary, Alberta T2N 1X7 Canada
Alan Hawrylyshen Ditech Networks 200-1167肯辛顿Cr.加拿大阿尔伯塔省卡尔加里西北部T2N 1X7
Phone : +1.403.806.3366
EMail : ahawrylyshen@ditechcom.com
Phone : +1.403.806.3366
EMail : ahawrylyshen@ditechcom.com
Alan Johnston Avaya St. Louis, MO 63124
密苏里州圣路易斯市艾伦·约翰斯顿·阿瓦亚63124
EMail: alan@sipstation.com
EMail: alan@sipstation.com
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07052
Jonathan Rosenberg思科系统公司，地址：新泽西州帕西帕尼拉尼德广场600号，邮编：07052
Phone: +1 973 952 5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Phone: +1 973 952 5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
美国纽约州纽约市哥伦比亚大学计算机科学系计算机科学大楼450号
Phone: +1 212 939 7042
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
Phone: +1 212 939 7042
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。