メインコンテンツまでスキップ

19. 共通メッセージ構成要素 (Common Message Components)

SIP メッセージには、SIP メッセージ内のさまざまな箇所（そして時にはメッセージの外部）に現れ、個別に論じる価値がある特定の構成要素が存在する。

19.1 SIP および SIPS の URI (SIP and SIPS Uniform Resource Indicators)​

SIP または SIPS URI は通信リソースを識別する。すべての URI と同様に、SIP および SIPS URI は Web ページ、電子メールメッセージ、または印刷された文献に配置できる。これらは、そのリソースとの通信セッションを開始および維持するために十分な情報を含んでいる。

通信リソースの例としては以下が挙げられる。

  o  オンラインサービスのユーザー

  o  多線電話機のアピアランス（外見）

  o  メッセージングシステム上のメールボックス

  o  ゲートウェイサービス上の PSTN 番号

  o  組織内のグループ（「sales」や「helpdesk」など）

SIPS URI は、そのリソースに安全に接続することを指定する。これは特に、UAC とその URI を所有するドメインとの間に TLS を使用することを意味する。そこから先は、リソースに到達するために安全な通信が使用され、具体的なセキュリティ機構はドメインのポリシーに依存する。SIP URI で記述されるリソースは、そのリソースと安全に通信したい場合、スキームを変更するだけで「アップグレード」して SIPS URI にできる。

19.1.1 SIP および SIPS URI の構成要素 (SIP and SIPS URI Components)​

「sip:」および「sips:」スキームは RFC 2396 [5] のガイドラインに従う。これらは mailto URL と似た形式を使用し、SIP リクエストヘッダフィールドおよび SIP メッセージボディの指定を可能にする。これにより、Web ページ上や電子メールメッセージ内の URI を用いて開始されるセッションの件名、メディアタイプ、または緊急度を指定できるようになる。SIP または SIPS URI の正式な構文はセクション 25 に示される。SIP URI の場合の一般形式は次のとおりである。

  sip:user:password@host:port;uri-parameters?headers

