20. ヘッダフィールド (Header Fields)

20 ヘッダフィールド

ヘッダフィールドの一般構文はセクション 7.3 で扱う。このセクションでは、構文、意味、および使用方法に関する注釈とともにヘッダフィールドの完全な集合を列挙する。本セクションを通じて、現在の HTTP/1.1 仕様 RFC 2616 [8] のセクション X.Y を参照するために [HX.Y] を使用する。各ヘッダフィールドの例を示す。

メソッドおよびプロキシ処理に関連するヘッダフィールドの情報は、表 2 および 3 にまとめられている。

「where」列は、ヘッダフィールドを使用できるリクエストおよびレスポンスの種類を記述する。この列の値は次のとおりである。

  R: ヘッダフィールドはリクエストにのみ現れ得る。

  r: ヘッダフィールドはレスポンスにのみ現れ得る。

  2xx、4xx など: 数値または範囲は、ヘッダフィールドを使用できるレスポンスコードを示す。

  c: ヘッダフィールドはリクエストからレスポンスにコピーされる。

  「where」列が空の場合、ヘッダフィールドはすべてのリクエストおよびレスポンスに存在し得ることを示す。

「proxy」列は、プロキシがヘッダフィールドに対して実行できる操作を記述する。

  a: プロキシは、ヘッダフィールドが存在しない場合、それを追加または連結できる。

  m: プロキシは既存のヘッダフィールド値を変更できる。

  d: プロキシはヘッダフィールド値を削除できる。

  r: プロキシはヘッダフィールドを読み取れる必要があり、したがってこのヘッダフィールドは暗号化できない。

次の 6 列は、メソッドにおけるヘッダフィールドの存在に関係する。

  c: 条件付き。ヘッダフィールドに対する要件はメッセージの文脈に依存する。

  m: ヘッダフィールドは必須である。

  m*: ヘッダフィールドは送信されることが望ましい（SHOULD）が、クライアント/サーバーはそのヘッダフィールドのないメッセージを受信する用意が必要である。

  o: ヘッダフィールドはオプションである。

  t: ヘッダフィールドは送信されることが望ましい（SHOULD）が、クライアント/サーバーはそのヘッダフィールドのないメッセージを受信する用意が必要である。

     ストリームベースのプロトコル（TCP など）がトランスポートとして使用される場合、ヘッダフィールドは送信されなければならない。

  *: メッセージボディが空でない場合、ヘッダフィールドは必須である。詳細はセクション 20.14、20.15、および 7.4 を参照。

  -: ヘッダフィールドは適用不可である。

「オプション」とは、要素がリクエストまたはレスポンスにヘッダフィールドを含めてもよく（MAY）、UA はリクエストまたはレスポンスに存在する場合ヘッダフィールドを無視してもよい（MAY）ことを意味する（この規則の例外は 20.32 で論じる Require ヘッダフィールドである）。「必須」ヘッダフィールドはリクエストに存在しなければならず、リクエストを受信する UAS によって理解されなければならない。「必須」レスポンスヘッダフィールドはレスポンスに存在しなければならず、レスポンスを処理する UAC によってヘッダフィールドが理解されなければならない。「適用不可」とは、ヘッダフィールドがリクエストに存在してはならない（MUST NOT）ことを意味する。誤ってリクエストに配置された場合、リクエストを受信する UAS によって無視されなければならない。同様に、レスポンスに対して「適用不可」とラベル付けされたヘッダフィールドは、UAS がレスポンスにそのヘッダフィールドを配置してはならず、UAC がレスポンス内のヘッダフィールドを無視しなければならないことを意味する。

UA は、理解できない拡張ヘッダフィールドパラメータを無視すべきである（SHOULD）。

全体的なメッセージサイズが問題となる場合に使用するため、一部の一般的なヘッダフィールド名の省略形も定義されている。

Contact、From、および To ヘッダフィールドには URI が含まれる。URI にカンマ、疑問符、またはセミコロンが含まれる場合、URI は山括弧（< および >）で囲まれなければならない。URI パラメータはこれらの括弧内に含まれる。URI が山括弧で囲まれていない場合、セミコロン区切りのパラメータは URI パラメータではなくヘッダパラメータである。

20.1 Accept

Accept ヘッダフィールドは [H14.1] で定義された構文に従う。セマンティクスも同一であるが、Accept ヘッダフィールドが存在しない場合、サーバーはデフォルト値 application/sdp を想定すべきである（SHOULD）という例外がある。

空の Accept ヘッダフィールドは、いかなるフォーマットも受け入れられないことを意味する。

