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
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
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
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）に基づいて、テストメッセージを含んでいます。一部のメッセージは、[RFC3264]で説明したように、セッション記述プロトコル（SDP）のSIPの使用を行使する。
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.
メッセージは、あいまいさを避けて、インターネットドラフトレイアウト要件を満たすために、マークアップの規則のセットを使用してテキストに提示されています。残りのあいまいさを解決するために、各メッセージのビット精度バージョンは付録に封入されています。
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 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.
この文書では、多くの例のSIPメッセージが含まれています。 SIPは、テキストベースのプロトコルであるが、これらの例の多くは、明確RFCの書式上に配置された制約に起因する追加のマークアップなしでレンダリングすることができません。この文書では、定義し、その曖昧さを取り除くために、このセクションで定義されたマークアップを使用しています。このマークアップは、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、第3の値
<allOneLine> Header-name: first value, reallylongsecondvalue , third value </allOneLine>
<allOneLine>ヘッダ名：最初の値、reallylongsecondvalue、第3の値</ allOneLine>
<allOneLine> Header-name: first value, reallylong second value, third value </allOneLine>
<allOneLine>ヘッダ名：第2の値をreallylong最初の値、第3の値</ allOneLine>
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でエンコードされた文字を含むバイナリメッセージ本文またはヘッダフィールド値を含みます。これらは、<ヘキサン/>タグの間のオクテット当たり16進数の対としてここでレンダリングされます。このレンダリングでも引用され、文字列の内部で適用されます。
The following represent the same string of bits:
以下は、同じビット列を表します。
Header-name: value one Header-name: value<hex>206F6E</hex>e
ヘッダー名：値1ヘッダー名：値<進> 206F6E </六角> E
The following is a Subject header field containing the euro symbol:
以下は、ユーロ記号を含む件名ヘッダフィールドです。
Subject: <hex>E282AC</hex>
件名：<進> E282AC </六角>
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.
いくつかの例には、ビット列を繰り返して作成した、非常に大きなデータ値が含まれています。これらは、<繰り返し回数= some_integer>値</リピート>を使用して、ここでレンダリングされます。 <六角>と同じように、このレンダリングも、引用符で囲まれた文字列の内側に適用されます。
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
例えば、値が「ABCABCABC」<繰り返し回数= 3> ABC </リピート>としてレンダリングすることができます。 「ビールのボトル1000000」の表示名は次のようにレンダリングすることができ
To: "1<repeat count=6><hex>30</hex></repeat> bottles of beer" <sip:beer.example.com>
To： "1 <繰返し回数= 6> <進> 30 </進> </リピート>ビールの瓶" <一口：beer.example.com>
A Max-Forwards header field with a value of one google will be rendered here as
Googleの値と最大Forwardsヘッダフィールドは、ここでのようにレンダリングされます
Max-Forwards: 1<repeat count=100>0</repeat>
マックス・フォワード：1 <繰返し回数= 100> 0 </繰り返し>
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、未知のRequest-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.
それは、一般的な-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.
値のないuriパラメータO。
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.
UnknownHeaderWithUnusualValueヘッダフィールドは、特別な注意に値します。 （既存の定義されたヘッダフィールドの多くと同じように）このヘッダフィールドはセミコロンで区切られたパラメータを持つカンマ区切り値で定義された場合、これは無効になるであろう。しかし、受光素子は、このフィールドの構文の定義を知らないので、ヘッダの値として、それを解析する必要があります。プロキシは、このヘッダフィールドはそのまま転送します。エンドポイントは、ヘッダフィールドを無視します。
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
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 0 = mhandley IP4 192.0.2.3 S = IN 29739 7272939 - C = IN IP4 192.0.2.4 T = 0、M =オーディオ49217 RTP / AVP 0〜12、M =映像3227 RTP / AVP 31 = 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メソッドは、トークンから非アルファベット文字が含まれています。 ％がこのフィールドのエスケープ文字ではないことに注意してください。 IN％の56ITEの方法は、未知の方法です。それは、INVITEの方法と同じではありません。
o The Request-URI contains unusual, but legal, characters.
O Request-URIが、珍しいが、法的な文字が含まれています。
o A branch parameter contains all non-alphanum characters from token.
O分岐パラメータは、トークンからすべての非alphanum文字が含まれています。
o The To header field value's quoted string contains quoted-pair expansions, including a quoted NULL character.
O Toヘッダーフィールド値の引用符で囲まれた文字列は引用符で囲まれたNULL文字を含む引用されたペアの拡張が含まれています。
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からヘッダフィールド値の名前-ADDRの名前部分は、トークン生成規則からすべての非alphanum文字を（代わりに引用符で囲まれた文字列の）複数のトークンを含んでいます。その値はまた、その名前非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コールIDヘッダフィールド値はワードからの非alphanum文字を含みます。この生産のことに注意してください：
* % 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ヘッダーフィールドに理解する方法をリスト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>面白い-Method0123456789 _ * + `確か％ '〜一口：。？＆それは= 1を持っている+、奇妙：1_unusual.URI〜＆それを+されていない$ /クレイジー、/ ;; *（！確かなことに） ！* PAS $ WO〜d_too（doesn't-それを）@ example.com SIP / 2.0 </ allOneLine>ビア：。。！SIP / 2.0 / TCP host1.example.com;ブランチ= z9hG4bK - ％66 * _ + ` '〜<allOneLine>へ： "BEL：\ <進> 07 </六角> NUL：\ <進> 00 </六角> DEL：\ <進> 7F </進>"<一口：1_unusual.URI〜 （へ-ことを確認してください！）＆$ /クレイジーそれを+されていない、/ ;; * @ example.com> </ allOneLine> <allOneLine>より：TOKEN1〜 `token2' + _ token3 *％.- <一口！ ：mundane@example.com>; fromParam '' 〜+ * _ .-％= "<進> D180D0B0D0B1D0BED182D0B0D18ED189D0B8D0B9 </六角>";タグ= _token〜1' ！+ `*％！ - 。 </ allOneLine>コール-IDを：！。intmeth.word％ZK - * _ + '@ word`〜）（> <：\ / "] [} {のCSeq：139122385面白い-Method0123456789 _ * +`％本当に？！。 '〜マックス・フォワード：255 <allOneLine> extensionHeader - ％* + _ `！' 〜：<進> EFBBBFE5A4A7E5819CE99BBB </進> </ 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の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そのuserpartに埋め込まれては。どのようなことがexample.netに意味するかもしれないことは、この文書の範囲外です。
o The From and To URIs have escaped characters in their userparts.
FromとURIにOがそのuserparts内の文字をエスケープしています。
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パラメータの文字をエスケープしています。 「名前」のuri-パラメータが「valueA」と同等ではありません「値％41」の値を持っていることに注意してください。 [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 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
sips%3Auser%40example.com@example.net SIP / 2.0：SIP：SIPのINVITE %75se%72@example.comから<SIP：I%20have%20spaces@example.net>;タグ= 938 MAX-フォワード：87 I：esc01.239409asdfakjkn23onasd0-3234のCSeq：234234 INVITEを経由：SIP / 2.0 / UDP host5.example.net;ブランチ= z9hG4bKkdjuw C：アプリケーション/ SDP連絡先：<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 0 = mhandley IP4 192.0.2.1 S = IN 29739 7272939 - C = IN IP4 192.0.2.1 T = 0、M =オーディオ49217 RTP / AVP 0〜12、M =映像3227 RTP / AVP 31 = 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.
このレジスタ要求はuserpartでヌルを持ついくつかのURIが含まれています。メッセージは十分に形成されている - パーサは、このメッセージを受け入れなければなりません。この要求のアドレス・オブ・レコード（AOR）をアンエスケープするとき途中でユーザ名を短くしないように実装は、特別な注意を払う必要があります。この要求は、2つの異なる接触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
example.com SIP / 2.0：SIP：null-%00-null@example.comから：SIP：SIPレジスタnull-%00-null@example.comと、タグ= 839923423最大フォワード：70のCall-ID： escnull.39203ndfvkjdasfkq3w4otrq0adsfdfnavdのCSeq：14398234レジスタを介して：SIP / 2.0 / UDP host5.example.com;ブランチ= z9hG4bKkdjuw連絡先：<SIP：%00@host5.example.com>連絡先：<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このメッセージは、次の2つのContactヘッダーフィールド値ではなく、3つ有しています。 <SIP：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.
パーサは、同様に形成され、このメッセージを受け入れる必要があります。プロキシは、Request-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： "％Z％45" <SIP：resource@example.com>から： "％Z％45" <SIP：resource@example.com>。タグ= f232jadfj23コールIDを：経由esc02.asdfnqwo34rq23i34jrjasdcnl23nrlknsdf：SIP / 2.0 / TCP host.example.com;ブランチ= z9hG4bK209％fzsnel234のCSeq：29344 RE％47IST％45Rマックス・フォワード：70お問い合わせ：<SIP：ALIAS1 @ HOST1。 example.com> C％6Fntact <SIP：alias2@host2.example.com>連絡先：<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.
トークンの間にLWSは、Fromヘッダフィールド値の表示名と<に存在しないため、このOPTIONS要求は、RFC 3261に文法ごとに有効ではありません。これは、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：SIP：user@example.comから：発信者<SIP：caller@example.com>;タグ= 323最大フォワード：70のCall-ID：lwsdisp.1234abcd@funky .example.comというのCSeq：60 OPTIONSのVia：SIP / 2.0 / UDP funky.example.com;分岐= z9hG4bKkdjuw 1：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 Toヘッダーフィールドは、長い表示名、および長いuriパラメータ名と値を持っています。
o The From header field has long header parameter names and values, in particular, a very long tag.
Fromヘッダフィールドoは、特に、非常に長いタグを長いヘッダパラメータ名と値を有しています。
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
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
ビア：SIP / 2.0 / TCP sip12.example.com経由：SIP / 2.0 / TCP sip11.example.com経由：SIP / 2.0 / TCP sip10.example.com経由：SIP / 2.0 / TCP sip9.example.com経由： SIP / 2.0 / TCP sip8.example.com経由：SIP / 2.0 / TCP sip7.example.com経由：SIP / 2.0 / TCP sip6.example.com経由：SIP / 2.0 / TCP sip5.example.com経由：SIP / 2.0 / TCP sip4.example.com経由：SIP / 2.0 / TCP sip3.example.com経由：SIP / 2.0 / TCP sip2.example.com経由：SIP / 2.0 / TCP sip1.example.com <allOneLine>経由：SIP /2.0/TCP host.example.com;受信= 192.0.2.5。ブランチ=非常<繰返し回数= 50>長い</リピート> branchvalue </ allOneLine>マックス・フォワード：70 <allOneLine>連絡先：<SIP：<繰り返し回数= 5> amazinglylongcallername </リピート> @ host5.example.net> </ allOneLine>のContent-Type：アプリケーション/ SDPリットル：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 0 = mhandley IP4 192.0.2.1 S = IN 29739 7272939 - C = IN IP4 192.0.2.1 T = 0、M =オーディオ49217 RTP / AVP 0〜12、M =映像3227 RTP / AVP 31 = 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.
このメッセージは、表向きは、単一のデータグラムでUDPの上に到着した単一のSIP REGISTERリクエストを、含まれています。パケットは、（この場合はゼロの長さを有する）本体の後、余分なオクテットを含んでいます。余分なオクテットは、それらは無視されなければならないだけでスプリアスです。（[RFC3261]のセクション18.3あたり）SIP INVITE要求のように見えるために起こるが、
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要素は、通常、REGISTERリクエストを処理し、INVITEリクエストのように見える余分なビットを無視します。要素がREGISTERを転送することを選択するプロキシがある場合は、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
example.comへのSIP / 2.0：SIP：j.user@example.comから：SIP：SIPレジスタj.user@example.comを、タグ= 43251j3j324マックス・フォワード：8 I：dblreq.0ha0isndaksdj99sdfafnl3lk233412お問い合わせ：SIP：J .user @ host.example.comのCSeq：8レジスタを介して：SIP / 2.0 / UDP 192.0.2.125;ブランチ= 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
SIPのINVITE：joe@example.com SIP / 2.0 T：SIP：joe@example.comから：SIP：caller@example.net;タグは= 141334最大フォワード：8のCall-ID：dblreq.0ha0isnda977644900765@192.0.2.15のCSeqアプリケーション/ SDPのContent-Length：150;：ブランチ= z9hG4bKkdjuw380234 Content-TypeのSIP / 2.0 / UDP 192.0.2.15：8経由のINVITE
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 0 = IP4 192.0.2.15 S = IN mhandley 29739 7272939 - C = IP4 IN 192.0.2.15 T = 0、M =オーディオ49217 RTP / AVP 0〜12、M =映像3227 RTP / AVP 31 = 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".
この要求は、（値エスケープ@記号が含まれている）のRequest-URIの「ユーザ」部分に含まれるセミコロンで区切られたパラメータを有します。要素を受信することは、十分に形成されたメッセージとしてこれを受け入れます。 Request-URIがユーザーの一部が「; 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：ユーザー; par=u%40example.net@example.com SIP / 2.0：SIP：j_user@example.comから：SIP：caller@example.org;タグ= 33242最大フォワード：3のCall-ID： semiuri.0ha0isndaksdjのCSeq：8 OPTIONS受け入れ：アプリケーション/ SDP、アプリケーション/ PKCS7-MIMEマルチパート/混合、マルチパート/署名された、メッセージ/ SIP、メッセージ/ sipfragのVia：SIP / 2.0 / UDP 192.0.2.1;分岐= z9hG4bKkdjuw 1： 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).
この要求は、すべての既知のトランスポート・タイプのヘッダーフィールド値を経由して含まれており、トランスポート拡張機構を行使する。パーサは、同様に形成され、このメッセージを受け入れなければなりません。このメッセージを受信した要素は、正確にUDP（または他のトランスポート）指定された第2及び後続のヘッダフィールド値かのようにそれを処理するであろう。
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：SIP：user@example.comから<SIP：caller@example.com>;タグ= 323最大フォワード：70のCall-ID：受け入れtransports.kijh4akdnaqjkwendsasfdj：アプリケーション/ SDPのCSeq：60 OPTIONSのVia：SIP / 2.0 / UDP t1.example.com;分岐= z9hG4bKkdjuwのVia：SIP / 2.0 / SCTP t2.example.com;分岐= z9hG4bKklasjdhfのVia：SIP / 2.0 / TLS t3.example.com ;分岐= z9hG4bK2980unddjのVia：SIP / 2.0 / UNKNOWN t4.example.com;分岐= z9hG4bKasd0f3enのVia：SIP / 2.0 / TCP t5.example.com;分岐= z9hG4bK0a9idfnee 1：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.
このMESSAGEリクエストは、2体の部分が含まれています。第二部は、バイナリ符号化され、ヌル（0×00）文字を含みます。レシーバは、適切に受信したメッセージをフレームに世話をする必要があります。
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].
マルチパート/ MIMEメッセージの追加の例は、特定のS / MIMEメッセージで、セキュリティコールフローの例ドキュメント[SIP-SEC]でご利用いただけます。
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>ビア：SIP / 2.0 / UDP 127.0.0.1:5070、支店= z9hG4bK-d87543-4dade06d0bdb11ee-1 - d87543-; RPORT </ allOneLine>マックス転送します。 70ルート：<SIP：127.0.0.1：5080> <allOneLine>アイデンティティ：r5mwreLuyDRYBi / 0TiPwEsY3rEVsk / G2WxhgTV1PF7hHuL IK0YWVKZhKv9Mj8UeXqkMVbnVq37CD + 813gvYjcBUaZngQmXc9WNZSDN GCzA + fWl9MEUHWIZo1CeJebdY / XlgKeTa0Olvq0rt70Q5jiSfbqMJmQF teeivUhkMWYUA = </ allOneLine>連絡先：<SIP：fluffy@127.0.0.1：5070>へ：<SIP：kumiko@example.org>から<SIP：fluffy@example.com>;タグ= 2fb0dcc9のCall-ID：3d9485ad0c49859b @ Zmx1ZmZ5LW1hYy0xNi5sb2NhbA ...のCSeq：1 MESSAGEコンテンツ転送エンコード：バイナリのContent-Type：マルチパート/ミックス;境界= 7a9cbec02ceef655日：土、2005年10月15日4時44分56秒GMTユーザーエージェント：SIPimp.org/0.2.5（呪い）のContent-Length：553
--7a9cbec02ceef655 Content-Type: text/plain Content-Transfer-Encoding: binary
--7a9cbec02ceef655のContent-Type：text / plainのコンテンツ転送 - エンコード：バイナリ
Hello --7a9cbec02ceef655 Content-Type: application/octet-stream Content-Transfer-Encoding: binary
こんにちは--7a9cbec02ceef655のContent-Type：アプリケーション/ octet-streamのコンテンツ転送 - エンコード：バイナリ
<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--
<ヘクス> 3082015206092A86 4886F70D010702A08201433082013F02 01013109300706052B0E03021A300B06 092A864886F70D010701318201203082 011C020101307C3070310B3009060355 04061302555331133011060355040813 0A43616C69666F726E69613111300F06 03550407130853616E204A6F7365310E 300C060355040A130573697069743129 3027060355040B132053697069742054 65737420436572746966696361746520 417574686F7269747902080195007102 330113300706052B0E03021A300D0609 2A864886F70D01010105000481808EF4 66F948F0522DD2E5978E9D95AAE9F2FE 15A06659716292E8DA2AA8D8350A68CE FFAE3CBD2BFF1675DDD5648E593DD647 28F26220F7E941749E330D9A15EDABDB 93D10C42102E7B7289D29CC0C9AE2EFB C7C0CFF9172F3B027E4FC027E1546DE4 B6AA3ABB3E66CCCB5DD6C64B8383149C B8E6FF182D944FE57B65BC99D005 </ヘキサン> --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)
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
メッセージの詳細：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 <六角> D0BDD0BE20D181D182 D0BE20D0B4D0B5D0B2D18FD0BDD0BED181D182D0BE20D0B4 D0B5D0B2D18FD182D18C202D20D0BFD180D0BED181D182D0 BED0B5 </進> </ allOneLine>ビア：SIP / 2.0 / UDP 192.0.2.198;ブランチ= z9hG4bK1324923コールID： unreason.1234ksdfak3j2erwedfsASdfのCSeq：35からINVITE：SIP：user@example.com; = 11141343へタグ：SIP：user@example.edu;タグ= 2229のContent-Length：154のContent-Type：アプリケーション/ SDP連絡先：<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 0 = IP4 192.0.2.198 S = IN mhandley 29739 7272939 - C = IP4 IN 192.0.2.198 T = 0、M =オーディオ49217 RTP / AVP 0〜12、M =映像3227 RTP / AVP 31 = 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 <進> 20 </ヘキサン>のVia：SIP / 2.0 / UDP 192.0.2.105;分岐= z9hG4bK2398ndaoeのCall-ID：のCSeq noreason.asndj203insdf99223ndf：35からのINVITE <SIP：user@example.com>;タグ= 39ansfi3宛先：<SIP：user@example.edu>;タグ= 902jndnke3のContent-Length：0お問い合わせ：<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ヘッダーフィールドは、パラメータまたは値なしで追加セミコロン、コンマを含んでいます。 Contactヘッダーフィールドは、パラメータなしで追加セミコロンが含まれています。このメッセージは、構文的に無効です。
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
7コールID：badinv01.0ha0isndaksdjasdf3234nas用のCSeq：8; user@example.com SIP / 2.0：SIP：j.user@example.comから：SIPタグ= 134161461246最大転送しcaller@example.net SIPのINVITE経由のINVITE：SIP / 2.0 / UDP 192.0.2.15 ;;、; ,,連絡先： "ジョー" <一口：joe@example.org> ;;;;コンテンツの長さ：152のContent-Type：アプリケーション/ 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 0 = IP4 192.0.2.15 S = IN mhandley 29739 7272939 - C = IP4 IN 192.0.2.15 T = 0、M =オーディオ49217 RTP / AVP 0〜12、M =映像3227 RTP / AVP 31 = 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 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.
（このメッセージは表向きあったように）UDP経由で送信される場合には、受光素子は、400不正な要求エラーで応答する必要があります。このメッセージは、TCPのようなストリームベースの輸送、上に到着した場合は、あまりありません受信側はやるが、どれも合理的な期間内に迫っていない場合は、ストリームの詳細データを待機して接続を閉じることができます。
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
<SIP：caller@hungry.example; user@example.com SIP / 2.0最大転送します：80：SIP：j.user@example.comから：SIPタグ= 93942939o2接触caller@example.net SIPのINVITE .NET>コール-IDを：clerr.0ha0isndaksdjweiafasdk3のCSeqは：経由のINVITE 8：SIP / 2.0 / UDP host5.example.com;ブランチ= z9hG4bK-39234から23523のContent-Type：アプリケーション/ 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 0 = IP4 192.0.2.155 S = IN mhandley 29739 7272939 - C = IP4 IN 192.0.2.155 T = 0、M =オーディオ49217 RTP / AVP 0〜12、M =映像3227 RTP / AVP 31 = 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ヘッダフィールド内の数値なしに到着するメッセージのために適切です。
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.
彼らは積分形式にこのアスキーフィールドを変換するために選択する手法が負の値を返すことができる場合は実装者は、余分な予防策を取る必要があります。具体的には、結果は、カウンタまたは配列インデックスとして使用してはなりません。
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最大転送します。254：SIP：j.user@example.comから：SIP：caller@example.net;タグ= 32394234のCall-ID：ncl.0ha0isndaksdj2193423r542w35のCSeq：0経由のINVITE：SIP / 2.0 / UDP 192.0.2.53;ブランチ= z9hG4bKkdjuw連絡先：<SIP：caller@example53.example.net>のContent-Type：アプリケーション/ 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 0 = IP4 192.0.2.53 S = IN mhandley 29739 7272939 - C = IP4 IN 192.0.2.53 T = 0、M =オーディオ49217 RTP / AVP 0〜12、M =映像3227 RTP / AVP 31 = 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ザ・有効期限は、値が> 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不正な要求に応答する必要があります。唯一のマックス・フォワードフィールドが誤っていた場合は、要素は、フィールドが存在しなかったかのように要求を処理することを選択することができます。唯一の有効期限値がエラーであった場合、彼らは有効期限（この場合は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
SIP REGISTER：example.comをSIP / 2.0経由：SIP / 2.0 / TCP host129.example.com;ブランチ= z9hG4bK342sdfoi3へ：<SIP：user@example.com>から<SIP：user@example.com>;タグ= 239232jh3のCSeq：36893488147419103232 REGISTERコール-ID：scalar02.23o0pd9vanlq3wnrlnewofjas9ui32マックス・フォワード：300有効期限：1 <繰り返し回数= 100> 0 </リピート>連絡先：<SIP：user@host129.example.com>を; = 280297596632815のContentを有効期限が切れます長さ：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サービスを使用できません<allOneLine>ビア：SIP / 2.0 / TCP host129.example.com;ブランチ= z9hG4bKzzxdiwo34sw;受け取ら= 192.0.2.129 </ allOneLine>宛先：<SIP：user@example.com>から<一口：other@example.net>;タグ= 2easdjfejwのCSeq：9292394834772304023312 OPTIONS呼び出しは-ID：scalarlg.noase0of0234hn2qofoaf0232aewf2394rリトライ後：949302838503028349304023988警告：1812序曲の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：「ミスターJ.ユーザー<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
user@example.com 2.0 SIP /：から<j.user@example.com SIP>：SIP：「氏J.ユーザーSIP INVITE caller@example.netと、タグ= 93334最大フォワード：10 Call- ID：quotbal.aksdj連絡先：<SIP：caller@host59.example.net>のCSeq：SIP / 2.0 / UDP 192.0.2.59:5050;branch=z9hG4bKkdjuw39234のContent-Type：アプリケーション/ SDPのContent-Length：152を介してのINVITE 8
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 0 = IP4 192.0.2.15 S = IN mhandley 29739 7272939 - C = IP4 IN 192.0.2.15 T = 0、M =オーディオ49217 RTP / AVP 0〜12、M =映像3227 RTP / AVP 31 = rtpmap：31 LPC
This INVITE request is invalid because the Request-URI has been enclosed within in "<>".
要求URIは中で囲まれているので、このINVITE要求は「> <」は無効です。
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：SIP：user@example.comから：SIP：caller@example.net;タグ= 39291最大フォワード：23のCall-ID：ltgtruri.1@192.0。 2.5のCSeq：SIP / 2.0 / UDP 192.0.2.5連絡先：<SIP：caller@host5.example.net>のContent-Type：アプリケーション/ SDPのContent-Lengthを：159経由のINVITE 1
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 0 = mhandley IP4 192.0.2.5 S = IN 29739 7272939 - C = IN IP4 192.0.2.5 T = 3149328700 0、M =オーディオ49217 RTP / AVP 0〜12、M =映像3227 RTP / AVP 31 = rtpmap：31 LPC
This INVITE has illegal LWS within the Request-URI.
これは、INVITE要求URI内の違法LWSを持っています。
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など）、これらのスキームの組み込みLWSを無視しようとする可能性があり。
Message Details : lwsruri
メッセージの詳細：lwsruri
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
SIP INVITE：user@example.comを。 LR SIP / 2.0：SIP：user@example.com;タグ= 3xfe-9921883-z9fから：SIP：caller@example.net;タグ= 231413434最大フォワード：5のCall-ID：lwsruri.asdfasdoeoi2323-asdfwrn23-asd834rk423 CSeq：2130706432経由のINVITE：SIP / 2.0 / UDP 192.0.2.1:5060;branch=z9hG4bKkdjuw2395連絡先：<SIP：caller@host1.example.net>のContent-Type：アプリケーション/ SDPコンテンツの長さ：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 0 = mhandley IP4 192.0.2.1 S = IN 29739 7272939 - C = IN IP4 192.0.2.1 T = 3149328700 0、M =オーディオ49217 RTP / AVP 0〜12、M =映像3227 RTP / AVP 31 = 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マックスフォワード：8：SIP：user@example.comから：SIP：caller@example.net;タグ= 8814のCall-ID：lwsstart.dfknq234oi243099adsdfnawe3@example.comのCSeq ：1893884ビアをINVITE：SIP / 2.0 / UDP host1.example.com;ブランチ= z9hG4bKkdjuw3923連絡先：<SIP：caller@host1.example.net>のContent-Type：アプリケーション/ SDPコンテンツの長さ：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 0 = mhandley IP4 192.0.2.1 S = IN 29739 7272939 - C = IN IP4 192.0.2.1 T = 0、M =オーディオ49217 RTP / AVP 0〜12、M =映像3227 RTP / AVP 31 = rtpmap：31 LPC
This OPTIONS request contains SP characters between the SIP-Version field and the CRLF terminating the Request-Line.
このOPTIONS要求は、SIP-Versionフィールドとリクエストラインを終端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
メッセージの詳細：食べます
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 <進> 2020 </六角>ビア：SIP / 2.0 / TCP host1.example.com;ブランチ= z9hG4bK299342093へ：<SIP：remote-target@example.com> From：<SIP：local-resource@example.com>;タグ= 329429089コールID：受け入れtrws.oicu34958239neffasdhr2345r：アプリケーション/ SDPのCSeq：238923 OPTIONSマックス・フォワード：70のContent-Length：0
This INVITE is malformed, as the SIP Request-URI contains escaped headers.
これは、SIP INVITEリクエスト-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
SIPのINVITE：user@example.comルート=％3Csip：example.com％3E SIP / 2.0：SIP：user@example.comから：SIP：caller@example.net;タグ= 341518最大転送します？7コンタクト：<SIP：caller@host39923.example.net> ID-CALL：escruri.23940-asdfhj-aje3br-234q098w-fawerh2q-h4n5のCSeq：149209342が経由のINVITE：SIP /ホストの-hour.example UDP 2.0 /。 COM;ブランチ= z9hG4bKkdjuwのContent-Type：アプリケーション/ SDPコンテンツの長さ：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 0 = mhandley IP4 192.0.2.1 S = IN 29739 7272939 - C = IN IP4 192.0.2.1 T = 0、M =オーディオ49217 RTP / AVP 0〜12、M =映像3227 RTP / AVP 31 = rtpmap：31 LPC
This INVITE is invalid, as it contains a non-GMT time zone in the SIP Date header field.
これは、INVITEそれは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.
（要素がDateヘッダーフィールドの内容がない限り、その処理に実際に重要であったことをやるべきではないが）、不正な形式としてこの要求を拒否することが許容されます。それはとにかく日付ヘッダフィールドを使用するつもりではなかった場合、要素、それは受け入れ何でリベラルされることを望むものでは完全にこの値を無視することができます。それ以外の場合は、この日付を解釈し、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
user@example.com SIP / 2.0：SIPのINVITE SIP：user@example.comから：SIP：caller@example.net;タグ= 2234923最大フォワード：70のCall-ID：baddate.239423mnsadf3j23lj42 - sedfnm234のCSeq： 1392934が経由のINVITE：SIP / 2.0 / UDP host.example.com;ブランチ= z9hG4bKkdjuw日：金、2010年1月1日午前16時○○分00秒EST連絡先：<SIP：caller@host5.example.net>のContent-Type：アプリケーション/ 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 0 = mhandley IP4 192.0.2.5 S = IN 29739 7272939 - C = IN IP4 192.0.2.5 T = 0、M =オーディオ49217 RTP / AVP 0〜12、M =映像3227 RTP / AVP 31 = 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 <>).
このREGISTERリクエストが不正な形式です。コンタクトヘッダフィールドに含まれるSIP URIエスケープヘッダを有しているので、フィールド名-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
user@example.com;タグ= 998332最大転送します：example.com SIP / 2.0：SIP：user@example.comから：SIP SIPレジスタ70のCall-ID：regbadct.k345asrl3fdbv@10.0.0.1のCSeq：1レジスタを介して：SIP / 2.0 / UDP 135.180.130.133:5060;branch=z9hG4bKkdjuwお問い合わせ：SIP：user@example.comルート=％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.
Toヘッダフィールド内の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経由：SIP / 2.0 / UDP host4.example.com:5060;branch=z9hG4bKkdju43234マックス・フォワード：70から： "ベル、アレクサンダー" <一口：agbell@example.com >;タグ= 433423は：を "ワトソン、トーマス" <SIP：t.watson@example.org>コール番号：badaspec.sdf0234n2nds0a099u23h3hnnw009cdkne3受け入れ：アプリケーション/ SDPのCSeq：3923239 OPTIONS 1：0を
This OPTIONS request is malformed, since the display names in the To and From header fields contain non-token characters but are unquoted.
してヘッダフィールドから、表示名が非トークンの文字が含まれているが、引用符で囲まれていないので、これOPTIONSリクエストは、不正な形式です。
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：SIP / 2.0 / UDP c.example.com:5060;branch=z9hG4bKkdjuwマックス転送します：SIP / 2.0を介してt.watson@example.org 70から：ベル、アレクサンダー<SIP：agbell@example.com >;タグが= 43：ワトソン、トーマス<SIP：t.watson@example.org>コール番号：baddn.31415@c.example.comは受け入れ：アプリケーション/ SDPのCSeq：3923239 OPTIONS 1：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：SIP / 7.0経由t.watson@example.org：SIP / 7.0 / UDP c.example.com;ブランチ= z9hG4bKkdjuwマックス・フォワード：70から：A.ベル<一口：agbell@example.com>。タグ= qweoiqpeに：T.ワトソン<SIP：t.watson@example.org>コールID：badvers.31417@c.example.comのCSeq：1オプション1：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
メッセージの詳細：mismatch01
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：SIP：j.user@example.comから：SIP：caller@example.net;タグは= 34525最大フォワード：6のCall-ID：mismatch01.dj0234sxdfl3のCSeq：8経由のINVITE：SIP / 2.0 / UDP host.example.com;ブランチ= z9hG4bKkdjuw 1：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
メッセージの詳細：mismatch02
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：SIP：j.user@example.comから：SIP：caller@example.net;タグは= 34525最大フォワード：6のCall-ID：mismatch02.dj0234sxdfl3のCSeq：8連絡先をINVITE：<SIP：caller@host.example.net>ビア：SIP / 2.0 / UDP host.example.net;ブランチ= z9hG4bKkdjuwのContent-Type：アプリケーション/ SDPリットル：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 0 = mhandley 29739 7272939 IN IP4 192.0.2.1 C = IN IP4 192.0.2.1のM =オーディオ49217 RTP / AVP 0〜12、M =映像3227 RTP / AVP 31 = 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より良い介して受信機を壊さない：SIP / 2.0 / UDP 192.0.2.105;ブランチ= z9hG4bK2398ndaoeのCall-ID：;、タグ= 39ansfi3：<user@example.com SIP：> bigcode.asdof3uj203asdnf3429uasdhfas3ehjasdfas9iのCSeq：353494〜からINVITE ：<SIP：user@example.edu>;タグ= 902jndnke3のContent-Length：0お問い合わせ：<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：SIP：user@example.comから：SIP：caller@example.org;タグ= 33242マックス・フォワード：3ビア：SIP / 2.0 / UDP 192.0.2.1;ブランチ= z9hG4bKは受け入れ：アプリケーション/ SDPのCall-ID：badbranch.sadonfo23i420jv0as0derf3j3nのCSeq：8オプション1：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.
この要求はから、何のCall-IDが含まれていない、またはフィールドをToヘッダー。
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
user@example.com SIP / 2.0のCSeq：SIPのINVITE SIP / 2.0 / UDP 192.0.2.95;分岐= z9hG4bKkdj.insufのContent-Type：193942ビアINVITEアプリケーション/ SDPリットル：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 0 = IP4 192.0.2.95 S = IN mhandley 29739 7272939 - C = IP4 IN 192.0.2.95 T = 0、M =オーディオ49217 RTP / AVP 0〜12、M =映像3227 RTP / AVP 31 = 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.
このオプションは、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ヘッダーフィールドの内容を見てみます。それは誤りです。フィールドとURIが頻繁に単純化した最初のホップのメッセージに似て要求をToヘッダという事実にもかかわらず、Toヘッダーフィールドには、ルーティング情報が含まれていません。
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：SIP：user@example.comから：SIP：caller@example.net;タグは= 384最大フォワード：3のCall-ID：unkscm.nasdfasser0q239nwsdfasdkl34のCSeq：3923423 OPTIONSのVia：SIP / 2.0 / TCP host9.example.com;ブランチ= 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.
このオプションは、一般的にSIPリクエストのリクエストURIを-に表示されていないIANA登録スキームでのRequest-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を受け入れる可能性がある場合は、見つからない404は、それが受け入れないそれらの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：SIP：user@example.comから：SIP：caller@example.net;タグ= 384最大フォワード：3のCall-ID：novelsc.asdfasser0q239nwsdfasdkl34のCSeq ：3923423 OPTIONSビア：SIP / 2.0 / TCP host9.example.com;ブランチ= z9hG4bKkdjuw39234のコンテンツの長さ：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.
このメッセージは、登録するにはスキーム、から、リクエストのContactヘッダーフィールドが含まれています。メッセージは、構文的に有効です。このメッセージを受信したときにパーサは失敗してはいけません。
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不正な要求応答でこの要求を拒否します：ヘッダフィールドは、SIPを含有することが必要又はAORとしてURIをSIPSれます。
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
タグ= 3234233のCall-ID; <http://www.example.com>：unksm2.daksdj@hyphenated-host.example.comのCSeq：234902 REGISTER example.com SIP / 2.0：ISBN：2983792873からのSIPレジスタマックス・フォワード：70経由：SIP / 2.0 / UDP 192.0.2.21:5060;branch=z9hG4bKkdjuw連絡先：<名：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悪い拡張応答で応答します。
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：SIP：j_user@example.comから：SIP：caller@example.net;タグ= 242etr最大フォワード：6のCall-ID：bext01.0ha0isndaksdjが必要：nothingSupportsThis、nothingSupportsThisEitherプロキシが必要：noProxiesSupportThis、norDoAnyProxiesSupportThisのCSeq：8 OPTIONSビア：SIP / 2.0 / TLS fold-and-staple.example.com;ブランチ= z9hG4bKkdjuwのコンテンツの長さ：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.
この要求を受けたプロキシが、それは、他のは、INVITEと同じように、それを処理します。この要求を受けたエンドポイントは、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
SIPのINVITE：user@example.com SIP / 2.0連絡先：<SIP：caller@host5.example.net>へ：SIP：j.user@example.comから：SIP：caller@example.net;タグ= 8392034 MAX-フォワード：70のCall-ID：invut.0ha0isndaksdjadsfij34n23dのCSeq：235448経由のINVITE：SIP / 2.0 / UDP somehost.example.com;ブランチ= z9hG4bKkdjuwのContent-Type：アプリケーション/ unknownformatのコンテンツの長さ：40
<audio> <pcmu port="443"/> </audio>
<オーディオ> <PCMUポート= "443" /> </オーディオ>
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.
このREGISTERリクエストは、未知の方式でAuthorizationヘッダフィールドが含まれています。要求がうまく形成されています。それを受信したとき、パーサは失敗してはいけません。
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.
プロキシは、それが他のREGISTERを同じようにこの要求を扱います。それが要求を転送する場合、それは転送されたメッセージで修飾されていないこのAuthorizationヘッダフィールドを含むであろう。
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.
フィールドが存在しないかのようにチャレンジレスポンス認証を気にしないレジストラは、単純にこの登録を処理し、Authorizationヘッダーフィールドを無視します。チャレンジレスポンス認証を気にしないレジストラはそれが理解スキームで新しい挑戦を発行し、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
タグ= 87321hj23128最大転送する。j.user@example.com：8のCall-ID：regaut01.0ha0isndaksdj用のCSeq：9338 example.com SIP / 2.0：SIP：j.user@example.comから：SIP SIPレジスタレジスタを介して：SIP / 2.0 / TCP 192.0.2.253;ブランチ= z9hG4bKkdjuw許可：NoOneKnowsThisScheme不透明データ=ここでの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.
メッセージは、マックス・フォワード、とのCSeq値からは、複数のCall-ID、へと要求が含まれています。この要求を受けた要素が壊れてはいけません。
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連絡先：<SIP：caller@host25.example.net>ビア：SIP / 2.0 / UDP 192.0.2.25;ブランチ= z9hG4bKkdjuwマックス・フォワード：70のCSeq：コールIDをINVITE 5 ：multi01.98asdh@192.0.2.1のCSeq：59コールIDをINVITE：SIP：からmulti01.98asdh@192.0.2.2 caller@example.com;タグ= 3413415へ：SIP：user@example.comへ：SIP：その他@ example.netから：SIP：caller@example.net;タグ= 2923420123のContent-Type：アプリケーション/ SDPリットル：154連絡先：<SIP：caller@host36.example.net>マックス・フォワード：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 0 = IP4 192.0.2.25 S = IN mhandley 29739 7272939 - C = IP4 IN 192.0.2.25 T = 0、M =オーディオ49217 RTP / AVP 0〜12、M =映像3227 RTP / AVP 31 = rtpmap：31 LPC
Multiple conflicting Content-Length header field values appear in this request.
競合する複数のContent-Lengthヘッダフィールドの値は、この要求に表示されます。
From a framing perspective, this situation is equivalent to an invalid Content-Length value (or no value at all).
フレーミングの観点から、このような状況では、無効な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.
このメッセージを受信する要素はエラーで応答する必要があります。この要求は、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経由：SIP / 2.0 / UDP host5.example.net;ブランチ= z9hG4bK293423へ：SIP：user@example.comから：SIP：other@example.net;タグ= 3923942コール-ID：mcl01.fhn2323orihawfdoa3o4r52o3irsdfのCSeq：15932 OPTIONSのContent-Length：13マックス・フォワード：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を含むヘッダフィールド値のヴィア2との反応です。メッセージが十分に形成されています。それを受信したときにパーサは失敗してはいけません。
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経由：SIP / 2.0 / UDP 192.0.2.198;ブランチ= z9hG4bK1324923経由：SIP / 2.0 / UDP 255.255.255.255;ブランチ= z9hG4bK1saber23のCall-ID：bcast.0384840201234ksdfak3j2erwedfsASdfのCSeq：SIP：35からINVITEユーザー@ example.com; = 11141343へタグ：SIP：user@example.edu;タグ= 2229のContent-Length：154のContent-Type：アプリケーション/ SDP連絡先：<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 0 = IP4 192.0.2.198 S = IN mhandley 29739 7272939 - C = IP4 IN 192.0.2.198 T = 0、M =オーディオ49217 RTP / AVP 0〜12、M =映像3227 RTP / AVP 31 = rtpmap：31 LPC
This is a legal SIP request with the Max-Forwards header field value set to zero.
これはゼロに設定Max-Forwardsヘッダフィールドの値を持つ法的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：SIP：user@example.comから：SIP：caller@example.net;タグは= 3ghsd41コールID：zeromf.jfasdlfnm2o2l43r5u0asdfas用のCSeq：39234321 OPTIONSのVia：SIP / 2.0 / UDP host1.example.com;ブランチ= z9hG4bKkdjuw2349iマックス・フォワード：0コンテンツ長：0
This register request contains a contact where the 'unknownparam' parameter must be interpreted as a contact-param and not a url-param.
このレジスタ要求は「unknownparam」パラメータは、非接触型のparamではなく、URLのparamとして解釈されなければならない連絡先が含まれています。
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.
このレジスタは成功するはずです。応答は、この結合のために、URLパラメータとして「unknownparam」を含めることはできません。同様に、「unknownparam」後続のフェッチの間の結合のURLパラメータとして現れてはなりません。
Behavior is the same, of course, for any known contact-param parameter names.
行動は、任意の既知の接触-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
example.com SIP / 2.0経由：SIP / 2.0 / UDP saturn.example.com:5060;branch=z9hG4bKkdjuw最大フォワード：5,441：SIP：SIPレジスタwatson@example.comと、タグ= DkfVgjkrtMwaerKKpeに：SIP：・ワトソン@ example.comコールID：cparam01.70710@saturn.example.comのCSeq：2 REGISTER連絡先：SIP：+19725552222@gw1.example.net; unknownparam 1：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.
レジスタは成功するはず、と登録のその後の検索は、URLパラメータとして「unknownparam」を含める必要があります。
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
SIP REGISTER：example.comをSIP / 2.0経由：SIP / 2.0 / UDP saturn.example.com:5060;branch=z9hG4bKkdjuw最大フォワード：5,441：SIP：watson@example.com;タグ= 838293：をSIP：・ワトソン@ example.comコールID：cparam02.70710@saturn.example.comのCSeq：3 REGISTER連絡先：<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におけるエスケープRouteヘッダを含まなければなりません。
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
user@example.com;タグ= 8最大転送します：example.com SIP / 2.0：SIP：user@example.comから：SIP SIPレジスタ70のCall-ID：regescrt.k345asrl3fdbv@192.0.2.1のCSeq：14398234レジスタを介して：SIP / 2.0 / UDP host5.example.com;ブランチ= z9hG4bKkdjuw M：<？SIP：user@example.comルート=％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ヘッダーフィールドは、アプリケーション/ SDPを含んでいないので、特に、応答はSDPボディを含まなくてもよいです。この要求の受信者は、応答が受け入れヘッダフィールドで提供される形式で製剤化することができないことを示す警告/ 399で、許容できない406で応答することができました。 INVITEサポートするすべてのSIPユーザーエージェント（UAが）アプリケーション/ 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
user@example.com SIP / 2.0：SIPのINVITE SIP：j_user@example.com問い合わせ：<SIP：caller@host15.example.net>から：SIP：caller@example.net;タグ= 234最大転送します。 5コールID：受け入れsdp01.ndaksdj9342dasdd：テキスト/ nobodyKnowsThisのCSeqを：経由のINVITE 8：SIP / 2.0 / UDP 192.0.2.15;ブランチ= z9hG4bKkdjuwのコンテンツの長さ：150のContent-Type：アプリケーション/ 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 0 = mhandley IP4 192.0.2.5 S = IN 29739 7272939 - C = IN IP4 192.0.2.5 T = 0、M =オーディオ49217 RTP / AVP 0〜12、M =映像3227 RTP / AVP 31 = 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 3261個の要素によって受け入れられるべきであるRFC 2543（およびいくつかのビスバージョン）あたりの法的なメッセージです。
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明示的にContent-Lengthはありません。 （本体がヌル行の後、データグラム内のすべてのオクテットであると仮定されます。）
o There is no Max-Forwards header field.
O何マックス-Forwardsヘッダフィールドはありません。
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
<SIP：;からSIP / 2.0 / UDP iftgw.example.com：<SIPユーザ=電話+13035551111@ift.client.example.net>レコードルートUserB@example.com SIP / 2.0経由：SIPのINVITE UserB@example.com; MADDR = ss1.example.com>へ：SIP：+16505552222@ss1.example.net;ユーザー=電話のCall-ID：inv2543.1717@ift.client.example.comのCSeq：56コンテンツINVITE - タイプ：アプリケーション/ 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 0 = mhandley IP4 192.0.2.5 IN 29739 7272939 S = - C = IN IP4 192.0.2.5 T = 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.
パーサは、慎重に設計の一部として、エッジ条件と悪質な入力を考慮しなければなりません。多くのインターネットシステムに対する攻撃は、実装が望ましくない方法で動作させるために細工された入力を使用します。この文書に記載されているメッセージの多くは、伝統的に、このような攻撃に使用されるポイントで、パーサーの実装を強調するように設計されています。しかし、この文書は包括的であることをしようとしません。それは思考と計画を刺激する種子ではなく、単純に渡される一連のテストと考えるべきです。
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.
このドキュメントの最後の詳細なレビューはサンディエゴBesprosvan、ビジェイGurbani、シャシクマール、デレク・マクドナルド、Gautham Narasimhan、ニルスOhlmeier、ボブペンフィールド、レイナルドPenno、マーク・プティ・Huguenin、リチャード・シュガーマン、そしてベンカテッシュ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さん、ラフィーAssadi、ゴンサロ・カマリロ、ベン・キャンベル、カレン・ジェニングス、ビジェイGurbani、Sunithaクマール、ロハンマーイ、ジョンピーターソン、マーク・プティ・Huguenin、Vidhi Rastogi、アダムローチ、Bodgey殷Shaohuaによって検討されましたそして、トム・テイラー。
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.
[SIP-SEC]でS / MIMEの例を構築し、この文書と自分の仕事のマルチパート/ MIMEセクションへの貢献のためのカレン・ジェニングスとエリックレスコラに感謝します。以前のバージョンでは、メッセージのパーサの検証を実行するためのいくつかのメッセージを寄与するとKundanシンにニールDeasonに感謝します。
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.
ジャン=フランソワラバ、Hemant Agrawalさん、ヘンリーSinnreich、デビッドDevanatham、ジョーPizzimenti、マット・キャノン、ジョン・ハーティ、全体MCI IPOPデザインチーム、スコット・オートン、以下の個人は、この文書の開発の初期段階で重要なコメントを提供しましたMCI、3Comの、シスコ、ルーセント、およびNortelからグレッグOsterhout、パットSollee、ダグWeisenberg、ダニーMistryさん、スティーブ・マッキノン、そしてデニス・イングラム、デニス・キャバレロ、トム・レッドマン、イリヤ・殺害され、パットSollee、ジョンTruetkenなど。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]レズニック、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "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]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]バーナーズ - リー、T.、フィールディング、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]ジェニングス、C.及びK.小野、進行、2005年7月に、ワーク "例コールがSIPセキュリティメカニズムを使用して流れます"。
Appendix A. Bit-Exact Archive of Each Test Message
各テストメッセージの付録A.のビット正確なアーカイブ
The following text block is an encoded, gzip-compressed TAR archive of files that represent each of the example messages discussed in Section 3.
次のテキストブロックは、第3節で説明した例示的なメッセージのそれぞれを表すファイルの符号化され、gzipで圧縮されたtarアーカイブです。
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 -").
そのまま圧縮されたアーカイブファイルを復元するには、この文書のテキストは（出力をファイルにリダイレクトするかを「タール-xzvf - 」パイプする必要があります）次のPerlスクリプトへの入力として渡すことができます。
#!/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.
あるいは、ベース64符号化されたブロックは、文書構造線を除去するために手動で編集し、任意のベース64復号ユーティリティへの入力として供給することができます。
A.1. Encoded Reference Messages
A.1。エンコードされた参照メッセージ
-- 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
- BEGINメッセージアーカイブ - 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 + xXydxSNXafJ2Y226Z3oPk4 c5u 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 + Q4j UrDpaHrL8jsXZ / r5hAqAFVM1q6zWJ0ZK + xh49GYj Ft7TqP9LFLHtMed / 5CwM + 3 /アラブ首長国連邦/ 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 NYiCRJEL9kjssMWe4AE2dOwIfkowlBC8MJO9FCGFfnlY mDR6TOQRohDhkccf 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 r0SBivc CDq1jRK5moYZV1S44TjjO3o5AzAlZCbTr + 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 / 8 lANL5P8Yd / 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/ 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 --
VvAdlxIKjgILniUHqGCvqlQ + DXC / z9lSrWmT6439i7fvntfnwYZ + q7ni3EX2 ypZTnb8M7 + yVtze2hFuX5PKVxvXVa + Duna1r98rXdpW1Sm6TvLFTXdsqmls7 SL5wcS4noO3du5XS + U18z9x + vfZGSblz4976xRuXLzxYntPuGMrayuaVO6v3 LOECuUqK6t35N4zta2QDg5vG7g6wXRm8LlX0da24s3a19vollxB9d7NcXbtz d3O5EAYuzWho2v5Sbx8uBpaqij6KxZ4Rdq0DRLJsUCsCtVRSAtiKVEXMSVgF JVHJSUpx6V5tT7hXuyddvyOU7 + 6DvRu65BThjXJxOZPppt1bjBHARJstqEVs fsUsWapubrO1vExs74dhs9YwXJ3BynxN3yPqQtFiQ5 / T / YKMlVKRlAAsEaJl 2cjhi5g96XXsnqUeG3ez5LJ1aCUOiHlRzEtZ7vLaxvQUGwnIL2 / TE3gcqNfq RD / mvZQ690qpYTvEeTXGe5MQQ2qej562v1eX4Ganp64Qw7CSHDmoQDxvkHdc m7DVQxKdB7x9 / PbzL535 +インベントリ/ 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 // EAH B5E // 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 + 29nu2 wtS4DvXvQBu / Dx5SKVSu + LQtgNfq / 9RckP9Jjf + 3BP + XN2AhVQY2ahLp + eFqs33eVlBh /ワンセグ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 / + 3ワット/ 8 / rP7vR1X + RTkYHAaDvukOPe6eDYYJ4550pQ + MfwWfv1ZN4PVl4EqLjr / 6Sa0i VatGrhx4fb9 SH / N + GEW0Yh1xbBxzDz5R8TEPvzs8OjlEkVmxWKk72KeMLzHK VLO / sOsEns8ZWyJ6RCKR2 + B / Fi7jv0lxjf8bx3 / BxmHEGmo / esuFfoQq + 7Gv gHhQ1bGT9wWsvFHR / DcKFUlpCCbDWHTZMsLimMTBdr7aQQrPYdCNqelYNoQQ Mx8iiPsCGpqLtYSEUNvJBxcv72Xy / 4kYjvlQdseflgKslf9NWsb / Zo3 / m8X / kt1Mx8S1ozCCpnk6NK6rAX8T2QAZVPI6G2AT + D8mW8Z / Ssr4b5Fa / 78リットル/ 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 qf1h2oZ9tiepwfABAh0chpwEwO4KUJF9fXq HADIQyoQCJxgObITABz / fYn1F 9SfIE + kGG017n1jWvuLucK3sQh21aBaJDBF6igO2d36MQ6VqIBmJgCvw2gHw WglY6lJqtzWsd2ZhAGom / ZT6mSXYQzx9ygE6U8 + O9ym9MXtfWQPI3Axrv2AK / fwt6 / 8EL9r / AV3 / DVN / qix9vb70TCNHgDOQG4Apb + TzMQnJyKTCirE29xVM e5QYFZ69a / V4AitCULYd4Lr0Rz3qUY / PfPwLcaRGXQDwAAA = - ENDメッセージアーカイブ -
Authors' Addresses
著者のアドレス
Robert J. Sparks (editor) Estacado Systems
ロバート・J・スパークス（エディタ）Estacadoシステム
EMail: RjS@estacado.net
メールアドレス：RjS@estacado.net
Alan Hawrylyshen Ditech Networks 200 - 1167 Kensington Cr. NW Calgary, Alberta T2N 1X7 Canada
アランHawrylyshen Ditechネットワーク200 - 1167ケンジントンクロム。 NWカルガリー、アルバータ州T2N 1X7カナダ
Phone : +1.403.806.3366 EMail : ahawrylyshen@ditechcom.com
電話：+1.403.806.3366電子メール：ahawrylyshen@ditechcom.com
Alan Johnston Avaya St. Louis, MO 63124
アラン・ジョンストンアバイアセントルイス、MO 63124
EMail: alan@sipstation.com
メールアドレス：alan@sipstation.com
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07052
ジョナサン・ローゼンバーグシスコシステムズ600 Lanidexプラザパーシッパニー、NJ 07052
Phone: +1 973 952 5000 EMail: jdrosen@cisco.com URI: http://www.jdrosen.net
電話：+1 973 952 5000 Eメール：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コンピュータサイエンスビル、ニューヨーク、NY 10027米国のヘニングSchulzrinneとコロンビア大学学部
Phone: +1 212 939 7042 EMail: hgs@cs.columbia.edu URI: http://www.cs.columbia.edu
電話：+1 212 939 7042 Eメール：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。