SIPS URI の形式も同様であるが、スキームが sip ではなく「sips」である点が異なる。これらのトークン、およびそれらの展開における一部のトークンは、以下の意味を持つ。

  user: 宛先とされるホスト上の特定のリソースの識別子。「host」という用語はこの文脈では頻繁にドメインを指す。URI の「userinfo」は、この user フィールド、password フィールド、およびそれに続く @ 記号からなる。URI の userinfo 部分はオプションであり、宛先ホストにユーザーの概念がない場合や、ホスト自身が識別されるリソースである場合には存在しなくてもよい。SIP または SIPS URI に @ 記号が存在する場合、user フィールドは空であってはならない。

     アドレス指定されるホストが電話番号を処理できる場合（例えばインターネット電話ゲートウェイ）、RFC 2806 [9] で定義される telephone-subscriber フィールドを user フィールドに格納してもよい。SIP および SIPS URI 内で telephone-subscriber フィールドを符号化するための特別なエスケープ規則はセクション 19.1.2 に記述されている。

  password: ユーザーに関連付けられたパスワード。SIP および SIPS URI の構文ではこのフィールドの存在を許しているが、その使用は推奨されない。なぜなら、平文（URI など）での認証情報の受け渡しは、使用されたほぼすべてのケースでセキュリティリスクであることが証明されているからである。例えば、このフィールドに PIN 番号を運ぶと PIN が露出する。

     なお、password フィールドは user 部分の単なる拡張である。フィールドの password 部分に特別な意味を持たせたくない実装は、「user:password」を単一の文字列として扱ってもよい。

  host: SIP リソースを提供するホスト。host 部分には、完全修飾ドメイン名、または数値の IPv4 ないし IPv6 アドレスのいずれかが含まれる。可能な限り完全修飾ドメイン名形式を使用することが推奨される。

  port: リクエストを送信する先のポート番号。

  URI parameters: URI から構成されるリクエストに影響を及ぼすパラメータ。

     URI パラメータは hostport 構成要素の後に追加され、セミコロンで区切られる。

     URI パラメータの形式は次のとおりである。

        parameter-name "=" parameter-value

     任意の数の URI パラメータを URI に含めることができるが、特定の parameter-name が複数回現れてはならない。

     この拡張可能な機構には、transport、maddr、ttl、user、method、および lr パラメータが含まれる。

     transport パラメータは、[4] で指定されるように、SIP メッセージの送信に使用されるトランスポート機構を決定する。SIP は任意のネットワークトランスポートプロトコルを使用できる。パラメータ名は UDP（RFC 768 [14]）、TCP（RFC 761 [15]）、および SCTP（RFC 2960 [16]）に対して定義されている。SIPS URI の場合、transport パラメータは信頼できるトランスポートを示さなければならない。

     maddr パラメータは、このユーザーに対して接続すべきサーバーアドレスを示し、host フィールドから導出される任意のアドレスを上書きする。maddr パラメータが存在する場合、URI の port および transport 構成要素は、maddr パラメータ値で示されるアドレスに適用される。[4] は、リクエストを送信するための宛先アドレス、ポート、トランスポートを得るための、transport、maddr、および hostport の適切な解釈を説明している。

     maddr フィールドは、ルースソースルーティングの単純な形式として使用されてきた。これにより、URI は宛先への経路上で通過しなければならないプロキシを指定できる。この方法での maddr パラメータの継続使用は強く推奨されない（それを可能にする機構は非推奨である）。実装は代わりに、この文書で説明される Route 機構を使用し、必要に応じて事前に存在するルートセットを確立すべきである（セクション 8.1.1.1 参照）。これにより、通過すべきノードを記述する完全な URI が提供される。

     ttl パラメータは UDP マルチキャストパケットの生存時間（time-to-live）値を決定し、maddr がマルチキャストアドレスでありトランスポートプロトコルが UDP である場合にのみ使用されなければならない。例えば、ttl 15 で 239.255.255.1 へのマルチキャストを使用して [email protected] への呼び出しを指定するには、次の URI が使用される。

        sip:[email protected];maddr=239.255.255.1;ttl=15

     有効な telephone-subscriber 文字列の集合は、有効な user 文字列の部分集合である。user URI パラメータは、電話番号と偶然電話番号のように見えるユーザー名を区別するために存在する。user 文字列に telephone-subscriber として書式化された電話番号が含まれる場合、「phone」という user パラメータ値を存在させるべきである（SHOULD）。このパラメータがなくても、SIP および SIPS URI の受信者は、ユーザー名の名前空間に対するローカルな制限が許すならば、@ の前の部分を電話番号として解釈してもよい。

     URI から構成される SIP リクエストのメソッドは、method パラメータで指定できる。

     lr パラメータが存在する場合、このリソースを担当する要素がこの文書で指定されるルーティング機構を実装していることを示す。このパラメータは、プロキシが Record-Route ヘッダフィールド値に格納する URI 内で使用され、事前に存在するルートセット内の URI に現れてもよい。

     このパラメータは、RFC 2543 の厳密ルーティング機構および bis-05 までの rfc2543bis ドラフトを実装するシステムとの後方互換性を達成するために使用される。このパラメータを含まない URI に基づいてリクエストを送信しようとする要素は、受信要素が厳密ルーティングを実装していると仮定し、Request-URI 内の情報を保持するためにメッセージを再構成できる。

     URI パラメータ機構は拡張可能であるため、SIP 要素は理解できない URI パラメータを黙って無視しなければならない。

  Headers: URI から構成されるリクエストに含めるべきヘッダフィールド。

     SIP リクエスト内のヘッダフィールドは、URI 内の「?」機構を用いて指定できる。ヘッダ名および値は、アンパサンドで区切られた hname = hvalue の組として符号化される。特別な hname である「body」は、関連する hvalue が SIP リクエストのメッセージボディであることを示す。

表 1 は、URI が現れる文脈に基づく SIP および SIPS URI 構成要素の使用法をまとめたものである。external 列は、SIP メッセージの外部（例えば Web ページや名刺）に現れる URI を説明する。「m」と印付けられた項目は必須、「o」はオプション、「-」は許可されない。URI を処理する要素は、存在する場合、許可されない構成要素を無視すべきである（SHOULD）。第 2 列は、オプションの要素が存在しない場合のデフォルト値を示す。「--」は、その要素がオプションでないか、デフォルト値を持たないことを示す。