例：

  Header field          where   proxy ACK BYE CAN INV OPT REG
  ___________________________________________________________
  Accept                  R            -   o   -   o   m*  o
  Accept                 2xx           -   -   -   o   m*  o
  Accept                 415           -   c   -   c   c   c
  Accept-Encoding         R            -   o   -   o   o   o
  Accept-Encoding        2xx           -   -   -   o   m*  o
  Accept-Encoding        415           -   c   -   c   c   c
  Accept-Language         R            -   o   -   o   o   o
  Accept-Language        2xx           -   -   -   o   m*  o
  Accept-Language        415           -   c   -   c   c   c
  Alert-Info              R      ar    -   -   -   o   -   -
  Alert-Info             180     ar    -   -   -   o   -   -
  Allow                   R            -   o   -   o   o   o
  Allow                  2xx           -   o   -   m*  m*  o
  Allow                   r            -   o   -   o   o   o
  Allow                  405           -   m   -   m   m   m
  Authentication-Info    2xx           -   o   -   o   o   o
  Authorization           R            o   o   o   o   o   o
  Call-ID                 c       r    m   m   m   m   m   m
  Call-Info                      ar    -   -   -   o   o   o
  Contact                 R            o   -   -   m   o   o
  Contact                1xx           -   -   -   o   -   -
  Contact                2xx           -   -   -   m   o   o
  Contact                3xx      d    -   o   -   o   o   o
  Contact                485           -   o   -   o   o   o
  Content-Disposition                  o   o   -   o   o   o
  Content-Encoding                     o   o   -   o   o   o
  Content-Language                     o   o   -   o   o   o
  Content-Length                 ar    t   t   t   t   t   t
  Content-Type                         *   *   -   *   *   *
  CSeq                    c       r    m   m   m   m   m   m
  Date                            a    o   o   o   o   o   o
  Error-Info           300-699    a    -   o   o   o   o   o
  Expires                              -   -   -   o   -   o
  From                    c       r    m   m   m   m   m   m
  In-Reply-To             R            -   -   -   o   -   -
  Max-Forwards            R      amr   m   m   m   m   m   m
  Min-Expires            423           -   -   -   -   -   m
  MIME-Version                         o   o   -   o   o   o
  Organization                   ar    -   -   -   o   o   o

        表 2: ヘッダフィールドの概要、A–O

Header field where proxy ACK BYE CAN INV OPT REG

Priority R ar - - - o - - Proxy-Authenticate 407 ar - m - m m m Proxy-Authenticate 401 ar - o o o o o Proxy-Authorization R dr o o - o o o Proxy-Require R ar - o - o o o Record-Route R ar o o o o o - Record-Route 2xx,18x mr - o o o o - Reply-To - - - o - - Require ar - c - c c c Retry-After 404,413,480,486 - o o o o o 500,503 - o o o o o 600,603 - o o o o o Route R adr c c c c c c Server r - o o o o o Subject R - - - o - - Supported R - o o m* o o Supported 2xx - o o m* m* o Timestamp o o o o o o To c(1) r m m m m m m Unsupported 420 - m - m m m User-Agent o o o o o o Via R amr m m m m m m Via rc dr m m m m m m Warning r - o o o o o WWW-Authenticate 401 ar - m - m m m WWW-Authenticate 407 ar - o - o o o

表 3: ヘッダフィールドの概要、P–Z；（1）: 可能なタグ追加とともにコピーされる

  Accept: application/sdp;level=1, application/x-private, text/html

20.2 Accept-Encoding

Accept-Encoding ヘッダフィールドは Accept と類似しているが、レスポンスにおいて受け入れ可能な content-coding [H3.5] に制限する。[H14.3] を参照。SIP におけるセマンティクスは [H14.3] で定義されたものと同一である。

空の Accept-Encoding ヘッダフィールドは許容される。これは Accept-Encoding: identity と等価であり、つまり符号化なしを意味する identity 符号化のみが許容される。

Accept-Encoding ヘッダフィールドが存在しない場合、サーバーはデフォルト値 identity を想定すべきである（SHOULD）。

これは HTTP の定義とやや異なる。HTTP の定義は、存在しない場合は任意の符号化を使用できるが、identity 符号化が優先されるとしている。

例：

  Accept-Encoding: gzip

20.3 Accept-Language

Accept-Language ヘッダフィールドはリクエストで使用され、レスポンス内のメッセージボディとして運ばれる理由句、セッション記述、またはステータスレスポンスに対する優先言語を示す。Accept-Language ヘッダフィールドが存在しない場合、サーバーはすべての言語がクライアントに受け入れ可能であると想定すべきである（SHOULD）。

Accept-Language ヘッダフィールドは [H14.4] で定義された構文に従う。「q」パラメータに基づく言語の順序付けの規則は SIP にも適用される。

例：

  Accept-Language: da, en-gb;q=0.8, en;q=0.7

20.4 Alert-Info

INVITE リクエストに存在する場合、Alert-Info ヘッダフィールドは UAS に対する代替着信音を指定する。180（Ringing）レスポンスに存在する場合、Alert-Info ヘッダフィールドは UAC に対する代替呼出音を指定する。典型的な使用方法は、プロキシがこのヘッダフィールドを挿入して独特な着信音機能を提供することである。

Alert-Info ヘッダフィールドはセキュリティリスクをもたらし得る。これらのリスクおよびその対処方法は、リスクが同一であるため Call-Info ヘッダフィールドを論じるセクション 20.9 で論じる。

さらに、ユーザーはこの機能を選択的に無効にできるべきである（SHOULD）。

  これは、信頼できない要素によるこのヘッダフィールドの使用に起因する可能性のある混乱を防ぐのに役立つ。

例：

  Alert-Info: <http://www.example.com/sounds/moo.wav>

20.5 Allow

Allow ヘッダフィールドは、メッセージを生成する UA がサポートするメソッドの集合を列挙する。

UA によって理解されるすべてのメソッド（ACK および CANCEL を含む）は、存在する場合、Allow ヘッダフィールドのメソッドのリストに含まれなければならない（MUST）。Allow ヘッダフィールドが存在しないことは、メッセージを送信する UA がいかなるメソッドもサポートしていないことを意味すると解釈されてはならない（MUST NOT）。むしろ、それは UA がサポートするメソッドについていかなる情報も提供していないことを意味する。

OPTIONS 以外のメソッドに対するレスポンスに Allow ヘッダフィールドを含めることは、必要なメッセージ数を減らす。

例：

  Allow: INVITE, ACK, OPTIONS, CANCEL, BYE

20.6 Authentication-Info

