8. 一般的なユーザーエージェントの動作 (General User Agent Behavior)
8 一般的なユーザーエージェントの動作 (General User Agent Behavior)
ユーザーエージェント (user agent) はエンドシステムを表します。これは、リクエストを生成する user agent client (UAC) と、それらに応答する user agent server (UAS) の両方を含みます。UAC は、何らかの外部刺激 (ユーザーがボタンをクリックする、または PSTN 回線の信号) に基づいてリクエストを生成し、レスポンスを処理することができます。UAS は、リクエストを受信し、ユーザー入力、外部刺激、プログラム実行の結果、またはその他のメカニズムに基づいてレスポンスを生成することができます。
UAC がリクエストを送信すると、そのリクエストはいくつかの proxy server を経由し、それらがリクエストを UAS に転送します。UAS がレスポンスを生成すると、そのレスポンスは UAC に向けて転送されます。
UAC と UAS の手順は、2 つの要因に強く依存します。第 1 に、リクエストまたはレスポンスが dialog の内か外か、第 2 に、リクエストの method です。dialog については Section 12 で詳しく議論します。これらはユーザーエージェント間の peer-to-peer 関係を表し、INVITE などの特定の SIP method によって確立されます。
この節では、dialog 外のリクエストを処理するときの、method に依存しない UAC および UAS の動作に関する規則について議論します。これにはもちろん、それ自体が dialog を確立するリクエストが含まれます。
dialog 外のリクエストとレスポンスのセキュリティ手順は Section 26 で説明されています。具体的には、UAS と UAC が相互に認証するためのメカニズムが存在します。S/MIME を使用した body の暗号化による、限られたプライバシー機能のセットもサポートされています。
8.1 UAC の動作 (UAC Behavior)
この節は、dialog 外の UAC の動作を扱います。
8.1.1 リクエストの生成 (Generating the Request)
UAC によって作成された有効な SIP リクエストは、最低限、以下の header field を含まなければなりません (MUST)。To、From、CSeq、Call-ID、Max-Forwards、および Via です。これらすべての header field はすべての SIP リクエストで必須です。これらの 6 つの header field は SIP メッセージの基本的な構成要素であり、メッセージのアドレッシング、レスポンスのルーティング、メッセージ伝播の制限、メッセージの順序付け、およびトランザクションの一意識別を含む、ほとんどの重要なメッセージルーティングサービスを共同で提供するためです。これらの header field は、method、Request-URI、および SIP version を含む必須の request line に加えて必要です。
dialog 外で送信されるリクエストの例には、セッションを確立するための INVITE (Section 13) や、能力を照会するための OPTIONS (Section 11) が含まれます。
8.1.1.1 Request-URI
メッセージの初期 Request-URI は、To field 内の URI の値に設定すべきです (SHOULD)。注目すべき例外は REGISTER method です。REGISTER の Request-URI を設定するための動作は Section 10 にあります。プライバシー上の理由または便宜のために、これらの field を同じ値に設定しないことも望ましくない場合があります (特に、発信 UA が Request-URI が転送中に変更されると予想する場合)。
いくつかの特殊な状況では、事前に存在する route set がメッセージの Request-URI に影響を与えることがあります。事前に存在する route set (pre-existing route set) とは、UAC が dialog 外の発信リクエストを送信するサーバーのチェーンを識別する、順序付けられた URI の集合です。一般的に、これらはユーザーまたはサービスプロバイダーによって手動で、または何らかの非 SIP メカニズムを通じて UA 上に設定されます。プロバイダーが outbound proxy を使用して UA を設定したい場合、単一の URI (outbound proxy の URI) を持つ事前に存在する route set を提供することによってこれを行うことが推奨されます (RECOMMENDED)。
事前に存在する route set が存在する場合、Section 12.2.1.1 で詳述された Request-URI と Route header field を投入する手順に従わなければなりません (MUST)。(dialog が存在しなくても、) 望ましい Request-URI を remote target URI として使用します。
8.1.1.2 To
To header field は、まず第一に、リクエストの望ましい「論理的 (logical)」受信者、またはこのリクエストのターゲットであるユーザーまたはリソースの address-of-record を指定します。これは最終的な受信者である場合とそうでない場合があります。To header field には SIP または SIPS URI が含まれてもかまいません (MAY) が、適切な場合は他の URI scheme (たとえば tel URL (RFC 2806 [9])) を利用してもかまいません (MAY)。すべての SIP 実装は SIP URI scheme をサポートしなければなります (MUST)。TLS をサポートする実装はすべて SIPS URI scheme をサポートしなければなります (MUST)。To header field は display name を許可します。
UAC は、特定のリクエストに対して To header field をどのように投入するかをいくつかの方法で学習できます。通常、ユーザーは人間のインターフェースを通じて To header field を提案し、おそらく URI を手動で入力するか、何らかのアドレス帳から選択します。しばしば、ユーザーは完全な URI を入力するのではなく、数字や文字の文字列 (たとえば "bob") を入力します。この入力をどのように解釈するかは UA の裁量です。この文字列を使用して SIP URI の user part を形成することは、UA がその名前を SIP URI 内の at-sign の右側 (RHS) のドメインで解決したいことを意味します (たとえば sip:[email protected])。この文字列を使用して SIPS URI の user part を形成することは、UA が安全に通信したいこと、およびその名前が at-sign の RHS のドメインで解決されることを意味します。RHS はしばしばリクエスト者の home domain であり、home domain が発信リクエストを処理できるようにします。これは、"speed dial" のように home domain 内で user part を解釈することを必要とする機能に役立ちます。UA がユーザーが入力した電話番号を解釈すべきドメインを指定したくない場合、tel URL を使用できます。むしろ、リクエストが通過する各ドメインにその機会が与えられます。たとえば、空港のユーザーがログインし、空港の outbound proxy を通じてリクエストを送信する可能性があります。彼らが "411" (これは米国のローカル案内サービスの電話番号です) を入力した場合、それは空港の outbound proxy によって解釈および処理される必要があり、ユーザーの home domain ではありません。この場合、tel:411 が正しい選択です。
dialog 外のリクエストは To tag を含んではなりません (MUST NOT)。リクエストの To field 内の tag は dialog のピアを識別します。dialog が確立されていないため、tag は存在しません。
To header field の詳細については、Section 20.39 を参照してください。以下は有効な To header field の例です。
To: Carol `<sip:[email protected]>`
8.1.1.3 From
From header field は、リクエストの発信者の論理的アイデンティティ、おそらくユーザーの address-of-record を示します。To header field と同様に、これは URI と、オプションで display name を含みます。SIP 要素はこれを使用して、リクエストに適用する処理規則 (自動通話拒否など) を決定します。そのため、From URI に IP アドレスや UA が実行されているホストの FQDN を含めないことが非常に重要です。これらは論理名ではないためです。
From header field は display name を許可します。クライアントのアイデンティティを隠したままにする場合、UAC は display name "Anonymous" と、それ以外は無意味だが構文的に正しい URI (たとえば sip:[email protected]) を使用すべきです (SHOULD)。
通常、特定の UA によって生成されたリクエスト内の From header field を投入する値は、ユーザーまたはユーザーのローカルドメインの管理者によって事前に設定されます。特定の UA が複数のユーザーによって使用される場合、プロファイルされたユーザーのアイデンティティに対応する URI を含む切り替え可能なプロファイルを持つ場合があります。リクエストの受信者は、From header field が主張する者が実際に彼らであることを確認するために、リクエストの発信者を認証できます (認証の詳細については Section 22 を参照)。
From field は、UAC によって選択された新しい "tag" パラメータを含まなければなります (MUST)。tag の選択に関する詳細は Section 19.3 を参照してください。
From header field の詳細については、Section 20.20 を参照してください。例：
From: "Bob" `<sips:[email protected]>` ;tag=a48s
From: sip:[email protected];tag=887s
From: Anonymous `<sip:[email protected]>`;tag=hyh8
8.1.1.4 Call-ID
Call-ID header field は、一連のメッセージをまとめるための一意の識別子として機能します。dialog 内のいずれかの UA によって送信されたすべてのリクエストとレスポンスで、これは同じでなければなります (MUST)。UA の各登録では、同じであるべきです (SHOULD)。
dialog 外のいずれかの UAC によって作成された新しいリクエストでは、Call-ID header field は、特定の method の動作によって上書きされない限り、UAC によって空間および時間を通じてグローバルに一意の識別子として選択されなければなります (MUST)。すべての SIP UA は、それらが生成する Call-ID header field が他の UA によって誤って生成されることがないことを保証する手段を持たなければなります。特定の失敗レスポンスがリクエストの修正を求める場合 (たとえば認証 challenge)、これらの再試行されたリクエストは新しいリクエストとはみなされず、したがって新しい Call-ID header field を必要としないことに注意してください。Section 8.1.3.5 を参照してください。
Call-ID の生成に暗号的にランダムな識別子 (cryptographically random identifiers) (RFC 1750 [12]) を使用することが推奨されます (RECOMMENDED)。実装は "localid@host" という形式を使用してもかまいません (MAY)。Call-ID は大文字小文字を区別し、単にバイトごとに比較されます。
暗号的にランダムな識別子を使用すると、セッションハイジャックに対するある程度の保護が提供され、意図しない Call-ID の衝突の可能性を減らします。
Call-ID header field value をリクエスト用に選択するためのプロビジョニングや人間のインターフェースは必要ありません。
Call-ID header field の詳細については、Section 20.8 を参照してください。
例：
Call-ID: [email protected]
8.1.1.5 CSeq
CSeq header field は、トランザクションを識別および順序付けする手段として機能します。これは sequence number と method で構成されます。method はリクエストの method と一致しなければなります (MUST)。dialog 外の非 REGISTER リクエストの場合、sequence number value は任意です。sequence number value は 32 ビット符号なし整数として表現可能でなければならず (MUST)、2**31 未でなければなりません (MUST)。上記のガイドラインに従う限り、クライアントは任意のメカニズムを使用して CSeq header field value を選択してもかまいません (MAY)。
dialog 内のリクエストの CSeq の構築については、Section 12.2.1.1 で議論します。
例：
CSeq: 4711 INVITE
8.1.1.6 Max-Forwards
Max-Forwards header field は、リクエストが宛先に到達するまでに経由できるホップ数を制限するために機能します。これは整数で構成され、各ホップで 1 減算されます。Max-Forwards 値がリクエストが宛先に到達する前に 0 に達した場合、483 (Too Many Hops) エラーレスポンスで拒否されます。
UAC は、それが発信する各リクエストに Max-Forwards header field を挿入しなければなります (MUST)。その値は 70 であるべきです (SHOULD)。この数値は、loop がない場合にリクエストがどの SIP ネットワークでもドロップされないことを保証するのに十分大きく、かつ loop が発生したときに proxy リソースを消費しすぎないように十分小さくなるように選択されました。より低い値は注意して使用すべきであり、UA がトポロジを知っているネットワークでのみ使用してください。
8.1.1.7 Via
Via header field は、トランザクションに使用されるトランスポートを示し、レスポンスを送信する場所を識別します。Via header field value は、次のホップに到達するために使用されるトランスポートが選択された後でのみ追加されます (これには [4] の手順の使用が含まれる場合があります)。
UAC がリクエストを作成するとき、そのリクエストに Via を挿入しなければなります (MUST)。header field 内の protocol name と protocol version は、それぞれ SIP と 2.0 でなければなります (MUST)。Via header field value は branch パラメータを含まなければなります (MUST)。このパラメータは、そのリクエストによって作成されたトランザクションを識別するために使用されます。このパラメータはクライアントとサーバーの両方によって使用されます。
branch パラメータ値は、UA によって送信されるすべてのリクエストについて空間および時間を通じて一意でなければなります (MUST)。この規則の例外は、CANCEL と非 2xx レスポンスに対する ACK です。以下で説明するように、CANCEL リクエストは、それがキャンセルするリクエストと同じ branch パラメータ値を持ちます。Section 17.1.1.3 で説明したように、非 2xx レスポンスに対する ACK も、それが確認する INVITE のレスポンスと同じ branch ID を持ちます。
transaction ID としての使用を容易にするための branch ID パラメータの一意性プロパティは、RFC 2543 の一部ではありませんでした。
この仕様に準拠する要素によって挿入される branch ID は、常に文字 "z9hG4bK" で始まらなければなりません (MUST)。これらの 7 文字は magic cookie として使用されます (7 は、古い RFC 2543 実装がそのような値を選択しないことを保証するのに十分であると考えられます)。これにより、リクエストを受信するサーバーは、branch ID がこの仕様で説明された方法 (つまり、グローバルに一意) で構築されたと判断できます。この要件を超えて、branch token の正確な形式は実装定義です。
Via header の maddr、ttl、および sent-by コンポーネントは、リクエストがトランスポート層によって処理されるときに設定されます (Section 18)。
proxy の Via 処理は、Section 16.6 Item 8 および Section 16.7 Item 3 で説明されています。
8.1.1.8 Contact
Contact header field は、後続のリクエストでその特定の UA インスタンスに連絡するために使用できる SIP または SIPS URI を提供します。dialog の確立をもたらす可能性のあるリクエストでは、Contact header field が存在し、正確に 1 つの SIP または SIPS URI を含まなければなります (MUST)。この仕様で定義された method の場合、それには INVITE リクエストのみが含まれます。これらのリクエストの場合、Contact のスコープはグローバルです。つまり、Contact header field value には、UA がリクエストを受信したい URI が含まれ、この URI は dialog 外の後続のリクエストで使用された場合でも有効でなければなります (MUST)。
Request-URI またはトップの Route header field value に SIPS URI が含まれている場合、Contact header field にも SIPS URI が含まれていなければなります (MUST)。
Contact header field の詳細については、Section 20.10 を参照してください。
8.1.1.9 Supported および Require
UAC が、サーバーによってレスポンスに適用できる SIP 拡張をサポートしている場合、UAC はそれらの拡張の option tag (Section 19.2) をリストした Supported header field をリクエストに含めるべきです (SHOULD)。
リストされた option tag は、standards-track RFC で定義された拡張のみを参照しなければなります (MUST)。これは、サーバーが、サービスを受けるためにクライアントに非標準のベンダー定義機能の実装を強制するのを防ぐためです。experimental および informational RFC によって定義された拡張は、リクエストの Supported header field での使用から明示的に除外されます。なぜなら、それらもベンダー定義拡張を文書化するために頻繁に使用されるためです。
UAC が、UAS にリクエストを処理するために UAC がリクエストに適用する拡張を理解することを強く要求したい場合、その拡張の option tag をリストした Require header field をリクエストに挿入しなければなります (MUST)。UAC が拡張をリクエストに適用し、通過するすべての proxy にその拡張を理解することを強く要求したい場合、その拡張の option tag をリストした Proxy-Require header field をリクエストに挿入しなければなります (MUST)。
Supported header field と同様に、Require および Proxy-Require header field の option tag は、standards-track RFC で定義された拡張のみを参照しなければなります (MUST)。
8.1.1.10 追加のメッセージコンポーネント (Additional Message Components)
新しいリクエストが作成され、上記の header field が適切に構築された後、追加のオプションの header field および method に固有の header field が追加されます。
SIP リクエストは MIME エンコードされた message-body を含んでもかまいません (MAY)。リクエストに含まれる body の種類に関係なく、body の内容を特徴付けるために特定の header field を作成する必要があります。これらの header field の詳細については、Section 20.11 から 20.15 を参照してください。
8.1.2 リクエストの送信 (Sending the Request)
リクエストの宛先が次に計算されます。ローカルポリシーで別途指定されない限り、宛先は [4] で説明された DNS 手順を次のように適用して決定されなければなります (MUST)。route set の最初の要素が strict router を示していた場合 (Section 12.2.1.1 で説明された方法でリクエストを形成する結果となる)、手順はリクエストの Request-URI に適用されなければなります (MUST)。それ以外の場合、手順はリクエストの最初の Route header field value (存在する場合)、または Route header field が存在しない場合はリクエストの Request-URI に適用されます。これらの手順は、試行する順序付けられた address、port、および transport の集合をもたらします。[4] の手順への入力としてどの URI が使用されるかに関係なく、Request-URI が SIPS resource を指定する場合、UAC は入力 URI が SIPS URI であるかのように [4] の手順に従わなければなります (MUST)。
ローカルポリシーは、試行する代替の宛先の集合を指定してもかまいません (MAY)。Request-URI に SIPS URI が含まれている場合、任意の代替宛先は TLS を使用して接触されなければなります (MUST)。それ以外については、リクエストに Route header field が含まれていない場合、代替宛先に制限はありません。これは、事前に存在する route set を必要とせずに outbound proxy を指定するための簡単な代替手段を提供します。ただし、この outbound proxy を設定するアプローチは推奨されません (NOT RECOMMENDED)。代わりに、単一の URI を持つ事前に存在する route set を使用すべきです (SHOULD)。リクエストに Route header field が含まれている場合、リクエストはその最上位の値から派生した場所に送信されるべきです (SHOULD) が、UA が本文書で指定された Route および Request-URI ポリシー (RFC 2543 のポリシーではなく) を確実に守ることができると確信する任意のサーバーに送信されてもかまいません (MAY)。特に、outbound proxy で設定された UAC は、すべてのメッセージを outbound proxy に送信するというポリシーを採用するのではなく、最初の Route header field value で示された場所にリクエストを送信しようとするべきです (SHOULD)。
これにより、Record-Route header field value を追加しない outbound proxy が、後続のリクエストのパスから外れることを保証します。最初の Route URI を解決できないエンドポイントが、そのタスクを outbound proxy に委任できるようにします。
UAC は [4] で状態を持つ要素に対して定義された手順に従い (SHOULD)、サーバーに接触するまで各 address を試行すべきです。各試行は新しいトランザクションを構成するため、それぞれが新しい branch パラメータを持つ異なる topmost Via header field value を運びます。さらに、Via header field の transport 値は、ターゲットサーバーに対して決定されたトランスポートに設定されます。
8.1.3 レスポンスの処理 (Processing Responses)
レスポンスは最初にトランスポート層によって処理され、次にトランザクション層に渡されます。トランザクション層はその処理を実行し、次にレスポンスを TU に渡します。TU でのレスポンス処理の大部分は method 固有です。ただし、method に依存しない一般的な動作がいくつかあります。
8.1.3.1 トランザクション層エラー (Transaction Layer Errors)
場合によっては、トランザクション層から返されるレスポンスは SIP メッセージではなく、トランザクション層エラーです。トランザクション層から timeout error を受信した場合、408 (Request Timeout) ステータスコードを受信したものとして扱わなければなります (MUST)。トランスポート層から致命的なトランスポートエラー (一般に、UDP の致命的な ICMP エラーまたは TCP の接続失敗による) が報告された場合、その条件は 503 (Service Unavailable) ステータスコードとして扱わなければなります (MUST)。
8.1.3.2 認識されないレスポンス (Unrecognized Responses)
UAC は、認識できない最終レスポンスを、そのクラスの x00 レスポンスコードと同等であると扱わなければなります (MUST)。また、すべてのクラスの x00 レスポンスコードを処理できる必要があります (MUST)。たとえば、UAC が認識できないレスポンスコード 431 を受信した場合、自分のリクエストに何らかの問題があったと安全に想定し、400 (Bad Request) レスポンスコードを受信したかのようにレスポンスを扱うことができます。UAC は、認識できない 100 以外の暫定レスポンスを 183 (Session Progress) として扱わなければなります (MUST)。UAC は 100 および 183 レスポンスを処理できる必要があります (MUST)。
8.1.3.3 Vias
レスポンスに複数の Via header field value が存在する場合、UAC はメッセージを破棄すべきです (SHOULD)。
リクエストの発信者より前に追加の Via header field value が存在することは、メッセージが誤ってルーティングされたか、おそらく破損したことを示唆します。
8.1.3.4 3xx レスポンスの処理 (Processing 3xx Responses)
リダイレクションレスポンス (たとえば 301 レスポンスステータスコード) を受信すると、クライアントは Contact header field 内の URI を使用して、リダイレクトされたリクエストに基づいて 1 つ以上の新しいリクエストを作成すべきです (SHOULD)。このプロセスは、Section 16.5 および 16.6 で詳述されている 3xx クラスレスポンスに対する proxy の再帰 (recursion) に似ています。クライアントは、正確に 1 つの URI (元のリクエストの Request-URI) を含む初期 target set から始まります。クライアントがそのリクエストに対する 3xx クラスレスポンスに基づいて新しいリクエストを作成したい場合、試行する URI を target set に配置します。この仕様の制限に従って、クライアントはどの Contact URI を target set に配置するかを選択できます。proxy の再帰と同様に、3xx クラスレスポンスを処理するクライアントは、任意の given URI を target set に複数回追加してはなりません (MUST NOT)。元のリクエストの Request-URI に SIPS URI があった場合、クライアントは非 SIPS URI への再帰を選択してもかまいません (MAY) が、安全でない URI へのリダイレクトをユーザーに通知すべきです (SHOULD)。
新しいリクエスト自体が、元の URI を contact として含む 3xx レスポンスを受信する可能性があります。2 つの場所は互いにリダイレクトするように設定できます。任意の given URI を target set に 1 回だけ配置すると、無限のリダイレクション loop を防ぎます。
target set が大きくなるにつれて、クライアントはその中の URI に対して任意の順序で新しいリクエストを生成してもかまいません (MAY)。一般的なメカニズムは、Contact header field value の "q" パラメータ値によって集合を順序付けることです。URI へのリクエストは、直列または並列に生成されてもかまいません (MAY)。1 つのアプローチは、減少する q 値のグループを直列に処理し、各 q 値グループ内の URI を並列に処理することです。別のアプローチは、等しい q 値の contact 間で任意に選択しながら、減少する q 値の順序でのみ直列処理を行うことです。
リスト内のアドレスへの接触が失敗 (次の段落で定義) した場合、要素はリストの次のアドレスに移動し、リストが使い果たされるまで続きます。リストが使い果たされた場合、リクエストは失敗です。
失敗は、失敗レスポンスコード (399 より大きいコード) によって検出されるべきです (SHOULD)。ネットワークエラーの場合、client transaction はトランザクション層の失敗を transaction user に報告します。一部のレスポンスコード (8.1.3.5 で詳述) は、リクエストを再試行できることを示していることに注意してください。再試行されたリクエストは失敗とはみなされません。
特定の contact address の失敗を受信した場合、クライアントは次の contact address を試行すべきです (SHOULD)。これには、新しいリクエストを配信するための新しい client transaction の作成が含まれます。
3xx レスポンス内の contact address に基づいてリクエストを作成するために、UAC は target set 内の URI 全体を Request-URI にコピーしなければなります (MUST)。ただし、"method-param" および "header" URI パラメータを除きます (これらのパラメータの定義については Section 19.1.1 を参照)。新しいリクエストの header field value を作成するために "header" パラメータを使用し、Section 19.1.5 のガイドラインに従って、リダイレクトされたリクエストに関連付けられた header field value を上書きします。
場合によっては、contact address で通信された header field が、代わりに元のリダイレクトされたリクエストの既存の request header field に追加されることに注意してください。一般に、header field が値のカンマ区切りリストを受け入れる場合、新しい header field value は元のリダイレクトされたリクエストの既存の値に追加されてもかまいません (MAY)。header field が複数の値を受け入れない場合、元のリダイレクトされたリクエストの値は、contact address で通信された header field value によって上書きされてもかまいません (MAY)。たとえば、contact address が次の値で返された場合：
sip:user@host?Subject=foo&Call-Info=`\`http://www.foo.com\``
元のリダイレクトされたリクエスト内の任意の Subject header field は上書きされますが、HTTP URL は既存の Call-Info header field value に単に追加されます。
UAC は、元のリダイレクトされたリクエストで使用された同じ To、From、および Call-ID を再利用することが推奨されます (RECOMMENDED)。ただし、UAC は新しいリクエストの Call-ID header field value を更新することなどを選択してもかまいません (MAY)。
最後に、新しいリクエストが構築されると、それは新しい client transaction を使用して送信されるため、Section 8.1.1.7 で説明したように、top Via field に新しい branch ID を持たなければなります (MUST)。
他のすべての点で、リダイレクトレスポンスの受信時に送信されるリクエストは、元のリクエストの header field と body を再利用すべきです (SHOULD)。
場合によっては、受信したステータスコードと有効期限間隔の存在に応じて、Contact header field value は UAC に一時的または永続的にキャッシュされる場合があります。Section 21.3.2 および 21.3.3 を参照してください。
8.1.3.5 4xx レスポンスの処理 (Processing 4xx Responses)
特定の 4xx レスポンスコードは、method に依存しない特定の UA 処理を必要とします。
401 (Unauthorized) または 407 (Proxy Authentication Required) レスポンスを受信した場合、UAC は Section 22.2 および 22.3 の認証手順に従って、資格情報を使用してリクエストを再試行すべきです (SHOULD)。
413 (Request Entity Too Large) レスポンス (Section 21.4.11) を受信した場合、リクエストには UAS が受け入れる用意のあるものより長い body が含まれていました。可能であれば、UAC は body を省略するか、より短い長さの body を使用してリクエストを再試行すべきです (SHOULD)。
415 (Unsupported Media Type) レスポンス (Section 21.4.13) を受信した場合、リクエストには UAS がサポートしていない media type が含まれていました。UAC は、レスポンスの Accept header field にリストされた型、レスポンスの Accept-Encoding header field にリストされたエンコーディング、およびレスポンスの Accept-Language にリストされた言語のみを使用して、リクエストの送信を再試行すべきです (SHOULD)。
416 (Unsupported URI Scheme) レスポンス (Section 21.4.14) を受信した場合、Request-URI はサーバーがサポートしていない URI scheme を使用していました。クライアントは、今回は SIP URI を使用してリクエストを再試行すべきです (SHOULD)。
420 (Bad Extension) レスポンス (Section 21.4.15) を受信した場合、リクエストには、proxy または UAS がサポートしていない機能の option-tag をリストした Require または Proxy-Require header field が含まれていました。UAC は、今回はレスポンスの Unsupported header field にリストされた拡張を省略してリクエストを再試行すべきです (SHOULD)。
上記のすべての場合において、リクエストは適切な変更を加えた新しいリクエストを作成することによって再試行されます。この新しいリクエストは新しいトランザクションを構成し、前のリクエストと同じ Call-ID、To、および From の値を持つべきです (SHOULD) が、CSeq には前の値より 1 大きい新しい sequence number を含める必要があります。
他の 4xx レスポンス (まだ定義されていないものを含む) の場合、再試行が可能かどうかは method とユースケースに依存します。
8.2 UAS の動作 (UAS Behavior)
UAS が dialog 外のリクエストを処理する場合、method に依存しない一連の処理規則に従います。Section 12 は、UAS がリクエストが dialog 内か外かを判断する方法に関するガイダンスを提供します。
リクエスト処理はアトミックであることに注意してください。リクエストが受け入れられた場合、それに関連するすべての状態変更が実行されなければなります (MUST)。拒否された場合、すべての状態変更が実行されてはならない (MUST NOT) ことに注意してください。
UAS は、この節の以降のステップの順序 (つまり、認証から始まり、次に method、header field などの検査を行い、この節の残りを通じて続く) でリクエストを処理すべきです (SHOULD)。
8.2.1 Method の検査 (Method Inspection)
リクエストが認証されると (または認証がスキップされると)、UAS はリクエストの method を検査しなければなります (MUST)。UAS がリクエストの method を認識するがサポートしない場合、405 (Method Not Allowed) レスポンスを生成しなければなります (MUST)。レスポンスを生成する手順は Section 8.2.6 に記述されています。UAS は 405 (Method Not Allowed) レスポンスに Allow header field を追加しなければなります (MUST)。Allow header field は、メッセージを生成する UAS がサポートする method の集合をリストしなければなります (MUST)。Allow header field は Section 20.5 に示されています。
method がサーバーがサポートするものである場合、処理は続行されます。
8.2.2 Header の検査 (Header Inspection)
UAS がリクエスト内の header field を理解しない場合 (つまり、その header field がこの仕様またはサポートされる拡張のいずれでも定義されていない場合)、サーバーはその header field を無視し、メッセージの処理を続行しなければなります (MUST)。UAS は、リクエストの処理に必要ないいかなる不正な形式の header field も無視すべきです (SHOULD)。
8.2.2.1 To および Request-URI
To header field は、From field で識別されたユーザーによって指定されたリクエストの元の受信者を識別します。元の受信者は、コール転送または他の proxy 操作のため、リクエストを処理する UAS である場合とそうでない場合があります。To header field が UAS のアイデンティティでない場合、UAS はリクエストを受け入れるかどうかを決定するために任意のポリシーを適用してもかまいません (MAY)。ただし、UAS が To header field 内の URI scheme (たとえば tel: URI) を認識しない場合、または To header field がこの UAS の既知または現在のユーザーにアドレス指定されていない場合でも、リクエストを受け入れることが推奨されます (RECOMMENDED)。一方、UAS がリクエストを拒否することを決定した場合、403 (Forbidden) ステータスコードのレスポンスを生成し、送信のために server transaction に渡すべきです (SHOULD)。
ただし、Request-URI はリクエストを処理する UAS を識別します。Request-URI が UAS がサポートしていない scheme を使用している場合、416 (Unsupported URI Scheme) レスポンスでリクエストを拒否すべきです (SHOULD)。Request-URI が UAS がリクエストを受け入れる用意のあるアドレスを識別しない場合、404 (Not Found) レスポンスでリクエストを拒否すべきです (SHOULD)。一般に、REGISTER method を使用してその address-of-record を特定の contact address にバインドする UA は、Request-URI がその contact address と等しいリクエストを見ます。受信した Request-URI の他の潜在的なソースには、dialog を確立または更新する UA が送信したリクエストおよびレスポンスの Contact header field が含まれます。
8.2.2.2 マージされたリクエスト (Merged Requests)
リクエストの To header field に tag がない場合、UAS core は進行中のトランザクションに対してリクエストをチェックしなければなります (MUST)。From tag、Call-ID、および CSeq が進行中のトランザクションに関連付けられたものと完全に一致するが、リクエストがそのトランザクションと一致しない場合 (Section 17.2.3 の一致規則に基づく)、UAS core は 482 (Loop Detected) レスポンスを生成し、それを server transaction に渡すべきです (SHOULD)。
同じリクエストが、おそらく forking によるものと思われる異なるパスを経由して複数回 UAS に到達しました。UAS は受信した最初のそのようなリクエストを処理し、残りのリクエストに対して 482 (Loop Detected) で応答します。
8.2.2.3 Require
UAS が自分がリクエストを処理する適切な要素であると判断したと仮定すると、存在する場合は Require header field を検査します。
Require header field は、UAC が、リクエストを適切に処理するために UAS がサポートすると期待する SIP 拡張について UAS に通知するために使用されます。その形式は Section 20.32 で説明されています。UAS が Require header field にリストされた option-tag を理解しない場合、420 (Bad Extension) のステータスコードでレスポンスを生成することによって応答しなければなります (MUST)。UAS は Unsupported header field を追加し、リクエストの Require header field の中で理解しないオプションをリストしなければなります (MUST)。
Require および Proxy-Require は、SIP CANCEL リクエスト、または非 2xx レスポンスに対して送信される ACK リクエストでは使用してはならない (MUST NOT) ことに注意してください。これらの header field がこれらのリクエストに存在する場合、無視されなければなります (MUST)。
2xx レスポンスに対する ACK リクエストは、初期リクエストに存在した Require および Proxy-Require 値のみを含まなければなります (MUST)。
例：
UAC->UAS: INVITE sip:[email protected] SIP/2.0
Require: 100rel
UAS->UAC: SIP/2.0 420 Bad Extension
Unsupported: 100rel
この動作は、両方の側がすべての option を理解しているときにクライアントサーバー対話が遅延なく進行し、(上記の例のように) option が理解されない場合にのみ遅くなることを保証します。よく一致するクライアントサーバーペアの場合、対話は迅速に進行し、ネゴシエーションメカニズムでしばしば必要となる往復を節約します。さらに、クライアントがサーバーが理解しない機能を必要とする場合の曖昧さも解消します。一部の機能 (コール処理 field など) は、エンドシステムにのみ関心があります。
8.2.3 コンテンツの処理 (Content Processing)
UAS がクライアントが要求した拡張を理解すると仮定すると、UAS はメッセージの body とそれを記述する header field を検査します。type (Content-Type で示される)、言語 (Content-Language で示される)、またはエンコーディング (Content-Encoding で示される) が理解されず、その body part がオプションでない (Content-Disposition header field で示される) 場合、UAS は 415 (Unsupported Media Type) レスポンスでリクエストを拒否しなければなります (MUST)。リクエストに UAS がサポートしない型の body が含まれていた場合、レスポンスは UAS が理解するすべての body の型をリストした Accept header field を含まなければなります (MUST)。リクエストに UAS が理解しない content encoding が含まれていた場合、レスポンスは UAS が理解するエンコーディングをリストした Accept-Encoding header field を含まなければなります (MUST)。リクエストに UAS が理解しない言語の content が含まれていた場合、レスポンスは UAS が理解する言語を示す Accept-Language header field を含まなければなります (MUST)。これらのチェックを超えて、body の処理は method と型に依存します。content 固有の header field の処理の詳細については、Section 7.4 および Section 20.11 から 20.15 を参照してください。
8.2.4 拡張の適用 (Applying Extensions)
UAS がレスポンスの生成時に何らかの拡張を適用したい場合、その拡張のサポートがリクエストの Supported header field で示されていない限り、そうしてはなりません (MUST NOT)。望ましい拡張がサポートされていない場合、サーバーは baseline SIP およびクライアントがサポートするその他の拡張のみに依存すべきです (SHOULD)。サーバーが拡張なしでリクエストを処理できないまれな状況では、サーバーは 421 (Extension Required) レスポンスを送信してもかまいません (MAY)。このレスポンスは、特定の拡張のサポートなしでは適切なレスポンスを生成できないことを示します。必要な拡張はレスポンスの Require header field に含まれなければなります (MUST)。この動作は推奨されません (NOT RECOMMENDED)。なぜなら、一般に相互運用性を損なうためです。
421 以外のレスポンスに適用される拡張はすべて、レスポンスに含まれる Require header field にリストされなければなります (MUST)。もちろん、サーバーはリクエストの Supported header field にリストされていない拡張を適用してはなりません (MUST NOT)。その結果、レスポンスの Require header field には、standards-track RFC で定義された option tag のみが含まれます。
8.2.5 リクエストの処理 (Processing the Request)
前の小節のすべてのチェックが通過したと仮定すると、UAS の処理は method 固有になります。Section 10 は REGISTER リクエストを扱い、Section 11 は OPTIONS リクエストを扱い、Section 13 は INVITE リクエストを扱い、Section 15 は BYE リクエストを扱います。
8.2.6 レスポンスの生成 (Generating the Response)
UAS がリクエストに対するレスポンスを構築したい場合、以下の小節で詳述された一般的な手順に従います。問題のレスポンスコードに固有の、この節で詳述されていない追加の動作も必要な場合があります。
レスポンスの作成に関連するすべての手順が完了すると、UAS はレスポンスを、リクエストを受信した server transaction に戻します。
8.2.6.1 暫定レスポンスの送信 (Sending a Provisional Response)
レスポンスを生成するための 1 つの大部分が method 非依存のガイドラインは、UAS が非 INVITE リクエストに対して暫定レスポンスを発行してはならない (SHOULD NOT) ということです。むしろ、UAS は非 INVITE リクエストに対する final response をできるだけ早く生成すべきです (SHOULD)。
100 (Trying) レスポンスが生成されるとき、リクエストに存在する任意の Timestamp header field はこの 100 (Trying) レスポンスにコピーされなければなります (MUST)。レスポンスの生成に遅延がある場合、UAS はレスポンスの Timestamp value に遅延値を追加すべきです (SHOULD)。この値は、レスポンスの送信時刻とリクエストの受信時刻の差を秒単位で測定したものを含まなければなります (MUST)。
8.2.6.2 Header と Tag
レスポンスの From field はリクエストの From header field と等しくなければなります (MUST)。レスポンスの Call-ID header field はリクエストの Call-ID header field と等しくなければなります (MUST)。レスポンスの CSeq header field はリクエストの CSeq field と等しくなければなります (MUST)。レスポンス内の Via header field value はリクエスト内の Via header field value と等しく、同じ順序を維持しなければなります (MUST)。
リクエストの To header field に tag が含まれていた場合、レスポンスの To header field はリクエストの To header field と等しくなければなります (MUST)。ただし、リクエストの To header field に tag が含まれていなかった場合、レスポンスの To header field 内の URI は To header field 内の URI と等しくなければなります (MUST)。さらに、UAS はレスポンスの To header field に tag を追加しなければなります (MUST) (100 (Trying) レスポンスを除き、そこでは tag が存在してもかまいません (MAY))。これはレスポンスしている UAS を識別する役割を果たし、おそらく dialog ID の構成要素になります。そのリクエストに対するすべてのレスポンス (final および provisional の両方) は、同じ tag を使用しなければなります (MUST) (再び 100 (Trying) を除く)。tag を生成する手順は Section 19.3 で定義されています。
8.2.7 ステートレス UAS の動作 (Stateless UAS Behavior)
stateless UAS は、トランザクション状態を維持しない UAS です。これは通常どおりリクエストに応答しますが、レスポンスの送信後に UAS によって通常保持される状態を破棄します。stateless UAS がリクエストの再送信を受信した場合、まるで最初のインスタンスへの応答であるかのようにレスポンスを再生成して再送信します。UAS がステートレスになることができるのは、リクエストが同一である場合にその method のリクエスト処理が常に同じレスポンスになる場合のみです。これはたとえばステートレスな registrar を排除します。stateless UAS はトランザクション層を使用しません。これらはトランスポート層から直接リクエストを受信し、トランスポート層に直接レスポンスを送信します。
stateless UAS の役割は、主に、challenge response が発行される未認証リクエストを処理するために必要です。未認証リクエストが状態を持つ方法で処理された場合、悪意のある未認証リクエストの洪水が大量のトランザクション状態を作成し、UAS のコール処理を遅くしたり完全に停止したりして、事実上 denial of service 状態を作成する可能性があります。詳細については Section 26.1.5 を参照してください。
stateless UAS の最も重要な動作は以下のとおりです。
o stateless UAS は暫定 (1xx) レスポンスを送信してはならない (MUST NOT)。
o stateless UAS はレスポンスを再送信してはならない (MUST NOT)。
o stateless UAS は ACK リクエストを無視しなければならない (MUST)。
o stateless UAS は CANCEL リクエストを無視しなければならない (MUST)。
o To header tag はステートレスな方法で生成されなければならない (MUST) — 同じリクエストに対して常に同じ tag を生成する方法で。tag の構築については Section 19.3 を参照してください。
他のすべての点で、stateless UAS は stateful UAS と同じように動作します。UAS は新しいリクエストごとに stateful または stateless モードのいずれかで動作できます。
8.3 Redirect Server
一部のアーキテクチャでは、ルーティングリクエストを担当する proxy server の処理負荷を削減し、シグナリングパスの堅牢性を向上させるために、リダイレクションに依存することが望ましい場合があります。
リダイレクションにより、サーバーはリクエストのルーティング情報をレスポンスでクライアントにプッシュバックでき、それによってこのトランザクションのさらなるメッセージングの loop から自身を排除しながら、リクエストのターゲットを見つける支援を続けることができます。リクエストの発信者がリダイレクションを受信すると、受信した URI に基づいて新しいリクエストを送信します。URI をネットワークのコアからエッジに伝播させることで、リダイレクションはかなりのネットワークのスケーラビリティを可能にします。
redirect server は、論理的に、server transaction layer と、何らかの location service にアクセスできる transaction user から構成されます (registrar と location service の詳細については Section 10 を参照)。この location service は、実効的に、単一の URI と、その URI のターゲットが見つかる 1 つ以上の代替場所の集合との間のマッピングを含むデータベースです。
redirect server は独自の SIP リクエストを発行しません。CANCEL 以外のリクエストを受信すると、サーバーはリクエストを拒否するか、location service から代替場所のリストを収集し、3xx クラスの final response を返します。整形式の CANCEL リクエストに対しては、2xx レスポンスを返すべきです (SHOULD)。このレスポンスは SIP トランザクションを終了します。redirect server は、SIP トランザクション全体でトランザクション状態を維持します。redirect server 間の forwarding loop を検出するのはクライアントの責任です。
redirect server がリクエストに対する 3xx レスポンスを返すとき、1 つ以上の代替場所のリストを Contact header field に投入します。Contact header field value の "expires" パラメータを提供して、Contact データのライフタイムを示してもかまいません (MAY)。
Contact header field には、試行する新しい場所またはユーザー名を与える URI が含まれます。または、追加のトランスポートパラメータのみを指定する場合があります。301 (Moved Permanently) または 302 (Moved Temporarily) レスポンスは、初期リクエストがターゲットとしたものと同じ場所およびユーザー名を与えるが、試行する異なるサーバーやマルチキャストアドレス、または SIP transport を UDP から TCP へ (またはその逆へ) 変更するなど、追加のトランスポートパラメータを指定する場合もあります。
ただし、redirect server はリクエストを Request-URI 内の URI と等しい URI にリダイレクトしてはなりません (MUST NOT)。代わりに、URI が自身を指していない場合、サーバーはリクエストを宛先 URI に proxy してもかまいません (MAY)。または 404 で拒否してもかまいません (MAY)。
クライアントが outbound proxy を使用しており、その proxy が実際にリクエストをリダイレクトする場合、無限リダイレクション loop が発生する可能性があります。
Contact header field value は、最初に呼び出されたリソースとは異なるリソースを参照する場合があることに注意してください。たとえば、PSTN gateway に接続された SIP コールは、「おかけになった番号は変更されました」などの特別な情報アナウンスを配信する必要がある場合があります。
Contact レスポンス header field は、呼ばれた相手に到達できる場所を示す任意の適切な URI を含めることができ、SIP URI に限定されません。たとえば、phone、fax、または irc の URI (定義されていれば) や、mailto: (RFC 2368 [32]) URL を含めることができます。SIPS URI を非 SIPS URI にリダイレクトする影響と制限については Section 26.4.4 を参照してください。
Contact header field value の "expires" パラメータは、URI が有効な期間を示します。パラメータの値は秒数を示す数値です。このパラメータが提供されない場合、Expires header field の値が URI が有効な期間を決定します。不正な形式の値は 3600 と同等として扱われるべきです (SHOULD)。
これは、この header field で絶対時間を許可した RFC 2543 との適度な下位互換性を提供します。絶対時間を受信した場合、それは不正な形式として扱われ、次に 3600 がデフォルトになります。
redirect server は理解できない機能 (認識されない header field、Require 内の不明な option tag、さらには method name を含む) を無視し、問題のリクエストのリダイレクションを続行しなければなります (MUST)。