Contact ヘッダフィールド内の URI には、ヘッダフィールドが現れる文脈に応じて異なる制限がある。一方の集合は、ダイアログを確立および維持するメッセージ（INVITE およびその 200（OK）応答）に適用される。もう一方は、登録およびリダイレクトメッセージ（REGISTER、その 200（OK）応答、および任意のメソッドに対する 3xx クラス応答）に適用される。

19.1.2 文字エスケープ要件 (Character Escaping Requirements)​

                                                   dialog
                                      reg./redir. Contact/
          default  Req.-URI  To  From  Contact   R-R/Route  external

user -- o o o o o o password -- o o o o o o host -- m m m m m m port (1) o - - o o o user-param ip o o o o o o method INVITE - - - - - o maddr-param -- o - - o o o ttl-param 1 o - - o - o transp.-param (2) o - - o o o lr-param -- o - - - o o other-param -- o o o o o o headers -- - - - o - o

(1): デフォルトのポート値はトランスポートおよびスキームに依存する。デフォルトは、UDP、TCP、または SCTP を使用する sip: の場合 5060 である。デフォルトは、TCP 上の TLS を使用する sip: および TCP 上の sips: の場合 5061 である。

(2): デフォルトのトランスポートはスキームに依存する。sip: の場合は UDP である。sips: の場合は TCP である。

表 1: SIP ヘッダフィールド値、Request-URI、および参照のための URI 構成要素の使用法およびデフォルト値

SIP は、SIP URI 内でエスケープされなければならない文字の集合を定義する際、RFC 2396 [5] の要件およびガイドラインに従い、エスケープにその「%」HEX HEX 機構を使用する。RFC 2396 [5] より：

  特定の URI 構成要素内で実際に予約されている文字の集合は、その構成要素によって定義される。一般に、その文字がそのエスケープされた US-ASCII 符号化に置き換えられた場合に URI の意味が変化するならば、その文字は予約されている。除外された US-ASCII 文字（RFC 2396 [5]）（スペースや制御文字、および URI の区切り文字として使用される文字など）もエスケープされなければならない。URI は、エスケープされていないスペースおよび制御文字を含んではならない。

各構成要素について、有効な BNF 展開の集合は、どの文字がエスケープされずに現れてよいかを正確に定義する。それ以外のすべての文字はエスケープされなければならない。

例えば、「@」は user 構成要素内の文字の集合に含まれないため、「j@s0n」というユーザーは、少なくとも @ 記号を「j%40s0n」のように符号化しなければならない。

セクション 25 の hname および hvalue トークンを展開すると、ヘッダフィールド名および値内のすべての URI 予約文字をエスケープしなければならないことが示される。

user 構成要素の telephone-subscriber 部分集合には、特別なエスケープの考慮事項がある。RFC 2806 [9] の telephone-subscriber の記述で予約されていない文字の集合には、SIP URI で使用される際にエスケープする必要があるさまざまな構文要素内の多数の文字が含まれる。telephone-subscriber に現れ、user 規則の BNF の展開に現れない文字は、すべてエスケープされなければならない。

なお、SIP または SIPS URI の host 構成要素では文字のエスケープは許されない（% 文字はその展開内で有効ではない）。これは、国際化ドメイン名（IDN）の要件が確定するにつれて将来変更される可能性が高い。現在の実装は、host 構成要素内で受信したエスケープされた文字を、そのエスケープされていない対応物と文字通り同等であるとみなして堅牢性を向上させようとしてはならない。IDN の要件を満たすために必要な挙動は大きく異なる可能性がある。

19.1.3 SIP および SIPS URI の例 (Example SIP and SIPS URIs)​

sip:[email protected] sip:alice:[email protected];transport=tcp sips:[email protected]?subject=project%20x&priority=urgent sip:+1-212-555-1212:[email protected];user=phone sips:[email protected] sip:[email protected] sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com sip:alice;day=[email protected]