Authentication-Info ヘッダフィールドは HTTP Digest による相互認証を提供する。UAS は、Authorization ヘッダフィールドに基づく digest で正常に認証されたリクエストに対する 2xx レスポンスに、このヘッダフィールドを含めてもよい（MAY）。

構文およびセマンティクスは RFC 2617 [17] で指定されたものに従う。

例：

  Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c"

20.7 Authorization

Authorization ヘッダフィールドは UA の認証資格情報を含む。Authorization ヘッダフィールドの使用の概要はセクション 22.2 であり、HTTP 認証で使用される場合の構文およびセマンティクスはセクション 22.4 で説明する。

このヘッダフィールドは、Proxy-Authorization とともに、複数のヘッダフィールド値に関する一般規則を破る。コンマ区切りのリストではないが、このヘッダフィールド名は複数回存在し得り、セクション 7.3 で説明される通常の規則を使用して単一のヘッダ行に統合されてはならない（MUST NOT）。

以下の例では、Digest パラメータの周りに引用符はない。

  Authorization: Digest username="Alice", realm="atlanta.com",
   nonce="84a4cc6f3082121f32b42a2187831a9e",
   response="7587245234b3434cc3412213e5f113a5432"

20.8 Call-ID

Call-ID ヘッダフィールドは、特定の招待または特定のクライアントのすべての登録を一意に識別する。単一のマルチメディア会議は、例えばユーザが単一の個人を同じ（長時間実行される）会議に複数回招待した場合、異なる Call-ID を持ついくつかの呼び出しを生じ得る。Call-ID は大文字小文字を区別し、単純にバイトごとに比較される。

Call-ID ヘッダフィールドの省略形は i である。

例：

  Call-ID: [email protected]
  i:[email protected]

20.9 Call-Info

Call-Info ヘッダフィールドは、リクエストかレスポンスかに応じて、発信者または被呼者に関する追加情報を提供する。URI の目的は「purpose」パラメータによって記述される。「icon」パラメータは発信者または被呼者のアイコン的表現として適切な画像を指定する。「info」パラメータは、例えば Web ページを通じて、発信者または被呼者を一般的に記述する。「card」パラメータは、例えば vCard [36] または LDIF [37] 形式で名刺を提供する。追加のトークンは IANA およびセクション 27 の手順を使用して登録できる。

Call-Info ヘッダフィールドの使用はセキュリティリスクをもたらし得る。悪意のある発信者が提供する URI を被呼者が取得した場合、不適切または不快なコンテンツ、危険または違法なコンテンツなどのリスクにさらされ得る。したがって、UA は、ヘッダフィールドを発信した要素の真正性を検証でき、かつその要素を信頼する場合にのみ、Call-Info ヘッダフィールドの情報を表示すべきである（RECOMMENDED）。これはピア UA である必要はない。プロキシがこのヘッダフィールドをリクエストに挿入してもよい。

例：

Call-Info: http://wwww.example.com/alice/photo.jpg ;purpose=icon, http://www.example.com/alice/ ;purpose=info

20.10 Contact

Contact ヘッダフィールド値は、それが含まれるリクエストまたはレスポンスの種類に応じて意味を持つ URI を提供する。

Contact ヘッダフィールド値は、表示名、URI パラメータ付きの URI、およびヘッダパラメータを含み得る。

この文書は Contact パラメータ「q」および「expires」を定義する。これらのパラメータは、Contact が REGISTER リクエストまたはレスポンス、あるいは 3xx レスポンスに存在する場合にのみ使用される。追加のパラメータは他の仕様で定義されてもよい。

ヘッダフィールド値に表示名が含まれる場合、すべての URI パラメータを含む URI は「<」および「>」で囲まれる。「<」および「>」が存在しない場合、URI 以降のすべてのパラメータは URI パラメータではなくヘッダパラメータである。表示名はトークンであってもよく、より大きな文字セットが希望される場合は引用符付き文字列であってもよい。

「display-name」が空であっても、「addr-spec」にカンマ、セミコロン、または疑問符が含まれる場合は、「name-addr」形式を使用しなければならない（MUST）。表示名と「<」の間に LWS があってもなくてもよい。

表示名、URI、および URI パラメータ、ならびにヘッダパラメータを解析するこれらの規則は、To および From ヘッダフィールドにも適用される。

  Contact ヘッダフィールドは HTTP の Location ヘッダフィールドと類似した役割を持つ。しかし、HTTP ヘッダフィールドは引用符なしの 1 つのアドレスのみを許可する。URI は予約文字としてカンマおよびセミコロンを含み得るため、それらはそれぞれヘッダまたはパラメータの区切り文字と誤認され得る。

Contact ヘッダフィールドの省略形は m（「moved」の意）である。

例：

  Contact: "Mr. Watson" <sip:[email protected]>
     ;q=0.7; expires=3600,
     "Mr. Watson" <mailto:[email protected]> ;q=0.1
  m: <sips:[email protected]>;expires=60

20.11 Content-Disposition

Content-Disposition ヘッダフィールドは、メッセージボディ、またはマルチパートメッセージの場合はメッセージボディパーツが UAC または UAS によってどのように解釈されるかを記述する。この SIP ヘッダフィールドは MIME Content-Type（RFC 2183 [18]）を拡張する。

Content-Disposition ヘッダのいくつかの新しい「disposition-type」が SIP によって定義される。値「session」は、ボディパーツが、呼び出しまたは初期（呼び出し前）メディアのいずれかについてセッションを記述することを示す。値「render」は、ボディパーツがユーザーに表示またはそれ以外の方法でレンダリングされるべきであることを示す。「render」という値は、MIME ボディがメッセージ全体のレンダリングの一部として表示されるという含意を避けるために「inline」ではなく使用される（SIP メッセージの MIME ボディはユーザーに表示されないことが多いため）。後方互換性のため、Content-Disposition ヘッダフィールドが欠落している場合、サーバーは Content-Type application/sdp のボディを disposition「session」であると想定すべきであり（SHOULD）、他のコンテンツタイプは「render」であると想定すべきである。

