RFC4475 日本語訳
4475 Session Initiation Protocol (SIP) Torture Test Messages. R.Sparks, Ed., A. Hawrylyshen, A. Johnston, J. Rosenberg, H.Schulzrinne. May 2006. (Format: TXT=93276 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
エド、ネットワークワーキンググループR.をスパークさせます。コメントのために以下を要求してください。 4475年のエスタカードシステムカテゴリ: 情報のA.Hawrylyshen DitechはシスコシステムズH.Schulzrinneコロンビア大学2006年5月にA.ジョンストン・Avaya J.ローゼンバーグをネットワークでつなぎます。
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).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This informational document gives examples of Session Initiation Protocol (SIP) test messages designed to exercise and "torture" a SIP implementation.
この情報のドキュメントはメッセージが運動するように設計したテストと「拷問」というSession Initiationプロトコル(SIP)に関する例にSIP実装を与えます。
Table of Contents
目次
1. Overview ........................................................3
2. Document Conventions ............................................3
2.1. Representing Long Lines ....................................4
2.2. Representing Non-printable Characters ......................4
2.3. Representing Long Repeating Strings ........................5
3. SIP Test Messages ...............................................5
3.1. Parser Tests (syntax) ......................................5
3.1.1. Valid Messages ......................................5
3.1.1.1. A Short Tortuous INVITE ....................5
3.1.1.2. Wide Range of Valid Characters .............8
3.1.1.3. Valid Use of the % Escaping Mechanism ......9
3.1.1.4. Escaped Nulls in URIs .....................11
3.1.1.5. Use of % When It Is Not an Escape .........11
3.1.1.6. Message with No LWS between
Display Name and < ........................12
1. 概要…3 2. コンベンションを記録してください…3 2.1. 表すことは長い間、立ち並んでいます…4 2.2. 非印刷可能なキャラクターを表します…4 2.3. 長い繰り返しているストリングを表します…5 3. テストメッセージをちびちび飲んでください…5 3.1. パーサは(構文)をテストします…5 3.1.1. 有効なメッセージ…5 3.1.1.1. 短いねじれている招待…5 3.1.1.2. 広範囲の有効なキャラクター…8 3.1.1.3. メカニズムから逃げる%の有効な使用…9 3.1.1.4. URIでヌルから逃げます…11 3.1.1.5. それであるときに、%の使用はエスケープではありません…11 3.1.1.6. ディスプレイ名と<の間のLWSのないメッセージ…12
Sparks, et al. Informational [Page 1] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[1ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
3.1.1.7. Long Values in Header Fields ..............12
3.1.1.8. Extra Trailing Octets in a UDP Datagram ...14
3.1.1.9. Semicolon-Separated Parameters in
URI User Part .............................16
3.1.1.10. Varied and Unknown Transport Types .......16
3.1.1.11. Multipart MIME Message ...................17
3.1.1.12. Unusual Reason Phrase ....................18
3.1.1.13. Empty Reason Phrase ......................19
3.1.2. Invalid Messages ...................................20
3.1.2.1. Extraneous Header Field Separators ........20
3.1.2.2. Content Length Larger Than Message ........20
3.1.2.3. Negative Content-Length ...................21
3.1.2.4. Request Scalar Fields with
Overlarge Values ..........................22
3.1.2.5. Response Scalar Fields with
Overlarge Values ..........................23
3.1.2.6. Unterminated Quoted String in
Display Name ..............................24
3.1.2.7. <> Enclosing Request-URI ..................25
3.1.2.8. Malformed SIP Request-URI (embedded LWS) ..26
3.1.2.9. Multiple SP Separating
Request-Line Elements .....................27
3.1.2.10. SP Characters at End of Request-Line .....28
3.1.2.11. Escaped Headers in SIP Request-URI .......29
3.1.2.12. Invalid Timezone in Date Header Field ....30
3.1.2.13. Failure to Enclose name-addr URI in <> ...31
3.1.2.14. Spaces within addr-spec ..................31
3.1.2.15. Non-token Characters in Display Name .....32
3.1.2.16. Unknown Protocol Version .................32
3.1.2.17. Start Line and CSeq Method Mismatch ......33
3.1.2.18. Unknown Method with CSeq Method Mismatch .33
3.1.2.19. Overlarge Response Code ..................34
3.2. Transaction Layer Semantics ...............................34
3.2.1. Missing Transaction Identifier .....................34
3.3. Application-Layer Semantics ...............................35
3.3.1. Missing Required Header Fields .....................35
3.3.2. Request-URI with Unknown Scheme ....................36
3.3.3. Request-URI with Known but Atypical Scheme .........36
3.3.4. Unknown URI Schemes in Header Fields ...............37
3.3.5. Proxy-Require and Require ..........................37
3.3.6. Unknown Content-Type ...............................38
3.3.7. Unknown Authorization Scheme .......................38
3.3.8. Multiple Values in Single Value Required Fields ....39
3.3.9. Multiple Content-Length Values .....................40
3.3.10. 200 OK Response with Broadcast Via Header
Field Value .......................................40
3.3.11. Max-Forwards of Zero ..............................41
3.3.12. REGISTER with a Contact Header Parameter ..........42
3.1.1.7. ヘッダーフィールドにおける長い値…12 3.1.1.8. UDPデータグラムにおける…付加的な引きずっている八重奏14 3.1.1.9. URIユーザのセミコロンで切り離されたパラメタは離れています…16 3.1.1.10. 様々で未知の輸送タイプ…16 3.1.1.11. 複合MIMEメッセージ…17 3.1.1.12. 珍しい理由句…18 3.1.1.13. 理由句を空にしてください…19 3.1.2. 無効のメッセージ…20 3.1.2.1. 異質なヘッダーフィールド分離…20 3.1.2.2. メッセージより大きいコンテンツの長さ…20 3.1.2.3. 否定的コンテンツの長さ…21 3.1.2.4. 大き過ぎている値でスカラの分野を要求してください…22 3.1.2.5. 大き過ぎている値がある応答スカラ分野…23 3.1.2.6. ディスプレイ名の引用文字列をUnterminatedしました…24 3.1.2.7. 要求URIを同封する<>…25 3.1.2.8. 奇形の一口要求URI(埋め込まれたLWS)。26 3.1.2.9. 複数のSP分離要求Line Elements…27 3.1.2.10. 要求行の終わりのSPキャラクター…28 3.1.2.11. 一口要求URIでヘッダーから逃げます…29 3.1.2.12. 日付のヘッダーフィールドにおける無効のタイムゾーン…30 3.1.2.13. <>の…Enclose名前-addr URIへの失敗31 3.1.2.14. addr-仕様の中の空間…31 3.1.2.15. ディスプレイ名の非トークンキャラクター…32 3.1.2.16. 未知のプロトコルバージョン…32 3.1.2.17. 線とCSeqメソッドミスマッチを始動してください…33 3.1.2.18. CSeqメソッドミスマッチ.33 3.1.2.19がある未知のメソッド。 大き過ぎている応答コード…34 3.2. トランザクション層の意味論…34 3.2.1. トランザクション識別子を逃します…34 3.3. 応用層意味論…35 3.3.1. なくなった必要なヘッダーフィールド…35 3.3.2. 未知がある要求URI体系…36 3.3.3. 知られるのにもかかわらずの、非定型的であるのがある要求URI体系…36 3.3.4. ヘッダーフィールドにおける未知のURI体系…37 3.3.5. プロキシで必要であり、必要です。37 3.3.6. 未知のコンテントタイプ…38 3.3.7. 未知の承認体系…38 3.3.8. ただ一つの値における複数の値が分野を必要としました…39 3.3.9. 複数のコンテンツの長さ値…40 3.3.10. 200 ヘッダーフィールド値を通して放送がある状態で、応答を承認してください…40 3.3.11. 前方へゼロ歳のマックス…41 3.3.12. 連絡ヘッダーパラメタとともに記名してください…42
Sparks, et al. Informational [Page 2] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[2ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
3.3.13. REGISTER with a url-parameter .....................42
3.3.14. REGISTER with a URL Escaped Header ................43
3.3.15. Unacceptable Accept Offering ......................44
3.4. Backward Compatibility ....................................44
3.4.1. INVITE with RFC 2543 Syntax ........................44
4. Security Considerations ........................................45
5. Acknowledgements ...............................................46
6. Informative References .........................................46
Appendix A. Bit-Exact Archive of Each Test Message ................47
A.1. Encoded Reference Messages ................................48
3.3.13. url-パラメタがあるREGISTER…42 3.3.14. URLの逃げられたヘッダーとともに記名してください…43 3.3.15. 容認できなさ、提供を受け入れてください…44 3.4. 後方の互換性…44 3.4.1. RFCと共に2543年の構文を招待してください…44 4. セキュリティ問題…45 5. 承認…46 6. 有益な参照…それぞれのテストメッセージの46の付録のA.のビット正確なアーカイブ…47 A.1。 参照メッセージをコード化します…48
1. Overview
1. 概要
This document is informational and is NOT NORMATIVE on any aspect of SIP.
このドキュメントは、情報であり、SIPのどんな局面のNOT NORMATIVEです。
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]で定義されて、このドキュメントはSession Initiationプロトコルの最新版(2.0)に基づくテストメッセージを含んでいます。 いくつかのメッセージが[RFC3264]で説明されるようにSession記述プロトコル(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.
メッセージは、テキストにあいまいさを避けて、インターネット草稿レイアウト必要条件を満たすのに1セットのマーク付けコンベンションを使用することで提示されます。 どんな残っているあいまいさも取り除くために、それぞれのメッセージの少し正確なバージョンは付録でカプセル化されます。
2. Document Conventions
2. ドキュメントコンベンション
This document contains many example SIP messages. Although SIP is a text-based protocol, many of these examples cannot be unambiguously rendered without additional markup due to the constraints placed on the formatting of RFCs. This document defines and uses the markup
このドキュメントは多くの例のSIPメッセージを含んでいます。 SIPはテキストベースのプロトコルですが、RFCsの形式に置かれた規制のため追加マーク付けなしでこれらの例の多くを明白に表すことができません。 このドキュメントは、マークアップを定義して、使用します。
Sparks, et al. Informational [Page 3] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[3ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
defined in this section to remove that ambiguity. This markup uses the start and end tag conventions of XML but does not define any XML document type.
このセクションで、そのあいまいさを取り除くために定義されます。 このマークアップは、XMLの始めと終了タグコンベンションを使用しますが、少しのXMLドキュメントタイプも定義しません。
The appendix contains an encoded binary form of all the messages and the algorithm needed to decode them into files.
付録はファイルの中にそれらを解読するのに必要であるすべてのメッセージとアルゴリズムのコード化された二部形式を含んでいます。
2.1. Representing Long Lines
2.1. 長い台詞を表します。
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>ヘッダー名: まず最初に、値、reallylongの2番目の値は3番目に</allOneLine>を評価します。
Note that this is NOT SIP header-line folding, where different strings of bits have equivalent meaning.
ビットの異なったストリングには同等な意味があるところでこれがNOT SIPヘッダー系列の折り重なりであることに注意してください。
2.2. Representing Non-printable Characters
2.2. 非印刷可能なキャラクターを表します。
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.
いくつかの例が2進のメッセージ本体を含んでいるか、または非ASCII範囲UTF-8を含むヘッダーフィールド値がキャラクタをコード化しました。 これらは1組の1八重奏あたりの16進数字として<十六進法/>タグの間でここでレンダリングされます。 このレンダリングは引用文字列でさえ適用されます。
Sparks, et al. Informational [Page 4] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[4ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
The following represent the same string of bits:
以下はビットの同じストリングを表します:
Header-name: value one
Header-name: value<hex>206F6E</hex>e
ヘッダー名: 1つのHeader-名前を評価してください: 値の<十六進法>206F6E</十六進法>e
The following is a Subject header field containing the euro symbol:
↓これはユーロシンボルを含むSubjectヘッダーフィールドです:
Subject: <hex>E282AC</hex>
Subject: <十六進法>E282AC</十六進法>。
2.3. Representing Long Repeating Strings
2.3. 長い繰り返しているストリングを表します。
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.
いくつかの例が繰り返しているビット列で作成された非常に大きいデータ値を含んでいます。 ものは、ここでいくらかの_整数>値の</反復<繰返し回数=>を使用することでレンダリングされるでしょう。 <十六進法>のように、このレンダリングは引用文字列でさえ適用されます。
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
例えば、<繰返し回数が3>abc</反復>と等しいときに、値の"abcabcabc"をレンダリングできます。 「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
1の値があるヘッダーフィールドがGoogleで検索するAマックス-フォワードはここでレンダリングされるでしょう。
Max-Forwards: 1<repeat count=100>0</repeat>
マックス-フォワード: 1 <繰返し回数は100>0</反復>と等しいです。
3. SIP Test Messages
3. 一口テストメッセージ
3.1. Parser Tests (syntax)
3.1. パーサテスト(構文)
3.1.1. Valid Messages
3.1.1. 有効なメッセージ
3.1.1.1. A Short Tortuous INVITE
3.1.1.1. 短いねじれている招待
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 切り離されたコンマと別々に記載されたヘッダーの両方が値をさばきます。
Sparks, et al. Informational [Page 5] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[5ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
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.
o それがジェネリック-paramに関して定義されるならシンタクス上無効の値がある未知のヘッダーフィールド。
o unusual header field ordering.
o 珍しいヘッダーフィールド注文。
o unusual header field name character case.
o 珍しいヘッダーフィールド名前キャラクタ事件。
o unknown parameters of a known header field.
o 知られているヘッダーフィールドの未知のパラメタ。
o a uri parameter with no value.
o 値のないuriパラメタ。
o a header parameter with no value.
o 値のないヘッダーパラメタ。
o integer fields (Max-Forwards and CSeq) with leading zeros.
o 整数は先行ゼロで(前方へマックスとCSeq)をさばきます。
All elements should treat this as a well-formed request.
すべての要素が整形式の要求としてこれを扱うはずです。
The UnknownHeaderWithUnusualValue header field deserves special attention. If this header field were defined in terms of comma- separated values with semicolon-separated parameters (as would many of the existing defined header fields), this would be invalid. However, since the receiving element does not know the definition of the syntax for this field, it must parse it as a header value. Proxies would forward this header field unchanged. Endpoints would ignore the header field.
UnknownHeaderWithUnusualValueヘッダーフィールドは特別な注意に値します。 このヘッダーフィールドがセミコロンで切り離されたパラメタ(既存の定義されたヘッダーフィールドの多くであるだろうことのような)でコンマの切り離された値で定義されるなら、これは無効でしょうに。 しかしながら、受信要素が構文の定義をこの分野に知らないので、それはヘッダー値としてそれを分析しなければなりません。 プロキシは変わりがない状態でこのヘッダーフィールドを進めるでしょう。 終点はヘッダーフィールドを無視するでしょう。
Sparks, et al. Informational [Page 6] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[6ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
Message Details : wsinv
メッセージの詳細: wsinv
INVITE sip:vivekg@chair-dnrc.example.com;unknownparam SIP/2.0
TO :
sip:vivekg@chair-dnrc.example.com ; tag = 1918181833n
from : "J Rosenberg \\\"" <sip:jdrosen@example.com>
;
tag = 98asjd8
MaX-fOrWaRdS: 0068
Call-ID: wsinv.ndaksdj@192.0.2.1
Content-Length : 150
cseq: 0009
INVITE
Via : SIP / 2.0
/UDP
192.0.2.2;branch=390skdjuw
s :
NewFangledHeader: newfangled value
continued newfangled value
UnknownHeaderWithUnusualValue: ;;,,;;,;
Content-Type: application/sdp
Route:
<sip:services.example.com;lr;unknownwith=value;unknown-no-value>
v: SIP / 2.0 / TCP spindle.example.com ;
branch = z9hG4bK9ikj8 ,
SIP / 2.0 / UDP 192.168.255.111 ; branch=
z9hG4bK30239
m:"Quoted string \"\"" <sip:jdrosen@example.com> ; newparam =
newvalue ;
secondparam ; q = 0.33
INVITE一口: vivekg@chair-dnrc.example.com;unknownparam SIP/2.0 TO: ちびちび飲んでください: vivekg@chair-dnrc.example.com 以下から=1918181833nにタグ付けをしてください。 「「Jローゼンバーグ\\\」」<一口: jdrosen@example.com 、gt;、。 =98asjd8 MaX-fOrWaRdSにタグ付けをしてください: 0068年の呼び出しID: wsinv.ndaksdj@192.0.2.1 コンテンツの長さ: 150cseq: 以下を通って0009年の招待 一口/ 2.0 /UDP192.0.2.2; ブランチは390skdjuw sと等しいです: NewFangledHeader: 新式の値は新式の値のUnknownHeaderWithUnusualValueを続けていました: ;;,,;;,; コンテントタイプ: アプリケーション/sdp Route: <一口: services.example.com; lr; unknownwithは値と等しいです; 未知の値がないことの>対以下 SIP/2.0/TCP spindle.example.com。 ブランチ=z9hG4bK9ikj8、SIP/2.0/UDP192.168.255.111。 「ブランチ=z9hG4bK30239m:、「」 」 <一口: 引用文字列\」 \ jdrosen@example.com 、gt;、。 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
0 0v=0 o=mhandley29739 7272939IN IP4 192.0.2.3 s=c=IN IP4 192.0.2.4t=mがオーディオの49217RTP/AVPと等しい、0、12m、=ビデオ3227RTP/AVP31a=rtpmap: 31LPC
Sparks, et al. Informational [Page 7] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[7ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
3.1.1.2. Wide Range of Valid Characters
3.1.1.2. 広範囲の有効なキャラクター
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 Methodはトークンからの非アルファキャラクタを含んでいます。 %がこの分野への拡張文字でないことに注意してください。 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 Fromヘッダーフィールド価値における名前-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 Call-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 名前とUTF8-NONASCII値には非alphanumトークンキャラクタを伴う未知のヘッダーフィールド(合っている拡張ヘッダー)があります。
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リストに生成するでしょう。
Sparks, et al. Informational [Page 8] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[8ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
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_unusual.URI~、(-いてください、確実に)、+ それが$/気が狂っていないか、/。* :それ、+には=1があって、*上席$wo~dもおかしくしてください、(-、それ、)、@example以下を通って.com一口/2.0</allOneLine>。 SIP/2.0/TCP host1.example.com;branch=z9hG4bK-.!%66*_+`'~ <allOneLine> To: 「ベル: \<十六進法>07</十六進法>NUL: \<十六進法>00</十六進法>DEL: \<の十六進法の>の7Fの</十六進法>」<一口: 1_unusual.URI~、(-いてください、確実に)、+ それが$/気が狂っていないか、/。* @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! '. 本当に、%'おもしろいMethod0123456789の_*+~マックス-フォワード: 255 <allOneLine> extensionHeader-!.%*+_`'~: <十六進法>EFBBBFE5A4A7E5819CE99BBB</十六進法>allOneLine></コンテンツの長さ: 0
3.1.1.3. Valid Use of the % Escaping Mechanism
3.1.1.3. メカニズムから逃げる%の有効な使用
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には、一口があります: userpartに埋め込まれた user@example.com 。 それがexample.netに意味するかもしれないことはこのドキュメントの範囲を超えています。
o The From and To URIs have escaped characters in their userparts.
o FromとTo URIは彼らの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 Contact URIはURIパラメタでキャラクタから逃げました。 「名前」uri-パラメタが値を持っている注意は「%41インチを評価します」。(41インチは"valueA"に同等ではありません)。 [RFC3986]に従って、URIコンポーネントを非エスケープさせるのは再帰的に決して実行されません。
Sparks, et al. Informational [Page 9] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[9ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
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-ユリ、SIPS-URI、およびReason-句の拡張で起こるだけです。
Message Details : esc01
メッセージの詳細: esc01
INVITE sip:sips%3Auser%40example.com@example.net SIP/2.0
To: sip:%75se%72@example.com
From: <sip:I%20have%20spaces@example.net>;tag=938
Max-Forwards: 87
i: esc01.239409asdfakjkn23onasd0-3234
CSeq: 234234 INVITE
Via: SIP/2.0/UDP host5.example.net;branch=z9hG4bKkdjuw
C: application/sdp
Contact:
<sip:cal%6Cer@host5.example.net;%6C%72;n%61me=v%61lue%25%34%31>
Content-Length: 150
INVITE一口: sips%3Auser%40example.com@example.net SIP/2.0To: 一口: %75se%72@example.com From: <一口: I%20have%20spaces@example.net 、gt;、; 前方へ=938最大にタグ付けをしてください: 87、i: esc01.239409asdfakjkn23onasd0-3234 CSeq: 234234 以下を通って招待 一口/2.0/UDP host5.example.net; ブランチはz9hG4bKkdjuw Cと等しいです: アプリケーション/sdp Contact: <一口: cal%6Cer@host5.example.net;%6C%72;n%61me はv%61lue%25%34%31>コンテンツの長さと等しいです: 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
0 0v=0 o=mhandley29739 7272939IN IP4 192.0.2.1 s=c=IN IP4 192.0.2.1t=mがオーディオの49217RTP/AVPと等しい、0、12m、=ビデオ3227RTP/AVP31a=rtpmap: 31LPC
Sparks, et al. Informational [Page 10] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[10ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
3.1.1.4. Escaped Nulls in URIs
3.1.1.4. URIにおける逃げられたヌル
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を含んでいます。 メッセージは整形式です--パーサはこのメッセージを受け入れなければなりません。 早まってユーザ名を短くしないように、この要求で記録のAddress(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
REGISTER一口: example.com SIP/2.0To: 一口: null-%00-null@example.com From: 一口: null-%00-null@example.com;tag は839923423のマックス-フォワードと等しいです: 70呼び出しID: escnull.39203ndfvkjdasfkq3w4otrq0adsfdfnavd CSeq: 14398234は以下を通って登録されます。 一口/2.0/UDP host5.example.com; ブランチはz9hG4bKkdjuw接触と等しいです: <一口: %00@host5.example.com 、gt;、接触: <一口: %00%00@host5.example.com 、gt;、L: 0
3.1.1.5. Use of % When It Is Not an Escape
3.1.1.5. それがエスケープでないことの%の使用
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 要求メソッドは未知です。 それはREGISTERに同等ではありません。
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 「部分というToとFromヘッダーフィールドのディスプレイ名はそうです」という%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 このメッセージには、3ではなく2つのContactヘッダーフィールド値があります。 <一口: alias2@host2.example.com 、gt;、a 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でこのメッセージを拒絶するでしょう。
Sparks, et al. Informational [Page 11] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[11ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
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
45R一口: RE%47IST%registrar.example.com SIP/2.0To: 「45インチの<一口: %Z% resource@example.com 、gt;、From:、」 「45インチの<一口: %Z% resource@example.com 、gt;、; =f232jadfj23呼び出しIDにタグ付けをしてください:、」 esc02.asdfnqwo34rq23i34jrjasdcnl23nrlknsdf Via: 一口/2.0/TCP host.example.com; ブランチ=z9hG4bK209%fzsnel234 CSeq: 29344 re%47IST%45Rは以下をマックスと同じくらい進めます。 70 接触: <一口: alias1@host1.example.com 、gt;、C%6Fntact: <一口: alias2@host2.example.com 、gt;、接触: <一口: alias3@host3.example.com 、gt;、l: 0
3.1.1.6. Message with No LWS between Display Name and <
3.1.1.6. ディスプレイ名と<の間のLWSのないメッセージ
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.
ディスプレイ名のトークンとFromヘッダーフィールド価値における<の間には、LWSが全くないので、このOPTIONS要求はRFC3261で文法単位で有効ではありません。 これはRFC3261が改訂されているとき取り除かれる仕様バグとして特定されました。 Elementsは、この要求が整形式であると受け入れるべきです。
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一口: user@example.com SIP/2.0To: 一口: user@example.com From: 訪問者<一口: caller@example.com 、gt;、; =323マックス-フォワードにタグ付けをしてください: 70呼び出しID: lwsdisp.1234abcd@funky.example.com CSeq: 以下を通って60のオプション SIP/2.0/UDP funky.example.com; ブランチはz9hG4bKkdjuw lと等しいです: 0
3.1.1.7. Long Values in Header Fields
3.1.1.7. ヘッダーフィールドにおける長い値
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.
o Fromヘッダーフィールドは、長いヘッダーパラメタ名を持って、非常に長いタグを特に評価します。
o The Call-ID is one long token.
o Call-IDは1つの長いトークンです。
Sparks, et al. Informational [Page 12] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[12ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
Message Details : longreq
メッセージの詳細: longreq
INVITE sip:user@example.com SIP/2.0
<allOneLine>
To: "I have a user name of
<repeat count=10>extreme</repeat> proportion"
<sip:user@example.com:6000;
unknownparam1=very<repeat count=20>long</repeat>value;
longparam<repeat count=25>name</repeat>=shortvalue;
very<repeat count=25>long</repeat>ParameterNameWithNoValue>
</allOneLine>
<allOneLine>
F: sip:
<repeat count=5>amazinglylongcallername</repeat>@example.net
;tag=12<repeat count=50>982</repeat>424
;unknownheaderparam<repeat count=20>name</repeat>=
unknowheaderparam<repeat count=15>value</repeat>
;unknownValueless<repeat count=10>paramname</repeat>
</allOneLine>
Call-ID: longreq.one<repeat count=20>really</repeat>longcallid
CSeq: 3882340 INVITE
<allOneLine>
Unknown-<repeat count=20>Long</repeat>-Name:
unknown-<repeat count=20>long</repeat>-value;
unknown-<repeat count=20>long</repeat>-parameter-name =
unknown-<repeat count=20>long</repeat>-parameter-value
</allOneLine>
Via: SIP/2.0/TCP sip33.example.com
v: SIP/2.0/TCP sip32.example.com
V: SIP/2.0/TCP sip31.example.com
Via: SIP/2.0/TCP sip30.example.com
ViA: SIP/2.0/TCP sip29.example.com
VIa: SIP/2.0/TCP sip28.example.com
VIA: SIP/2.0/TCP sip27.example.com
via: SIP/2.0/TCP sip26.example.com
viA: SIP/2.0/TCP sip25.example.com
vIa: SIP/2.0/TCP sip24.example.com
vIA: SIP/2.0/TCP sip23.example.com
V : SIP/2.0/TCP sip22.example.com
v : SIP/2.0/TCP sip21.example.com
V : SIP/2.0/TCP sip20.example.com
v : SIP/2.0/TCP sip19.example.com
Via : SIP/2.0/TCP sip18.example.com
Via : SIP/2.0/TCP sip17.example.com
Via: SIP/2.0/TCP sip16.example.com
Via: SIP/2.0/TCP sip15.example.com
Via: SIP/2.0/TCP sip14.example.com
Via: SIP/2.0/TCP sip13.example.com
INVITE一口: user@example.com SIP/2.0<allOneLine>To: 「私は<繰返し回数のユーザ名が10>の極端な</反復>割合との等しさにする」<一口: user@example.com :6000。 まさしくその<unknownparam1=繰返し回数は20>の長い</反復>価値と等しいです。 25>名前</反復longparam<繰返し回数=>はshortvalueと等しいです。 まさしくその<繰返し回数は25>の長い</反復>ParameterNameWithNoValue></allOneLine><allOneLine>Fと等しいです: 一口: <繰返し回数は 5>amazinglylongcallername</repeat>@example.net と等しいです; =12にタグ付けをしてください、lt;、カウント=50を繰り返してください、gt;、982 </反復>424; 15>値の</反復unknowheaderparam<20>名前</反復unknownheaderparam<繰返し回数=>=繰返し回数=>; unknownValueless<反復カウント=10>paramname</反復></allOneLine>Call-ID: longreq1つの<繰返し回数が本当に20>と等しい、</反復>longcallid CSeq: 3882340 <の>の未知の<の反復カウントallOneLine=20>の長い</反復>-名を招待してください: 未知の<の繰返し回数は20>の長い</反復>-価値と等しいです。 未知の<の繰返し回数は20>の長い反復>-パラメタ</価値の</allOneLine>未知の<の20の>の長い反復>-パラメタ</名=繰返し回数=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 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
Sparks, et al. Informational [Page 13] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[13ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
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 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; =192.0.2を受け取る、.5。 まさしくその<ブランチ=繰返し回数は50の>の長い</反復>branchvalue</allOneLine>マックス-フォワードと等しいです: 70 <allOneLine>接触: <一口: <反復カウント=5>amazinglylongcallername</反復>@host5.example.net></allOneLine>コンテントタイプ: アプリケーション/sdp l: 150
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
0 0v=0 o=mhandley29739 7272939IN IP4 192.0.2.1 s=c=IN IP4 192.0.2.1t=mがオーディオの49217RTP/AVPと等しい、0、12m、=ビデオ3227RTP/AVP31a=rtpmap: 31LPC
3.1.1.8. Extra Trailing Octets in a UDP Datagram
3.1.1.8. UDPデータグラムにおける余分な引きずっている八重奏
This message contains a single SIP REGISTER request, which ostensibly arrived over UDP in a single datagram. The packet contains extra octets after the body (which in this case has zero length). The extra octets happen to look like a SIP INVITE request, but (per section 18.3 of [RFC3261]) they are just spurious noise that must be ignored.
このメッセージはただ一つのSIP REGISTER要求を含んでいます。(それは、UDPの上で単一のデータグラムに表面上到着しました)。 パケットはボディー(この場合ゼロ・レングスを持っている)の後に余分な八重奏を含みます。 余分な八重奏はたまたまSIP INVITE要求に似ていますが、([RFC3261]のセクション18.3あたりの)それらはただ無視しなければならない偽りの雑音です。
A SIP element receiving this datagram would handle the REGISTER request normally and ignore the extra bits that look like an INVITE request. If the element is a proxy choosing to forward the REGISTER, the INVITE octets would not appear in the forwarded request.
このデータグラムを受けるSIP要素は、通常、REGISTER要求を扱って、INVITE要求に似ている余分なビットを無視するでしょう。 要素がREGISTERを進めるのを選ぶプロキシであるなら、INVITE八重奏は転送された要求に現れないでしょう。
Sparks, et al. Informational [Page 14] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[14ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
Message Details : dblreq
メッセージの詳細: dblreq
REGISTER sip:example.com SIP/2.0
To: sip:j.user@example.com
From: sip:j.user@example.com;tag=43251j3j324
Max-Forwards: 8
I: dblreq.0ha0isndaksdj99sdfafnl3lk233412
Contact: sip:j.user@host.example.com
CSeq: 8 REGISTER
Via: SIP/2.0/UDP 192.0.2.125;branch=z9hG4bKkdjuw23492
Content-Length: 0
REGISTER一口: example.com SIP/2.0To: 一口: j.user@example.com From: 一口: j.user@example.com;tag は前方へ43251j3j324マックスと等しいです: 8、私: dblreq.0ha0isndaksdj99sdfafnl3lk233412 Contact: 一口: j.user@host.example.com CSeq: 8は以下を通って登録されます。 一口/2.0/UDP192.0.2.125; ブランチはz9hG4bKkdjuw23492コンテンツの長さと等しいです: 0
INVITE sip:joe@example.com SIP/2.0
t: sip:joe@example.com
From: sip:caller@example.net;tag=141334
Max-Forwards: 8
Call-ID: dblreq.0ha0isnda977644900765@192.0.2.15
CSeq: 8 INVITE
Via: SIP/2.0/UDP 192.0.2.15;branch=z9hG4bKkdjuw380234
Content-Type: application/sdp
Content-Length: 150
INVITE一口: joe@example.com SIP/2.0t: 一口: joe@example.com From: 一口: caller@example.net;tag は141334のマックス-フォワードと等しいです: 8呼び出しID: dblreq.0ha0isnda977644900765@192.0.2.15 CSeq: 8 以下を通って招待 一口/2.0/UDP192.0.2.15; ブランチはz9hG4bKkdjuw380234コンテントタイプと等しいです: sdp Contentアプリケーション/長さ: 150
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.15
s=-
c=IN IP4 192.0.2.15
t=0 0
m=audio 49217 RTP/AVP 0 12
m =video 3227 RTP/AVP 31
a=rtpmap:31 LPC
0 0v=0 o=mhandley29739 7272939IN IP4 192.0.2.15 s=c=IN IP4 192.0.2.15t=mがオーディオの49217RTP/AVPと等しい、0、12m、=ビデオ3227RTP/AVP31a=rtpmap: 31LPC
Sparks, et al. Informational [Page 15] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[15ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
3.1.1.9. Semicolon-Separated Parameters in URI User Part
3.1.1.9. URIユーザ部分のセミコロンで切り離されたパラメタ
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が分析されるので、ユーザ部分は「ユーザ; 平価は 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一口: u%40example.net@example.com ユーザ;平価=SIP/2.0To: 一口: j_user@example.com From: 一口: caller@example.org;tag は33242のマックス-フォワードと等しいです: 3呼び出しID: semiuri.0ha0isndaksdj CSeq: 8つのオプションが受け入れます: アプリケーション/sdp、pkcs7アプリケーション/パントマイム、複合か混ぜられて、複合の、または、サインされたメッセージ/一口、メッセージ/sipfrag Via: SIP/2.0/UDP192.0.2.1; ブランチはz9hG4bKkdjuw lと等しいです: 0
3.1.1.10. Varied and Unknown Transport Types
3.1.1.10. 様々で未知の輸送タイプ
This request contains Via header field values with all known transport types and exercises the transport extension mechanism. Parsers must accept this message as well formed. Elements receiving this message would process it exactly as if the 2nd and subsequent header field values specified UDP (or other transport).
この要求は、すべての知られている輸送タイプがあるViaヘッダーフィールド値を含んでいて、輸送拡大メカニズムを運動させます。 パーサは、このメッセージがよく形成されていると受け入れなければなりません。 まるでちょうど2番目の、そして、その後のヘッダーフィールド値がUDP(または、他の輸送)を指定するかのようにこのメッセージを受け取るElementsがそれを処理するでしょう。
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一口: user@example.com SIP/2.0To: 一口: user@example.com From: <一口: caller@example.com 、gt;、; 前方へ=323最大にタグ付けをしてください: 70呼び出しID: transports.kijh4akdnaqjkwendsasfdj Accept: アプリケーション/sdp CSeq: 以下を通って60のオプション 一口/2.0/UDP t1.example.com; ブランチは以下を通ってz9hG4bKkdjuwと等しいです。 一口/2.0/SCTP t2.example.com; ブランチは以下を通ってz9hG4bKklasjdhfと等しいです。 一口/2.0/TLS t3.example.com; ブランチは以下を通ってz9hG4bK2980unddjと等しいです。 一口/2.0/未知のt4.example.com; ブランチは以下を通ってz9hG4bKasd0f3enと等しいです。 SIP/2.0/TCP t5.example.com; ブランチはz9hG4bK0a9idfnee lと等しいです: 0
Sparks, et al. Informational [Page 16] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[16ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
3.1.1.11. Multipart MIME Message
3.1.1.11. 複合MIMEメッセージ
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つの身体の部分を含んでいます。 第二部は、コード化されていた状態で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].
複合/パントマイムメッセージの追加例(特に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一口: kumiko@example.org SIP/2.0<allOneLine>Via: 一口/2.0/UDP、127.0、.0、.1:5070、; ブランチ=z9hG4bK-d87543-4dade06d0bdb11ee-1--d87543; 前方へrport allOneLine></マックス: 70ルート: <一口: 127.0 .0 .1:5080 ><allOneLine>のアイデンティティ: r5mwreLuyDRYBi/0TiPwEsY3rEVsk/G2WxhgTV1PF7hHuL IK0YWVKZhKv9Mj8UeXqkMVbnVq37CD+813gvYjcBUaZngQmXc9WNZSDN GCzA+fWl9MEUHWIZo1CeJebdY/XlgKeTa0Olvq0rt70Q5jiSfbqMJmQF teeivUhkMWYUAは</allOneLine>接触と等しいです: <一口: fluffy@127.0.0.1 :5070、gt;、To: <一口: kumiko@example.org 、gt;、From: <一口: fluffy@example.com 、gt;、; =2fb0dcc9呼び出しIDにタグ付けをしてください: 3d9485ad0c49859b@Zmx1ZmZ5LW1hYy0xNi5sb2NhbA. 。 CSeq: 1 メッセージ内容転送コード化: 2進のコンテントタイプ: 複合/は混入しました; 境界は7a9cbec02ceef655日付:と等しいです。 グリニッジ標準時2005年10月15日土曜日4時44分56秒のユーザエージェント: SIPimp.org/0.2.5(呪い)コンテンツの長さ: 553
--7a9cbec02ceef655
Content-Type: text/plain
Content-Transfer-Encoding: binary
--7a9cbec02ceef655コンテントタイプ: 明瞭なContent転送テキスト/コード化: バイナリー
Hello
--7a9cbec02ceef655
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary
こんにちは、--7a9cbec02ceef655コンテントタイプ: 八重奏アプリケーション/流れのContent転送コード化: バイナリー
Sparks, et al. Informational [Page 17] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[17ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
<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 28F26220F7E941749E330D9A15EDABDB93D10C42102E7B7289D29CC0C9AE2EFB C7C0CFF9172F3B027E4FC027E1546DE4B6AA3ABB3E66CCCB5DD6C64B8383149C B8E6FF182D944FE57B65BC99D005</十六進法>--7a9cbec02ceef655--
3.1.1.12. Unusual Reason Phrase
3.1.1.12. 珍しい理由句
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)
理由句の=*(予約されるか無遠慮であるか逃げられた/ 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性格を含んでいます。 この応答はよく形成されます。 パーサはこのメッセージを受け入れなければなりません。
Sparks, et al. Informational [Page 18] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[18ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
Message Details : unreason
メッセージの詳細: 理性のなさ
<allOneLine>
SIP/2.0 200 = 2**3 * 5**2 <hex>D0BDD0BE20D181D182
D0BE20D0B4D0B5D0B2D18FD0BDD0BED181D182D0BE20D0B4
D0B5D0B2D18FD182D18C202D20D0BFD180D0BED181D182D0
BED0B5</hex>
</allOneLine>
Via: SIP/2.0/UDP 192.0.2.198;branch=z9hG4bK1324923
Call-ID: unreason.1234ksdfak3j2erwedfsASdf
CSeq: 35 INVITE
From: sip:user@example.com;tag=11141343
To: sip:user@example.edu;tag=2229
Content-Length: 154
Content-Type: application/sdp
Contact: <sip:user@host198.example.com>
以下を通って<allOneLine>一口/2.0 200 = 2**3*5**2<十六進法>D0BDD0BE20D181D182 D0BE20D0B4D0B5D0B2D18FD0BDD0BED181D182D0BE20D0B4D0B5D0B2D18FD182D18C202D20D0BFD180D0BED181D182D0 BED0B5</十六進法></allOneLine>。 一口/2.0/UDP192.0.2.198; ブランチはz9hG4bK1324923呼び出しIDと等しいです: unreason.1234ksdfak3j2erwedfsASdf CSeq: 35はFrom:を招待します。 一口: user@example.com;tag =11141343To: 一口: user@example.edu;tag は2229年のContent-長さと等しいです: 154コンテントタイプ: アプリケーション/sdp Contact: <一口: user@host198.example.com 、gt。
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
0 0v=0 o=mhandley29739 7272939IN IP4 192.0.2.198 s=c=IN IP4 192.0.2.198t=mがオーディオの49217RTP/AVPと等しい、0、12m、=ビデオ3227RTP/AVP31a=rtpmap: 31LPC
3.1.1.13. Empty Reason Phrase
3.1.1.13. 空の理由句
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>
以下を通って一口/2.0 100<十六進法>20</十六進法>。 一口/2.0/UDP192.0.2.105; ブランチはz9hG4bK2398ndaoe呼び出しIDと等しいです: noreason.asndj203insdf99223ndf CSeq: 35はFrom:を招待します。 <一口: user@example.com 、gt;、;=39ansfi3To:にタグ付けをしてください <一口: user@example.edu 、gt;、; =902jndnke3コンテンツの長さにタグ付けをしてください: 0 接触: <一口: user@host105.example.com 、gt。
Sparks, et al. Informational [Page 19] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[19ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
3.1.2. Invalid Messages
3.1.2. 無効のメッセージ
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.
このセクションは相互運用性出来事で見られた誤りを反映して、奇形のメッセージを通して引き起こすことができる重要な周辺条件について調査するいくつかの無効のメッセージを含みます。 このセクションは、すべてのタイプの無効のメッセージに関する総覧であることを試みません。
3.1.2.1. Extraneous Header Field Separators
3.1.2.1. 異質なヘッダーフィールド分離
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.
この要求を受け取る要素は400Bad Request誤りで応じるはずです。
Message Details : badinv01
メッセージの詳細: badinv01
INVITE sip:user@example.com SIP/2.0
To: sip:j.user@example.com
From: sip:caller@example.net;tag=134161461246
Max-Forwards: 7
Call-ID: badinv01.0ha0isndaksdjasdf3234nas
CSeq: 8 INVITE
Via: SIP/2.0/UDP 192.0.2.15;;,;,,
Contact: "Joe" <sip:joe@example.org>;;;;
Content-Length: 152
Content-Type: application/sdp
INVITE一口: user@example.com SIP/2.0To: 一口: j.user@example.com From: 一口: caller@example.net;tag は134161461246のマックス-フォワードと等しいです: 7呼び出しID: badinv01.0ha0isndaksdjasdf3234nas CSeq: 8 以下を通って招待 一口/2.0/UDP192.0.2.15。;、以下に連絡してください。 「ジョー」<一口: joe@example.org 、gt;、。 コンテンツの長さ: 152コンテントタイプ: アプリケーション/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
0 0v=0 o=mhandley29739 7272939IN IP4 192.0.2.15 s=c=IN IP4 192.0.2.15t=mがオーディオの49217RTP/AVPと等しい、0、12m、=ビデオ3227RTP/AVP31a=rtpmap: 31LPC
3.1.2.2. Content Length Larger Than Message
3.1.2.2. メッセージより大きいコンテンツの長さ
This is a request message with a Content Length that is larger than the actual length of the body.
これはボディーの実際の長さより大きいContent Lengthがある要求メッセージです。
When sent over UDP (as this message ostensibly was), the receiving element should respond with a 400 Bad Request error. If this message arrived over a stream-based transport, such as TCP, there's not much
UDPの上に送ると(このメッセージが表面上そうであったように)、受信要素は400Bad Request誤りで応じるはずです。 このメッセージがTCPなどに似ている流れのベースの輸送の上でそれほど多くない状態で到着したなら
Sparks, et al. Informational [Page 20] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[20ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
the receiving party could do but wait for more data on the stream and close the connection if none is forthcoming within a reasonable period of time.
受領者はできましたが、流れに関する、より多くのデータを待ってください、そして、なにも適正な期間以内に用意されていないなら、接続を終えてください。
Message Details : clerr
メッセージの詳細: clerr
INVITE sip:user@example.com SIP/2.0
Max-Forwards: 80
To: sip:j.user@example.com
From: sip:caller@example.net;tag=93942939o2
Contact: <sip:caller@hungry.example.net>
Call-ID: clerr.0ha0isndaksdjweiafasdk3
CSeq: 8 INVITE
Via: SIP/2.0/UDP host5.example.com;branch=z9hG4bK-39234-23523
Content-Type: application/sdp
Content-Length: 9999
INVITE一口: 前方へ user@example.com SIP/2.0マックス: 80 To: 一口: j.user@example.com From: 一口: caller@example.net;tag は93942939o2 Contactと等しいです: <一口: caller@hungry.example.net 、gt;、呼び出しID: clerr.0ha0isndaksdjweiafasdk3 CSeq: 8 以下を通って招待 一口/2.0/UDP host5.example.com; ブランチはz9hG4bK-39234-23523コンテントタイプと等しいです: sdp Contentアプリケーション/長さ: 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
0 0v=0 o=mhandley29739 7272939IN IP4 192.0.2.155 s=c=IN IP4 192.0.2.155t=mがオーディオの49217RTP/AVPと等しい、0、12m、=ビデオ3227RTP/AVP31a=rtpmap: 31LPC
3.1.2.3. Negative Content-Length
3.1.2.3. 否定的コンテンツの長さ
This request has a negative value for Content-Length.
この要求には、Content-長さのための負の数があります。
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-長さのヘッダーフィールドに到着するメッセージに、同じ振舞いは適切です、以下などのように:
Content-Length: five
コンテンツの長さ: 5
Implementors should take extra precautions if the technique they choose for converting this ascii field into an integral form can return a negative value. In particular, the result must not be used as a counter or array index.
彼らがこのASCII分野を不可欠のフォームに変換するのに選ぶテクニックが負の数を返すことができるなら、作成者は大事を取るべきです。 特に、カウンタか配列指数として結果を使用してはいけません。
Sparks, et al. Informational [Page 21] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[21ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
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一口: 前方へ user@example.com SIP/2.0マックス: 254 To: 一口: j.user@example.com From: 一口: caller@example.net;tag =32394234Call-ID: ncl.0ha0isndaksdj2193423r542w35 CSeq: 0 以下を通って招待 一口/2.0/UDP192.0.2.53; ブランチはz9hG4bKkdjuw接触と等しいです: <一口: caller@example53.example.net 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: -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
0 0v=0 o=mhandley29739 7272939IN IP4 192.0.2.53 s=c=IN IP4 192.0.2.53t=mがオーディオの49217RTP/AVPと等しい、0、12m、=ビデオ3227RTP/AVP31a=rtpmap: 31LPC
3.1.2.4. Request Scalar Fields with Overlarge Values
3.1.2.4. 大き過ぎている値でスカラの分野を要求してください。
This request contains several scalar header field values outside their legal range.
この要求はそれらの法的な範囲の外にいくつかのスカラのヘッダーフィールド値を保管しています。
o The CSeq sequence number is >2**32-1.
o CSeq一連番号は>2**32-1です。
o The Max-Forwards value is >255.
o 前方へマックス値は>255です。
o The Expires value is >2**32-1.
o Expires値は>2**32-1です。
o The Contact expires parameter value is >2**32-1.
o Contactは期限が切れます。パラメタ値は>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誤りのため400Bad Requestと共に応じるはずです。 前方へマックス分野だけが間違っているなら、要素は、まるで分野に欠けているかのように要求を処理するのを選ぶかもしれないでしょうに。 満期値だけが間違っているなら、まるで満了(この場合、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.
常軌をはずしている値のインクルードを含むかもしれませんが、有限でなくて、Contact q価値と、Timestamp値と、Via ttlパラメタである他のスカラの要求分野。
Sparks, et al. Informational [Page 22] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[22ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
Message Details : scalar02
メッセージの詳細: scalar02
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TCP host129.example.com;branch=z9hG4bK342sdfoi3
To: <sip:user@example.com>
From: <sip:user@example.com>;tag=239232jh3
CSeq: 36893488147419103232 REGISTER
Call-ID: scalar02.23o0pd9vanlq3wnrlnewofjas9ui32
Max-Forwards: 300
Expires: 1<repeat count=100>0</repeat>
Contact: <sip:user@host129.example.com>
;expires=280297596632815
Content-Length: 0
REGISTER一口: example.com SIP/2.0Via: 一口/2.0/TCP host129.example.com; ブランチ=z9hG4bK342sdfoi3To: <一口: user@example.com 、gt;、From: <一口: user@example.com 、gt;、; =239232jh3 CSeqにタグ付けをしてください: 36893488147419103232 呼び出しIDを登録してください: 前方へscalar02.23o0pd9vanlq3wnrlnewofjas9ui32マックス: 300 期限が切れます: 1 <繰返し回数は100>0</反復>Contactと等しいです: <一口: user@host129.example.com 、gt;、; =280297596632815コンテンツの長さを吐き出します: 0
3.1.2.5. Response Scalar Fields with Overlarge Values
3.1.2.5. 大き過ぎている値がある応答スカラ分野
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 後のRetry分野は無分別に大きいです(RFC3261が法的な範囲をこの分野と定義しないことに注意してください)。
o The Warning field has a warning-value with more than 3 digits.
o Warning分野には、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
一口/2.0 503は以下を通って入手できない<allOneLine>を調整します。 SIP/2.0/TCP host129.example.com; ブランチはz9hG4bKzzxdiwo34swと等しいです; =192.0.2.129</allOneLine>To:を受けます。 <一口: user@example.com 、gt;、From: <一口: other@example.net 、gt;、; =2easdjfejw CSeqにタグ付けをしてください: 9292394834772304023312 オプション呼び出しID: 後のscalarlg.noase0of0234hn2qofoaf0232aewf2394r Retry: 949302838503028349304023988 警告: 1812年の申し出の「進行中」のContent-長さ: 0
Sparks, et al. Informational [Page 23] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[23ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
3.1.2.6. Unterminated Quoted String in Display Name
3.1.2.6. 表示名の引用文字列をUnterminatedしました。
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.
これは「非-終え」られた引用文がTo分野の表示名にある要求です。 この要求を受け取る要素は400Bad Request誤りを返すはずです。
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.ユーザ<一口さん: j.user@example.com 、gt;、<一口: realj@example.net 、gt;、」
Message Details : quotbal
メッセージの詳細: quotbal
INVITE sip:user@example.com SIP/2.0
To: "Mr. J. User <sip:j.user@example.com>
From: sip:caller@example.net;tag=93334
Max-Forwards: 10
Call-ID: quotbal.aksdj
Contact: <sip:caller@host59.example.net>
CSeq: 8 INVITE
Via: SIP/2.0/UDP 192.0.2.59:5050;branch=z9hG4bKkdjuw39234
Content-Type: application/sdp
Content-Length: 152
INVITE一口: user@example.com SIP/2.0To: 「J.ユーザ<一口さん: j.user@example.com 、gt;、From:、」 一口: caller@example.net;tag は93334のマックス-フォワードと等しいです: 10呼び出しID: quotbal.aksdj Contact: <一口: caller@host59.example.net 、gt;、CSeq: 8 以下を通って招待 一口/2.0/UDP192.0.2.59: 5050; ブランチはz9hG4bKkdjuw39234コンテントタイプと等しいです: sdp Contentアプリケーション/長さ: 152
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.15
s=-
c=IN IP4 192.0.2.15
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
0 0v=0 o=mhandley29739 7272939IN IP4 192.0.2.15 s=c=IN IP4 192.0.2.15t=mがオーディオの49217RTP/AVPと等しい、0、12m、=ビデオ3227RTP/AVP31a=rtpmap: 31LPC
Sparks, et al. Informational [Page 24] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[24ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
3.1.2.7. <> Enclosing Request-URI
3.1.2.7. 要求URIを同封する<>。
This INVITE request is invalid because the Request-URI has been enclosed within in "<>".
「<>」に中にRequest-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.
400Bad Requestと共にこの誤りで要求を拒絶するのはいつも妥当です。 彼らが受け入れるもので寛容であることを試みるElementsは、括弧を無視するのを選ぶかもしれません。 要素が要求を転送するなら、それは送るメッセージに括弧を含んではいけません。
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
<一口: user@example.com を招待してください、gt;、一口/2.0To: 一口: user@example.com From: 一口: caller@example.net;tag は39291のマックス-フォワードと等しいです: 23呼び出しID: ltgtruri.1@192.0.2.5 CSeq: 1 以下を通って招待 UDP192.0.2.5一口/2.0/接触: <一口: caller@host5.example.net 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: 159
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.5
s=-
c=IN IP4 192.0.2.5
t=3149328700 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
v=0 o=mhandley29739 7272939IN IP4 192.0.2.5 s=cがIN IP4 192.0.2.5t=と等しい、3149328700、0m、オーディオの49217RTP/AVPと等しい、0、12m、=ビデオ3227RTP/AVP31a=rtpmap: 31LPC
Sparks, et al. Informational [Page 25] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[25ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
3.1.2.8. Malformed SIP Request-URI (embedded LWS)
3.1.2.8. 奇形の一口要求URI(埋め込まれたLWS)
This INVITE has illegal LWS within the Request-URI.
このINVITEはRequest-URIの中に不法なLWSを持っています。
An element receiving this request should respond with a 400 Bad Request.
この要求を受け取る要素は400Bad Requestと共に応じるはずです。
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
INVITE一口: user@example.com; lr SIP/2.0To: 一口: user@example.com;tag は3xfe-9921883-z9f From:と等しいです。 一口: caller@example.net;tag は231413434のマックス-フォワードと等しいです: 5呼び出しID: lwsruri.asdfasdoeoi2323-asdfwrn23-asd834rk423 CSeq: 2130706432 以下を通って招待 一口/2.0/UDP192.0.2.1: 5060; ブランチはz9hG4bKkdjuw2395接触と等しいです: <一口: caller@host1.example.net 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: 159
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=3149328700 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
v=0 o=mhandley29739 7272939IN IP4 192.0.2.1 s=cがIN IP4 192.0.2.1t=と等しい、3149328700、0m、オーディオの49217RTP/AVPと等しい、0、12m、=ビデオ3227RTP/AVP31a=rtpmap: 31LPC
Sparks, et al. Informational [Page 26] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[26ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
3.1.2.9. Multiple SP Separating Request-Line Elements
3.1.2.9. 要求線要素を切り離す複数のSP
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一口: 前方へ user@example.com SIP/2.0マックス: 8 To: 一口: user@example.com From: 一口: caller@example.net;tag は8814年のCall-IDと等しいです: lwsstart.dfknq234oi243099adsdfnawe3@example.com CSeq: 1893884 以下を通って招待 一口/2.0/UDP host1.example.com; ブランチはz9hG4bKkdjuw3923接触と等しいです: <一口: caller@host1.example.net 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: 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
0 0v=0 o=mhandley29739 7272939IN IP4 192.0.2.1 s=c=IN IP4 192.0.2.1t=mがオーディオの49217RTP/AVPと等しい、0、12m、=ビデオ3227RTP/AVP31a=rtpmap: 31LPC
Sparks, et al. Informational [Page 27] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[27ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
3.1.2.10. SP Characters at End of Request-Line
3.1.2.10. 要求行の終わりのSPキャラクター
This OPTIONS request contains SP characters between the SIP-Version field and the CRLF terminating the Request-Line.
このOPTIONS要求は、Request-線を終えながら、SIP-バージョン分野とCRLFの間にSPキャラクタを保管しています。
It is acceptable to reject this request as malformed. An element that is liberal in what it accepts may ignore these extra SP characters when processing the request. If the element forwards the request, it must not include these extra SP characters in the messages it sends.
この要求が奇形であると拒絶するのは許容できます。 要求を処理するとき、それが受け入れるもので自由主義である要素はこれらの余分なSPキャラクタを無視するかもしれません。 要素が要求を転送するなら、それは送るメッセージにこれらの余分なSPキャラクタを含んではいけません。
Message Details : trws
メッセージの詳細: trws
OPTIONS sip:remote-target@example.com SIP/2.0<hex>2020</hex>
Via: SIP/2.0/TCP host1.example.com;branch=z9hG4bK299342093
To: <sip:remote-target@example.com>
From: <sip:local-resource@example.com>;tag=329429089
Call-ID: trws.oicu34958239neffasdhr2345r
Accept: application/sdp
CSeq: 238923 OPTIONS
Max-Forwards: 70
Content-Length: 0
OPTIONS一口: remote-target@example.com SIP/2.0、lt;、>2020</十六進法>Viaに魔法をかけてください: 一口/2.0/TCP host1.example.com; ブランチ=z9hG4bK299342093To: <一口: remote-target@example.com 、gt;、From: <一口: local-resource@example.com 、gt;、; タグは329429089呼び出しIDと等しいです: trws.oicu34958239neffasdhr2345r Accept: アプリケーション/sdp CSeq: 238923のオプションマックス-フォワード: 70 コンテンツの長さ: 0
Sparks, et al. Informational [Page 28] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[28ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
3.1.2.11. Escaped Headers in SIP Request-URI
3.1.2.11. 一口要求URIにおける逃げられたヘッダー
This INVITE is malformed, as the SIP Request-URI contains escaped headers.
SIP Request-URIが逃げられたヘッダーを含むとき、このINVITEは奇形です。
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).
要素が400Bad Requestと共にこの要求を拒絶するのは、許容できます。 要素は、それが受け入れるもので寛容であり、逃げられたヘッダーを無視するのを選ぶかもしれません。 要素がプロキシであるなら、逃げられたヘッダーは転送された要求のRequest-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
一口を招待してください: user@example.com?Route は%3Csip: example.com%3E一口/2.0To:と等しいです。 一口: user@example.com From: 一口: caller@example.net;tag は341518のマックス-フォワードと等しいです: 7 接触: <一口: caller@host39923.example.net 、gt;、呼び出しID: escruri.23940-asdfhj-aje3br-234q098w-fawerh2q-h4n5 CSeq: 149209342 以下を通って招待 hour.example.comの2.0/UDP一口/ホスト; ブランチはz9hG4bKkdjuwコンテントタイプと等しいです: sdp Contentアプリケーション/長さ: 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
0 0v=0 o=mhandley29739 7272939IN IP4 192.0.2.1 s=c=IN IP4 192.0.2.1t=mがオーディオの49217RTP/AVPと等しい、0、12m、=ビデオ3227RTP/AVP31a=rtpmap: 31LPC
Sparks, et al. Informational [Page 29] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[29ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
3.1.2.12. Invalid Time Zone in Date Header Field
3.1.2.12. 日付のヘッダーフィールドにおける無効の時間帯
This INVITE is invalid, as it contains a non-GMT time zone in the SIP Date header field.
SIP Dateヘッダーフィールドにおける非グリニッジ標準時の時間帯を含むとき、このINVITEは無効です。
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ヘッダーフィールドの内容が実際に処理に重要でない場合、要素がそれをしないでしょうにが)。 とにかくDateヘッダーフィールドを使用しないなら、それが受け入れるもので寛容になりたがっている要素は全体でこの値を無視するかもしれないでしょうに。 さもなければ、それは、この日付を解釈して、グリニッジ標準時にそれを調整するのを試みるかもしれません。
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.
RFC3261は明らかに唯一の許容できる時間帯の名称を「グリニッジ標準時と」定義します。 [RFC2822]単位でグリニッジ標準時と同義ですが、「ユタ」は有効ではありません。 また、"UTC"と"UCT"も無効です。
Message Details : baddate
メッセージの詳細: baddate
INVITE sip:user@example.com SIP/2.0
To: sip:user@example.com
From: sip:caller@example.net;tag=2234923
Max-Forwards: 70
Call-ID: baddate.239423mnsadf3j23lj42--sedfnm234
CSeq: 1392934 INVITE
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKkdjuw
Date: Fri, 01 Jan 2010 16:00:00 EST
Contact: <sip:caller@host5.example.net>
Content-Type: application/sdp
Content-Length: 150
INVITE一口: user@example.com SIP/2.0To: 一口: user@example.com From: 一口: caller@example.net;tag は2234923のマックス-フォワードと等しいです: 70呼び出しID: baddate.239423mnsadf3j23lj42--、sedfnm234 CSeq: 1392934 以下を通って招待 一口/2.0/UDP host.example.com; ブランチ=z9hG4bKkdjuw日付: 東部標準時2010年1月1日金曜日16時0分0秒の接触: <一口: caller@host5.example.net 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: 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
0 0v=0 o=mhandley29739 7272939IN IP4 192.0.2.5 s=c=IN IP4 192.0.2.5t=mがオーディオの49217RTP/AVPと等しい、0、12m、=ビデオ3227RTP/AVP31a=rtpmap: 31LPC
Sparks, et al. Informational [Page 30] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[30ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
3.1.2.13. Failure to Enclose name-addr URI in <>
3.1.2.13. <>のEnclose名前-addr URIへの失敗
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要求は奇形です。 Contact Header分野に保管されていた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.
400Bad Requestと共に応じるというこの要求を受け取る要素に、それは妥当です。 この例にはあいまいさが全くないので、それが受け入れるもので寛容であることを選ぶ要素は角ブラケットを推論するかもしれません。 一般に、それは可能にならないでしょう。
Message Details : regbadct
メッセージの詳細: regbadct
REGISTER sip:example.com SIP/2.0
To: sip:user@example.com
From: sip:user@example.com;tag=998332
Max-Forwards: 70
Call-ID: regbadct.k345asrl3fdbv@10.0.0.1
CSeq: 1 REGISTER
Via: SIP/2.0/UDP 135.180.130.133:5060;branch=z9hG4bKkdjuw
Contact: sip:user@example.com?Route=%3Csip:sip.example.com%3E
l: 0
REGISTER一口: example.com SIP/2.0To: 一口: user@example.com From: 一口: user@example.com;tag は998332のマックス-フォワードと等しいです: 70呼び出しID: regbadct.k345asrl3fdbv@10.0.0.1 CSeq: 以下を通って1つのレジスタ 一口/2.0/UDP135.180.130.133: 5060; ブランチはz9hG4bKkdjuw接触と等しいです: 一口: user@example.com?Route =%3Csip: sip.example.com%3E l: 0
3.1.2.14. Spaces within addr-spec
3.1.2.14. addr-仕様の中の空間
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-仕様が空間を含んでいるので、この要求は奇形です。 この要求を受け取るパーサは壊れてはいけません。 400Bad Request応答でこの要求を拒絶するのは妥当です。 寛容であることを試みるElementsは空間を無視するかもしれません。
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一口: user@example.org SIP/2.0Via: 一口/2.0/UDP host4.example.com: 5060; ブランチは前方へz9hG4bKkdju43234マックスと等しいです: 70 From: : 「ベル、アレクサンダー」<一口 a.g.bell@example.com 、gt;、;=433423To:にタグ付けをしてください : 「ワトソン、トーマス」<一口 t.watson@example.org 、gt;、呼び出しID: badaspec.sdf0234n2nds0a099u23h3hnnw009cdkne3 Accept: アプリケーション/sdp CSeq: 3923239OPTIONS l: 0
Sparks, et al. Informational [Page 31] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[31ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
3.1.2.15. Non-token Characters in Display Name
3.1.2.15. 表示名の非象徴キャラクター
This OPTIONS request is malformed, since the display names in the To and From header fields contain non-token characters but are unquoted.
このOPTIONS要求は奇形です、ToとFromヘッダーフィールドにおける表示名が非象徴キャラクタを含んでいますが、引用を終わられるので。
It is reasonable always to reject this kind of error with a 400 Bad Request response.
400Bad Request応答でこの種類の誤りを拒絶するのはいつも妥当です。
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一口: t.watson@example.org SIP/2.0Via: 一口/2.0/UDP c.example.com: 5060; ブランチは前方へz9hG4bKkdjuwマックスと等しいです: 70 From: アレクサンダー<一口: ベル、 a.g.bell@example.com 、gt;、;=43To:にタグ付けをしてください トーマス<一口: ワトソン、 t.watson@example.org 、gt;、呼び出しID: baddn.31415@c.example.com は受け入れます: アプリケーション/sdp CSeq: 3923239OPTIONS l: 0
3.1.2.16. Unknown Protocol Version
3.1.2.16. 未知のプロトコルバージョン
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バージョンNot Supported誤りで要求に応じるはずです。
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一口: t.watson@example.org SIP/7.0Via: 一口/7.0/UDP c.example.com; ブランチは前方へz9hG4bKkdjuwマックスと等しいです: 70 From: A。 ベル<一口: a.g.bell@example.com 、gt;、;=qweoiqpe To:にタグ付けをしてください T。 ワトソン<一口: t.watson@example.org 、gt;、呼び出しID: badvers.31417@c.example.com CSeq: 1OPTIONS l: 0
Sparks, et al. Informational [Page 32] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[32ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
3.1.2.17. Start Line and CSeq Method Mismatch
3.1.2.17. 線とCSeq方法がミスマッチする始め
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ヘッダーフィールドがあります。 この要求を受け取るどんな要素も400Bad Requestと共に応じるでしょう。
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一口: user@example.com SIP/2.0To: 一口: j.user@example.com From: 一口: caller@example.net;tag は34525のマックス-フォワードと等しいです: 6呼び出しID: mismatch01.dj0234sxdfl3 CSeq: 8 以下を通って招待 SIP/2.0/UDP host.example.com; ブランチはz9hG4bKkdjuw lと等しいです: 0
3.1.2.18. Unknown Method with CSeq Method Mismatch
3.1.2.18. CSeq方法ミスマッチがある未知の方法
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.
この応答を受けるどんな要素も501Not Implementedと共に応じるはずです。 また、400Bad Requestも許容できますが、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一口: user@example.com SIP/2.0To: 一口: j.user@example.com From: 一口: caller@example.net;tag は34525のマックス-フォワードと等しいです: 6呼び出しID: mismatch02.dj0234sxdfl3 CSeq: 8 接触を招いてください: <一口: caller@host.example.net 、gt;、以下を通って 一口/2.0/UDP host.example.net; ブランチはz9hG4bKkdjuwコンテントタイプと等しいです: アプリケーション/sdp l: 138
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.1
c=IN IP4 192.0.2.1
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
v=0 o=mhandley29739 7272939IN IP4 192.0.2.1c=IN IP4、192.0、.2、.1m、オーディオの49217RTP/AVPと等しい、0、12m、=ビデオ3227RTP/AVP31a=rtpmap: 31LPC
Sparks, et al. Informational [Page 33] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[33ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
3.1.2.19. Overlarge Response Code
3.1.2.19. 大き過ぎている応答コード
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は受信機Viaを壊さないほうがよいです: 一口/2.0/UDP192.0.2.105; ブランチはz9hG4bK2398ndaoe呼び出しIDと等しいです: bigcode.asdof3uj203asdnf3429uasdhfas3ehjasdfas9i CSeq: 353494はFrom:を招待します。 <一口: user@example.com 、gt;、;=39ansfi3To:にタグ付けをしてください <一口: user@example.edu 、gt;、; =902jndnke3コンテンツの長さにタグ付けをしてください: 0 接触: <一口: user@host105.example.com 、gt。
3.2. Transaction Layer Semantics
3.2. 取引層の意味論
This section contains tests that exercise an implementation's parser and transaction-layer logic.
このセクションは実現のパーサを運動させるテストと取引層の論理を含みます。
3.2.1. Missing Transaction Identifier
3.2.1. なくなった取引識別子
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接頭語をブランチパラメタに提供することによって、3261スタイルのRFC取引識別子のサポートを示しますが、それは識別子を全く提供しません。 このメッセージを受け取るとき、パーサは壊れてはいけません。 この要求を受け取る要素が400Response(望ましくは、また、ソースからの他の要求も奇形のブランチパラメタを持っていそうなとき、国がない)との要求を拒絶するかもしれませんか、またはそれは2543スタイルのRFC取引識別子へ後ろへ下がることができました。
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一口: user@example.com SIP/2.0To: 一口: user@example.com From: 一口: caller@example.org;tag は33242のマックス-フォワードと等しいです: 以下を通って3 一口/2.0/UDP192.0.2.1; ブランチ=z9hG4bKは受け入れます: sdp Callアプリケーション/ID: badbranch.sadonfo23i420jv0as0derf3j3n CSeq: 8OPTIONS l: 0
Sparks, et al. Informational [Page 34] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[34ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
3.3. Application-Layer Semantics
3.3. 応用層意味論
This section contains tests that exercise an implementation's parser and application-layer logic.
このセクションは実現のパーサを運動させるテストと応用層論理を含みます。
3.3.1. Missing Required Header Fields
3.3.1. なくなった必要なヘッダーフィールド
This request contains no Call-ID, From, or To header fields.
この要求はどんなCall-ID、Fromも、またはToヘッダーフィールドも含んでいません。
An element receiving this message must not break because of the missing information. Ideally, it will respond with a 400 Bad Request error.
このメッセージを受け取る要素はなくなった情報のために壊れてはいけません。 理想的に、それは400Bad Request誤りで応じるでしょう。
Message Details : insuf
メッセージの詳細: insuf
INVITE sip:user@example.com SIP/2.0
CSeq: 193942 INVITE
Via: SIP/2.0/UDP 192.0.2.95;branch=z9hG4bKkdj.insuf
Content-Type: application/sdp
l: 152
INVITE一口: user@example.com SIP/2.0CSeq: 193942 以下を通って招待 一口/2.0/UDP192.0.2.95; ブランチはz9hG4bKkdj.insufコンテントタイプと等しいです: アプリケーション/sdp l: 152
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.95
s=-
c=IN IP4 192.0.2.95
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
0 0v=0 o=mhandley29739 7272939IN IP4 192.0.2.95 s=c=IN IP4 192.0.2.95t=mがオーディオの49217RTP/AVPと等しい、0、12m、=ビデオ3227RTP/AVP31a=rtpmap: 31LPC
Sparks, et al. Informational [Page 35] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[35ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
3.3.2. Request-URI with Unknown Scheme
3.3.2. 未知の計画を伴う要求URI
This OPTIONS contains an unknown URI scheme in the Request-URI. A parser must accept this as a well-formed SIP request.
このOPTIONSはRequest-URIにおける未知のURI計画を含んでいます。 パーサはよく形成されたSIP要求としてこれを認めなければなりません。
An element receiving this request will reject it with a 416 Unsupported URI Scheme response.
この要求を受け取る要素は416Unsupported URI Scheme応答でそれを拒絶するでしょう。
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ヘッダーフィールドのコンテンツを見るのを試みます。 それは誤りです。 ToヘッダーフィールドとRequest URIが頻繁に同じく安易な最初に、ホップメッセージの中を見るという事実にもかかわらず、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
オプションnobodyKnowsThisScheme: totallyopaquecontent一口/2.0To: 一口: user@example.com From: 一口: caller@example.net;tag は384のマックス-フォワードと等しいです: 3呼び出しID: unkscm.nasdfasser0q239nwsdfasdkl34 CSeq: 以下を通って3923423のオプション 一口/2.0/TCP host9.example.com; ブランチはz9hG4bKkdjuw39234コンテンツの長さと等しいです: 0
3.3.3. Request-URI with Known but Atypical Scheme
3.3.3. 知られていますが、非定型的な計画を伴う要求URI
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.
このOPTIONSはSIP要求のRequest-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.
要素が、この計画がRequest-URIで重要であると決して受け入れないなら、未知としてそれを扱って、416Unsupported URI Schemeに応答を返すのは適切です。 要素がこの計画でいくつかのURIを受け入れるかもしれないなら、それが受け入れないそれらのURIに、404Not Foundは適切です。
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: 3002SIP/2.0To: 一口: user@example.com From: 一口: caller@example.net;tag は384のマックス-フォワードと等しいです: 3呼び出しID: novelsc.asdfasser0q239nwsdfasdkl34 CSeq: 以下を通って3923423のオプション 一口/2.0/TCP host9.example.com; ブランチはz9hG4bKkdjuw39234コンテンツの長さと等しいです: 0
Sparks, et al. Informational [Page 36] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[36ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
3.3.4. Unknown URI Schemes in Header Fields
3.3.4. ヘッダーフィールドにおける未知のURI計画
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.
このメッセージはTo、From、および要求の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を要求するというこのメッセージを扱うべきです。 To:以来記録係は400Bad Request応答でこの要求を拒絶するでしょう。 ヘッダーフィールドが、AORとしてSIPかSIPS URIを含むのに必要です。
Message Details : unksm2
メッセージの詳細: unksm2
REGISTER sip:example.com SIP/2.0
To: isbn:2983792873
From: <http://www.example.com>;tag=3234233
Call-ID: unksm2.daksdj@hyphenated-host.example.com
CSeq: 234902 REGISTER
Max-Forwards: 70
Via: SIP/2.0/UDP 192.0.2.21:5060;branch=z9hG4bKkdjuw
Contact: <name:John_Smith>
l: 0
REGISTER一口: example.com SIP/2.0To: isbn: 2983792873From: <http://www.example.com>; =3234233呼び出しIDにタグ付けをしてください: unksm2.daksdj@hyphenated-host.example.com CSeq: 234902 前方へマックスを登録してください: 以下を通って70 一口/2.0/UDP192.0.2.21: 5060; ブランチはz9hG4bKkdjuw接触と等しいです: <名: ジョン_スミス>l: 0
3.3.5. Proxy-Require and Require
3.3.5. プロキシで必要であり、必要です。
This request tests proper implementation of SIP's Proxy-Require and Require extension mechanisms.
これはSIPの適切な履行がProxy必要とするテストとRequire拡大メカニズムを要求します。
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.
この要求を受け取るどんな要素も、Requireからこれらの特徴をリストアップするUnsupportedヘッダーフィールドを含んでいて、420Bad Extension応答で応じるか、またはヘッダーフィールドをProxy必要とするでしょう、要素が応じている役割によって。
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一口: user@example.com SIP/2.0To: 一口: j_user@example.com From: 一口: caller@example.net;tag は前方へ242etrマックスと等しいです: 6呼び出しID: bext01.0ha0isndaksdj Require: nothingSupportsThis、nothingSupportsThisEitherは以下をプロキシで必要とします。 noProxiesSupportThis、norDoAnyProxiesSupportThis CSeq: 以下を通って8つのオプション 2.0/TLSの折り目と一口/staple.example.com; ブランチはz9hG4bKkdjuwコンテンツの長さと等しいです: 0
Sparks, et al. Informational [Page 37] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[37ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
3.3.6. Unknown Content-Type
3.3.6. 未知のコンテントタイプ
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も処理するようにこの要求を受け取るプロキシはそれを処理するでしょう。 この要求を受け取る終点は415UnsupportedメディアType誤りでそれを拒絶するでしょう。
Message Details : invut
メッセージの詳細: invut
INVITE sip:user@example.com SIP/2.0
Contact: <sip:caller@host5.example.net>
To: sip:j.user@example.com
From: sip:caller@example.net;tag=8392034
Max-Forwards: 70
Call-ID: invut.0ha0isndaksdjadsfij34n23d
CSeq: 235448 INVITE
Via: SIP/2.0/UDP somehost.example.com;branch=z9hG4bKkdjuw
Content-Type: application/unknownformat
Content-Length: 40
INVITE一口: user@example.com SIP/2.0Contact: <一口: caller@host5.example.net 、gt;、To: 一口: j.user@example.com From: 一口: caller@example.net;tag は8392034のマックス-フォワードと等しいです: 70呼び出しID: invut.0ha0isndaksdjadsfij34n23d CSeq: 235448 以下を通って招待 一口/2.0/UDP somehost.example.com; ブランチはz9hG4bKkdjuwコンテントタイプと等しいです: unknownformat Contentアプリケーション/長さ: 40
<audio>
<pcmu port="443"/>
</audio>
「443」/></オーディオ<オーディオ><pcmuポート=>。
3.3.7. Unknown Authorization Scheme
3.3.7. 未知の認可計画
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.
記録係として務めないのを選ぶ終点が単に要求を拒絶するでしょう。 405Method Not Allowedは適切です。
Sparks, et al. Informational [Page 38] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[38ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
Message Details : regaut01
メッセージの詳細: regaut01
REGISTER sip:example.com SIP/2.0
To: sip:j.user@example.com
From: sip:j.user@example.com;tag=87321hj23128
Max-Forwards: 8
Call-ID: regaut01.0ha0isndaksdj
CSeq: 9338 REGISTER
Via: SIP/2.0/TCP 192.0.2.253;branch=z9hG4bKkdjuw
Authorization: NoOneKnowsThisScheme opaque-data=here
Content-Length:0
REGISTER一口: example.com SIP/2.0To: 一口: j.user@example.com From: 一口: j.user@example.com;tag は前方へ87321hj23128マックスと等しいです: 8呼び出しID: regaut01.0ha0isndaksdj CSeq: 9338は以下を通って登録されます。 一口/2.0/TCP192.0.2.253; ブランチはz9hG4bKkdjuw認可と等しいです: = ここのデータについて不透明にしているNoOneKnowsThisScheme Content-長さ: 0
3.3.8. Multiple Values in Single Value Required Fields
3.3.8. ただ一つの値の必須項目における複数の値
The message contains a request with multiple Call-ID, To, From, Max- Forwards, and CSeq values. An element receiving this request must not break.
メッセージは複数のCall-ID、To、From、マックスフォワード、およびCSeq値がある要求を含んでいます。 この要求を受け取る要素は壊れてはいけません。
An element receiving this request would respond with a 400 Bad Request error.
この要求を受け取る要素は400Bad Request誤りで応じるでしょう。
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一口: user@company.com SIP/2.0Contact: <一口: caller@host25.example.net 、gt;、以下を通って 一口/2.0/UDP192.0.2.25; ブランチは前方へz9hG4bKkdjuwマックスと等しいです: 70CSeq: 5 呼び出しIDを招待してください: multi01.98asdh@192.0.2.1 CSeq: 59 呼び出しIDを招待してください: multi01.98asdh@192.0.2.2 From: 一口: caller@example.com;tag =3413415To: 一口: user@example.com To: 一口: other@example.net From: 一口: caller@example.net;tag =2923420123コンテントタイプ: アプリケーション/sdp l: 154 接触: <一口: caller@host36.example.net 、gt;、前方へマックス: 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
0 0v=0 o=mhandley29739 7272939IN IP4 192.0.2.25 s=c=IN IP4 192.0.2.25t=mがオーディオの49217RTP/AVPと等しい、0、12m、=ビデオ3227RTP/AVP31a=rtpmap: 31LPC
Sparks, et al. Informational [Page 39] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[39ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
3.3.9. Multiple Content-Length Values
3.3.9. 複数のコンテンツの長さ値
Multiple conflicting Content-Length header field values appear in this request.
複数の闘争のContent-長さに、ヘッダーフィールド値はこの要求に現れます。
From a framing perspective, this situation is equivalent to an invalid Content-Length value (or no value at all).
縁どり見解から、この状況は無効のContent-長さの値(または、全く値がない)に同等です。
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一口: user@example.com SIP/2.0Via: 一口/2.0/UDP host5.example.net; ブランチ=z9hG4bK293423To: 一口: user@example.com From: 一口: other@example.net;tag =3923942Call-ID: mcl01.fhn2323orihawfdoa3o4r52o3irsdf CSeq: 15932オプションコンテンツの長さ: 13 マックス-フォワード: 60 コンテンツの長さ: 5コンテントタイプ: テキスト/平野
There's no way to know how many octets are supposed to be here.
ここで八重奏によるいくつと思われるかを知る方法が全くありません。
3.3.10. 200 OK Response with Broadcast Via Header Field Value
3.3.10. 200 ヘッダーフィールド値を通して放送があるOK応答
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.
このメッセージが値が含むことによって送った2番目のViaヘッダーフィールドがある応答である、255.255、.255、.255 メッセージはよく形成されます。 それを受けるとき、パーサは失敗してはいけません。
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.
プロキシが盲目的に正常な応答処理規則に従うなら、それは放送演説へのこの応答を進めるでしょうに。 攻撃の大通りとしてこれから守るために、プロキシはそのような応答を落とすべきです。
Sparks, et al. Informational [Page 40] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[40ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
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>
以下を通って一口/2.0 200OK 一口/2.0/UDP192.0.2.198; ブランチは以下を通ってz9hG4bK1324923と等しいです。 一口/2.0/UDP255.255.255.255; ブランチはz9hG4bK1saber23呼び出しIDと等しいです: bcast.0384840201234ksdfak3j2erwedfsASdf CSeq: 35はFrom:を招待します。 一口: user@example.com;tag =11141343To: 一口: user@example.edu;tag は2229年のContent-長さと等しいです: 154コンテントタイプ: アプリケーション/sdp Contact: <一口: user@host28.example.com 、gt。
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
0 0v=0 o=mhandley29739 7272939IN IP4 192.0.2.198 s=c=IN IP4 192.0.2.198t=mがオーディオの49217RTP/AVPと等しい、0、12m、=ビデオ3227RTP/AVP31a=rtpmap: 31LPC
3.3.11. Max-Forwards of Zero
3.3.11. 前方へゼロ歳のマックス
This is a legal SIP request with the Max-Forwards header field value set to zero.
これはゼロに設定された前方へマックスヘッダーフィールド価値がある法的なSIP要求です。
A proxy should not forward the request and should respond 483 (Too Many Hops). An endpoint should process the request as if the Max- Forwards field value were still positive.
また、プロキシが要求を転送するべきでなくて、483を反応させるべきである、(Manyホップス) まるでフォワードがさばくマックス値がまだ上向きであるかのように終点は要求を処理するべきです。
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一口: user@example.com SIP/2.0To: 一口: user@example.com From: 一口: caller@example.net;tag は3ghsd41 Call-IDと等しいです: zeromf.jfasdlfnm2o2l43r5u0asdfas CSeq: 以下を通って39234321のオプション 一口/2.0/UDP host1.example.com; ブランチは前方へz9hG4bKkdjuw2349iマックスと等しいです: 0 コンテンツの長さ: 0
Sparks, et al. Informational [Page 41] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[41ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
3.3.12. REGISTER with a Contact Header Parameter
3.3.12. 連絡ヘッダーパラメタとともに記名してください。
This register request contains a contact where the 'unknownparam' parameter must be interpreted as a contact-param and not a url-param.
このレジスタ要求はurl-paramではなく、接触-paramとして'unknownparam'パラメタを解釈しなければならない接触を含んでいます。
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.
このREGISTERは成功するはずです。 応答はこの結合のための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
REGISTER一口: example.com SIP/2.0Via: 一口/2.0/UDP saturn.example.com: 5060; ブランチは前方へz9hG4bKkdjuwマックスと等しいです: 70 From: 一口: watson@example.com;tag はDkfVgjkrtMwaerKKpe To:と等しいです。 一口: watson@example.com Call-ID: cparam01.70710@saturn.example.com CSeq: 2 接触を登録してください: 一口: + 19725552222@gw1.example.net;unknownparam l: 0
3.3.13. REGISTER with a url-parameter
3.3.13. url-パラメタがあるREGISTER
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
REGISTER一口: example.com SIP/2.0Via: 一口/2.0/UDP saturn.example.com: 5060; ブランチは前方へz9hG4bKkdjuwマックスと等しいです: 70 From: 一口: watson@example.com;tag =838293To: 一口: watson@example.com Call-ID: cparam02.70710@saturn.example.com CSeq: 3 接触を登録してください: <一口: + 19725552222@gw1.example.net;unknownparam 、gt;、l: 0
Sparks, et al. Informational [Page 42] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[42ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
3.3.14. REGISTER with a URL Escaped Header
3.3.14. URLの逃げられたヘッダーとともに記名してください。
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
REGISTER一口: example.com SIP/2.0To: 一口: user@example.com From: 一口: user@example.com;tag は8つのマックス-フォワードと等しいです: 70呼び出しID: regescrt.k345asrl3fdbv@192.0.2.1 CSeq: 14398234は以下を通って登録されます。 一口/2.0/UDP host5.example.com; ブランチはz9hG4bKkdjuw Mと等しいです: <一口: user@example.com?Route =%3Csip: sip.example.com%3E>L: 0
Sparks, et al. Informational [Page 43] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[43ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
3.3.15. Unacceptable Accept Offering
3.3.15. 容認できなさ、提供を受け入れてください。
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ボディーを含まないかもしれません。 この要求の受取人は406Not Acceptableと共に応じることができました、Warning/399が、Acceptヘッダーフィールドで提供された形式で応答を定式化できないのを示していて。 また、400Bad Requestと共に応じるのも適切です、INVITEを支持しているすべてのSIP User-エージェント(UAs)がアプリケーション/sdpを支持するのに必要であるので。
Message Details : sdp01
メッセージの詳細: sdp01
INVITE sip:user@example.com SIP/2.0
To: sip:j_user@example.com
Contact: <sip:caller@host15.example.net>
From: sip:caller@example.net;tag=234
Max-Forwards: 5
Call-ID: sdp01.ndaksdj9342dasdd
Accept: text/nobodyKnowsThis
CSeq: 8 INVITE
Via: SIP/2.0/UDP 192.0.2.15;branch=z9hG4bKkdjuw
Content-Length: 150
Content-Type: application/sdp
INVITE一口: user@example.com SIP/2.0To: 一口: j_user@example.com Contact: <一口: caller@host15.example.net 、gt;、From: 一口: caller@example.net;tag は234のマックス-フォワードと等しいです: 5呼び出しID: sdp01.ndaksdj9342dasdd Accept: テキスト/nobodyKnowsThis CSeq: 8 以下を通って招待 一口/2.0/UDP192.0.2.15; ブランチはz9hG4bKkdjuwコンテンツの長さと等しいです: 150コンテントタイプ: アプリケーション/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
0 0v=0 o=mhandley29739 7272939IN IP4 192.0.2.5 s=c=IN IP4 192.0.2.5t=mがオーディオの49217RTP/AVPと等しい、0、12m、=ビデオ3227RTP/AVP31a=rtpmap: 31LPC
3.4. Backward Compatibility
3.4. 後方の互換性
3.4.1. INVITE with RFC 2543 Syntax
3.4.1. RFCと共に2543年の構文を招待してください。
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.
そして、RFC2543あたりこれが1つの法的なメッセージである、(数個、2回、バージョン、)、後方に互換性を維持したがっているRFC3261要素でそれを受け入れるべきです。
o There is no branch parameter at all on the Via header field value.
o ブランチパラメタがViaヘッダーフィールド価値に全くありません。
o There is no From tag.
o Fromタグが全くありません。
Sparks, et al. Informational [Page 44] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[44ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
o There is no explicit Content-Length. (The body is assumed to be
all octets in the datagram after the null-line.)
o どんな明白なContent-長さもありません。 (ボディーは空行の後のデータグラムの八重奏であると思われます。)
o There is no Max-Forwards header field.
o 前方へマックスヘッダーフィールドが全くありません。
Message Details : inv2543
メッセージの詳細: inv2543
INVITE sip:UserB@example.com SIP/2.0
Via: SIP/2.0/UDP iftgw.example.com
From: <sip:+13035551111@ift.client.example.net;user=phone>
Record-Route: <sip:UserB@example.com;maddr=ss1.example.com>
To: sip:+16505552222@ss1.example.net;user=phone
Call-ID: inv2543.1717@ift.client.example.com
CSeq: 56 INVITE
Content-Type: application/sdp
INVITE一口: UserB@example.com SIP/2.0Via: SIP/2.0/UDP iftgw.example.com From: <一口: + 13035551111@ift.client.example.net;user =電話、gt;、記録的なルート: <一口: UserB@example.com;maddr はss1.example.com>To:と等しいです。 一口: + 16505552222@ss1.example.net;user は電話Call-IDと等しいです: inv2543.1717@ift.client.example.com CSeq: 56 コンテントタイプを招待してください: アプリケーション/sdp
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.5
s=-
c=IN IP4 192.0.2.5
t=0 0
m=audio 49217 RTP/AVP 0
v=0 o=mhandley29739 7272939IN IP4 192.0.2.5 s=cは0 0t=mのIN IP4 192.0.2.5=オーディオの49217RTP/AVP0と等しいです。
4. Security Considerations
4. セキュリティ問題
This document presents NON-NORMATIVE examples of SIP session establishment. The security considerations in [RFC3261] apply.
このドキュメントはSIPセッション設立に関する例をNON-NORMATIVEに提示します。 [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.
パーサは、周辺条件と悪意がある入力がそれらのデザインの一部であると慎重にみなさなければなりません。 使用が作った多くのインターネット・システムに対する攻撃は、望ましくない方法で振る舞うために実現を原因に入力しました。 メッセージの多くが本書ではポイントでのパーサ実現がそのような攻撃に伝統的に使用した圧力に設計されています。 しかしながら、このドキュメントは、包括的であることを試みません。 それは単に合格される1セットのテストではなく、考えと計画を刺激する種子であると考えられるべきです。
Sparks, et al. Informational [Page 45] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[45ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
5. Acknowledgements
5. 承認
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ナラシマン、ニルスOhlmeier、ボブ・ペンフィールド、レイナルド・ペンノ、マークPetit-Huguenin、リチャードSugarman、およびVenkatesh Venkataramananによって実行されました。
Earlier versions of this document were reviewed by Aseem Agarwal, Rafi Assadi, Gonzalo Camarillo, Ben Campbell, Cullen Jennings, Vijay Gurbani, Sunitha Kumar, Rohan Mahy, Jon Peterson, Marc Petit-Huguenin, Vidhi Rastogi, Adam Roach, Bodgey Yin Shaohua, and Tom Taylor.
このドキュメントの以前のバージョンはBodgey殷のAseem Agarwal、Rafi Assadi、ゴンサロ・キャマリロ、ベン・キャンベル、Cullenジョニングス、ビジェイGurbani、Sunithaクマー、Rohanマーイ、ジョン・ピーターソン、マークPetit-Huguenin、Vidhiラストーギ、アダム・ローチ、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.
おかげに、複合/への彼らの貢献のためのCullenジョニングスとエリック・レスコラは[SIP-SEC]のS/MIMEの例を構成するこのドキュメントと彼らの仕事のセクションをまねます。 いくつかのメッセージを寄付するためのニールDeasonと、そして、Kundanシンに以前のバージョンにおける、メッセージのパーサ合法化を実行してくださってありがとうございます。
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.
以下の個人はこのドキュメントの開発の早めの段階の間、重要なコメントを提供しました: ジャン・フランソワMule、Hemant Agrawal、ヘンリーSinnreich、デヴィッドDevanatham、ジョーPizzimenti、マットCannon、ジョンHearty、全体のMCI IPOP Designチーム、スコット・オートン、グレッグ・オスターハウト、パットSollee、ダグWeisenberg、ダニー・ミストリ、スティーブMcKinnon、デニーズ・イングラム、デニーズ・カバリェロ、トム・レッドマン、イリヤSlain、パットSollee、ジョンTruetken、およびMCI、3Com、シスコ、Lucent、およびノーテルからの他のもの。
6. Informative References
6. 有益な参照
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
2001.
[RFC2822] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、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、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
[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、「Uniform Resource Identifier(URI):」 「一般的な構文」、STD66、RFC3986、2005年1月。
[SIP-SEC] Jennings, C. and K. Ono, "Example call flows using SIP
security mechanisms", Work in Progress, July 2005.
Progress、2005年7月の[SIP-SEC]ジョニングスとC.とK.小野、「SIPセキュリティー対策を使用する例の呼び出し流れ」、Work。
Sparks, et al. Informational [Page 46] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[46ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
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 -").
完全な状態で圧縮されたアーカイブファイルを回収するために、このドキュメントの原本は以下のPerlスクリプトに入力されるように通過されるかもしれません(出力は「-xzvfのタールを塗ってください」というファイルに向け直されるか、または運ばれて、ことであるべきです)。
#!/usr/bin/perl
use strict;
my $bdata = "";
use MIME::Base64;
while(<>) {
if (/-- BEGIN MESSAGE ARCHIVE --/ .. /-- END MESSAGE ARCHIVE --/) {
if ( m/^\s*[^\s]+\s*$/) {
$bdata = $bdata . $_;
}
}
}
print decode_base64($bdata);
#/usr/bin/perl使用厳しい。 私の$bdataが等しい、「「;」 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コード化されたブロックをドキュメント構造線を取り外すために手で編集して、与えることができます。
Sparks, et al. Informational [Page 47] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[47ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
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
-- メッセージアーカイブを始めてください; H4sIAEDwcEMCA+xdW2zc2Hm2nexNG6UN3LRF0QfaiKJdyxwdnkMOhyOPVrIt27It22tdvHYTeM8MDzWc4ZAjkqORvK2bbIAAedmHtEHRdlvkoUCLFAjSlyLF9rJPLYoWrTdAg6JFHwp0i+5D0SIoEAQFuj2HnAuH5GgoW3PxmgcazYU/b4f///3Xc04Rq9ipk1JGxe6xITVAW1YUvXc5K/W8syYheEygP0lIECWJ0gkSkMAx DhwbQWs4LrY57phdcerYrjr96AZtb91L5/0paTdvbazevLHOOXo933CIvUT2cK1ukIxlb3Prq7fmYQZMT23pON/+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+3sr5Bz2iZLi5R7DkXuEd2fCkTuNNFn5CYLr+xXydxSNXafJ2Y226Z3oPk4c5u gb5ZhVqZGj8G2eegIlNTQoYyvUGF3iC3ekvsAKM0PeUU+OmpUiG6wS0AhmS1Am6ousXRLhdk7vbGrfnlrVscvSnItu3qKrE4BGF3ExKmp3DBdus1XM8jgbt+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/広告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
Sparks, et al. Informational [Page 48] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[48ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
vXVpBokzSFg8ItTsC5ppaUDaDov/cMzx/2zU/6eSnOL/aOz/GVGmtvKMKPk+ gE22dce1sZ3p6w2cnrlHyVvF1DZxrIZd6jF2FzvD+wdSevCvQQQrWNUqPUVh Pmsy0Dd3mhYS7R2IdCRWbJYbLJkGRKZtVE2H1YX1JugvDBwDCIEyoz1wTGIE NYiCRJEL9kjssMWe4AE2dOwIfkowlBC8MJO9FCGFfnlYmDR6TOQRohDhkccf aCebDcMYb/5fjMb/sun4/wnz/xmb8DMA8OxDP9e2L1Ersqco0J+/44DhwG2W RAoEyFS13WpFxY5W3UFN0XLtHYBVR6OggHfVzpBgESk5Zv0d4PgPSvsFCnW6 okhvZSmy42IMVT/C6/nJjhfSzrYbtj7e8f9iJP4nS6n+H7X/Fw7gvXbbarik MIMuhLBhBq0cydwASBQkIRc3JqzfqHsPP/rVBbRZ2XMWeWY3lCs8rhBUtHmK DTtAyTV5DTeJXYY7fFk0pS58UKihyh8e7D3ylsa7ZcKXqRmTvOJvmMGz1A1M 25M13XQa2pj9PzEbGf8rpvnfseN/F+NbKOnVbQ3OKSgxOYWMx2cDQdFoDbs9 JA4qfZMISjo3yiD5d2vELY/V/oM99V9Z3/5L/b+RtFOUAYhNHFc3t/k1ygmW 6g2/k7JyTrl/Zu7NzIxuqoSosw89kBDuN8yG08BGZvP26sNXXIsvklNOwyav flF3zFl3Tne/MF+y8YP9187OLyycyX9Rd+fK2CkIZ5tEt9VTZ+rY+ULTeqje dy0r84pqEbYbr7uvLg0uP2lHdoSDyjczp2ay2TP3596cfdiKV51fuZ7/0gvc jU36doy7yL79aisoddj7iQ1zuVaVmMLDN/0PcHbuvv8JnZk5leH9E9UaporN UPBLo7vfYqUls7MP587cp8QzhdMffOXR9x790aM//+DtR9/74J0PvvHo+4/+ 5LRnMN/3jvpQmJ17kx6ZzwSM37YcNy1bnbl3jT+VoT0wu8S+vvnw1VcWz+W/ NH/6y7/02q+8FZhGS4AQ5STuEDwQNtYhK08lexTTHQriVwhWiU3PPXNm7j7t /vx/vfcXH/7e73/41Xc/+u33JncMzLNt/+1CSURjjf9lvfF/IfsvHf83avtv k9p/55eS1QDqmrvdzPTL+M4JCCBJkgTalihppmToVPB7C+vo2Qr1smWSRTbU r0SBivcCDq1jRK5moYZV1S44TjjO3o5AzAlZCbTr+IJkvafrAU2f+QVZkOOu M1BTJGU7hu/Rzgnz+LP6HQl20i5ouOPO/wE5bP+J6fyfk+T/JZ0F84mGBeW8 gL94YG7AZ9feGaJUR9MrbBZvpHZrQSRRPKD8zbFqJNksof2FvVUZrFl2DbtR 40b0rJtznuTSnuHO1Uu1BsfGGBdOiyI6PU9/PDff3jy2529Y5vawC4AHyH82 K6NI/D/N/02Q/HtO1CrHirg4zDE6zsQ1wlkaR21/m9TIE75xddtiokHl6nTs mN58lvZpTzG+UNgl9j5j36N87WKjQRbYJ+8k7C6H/So4ZXrn/omHcUtxL8/n JNTpu0Hf7uhu+Ya1xS6AebQ+RuMafkDdQcO7HB+w2cUO8+doQTRUcpP4J0Kx zYplz+MdCq8U/FMEzuDxyNH8a1+/99QN4jidWzjyDwHt3VY21Aq3Cf1xf/T/ 2yynd2wFlGOVA6BjLGz6PcNfp5RH+eKZrOW5VsfzRy3SvP9ch3f8ehszeA/7 C6M4k3dPMTFAilAI9bppu1EK2EuxFaUQQhRx5wFhmuUIDVRCNKvR4/TOCMZo Yo4jh+4p5npgNkwTcxwpRBN3PWKYJuY4oT7e4vJchCbUy7txNOF+5rjouUD4 OFEaQYk8rxiiXJQohkoe/OiFbAIaKQGNmIAGJaCBCWgSsLQABtMog0lyg0kS dHKCPk7QxQl6OEEHJ+nfASQRr7I1cY5a6MR12o7mqIy9Ubz8W2rB9cCa2THY lo+xZofxLBTlGO62O+wCwIHz/0Tmf5WEtP5vpP5//ERaR1Plp0BFiOQNg4X+ HR4UlgLB71aWcnC9iTTMZXqUIw7oI0FUEMzJYEKAwGg6qu7Ux5r/QzKL/7OB 3jKbDNqP/6X1XyNpR7P+ny9x52JQoDsf34Cq/zYjssIDXCypSxr1L/fjUnFZ 0GdiTgYKkb3iw/rpwn9d+R9//T8K5/8lANL5P8Yd/1/gDHswBPjCvacRXqFK LJdD/ANFSzIrMPJnZo/k+6ReUPC4058MVLWIpbOll7zi/qZt+p9ySLSr3qCi VvJPQNSkzIooQa2q0HfqIoiUgwwLYfSGxcGOxaQZFml7WvCfAaA7Vv9PhhH/ T07rP0aJ//H2X98ZYJ/IIczlBLEX41scqFXNHWr9UYwXEVAUrLKh37hJ0FKM FSjkFJTLDZjvQxhkCSKlPcfrcFB+4sNHtZIx7vl/gCRnw/Vf6fwPE+X/HXoy HTaVAkTJYMJiqzbEhY3YcKMAUPisqpVNZgJatl7GTU21MLJEW4IW0m2nu0IQ ta+o+ddxEyOCGfFFsyBKJYUF3iV77nzdwLrJxHqDXjaZdTjT4pp4n3MtjuVD adc0uRo29zmr5BLX4bBNOIetLuEQlREVCcd2zEyG+1nTnRp2S+VhgsDA+I8k huRfgmn95yTGfx6rrhOJEpQOWv4lyIMVNvOgs6dqRtKp3NNgz5HIPxyf/Mve +L8e+59+SeV/FO3Gyp21lY0rNy9OBgLAAQjQ11IPGeoHI0X/yf8GZ4TZTIWH N+njrPmJiNHUKFMPewG4AfIPRYH5/wjK9Mkj4M3/JKX6fzRtbWV9ffmyHwCu Nmp61Yqs/hvvAQhQpowMvAiqHI6g8mpOlkTEiypWCciqoKgWBYEQXuDbmxZs
vXVpBokzSFg8ItTsC5ppaUDaDov/cMzx/2zU/6eSnOL/aOz/GVGmtvKMKPk+gE22dce1sZ3p6w2cnrlHyVvF1DZxrIZd6jF2FzvD+wdSevCvQQQrWNUqPUVh Pmsy0Dd3mhYS7R2IdCRWbJYbLJkGRKZtVE2H1YX1JugvDBwDCIEyoz1wTGIE NYiCRJEL9kjssMWe4AE2dOwIfkowlBC8MJO9FCGFfnlYmDR6TOQRohDhkccf aCebDcMYb/5fjMb/sun4/wnz/xmb8DMA8OxDP9e2L1Ersqco0J+/44DhwG2W RAoEyFS13WpFxY5W3UFN0XLtHYBVR6OggHfVzpBgESk5Zv0d4PgPSvsFCnW6 okhvZSmy42IMVT/C6/nJjhfSzrYbtj7e8f9iJP4nS6n+H7X/Fw7gvXbbarik MIMuhLBhBq0cydwASBQkIRc3JqzfqHsPP/rVBbRZ2XMWeWY3lCs8rhBUtHmK; DTtAyTV5DTeJXYY7fFk0pS58UKihyh8e7D3ylsa7ZcKXqRmTvOJvmMGz1A1M25M13XQa2pj9PzEbGf8rpvnfseN/F+NbKOnVbQ3OKSgxOYWMx2cDQdFoDbs9 JA4qfZMISjo3yiD5d2vELY/V/oM99V9Z3/5L/b+RtFOUAYhNHFc3t/k1ygmW 6g2/k7JyTrl/Zu7NzIxuqoSosw89kBDuN8yG08BGZvP26sNXXIsvklNOwyav; ニューハンプシャー/6y7/02q+8FZhGS4AQ5STuEDwQNtYhK08lexTTHQriVwhWiU3PPXNm7j7t /vx/vfcXH/7e73/41Xc/+u33JncMzLNt/+1CSURjjf9lvfF/IfsvHf83avtv k9p/55eS1QDqmrvdzPTL+M4JCCBJkgTalihppmToVPB7C+vo2Qr1smWSRTbU r0SBivcCDq1jRK5moYZV1S44TjjO3o5AzAlZCbTr+IJkvafrAU2f+QVZkOOu M1BTJGU7hu/Rzgnz+LP6HQl20i5ouOPO/wE5bP+J6fyfk+T/JZ0F84mGBeW8 gL94YG7AZ9feGaJUR9MrbBZvpHZrQSRRPKD8zbFqJNksof2FvVUZrFl2DbtR40b0rJtznuTSnuHO1Uu1BsfGGBdOiyI6PU9/PDff3jy2529Y5vawC4AHyH82 K6NI/D/N/02Q/HtO1CrHirg4zDE6zsQ1wlkaR21/m9TIE75xddtiokHl6nTsがあるu8S+vvnw1VcWz+; mN58lvZpTzG+UNgl9j5j36N87WKjQRbYJ+8k7C6H/So4ZXrn/omHcUtxL8/n JNTpu0Hf7uhu+Ya1xS6AebQ+RuMafkDdQcO7HB+w2cUO8+doQTRUcpP4J0Kx zYplz+MdCq8U/FMEzuDxyNH8a1+/99QN4jidWzjyDwHt3VY21Aq3Cf1xf/T/ 2yynd2wFlGOVA6BjLGz6PcNfp5RH+eKZrOW5VsfzRy3SvP9ch3f8ehszeA/7; EtP5vpP5//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、+ バイバイ、o+ddxEyOCGfFFsyBKJYUF3iV77nzdwLrJxHqDXjaZdTjT4pp4n3MtjuVD adc0uRo29zmr5BLX4bBNOIetLuEQlREVCcd2zEyG+1nTnRp2S+VhgsDA+I8k huRfgmn95yTGfx6rrhOJEpQOWv4lyIMVNvOgs6dqRtKp3NNgz5HIPxyf/Mve+L8e+59+SeV/FO3Gyp21lY0rNy9OBgLAAQjQ11IPGeoHI0X/yf8GZ4TZTIWH N+njrPmJiNHUKFMPewG4AfIPRYH5/wjK9Mkj4M3/JKX6fzRtbWV9ffmyHwCu Nmp61Yqs/hvvAQhQpowMvAiqHI6g8mpOlkTEiypWCciqoKgWBYEQXuDbmxZs
Sparks, et al. Informational [Page 49] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[49ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
VvAdlxIKjgILniUHqGCvqlQ+dXc/z9lSrWmT6439i7fvntfnwYZ+q7ni3EX2 ypZTnb8M7+yVtze2hFuX5PKVxvXVa+Duna1r98rXdpW1Sm6TvLFTXdsqmls7 SL5wcS4noO3du5XS+U18z9x+vfZGSblz4976xRuXLzxYntPuGMrayuaVO6v3 LOECuUqK6t35N4zta2QDg5vG7g6wXRm8LlX0da24s3a19vollxB9d7NcXbtz d3O5EAYuzWho2v5Sbx8uBpaqij6KxZ4Rdq0DRLJsUCsCtVRSAtiKVEXMSVgF JVHJSUpx6V5tT7hXuyddvyOU7+6DvRu65BThjXJxOZPppt1bjBHARJstqEVs fsUsWapubrO1vExs74dhs9YwXJ3BynxN3yPqQtFiQ5/t/YKMlVKRlAAsEaJl 2cjhi5g96XXsnqUeG3ez5LJ1aCUOiHlRzEtZ7vLaxvQUGwnIL2/TE3gcqNfq rD/mvZQ690qpYTvEeTXGe5MQQ2qej562v1eX4Ganp64Qw7CSHDmoQDxvkHdc m7DVQxKdB7x9/PbzL535+pWv/3j6+Asnvv328Qv0p9dOHD8uvAReeP65uc9+ 6sQvgJe7JMeFt49zlOQXKQn4ZVAXXgYvPf+pzU8/f/LE5rpwEnyOfXnxJOMN XbNsU8fC58BPsR9fOPniOja5q9RJFT4LPsN+mjr5HOU03RVeBbPs+8snuXX2 ndsgjstdILara+zmCLfccMvUH3f3T7x4/FvHdk6g4ye7lzfdubzjx5879umv fuWd/9F+cuW/b/M/+PA33vmdb33nox/93+e/rd3dKX7zP/7pzB/8ozRV/ruP v3vuz+Y+/tnGv/yD+s7dwg8vv/KjIvfjj5bd30XTv/X5//zDf/61Dz5z/qcz b9nf+MG77//1dzP/+1fv//1Pfm5+4cTDm+/P/utG7d/++Dv59xa1v/2bL//w L6997Ws/8+73//3jn+d//eaHb5E//c1Hz8U9OJ5/Vr0DT1jHq/8FCILjv0Rf /6frP40l/0s1SR2b+wnHf0JpkN3dtnfjV1uIrQjxx1t3Tf6Ok9BiVSXHlolc CljSrV2UxPvAA5yWTk6bpafZIgT9Y5jtLZEIZpL8tzcTJptnI1khqnjQtHjZ 0GOIZNQP6bHAvkVs8KgnVErDMmNtZskYcvYnQfynZ/5PD/9BWv83HvxPsP4n ZFj0ZPEgL7WDgllgxoc9w/qh4KWQbEmETdQpBwYJyoFRkol9e69MQk+W6OUf Z9VP5p/0qRRGIxsqYFrUIXEsc6zr/0EYyP/IXv0HSuV/JK29/jftf+6J1/bu MBOmUsxW9tbZ7PyKAiGbx7u7kne6ivfk6H9rlxhOaaz1/yKUQvKf1v+PPP9r 4XqmSEg9Pz/fFXqURwDAoxkGlItU+qIe6PD50K/0pYcHOxRhzKZf+Fs1uqt0 IH8JgT5jANpjMJUklV9iOifhTsNyi3i863/IohS2/+V0/c8Jsv+9+X/W7Ax3 NcOxaLyvRaOm/2ICHFBQzCKXQnAkUJslPTfgoLF9SthoT7rqpaTkJSCBBLCQ uNATjmHly6PIEdtkGzeGnABONv97r/4X0/k/R9KGvP5vTkZQKFcgEmDuoJVt O2zYEwNoizTFjL5r+jKF3w1O9vH9WxmqB54I57kb1k2TXDOtprNR1p31UplN QWbV8U6D8FQOcIEVaEak/BNpGtCOL2K15I5X/lHY/wdp/mfS5P8g6Y+VfUXJ IQQPHPTb4b4qEiXs2AbS1OLukgD8sohuNcJBC3ojKSPkKDViL9R3QF9oDfGD Vzuir0zvikef0DJS+gTYuknjlX8pG43/pfWfT7v85waJvs94IdEPZ3X/v72j 2W3bBt8L9B2IALsEcUqRki05c9Fi2LB2a7I169JDgUKxKFv+oRxSspqctp4H 7F2G9bjtFZI3Gj9RdiXZlpN2tZNVbFLHlCjJ9Pf/+x+29nu2wtS4DvXvQBu/ Dx5SKVSu+LQtgNfq/9RckP9Jjf+3BP+XN2AhVQY2ahLp+eFqs33eVlBh/Seg jZNBfx4ITpu2Q01IIFUKogMxw5TkCMOcuMyhmtAQTzxn6vLRGU24GHGWhP7A lU4cLMomFKvP+/WbSSBYapTYwFjtmijuMJQQRwdMP1uH2Jg4LctpNimxDesj zJh6p0a9beJ/U+d/ENLEoCim8n9t/9us/8/CFB0zMQ26DL3g7tQNRu7piH0Q +l9cvPEC6Ngtk8Xyh2rptanCQlxVRhaYK72BzwbJ3EBA0mxRm5qtFqHYhEQC I5//WSQMCtx56EqGQx+STfqcnIV+6MIb4rLEh2sJ6EoSifPGYz9iQt3CdCgm NrXVTsErvIX7OLaSc05cwdPgXcNWtw2nTESxYGjnCUc/iLCnUFbu3E5fg/Qm W8//blkL8T+E1vr/7bL/p0a+14tKwOraCeXY0GuUBKosBqRBNTMNQnCQp8iA d//e426XTaIsjp+Hp6F3Prft3cApYFjVOWGFog63pQfQRzsCJBsHW67/ha1W Tv5vZvX/mjX+b2KU878P1IfsxF+YOIecNycKK1E9FD0dDUCJSariAWZwudQf YL/n7DPkL6HgXmFiMuzKVmMcjNkeiNF6lNKU9nITMuhxNZM7VzFwt8fUAXXl 3BtfuL0qknL789EjJj91+6/19r98/ReN/6RV+/82zf+VZMwfKdU4HAdZesMR UohVntW4LdzRpF9E+mfuy4Z/JE7c596xgnDczDv4UjgrIHPe1Pfy/OLivEHU aYpnI/WjBH/E4/EpE2olRzpCQJ9F23Nenk4UFHX1FMzVorgfhuhUfbXqa4On DkN4I9KXJUzdvi5Pj3Sf1E6auHH37X8RJCBCJq7cYv2HZquE/5ZV2/+3w/8/
VvAdlxIKjgILniUHqGCvqlQ+dXc/z9lSrWmT6439i7fvntfnwYZ+q7ni3EX2 ypZTnb8M7+yVtze2hFuX5PKVxvXVa+Duna1r98rXdpW1Sm6TvLFTXdsqmls7 SL5wcS4noO3du5XS+U18z9x+vfZGSblz4976xRuXLzxYntPuGMrayuaVO6v3 LOECuUqK6t35N4zta2QDg5vG7g6wXRm8LlX0da24s3a19vollxB9d7NcXbtz d3O5EAYuzWho2v5Sbx8uBpaqij6KxZ4Rdq0DRLJsUCsCtVRSAtiKVEXMSVgF JVHJSUpx6V5tT7hXuyddvyOU7+6DvRu65BThjXJxOZPppt1bjBHARJstqEVs fsUsWapubrO1vExs74dhs9YwXJ3BynxN3yPqQtFiQ5/t/YKMlVKRlAAsEaJl 2cjhi5g96XXsnqUeG3ez5LJ1aCUOiHlRzEtZ7vLaxvQUGwnIL2/TE3gcqNfq; /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 CljSrV2UxPvAA5yWTk6bpafZIgT9Y5jtLZEIZpL8tzcTJptnI1khqnjQtHjZ0GOIZNQP6bHAvkVs8KgnVErDMmNtZskYcvYnQfynZ/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/4×0/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/
Sparks, et al. Informational [Page 50] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[50ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
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 --
+ 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 --
Sparks, et al. Informational [Page 51] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[51ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
Authors' Addresses
作者のアドレス
Robert J. Sparks (editor) Estacado Systems
ロバートJ.は(エディタ)エスタカードシステムをかきたてます。
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ケンジントンCrをネットワークでつなぎます。 NWアルバータT2N1X7カルガリー(カナダ)
Phone : +1.403.806.3366 EMail : ahawrylyshen@ditechcom.com
以下に電話をしてください。 +1.403 .806 .3366 メール: ahawrylyshen@ditechcom.com
Alan Johnston Avaya St. Louis, MO 63124
アラン・ジョンストン・Avayaセントルイス、MO 63124
EMail: alan@sipstation.com
メール: alan@sipstation.com
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07052
ジョナサンローゼンバーグシスコシステムズ600Lanidex Plazaパーシッパニー、ニュージャージー 07052
Phone: +1 973 952 5000 EMail: jdrosen@cisco.com URI: http://www.jdrosen.net
以下に電話をしてください。 +1 5000年の973 952メール: jdrosen@cisco.com ユリ: http://www.jdrosen.net
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
Buildingニューヨーク、コンピュータサイエンス450コンピュータサイエンスニューヨーク10027米国のヘニングSchulzrinneコロンビア大学部
Phone: +1 212 939 7042 EMail: hgs@cs.columbia.edu URI: http://www.cs.columbia.edu
以下に電話をしてください。 +1 7042年の212 939メール: hgs@cs.columbia.edu ユリ: http://www.cs.columbia.edu
Sparks, et al. Informational [Page 52] RFC 4475 SIP Torture Test Messages May 2006
スパーク、他 情報[52ページ]のRFC4475は耐久テストメッセージ2006年5月にちびちび飲みます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Sparks, et al. Informational [Page 53]
スパーク、他 情報[53ページ]
一覧
スポンサーリンク