上記の最後のサンプル URI の user フィールド値は「alice;day=tuesday」である。上記で定義されたエスケープ規則により、このフィールド内にセミコロンをエスケープされずに現すことができる。このプロトコルの目的上、このフィールドは不透明である。その値の構造が有用なのは、そのリソースを担当する SIP 要素に対してのみである。

19.1.4 URI の比較 (URI Comparison)​

この仕様の一部の操作では、2 つの SIP または SIPS URI が等価であるかどうかを決定する必要がある。この仕様では、レジストラは REGISTER リクエスト内の Contact URI のバインディングを比較する必要がある（セクション 10.3 参照）。SIP および SIPS URI は、次の規則に従って等値比較される。

  o  SIP URI と SIPS URI は決して等価ではない。

  o  SIP および SIPS URI の userinfo の比較は大文字小文字を区別する。これには、パスワードを含む、または telephone-subscriber として書式化された userinfo が含まれる。URI のその他すべての構成要素の比較は、明示的に別途定義されない限り大文字小文字を区別しない。

  o  パラメータおよびヘッダフィールドの順序は、SIP および SIPS URI の比較において重要ではない。

  o  「予約」集合（RFC 2396 [5] 参照）内にない文字は、その「%」HEX HEX 符号化と等価である。

  o  ホスト名の DNS ルックアップの結果である IP アドレスは、そのホスト名と一致しない。

  o  2 つの URI が等しいためには、user、password、host、および port 構成要素が一致しなければならない。

     user 構成要素を省略した URI は、それを含む URI と一致しない。password 構成要素を省略した URI は、それを含む URI と一致しない。

     デフォルト値を持つ構成要素を省略した URI は、その構成要素をそのデフォルト値とともに明示的に含む URI と一致しない。例えば、オプションの port 構成要素を省略した URI は、ポート 5060 を明示的に宣言する URI と一致しない。これは transport-parameter、ttl-parameter、user-parameter、および method 構成要素についても同様である。

        sip:user@host を sip:user@host:5060 と等価でないと定義することは、RFC 2543 からの変更である。URI からアドレスを導出する際、等価な URI からは等価なアドレスが期待される。URI sip:user@host:5060 は常にポート 5060 に解決される。URI sip:user@host は、[4] で詳述される DNS SRV 機構を通じて他のポートに解決される可能性がある。

  o  URI の uri-parameter 構成要素は次のように比較される。

     -  両方の URI に現れる任意の uri-parameter は一致しなければならない。

     -  一方の URI にのみ現れる user、ttl、または method の uri-parameter は、デフォルト値を含んでいても決して一致しない。

     -  maddr パラメータを含む URI は、maddr パラメータを含まない URI と一致しない。

     -  一方の URI にのみ現れるその他すべての uri-parameter は、URI を比較する際に無視される。

  o  URI のヘッダ構成要素が無視されることはない。存在するヘッダ構成要素は、URI が一致するためには両方の URI に存在し、かつ一致しなければならない。一致規則は各ヘッダフィールドについてセクション 20 で定義される。

以下の各集合内の URI は等価である。

sip:%[email protected];transport=TCP sip:[email protected];Transport=tcp

sip:[email protected] sip:[email protected];newparam=5 sip:[email protected];security=on

sip:biloxi.com;transport=tcp;method=REGISTER?to=sip:bob%40biloxi.com sip:biloxi.com;method=REGISTER;transport=tcp?to=sip:bob%40biloxi.com

sip:[email protected]?subject=project%20x&priority=urgent sip:[email protected]?priority=urgent&subject=project%20x

以下の各集合内の URI は等価ではない。

SIP:[email protected];Transport=udp （異なるユーザー名） sip:[email protected];Transport=UDP

sip:[email protected] （異なるポートに解決される可能性がある） sip:[email protected]:5060

sip:[email protected] （異なるトランスポートに解決される可能性がある） sip:[email protected];transport=udp

sip:[email protected] （異なるポートおよびトランスポートに解決される可能性がある） sip:[email protected]:6000;transport=tcp

sip:[email protected] （異なるヘッダ構成要素） sip:[email protected]?Subject=next%20meeting

sip:[email protected] （たとえそれが sip:[email protected] phone21.boxesbybob.com の解決先であっても）

