セッション開始プロトコルの負荷テストメッセージ
- この文書の位置づけ
- この文書はインターネット社会にむけた参考情報として提供するものであり、いかなるインターネット標準としても定めるものではない。この文書の配布は無制限である。
- 著作権表示
- 著作権(C) インターネットソサエティ
- 概要
- この文書には、SIP実装の負荷試験のために考えられたセッション開始プロトコル（SIP）のテストメッセージの例が記載されている。
要旨[編集]
この文書は参考であり、SIPに関して規範的でない。
この文書には、RFC 3261で定められたセッション開始プロトコルの最新版（2.0）に基づいたテストメッセージを記載する。いくつかのメッセージでは、SIPがRFC 3264で定められたセッション記述プロトコル（SDP）を用いて実行する。
これらのメッセージは、SIPIT相互運用テストイベントで開発、改善された。
テストメッセージはさまざまな節で構成されている。いくつかのテストメッセージはSIPパーサのみに、その他のテストメッセージはパーサとアプリケーションの双方に負荷をかけるものである。メッセージは正当（valid）なものとそうでないものがある。何がメッセージを不当（invalid）なものとするのかを、各事例では明確に示している。
この文書は、不当なメッセージを作成するために完全な目録を作る努力をしないし、あまり用いられないが正当なメッセージを精査して包括的にすることに努めない。その代わり、不適切に扱ったときに特に好ましくない特性を持つ、あるいは相互運用上の問題となる分野に重点的に取り組むことを目指す。この文書はテスト計画の元にはなるが、テスト計画そのものではない。
メッセージは、あいまいさを避けるためにマークアップ規則の集まりを用いた文字列で表され、インターネット草案の配置要求事項を満たす。残りのあいまいさを解決するために、各メッセージの真に正確なデータが付録に収められている。
文書規約[編集]
この文書では多くのSIPメッセージ例を記載している。SIPは文字列に基づくプロトコルなので、RFCの形式的制約があるので、追加の決まりごとなしにこれらの例が曖昧さなしに表現できない。この文書では、曖昧さを取り除くためにこの節で定義するマーク付けを明示し、利用する。このマーク付けはXMLの開始・終了タグの制約を用いるが、いかなるXML文書型も定義しない。
付録では、すべてのメッセージのバイナリ形式と、それらをファイルからデコードするのに必要なアルゴリズムを記載している。
長大な行の表現[編集]
いくつかの例では72文字より長い行を折り返さずに記載している。その場合は<allOneLine/>タグに囲まれている。その折り返しのない単独の行は、（あらゆる改行（line feeds）文字や復帰（carriage returns）文字も破棄して）タグの間に現れたすべての行が直接連結されることで再構成される。行末には空白文字（whitespace）は存在しない。折り返し部分にある空白文字は、行頭に現れる。
次は、まったく同じ文字列を表す。すなわち、
Header-name: first value, reallylongsecondvalue, third value
<allOneLine>
Header-name: first value,
reallylongsecondvalue
, third value
</allOneLine>
<allOneLine>
Header-name: first value,
reallylong
second
value,
third value
</allOneLine>
SIPヘッダ行は折り返さない[NOT]ことに留意し、異なる文字列でも同等の意味を持つことに留意せよ。
表示されない文字の表現[編集]
いくつかの例では、バイナリデータのメッセージボディや、UTF-8でエンコードされたASCII範囲にない文字列を含んだヘッダフィールドがある。それらはこの文書で、<hex/>タグの間に、オクテット毎16進数値のペアとして表される。表示では、引用符で囲まれた文字列の内側と等しい。
次は、まったく同じ文字列を表す。すなわち、
Header-name: value one
Header-name: value<hex>206F6E</hex>e
次は、ユーロ記号を含むSubjectヘッダフィールドである。
Subject: <hex>E282AC</hex>
長い繰り返し文字列の表現[編集]
いくつかの例には、繰り返した文字列から作成された非常に大きなデータ値がある。それらはこの文書で<repeat count=整数値>値</repeat>として表記する。<hex>と同様に、この表記は引用符で囲まれた文字列の内側と等しい。
例えば、値"abcabcabc"は、<repeat count=3>abc</repeat>のように表記できる。表示名"1000000 bottles of beer"は、次のように表記できる。すなわち、
To: "1<repeat count=6><hex>30</hex></repeat> bottles of beer"
<sip:beer.example.com>
googleのような値（a value of one google）を持ったMax-Forwardsヘッダフィールドは、この文書では次のように表記できる。すなわち、
Max-Forwards: 1<repeat count=100>0</repeat>
SIPテストメッセージ[編集]
パーサテスト（構文）[編集]
正当なメッセージ[編集]
短くのたうったINVITE[編集]
この短く、相対的に可読性のあるメッセージでは、以下のものを含む。すなわち、
- 全面的にに行の折り返しがある
- 引用符のなかにエスケープされた文字列がある
- 題名(subject）がない
- コロン、セミコロン、ヘッダフィールド値、そのほかの値の間にLWS（liner white space）がある
- コンマで分割されたヘッダフィールド値と別々に記載されたヘッダフィールド値が両方ある
- 同一のヘッダフィールド名について、通常のものと簡略名が混ざっている
- 不明なRequest-URI値
- 不明なヘッダフィールド
- 一般的な値の項目として定義されたのなら構文的に誤っている値を持った不明なヘッダフィールド
- 珍奇なヘッダフィールドの並び順
- 珍奇なヘッダフィールド名（大文字、小文字）
- 既知のヘッダフィールドの珍奇な値
- URI値が空
- ヘッダ値が空
- ゼロが先頭についた整数フィールド（Max-ForwardsとCSeq）
多くのエレメントは、これを整形された（well-formed）リクエストとして扱うべきである。
UnknownHeaderWithUnusualValueヘッダフィールドは特段の注意を受ける必要がある。このヘッダフィールドが（既存の定義済みヘッダフィールドの多くのように）セミコロンで分割された値を持ってコンマで分割された項目として定義されたなら、これは正当なものでない。しかし、受信した後にエレメントがこのフィールドのための構文定義を知らないなら、それはヘッダ値として構文解析されねばならない。プロキシはこのヘッダフィールドに変更を加えずに転送する。エンドポイントはそのヘッダフィールドを無視する。
Message Details : 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
広範囲な正規の文字[編集]
このメッセージでは、通常の実装で用いられない、いくつかの構文要素上の要点においてより広範囲な（a wider range）文字を用いる。具体的には以下のとおり。すなわち、
- メソッドはトークンにアルファベットでない文字列を含むが、%はこのフィールドのエスケープ文字ではないことに留意せよ。メソッドIN%56ITEは不明なメソッドであり、メソッドINVITEと同一でない。
- Request-URIが普通ではないが正しい文字を含む。
- branchパラメータがトークン全てに英数字でない文字を含む。
- Toヘッダフィールド値の引用符で囲われた文字列が、NULL文字を制御文字のペアで囲んだものを含む。
- Fromヘッダフィールド値内のname-addrのname部分が、（引用符で囲まれた文字列の代わりに）トークン生成規則に英数字でない文字を持った複数のトークンを含む。その値もまた、英数字でないトークン文字を含んだ名前とUTF-8でエンコードされたascii範囲にない文字の値の、不明なヘッダ値を持つ。この値のtag値は英数字でないトークン値を含む。
- Call-IDヘッダフィールド値が、単語に英数字でない文字を含む。以下の点に注目せよ。すなわち、
- %はエスケープ文字ではない。規則「escaped」に適合するもののみが、有効なエスケープ文字である。
- "は引用符で囲まれた文字の始まりでない。'、`あるいは"のいずれも、文字後尾のシンボル文字にあたらない。
- []{}()<>の各文字は、いかなるグループ化の意味を持たず、つりあったペアのうちに現れる必要はない。*英数字でないトークン文字を名前に含み、UTF-8NONASCII値を持った（拡張ヘッダに適合する）不明なヘッダフィールドが存在する。
この普通ではないURIがプロキシで定義されていた場合、プロキシはこのリクエストを通常通り通過させる。そうでなければ、プロキシは404を生成する。エンドポイントはAllowヘッダフィールドにこれらのメソッドが一覧されていれば501を生成する。
Message Details : 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
%エスケープメカニズムの正規利用[編集]
このINVITEでは何箇所かで% HEX HEXエスケープメカニズムを用いている。リクエストは構文的に正しい。後述する興味深い特徴がある。すなわち、
- request-URIには、ユーザ部分にsip:user@example.comと埋め込まれている。それがexample.netとどう関連するのかは、この文書の範疇にない。
- FromとToのURIは、ユーザ部分にエスケープされた文字がある。
- Contact URIには、URI値にエスケープされた文字があるが、URIパラメータ「name」値が持つ値「value%41」は「valueA」と同一でない[NOT]ことに留意せよ。[RFC 3986]では、URIコンポーネントのエスケープ解除は再帰的に機能しない。
パーサはこれを整形されたメッセージとして受理する。そのメッセージを用いるアプリケーションは、文字がエンコードされたものと同様に% HEX HEX展開を取り扱うべきである。アプリケーションは、（文法的に「エスケープされた」）% HEX HEXが構文上認められない箇所にあるところで、%をエスケープ文字として解釈しようとすべきでない。[RFC 3261]では、「エスケープされた」はSIP-URI、SIPS-URI、Reason-Phraseの展開時のみに起きる。
Message Details : 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
URI中のエスケープされたNull[編集]
このREGISTERリクエストには、ユーザ部分にNullを持つURIがある。メッセージは整形されているので、パーサはこのメッセージを受理しなければならない。実装において、このリクエスト中でAddress-of-Recode（AOR）のアンエスケープ時に、ユーザ名の短縮をしないように特段の対策を実施すべきである。このリクエストでは、二つの特別なContact URIを登録する。
Message Details : 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
%がエスケープでない時の%の利用[編集]
SIPメッセージの中でもっとも%が多く現れることが可能な箇所は、エスケープ文字ではない。これは不注意な実装者を驚かせる。後述する整形されたメッセージに、これらの属性がある。すなわち、
- リクエストメソッドが不明で、REGISTERと一致しない[NOT]。
- FromとToヘッダフィールドの表示名部分が、「%z%45」である。これは%ZEと同じでないことに留意せよ。
- このメッセージは、3つでなく2つのContactヘッダフィールド値を持つ。<sip:alias2@host2.example.com>はC%6Fntactヘッダフィールド値である。
パーサはこのメッセージが整形されているので受理するべきである。プロキシは、Request-URIがどうなるべきかの意図によって、メッセージを転送するか破棄するだろう。エンドポイントは、501レスポンスと共にこのメッセージを破棄するだろう。
Message Details : 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
表示名と<の間にLWSがないメッセージ[編集]
このOPTIONSリクエストでは、Fromヘッダフィールド値の中の表示名と<のトークン間にLWSが存在しないのでRFC 3261の文法に違反している。これは、RFC 3261を改定する際に削除される予定の仕様バグとして確認されている。エレメントは整形されたものとしてこのリクエストを受理すべきである。
Message Details : 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
ヘッダーフィールド中の長大な値[編集]
この整形されたリクエストには非常に長い値と多量の値を持ったヘッダフィールドがあり、次のような特徴がある。すなわち、
- Toヘッダフィールドには、長い表示名と長いURIパラメータ名と値がある。
- Fromヘッダフィールドには、長いヘッダ値名と値、特に長大なtagがある。
- Call-IDが長大なトークンである。
Message Details : 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
UDPデータグラム中の余計な付帯バイナリ[編集]
このメッセージは、単独データグラムのUDPの上に表向きは乗ったように見える、単独のSIP REGISTERリクエストである。そのパケットは、（この例では長さが0の）ボディの後に余計なバイナリがある。余分なバイナリによってSIP INVITEリクエストのように見えるが、（RFC 3261の18.3節にあるように）そういった偽のノイズは無視されねばならない。
このデータグラムを受信したSIPエレメントは、通常どおりREGISTERリクエストとして処理し、INVITEリクエストのような余分なデータは無視する。もしそのエレメントがREGISTERを転送するためにプロキシを選ぶならば、INVITEデータは転送されるリクエストに存在しない。
Message Details : 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
URIユーザ部分中のセミコロンで分割された値[編集]
このリクエストでは、Request-URIの「ユーザ」部分にセミコロンで分割された値（その値はエスケープされた@記号を含んでいる）を含んでいる。受信側エレメントは整形されたメッセージとしてこれを受理し、Request-URIはユーザ部分が「user;par=u@example.net」であるように解析するだろう。
Message Details : 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
多彩で不明なトランスポート型[編集]
このリクエストには、よく知られたトランスポート型とトランスポート拡張メカニズムに影響するViaヘッダフィールド値がある。パーサは整形されたものとしてこのメッセージを受理せねばならない。このメッセージを受信したエレメントは、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
マルチパートMIMEメッセージ[編集]
このMESSAGEリクエストには、二つのボディ部分がある。二番目の部分はバイナリエンコードされており、Null（0x00）文字も含んでいる。受信者は受信したメッセージを適切に構成することに配慮せねばならない。
パーサは、整形されたものとしてこのメッセージを受信せねばならない。同様にパーサ上層にあるアプリケーションはマルチパートの署名済みメッセージに対応してはならない。
マルチパートMIMEメッセージの追加例として、特にS/MIMEメッセージのような、SIP-SEC文書に例示されている呼情報のセキュリティで有効なものがある。
Message Details : 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
<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--
普通でないReason Phrase[編集]
この200レスポンスには、「OK」以外のReason Phraseがある。Reason Phraseは人間が利用するためのものであり、以下によって与えられる文字列である。
Reason-Phrase = *(reserved / unreserved / escaped
/ UTF8-NONASCII / UTF8-CONT / SP / HTAB)
この項目のレスポンスでは、非予約語かつASCII範囲にないUTF-8文字を含んでいる。このレスポンスは整形されている。パーサはこのメッセージを受理せねばならない。
Message Details : unreason
<allOneLine>
SIP/2.0 200 = 2**3 * 5**2 <hex>D0BDD0BE20D181D182
D0BE20D0B4D0B5D0B2D18FD0BDD0BED181D182D0BE20D0B4
D0B5D0B2D18FD182D18C202D20D0BFD180D0BED181D182D0
BED0B5</hex>
</allOneLine>
Via: SIP/2.0/UDP 192.0.2.198;branch=z9hG4bK1324923
Call-ID: unreason.1234ksdfak3j2erwedfsASdf
CSeq: 35 INVITE
From: sip:user@example.com;tag=11141343
To: sip:user@example.edu;tag=2229
Content-Length: 154
Content-Type: application/sdp
Contact: <sip:user@host198.example.com>
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
空のReason Phrase[編集]
この整形されたレスポンスはReason Phraseを含まない。パーサはこのメッセージを受理せねばならない。Reason Codeの後ろの空白文字は必須である。その空白文字が存在しない場合、このメッセージは不正なものとして破棄することができる（寛大な受信者であればどのみち受理してしまうだろうが）。
Message Details : 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>
不正なメッセージ[編集]
余分なヘッダフィールドの分割子[編集]
このリクエストのViaヘッダフィールドには、パラメータや値のない追加のセミコロンやコンマがあり、Contactヘッダフィールドには、パラメータを持たない追加のセミコロンがある。このメッセージは構文的に不正である。
このリクエストを受信するエレメントは、400 Bad Requestエラーをもってレスポンスすべきである。
Message Details : 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
メッセージより大きなContent Length[編集]
これは、ボディの実際の長さより大きなContent Lengthを持ったリクエストメッセージである。
このメッセージが表面上ではUDPで送られた時、受信側エレメントは400 Bad Requestエラーでレスポンスすべきである。もしこのメッセージが、TCPのようなストリームベースのトランスポートで到着した場合、そのストリームで更なるデータを待つこと以外に受信者ができることはないし、適当な時間なにも到着しなければコネクションを閉じることができる。
Message Details : 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
負のContent-Length[編集]
このリクエストは、Content-Lengthに負の値がある。
このメッセージを受け取るエレメントは、エラーでレスポンスすべきである。このリクエストがUDPで現れたのなら、データグラムの余りは単純に破棄することができる。このようなリクエストがTCPで到着するなら、構築エラーは回復不能であり、回線は閉じられるべきである。同様の振る舞いが、後述するような、Content-Lengthヘッダフィールドに整数値のないメッセージにも同様である。
Content-Length: five
実装者が選択する、このASCII領域を整数に変換する技術が負の値を返すならば、実装者はさらに用心すべきである。特に、その結果をカウンタや配列の添え字として用いてはならない。
Message Details : 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
大きすぎる値を持ったスカラーフィールドのリクエスト[編集]
このリクエストには、適正範囲を超えたスカラーヘッダーフィールド値がいくつかある。
- CSeqシーケンス番号が、232-1より大きい。
- Max-Forwards値が、255より大きい。
- Expires値が、232-1より大きい。
- Contactのexpiresパラメータ値が、232-1より大きい。
このリクエストを受信したエレメントは、CSeqエラーを原因にして400 Bad Requestレスポンスをすべきである。Max-Forwardsフィールドのエラーのみであれば、エレメントはフィールドが存在しないかのようにリクエストを処理するかを選択できる。expire関係の値のエラーのみであれば、エレメントは期間満了の既定値（ここでは3600）をもつものとして取り扱うことができる。
常軌を逸した値を持ちうるスカラーリクエストフィールドは、Contactのq値、Timestamp値、Viaのttlパラメータも挙げられる。
Message Details : 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
大きすぎる値を持ったスカラーフィールドのレスポンス[編集]
このレスポンスには、適正範囲を超えたスカラーヘッダフィールド値がいくつかある。
- CSeqシーケンス番号が、232-1より大きい。
- Retry-Afterフィールドが、不当に大きい（RFC 3261ではこのフィールドの適正範囲を定めていないことに留意せよ）。
- Warningフィールドが、3桁より大きなwarning-valueを持っている。
このレスポンスを受信したエレメントは、単純にそれを破棄する。
Message Details : 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
引用符で閉じられていない表示名[編集]
これは、Toフィールドの表示名が引用符で閉じられていないリクエストである。このリクエストを受信したエレメントは、400 Bad Requestエラーを返すべきである。
エレメントは引用符で閉じることを察しようと努め、メッセージを受理することができる。そのようなエレメントは、下記フィールドに直面したとき、妥当な推測をするよう留意する必要がある。
To: "Mr J. User <sip:j.user@example.com> <sip:realj@example.net>
Message Details : 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
<>で取り囲んだRequest-URI[編集]
このINVITEリクエストは、Request-URIが「<>」で囲われているために不正である。
400 Bad Requestエラーでリクエストを拒絶することが常に妥当である。そのようなリクエストを受理する寛容なエレメントは、角括弧を無視してもよい。そのエレメントがリクエストを転送するならば、転送するメッセージに角括弧を含んではならない。
Message Details : 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
（LWSが埋め込まれた）不整形なSIP Request-URI[編集]
このINVITEには、Request-URI中に不正なLWSがある。
このリクエストを受信したエレメントは、400 Bad Requestでレスポンスすべきである。
エレメントは、（SIPのような）決まりごとによって埋め込まれたLWSを無視しようとすれば、曖昧さを取り込まずにすむ。
Message Details : 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
複数の空白で分割されたRequest-Lineの要素[編集]
このINVITEは、開始行の要素間に不正な複数の空白がある。
不整形なものとしてこのリクエストを拒絶すると良い。このリクエストを受容するエレメントは、リクエストを処理するときに余計な空白文字を無視してよい。そのエレメントがリクエストを転送する場合、転送するメッセージ中に余計な空白文字を含んではならない。
Message Details : 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
Request-Line末尾の空白文字[編集]
このOPTIONSリクエストには、Request-LineのSIPバージョンフィールドとCRLF行末文字の間に空白文字がある。
不整形なものとしてこのリクエストを拒絶すると良い。このリクエストを受容するエレメントは、リクエストを処理するときに余計な空白文字を無視してよい。そのエレメントがリクエストを転送する場合、転送するメッセージ中に余計な空白文字を含んではならない。
Message Details : trws
OPTIONS sip:remote-target@example.com SIP/2.0<hex>2020</hex>
Via: SIP/2.0/TCP host1.example.com;branch=z9hG4bK299342093
To: <sip:remote-target@example.com>
From: <sip:local-resource@example.com>;tag=329429089
Call-ID: trws.oicu34958239neffasdhr2345r
Accept: application/sdp
CSeq: 238923 OPTIONS
Max-Forwards: 70
Content-Length: 0
SIP Request-URI中のエスケープされたヘッダ[編集]
このINVITEは、SIP Request-URIにエスケープされたヘッダがあるために不整形である。
400 Bad Requestでこのリクエストを拒絶すると良い。エレメントは、エスケープされたヘッダを無視し、リクエストを受容するかを選択できる。エレメントがプロキシの場合、エスケープされたヘッダは転送するリクエストのRequest-URIに存在してはならない（加えて、転送するリクエストの実ヘッダ中へ、絶対に変換してはならない）。
Message Details : 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
Dateヘッダフィールドの不正なタイムゾーン[編集]
このINVITEには、SIP DateヘッダフィールドにGMTでないタイムゾーンがあるので不正である。
不整形なものとしてこのリクエストを拒絶するのが良い（しかし、Dateヘッダフィールドの内容がその処理に実際に不可欠である場合を除いて、エレメントはそうすべきでない）。このリクエストを受容したいエレメントは、どうしてもDateヘッダフィールドを用いたかったら、この値全てを無視することができる。一方、この日付を解釈しGMTに調整することに努めることができる。
RFC 3261では明確に唯一受け入れられるタイムゾーン指定を「GMT」と定義している。[RFC 2822]でGMTと同義としている「UT」は不正である。「UTC」や「UCT」も同様に不正である。
Message Details : 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
<>で囲まれないname-addr[編集]
このREGISTERリクエストは不整形である。Contactヘッダフィールド中のSIP URIはエスケープされたヘッダであり、フィールドはname-addr形式（URIは必ず<>で囲まれる）でなければならない。
このリクエストを受信したエレメントは、400 Bad Requestを返すと良い。この例では少しの曖昧さもないので、寛容なエレメントは角括弧を推測してリクエストを受理することができる。一般的には難しいだろう。
Message Details : 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
空白を含むaddr-spec[編集]
Toヘッダフィールドのaddr-specに空白を含むので、このリクエストは不整形である。このリクエストを受信したパーサは、中止してはならず、400 Bad Requestでこのリクエストを拒絶すると良い。寛容なエレメントなら空白を無視すればよい。
Message Details : 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
トークン文字のない表示名[編集]
ToとFromヘッダフィールドの表示名が引用符で囲まれておらずトークン文字がないので、このOPTIONSリクエストは不整形である。
400 Bad Requestレスポンスのエラーで拒絶すると良い。
エレメントは、このリクエストを受信して存在しない引用符を推測しても良い。このエレメントがプロキシの場合、転送するリクエストの中で誤りを増やしてはならない。結果として、フィールドが署名で埋められていても、受容することが大して重要でないなら、メッセージは単に拒絶されるべきである。
Message Details : 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
不明なプロトコルバージョン[編集]
[RFC 3261]で実装されているエレメントにとって、このリクエストはより高いバージョン番号なので不整形となる。
エレメントは、505 Version Not Supportedエラーでリクエストにレスポンスすべきである。
Message Details : 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
開始行とCSeq行のメソッド不一致[編集]
このリクエストでは、開始行とCSeqヘッダフィールドのメソッドを表す値が不一致である。このリクエストを受信する全てのエレメントは、400 Bad Requestでレスポンスするだろう。
Message Details : 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
不明なメソッドとCSeqメソッドの不一致[編集]
このメッセージは開始行に不明なメソッドがあり、CSeqにあるメソッドと一致していない
このレスポンスを受信した全てのエレメントは501 Not Implementedでレスポンスすべきである。400 Bad Requestでも良いが、501は（特にプロキシにおいて）のほうが将来性がある。
Message Details : 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
大きすぎるレスポンスコード[編集]
このレスポンスには、699より大きいレスポンスコードがある。このレスポンスを受信したエレメントは単純に無視すべきである。
Message Details : 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>
トランザクションレイヤでのセマンティクス[編集]
今節には、パーサとトランザクションレイヤでの論理の実装について試すテストがある。
トランザクション識別子の喪失[編集]
このリクエストでは、branchパラメータに接頭辞z9hG4bKで始まるRFC 3261様式のトランザクション識別子への対応が示されているが、識別子が与えられていない。パーサは、このメッセージを受け取ったときに中止してはならない。このリクエストを受信したエレメントは、400レスポンス（できるならステートレスに、その送信元からの他のリクエストも同様に不整形なbranchパラメータを持っているとして）で拒絶する、あるいはRFC 2543様式のトランザクション識別子へ差し戻すことができる。
Message Details : 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
アプリケーションレイヤのセマンティクス[編集]
今節には、パーサとアプリケーションレイヤでの論理の実装について試すテストがある。
必須であるヘッダフィールドの喪失[編集]
このリクエストには、Call-ID、From、そしてToヘッダフィールドがない。
このメッセージを受信したエレメントは、情報不足を理由に中止してはならない。理想的には、400 Bad Requestエラーでレスポンスすべき。
Message Details : 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
不明なスキーマを持ったRequest-URI[編集]
このOPTIONSには、Request-URIに不明なURIスキームがある。パーサはこのリクエストを整形されたSIPリクエストとして受理せねばならない。
このリクエストを受信したエレメントは、416 Unsupported URI Schemeレスポンスで拒絶すべき。
初期の実装では、この種のリクエストをどうやって送るか判別するためにToヘッダフィールドの内容を探そうとするが、それは誤りである。ToヘッダフィールドとRequest-URIはファーストホップメッセージとして単純によく似ているが、Toヘッダフィールドにはルーティング情報はない。
Message Details : 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
既知だが特殊なスキームのRequest-URI[編集]
このOPTIONSには、SIPリクエストのRequest-URIに一般に現れないIANA登録済みスキームのRequest-URIがある。パーサは、このリクエストを整形されたSIPリクエストとして受理せねばならない。
エレメントはRequest-URIでこのスキームを有効なものとして受理しないだろうが、不明なものとして取り扱い、416 Unsupported URI Schemeレスポンスを返すと良い。エレメントがこのスキームを含むURIを受けいれたならば、そのときは404 Not FoundがこのようなURIを受け入れないためには適当である。
Message Details : 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
ヘッダフィールド中の不明なURIスキーム[編集]
このメッセージには、リクエストのTo、From、Contactヘッダフィールドに登録されたスキームがある。メッセージは構文的に正しい。パーサは、このメッセージを受信したときにメッセージを不正規なものとしてはならない。
プロキシは、このメッセージをこのURIに対するどのリクエストと同様に取り扱うべきである。レジスタでは、Toヘッダフィールドに必須のAORであるSIPまたはSIPS URIを持たないため、400 Bad Requestレスポンスでこのリクエストを拒絶するだろう。
Message Details : 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
Proxy-RequireとRequire[編集]
このリクエストでは、SIPのProxy-RequireとRequire拡張メカニズムの正式な実装を試験する。
このリクエストを受信した全てのエレメントは、RequireとProxy-Requireヘッダフィールドの双方で挙げられたフィーチャの一覧に対応しないヘッダフィールドが含まれているので、エレメントは応答での役割に従って420 Bad Extensionレスポンスで反応するだろう。
Message Details : 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
不明なContent-Type[編集]
このINVITEリクエストには、タイプのわからないボディがある。構文的には正しく、パーサはこのリクエストを受信したときに不正なものとしてはならない。
このリクエストを受信したプロキシは、他のINVITEと同様にこのリクエストを処理する。このリクエストを受信したエンドポイントは415 Unsupported Media Typeエラーで拒絶する。
Message Details : 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>
不明な認可スキーム[編集]
このREGISTERリクエストには、不明なスキームを持ったAuthorizationヘッダフィールドがある。このリクエストは整形されている。パーサはこのリクエストを受信したときに不正なものとしてはならない。
プロキシは他のREGISTERと同様にこのリクエストを扱う。このリクエストを転送する場合、プロキシは転送メッセージ中のこのAuthorizationヘッダフィールドを変更せずに含める。
チャレンジ・レスポンス認証に関して感知しないレジスタは単にAuthorizationヘッダフィールドを無視し、このフィールドが存在しないかのように登録処理をする。チャレンジ・レスポンス認証を重視するレジスタは401でこのリクエストを拒絶し、レジスタの解するスキームで新たなチャレンジを発行する。
レジスタのように振舞わないエンドポイントは単にそのリクエストを拒絶する。405 Method Not Allowedが適当である。
Message Details : 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
単一値が求められるフィールドへの複数値[編集]
このメッセージには、リクエストに複数のCall-ID、To、From、Max-Forwards、CSeq値がある。このリクエストを受信したエレメントは、処理を中止してはならない。
このリクエストを受信したエレメントは、400 Bad Requestエラーで応答する。
Message Details : 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
複数のContent-Length値[編集]
複数の競合するContent-Lengthヘッダフィールド値が、このリクエストに存在する。
大枠では、この状況は、ひとつの不正な（あるいは値のない）Content-Length値と等価である。
このリクエストを受信したエレメントは、エラーで応答すべきである。このリクエストがUDPであったなら、データグラムの残りを単純に破棄してよい。このようなリクエストがTCPで到着したなら、フレームエラーは回復不能なので、接続を閉じるべきである。
Message Details : 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
ここにどれだけのデータがあるのか不明
ブロードキャストアドレスをViaヘッダフィールドに持った200 OKレスポンス[編集]
このメッセージは、二番目のViaヘッダフィールドにあるあて先が255.255.255.255のレスポンスである。このメッセージは整形されているので、パーサは受信時に不正なものとしてはならない。
[RFC 3261]では、このメッセージを受信したエンドポイントは単純にそれを破棄すべきである。
プロキシが、通常の応答を無分別な規則で転送するものであった場合、このレスポンスをブロードキャストアドレスに転送するだろう。このような攻撃手段に対して防御するために、プロキシはそのようなレスポンスを破棄すべきである。
Message Details : 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
Max-Forwards値が0[編集]
これは、Max-Forwardsヘッダフィールド値に0が指定された正しいSIPリクエストである。
プロキシはリクエストを転送せず、483（Too Many Hops）でレスポンスすべきである。エンドポイントは、Max-Forwardsフィールド値が正の整数値であるようにリクエストを処理すべきである。
Message Details : 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
ContactヘッダパラメータのあるREGISTER[編集]
この登録要求のContactにある「unknownparam」は、contact-paramとして解されねばならず、url-paramとして解されてはならない
このREGISTERは成功すべきである。レスポンスでは、このバインディングのurl-parameterとして「unknownparam」を含んではならない。同様に、その後のレスポンスでも「unknownparam」は、あらゆるバインディングにurl-parameterとして存在してはならない。
もちろん、あらゆる既知のcontact-paramパラメータ名についても、振る舞いは同じである。
Message Details : 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
url-parameterのあるREGISTER[編集]
この登録要求には、不明なパラメータを持ったContact URIがある。
登録は成功すべきであり、その後の登録呼び出しではurl-parameterとして「unknownparam」を含めねばならない。
もちろん、あらゆる既知のurl-parameter名に対しても、振る舞いは同じである。
Message Details : 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
URLエスケープされたヘッダのあるREGISTER[編集]
この登録要求には、エスケープされたヘッダを持ったContact URIがある。
登録は成功するだろう。そして、その後の登録呼び出しではこのバインディング用のContact URIにエスケープされたRouteヘッダを含まねばならない。
Message Details : 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
応答できないオファーの受信[編集]
このリクエストは、レスポンスが不明なタイプのボディを含まねばならないことを示している。特に、Acceptヘッダフィールドにapplication/sdpを含まないので、レスポンスにはSDPボディを含まないほうが良い。このリクエストの受信者は406 Not Acceptableに、Acceptヘッダフィールドでオファーされた形式が使えないことを示すWarning/399を付けて応答することができる。同様に、INVITEに対応するあらゆるSIPユーザエージェント（UAs）はapplication/sdpに対応することが求められているので、400 Bad Requestで応答しても良い。
Message Details : 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
後方互換性[編集]
RFC2534構文でのINVITE[編集]
RFC 2543（とその第2版）の下で正しいメッセージは、後方互換性を保つRFC 3261エレメントによって受容されるべきである。
- Viaヘッダフィールドの全てにbranchパラメータがない
- Fromタグがない
- 明確なContent-Lengthがない（ボディは空行のあとのデータグラムにある全オクテットだと考えられる）
- Max-Forwardsヘッダフィールドがない
Message Details : 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
セキュリティの考え方[編集]
この文書では、SIPセッション確立の参考例を提供しており、[RFC 3261]でのセキュリティの考え方が当てはまる。
パーサは、自身の設計の一部として、周辺条件と悪意ある入力を注意深く考慮しなければならない。多くのインターネットシステム上での攻撃では、実装の望ましくない振る舞いの原因となるよう巧妙に作られた入力を用いる。この文書におけるほとんどのメッセージは、パーサ実装に負荷をかけるために、そのような攻撃で伝統的に用いられる要点で構成されている。しかし、この文書は総合的であろうと努めていない。この文書は検討と発想の刺激となるための種子となるべきであり、通過するための簡易なテストセットを検討えない。
謝辞[編集]
省略。
参考資料[編集]
- [RFC 2822]
- Resnick, P., "Internet Message Format", RFC 2822, April 2001.
- [RFC 3261]
- 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.
- [RFC 3264]
- Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
- [RFC 3986]
- Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
- SIP-SEC
- Jennings, C. and K. Ono, "Example call flows using SIP security mechanisms", Work in Progress, July 2005.
付録A 厳密な各テストメッセージのアーカイブ[編集]
以下省略。