disposition タイプ「icon」は、ボディパーツに、メッセージを受信したときにユーザーエージェントによって情報としてレンダリングされ得る、またはダイアログ中に持続的にレンダリングされ得る発信者または被呼者のアイコン的表現として適切な画像が含まれることを示す。値「alert」は、ボディパーツに、リクエスト（一般にダイアログを開始するリクエスト）の受信をユーザーに警告するためにユーザーエージェントによってレンダリングされるべき情報（音声クリップなど）が含まれることを示す。この警告ボディは、例えば 180 Ringing 暫定レスポンスが送信された後、電話呼び出しの着信音としてレンダリングされ得る。

コンテンツをユーザーにレンダリングする「disposition-type」を持つ任意の MIME ボディは、メッセージが適切に認証された場合にのみ処理されるべきである。

handling パラメータ（handling-param）は、UAS が、コンテンツタイプまたは disposition タイプを理解できないメッセージボディを受信した場合の反応を記述する。パラメータには「optional」および「required」という定義済みの値がある。handling パラメータが欠落している場合、「required」という値が想定されるべきである（SHOULD）。handling パラメータは RFC 3204 [19] で記述される。

このヘッダフィールドが欠落している場合、MIME タイプがデフォルトのコンテンツ disposition を決定する。それがない場合、「render」が想定される。

例：

  Content-Disposition: session

20.12 Content-Encoding

Content-Encoding ヘッダフィールドは「media-type」に対する修飾子として使用される。存在する場合、その値はエンティティボディにどの追加の content-coding が適用されたかを示し、したがって Content-Type ヘッダフィールドが参照する media-type を取得するためにどの復号機構を適用しなければならないかを示す。Content-Encoding は、主に、基礎となる media-type の同一性を失うことなくボディを圧縮できるようにするために使用される。

複数の符号化がエンティティボディに適用された場合、content-coding はそれらが適用された順序で列挙されなければならない（MUST）。

すべての content-coding 値は大文字小文字を区別しない。IANA は content-coding 値トークンのレジストリとして機能する。[H3.5] を content-coding の構文の定義について参照。

クライアントはリクエスト内のボディに content-coding を適用してもよい（MAY）。サーバーはレスポンス内のボディに content-coding を適用してもよい（MAY）。サーバーはリクエスト内の Accept-Encoding ヘッダフィールドに列挙された符号化のみを使用しなければならない（MUST）。

Content-Encoding ヘッダフィールドの省略形は e である。

例：

  Content-Encoding: gzip
  e: tar

20.13 Content-Language

[H14.12] を参照。例：

  Content-Language: fr

20.14 Content-Length

Content-Length ヘッダフィールドは、受信者に送信されるメッセージボディのサイズを、オクテットの 10 進数で示す。アプリケーションは、エンティティの media-type に関係なく、転送されるメッセージボディのサイズを示すためにこのフィールドを使用すべきである（SHOULD）。ストリームベースのプロトコル（TCP など）がトランスポートとして使用される場合、ヘッダフィールドは使用されなければならない（MUST）。

メッセージボディのサイズには、ヘッダフィールドとボディを分離する CRLF は含まれない。0 以上の任意の Content-Length は有効な値である。メッセージにボディが存在しない場合、Content-Length ヘッダフィールド値は 0 に設定されなければならない（MUST）。

  Content-Length を省略できることは、動的にレスポンスを生成する cgi 風スクリプトの作成を簡略化する。

ヘッダフィールドの省略形は l である。

例：

  Content-Length: 349
  l: 173

20.15 Content-Type

Content-Type ヘッダフィールドは、受信者に送信されるメッセージボディの media-type を示す。「media-type」要素は [H3.7] で定義される。ボディが空でない場合、Content-Type ヘッダフィールドは存在しなければならない（MUST）。ボディが空で、Content-Type ヘッダフィールドが存在する場合、それは特定のタイプのボディの長さがゼロ（例えば空の音声ファイル）であることを示す。

ヘッダフィールドの省略形は c である。

例：

  Content-Type: application/sdp
  c: text/html; charset=ISO-8859-4

20.16 CSeq

CSeq ヘッダフィールドは、リクエスト内に単一の 10 進シーケンス番号とリクエストメソッドを含む。シーケンス番号は 32 ビット符号なし整数として表現可能でなければならない（MUST）。CSeq のメソッド部分は大文字小文字を区別する。CSeq ヘッダフィールドは、ダイアログ内でトランザクションを順序付け、トランザクションを一意に識別する手段を提供し、新しいリクエストとリクエストの再送信を区別するために機能する。シーケンス番号およびリクエストメソッドが同一である場合、2 つの CSeq ヘッダフィールドは等しいとみなされる。例：

  CSeq: 4711 INVITE

20.17 Date

Date ヘッダフィールドは日付と時刻を含む。HTTP/1.1 と異なり、SIP は最新の RFC 1123 [20] 形式の日付のみをサポートする。[H3.3] と同様に、SIP は SIP-date のタイムゾーンを「GMT」に制限するが、RFC 1123 は任意のタイムゾーンを許可する。RFC 1123 の日付は大文字小文字を区別する。

Date ヘッダフィールドは、リクエストまたはレスポンスが最初に送信された時刻を反映する。

  Date ヘッダフィールドは、バックアップされたクロックのない単純な端末システムが現在時刻の概念を取得するために使用できる。ただし、GMT 形式では、クライアントは GMT からのオフセットを知っている必要がある。