なお、等値性は推移的ではない。

  o  sip:[email protected] と sip:[email protected];security=on は等価である

  o  sip:[email protected] と sip:[email protected];security=off は等価である

  o  sip:[email protected];security=on と
     sip:[email protected];security=off は等価ではない

19.1.5 URI からのリクエスト構成 (Forming Requests from a URI)​

実装は、URI から直接リクエストを構成する際に注意する必要がある。名刺、Web ページ、さらにはプロトコル内部のソース（登録されたコンタクトなど）からの URI には、不適切なヘッダフィールドやボディ部分が含まれている可能性がある。

実装は、構成されたリクエストの Request-URI に、提供された transport、maddr、ttl、または user パラメータを含めなければならない。URI に method パラメータが含まれる場合、その値をリクエストのメソッドとして使用しなければならない。method パラメータを Request-URI に配置してはならない。未知の URI パラメータは、メッセージの Request-URI に配置しなければならない。

実装は、URI 内のヘッダやボディ部分の存在を、メッセージにそれらを含めたいという意向として扱い、構成要素ごとにその要求に応えるかを選択すべきである（SHOULD）。

実装は、これらの明らかに危険なヘッダフィールド、すなわち From、Call-ID、CSeq、Via、および Record-Route に応えるべきではない（SHOULD NOT）。

実装は、悪意のある攻撃において無意識のエージェントとして利用されないよう、要求された Route ヘッダフィールド値に応えるべきではない（SHOULD NOT）。

実装は、自身の場所や能力を偽ってアドバタイズする原因となる可能性のあるヘッダフィールドの要求に応えるべきではない（SHOULD NOT）。これらには、Accept、Accept-Encoding、Accept-Language、Allow、Contact（ダイアログ中の使用）、Organization、Supported、および User-Agent が含まれる。

実装は、Content-Disposition、Content-Encoding、Content-Language、Content-Length、Content-Type、Date、Mime-Version、および Timestamp を含む、要求された記述的ヘッダフィールドの正確性を検証すべきである（SHOULD）。

特定の URI からメッセージを構成して形成されたリクエストが有効な SIP リクエストでない場合、その URI は無効である。実装はリクエストの送信を進めてはならない。その代わりに、それが発生した文脈において無効な URI に対してとるべき行動をとるべきである。

  構成されたリクエストは多くの点で無効になり得る。これには、ヘッダフィールドの構文エラー、URI パラメータの無効な組み合わせ、またはメッセージボディの不正な記述などが含まれるが、これらに限定されない。

特定の URI から形成されたリクエストの送信には、実装が利用できない能力が必要となる場合がある。例えば、URI は未実装のトランスポートや拡張の使用を示しているかもしれない。実装は、それらの能力に合わせて変更するのではなく、これらのリクエストの送信を拒否すべきである（SHOULD）。実装は、自身がサポートしない拡張を必要とするリクエストを送信してはならない。

  例えば、このようなリクエストは、未知または明示的にサポートされていない値を持つ Require ヘッダパラメータまたは method URI パラメータの存在を通じて形成される可能性がある。

19.1.6 SIP URI と tel URL の関連付け (Relating SIP URIs and tel URLs)​

tel URL（RFC 2806 [9]）が SIP または SIPS URI に変換される場合、tel URL の telephone-subscriber 部分全体（パラメータを含む）が、SIP または SIPS URI の userinfo 部分に配置される。

したがって、tel:+358-555-1234567;postd=pp22 は、

  sip:+358-555-1234567;[email protected];user=phone

または sips:+358-555-1234567;postd=[email protected];user=phone

となり、

  sip:[email protected];postd=pp22;user=phone

または

  sips:[email protected];postd=pp22;user=phone

とはならない。

一般に、この方法で SIP または SIPS URI に変換された等価な「tel」URL が、等価な SIP または SIPS URI を生成するとは限らない。SIP および SIPS URI の userinfo は大文字小文字を区別する文字列として比較される。tel URL の大文字小文字を区別しない部分の違いや、tel URL パラメータの順序変更は tel URL の等価性には影響しないが、そこから形成された SIP URI の等価性には影響する。

例えば、

  tel:+358-555-1234567;postd=pp22
  tel:+358-555-1234567;POSTD=PP22

