セッション開始プロトコルの負荷テストメッセージ

提供: STUDIO DDT ONLINE
移動先: 案内検索

この文書はIETFが参考情報として公開している仕様書"RFC4475 Session Initiation Protocol Torture Test Messages"をSTUDIO DDT ONLINEが学習目的で日本語に翻訳したものです。正式な仕様書は英語版のみであり、この日本語訳は参考にすぎません

この文書には翻訳上の誤りが含まれるかもしれません。STUDIO DDT ONLINEは翻訳の正確性を保証しません。

この文書のレイアウトはMediaWikiの記法に依存するため、オリジナルの文書とは文書構成、HTMLのセマンティクス、見栄え等が異なります。

この文書の位置づけ
この文書はインターネット社会にむけた参考情報として提供するものであり、いかなるインターネット標準としても定めるものではない。この文書の配布は無制限である。
著作権表示
著作権(C) インターネットソサエティ
概要
この文書には、SIP実装の負荷試験のために考えられたセッション開始プロトコル(SIP)のテストメッセージの例が記載されている。

この翻訳文の著作権はSTUDIO DDT ONLINEおよびサイト管理者が保持しています。この翻訳文の利用などについては免責事項を参照してください。ただし、原文のライセンス内容によっては免責事項よりも原文のライセンスが優先されます。

目次

要旨

この文書は参考であり、SIPに関して規範的でない。

この文書には、RFC 3261で定められたセッション開始プロトコルの最新版(2.0)に基づいたテストメッセージを記載する。いくつかのメッセージでは、SIPがRFC 3264で定められたセッション記述プロトコル(SDP)を用いて実行する。

これらのメッセージは、SIPIT相互運用テストイベントで開発、改善された。

テストメッセージはさまざまな節で構成されている。いくつかのテストメッセージはSIPパーサのみに、その他のテストメッセージはパーサとアプリケーションの双方に負荷をかけるものである。メッセージは正当(valid)なものとそうでないものがある。何がメッセージを不当(invalid)なものとするのかを、各事例では明確に示している。

この文書は、不当なメッセージを作成するために完全な目録を作る努力をしないし、あまり用いられないが正当なメッセージを精査して包括的にすることに努めない。その代わり、不適切に扱ったときに特に好ましくない特性を持つ、あるいは相互運用上の問題となる分野に重点的に取り組むことを目指す。この文書はテスト計画の元にはなるが、テスト計画そのものではない。

メッセージは、あいまいさを避けるためにマークアップ規則の集まりを用いた文字列で表され、インターネット草案の配置要求事項を満たす。残りのあいまいさを解決するために、各メッセージの真に正確なデータが付録に収められている。

この翻訳では巻末の付録については全て省略しています。

文書規約

この文書では多くのSIPメッセージ例を記載している。SIPは文字列に基づくプロトコルなので、RFCの形式的制約があるので、追加の決まりごとなしにこれらの例が曖昧さなしに表現できない。この文書では、曖昧さを取り除くためにこの節で定義するマーク付けを明示し、利用する。このマーク付けはXMLの開始・終了タグの制約を用いるが、いかなるXML文書型も定義しない。

この翻訳ではMediaWikiの記法に基づく制約から、原文にある意図が必ずしも反映されていない場合があり得ます。

付録では、すべてのメッセージのバイナリ形式と、それらをファイルからデコードするのに必要なアルゴリズムを記載している。

この翻訳では巻末の付録については全て省略しています。

長大な行の表現

いくつかの例では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>

goooo...oooogleということなのでしょうか?分かりません><

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 厳密な各テストメッセージのアーカイブ

以下省略。