例：

  Date: Sat, 13 Nov 2010 23:29:00 GMT

20.18 Error-Info

Error-Info ヘッダフィールドは、エラーステータスレスポンスに関する追加情報へのポインタを提供する。

  SIP UAC のユーザーインターフェース機能は、PC ソフトクライアント上のポップアップウィンドウおよび音声から、ゲートウェイ経由で接続された「ブラック」電話またはエンドポイント上の音声のみまでさまざまである。エラーを生成するサーバーに、詳細な理由句を持つエラーステータスコードを送信することと音声録音の再生とを選択させることを強制する代わりに、Error-Info ヘッダフィールドは両方を送信できるようにする。その後、UAC は発信者にレンダリングするエラーインジケータを選択できる。

UAC は、Error-Info ヘッダフィールド内の SIP または SIPS URI を、リダイレクト内の Contact であるかのように扱い、新しい INVITE を生成してもよく（MAY）、その結果、録音されたアナウンスメントセッションが確立される。非 SIP URI はユーザーにレンダリングされてもよい（MAY）。

例：

  SIP/2.0 404 The number you have dialed is not in service
  Error-Info: <sip:[email protected]>

20.19 Expires

Expires ヘッダフィールドは、メッセージ（またはコンテンツ）の期限が切れる相対時間を与える。

この意味の正確な内容はメソッドに依存する。

INVITE 内の有効期限は、招待から生じる可能性のある実際のセッションの継続時間には影響しない。ただし、セッション記述プロトコルはセッション継続時間に対する時間制限を表現する機能を提供し得る。

このフィールドの値は、リクエストの受信から測定される、0 から (2**32)-1 の範囲の整数秒数（10 進数）である。

例：

  Expires: 5

20.20 From

From ヘッダフィールドはリクエストの開始者を示す。これはダイアログの開始者とは異なる場合がある。被呼者から発信者へ送信されるリクエストは、From ヘッダフィールドに被呼者のアドレスを使用する。

オプションの「display-name」は人間のユーザーインターフェースによってレンダリングされることを意図している。クライアントの識別情報を非表示にする場合、システムは表示名「Anonymous」を使用すべきである（SHOULD）。「display-name」が空であっても、「addr-spec」にカンマ、疑問符、またはセミコロンが含まれる場合は「name-addr」形式を使用しなければならない（MUST）。構文の問題はセクション 7.3.1 で論じる。

2 つの From ヘッダフィールドは、それらの URI が一致し、かつそれらのパラメータが一致する場合に等価である。一方のヘッダフィールドに存在し、他方に存在しない拡張パラメータは、比較の目的上無視される。これは、表示名および山括弧の有無が一致に影響しないことを意味する。

表示名、URI、および URI パラメータ、およびヘッダフィールドパラメータを解析する規則についてはセクション 20.10 を参照。

From ヘッダフィールドの省略形は f である。

例：

  From: "A. G. Bell" <sip:[email protected]> ;tag=a48s
  From: sip:[email protected];tag=887s
  f: Anonymous <sip:[email protected]>;tag=hyh8

20.21 In-Reply-To

In-Reply-To ヘッダフィールドは、この呼び出しが参照または返信する Call-ID を列挙する。これらの Call-ID はクライアントによってキャッシュされ、返信呼び出しのこのヘッダフィールドに含まれていたかもしれない。

  これにより、自動呼び出し配信システムは返信呼び出しを最初の呼び出しの発信者にルーティングできる。また、被呼者が呼び出しをフィルタリングできるようにし、自分が発信した呼び出しの返信のみが受け入れられるようにする。このフィールドはリクエスト認証の代わりではない。

例：

  In-Reply-To: [email protected], [email protected]

20.22 Max-Forwards

Max-Forwards ヘッダフィールドは、任意の SIP メソッドとともに使用され、リクエストを次のダウンストリームサーバーに転送できるプロキシまたはゲートウェイの数を制限しなければならない（MUST）。これは、クライアントが途中で失敗またはループしていると思われるリクエストチェーンを追跡しようとする場合にも有用である。

Max-Forwards 値は 0–255 の範囲の整数であり、このリクエストメッセージを転送できる残り回数を示す。このカウントは、リクエストを転送する各サーバーによってデクリメントされる。推奨される初期値は 70 である。

このヘッダフィールドは、それ以外にループ検出を保証できない要素によって挿入されるべきである（SHOULD）。例えば、B2BUA は Max-Forwards ヘッダフィールドを挿入すべきである。

例：

  Max-Forwards: 6

20.23 Min-Expires

Min-Expires ヘッダフィールドは、そのサーバーによって管理されるソフトステート要素に対してサポートされる最小更新間隔を伝える。これにはレジストラによって格納される Contact ヘッダフィールドが含まれる。ヘッダフィールドは 0 から (2**32)-1 の 10 進整数秒数を含む。423（Interval Too Brief）レスポンスにおけるヘッダフィールドの使用は、セクション 10.2.8、10.3、および 21.4.17 で説明される。

例：

  Min-Expires: 60

20.24 MIME-Version

[H19.4.1] を参照。

例：

  MIME-Version: 1.0

20.25 Organization

Organization ヘッダフィールドは、リクエストまたはレスポンスを発行する SIP 要素が属する組織の名前を伝える。

  このフィールドはクライアントソフトウェアによって呼び出しをフィルタリングするために使用されてもよい（MAY）。

例：

  Organization: Boxes by Bob

20.26 Priority