は等価であるが、

  sip:+358-555-1234567;[email protected];user=phone
  sip:+358-555-1234567;[email protected];user=phone

は等価ではない。

同様に、

  tel:+358-555-1234567;postd=pp22;isub=1411
  tel:+358-555-1234567;isub=1411;postd=pp22

は等価であるが、

  sip:+358-555-1234567;postd=pp22;[email protected];user=phone
  sip:+358-555-1234567;isub=1411;[email protected];user=phone

は等価ではない。

この問題を軽減するため、SIP または SIPS URI の userinfo 部分に配置する telephone-subscriber フィールドを構成する要素は、telephone-subscriber の大文字小文字を区別しない部分をすべて小文字に折りたたみ、telephone-subscriber パラメータをパラメータ名の辞書順に並べ替えるべきである（SHOULD）。ただし、isdn-subaddress および post-dial は最初に、かつその順序で現れる。（tel URL の将来の拡張パラメータを除くすべての構成要素は、大文字小文字を区別せずに比較されるように定義されている。）

この提案に従うと、両方の

  tel:+358-555-1234567;postd=pp22
  tel:+358-555-1234567;POSTD=PP22

  は、次のようになる。

    sip:+358-555-1234567;[email protected];user=phone

また、両方の

    tel:+358-555-1234567;tsp=a.b;phone-context=5
    tel:+358-555-1234567;phone-context=5;tsp=a.b

  は、次のようになる。

    sip:+358-555-1234567;phone-context=5;[email protected];user=phone

19.2 オプションタグ (Option Tags)​

オプションタグは、SIP 内の新しいオプション（拡張）を指定するために使用される一意の識別子である。これらのタグは、Require（セクション 20.32）、Proxy-Require（セクション 20.29）、Supported（セクション 20.37）、および Unsupported（セクション 20.40）ヘッダフィールドで使用される。これらのオプションは、それらのヘッダフィールド内のパラメータとして、option-tag = token の形式（token の定義についてはセクション 25 参照）で現れることに注意されたい。

オプションタグは、標準トラック RFC で定義される。これは過去の慣行からの変更であり、継続的なマルチベンダー相互運用性を確保するために導入された（セクション 20.32 およびセクション 20.37 の議論を参照）。オプションタグの IANA レジストリが、容易な参照を確保するために使用される。

19.3 タグ (Tags)​

「tag」パラメータは、SIP メッセージの To および From ヘッダフィールドで使用される。これは、Call-ID と、ダイアログの各参加者からの 2 つのタグ（1 つずつ）の組み合わせであるダイアログを識別するための一般機構として機能する。UA がダイアログ外でリクエストを送信する場合、それには From タグのみが含まれ、ダイアログ ID の「半分」を提供する。ダイアログは応答から完成し、それぞれが To ヘッダフィールドで第 2 の半分を提供する。SIP リクエストのフォークにより、単一のリクエストから複数のダイアログを確立できる。これはまた、両側のダイアログ識別子の必要性を説明する。受信者からの寄与がなければ、発信者は単一のリクエストから確立された複数のダイアログを明確に区別できない。

タグがリクエストまたは応答への挿入のために UA によって生成される場合、それは少なくとも 32 ビットの乱数性を持つ、グローバルに一意かつ暗号的にランダムでなければならない。この選択要件の特性として、UA は同じ INVITE に対する応答の To ヘッダに配置するタグとは異なるタグを、INVITE の From ヘッダに配置する。これは、UA が自らをセッションに招待する（PSTN ゲートウェイにおける「ヘアピン」呼び出しの一般的なケース）ために必要である。同様に、異なる呼び出しに対する 2 つの INVITE は異なる From タグを持ち、異なる呼び出しに対する 2 つの応答は異なる To タグを持つ。

グローバルな一意性の要件に加えて、タグを生成するアルゴリズムは実装固有である。タグは、障害発生後に代替サーバー上でダイアログを回復する必要があるフォールトトレラントシステムにおいて有用である。UAS は、バックアップが要求を障害発生したサーバー上のダイアログの一部として認識できるようにタグを選択でき、したがってそのダイアログおよびそれに関連するその他の状態を回復しようとすることを決定できる。