[要約] RFC 4475は、SIPプロトコルの負荷テストメッセージに関する規格です。その目的は、SIP実装の耐久性とセキュリティをテストすることです。
Network Working Group R. Sparks, Ed.
Request for Comments: 4475 Estacado Systems
Category: Informational A. Hawrylyshen
Ditech Networks
A. Johnston
Avaya
J. Rosenberg
Cisco Systems
H. Schulzrinne
Columbia University
May 2006
Session Initiation Protocol (SIP) Torture Test Messages
セッション開始プロトコル（SIP）拷問テストメッセージ
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This informational document gives examples of Session Initiation Protocol (SIP) test messages designed to exercise and "torture" a SIP implementation.
この情報文書は、SIPの実装を行使し「拷問」するように設計されたセッション開始プロトコル（SIP）テストメッセージの例を示します。
Table of Contents
目次
1. Overview ........................................................3
2. Document Conventions ............................................3
2.1. Representing Long Lines ....................................4
2.2. Representing Non-printable Characters ......................4
2.3. Representing Long Repeating Strings ........................5
3. SIP Test Messages ...............................................5
3.1. Parser Tests (syntax) ......................................5
3.1.1. Valid Messages ......................................5
3.1.1.1. A Short Tortuous INVITE ....................5
3.1.1.2. Wide Range of Valid Characters .............8
3.1.1.3. Valid Use of the % Escaping Mechanism ......9
3.1.1.4. Escaped Nulls in URIs .....................11
3.1.1.5. Use of % When It Is Not an Escape .........11
3.1.1.6. Message with No LWS between
Display Name and < ........................12
3.1.1.7. Long Values in Header Fields ..............12
3.1.1.8. Extra Trailing Octets in a UDP Datagram ...14
3.1.1.9. Semicolon-Separated Parameters in
URI User Part .............................16
3.1.1.10. Varied and Unknown Transport Types .......16
3.1.1.11. Multipart MIME Message ...................17
3.1.1.12. Unusual Reason Phrase ....................18
3.1.1.13. Empty Reason Phrase ......................19
3.1.2. Invalid Messages ...................................20
3.1.2.1. Extraneous Header Field Separators ........20
3.1.2.2. Content Length Larger Than Message ........20
3.1.2.3. Negative Content-Length ...................21
3.1.2.4. Request Scalar Fields with
Overlarge Values ..........................22
3.1.2.5. Response Scalar Fields with
Overlarge Values ..........................23
3.1.2.6. Unterminated Quoted String in
Display Name ..............................24
3.1.2.7. <> Enclosing Request-URI ..................25
3.1.2.8. Malformed SIP Request-URI (embedded LWS) ..26
3.1.2.9. Multiple SP Separating
Request-Line Elements .....................27
3.1.2.10. SP Characters at End of Request-Line .....28
3.1.2.11. Escaped Headers in SIP Request-URI .......29
3.1.2.12. Invalid Timezone in Date Header Field ....30
3.1.2.13. Failure to Enclose name-addr URI in <> ...31
3.1.2.14. Spaces within addr-spec ..................31
3.1.2.15. Non-token Characters in Display Name .....32
3.1.2.16. Unknown Protocol Version .................32
3.1.2.17. Start Line and CSeq Method Mismatch ......33
3.1.2.18. Unknown Method with CSeq Method Mismatch .33
3.1.2.19. Overlarge Response Code ..................34
3.2. Transaction Layer Semantics ...............................34
3.2.1. Missing Transaction Identifier .....................34
3.3. Application-Layer Semantics ...............................35
3.3.1. Missing Required Header Fields .....................35
3.3.2. Request-URI with Unknown Scheme ....................36
3.3.3. Request-URI with Known but Atypical Scheme .........36
3.3.4. Unknown URI Schemes in Header Fields ...............37
3.3.5. Proxy-Require and Require ..........................37
3.3.6. Unknown Content-Type ...............................38
3.3.7. Unknown Authorization Scheme .......................38
3.3.8. Multiple Values in Single Value Required Fields ....39
3.3.9. Multiple Content-Length Values .....................40
3.3.10. 200 OK Response with Broadcast Via Header
Field Value .......................................40
3.3.11. Max-Forwards of Zero ..............................41
3.3.12. REGISTER with a Contact Header Parameter ..........42
3.3.13. REGISTER with a url-parameter .....................42
3.3.14. REGISTER with a URL Escaped Header ................43
3.3.15. Unacceptable Accept Offering ......................44
3.4. Backward Compatibility ....................................44
3.4.1. INVITE with RFC 2543 Syntax ........................44
4. Security Considerations ........................................45
5. Acknowledgements ...............................................46
6. Informative References .........................................46
Appendix A. Bit-Exact Archive of Each Test Message ................47
A.1. Encoded Reference Messages ................................48
This document is informational and is NOT NORMATIVE on any aspect of SIP.
このドキュメントは情報提供であり、SIPのいずれの側面でも規範的ではありません。
This document contains test messages based on the current version (2.0) of the Session Initiation Protocol as, defined in [RFC3261]. Some messages exercise SIP's use of the Session Description Protocol (SDP), as described in [RFC3264].
このドキュメントには、[RFC3261]で定義されているセッション開始プロトコルの現在のバージョン（2.0）に基づくテストメッセージが含まれています。一部のメッセージは、[RFC3264]で説明されているように、SIPがセッション説明プロトコル（SDP）を使用します。
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.
メッセージは、あいまいさを回避し、インターネットドラフトレイアウトの要件を満たすために、一連のマークアップコンベンションを使用してテキストに表示されます。残りのあいまいさを解決するために、各メッセージの少しacccurateバージョンが付録にカプセル化されています。
This document contains many example SIP messages. Although SIP is a text-based protocol, many of these examples cannot be unambiguously rendered without additional markup due to the constraints placed on the formatting of RFCs. This document defines and uses the markup defined in this section to remove that ambiguity. This markup uses the start and end tag conventions of XML but does not define any XML document type.
このドキュメントには、多くのサンプルSIPメッセージが含まれています。SIPはテキストベースのプロトコルですが、これらの例の多くは、RFCのフォーマットに課される制約のため、追加のマークアップなしでは明確にレンダリングすることはできません。このドキュメントでは、このセクションで定義されているマークアップを定義および使用して、そのあいまいさを削除します。このマークアップは、XMLの開始タグとエンドタグの規則を使用しますが、XMLドキュメントタイプを定義しません。
The appendix contains an encoded binary form of all the messages and the algorithm needed to decode them into files.
付録には、すべてのメッセージのエンコードされたバイナリ形式と、それらをファイルにデコードするために必要なアルゴリズムが含まれています。
Several of these examples contain unfolded lines longer than 72 characters. These are captured between <allOneLine/> tags. The single unfolded line is reconstructed by directly concatenating all lines appearing between the tags (discarding any line feeds or carriage returns). There will be no whitespace at the end of lines. Any whitespace appearing at a fold-point will appear at the beginning of a line.
これらの例のいくつかには、72文字より長い展開された行が含まれています。これらは<alloneline/>タグ間でキャプチャされます。単一の展開ラインは、タグ間に表示されるすべての線を直接連結することにより再構築されます（ラインフィードまたはキャリッジリターンを破棄します）。線の終わりには、空白はありません。折りたたみ点に表示される白人はすべて、行の先頭に表示されます。
The following represent the same string of bits:
以下は同じビットの文字列を表しています。
Header-name: first value, reallylongsecondvalue, third value
Header-Name：First Value、ReallongSecondValue、3番目の値
<allOneLine> Header-name: first value, reallylongsecondvalue , third value </allOneLine>
<Alloneline> Header-Name：最初の値、reallongsecondValue、3番目の値</alloneline>
<allOneLine> Header-name: first value, reallylong second value, third value </allOneLine>
<Alloneline> Header-Name：最初の値、本当にロング2番目の値、3番目の値</alloneline>
Note that this is NOT SIP header-line folding, where different strings of bits have equivalent meaning.
これは、ビットのさまざまな文字列が同等の意味を持つSIPヘッダーライン折りたたみではないことに注意してください。
Several examples contain binary message bodies or header field values containing non-ascii range UTF-8 encoded characters. These are rendered here as a pair of hexadecimal digits per octet between <hex/> tags. This rendering applies even inside quoted-strings.
いくつかの例には、非ASCII範囲UTF-8エンコード文字を含むバイナリメッセージ本文またはヘッダーフィールド値が含まれています。これらは、ここで<hex/>タグ間のオクテットあたりの16進数のペアとしてレンダリングされます。このレンダリングは、引用されたストリング内でも適用されます。
The following represent the same string of bits:
以下は同じビットの文字列を表しています。
Header-name: value one
Header-name: value<hex>206F6E</hex>e
The following is a Subject header field containing the euro symbol:
以下は、ユーロシンボルを含むサブジェクトヘッダーフィールドです。
Subject: <hex>E282AC</hex>
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.
いくつかの例には、ビット文字列を繰り返して作成された非常に大きなデータ値が含まれています。これらは、<繰り返しcount = some_integer> value </repeat>を使用してここでレンダリングされます。<hex>と同様に、このレンダリングは引用された文字列内でも適用されます。
For example, the value "abcabcabc" can be rendered as <repeat
count=3>abc</repeat>. A display name of "1000000 bottles of beer"
could be rendered as
To: "1<repeat count=6><hex>30</hex></repeat> bottles of beer"
<sip:beer.example.com>
A Max-Forwards header field with a value of one google will be rendered here as
1つのGoogleの値を持つ最大ヘッダーフィールドは、ここでここでレンダリングされます
Max-Forwards: 1<repeat count=100>0</repeat>
This short, relatively human-readable message contains:
この短く、比較的読みやすいメッセージには、次のことが含まれています。
o line folding all over.
o ラインが折りたたまれています。
o escaped characters within quotes.
o 引用符の中でキャラクターを逃がした。
o an empty subject.
o 空の被写体。
o LWS between colons, semicolons, header field values, and other fields.
o コロン、セミコロン、ヘッダーフィールド値、およびその他のフィールド間のLW。
o both comma separated and separately listed header field values.
o コンマは分離され、別々にリストされているヘッダーフィールド値。
o a mix of short and long form for the same header field name.
o 同じヘッダーフィールド名の短い形と長いフォームのミックス。
o unknown Request-URI parameter.
o 不明なリクエスト-URIパラメーター。
o unknown header fields.
o 未知のヘッダーフィールド。
o an unknown header field with a value that would be syntactically invalid if it were defined in terms of generic-param.
o Generic-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 主要なゼロを備えた整数フィールド（Max-Forwardsおよび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.
未知のヘッダーヘッダーフィールドは、特別な注意に値します。このヘッダーフィールドが、セミコロン分離されたパラメーター（既存の定義されたヘッダーフィールドの多くがそうであるように）を使用したコンマ分離値の観点から定義されている場合、これは無効です。ただし、受信要素はこのフィールドの構文の定義を知らないため、ヘッダー値として解析する必要があります。プロキシは、このヘッダーフィールドを変更せずに転送します。エンドポイントはヘッダーフィールドを無視します。
Message Details : wsinv
メッセージの詳細：WSINV
INVITE sip:vivekg@chair-dnrc.example.com;unknownparam SIP/2.0
TO :
sip:vivekg@chair-dnrc.example.com ; tag = 1918181833n
from : "J Rosenberg \\\"" <sip:jdrosen@example.com>
;
tag = 98asjd8
MaX-fOrWaRdS: 0068
Call-ID: wsinv.ndaksdj@192.0.2.1
Content-Length : 150
cseq: 0009
INVITE
Via : SIP / 2.0
/UDP
192.0.2.2;branch=390skdjuw
s :
NewFangledHeader: newfangled value
continued newfangled value
UnknownHeaderWithUnusualValue: ;;,,;;,;
Content-Type: application/sdp
Route:
<sip:services.example.com;lr;unknownwith=value;unknown-no-value>
v: SIP / 2.0 / TCP spindle.example.com ;
branch = z9hG4bK9ikj8 ,
SIP / 2.0 / UDP 192.168.255.111 ; branch=
z9hG4bK30239
m:"Quoted string \"\"" <sip:jdrosen@example.com> ; newparam =
newvalue ;
secondparam ; q = 0.33
v=0 o=mhandley 29739 7272939 IN IP4 192.0.2.3 s=- c=IN IP4 192.0.2.4 t=0 0 m=audio 49217 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC
V = 0 O = Mhandley 29739 7272939 In IP4 192.0.2.3 S = -C = In IP4 192.0.2.4 T = 0 0 M = Audio 49217 RTP/AVP 0 12 M = Video 3227 RTP/AVP 31 A = RTPMAP：31 LPC
This message exercises a wider range of characters in several key syntactic elements than implementations usually see. In particular, note the following:
このメッセージは、実装が通常見るよりもいくつかの重要な構文要素で、より広い範囲の文字を行使します。特に、次のことに注意してください。
o The Method contains non-alpha characters from token. Note that % is not an escape character for this field. A method of IN%56ITE is an unknown method. It is not the same as a method of INVITE.
o この方法には、トークンの非アルファ文字が含まれています。％はこのフィールドのエスケープキャラクターではないことに注意してください。in％56iteの方法は未知の方法です。招待方法と同じではありません。
o The Request-URI contains unusual, but legal, characters.
o リクエスト-URIには、異常な、しかし合法的なキャラクターが含まれています。
o A branch parameter contains all non-alphanum characters from token.
o ブランチパラメーターには、トークンのすべての非アルファナム文字が含まれています。
o The To header field value's quoted string contains quoted-pair expansions, including a quoted NULL character.
o To Header Field Valueの引用文字列には、引用された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 Header Field値のName-Addrの名前部分には、トークン生産ルールのすべての非α文字を持つ複数のトークン（引用符付き文字列の代わりに）が含まれています。その値には、名前が非アルファナムトークン文字が含まれており、その値が非ASCII範囲UTF-8エンコード文字列である未知のヘッダーパラメーターもあります。この値のタグパラメーターには、非アルファナムトークン文字が含まれています。
o The Call-ID header field value contains the non-alphanum characters from word. Notice that in this production:
o Call-IDヘッダーフィールド値には、Wordの非アルファナム文字が含まれています。この制作では次のことに注意してください。
* % is not an escape character. It is only an escape character in productions matching the rule "escaped".
* ％は脱出キャラクターではありません。これは、「逃げられた」ルールに一致するプロダクションの脱出キャラクターにすぎません。
* " does not start a quoted string. None of ',` or " imply that there will be a matching symbol later in the string.
* 「引用された文字列を起動しません。 '、または「または」は、文字列に後で一致するシンボルがあることを意味します。
* The characters []{}()<> do not have any grouping semantics. They are not required to appear in balanced pairs.
* 文字[] {}（）<>グループ化セマンティクスはありません。バランスの取れたペアに表示される必要はありません。
o There is an unknown header field (matching extension-header) with non-alphanum token characters in its name and a UTF8-NONASCII value.
o その名前には、非過去のトークン文字とUTF 8-non ASCII値を備えた未知のヘッダーフィールド（拡張ヘッダーを一致させる）があります。
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を生成します。エンドポイントは、許容ヘッダーフィールドで理解しているメソッドをリストする501を生成します。
Message Details : intmeth
メッセージの詳細：intmeth
<allOneLine>
!interesting-Method0123456789_*+`.%indeed'~
sip:1_unusual.URI~(to-be!sure)&isn't+it$/crazy?,/;;*
:&it+has=1,weird!*pas$wo~d_too.(doesn't-it)
@example.com SIP/2.0
</allOneLine>
Via: SIP/2.0/TCP host1.example.com;branch=z9hG4bK-.!%66*_+`'~
<allOneLine>
To: "BEL:\<hex>07</hex> NUL:\<hex>00</hex> DEL:\<hex>7F</hex>"
<sip:1_unusual.URI~(to-be!sure)&isn't+it$/crazy?,/;;*
@example.com>
</allOneLine>
<allOneLine>
From: token1~` token2'+_ token3*%!.- <sip:mundane@example.com>
;fromParam''~+*_!.-%=
"<hex>D180D0B0D0B1D0BED182D0B0D18ED189D0B8D0B9</hex>"
;tag=_token~1'+`*%!-.
</allOneLine>
Call-ID: intmeth.word%ZK-!.*_+'@word`~)(><:\/"][?}{
CSeq: 139122385 !interesting-Method0123456789_*+`.%indeed'~
Max-Forwards: 255
<allOneLine>
extensionHeader-!.%*+_`'~:
<hex>EFBBBFE5A4A7E5819CE99BBB</hex>
</allOneLine>
Content-Length: 0
This INVITE exercises the % HEX HEX escaping mechanism in several places. The request is syntactically valid. Interesting features include the following:
これは、いくつかの場所で％六角脱出メカニズムを招待します。リクエストは構文的に有効です。興味深い機能には以下が含まれます。
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 Request-uriには、sips：user@example.comがuserPartに埋め込まれています。それがexample.netに意味するかもしれないことは、このドキュメントの範囲を超えています。
o The From and To URIs have escaped characters in their userparts.
o urisとurisは、ユーザーパートでキャラクターを逃れました。
o The Contact URI has escaped characters in the URI parameters. Note that the "name" uri-parameter has a value of "value%41", which is NOT equivalent to "valueA". Per [RFC3986], unescaping URI components is never performed recursively.
o コンタクトURIは、URIパラメーターの文字を免れました。「name」uri-parameterの値は「値41」の値があり、これは「Valuea」に相当しないことに注意してください。[RFC3986]に従って、URIコンポーネントの脱却を解除することは再帰的に実行されることはありません。
A parser must accept this as a well-formed message. The application using the message must treat the % HEX HEX expansions as equivalent to the character being encoded. The application must not try to interpret % as an escape character in those places where % HEX HEX ("escaped" in the grammar) is not a valid part of the construction. In [RFC3261], "escaped" only occurs in the expansions of SIP-URI, SIPS-URI, and Reason-Phrase.
パーサーは、これを整形式のメッセージとして受け入れる必要があります。メッセージを使用したアプリケーションは、％16進ヘクスの拡張をエンコードする文字に相当するものとして扱う必要があります。アプリケーションは、％16進半分（文法で「逃げた」）が構造の有効な部分ではない場所のエスケープキャラクターとして％を解釈しようとしてはなりません。[rfc3261]では、「脱出」は、sip-uri、sips-uri、およびreason-phraseの拡張でのみ発生します。
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
v=0 o=mhandley 29739 7272939 IN IP4 192.0.2.1 s=- c=IN IP4 192.0.2.1 t=0 0 m=audio 49217 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC
V = 0 O = Mhandley 29739 7272939 IN IP4 192.0.2.1 s = -c = In IP4 192.0.2.1 T = 0 0 M = Audio 49217 RTP/AVP 0 12 M = Video 3227 RTP/AVP 31 A = RTPMAP：31 LPC
This register request contains several URIs with nulls in the userpart. The message is well formed - parsers must accept this message. Implementations must take special care when unescaping the Address-of-Record (AOR) in this request so as to not prematurely shorten the username. This request registers two distinct contact URIs.
このレジスタリクエストには、userPartにnullを持ついくつかのurisが含まれています。メッセージは適切に形成されています - パーサーはこのメッセージを受け入れる必要があります。このリクエストの録音アドレス（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
In most of the places % can appear in a SIP message, it is not an escape character. This can surprise the unwary implementor. The following well-formed request has these properties:
ほとんどの場所では、％がSIPメッセージに表示される可能性がありますが、エスケープキャラクターではありません。これは、不注意な実装者を驚かせる可能性があります。次の適切に形成されたリクエストには、これらのプロパティがあります。
o The request method is unknown. It is NOT equivalent to REGISTER.
o リクエスト方法は不明です。登録するのと同等ではありません。
o The display name portion of the To and From header fields is "%Z%45". Note that this is not the same as %ZE.
o ヘッダーフィールドからの表示名の部分は「％z％45」です。これは％Zeと同じではないことに注意してください。
o This message has two Contact header field values, not three. <sip:alias2@host2.example.com> is a C%6Fntact header field value.
o このメッセージには、3つではなく2つのコンタクトヘッダーフィールド値があります。<sip：alias2@host2.example.com>はC％6FntActヘッダーフィールド値です。
A parser should accept this message as well formed. A proxy would forward or reject the message depending on what the Request-URI meant to it. An endpoint would reject this message with a 501.
パーサーには、このメッセージも適切に形成される必要があります。プロキシは、リクエスト-URIがそれを意味するものに応じて、メッセージを転送または拒否します。エンドポイントは、501でこのメッセージを拒否します。
Message Details : esc02
メッセージの詳細：ESC02
RE%47IST%45R sip:registrar.example.com SIP/2.0
To: "%Z%45" <sip:resource@example.com>
From: "%Z%45" <sip:resource@example.com>;tag=f232jadfj23
Call-ID: esc02.asdfnqwo34rq23i34jrjasdcnl23nrlknsdf
Via: SIP/2.0/TCP host.example.com;branch=z9hG4bK209%fzsnel234
CSeq: 29344 RE%47IST%45R
Max-Forwards: 70
Contact: <sip:alias1@host1.example.com>
C%6Fntact: <sip:alias2@host2.example.com>
Contact: <sip:alias3@host3.example.com>
l: 0
This OPTIONS request is not valid per the grammar in RFC 3261 since there is no LWS between the token in the display name and < in the From header field value. This has been identified as a specification bug that will be removed when RFC 3261 is revised. Elements should accept this request as well formed.
このオプションリクエストは、RFC 3261の文法ごとに有効ではありません。これは、ディスプレイ名のトークンと<from Headerフィールド値の間にLWSがないためです。これは、RFC 3261が改訂されたときに削除される仕様バグとして特定されています。要素は、このリクエストも適切に形成される必要があります。
Message Details : lwsdisp
メッセージの詳細：lwsdisp
OPTIONS sip:user@example.com SIP/2.0
To: sip:user@example.com
From: caller<sip:caller@example.com>;tag=323
Max-Forwards: 70
Call-ID: lwsdisp.1234abcd@funky.example.com
CSeq: 60 OPTIONS
Via: SIP/2.0/UDP funky.example.com;branch=z9hG4bKkdjuw
l: 0
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 Headerフィールドには、長いディスプレイ名と長いURIパラメーター名と値があります。
o The From header field has long header parameter names and values, in particular, a very long tag.
o From Headerフィールドには、長いヘッダーパラメーター名と値、特に非常に長いタグがあります。
o The Call-ID is one long token.
o Call-IDは1つの長いトークンです。
Message Details : longreq
メッセージの詳細：longreq
INVITE sip:user@example.com SIP/2.0
<allOneLine>
To: "I have a user name of
<repeat count=10>extreme</repeat> proportion"
<sip:user@example.com:6000;
unknownparam1=very<repeat count=20>long</repeat>value;
longparam<repeat count=25>name</repeat>=shortvalue;
very<repeat count=25>long</repeat>ParameterNameWithNoValue>
</allOneLine>
<allOneLine>
F: sip:
<repeat count=5>amazinglylongcallername</repeat>@example.net
;tag=12<repeat count=50>982</repeat>424
;unknownheaderparam<repeat count=20>name</repeat>=
unknowheaderparam<repeat count=15>value</repeat>
;unknownValueless<repeat count=10>paramname</repeat>
</allOneLine>
Call-ID: longreq.one<repeat count=20>really</repeat>longcallid
CSeq: 3882340 INVITE
<allOneLine>
Unknown-<repeat count=20>Long</repeat>-Name:
unknown-<repeat count=20>long</repeat>-value;
unknown-<repeat count=20>long</repeat>-parameter-name =
unknown-<repeat count=20>long</repeat>-parameter-value
</allOneLine>
Via: SIP/2.0/TCP sip33.example.com
v: SIP/2.0/TCP sip32.example.com
V: SIP/2.0/TCP sip31.example.com
Via: SIP/2.0/TCP sip30.example.com
ViA: SIP/2.0/TCP sip29.example.com
VIa: SIP/2.0/TCP sip28.example.com
VIA: SIP/2.0/TCP sip27.example.com
via: SIP/2.0/TCP sip26.example.com
viA: SIP/2.0/TCP sip25.example.com
vIa: SIP/2.0/TCP sip24.example.com
vIA: SIP/2.0/TCP sip23.example.com
V : SIP/2.0/TCP sip22.example.com
v : SIP/2.0/TCP sip21.example.com
V : SIP/2.0/TCP sip20.example.com
v : SIP/2.0/TCP sip19.example.com
Via : SIP/2.0/TCP sip18.example.com
Via : SIP/2.0/TCP sip17.example.com
Via: SIP/2.0/TCP sip16.example.com
Via: SIP/2.0/TCP sip15.example.com
Via: SIP/2.0/TCP sip14.example.com
Via: SIP/2.0/TCP sip13.example.com
Via: SIP/2.0/TCP sip12.example.com
Via: SIP/2.0/TCP sip11.example.com
Via: SIP/2.0/TCP sip10.example.com
Via: SIP/2.0/TCP sip9.example.com
Via: SIP/2.0/TCP sip8.example.com
Via: SIP/2.0/TCP sip7.example.com
Via: SIP/2.0/TCP sip6.example.com
Via: SIP/2.0/TCP sip5.example.com
Via: SIP/2.0/TCP sip4.example.com
Via: SIP/2.0/TCP sip3.example.com
Via: SIP/2.0/TCP sip2.example.com
Via: SIP/2.0/TCP sip1.example.com
<allOneLine>
Via: SIP/2.0/TCP
host.example.com;received=192.0.2.5;
branch=very<repeat count=50>long</repeat>branchvalue
</allOneLine>
Max-Forwards: 70
<allOneLine>
Contact: <sip:
<repeat count=5>amazinglylongcallername</repeat>
@host5.example.net>
</allOneLine>
Content-Type: application/sdp
l: 150
v=0 o=mhandley 29739 7272939 IN IP4 192.0.2.1 s=- c=IN IP4 192.0.2.1 t=0 0 m=audio 49217 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC
V = 0 O = Mhandley 29739 7272939 IN IP4 192.0.2.1 s = -c = In IP4 192.0.2.1 T = 0 0 M = Audio 49217 RTP/AVP 0 12 M = Video 3227 RTP/AVP 31 A = RTPMAP：31 LPC
This message contains a single SIP REGISTER request, which ostensibly arrived over UDP in a single datagram. The packet contains extra octets after the body (which in this case has zero length). The extra octets happen to look like a SIP INVITE request, but (per section 18.3 of [RFC3261]) they are just spurious noise that must be ignored.
このメッセージには、単一のSIPレジスタリクエストが含まれており、表面上は1つのデータグラムでUDPを介して到着しました。パケットには、ボディの後に余分なオクテットが含まれています（この場合、長さはゼロです）。余分なオクテットは、たまたまSIPの招待リクエストのように見えますが、（[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要素は、レジスタリクエストを正常に処理し、招待リクエストのように見える追加ビットを無視します。要素がレジスタを転送することを選択するプロキシである場合、招待状のオクテットは転送リクエストに表示されません。
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
INVITE sip:joe@example.com SIP/2.0
t: sip:joe@example.com
From: sip:caller@example.net;tag=141334
Max-Forwards: 8
Call-ID: dblreq.0ha0isnda977644900765@192.0.2.15
CSeq: 8 INVITE
Via: SIP/2.0/UDP 192.0.2.15;branch=z9hG4bKkdjuw380234
Content-Type: application/sdp
Content-Length: 150
v=0 o=mhandley 29739 7272939 IN IP4 192.0.2.15 s=- c=IN IP4 192.0.2.15 t=0 0 m=audio 49217 RTP/AVP 0 12 m =video 3227 RTP/AVP 31 a=rtpmap:31 LPC
V = 0 O = Mhandley 29739 7272939 IN IP4 192.0.2.15 S = -C = IN IP4 192.0.2.15 T = 0 0 M = Audio 49217 RTP/AVP 0 12 M =ビデオ3227 RTP/AVP 31 A = RTPMAP：31 LPC
This request has a semicolon-separated parameter contained in the "user" part of the Request-URI (whose value contains an escaped @ symbol). Receiving elements will accept this as a well-formed message. The Request-URI will parse so that the user part is "user;par=u@example.net".
このリクエストには、リクエスト-URIの「ユーザー」部分（その値には @シンボルが含まれている）の「ユーザー」部分に含まれるセミコロン分離パラメーターがあります。受信要素は、これを適切に形成されたメッセージとして受け入れます。リクエスト-URIは解析され、ユーザーパーツが「ユーザー; par=u@example.net」になるようにします。
Message Details : semiuri
メッセージの詳細：Semiuri
OPTIONS sip:user;par=u%40example.net@example.com SIP/2.0
To: sip:j_user@example.com
From: sip:caller@example.org;tag=33242
Max-Forwards: 3
Call-ID: semiuri.0ha0isndaksdj
CSeq: 8 OPTIONS
Accept: application/sdp, application/pkcs7-mime,
multipart/mixed, multipart/signed,
message/sip, message/sipfrag
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKkdjuw
l: 0
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).
この要求には、すべての既知の輸送タイプを持つヘッダーフィールド値を介して含まれ、輸送拡張メカニズムを行使します。パーサーは、このメッセージも適切に形成する必要があります。このメッセージを受信する要素は、2番目と後続のヘッダーフィールド値がUDP（またはその他のトランスポート）を指定したかのように正確に処理します。
Message Details : transports
メッセージの詳細：トランスポート
OPTIONS sip:user@example.com SIP/2.0
To: sip:user@example.com
From: <sip:caller@example.com>;tag=323
Max-Forwards: 70
Call-ID: transports.kijh4akdnaqjkwendsasfdj
Accept: application/sdp
CSeq: 60 OPTIONS
Via: SIP/2.0/UDP t1.example.com;branch=z9hG4bKkdjuw
Via: SIP/2.0/SCTP t2.example.com;branch=z9hG4bKklasjdhf
Via: SIP/2.0/TLS t3.example.com;branch=z9hG4bK2980unddj
Via: SIP/2.0/UNKNOWN t4.example.com;branch=z9hG4bKasd0f3en
Via: SIP/2.0/TCP t5.example.com;branch=z9hG4bK0a9idfnee
l: 0
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.
このメッセージ要求には、2つのボディパーツが含まれています。2番目の部分はバイナリエンコードされており、null（0x00）文字が含まれています。受信者は、受信したメッセージを適切にフレーム化するように注意する必要があります。
Parsers must accept this message as well formed, even if the application above the parser does not support multipart/signed.
パーサーの上にあるアプリケーションがMultiPart/署名をサポートしていない場合でも、パーサーはこのメッセージも適切に形成される必要があります。
Additional examples of multipart/mime messages, in particular S/MIME messages, are available in the security call flow examples document [SIP-SEC].
MultiPart/MIMEメッセージ、特にS/MIMEメッセージの追加の例は、セキュリティコールフローの例[SIP-SEC]で利用できます。
Message Details : mpart01
メッセージの詳細：MPART01
MESSAGE sip:kumiko@example.org SIP/2.0
<allOneLine>
Via: SIP/2.0/UDP 127.0.0.1:5070
;branch=z9hG4bK-d87543-4dade06d0bdb11ee-1--d87543-;rport
</allOneLine>
Max-Forwards: 70
Route: <sip:127.0.0.1:5080>
<allOneLine>
Identity: r5mwreLuyDRYBi/0TiPwEsY3rEVsk/G2WxhgTV1PF7hHuL
IK0YWVKZhKv9Mj8UeXqkMVbnVq37CD+813gvYjcBUaZngQmXc9WNZSDN
GCzA+fWl9MEUHWIZo1CeJebdY/XlgKeTa0Olvq0rt70Q5jiSfbqMJmQF
teeivUhkMWYUA=
</allOneLine>
Contact: <sip:fluffy@127.0.0.1:5070>
To: <sip:kumiko@example.org>
From: <sip:fluffy@example.com>;tag=2fb0dcc9
Call-ID: 3d9485ad0c49859b@Zmx1ZmZ5LW1hYy0xNi5sb2NhbA..
CSeq: 1 MESSAGE
Content-Transfer-Encoding: binary
Content-Type: multipart/mixed;boundary=7a9cbec02ceef655
Date: Sat, 15 Oct 2005 04:44:56 GMT
User-Agent: SIPimp.org/0.2.5 (curses)
Content-Length: 553
--7a9cbec02ceef655
Content-Type: text/plain
Content-Transfer-Encoding: binary
Hello --7a9cbec02ceef655 Content-Type: application/octet-stream Content-Transfer-Encoding: binary
hello -7a9cbec02ceef655 content-type：アプリケーション/オクテットストリームコンテンツ - 転送エンコード：バイナリ
<hex> 3082015206092A86 4886F70D010702A08201433082013F02 01013109300706052B0E03021A300B06 092A864886F70D010701318201203082 011C020101307C3070310B3009060355 04061302555331133011060355040813 0A43616C69666F726E69613111300F06 03550407130853616E204A6F7365310E 300C060355040A130573697069743129 3027060355040B132053697069742054 65737420436572746966696361746520 417574686F7269747902080195007102 330113300706052B0E03021A300D0609 2A864886F70D01010105000481808EF4 66F948F0522DD2E5978E9D95AAE9F2FE 15A06659716292E8DA2AA8D8350A68CE FFAE3CBD2BFF1675DDD5648E593DD647 28F26220F7E941749E330D9A15EDABDB 93D10C42102E7B7289D29CC0C9AE2EFB C7C0CFF9172F3B027E4FC027E1546DE4 B6AA3ABB3E66CCCB5DD6C64B8383149C B8E6FF182D944FE57B65BC99D005 </hex> --7a9cbec02ceef655--
<hex> 3082015206092A86 4886F70D010702A08201433082013F02 01013109300706052B0E03021A300B06 092A864886F70D010701318201203082 011C020101307C3070310B3009060355 04061302555331133011060355040813 0A43616C69666F726E69613111300F06 03550407130853616E204A6F7365310E 300C060355040A130573697069743129 3027060355040B132053697069742054 65737420436572746966696361746520 417574686F7269747902080195007102 330113300706052B0E03021A300D0609 2A864886F70D01010105000481808EF4 66F948F0522DD2E5978E9D95AAE9F2FE 15A06659716292E8DA2AA8D8350A68CE FFAE3CBD2BFF1675DDD5648E593DD647 28F26220F7E941749E330D9A15EDABDB 93D10C42102E7B7289D29CC0C9AE2EFB C7C0CFF9172F3B027E4FC027E1546DE4 B6AA3ABB3E66CCCB5DD6C64B8383149C B8E6FF182D944FE57B65BC99D005 </hex> --7a9cbec02ceef655--
This 200 response contains a reason phrase other than "OK". The reason phrase is intended for human consumption and may contain any string produced by
この200の応答には、「OK」以外の理由フレーズが含まれています。理由のフレーズは人間の消費を目的としており、によって生成された文字列が含まれている場合があります
Reason-Phrase = *(reserved / unreserved / escaped
/ UTF8-NONASCII / UTF8-CONT / SP / HTAB)
This particular response contains unreserved and non-ascii UTF-8 characters. This response is well formed. A parser must accept this message.
この特定の応答には、予約されていないUTF-8文字が含まれています。この応答は十分に形成されています。パーサーはこのメッセージを受け入れる必要があります。
Message Details : unreason
メッセージの詳細：不合理
<allOneLine>
SIP/2.0 200 = 2**3 * 5**2 <hex>D0BDD0BE20D181D182
D0BE20D0B4D0B5D0B2D18FD0BDD0BED181D182D0BE20D0B4
D0B5D0B2D18FD182D18C202D20D0BFD180D0BED181D182D0
BED0B5</hex>
</allOneLine>
Via: SIP/2.0/UDP 192.0.2.198;branch=z9hG4bK1324923
Call-ID: unreason.1234ksdfak3j2erwedfsASdf
CSeq: 35 INVITE
From: sip:user@example.com;tag=11141343
To: sip:user@example.edu;tag=2229
Content-Length: 154
Content-Type: application/sdp
Contact: <sip:user@host198.example.com>
v=0 o=mhandley 29739 7272939 IN IP4 192.0.2.198 s=- c=IN IP4 192.0.2.198 t=0 0 m=audio 49217 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC
V = 0 O = Mhandley 29739 7272939 IN IP4 192.0.2.198 S = -C = IN IP4 192.0.2.198 T = 0 0 M = Audio 49217 RTP/AVP 0
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>
This section contains several invalid messages reflecting errors seen at interoperability events and exploring important edge conditions that can be induced through malformed messages. This section does not attempt to be a comprehensive list of all types of invalid messages.
このセクションには、相互運用性イベントで見られるエラーを反映したいくつかの無効なメッセージが含まれており、奇形のメッセージを介して誘導できる重要なエッジ条件を調査します。このセクションでは、あらゆる種類の無効なメッセージの包括的なリストになろうとはしません。
The Via header field of this request contains additional semicolons and commas without parameters or values. The Contact header field contains additional semicolons without parameters. This message is syntactically invalid.
このリクエストのViaヘッダーフィールドには、パラメーターや値のない追加のセミコロンとコンマが含まれています。コンタクトヘッダーフィールドには、パラメーターのない追加のセミコロンが含まれています。このメッセージは構文的に無効です。
An element receiving this request should respond with a 400 Bad Request error.
このリクエストを受信する要素は、400の悪い要求エラーで応答する必要があります。
Message Details : badinv01
メッセージの詳細：badinv01
INVITE sip:user@example.com SIP/2.0
To: sip:j.user@example.com
From: sip:caller@example.net;tag=134161461246
Max-Forwards: 7
Call-ID: badinv01.0ha0isndaksdjasdf3234nas
CSeq: 8 INVITE
Via: SIP/2.0/UDP 192.0.2.15;;,;,,
Contact: "Joe" <sip:joe@example.org>;;;;
Content-Length: 152
Content-Type: application/sdp
v=0 o=mhandley 29739 7272939 IN IP4 192.0.2.15 s=- c=IN IP4 192.0.2.15 t=0 0 m=audio 49217 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC
V = 0 O = Mhandley 29739 7272939 IN IP4 192.0.2.15 S = -C = IN IP4 192.0.2.15 T = 0 0 M = Audio 49217 RTP/AVP 0 12 M =ビデオ3227 RTP/AVP 31 A = RTPMAP：31 LPC
This is a request message with a Content Length that is larger than the actual length of the body.
これは、体の実際の長さよりも大きいコンテンツの長さを持つリクエストメッセージです。
When sent over UDP (as this message ostensibly was), the receiving element should respond with a 400 Bad Request error. If this message arrived over a stream-based transport, such as TCP, there's not much the receiving party could do but wait for more data on the stream and close the connection if none is forthcoming within a reasonable period of time.
UDPを介して送信された場合（このメッセージは表面上は）、受信要素は400の悪い要求エラーで応答する必要があります。このメッセージがTCPなどのストリームベースのトランスポートを介して届いた場合、受信者ができることはあまりありませんが、ストリーム上のより多くのデータを待ち、合理的な期間内に存在しない場合は接続を閉じます。
Message Details : clerr
メッセージの詳細：Clerr
INVITE sip:user@example.com SIP/2.0
Max-Forwards: 80
To: sip:j.user@example.com
From: sip:caller@example.net;tag=93942939o2
Contact: <sip:caller@hungry.example.net>
Call-ID: clerr.0ha0isndaksdjweiafasdk3
CSeq: 8 INVITE
Via: SIP/2.0/UDP host5.example.com;branch=z9hG4bK-39234-23523
Content-Type: application/sdp
Content-Length: 9999
v=0 o=mhandley 29739 7272939 IN IP4 192.0.2.155 s=- c=IN IP4 192.0.2.155 t=0 0 m=audio 49217 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC
V = 0 O = Mhandley 29739 7272939 IN IP4 192.0.2.155 S = -C = IN IP4 192.0.2.155 T = 0 0 M = Audio 49217 RTP/AVP 0 12 M =ビデオ3227 RTP/AVP 31 A = RTPMAP：31 LPC
This request has a negative value for Content-Length.
このリクエストは、コンテンツレングスに負の値を持っています。
An element receiving this message should respond with an error. This request appeared over UDP, so the remainder of the datagram can simply be discarded. If a request like this arrives over TCP, the framing error is not recoverable, and the connection should be closed. The same behavior is appropriate for messages that arrive without a numeric value in the Content-Length header field, such as the following:
このメッセージを受信する要素は、エラーで応答する必要があります。この要求はUDPを介して表示されるため、データグラムの残りの部分を単純に破棄することができます。このようなリクエストがTCPを介して到着した場合、フレーミングエラーは回復できず、接続を閉じる必要があります。同じ動作は、次のように、コンテンツ長ヘッダーフィールドに数値なしで到着するメッセージに適しています。
Content-Length: five
コンテンツレングス：5
Implementors should take extra precautions if the technique they choose for converting this ascii field into an integral form can return a negative value. In particular, the result must not be used as a counter or array index.
このASCIIフィールドを積分形式に変換するために選択した手法が負の値を返すことができる場合、実装者は追加の予防策を講じる必要があります。特に、結果はカウンターまたはアレイインデックスとして使用してはなりません。
Message Details : ncl
メッセージの詳細：NCL
INVITE sip:user@example.com SIP/2.0
Max-Forwards: 254
To: sip:j.user@example.com
From: sip:caller@example.net;tag=32394234
Call-ID: ncl.0ha0isndaksdj2193423r542w35
CSeq: 0 INVITE
Via: SIP/2.0/UDP 192.0.2.53;branch=z9hG4bKkdjuw
Contact: <sip:caller@example53.example.net>
Content-Type: application/sdp
Content-Length: -999
v=0 o=mhandley 29739 7272939 IN IP4 192.0.2.53 s=- c=IN IP4 192.0.2.53 t=0 0 m=audio 49217 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC
V = 0 O = Mhandley 29739 7272939 IN IP4 192.0.2.53 S = -C = IN IP4 192.0.2.53 T = 0 0 M = Audio 49217 RTP/AVP 0
This request contains several scalar header field values outside their legal range.
このリクエストには、法的範囲外のいくつかのスカラーヘッダーフィールド値が含まれています。
o The CSeq sequence number is >2**32-1.
o CSEQシーケンス番号は> 2 ** 32-1です。
o The Max-Forwards value is >255.
o 最大値は> 255です。
o The Expires value is >2**32-1.
o 有効期限は> 2 ** 32-1です。
o The Contact expires parameter value is >2**32-1.
o 連絡先の有効期限はパラメーター値> 2 ** 32-1です。
An element receiving this request should respond with a 400 Bad Request due to the CSeq error. If only the Max-Forwards field were in error, the element could choose to process the request as if the field were absent. If only the expiry values were in error, the element could treat them as if they contained the default values for expiration (3600 in this case).
このリクエストを受信する要素は、CSEQエラーのために400の悪い要求で応答する必要があります。Max-Forwardsフィールドのみが誤っている場合、要素は、フィールドが存在しないかのようにリクエストを処理することを選択できます。有効期限の値のみが誤っている場合、要素は有効期限のデフォルト値を含むかのようにそれらを扱うことができます（この場合は3600）。
Other scalar request fields that may contain aberrant values include, but are not limited to, the Contact q value, the Timestamp value, and the Via ttl parameter.
異常値を含む可能性のあるその他のスカラー要求フィールドには、接触q値、タイムスタンプ値、およびvia TTLパラメーターが含まれますが、これらに限定されません。
Message Details : scalar02
メッセージの詳細：SCALAR02
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TCP host129.example.com;branch=z9hG4bK342sdfoi3
To: <sip:user@example.com>
From: <sip:user@example.com>;tag=239232jh3
CSeq: 36893488147419103232 REGISTER
Call-ID: scalar02.23o0pd9vanlq3wnrlnewofjas9ui32
Max-Forwards: 300
Expires: 1<repeat count=100>0</repeat>
Contact: <sip:user@host129.example.com>
;expires=280297596632815
Content-Length: 0
This response contains several scalar header field values outside their legal range.
この応答には、法的範囲外のいくつかのスカラーヘッダーフィールド値が含まれています。
o The CSeq sequence number is >2**32-1.
o CSEQシーケンス番号は> 2 ** 32-1です。
o The Retry-After field is unreasonably large (note that RFC 3261 does not define a legal range for this field).
o 再試行後のフィールドは不当に大きい（RFC 3261はこのフィールドの法的範囲を定義していないことに注意してください）。
o The Warning field has a warning-value with more than 3 digits.
o 警告フィールドには、3桁以上の警告価値があります。
An element receiving this response will simply discard it.
この応答を受信する要素は、単純に破棄します。
Message Details : scalarlg
メッセージの詳細：Scalarlg
SIP/2.0 503 Service Unavailable
<allOneLine>
Via: SIP/2.0/TCP host129.example.com
;branch=z9hG4bKzzxdiwo34sw
;received=192.0.2.129
</allOneLine>
To: <sip:user@example.com>
From: <sip:other@example.net>;tag=2easdjfejw
CSeq: 9292394834772304023312 OPTIONS
Call-ID: scalarlg.noase0of0234hn2qofoaf0232aewf2394r
Retry-After: 949302838503028349304023988
Warning: 1812 overture "In Progress"
Content-Length: 0
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フィールドの表示名に未終端の見積もりを伴うリクエストです。このリクエストを受信する要素は、400の悪い要求エラーを返す必要があります。
An element could attempt to infer a terminating quote and accept the message. Such an element needs to take care that it makes a reasonable inference when it encounters
要素は、終了した引用を推測し、メッセージを受け入れようとすることができます。そのような要素は、それが遭遇するときに合理的な推論をするように注意する必要があります
To: "Mr J. User <sip:j.user@example.com> <sip:realj@example.net>
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
v=0 o=mhandley 29739 7272939 IN IP4 192.0.2.15 s=- c=IN IP4 192.0.2.15 t=0 0 m=audio 49217 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC
V = 0 O = Mhandley 29739 7272939 IN IP4 192.0.2.15 S = -C = IN IP4 192.0.2.15 T = 0 0 M = Audio 49217 RTP/AVP 0 12 M =ビデオ3227 RTP/AVP 31 A = RTPMAP：31 LPC
This INVITE request is invalid because the Request-URI has been enclosed within in "<>".
この招待リクエストは、リクエスト-URIが「<>」内に囲まれているため、無効です。
It is reasonable always to reject a request with this error with a 400 Bad Request. Elements attempting to be liberal with what they accept may choose to ignore the brackets. If the element forwards the request, it must not include the brackets in the messages it sends.
400の悪いリクエストでこのエラーでリクエストを拒否することは常に合理的です。彼らが受け入れるものでリベラルになろうとする要素は、括弧を無視することを選択するかもしれません。要素がリクエストを転送する場合、送信するメッセージにブラケットを含めてはなりません。
Message Details : ltgtruri
メッセージの詳細：ltgtruri
INVITE <sip:user@example.com> SIP/2.0
To: sip:user@example.com
From: sip:caller@example.net;tag=39291
Max-Forwards: 23
Call-ID: ltgtruri.1@192.0.2.5
CSeq: 1 INVITE
Via: SIP/2.0/UDP 192.0.2.5
Contact: <sip:caller@host5.example.net>
Content-Type: application/sdp
Content-Length: 159
v=0 o=mhandley 29739 7272939 IN IP4 192.0.2.5 s=- c=IN IP4 192.0.2.5 t=3149328700 0 m=audio 49217 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC
V = 0 O = Mhandley 29739 7272939 IN IP4 192.0.2.5 S = -C = IN IP4 192.0.2.5 T = 3149328700 0 M = Audio 49217 RTP/AVP 0 12 M =ビデオ3227 RTP/AVP 31A = RTPMAP：31 LPC
This INVITE has illegal LWS within the Request-URI.
この招待状には、リクエスト-URI内に違法なLWがあります。
An element receiving this request should respond with a 400 Bad Request.
このリクエストを受信する要素は、400の悪いリクエストで応答する必要があります。
An element could attempt to ignore the embedded LWS for those schemes (like SIP) where doing so would not introduce ambiguity.
要素は、これらのスキーム（SIPなど）の埋め込みLWを無視しようとする可能性があります。
Message Details : lwsruri
メッセージの詳細：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
v=0 o=mhandley 29739 7272939 IN IP4 192.0.2.1 s=- c=IN IP4 192.0.2.1 t=3149328700 0 m=audio 49217 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC
V = 0 O = Mhandley 29739 7272939 IN IP4 192.0.2.1 s = -c = In IP4 192.0.2.1 T = 3149328700 0 M = Audio 49217 RTP/AVP 0 12 M =ビデオ3227 RTP/AVP 31A = RTPMAP：31 LPC
This INVITE has illegal multiple SP characters between elements of the start line.
この招待状には、スタートラインの要素間に違法な複数の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
v=0 o=mhandley 29739 7272939 IN IP4 192.0.2.1 s=- c=IN IP4 192.0.2.1 t=0 0 m=audio 49217 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC
V = 0 O = Mhandley 29739 7272939 IN IP4 192.0.2.1 s = -c = In IP4 192.0.2.1 T = 0 0 M = Audio 49217 RTP/AVP 0 12 M = Video 3227 RTP/AVP 31 A = RTPMAP：31 LPC
This OPTIONS request contains SP characters between the SIP-Version field and the CRLF terminating the Request-Line.
このオプション要求には、SIPバージョンフィールドとCRLFの間にSP文字が含まれています。リクエストラインを終了します。
It is acceptable to reject this request as malformed. An element that is liberal in what it accepts may ignore these extra SP characters when processing the request. If the element forwards the request, it must not include these extra SP characters in the messages it sends.
この要求を奇形として拒否することは受け入れられます。それが受け入れるものにおいてリベラルである要素は、リクエストを処理するときにこれらの余分なSP文字を無視する場合があります。要素がリクエストを転送する場合、送信するメッセージにこれらの追加のSP文字を含めてはなりません。
Message Details : trws
メッセージの詳細：TRW
OPTIONS sip:remote-target@example.com SIP/2.0<hex>2020</hex>
Via: SIP/2.0/TCP host1.example.com;branch=z9hG4bK299342093
To: <sip:remote-target@example.com>
From: <sip:local-resource@example.com>;tag=329429089
Call-ID: trws.oicu34958239neffasdhr2345r
Accept: application/sdp
CSeq: 238923 OPTIONS
Max-Forwards: 70
Content-Length: 0
This INVITE is malformed, as the SIP Request-URI contains escaped headers.
SIP Request-URIにはエスケープヘッダーが含まれているため、この招待状は奇形です。
It is acceptable for an element to reject this request with a 400 Bad Request. An element could choose to be liberal in what it accepts and ignore the escaped headers. If the element is a proxy, the escaped headers must not appear in the Request-URI of the forwarded request (and most certainly must not be translated into the actual header of the forwarded request).
要素が400の悪いリクエストでこのリクエストを拒否することは許容されます。要素は、逃げ出したヘッダーを受け入れ、無視することにおいてリベラルになることを選択できます。要素がプロキシである場合、エスケープヘッダーは、転送された要求のリクエスト-URIに表示されてはなりません（そして、間違いなく、転送された要求の実際のヘッダーに翻訳してはなりません）。
Message Details : escruri
メッセージの詳細：Escruri
INVITE sip:user@example.com?Route=%3Csip:example.com%3E SIP/2.0
To: sip:user@example.com
From: sip:caller@example.net;tag=341518
Max-Forwards: 7
Contact: <sip:caller@host39923.example.net>
Call-ID: escruri.23940-asdfhj-aje3br-234q098w-fawerh2q-h4n5
CSeq: 149209342 INVITE
Via: SIP/2.0/UDP host-of-the-hour.example.com;branch=z9hG4bKkdjuw
Content-Type: application/sdp
Content-Length: 150
v=0 o=mhandley 29739 7272939 IN IP4 192.0.2.1 s=- c=IN IP4 192.0.2.1 t=0 0 m=audio 49217 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC
V = 0 O = Mhandley 29739 7272939 IN IP4 192.0.2.1 s = -c = In IP4 192.0.2.1 T = 0 0 M = Audio 49217 RTP/AVP 0 12 M = Video 3227 RTP/AVP 31 A = RTPMAP：31 LPC
This INVITE is invalid, as it contains a non-GMT time zone in the SIP Date header field.
SIP日付ヘッダーフィールドに非GMTタイムゾーンが含まれているため、この招待状は無効です。
It is acceptable to reject this request as malformed (though an element shouldn't do that unless the contents of the Date header field were actually important to its processing). An element wishing to be liberal in what it accepts could ignore this value altogether if it wasn't going to use the Date header field anyway. Otherwise, it could attempt to interpret this date and adjust it to GMT.
この要求を奇形として拒否することは許容されます（ただし、日付ヘッダーフィールドの内容が実際にその処理に重要であっていない限り、要素はそれを行うべきではありません）。とにかく日付ヘッダーフィールドを使用しない場合、それが受け入れるものにリベラルになりたいと願う要素は、この値を完全に無視する可能性があります。それ以外の場合は、この日付を解釈してGMTに調整しようとする可能性があります。
RFC 3261 explicitly defines the only acceptable time zone designation as "GMT". "UT", while synonymous with GMT per [RFC2822], is not valid. "UTC" and "UCT" are also invalid.
RFC 3261は、唯一の許容されるタイムゾーンの指定を「GMT」として明示的に定義しています。「UT」は、[RFC2822]ごとにGMTと同義語ですが、有効ではありません。「UTC」と「UCT」も無効です。
Message Details : baddate
メッセージの詳細：BadDate
INVITE sip:user@example.com SIP/2.0
To: sip:user@example.com
From: sip:caller@example.net;tag=2234923
Max-Forwards: 70
Call-ID: baddate.239423mnsadf3j23lj42--sedfnm234
CSeq: 1392934 INVITE
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKkdjuw
Date: Fri, 01 Jan 2010 16:00:00 EST
Contact: <sip:caller@host5.example.net>
Content-Type: application/sdp
Content-Length: 150
v=0 o=mhandley 29739 7272939 IN IP4 192.0.2.5 s=- c=IN IP4 192.0.2.5 t=0 0 m=audio 49217 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC
V = 0 O = Mhandley 29739 7272939 In IP4 192.0.2.5 S = -C = IN IP4 192.0.2.5 T = 0 0 M = Audio 49217 RTP/AVP 0 12 M = Video 3227 RTP/AVP 31 A = RTPMAP：31 LPC
This REGISTER request is malformed. The SIP URI contained in the Contact Header field has an escaped header, so the field must be in name-addr form (which implies that the URI must be enclosed in <>).
このレジスタリクエストは奇形です。コンタクトヘッダーフィールドに含まれるSIP URIには逃げられたヘッダーがあるため、フィールドはname-addr形式でなければなりません（これは、URIを<>に囲む必要があることを意味します）。
It is reasonable for an element receiving this request to respond with a 400 Bad Request. An element choosing to be liberal in what it accepts could infer the angle brackets since there is no ambiguity in this example. In general, that won't be possible.
この要求を受け取った要素が400の悪いリクエストで応答することは合理的です。この例にはあいまいさがないため、受け入れているものでリベラルになることを選択する要素は、角度ブラケットを推測する可能性があります。一般的に、それは不可能です。
Message Details : regbadct
メッセージの詳細：regbadct
REGISTER sip:example.com SIP/2.0
To: sip:user@example.com
From: sip:user@example.com;tag=998332
Max-Forwards: 70
Call-ID: regbadct.k345asrl3fdbv@10.0.0.1
CSeq: 1 REGISTER
Via: SIP/2.0/UDP 135.180.130.133:5060;branch=z9hG4bKkdjuw
Contact: sip:user@example.com?Route=%3Csip:sip.example.com%3E
l: 0
This request is malformed, since the addr-spec in the To header field contains spaces. Parsers receiving this request must not break. It is reasonable to reject this request with a 400 Bad Request response. Elements attempting to be liberal may ignore the spaces.
ヘッダーフィールドのADDRスペックにはスペースが含まれているため、このリクエストは奇形です。このリクエストを受け取るパーサーは壊れてはなりません。400の悪いリクエスト応答でこのリクエストを拒否することは合理的です。リベラルになろうとする要素は、空間を無視するかもしれません。
Message Details : badaspec
メッセージの詳細：badaspec
OPTIONS sip:user@example.org SIP/2.0
Via: SIP/2.0/UDP host4.example.com:5060;branch=z9hG4bKkdju43234
Max-Forwards: 70
From: "Bell, Alexander" <sip:a.g.bell@example.com>;tag=433423
To: "Watson, Thomas" < sip:t.watson@example.org >
Call-ID: badaspec.sdf0234n2nds0a099u23h3hnnw009cdkne3
Accept: application/sdp
CSeq: 3923239 OPTIONS
l: 0
This OPTIONS request is malformed, since the display names in the To and From header fields contain non-token characters but are unquoted.
ヘッダーフィールドからのディスプレイ名にはトークン以外の文字が含まれているが、引用されていないため、このオプション要求は不正されています。
It is reasonable always to reject this kind of error with a 400 Bad Request response.
400の悪い要求応答でこの種のエラーを拒否することは常に合理的です。
An element may attempt to be liberal in what it receives and infer the missing quotes. If this element were a proxy, it must not propagate the error into the request it forwards. As a consequence, if the fields are covered by a signature, there's not much point in trying to be liberal - the message should simply be rejected.
要素は、それが受け取るものにおいてリベラルになり、欠落している引用を推測しようとするかもしれません。この要素がプロキシである場合、エラーを転送するリクエストに伝播してはなりません。結果として、フィールドが署名でカバーされている場合、リベラルになろうとすることにはあまり意味がありません - メッセージは単に拒否されるべきです。
Message Details : baddn
メッセージの詳細：baddn
OPTIONS sip:t.watson@example.org SIP/2.0
Via: SIP/2.0/UDP c.example.com:5060;branch=z9hG4bKkdjuw
Max-Forwards: 70
From: Bell, Alexander <sip:a.g.bell@example.com>;tag=43
To: Watson, Thomas <sip:t.watson@example.org>
Call-ID: baddn.31415@c.example.com
Accept: application/sdp
CSeq: 3923239 OPTIONS
l: 0
To an element implementing [RFC3261], this request is malformed due to its high version number.
[RFC3261]を実装する要素に対して、このリクエストはバージョン数が高いために奇形されています。
The element should respond to the request with a 505 Version Not Supported error.
要素は、サポートされていないエラーがない505バージョンでリクエストに応答する必要があります。
Message Details : badvers
メッセージの詳細：Badvers
OPTIONS sip:t.watson@example.org SIP/7.0
Via: SIP/7.0/UDP c.example.com;branch=z9hG4bKkdjuw
Max-Forwards: 70
From: A. Bell <sip:a.g.bell@example.com>;tag=qweoiqpe
To: T. Watson <sip:t.watson@example.org>
Call-ID: badvers.31417@c.example.com
CSeq: 1 OPTIONS
l: 0
This request has mismatching values for the method in the start line and the CSeq header field. Any element receiving this request will respond with a 400 Bad Request.
このリクエストには、スタートラインとCSEQヘッダーフィールドのメソッドの不一致の値があります。このリクエストを受信する要素は、400の悪いリクエストで応答します。
Message Details : mismatch01
メッセージの詳細：mismatch01
OPTIONS sip:user@example.com SIP/2.0
To: sip:j.user@example.com
From: sip:caller@example.net;tag=34525
Max-Forwards: 6
Call-ID: mismatch01.dj0234sxdfl3
CSeq: 8 INVITE
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKkdjuw
l: 0
This message has an unknown method in the start line, and a CSeq method tag that does not match.
このメッセージには、スタート行に不明な方法があり、一致しないCSEQメソッドタグがあります。
Any element receiving this response should respond with a 501 Not Implemented. A 400 Bad Request is also acceptable, but choosing a 501 (particularly at proxies) has better future-proof characteristics.
この応答を受信する要素は、実装されていない501で応答する必要があります。400の悪いリクエストも受け入れられますが、501（特にプロキシで）を選択すると、将来の根拠の特性が向上します。
Message Details : mismatch02
メッセージの詳細：mismatch02
NEWMETHOD sip:user@example.com SIP/2.0
To: sip:j.user@example.com
From: sip:caller@example.net;tag=34525
Max-Forwards: 6
Call-ID: mismatch02.dj0234sxdfl3
CSeq: 8 INVITE
Contact: <sip:caller@host.example.net>
Via: SIP/2.0/UDP host.example.net;branch=z9hG4bKkdjuw
Content-Type: application/sdp
l: 138
v=0 o=mhandley 29739 7272939 IN IP4 192.0.2.1 c=IN IP4 192.0.2.1 m=audio 49217 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC
V = 0 o = Mhandley 29739 7272939 In IP4 192.0.2.1 C = IN IP4 192.0.2.1 M = Audio 49217 RTP/AVP 0 12 M =ビデオ3227 RTP/AVP 31 A = RTPMAP：31 LPC
This response has a response code larger than 699. An element receiving this response should simply drop it.
この応答には、699を超える応答コードがあります。この応答を受信する要素は、単純にドロップする必要があります。
Message Details : bigcode
メッセージの詳細：BigCode
SIP/2.0 4294967301 better not break the receiver
Via: SIP/2.0/UDP 192.0.2.105;branch=z9hG4bK2398ndaoe
Call-ID: bigcode.asdof3uj203asdnf3429uasdhfas3ehjasdfas9i
CSeq: 353494 INVITE
From: <sip:user@example.com>;tag=39ansfi3
To: <sip:user@example.edu>;tag=902jndnke3
Content-Length: 0
Contact: <sip:user@host105.example.com>
This section contains tests that exercise an implementation's parser and transaction-layer logic.
このセクションには、実装のパーサーとトランザクション層のロジックを行使するテストが含まれています。
This request indicates support for RFC 3261-style transaction identifiers by providing the z9hG4bK prefix to the branch parameter, but it provides no identifier. A parser must not break when receiving this message. An element receiving this request could reject the request with a 400 Response (preferably statelessly, as other requests from the source are likely also to have a malformed branch parameter), or it could fall back to the RFC 2543-style transaction identifier.
この要求は、Z9HG4BKプレフィックスをBranchパラメーターに提供することにより、RFC 3261スタイルのトランザクション識別子のサポートを示していますが、識別子は提供しません。パーサーは、このメッセージを受信するときに壊れてはなりません。このリクエストを受信する要素は、400の応答で要求を拒否する可能性があります（できれば、ソースからの他のリクエストも不正なブランチパラメーターを持つ可能性が高いため）、またはRFC 2543スタイルのトランザクション識別子に戻る可能性があります。
Message Details : badbranch
メッセージの詳細：Badbranch
OPTIONS sip:user@example.com SIP/2.0
To: sip:user@example.com
From: sip:caller@example.org;tag=33242
Max-Forwards: 3
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bK
Accept: application/sdp
Call-ID: badbranch.sadonfo23i420jv0as0derf3j3n
CSeq: 8 OPTIONS
l: 0
This section contains tests that exercise an implementation's parser and application-layer logic.
このセクションには、実装のパーサーとアプリケーション層ロジックを行使するテストが含まれています。
This request contains no Call-ID, From, or To header fields.
このリクエストには、call-id、from、またはheaderフィールドが含まれていません。
An element receiving this message must not break because of the missing information. Ideally, it will respond with a 400 Bad Request error.
このメッセージを受信する要素は、情報が欠落しているために壊れてはなりません。理想的には、400の悪い要求エラーで応答します。
Message Details : insuf
メッセージの詳細：Insuf
INVITE sip:user@example.com SIP/2.0
CSeq: 193942 INVITE
Via: SIP/2.0/UDP 192.0.2.95;branch=z9hG4bKkdj.insuf
Content-Type: application/sdp
l: 152
v=0 o=mhandley 29739 7272939 IN IP4 192.0.2.95 s=- c=IN IP4 192.0.2.95 t=0 0 m=audio 49217 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC
V = 0 O = Mhandley 29739 7272939 IN IP4 192.0.2.95 S = -C = IN IP4 192.0.2.95 T = 0 0 M = Audio 49217 RTP/AVP 0
This OPTIONS contains an unknown URI scheme in the Request-URI. A parser must accept this as a well-formed SIP request.
このオプションには、Request-URIに不明なURIスキームが含まれています。パーサーは、これをよく形成されたSIPリクエストとして受け入れる必要があります。
An element receiving this request will reject it with a 416 Unsupported URI Scheme response.
このリクエストを受信する要素は、サポートされていないURIスキーム応答でそれを拒否します。
Some early implementations attempt to look at the contents of the To header field to determine how to route this kind of request. That is an error. Despite the fact that the To header field and the Request URI frequently look alike in simplistic first-hop messages, the To header field contains no routing information.
一部の早期実装は、この種のリクエストをルーティングする方法を決定するために、ヘッダーフィールドのコンテンツを調べようとします。それはエラーです。To HeaderフィールドとリクエストURIが単純な最初のホップメッセージで頻繁に似ているという事実にもかかわらず、To Headerフィールドにはルーティング情報が含まれていません。
Message Details : unkscm
メッセージの詳細：UNKSCM
OPTIONS nobodyKnowsThisScheme:totallyopaquecontent SIP/2.0
To: sip:user@example.com
From: sip:caller@example.net;tag=384
Max-Forwards: 3
Call-ID: unkscm.nasdfasser0q239nwsdfasdkl34
CSeq: 3923423 OPTIONS
Via: SIP/2.0/TCP host9.example.com;branch=z9hG4bKkdjuw39234
Content-Length: 0
This OPTIONS contains an Request-URI with an IANA-registered scheme that does not commonly appear in Request-URIs of SIP requests. A parser must accept this as a well-formed SIP request.
このオプションには、SIPリクエストのリクエスト-urisには一般的に表示されないIANA登録スキームを備えたリクエスト-URIが含まれています。パーサーは、これをよく形成されたSIPリクエストとして受け入れる必要があります。
If an element will never accept this scheme as meaningful in a Request-URI, it is appropriate to treat it as unknown and return a 416 Unsupported URI Scheme response. If the element might accept some URIs with this scheme, then a 404 Not Found is appropriate for those URIs it doesn't accept.
要素がこのスキームをリクエストURIで意味のあるものとして受け入れない場合、それを不明として扱い、416のサポートされていないURIスキーム応答を返すことが適切です。要素がこのスキームでいくつかのURIを受け入れる可能性がある場合、404が見つかりません。
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
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、および連絡先ヘッダーフィールドに登録されたスキームが含まれています。メッセージは構文的に有効です。パーサーは、このメッセージを受信したときに失敗してはなりません。
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の他の要求と同じように扱う必要があります。登録官は、次のように：ヘッダーフィールドがAORとしてSIPまたはSIPS URIを封じ込める必要があるため、400の悪い要求応答でこのリクエストを拒否します。
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
This request tests proper implementation of SIP's Proxy-Require and Require extension mechanisms.
このリクエストは、SIPのプロキシリクイアの適切な実装をテストし、拡張メカニズムを必要とします。
Any element receiving this request will respond with a 420 Bad Extension response, containing an Unsupported header field listing these features from either the Require or Proxy-Require header field, depending on the role in which the element is responding.
このリクエストを受信する要素は、要素が応答している役割に応じて、これらの機能を要求またはプロキシレクイアヘッダーフィールドのいずれかからリストするサポートされていないヘッダーフィールドを含む420の悪い拡張応答で応答します。
Message Details : bext01
メッセージの詳細：bext01
OPTIONS sip:user@example.com SIP/2.0
To: sip:j_user@example.com
From: sip:caller@example.net;tag=242etr
Max-Forwards: 6
Call-ID: bext01.0ha0isndaksdj
Require: nothingSupportsThis, nothingSupportsThisEither
Proxy-Require: noProxiesSupportThis, norDoAnyProxiesSupportThis
CSeq: 8 OPTIONS
Via: SIP/2.0/TLS fold-and-staple.example.com;branch=z9hG4bKkdjuw
Content-Length: 0
This INVITE request contains a body of unknown type. It is syntactically valid. A parser must not fail when receiving it.
この招待リクエストには、未知のタイプの本体が含まれています。構文的に有効です。パーサーは、それを受け取ったときに失敗してはなりません。
A proxy receiving this request would process it just as it would any other INVITE. An endpoint receiving this request would reject it with a 415 Unsupported Media Type error.
このリクエストを受信するプロキシは、他の招待と同じように処理されます。このリクエストを受信するエンドポイントは、415個のサポートされていないメディアタイプエラーでそれを拒否します。
Message Details : invut
メッセージの詳細：Invut
INVITE sip:user@example.com SIP/2.0
Contact: <sip:caller@host5.example.net>
To: sip:j.user@example.com
From: sip:caller@example.net;tag=8392034
Max-Forwards: 70
Call-ID: invut.0ha0isndaksdjadsfij34n23d
CSeq: 235448 INVITE
Via: SIP/2.0/UDP somehost.example.com;branch=z9hG4bKkdjuw
Content-Type: application/unknownformat
Content-Length: 40
<audio>
<pcmu port="443"/>
</audio>
This REGISTER request contains an Authorization header field with an unknown scheme. The request is well formed. A parser must not fail when receiving it.
このレジスタリクエストには、未知のスキームを持つ認証ヘッダーフィールドが含まれています。リクエストは適切に形成されています。パーサーは、それを受け取ったときに失敗してはなりません。
A proxy will treat this request as it would any other REGISTER. If it forwards the request, it will include this Authorization header field unmodified in the forwarded messages.
プロキシは、このリクエストを他の登録と同様に扱います。リクエストを転送すると、転送されたメッセージに変更されていないこの承認ヘッダーフィールドが含まれます。
A registrar that does not care about challenge-response authentication will simply ignore the Authorization header field, processing this registration as if the field were not present. A registrar that does care about challenge-response authentication will reject this request with a 401, issuing a new challenge with a scheme it understands.
チャレンジ応答認証を気にしないレジストラは、フィールドが存在しないかのようにこの登録を処理する認証ヘッダーフィールドを単純に無視します。チャレンジ応答認証を気にするレジストラは、401でこのリクエストを拒否し、理解しているスキームで新しい課題を発行します。
Endpoints choosing not to act as registrars will simply reject the request. A 405 Method Not Allowed is appropriate.
レジストラとして行動しないことを選択するエンドポイントは、単にリクエストを拒否します。許可されていない405メソッドが適切です。
Message Details : regaut01
メッセージの詳細：regaut01
REGISTER sip:example.com SIP/2.0
To: sip:j.user@example.com
From: sip:j.user@example.com;tag=87321hj23128
Max-Forwards: 8
Call-ID: regaut01.0ha0isndaksdj
CSeq: 9338 REGISTER
Via: SIP/2.0/TCP 192.0.2.253;branch=z9hG4bKkdjuw
Authorization: NoOneKnowsThisScheme opaque-data=here
Content-Length:0
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、max-forwards、およびcseq値を含むリクエストが含まれています。このリクエストを受信する要素は壊れてはなりません。
An element receiving this request would respond with a 400 Bad Request error.
このリクエストを受信する要素は、400の悪い要求エラーで応答します。
Message Details : multi01
メッセージの詳細：Multi01
INVITE sip:user@company.com SIP/2.0
Contact: <sip:caller@host25.example.net>
Via: SIP/2.0/UDP 192.0.2.25;branch=z9hG4bKkdjuw
Max-Forwards: 70
CSeq: 5 INVITE
Call-ID: multi01.98asdh@192.0.2.1
CSeq: 59 INVITE
Call-ID: multi01.98asdh@192.0.2.2
From: sip:caller@example.com;tag=3413415
To: sip:user@example.com
To: sip:other@example.net
From: sip:caller@example.net;tag=2923420123
Content-Type: application/sdp
l: 154
Contact: <sip:caller@host36.example.net>
Max-Forwards: 5
v=0 o=mhandley 29739 7272939 IN IP4 192.0.2.25 s=- c=IN IP4 192.0.2.25 t=0 0 m=audio 49217 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC
V = 0 O = Mhandley 29739 7272939 IN IP4 192.0.2.25 S = -C = IN IP4 192.0.2.25 T = 0 0 M = Audio 49217 RTP/AVP 0 12 M =ビデオ3227 RTP/AVP 31 A = RTPMAP：31 LPC
Multiple conflicting Content-Length header field values appear in this request.
この要求には、複数の競合するコンテンツ長ヘッダーフィールド値が表示されます。
From a framing perspective, this situation is equivalent to an invalid Content-Length value (or no value at all).
フレーミングの観点から見ると、この状況は無効なコンテンツレングス値に相当します（またはまったく値はありません）。
An element receiving this message should respond with an error. This request appeared over UDP, so the remainder of the datagram can simply be discarded. If a request like this arrives over TCP, the framing error is not recoverable, and the connection should be closed.
このメッセージを受信する要素は、エラーで応答する必要があります。この要求はUDPを介して表示されるため、データグラムの残りの部分を単純に破棄することができます。このようなリクエストがTCPを介して到着した場合、フレーミングエラーは回復できず、接続を閉じる必要があります。
Message Details : mcl01
メッセージの詳細：MCL01
OPTIONS sip:user@example.com SIP/2.0
Via: SIP/2.0/UDP host5.example.net;branch=z9hG4bK293423
To: sip:user@example.com
From: sip:other@example.net;tag=3923942
Call-ID: mcl01.fhn2323orihawfdoa3o4r52o3irsdf
CSeq: 15932 OPTIONS
Content-Length: 13
Max-Forwards: 60
Content-Length: 5
Content-Type: text/plain
There's no way to know how many octets are supposed to be here.
ここにあるはずのオクテットの数を知る方法はありません。
This message is a response with a 2nd Via header field value's sent-by containing 255.255.255.255. The message is well formed; parsers must not fail when receiving it.
このメッセージは、255.255.255.255を含むHeader Field ValueのSent-Byを介して2番目の応答です。メッセージはよく形成されています。パーサーはそれを受け取るときに失敗してはなりません。
Per [RFC3261], an endpoint receiving this message should simply discard it.
[RFC3261]に従って、このメッセージを受信するエンドポイントは単純に破棄する必要があります。
If a proxy followed normal response processing rules blindly, it would forward this response to the broadcast address. To protect against this as an avenue of attack, proxies should drop such responses.
プロキシが通常の応答処理ルールに盲目的に続いた場合、この応答はブロードキャストアドレスに転送されます。これを攻撃の道として保護するために、プロキシはそのような応答をドロップする必要があります。
Message Details : bcast
メッセージの詳細：bcast
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.198;branch=z9hG4bK1324923
Via: SIP/2.0/UDP 255.255.255.255;branch=z9hG4bK1saber23
Call-ID: bcast.0384840201234ksdfak3j2erwedfsASdf
CSeq: 35 INVITE
From: sip:user@example.com;tag=11141343
To: sip:user@example.edu;tag=2229
Content-Length: 154
Content-Type: application/sdp
Contact: <sip:user@host28.example.com>
v=0 o=mhandley 29739 7272939 IN IP4 192.0.2.198 s=- c=IN IP4 192.0.2.198 t=0 0 m=audio 49217 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC
V = 0 O = Mhandley 29739 7272939 IN IP4 192.0.2.198 S = -C = IN IP4 192.0.2.198 T = 0 0 M = Audio 49217 RTP/AVP 0
This is a legal SIP request with the Max-Forwards header field value set to zero.
これは、Max-Forwardsヘッダーフィールド値がゼロに設定された法的SIPリクエストです。
A proxy should not forward the request and should respond 483 (Too Many Hops). An endpoint should process the request as if the Max-Forwards field value were still positive.
プロキシはリクエストを転送してはならず、483（あまりにも多くのホップ）に応答する必要があります。エンドポイントは、まるでMax-Forwardsのフィールド値が依然としてプラスであるかのようにリクエストを処理する必要があります。
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
This register request contains a contact where the 'unknownparam' parameter must be interpreted as a contact-param and not a url-param.
このレジスタリクエストには、「不明なパラム」パラメーターをURL-Paramではなく接触パラムとして解釈する必要がある連絡先が含まれています。
This REGISTER should succeed. The response must not include "unknownparam" as a url-parameter for this binding. Likewise, "unknownparam" must not appear as a url-parameter in any binding during subsequent fetches.
このレジスタは成功するはずです。応答には、このバインディングのURLパラメーターとして「不明なパラム」を含めてはなりません。同様に、「不明なパラム」は、後続のフェッチ中にバインディングでURLパラメーターとして表示されてはなりません。
Behavior is the same, of course, for any known contact-param parameter names.
もちろん、動作は、既知のコンタクトパラムパラメーター名でも同じです。
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
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パラメーターとして「不明）を含める必要があります。
Behavior is the same, of course, for any known url-parameter names.
もちろん、動作は、既知のurl-parameter名でも同じです。
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
This register request contains a contact where the URI has an escaped header.
このレジスタリクエストには、URIにヘッダーが漏れた連絡先が含まれています。
The register should succeed, and a subsequent retrieval of the registration must include the escaped Route header in the contact URI for this binding.
登録は成功する必要があり、その後の登録の取得には、このバインディングのために連絡先URIに逃げられたルートヘッダーを含める必要があります。
Message Details : regescrt
メッセージの詳細：regescrt
REGISTER sip:example.com SIP/2.0
To: sip:user@example.com
From: sip:user@example.com;tag=8
Max-Forwards: 70
Call-ID: regescrt.k345asrl3fdbv@192.0.2.1
CSeq: 14398234 REGISTER
Via: SIP/2.0/UDP host5.example.com;branch=z9hG4bKkdjuw
M: <sip:user@example.com?Route=%3Csip:sip.example.com%3E>
L:0
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ボディが含まれていない場合があります。このリクエストの受信者は、許容できない406で応答でき、警告/399は、Acceptヘッダーフィールドで提供される形式で応答を策定できないことを示しています。また、Application/SDPをサポートするために招待をサポートするすべてのSIPユーザーエージェント（UAS）が必要なため、400の悪いリクエストで応答することも適切です。
Message Details : sdp01
メッセージの詳細：SDP01
INVITE sip:user@example.com SIP/2.0
To: sip:j_user@example.com
Contact: <sip:caller@host15.example.net>
From: sip:caller@example.net;tag=234
Max-Forwards: 5
Call-ID: sdp01.ndaksdj9342dasdd
Accept: text/nobodyKnowsThis
CSeq: 8 INVITE
Via: SIP/2.0/UDP 192.0.2.15;branch=z9hG4bKkdjuw
Content-Length: 150
Content-Type: application/sdp
v=0 o=mhandley 29739 7272939 IN IP4 192.0.2.5 s=- c=IN IP4 192.0.2.5 t=0 0 m=audio 49217 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC
V = 0 O = Mhandley 29739 7272939 In IP4 192.0.2.5 S = -C = IN IP4 192.0.2.5 T = 0 0 M = Audio 49217 RTP/AVP 0 12 M = Video 3227 RTP/AVP 31 A = RTPMAP：31 LPC
This is a legal message per RFC 2543 (and several bis versions) that should be accepted by RFC 3261 elements that want to maintain backwards compatibility.
これは、RFC 2543（およびいくつかのBISバージョン）ごとの法的メッセージであり、後方互換性を維持したいRFC 3261要素に受け入れられる必要があります。
o There is no branch parameter at all on the Via header field value.
o Via Headerフィールド値には、ブランチパラメーターはまったくありません。
o There is no From tag.
o タグからはありません。
o There is no explicit Content-Length. (The body is assumed to be all octets in the datagram after the null-line.)
o 明示的なコンテンツレングスはありません。（ボディは、null-lineの後にデータグラムのすべてのオクテットであると想定されています。）
o There is no Max-Forwards header field.
o Max-Forwardsヘッダーフィールドはありません。
Message Details : inv2543
メッセージの詳細：INV2543
INVITE sip:UserB@example.com SIP/2.0
Via: SIP/2.0/UDP iftgw.example.com
From: <sip:+13035551111@ift.client.example.net;user=phone>
Record-Route: <sip:UserB@example.com;maddr=ss1.example.com>
To: sip:+16505552222@ss1.example.net;user=phone
Call-ID: inv2543.1717@ift.client.example.com
CSeq: 56 INVITE
Content-Type: application/sdp
v=0 o=mhandley 29739 7272939 IN IP4 192.0.2.5 s=- c=IN IP4 192.0.2.5 t=0 0 m=audio 49217 RTP/AVP 0
V = 0 O = Mhandley 29739 7272939 IN IP4 192.0.2.5 S = -C = IN IP4 192.0.2.5 T = 0 0 M =オーディオ49217 RTP/AVP 0
This document presents NON-NORMATIVE examples of SIP session establishment. The security considerations in [RFC3261] apply.
このドキュメントでは、SIPセッションの確立の非規範的な例を示しています。[RFC3261]のセキュリティ上の考慮事項が適用されます。
Parsers must carefully consider edge conditions and malicious input as part of their design. Attacks on many Internet systems use crafted input to cause implementations to behave in undesirable ways. Many of the messages in this document are designed to stress a parser implementation at points traditionally used for such attacks. However, this document does not attempt to be comprehensive. It should be considered a seed to stimulate thinking and planning, not simply a set of tests to be passed.
パーサーは、デザインの一部としてエッジ条件と悪意のある入力を慎重に考慮する必要があります。多くのインターネットシステムでの攻撃では、作成された入力を使用して、実装が望ましくない方法で動作します。このドキュメントのメッセージの多くは、そのような攻撃に従来使用されているポイントでパーサーの実装を強調するように設計されています。ただし、このドキュメントは包括的ではありません。単に合格する一連のテストではなく、思考と計画を刺激するための種と見なされるべきです。
The final detailed review of this document was performed by Diego Besprosvan, Vijay Gurbani, Shashi Kumar, Derek MacDonald, Gautham Narasimhan, Nils Ohlmeier, Bob Penfield, Reinaldo Penno, Marc Petit-Huguenin, Richard Sugarman, and Venkatesh Venkataramanan.
この文書の最終的な詳細なレビューは、ディエゴ・ベスプロスヴァン、ヴィジェイ・グルバニ、シャシ・クマール、デレク・マクドナルド、ゴーサム・ナラシムハン、ニルズ・オルマイヤー、ボブ・ペンフィールド、レイナルド・ペノ、マーク・ペチ・フーゲニン、リチャード・シュガーマン、ベネ・ベネカタラマンによって実施されました。
Earlier versions of this document were reviewed by Aseem Agarwal, Rafi Assadi, Gonzalo Camarillo, Ben Campbell, Cullen Jennings, Vijay Gurbani, Sunitha Kumar, Rohan Mahy, Jon Peterson, Marc Petit-Huguenin, Vidhi Rastogi, Adam Roach, Bodgey Yin Shaohua, and Tom Taylor.
この文書の以前のバージョンは、Aseem Agarwal、Rafi Assadi、Gonzalo Camarillo、Ben Campbell、Cullen Jennings、Vijay Gurbani、Sunitha Kumar、Rohan Mahyによってレビューされました。そしてトム・テイラー。
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.
このドキュメントのマルチパート/MIMEセクションへの貢献と、[SIP-SEC]のS/MIMEの例を構築してくれたCullen JenningsとEric Rescorlaに感謝します。いくつかのメッセージを提供してくれたNeil Deasonに感謝し、以前のバージョンでメッセージのパーサー検証を実行してくれたKundan Singhに感謝します。
The following individuals provided significant comments during the early phases of the development of this document: Jean-Francois Mule, Hemant Agrawal, Henry Sinnreich, David Devanatham, Joe Pizzimenti, Matt Cannon, John Hearty, the whole MCI IPOP Design team, Scott Orton, Greg Osterhout, Pat Sollee, Doug Weisenberg, Danny Mistry, Steve McKinnon, and Denise Ingram, Denise Caballero, Tom Redman, Ilya Slain, Pat Sollee, John Truetken, and others from MCI, 3Com, Cisco, Lucent, and Nortel.
次の個人は、この文書の開発の初期段階で重要なコメントを提供しました：Jean-Francois Mule、Hemant Agrawal、Henry Sinnreich、David Devanatham、Joe Pizzimenti、Matt Cannon、John Hearty、The McI Ipop Design Team、Scott Orton、グレッグ・オスターハウト、パット・ソリー、ダグ・ワイゼンバーグ、ダニー・ミストリー、スティーブ・マッキノン、デニス・イングラム、デニス・カバレロ、トム・レッドマン、イリヤ・スレイン、パット・ソリー、ジョン・トゥルーケン、その他MCI、3com、Cisco、Lucent、Nortelのその他。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822] Resnick、P。、「インターネットメッセージ形式」、RFC 2822、2001年4月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：ジェネリック構文」、STD 66、RFC 3986、2005年1月。
[SIP-SEC] Jennings, C. and K. Ono, "Example call flows using SIP security mechanisms", Work in Progress, July 2005.
[SIP-SEC] Jennings、C。and K. Ono、「SIPセキュリティメカニズムを使用したコールフローの例」、2005年7月の作業。
The following text block is an encoded, gzip-compressed TAR archive of files that represent each of the example messages discussed in Section 3.
次のテキストブロックは、セクション3で説明した各例メッセージを表すファイルのエンコードされたGZIP圧縮タールアーカイブです。
To recover the compressed archive file intact, the text of this document may be passed as input to the following Perl script (the output should be redirected to a file or piped to "tar -xzvf -").
圧縮されたアーカイブファイルを無傷の回復するには、このドキュメントのテキストを次のPerlスクリプトに入力すると渡される場合があります（出力はファイルにリダイレクトするか、「tar -xzvf」に配管する必要があります）。
#!/usr/bin/perl
use strict;
my $bdata = "";
use MIME::Base64;
while(<>) {
if (/-- BEGIN MESSAGE ARCHIVE --/ .. /-- END MESSAGE ARCHIVE --/) {
if ( m/^\s*[^\s]+\s*$/) {
$bdata = $bdata . $_;
}
}
}
print decode_base64($bdata);
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デコードユーティリティへの入力として供給することができます。
-- BEGIN MESSAGE ARCHIVE --
H4sIAEDwcEMCA+xdW2zc2Hm2nexNG6UN3LRF0QfaiKJdyxwdnkMOhyOPVrIt
27It22tdvHYTeM8MDzWc4ZAjkqORvK2bbIAAedmHtEHRdlvkoUCLFAjSlyLF
9rJPLYoWrTdAg6JFHwp0i+5D0SIoEAQFuj2HnAuH5GgoW3PxmgcazYU/b4f/
//3Xc04Rq9ipk1JGxe6xITVAW1YUvXc5K/W8syYheEygP0lIECWJ0gkSkMAx
DhwbQWs4LrY57phdcerYrjr96AZtb91L5/0paTdvbazevLHOOXo933CIvUT2
cK1ukIxlb3Prq7fmYQZMT23pON/+Nr958RZXthxXzLRpS1YtL4EsWCja2CyV
Cw+U8mWxeK2qVhoigkicnlrDe/wly25iW3XynEwPecmmO3GnzxPDOMstG/RQ
pkrs09w5diU4s50p0i1LgTMsLrh4uyAiJEI0PbVh0Z3vYNexzLPcRtmqYYfu
692Gm2l6v/fcyuL01AVsGPzqxTxXbPO8o2qAXp4JTdUBGChKA6IyKptmEwCl
pFZNQs+0XCqRupvncL1u6CXs6pY576h1erx1spPnkALpLSpcqyOnp4w8R29v
eurpeP60L/yHNkQAGCT/IsiG5R8KMJX/sco/lbiu/DNpi6NoizHbVqLi1Ysf
nsAiBEUYBgAUAymCQj9lYEYIochBEhiQ6BYXO1i1TM2CSBchqOwC7AAKKxqq
ILMtsbmnVVaHJP9U8Mkw1f8g+RcAFI+xf6IIBJRFVP7FbDbV/yNpqze2VjdW
jl78TeJ64g+pflWYwo5aAEHp9XiQqlGq22smlWEqsBAZFRHyvENUzax5VoQv
vwJVuQoSOf/S+xgnQdskxixpTk9dpKfMc5ds/SwHBO4qNjlIWZETsnkA6B+3
sr5Bz2iZLi5R7DkXuEd2fCkTuNNFn5CYLr+xXydxSNXafJ2Y226Z3oPk4c5u
gb5ZhVqZGj8G2eegIlNTQoYyvUGF3iC3ekvsAKM0PeUU+OmpUiG6wS0AhmS1
Am6ousXRLhdk7vbGrfnlrVscvSnItu3qKrE4BGF3ExKmp3DBdus1XM8jgbt+
68KzjIbPJv6bQ0X/BP6fgEL2n4gkKcX/Udt/sY5Trw/IWhBqS0l8wGYY/b3W
dQJpC7mBg71AXyl5rdcL9HeNu5WQC0jZnvKbIC313MNAf4+2Pi7f0yr/urkL
hHHGf2QEwvafDFAq/xNn/1Uyj2EBCkgUstSiF6CYjZiBvSLpcyIoY6A7poqr
jlrBDrUFWYwGO13/ra/l1/EhpYWFswtnzwYMuNNXLdKKLlUs0oMLC7TFmWhw
oFl3SAtO6GvCCeOy4Wiv7xLbGaf/B0QxqP8lT/5RNpX/idH/ckT/y3H6P6nq
79H8yxlP+Q/S+DtNYuk7dRLQ+xuZlupPrPI9TmdKXw4r/Y5uF56x4FCxhKmz
PFb7n4p+JP6Dsqn8j6S1tCcHAeBuXjtIpSq5kHwLCPqhncg+UJIygVd4PwcX
ic127Mqmx4UA5cScCCAQqMKnyl/DVVSBxG4SVXOW11Wtk3OROiZA1/wImya+
8SFQaUdtdyFCRtRGK0oFlTgLQEwU2OkGiLyDs/AQzAXxZfHwloKS62sqsE1p
vCdtR4P/ZM8drveXIP4jS2H7T4RCiv+Tl/+r3H+cFIAIiWuHDcFsEP59Juxx
/KanbpOdhm5T0DUtt6yb2+uNet2yXWejrDtn435c0d0yoSe6ZVt7+3xgd/aD
TpwWbXt/+6K1bO5Ht8XkCXs03Mb1dU6zDJWnQM5T7vEUySArOKxbJsWyLOrb
JUsda/4PSIIY8f/S+M9o7T8RKqKSlREQqDS6LrGZgHFFm+AqR6WKs0mJ6LtM
uvpbiCBs6UGk5Kg4WyQo6y2Gw45qaahRgQDRj6aG6BU06Keyhh1Eyl7gBzuK
3rX5kKiIIbvvXBxs+Q4jUrDpaHrL8jsXZ/r5hAqAFVM1q6zWJ0ZK+xh49GYj
Ft7TqP9LFLHtMed/5CwM+3/UaE/lf2Liv72aO/ekEWGF5fnpPwv2S7A3zG17
P5xhbyOIz7I9xkKT6JiihVpFCYLEven7qMbmWX5H5CGSIDp0Yl+h7THiwgcE
hocbGS5Rpsa18eZ/JCBE9b+cyv8o2u2Vy6vrGyu3PXmNFf6I/DjYbdjmYyV+
u5FfdrpQvLYds7lY1ba2K1XbXWtiYl+71g76xu8SBIY2L1PuEcBS9Drb4AC5
9m0HAIgdfk5QZEhZENK2tN0UghC00DCrptU0vZN8YqLDrT6D45R/MStH5B+m
+v9Zlf8cylEleTiZhwNlHsXJ/LlDCf3iJzAnpBYNm+yMNf4nICkbtv+ltP5r
UuQ/makf3doq1IKSUEEVBCODgHLTU6t5rsV/Pda8ojDfXzMNZFQhQqIAQ2q6
dbJwnW/X9u+Kev9oBZTiEMsrV+4TrqMX3PWWgkUkPf3Vvsbe7UkKZajTi+K6
qQN24c5SZJnKleJJ01KwlOQwhTIxnYBywK+3Hn5R85OXxHCJPZ800xVtxCkN
O/0zOP+P5DD+wzT+M/L4D305M2iZQeuMCALYFUSqqF6YkSWHzMgwDu08+2p1
BlLE2iX0jXZhiTjB47VisCgXwT15ekrPcz5/spEhQPFCwtVK1YTIMukXwKPA
sBDIBoaKScM+DHTjEzUHJPmnp7hOnGomeyFuKMgC/Z12xoI5kxVqpLBL34wG
vXVpBokzSFg8ItTsC5ppaUDaDov/cMzx/2zU/6eSnOL/aOz/GVGmtvKMKPk+
gE22dce1sZ3p6w2cnrlHyVvF1DZxrIZd6jF2FzvD+wdSevCvQQQrWNUqPUVh
Pmsy0Dd3mhYS7R2IdCRWbJYbLJkGRKZtVE2H1YX1JugvDBwDCIEyoz1wTGIE
NYiCRJEL9kjssMWe4AE2dOwIfkowlBC8MJO9FCGFfnlYmDR6TOQRohDhkccf
aCebDcMYb/5fjMb/sun4/wnz/xmb8DMA8OxDP9e2L1Ersqco0J+/44DhwG2W
RAoEyFS13WpFxY5W3UFN0XLtHYBVR6OggHfVzpBgESk5Zv0d4PgPSvsFCnW6
okhvZSmy42IMVT/C6/nJjhfSzrYbtj7e8f9iJP4nS6n+H7X/Fw7gvXbbarik
MIMuhLBhBq0cydwASBQkIRc3JqzfqHsPP/rVBbRZ2XMWeWY3lCs8rhBUtHmK
DTtAyTV5DTeJXYY7fFk0pS58UKihyh8e7D3ylsa7ZcKXqRmTvOJvmMGz1A1M
25M13XQa2pj9PzEbGf8rpvnfseN/F+NbKOnVbQ3OKSgxOYWMx2cDQdFoDbs9
JA4qfZMISjo3yiD5d2vELY/V/oM99V9Z3/5L/b+RtFOUAYhNHFc3t/k1ygmW
6g2/k7JyTrl/Zu7NzIxuqoSosw89kBDuN8yG08BGZvP26sNXXIsvklNOwyav
flF3zFl3Tne/MF+y8YP9187OLyycyX9Rd+fK2CkIZ5tEt9VTZ+rY+ULTeqje
dy0r84pqEbYbr7uvLg0uP2lHdoSDyjczp2ay2TP3596cfdiKV51fuZ7/0gvc
jU36doy7yL79aisoddj7iQ1zuVaVmMLDN/0PcHbuvv8JnZk5leH9E9UaporN
UPBLo7vfYqUls7MP587cp8QzhdMffOXR9x790aM//+DtR9/74J0PvvHo+4/+
5LRnMN/3jvpQmJ17kx6ZzwSM37YcNy1bnbl3jT+VoT0wu8S+vvnw1VcWz+W/
NH/6y7/02q+8FZhGS4AQ5STuEDwQNtYhK08lexTTHQriVwhWiU3PPXNm7j7t
/vx/vfcXH/7e73/41Xc/+u33JncMzLNt/+1CSURjjf9lvfF/IfsvHf83avtv
k9p/55eS1QDqmrvdzPTL+M4JCCBJkgTalihppmToVPB7C+vo2Qr1smWSRTbU
r0SBivcCDq1jRK5moYZV1S44TjjO3o5AzAlZCbTr+IJkvafrAU2f+QVZkOOu
M1BTJGU7hu/Rzgnz+LP6HQl20i5ouOPO/wE5bP+J6fyfk+T/JZ0F84mGBeW8
gL94YG7AZ9feGaJUR9MrbBZvpHZrQSRRPKD8zbFqJNksof2FvVUZrFl2DbtR
40b0rJtznuTSnuHO1Uu1BsfGGBdOiyI6PU9/PDff3jy2529Y5vawC4AHyH82
K6NI/D/N/02Q/HtO1CrHirg4zDE6zsQ1wlkaR21/m9TIE75xddtiokHl6nTs
mN58lvZpTzG+UNgl9j5j36N87WKjQRbYJ+8k7C6H/So4ZXrn/omHcUtxL8/n
JNTpu0Hf7uhu+Ya1xS6AebQ+RuMafkDdQcO7HB+w2cUO8+doQTRUcpP4J0Kx
zYplz+MdCq8U/FMEzuDxyNH8a1+/99QN4jidWzjyDwHt3VY21Aq3Cf1xf/T/
2yynd2wFlGOVA6BjLGz6PcNfp5RH+eKZrOW5VsfzRy3SvP9ch3f8ehszeA/7
C6M4k3dPMTFAilAI9bppu1EK2EuxFaUQQhRx5wFhmuUIDVRCNKvR4/TOCMZo
Yo4jh+4p5npgNkwTcxwpRBN3PWKYJuY4oT7e4vJchCbUy7txNOF+5rjouUD4
OFEaQYk8rxiiXJQohkoe/OiFbAIaKQGNmIAGJaCBCWgSsLQABtMog0lyg0kS
dHKCPk7QxQl6OEEHJ+nfASQRr7I1cY5a6MR12o7mqIy9Ubz8W2rB9cCa2THY
lo+xZofxLBTlGO62O+wCwIHz/0Tmf5WEtP5vpP5//ERaR1Plp0BFiOQNg4X+
HR4UlgLB71aWcnC9iTTMZXqUIw7oI0FUEMzJYEKAwGg6qu7Ux5r/QzKL/7OB
3jKbDNqP/6X1XyNpR7P+ny9x52JQoDsf34Cq/zYjssIDXCypSxr1L/fjUnFZ
0GdiTgYKkb3iw/rpwn9d+R9//T8K5/8lANL5P8Yd/1/gDHswBPjCvacRXqFK
LJdD/ANFSzIrMPJnZo/k+6ReUPC4058MVLWIpbOll7zi/qZt+p9ySLSr3qCi
VvJPQNSkzIooQa2q0HfqIoiUgwwLYfSGxcGOxaQZFml7WvCfAaA7Vv9PhhH/
T07rP0aJ//H2X98ZYJ/IIczlBLEX41scqFXNHWr9UYwXEVAUrLKh37hJ0FKM
FSjkFJTLDZjvQxhkCSKlPcfrcFB+4sNHtZIx7vl/gCRnw/Vf6fwPE+X/HXoy
HTaVAkTJYMJiqzbEhY3YcKMAUPisqpVNZgJatl7GTU21MLJEW4IW0m2nu0IQ
ta+o+ddxEyOCGfFFsyBKJYUF3iV77nzdwLrJxHqDXjaZdTjT4pp4n3MtjuVD
adc0uRo29zmr5BLX4bBNOIetLuEQlREVCcd2zEyG+1nTnRp2S+VhgsDA+I8k
huRfgmn95yTGfx6rrhOJEpQOWv4lyIMVNvOgs6dqRtKp3NNgz5HIPxyf/Mve
+L8e+59+SeV/FO3Gyp21lY0rNy9OBgLAAQjQ11IPGeoHI0X/yf8GZ4TZTIWH
N+njrPmJiNHUKFMPewG4AfIPRYH5/wjK9Mkj4M3/JKX6fzRtbWV9ffmyHwCu
Nmp61Yqs/hvvAQhQpowMvAiqHI6g8mpOlkTEiypWCciqoKgWBYEQXuDbmxZs
VvAdlxIKjgILniUHqGCvqlQ+dXc/z9lSrWmT6439i7fvntfnwYZ+q7ni3EX2
ypZTnb8M7+yVtze2hFuX5PKVxvXVa+Duna1r98rXdpW1Sm6TvLFTXdsqmls7
SL5wcS4noO3du5XS+U18z9x+vfZGSblz4976xRuXLzxYntPuGMrayuaVO6v3
LOECuUqK6t35N4zta2QDg5vG7g6wXRm8LlX0da24s3a19vollxB9d7NcXbtz
d3O5EAYuzWho2v5Sbx8uBpaqij6KxZ4Rdq0DRLJsUCsCtVRSAtiKVEXMSVgF
JVHJSUpx6V5tT7hXuyddvyOU7+6DvRu65BThjXJxOZPppt1bjBHARJstqEVs
fsUsWapubrO1vExs74dhs9YwXJ3BynxN3yPqQtFiQ5/t/YKMlVKRlAAsEaJl
2cjhi5g96XXsnqUeG3ez5LJ1aCUOiHlRzEtZ7vLaxvQUGwnIL2/TE3gcqNfq
rD/mvZQ690qpYTvEeTXGe5MQQ2qej562v1eX4Ganp64Qw7CSHDmoQDxvkHdc
m7DVQxKdB7x9/PbzL535+pWv/3j6+Asnvv328Qv0p9dOHD8uvAReeP65uc9+
6sQvgJe7JMeFt49zlOQXKQn4ZVAXXgYvPf+pzU8/f/LE5rpwEnyOfXnxJOMN
XbNsU8fC58BPsR9fOPniOja5q9RJFT4LPsN+mjr5HOU03RVeBbPs+8snuXX2
ndsgjstdILara+zmCLfccMvUH3f3T7x4/FvHdk6g4ye7lzfdubzjx5879umv
fuWd/9F+cuW/b/M/+PA33vmdb33nox/93+e/rd3dKX7zP/7pzB/8ozRV/ruP
v3vuz+Y+/tnGv/yD+s7dwg8vv/KjIvfjj5bd30XTv/X5//zDf/61Dz5z/qcz
b9nf+MG77//1dzP/+1fv//1Pfm5+4cTDm+/P/utG7d/++Dv59xa1v/2bL//w
L6997Ws/8+73//3jn+d//eaHb5E//c1Hz8U9OJ5/Vr0DT1jHq/8FCILjv0Rf
/6frP40l/0s1SR2b+wnHf0JpkN3dtnfjV1uIrQjxx1t3Tf6Ok9BiVSXHlolc
CljSrV2UxPvAA5yWTk6bpafZIgT9Y5jtLZEIZpL8tzcTJptnI1khqnjQtHjZ
0GOIZNQP6bHAvkVs8KgnVErDMmNtZskYcvYnQfynZ/5PD/9BWv83HvxPsP4n
ZFj0ZPEgL7WDgllgxoc9w/qh4KWQbEmETdQpBwYJyoFRkol9e69MQk+W6OUf
Z9VP5p/0qRRGIxsqYFrUIXEsc6zr/0EYyP/IXv0HSuV/JK29/jftf+6J1/bu
MBOmUsxW9tbZ7PyKAiGbx7u7kne6ivfk6H9rlxhOaaz1/yKUQvKf1v+PPP9r
4XqmSEg9Pz/fFXqURwDAoxkGlItU+qIe6PD50K/0pYcHOxRhzKZf+Fs1uqt0
IH8JgT5jANpjMJUklV9iOifhTsNyi3i863/IohS2/+V0/c8Jsv+9+X/W7Ax3
NcOxaLyvRaOm/2ICHFBQzCKXQnAkUJslPTfgoLF9SthoT7rqpaTkJSCBBLCQ
uNATjmHly6PIEdtkGzeGnABONv97r/4X0/k/R9KGvP5vTkZQKFcgEmDuoJVt
O2zYEwNoizTFjL5r+jKF3w1O9vH9WxmqB54I57kb1k2TXDOtprNR1p31UplN
QWbV8U6D8FQOcIEVaEak/BNpGtCOL2K15I5X/lHY/wdp/mfS5P8g6Y+VfUXJ
IQQPHPTb4b4qEiXs2AbS1OLukgD8sohuNcJBC3ojKSPkKDViL9R3QF9oDfGD
Vzuir0zvikef0DJS+gTYuknjlX8pG43/pfWfT7v85waJvs94IdEPZ3X/v72j
2W3bBt8L9B2IALsEcUqRki05c9Fi2LB2a7I169JDgUKxKFv+oRxSspqctp4H
7F2G9bjtFZI3Gj9RdiXZlpN2tZNVbFLHlCjJ9Pf/+x+29nu2wtS4DvXvQBu/
Dx5SKVSu+LQtgNfq/9RckP9Jjf+3BP+XN2AhVQY2ahLp+eFqs33eVlBh/Seg
jZNBfx4ITpu2Q01IIFUKogMxw5TkCMOcuMyhmtAQTzxn6vLRGU24GHGWhP7A
lU4cLMomFKvP+/WbSSBYapTYwFjtmijuMJQQRwdMP1uH2Jg4LctpNimxDesj
zJh6p0a9beJ/U+d/ENLEoCim8n9t/9us/8/CFB0zMQ26DL3g7tQNRu7piH0Q
+l9cvPEC6Ngtk8Xyh2rptanCQlxVRhaYK72BzwbJ3EBA0mxRm5qtFqHYhEQC
I5//WSQMCtx56EqGQx+STfqcnIV+6MIb4rLEh2sJ6EoSifPGYz9iQt3CdCgm
NrXVTsErvIX7OLaSc05cwdPgXcNWtw2nTESxYGjnCUc/iLCnUFbu3E5fg/Qm
W8//blkL8T+E1vr/7bL/p0a+14tKwOraCeXY0GuUBKosBqRBNTMNQnCQp8iA
d//e426XTaIsjp+Hp6F3Prft3cApYFjVOWGFog63pQfQRzsCJBsHW67/ha1W
Tv5vZvX/mjX+b2KU878P1IfsxF+YOIecNycKK1E9FD0dDUCJSariAWZwudQf
YL/n7DPkL6HgXmFiMuzKVmMcjNkeiNF6lNKU9nITMuhxNZM7VzFwt8fUAXXl
3BtfuL0qknL789EjJj91+6/19r98/ReN/6RV+/82zf+VZMwfKdU4HAdZesMR
UohVntW4LdzRpF9E+mfuy4Z/JE7c596xgnDczDv4UjgrIHPe1Pfy/OLivEHU
aYpnI/WjBH/E4/EpE2olRzpCQJ9F23Nenk4UFHX1FMzVorgfhuhUfbXqa4On
DkN4I9KXJUzdvi5Pj3Sf1E6auHH37X8RJCBCJq7cYv2HZquE/5ZV2/+3w/8/
rP7vR1X+RTkYHAaDvukOPe6eDYYJ4550pQ+MfwWfv1ZN4PVl4EqLjr/6Sa0i
VatGrhx4fb9sH/n+GEW0Yh1xbBxzDz5R8TEPvzs8OjlEkVmxWKk72KeMLzHK
VLo/sOsEns8ZWyJ6RCKR2+b/Fi7jv0lxjf8bx3/BxmHEGmo/esuFfoQq+7Gv
gHhQ1bGT9wWsvFHR/DcKFUlpCCbDWHTZMsLimMTBdr7aQQrPYdCNqelYNoQQ
Mx8iiPsCGpqLtYSEUNvJBxcv72Xy/4kYjvlQdseflgKslf9NWsb/Zo3/m8X/
kt1Mx8S1ozCCpnk6NK6rAX8T2QAZVPI6G2AT+D8mW8Z/Ssr4b5Fa/78l/n/A
8kCe8raSXWnLIXaLzrl0P4ogYShJkv1lYr9CzDJWp7CWqv/980mfcTdiXqNc
xvE9MzYdnHfwL3Lj1QUnjOtEAn4JzcHaT8M+f308DqL+w8+tWmTMt57/a2Cj
7P+zDFrXf9vImEn2BGPUQWR3l6JdZO3uEnT51+Xf6OrXq7fq5fLPy3eXf1z9
DnOlqau3V7+hBrr85+qX2bHLd1U2cccu4aRBiemQIqHIgBKaAQ2B6Q/pgDCR
MM+Xj48rUolXBiMahm43skJqYV6sXZAEwhMWXX7XSwlaFsbj2AsZxjdLE3Ls
lXlCcOj2tRSsxx0aiQz4dLvxH0bLMsrxH0oArOn/hv0/02DKhr1H3b4biIbH
RbegNGXdvtPe3Dnh8Ai1799bvxwdIIQUgQVnakcRMMOGf5Ty+/d8AZ1GUBvt
PEXPQ8n4KRM99OrVq52dzPuqs009AQcfLcREwn9w5Q6CIl8Dz17jidIQv8QJ
VaT66SOlsR5dmVaewdiBW+XiSLK20gg9UCen24GA1Wm38VwOnXE76mCZiZ8S
Nu2QJd+4vDdi3rfM9SDEDCHOEl/PoayXLgKtO+Cxmlk8mLWq1+tPlPj6gscy
dkc/w+E2OjjY21O/B2t5l664qm6W7rTUYYCy8PWPxAwCEnWfjm42P+sAz0Pd
qf1h2oZ9tiepwfABAh0chpwEwO4KUJF9fXqHADIQyoQCJxgObITABz/fYn1F
9SfIE+kGG017n1jWvuLucK3sQh21aBaJDBF6igO2d36MQ6VqIBmJgCvw2gHw
WglY6lJqtzWsd2ZhAGom/ZT6mSXYQzx9ygE6U8+O9ym9MXtfWQPI3Axrv2AK
/fwt6/8EL9r/av3/Dvn/qix9vb70TCNHgDOQG4Apb+TzMQnJyKTCirE29xVM
e5QYFZ69a/V4AitCULYd4Lr0Rz3qUY/PfPwLcaRGXQDwAAA=
-- END MESSAGE ARCHIVE --
Authors' Addresses
著者のアドレス
Robert J. Sparks (editor) Estacado Systems
ロバートJ.スパークス（編集者）エスタカドシステム
EMail: RjS@estacado.net
Alan Hawrylyshen Ditech Networks 200 - 1167 Kensington Cr. NW Calgary, Alberta T2N 1X7 Canada
Alan Hawrylyshen Ditech Networks 200-1167 Kensington CR。NWカルガリー、アルバータT2N 1x7カナダ
Phone : +1.403.806.3366
EMail : ahawrylyshen@ditechcom.com
Alan Johnston Avaya St. Louis, MO 63124
アラン・ジョンストン・アヴァヤ・セントルイス、ミズーリ州63124
EMail: alan@sipstation.com
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07052
ジョナサンローゼンバーグシスコシステム600ラニデックスプラザパルシッパニー、ニュージャージー07052
Phone: +1 973 952 5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
ヘニングシュルツリンコロンビア大学コンピュータサイエンス学科450コンピューターサイエンスビル、ニューヨーク、ニューヨーク10027米国
Phone: +1 212 939 7042
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。