Priority ヘッダフィールドは、クライアントによって認識されるリクエストの緊急度を示す。Priority ヘッダフィールドは、受信する人間またはそのエージェントに対して SIP リクエストが持つべき優先度を記述する。例えば、それは呼び出しのルーティングおよび受け入れの決定に組み込まれてもよい。これらの決定において、Priority ヘッダフィールドを含まないメッセージは、「normal」の優先度を指定したかのように扱われるべきである（SHOULD）。Priority ヘッダフィールドは、ルータ内のパケット転送優先度や PSTN ゲートウェイ内の回路へのアクセスなどの通信リソースの使用には影響しない。ヘッダフィールドは「non-urgent」、「normal」、「urgent」、および「emergency」の値を取り得るが、追加の値は他で定義されてもよい。「emergency」の値は、生命、肢体、または財産が差し迫った危険にある場合にのみ使用することが推奨される（RECOMMENDED）。それ以外の場合、このヘッダフィールドに対して定義されたセマンティクスはない。

  これらは「emergency」を追加した RFC 2076 [38] の値である。

例：

  Subject: A tornado is heading our way!
  Priority: emergency

または

  Subject: Weekend plans
  Priority: non-urgent

20.27 Proxy-Authenticate

Proxy-Authenticate ヘッダフィールド値は認証チャレンジを含む。

このヘッダフィールドの使用は [H14.33] で定義される。その使用法の詳細についてはセクション 22.3 を参照。

例：

  Proxy-Authenticate: Digest realm="atlanta.com",
   domain="sip:ss1.carrier.com", qop="auth",
   nonce="f84f1cec41e6cbe5aea9c8e88d359",
   opaque="", stale=FALSE, algorithm=MD5

20.28 Proxy-Authorization

Proxy-Authorization ヘッダフィールドは、クライアントに認証を要求するプロキシに対して、クライアント自身（またはそのユーザー）を識別させる。Proxy-Authorization フィールド値は、プロキシおよび/または要求されているリソースのレルムに対するユーザーエージェントの認証情報を含む資格情報からなる。

このヘッダフィールドの使用法の定義についてはセクション 22.3 を参照。

このヘッダフィールドは、Authorization とともに、複数のヘッダフィールド名に関する一般規則を破る。コンマ区切りのリストではないが、このヘッダフィールド名は複数回存在し得り、セクション 7.3.1 で説明される通常の規則を使用して単一のヘッダ行に統合されてはならない（MUST NOT）。

例：

Proxy-Authorization: Digest username="Alice", realm="atlanta.com", nonce="c60f3082ee1212b402a21831ae", response="245f23415f11432b3434341c022"

20.29 Proxy-Require

Proxy-Require ヘッダフィールドは、プロキシがこのリクエストを処理するためにサポートしなければならない（MUST）機能を指定するために、UAC によって使用される。Require ヘッダフィールド（セクション 20.32）は、UAC および UAS の双方によってサポートされる機能を指定するために使用される。

Require ヘッダフィールドのように、Proxy-Require ヘッダフィールドがサポートされない機能を含む場合、プロキシは 420（Bad Extension）レスポンスを返し、Unsupported ヘッダフィールドにサポートされない機能をリストしなければならない（MUST）。このヘッダフィールドは、信頼されたプロキシチェーンの外側に送信される可能性があるリクエストに使用すべきではない（SHOULD NOT）。このヘッダフィールドは、特に、プロキシに機能を実装するよう強制するためではなく、プロキシがサポートしている場合に機能が正しく動作するように、UA がそのリクエストを処理するためにプロキシが必要とする機能をプロキシに通知するために存在する。

例：

  Proxy-Require: foo

20.30 Record-Route

Record-Route ヘッダフィールドは、プロキシがリクエスト内に配置し、後続のダイアログ内のリクエストがそのプロキシを通過することを強制するために使用する。

Record-Route ヘッダフィールドは、ダイアログ ID には寄与しない（セクション 12）。ただし、Record-Route ヘッダフィールドに含まれる URI は、ダイアログ内で後続のリクエストが送信されるルートセットを確立するために使用される。

UA が Record-Route 値のいずれかの URI から、または Route ヘッダフィールド内に現れる URI から要素を削除することは許可されない。Record-Route ヘッダフィールドは、リクエストを処理するプロキシによって追加されてもよく（MAY）、セクション 16.6 の項目 5 で論じるルーティング判断に基づいて他のプロキシを指すこともできる。pp パラメータ（セクション 19.1.1）を含まない URI は、RFC 2543 要素とのルーティング互換性のために lr パラメータを含むべきである（SHOULD）。

ダイアログ内のリクエストをルーティングするために Record-Route ヘッダフィールドがどのように使用されるかの詳細はセクション 12 を参照。

例：

  Record-Route: <sip:server10.biloxi.com;lr>,
                 <sip:bigbox3.site3.atlanta.com;lr>

20.31 Reply-To

Reply-To ヘッダフィールドは、リクエストメッセージ内に含まれる場合、要求されたメソッド（例えば INVITE）への応答を送信する先の SIP または SIPS URI を含む。この URI が存在しない場合、応答は From または Contact ヘッダフィールド値によって提供されるアドレスに送信される。場合によっては、呼び出しは応答先のアドレスとは異なるアドレスから開始される。このヘッダフィールドは、宛先アドレスから独立して応答先を指定できる。

  このフィールドは、受信者の複数のアドレス間で応答をルーティングするために使用されてもよい（MAY）。たとえば、受信者は、呼び出しは仕事用の SIP 電話に着信するが、応答は携帯電話に送信されることを望むかもしれない。

例：

  Reply-To: <sip:[email protected]>

20.32 Require

Require ヘッダフィールドは、UAC がリクエストを処理するために UAS（およびプロキシ）がサポートする必要のある機能を指定するために使用する。受信したリクエストの Require ヘッダフィールドにリストされているサポートされていない機能をプロキシまたは UAS が理解できない場合、その要素は、Unsupported ヘッダフィールド内にサポートされていない機能を含む 420（Bad Extension）レスポンス（セクション 20.40）を返さなければならない（MUST）。

これに対して、Require ヘッダフィールドにリストされていない機能は、サポートされていなくても、その機能がリクエストのセマンティクスに不可欠なものであるならば、UAS がリクエストを適切に処理できたかもしれない。

機能は、SIP メッセージのフォーマット、またはセッション記述内のメディアタイプ、またはパラメータ、またはその他の機能のサポートとして現れてもよい。Require ヘッダフィールドのオプションタグは、セクション 19.2 で説明されるように、いくつかのタグ付き機能を参照する。一部の機能はプロキシに限定される（例えば「re-route」）。これらは Proxy-Require ヘッダフィールド（セクション 20.29）を使用して指定される。

Require ヘッダフィールドがリクエストメッセージに含まれる場合、それはレスポンスメッセージにコピーされなければならない（MUST）。

この仕様の実装は、Require ヘッダフィールドを正しく生成するように細心の注意を払うべきである（MUST）。

  Require ヘッダフィールドは、多くの実装が、互いに通信したいが、相反する拡張をサポートしている状況をもたらす。正しく実装された拡張ネゴシエーションは困難である。UA がサポートする機能を Require ヘッダフィールドに配置すると、それをサポートしない相手がリクエストを拒否する。したがって、Require ヘッダフィールドは、UA が確実にサポートされると合理的に信じる機能に対してのみ使用されるべきである（SHOULD）。他のすべての機能は、Supported ヘッダフィールド（セクション 20.37）で指定すべきである（SHOULD）。Require ヘッダフィールド用に使用可能なオプションタグは、標準トラック RFC でのみ定義される。これは、数少ない標準化された機能（および特にそれらが UAS および UAC の両方に影響を与えるもの）だけがオプションタグを取得できるようにするためである。オプションタグの厳しい審査プロセスは、Require ヘッダフィールドが使いやすく普及するのを防ぐ。

例：

  Require: 100rel

20.33 Retry-After

Retry-After ヘッダフィールドは、クライアントがリクエストを再試行できるようになるまでの期間をサーバーが示すことを可能にする。現在の時刻からの相対秒数、またはオプションとして SIP 日付値を含み得る。リクエストを拒否するレスポンス（例えば 500、503、または 600）に存在する場合、値はサーバーがリクエストを受け入れるか、または呼び出しを試行できるようになるまでの期間を示す。503（Service Unavailable）レスポンスに存在する場合、このヘッダフィールドは、発生した過負荷が終了すると予想される時刻を示す。

retry-after 値が 0 より大きい場合、クライアントはリクエストを再試行する前にその期間待機しなければならない（MUST）。この値が 0 の場合、クライアントはリクエストを直ちに再試行してもよい（MAY）。

オプションの「comment」パラメータは人間が読めるテキストを含む。オプションの「duration」パラメータは、呼び出しを試行できるとサーバーが判断した後も、呼び出しを試行すべきでない期間（秒）を表す。

例：

  Retry-After: 18000;duration=3600
  Retry-After: 120;duration=3600

20.34 Route

Route ヘッダフィールドは、UAC がセッションのルーティングに使用するプリフ�ローを強制するために存在する。プロキシは、受信したリクエスト内のルートセットを満たすことにも責任を負う。セクション 8.1.1.1 を参照。

例：

  Route: <sip:bigbox3.site3.atlanta.com;lr>,
    <sip:server10.biloxi.com;lr>

20.35 Server

Server ヘッダフィールドは、応答を処理するサーバーに関する情報を含み、ユーザーエージェントサーバーソフトウェアに関する情報を含んでもよい（MAY）。類似の HTTP ヘッダフィールドと同様に、このヘッダフィールドはセキュリティ上の理由から含めるのを省略できる。

Server ヘッダフィールドの使用は、HTTP/1.1 の [H14.38] で定義されるものと同一の規則に従う。

例：

  Server: HomeServer v2

20.36 Subject

Subject ヘッダフィールドは、呼び出しの性質またはトピックの短い記述を提供する。

User-Agent の「Subject」行の使用は、RFC 822 [39] で定義されるものと同一のセマンティクスを持つ。

例：

  Subject: Need more boxes

20.37 Supported

Supported ヘッダフィールドは、UAC または UAS がサポートする機能の集合をリストする。多くの場合、機能はオプションタグ（セクション 19.2）としてリストされる。

Supported ヘッダフィールドが UAC によって送信された場合、UAS は、サポートされている機能を Supported ヘッダフィールドで UAC に応答してもよい（MAY）。

Supported ヘッダフィールドが UAS によって送信された場合、UAC はそれを無視してもよい（MAY）。

Require と Supported の両方が 2xx レスポンスに含まれてよい（MAY）。

Supported ヘッダフィールドがリクエストメッセージに含まれる場合、それはレスポンスメッセージにコピーされなければならない（MUST）。

この仕様の実装は、Supported ヘッダフィールドを正しく生成するように細心の注意を払うべきである（MUST）。

  Require ヘッダフィールドの議論で説明されるように、UA は、標準化されたオプションタグのみによって識別される機能を Require ヘッダフィールド上に配置すべきである（SHOULD）。Require ヘッダフィールドを使用して、標準化されていない、または会社固有の拡張を強制しようとすると、相互運用性が低下する可能性がある。したがって、サポートされているすべてのオプションは Supported ヘッダフィールドにリストすべきである（SHOULD）。Require ヘッダフィールド用に使用可能なオプションタグは、標準トラック RFC でのみ定義される。これは、数少ない標準化された機能（および特にそれらが UAS および UAC の両方に影響を与えるもの）だけがオプションタグを取得できるようにするためである。オプションタグの厳しい審査プロセスは、Require ヘッダフィールドが使いやすく普及するのを防ぐ。

例：

  Supported: 100rel

20.38 Timestamp

Timestamp ヘッダフィールドは、UAC からのリクエストが生成された時刻を反映する。クライアントは、レスポンスを待機している時間を計算するためにサーバーに戻された時刻を使用できる。

例：

  Timestamp: 54

20.39 To

To ヘッダフィールドは、最初にリクエストが宛てられた第 2 パーティ（または論理的に宛てられたリソース）を指定する。このヘッダフィールドは、一般的に、UAS がリクエストを受け入れた後に、招待されたユーザーまたはリソースを指定する。

To ヘッダフィールドは、リクエストおよびレスポンス内のすべての SIP メッセージに含まれなければならない（MUST）。

To ヘッダフィールドが UAS によって生成される場合、UAS は、ダイアログ ID の一部として機能するよう、To ヘッダフィールドに「tag」パラメータを追加しなければならない（MUST）。

UAS がなんらかの理由でリクエストを拒否する場合でも、To ヘッダフィールドにタグを追加してもよい（MAY）。

タグの生成の詳細はセクション 19.3 を参照。

2 つの To ヘッダフィールドは、それらの URI が一致し、かつパラメータが一致する場合に等価である。一方のヘッダフィールドに存在し、他方に存在しない拡張パラメータは、比較目的上無視される。これは、表示名および山括弧の有無が一致に影響しないことを意味する。

表示名、URI、および URI パラメータ、ならびにヘッダフィールドパラメータを解析する規則についてはセクション 20.10 を参照。

To ヘッダフィールドの省略形は t である。

例：

  To: "A. G. Bell" <sip:[email protected]>;tag=a6c85cf

20.40 Unsupported

Unsupported ヘッダフィールドは、サーバーがサポートしていない機能をリストする。このヘッダフィールドは、Require ヘッダフィールド（セクション 20.32）を含むリクエストをサーバーが拒否した場合に生成される。

例：

  Unsupported: foo

20.41 User-Agent

User-Agent ヘッダフィールドは、リクエストを開始するユーザーエージェントに関する情報を含む。類似の HTTP ヘッダフィールドと同様に、このヘッダフィールドはセキュリティ上の理由から含めるのを省略できる。

例：

  User-Agent: Softphone Release 1.0

20.42 Via

Via ヘッダフィールドは、リクエストを送信するために使用された転送プロトコル、およびそのリクエストがネットワークを通じて到達した順序でそれを運んだエージェント（プロキシ、フォワーダ、およびユーザーエージェント）のアドレスを示す。リクエストおよび応答内の Via ヘッダフィールドは、リクエストが送信されたルートを追跡し、さらに応答を送信するためのループを防ぐ。

Via ヘッダフィールドは、アプリケーションがリクエストを送信するために使用するプロトコルをリストし、アプリケーション間でメッセージを転送するために使用されるトランスポートプロトコルと混同されてはならない。たとえば、SIP メッセージは UDP 上でアプリケーション間で転送されてもよい（MAY）が、SIP アプリケーションは TCP 上でメッセージを送信するために使用されるプロトコルを示すために SIP/2.0/TCP を使用する。

Via ヘッダフィールドの一部としてリストされるアドレスは、応答が送信されるアドレスである。責任ある場所（通常は最も近いアップストリーム要素）は、プロキシがどこから応答を受信すべきかを判断するために、受信した Via ヘッダフィールドに「received」パラメータを追加してもよい（MAY）。

Via ヘッダフィールドの「received」および「rport」パラメータの詳細は、それぞれセクション 18.2.1 および 18.2.2 を参照。

応答を生成する UA またはプロキシは、メッセージを生成するために使用されたプロトコルをリストする Via ヘッダフィールド値を含める。この値は、応答を送信するために使用されるプロトコルと混同されてはならない。リクエストと同様に、Via ヘッダフィールド値は複数の要素を通過し得る（例えば、応答がプロキシチェーンを通じて戻される場合）。

Via ヘッダフィールド値は、リクエストを送信するために使用されたプロトコル、ブランチ識別子、および送信アプリケーションのアドレスを含む。ブランチパラメータは、トランザクションを識別するために使用される。最も近いアップストリーム要素（および場合によってはプロキシ）が応答をルーティングするために追加する「received」パラメータを含んでもよい（MAY）。ブランチパラメータの値は要素によって選択されるが、次の要件を満たさなければならない（MUST）。これは、アプリケーションが、リクエスト、リクエストを送信するために使用されるトランスポート、およびリクエストを送信するために使用されるトランスポートインスタンスの一意の（部分的には大文字小文字を区別しない）アドレスを区別することを可能にする。

  o ブランチパラメータ値は、要素のホスト名または識別情報を含まなければならない（MUST）。

  o  ブランチパラメータ値は、要素のアドレス、ポート、およびトランスポートプロトコルを変更せずに変更されるメッセージのリクエストの一部の作成または変更を反映するために変更されてもよい（MAY）。

「branch」パラメータの詳細はセクション 17 を参照。

このヘッダフィールドの省略形は V である。

例：

  Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776sgdkse
  Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bK77ef4z'