21. 応答コード (Response Codes)
21 応答コード
応答コードは、HTTP/1.1 応答コードと一致し、かつそれを拡張する。すべての HTTP/1.1 応答コードが適切であるとは限らず、ここでは適切なもののみを示す。他の HTTP/1.1 応答コードは使用すべきではない（SHOULD NOT）。また、SIP は新しいクラス 6xx を定義する。
21.1 暫定 1xx
暫定応答（information 応答とも呼ばれる）は、接続されたサーバーが何らかの追加アクションを実行中であり、まだ最終応答を持っていないことを示す。サーバーは、最終応答を得るために 200 ms 以上かかると予想される場合、1xx 応答を送信する。1xx 応答は信頼できない方法で送信されることに注意。これらは決してクライアントに ACK を送信させない。暫定（1xx）応答は、セッション記述を含むメッセージボディを含んでもよい（MAY）。
21.1.1 100 Trying
この応答は、リクエストが次ホップサーバーによって受信され、この呼び出しに代わって何らかの不特定のアクションが実行されていることを示す（例えば、データベースが照会されている）。この応答は、他のすべての暫定応答と同様に、UAC による INVITE の再送信を停止させる。100（Trying）応答は、他の暫定応答と異なり、状態を持つプロキシによって上流に転送されることは決してない。
21.1.2 180 Ringing
INVITE を受信した UA は、ユーザーに警告しようとしている。この応答は、ローカルリンギングバックを開始するために使用されてもよい（MAY）。
21.1.3 181 Call Is Being Forwarded
サーバーは、このステータスコードを使用して、呼び出しが異なる宛先の集合に転送されていることを示してもよい（MAY）。
21.1.4 182 Queued
被呼者は一時的に利用できないが、サーバーは呼び出しを拒否するのではなくキューイングすることを決定した。被呼者が利用可能になると、適切な最終ステータス応答を返す。理由句は、呼び出しのステータスについての詳細をさらに与えてもよい（MAY）。例えば「5 件の呼び出しがキューイングされています。予想待機時間は 15 分です」。サーバーは、キューイングされた呼び出しのステータスについて発信者に通知するために、複数の 182（Queued）応答を発行してもよい（MAY）。
21.1.5 183 Session Progress
183（Session Progress）応答は、それ以外の分類がなされない呼び出しの進行状況に関する情報を伝えるために使用される。Reason-Phrase、ヘッダフィールド、またはメッセージボディを使用して、呼び出しの進行状況に関する詳細を伝えてもよい（MAY）。
21.2 成功 2xx
リクエストは成功した。
21.2.1 200 OK
リクエストは成功した。応答とともに返される情報は、リクエストで使用されたメソッドに依存する。
21.3 リダイレクト 3xx
3xx 応答は、ユーザーの新しい場所、または呼び出しを満たす可能性のある代替サービスに関する情報を与える。
21.3.1 300 Multiple Choices
リクエスト内のアドレスは、それぞれが独自の特定の場所を持ついくつかの選択肢に解決され、ユーザー（または UA）は優先する通信エンドポイントを選択し、その場所にリクエストをリダイレクトできる。
応答は、ユーザーまたは UA が最も適切なものを選択できるリソース特性と場所のリストを含むメッセージボディを含んでもよい（MAY）。ただし、Accept リクエストヘッダフィールドで許可されている場合。しかし、このメッセージボディに対する MIME タイプは定義されていない。
選択肢は、Contact フィールド（セクション 20.10）としてもリストされるべきである（SHOULD）。HTTP と異なり、SIP 応答は複数の Contact フィールド、または Contact フィールド内のアドレスリストを含んでもよい（MAY）。UA は、自動リダイレクトのために Contact ヘッダフィールド値を使用してもよく（MAY）、ユーザーに選択の確認を求めてもよい（MAY）。しかし、この仕様はそのような自動選択の標準を定義しない。
このステータス応答は、被呼者に複数の異なる場所で到達可能であり、サーバーがリクエストをプロキシできない、またはプロキシしたくない場合に適切である。
21.3.2 301 Moved Permanently
ユーザーは Request-URI 内のアドレスに既に存在せず、リクエスト元は Contact ヘッダフィールド（セクション 20.10）で与えられた新しいアドレスで再試行すべきである（SHOULD）。リクエスト元は、この新しい値でローカルディレクトリ、アドレス帳、およびユーザー位置キャッシュを更新し、将来のリクエストをリストされたアドレスにリダイレクトすべきである（SHOULD）。
21.3.3 302 Moved Temporarily
リクエスト元は、Contact ヘッダフィールド（セクション 20.10）で与えられた新しいアドレスでリクエストを再試行すべきである（SHOULD）。新しいリクエストの Request-URI は、応答内の Contact ヘッダフィールドの値を使用する。
Contact URI の有効期間は、Expires（セクション 20.19）ヘッダフィールドまたは Contact ヘッダフィールド内の expires パラメータを通じて示すことができる。プロキシと UA の両方が、有効期限の期間中この URI をキャッシュしてもよい（MAY）。明示的な有効期限がない場合、アドレスは再帰に対して一度のみ有効であり、将来のトランザクションのためにキャッシュされてはならない（MUST NOT）。
もし Contact ヘッダフィールドからキャッシュされた URI が失敗した場合、リダイレクトされたリクエストの Request-URI は一度だけ再試行されてもよい（MAY）。
一時的な URI は有効期限よりも早く古くなっている可能性があり、新しい一時的な URI が利用可能かもしれない。
21.3.4 305 Use Proxy
要求されたリソースは、Contact フィールドで与えられたプロキシを通じてアクセスされなければならない。Contact フィールドはプロキシの URI を与える。受信者は、この単一のリクエストをプロキシ経由で繰り返すことが期待される。305（Use Proxy）応答は、UAS によってのみ生成されてもよい（MAY）。
21.3.5 380 Alternative Service
呼び出しは成功しなかったが、代替サービスが可能である。
代替サービスは、応答のメッセージボディ内で記述される。そのようなボディのフォーマットはここでは定義されず、将来の標準化の対象となるかもしれない。
21.4 リクエスト失敗 4xx
4xx 応答は、特定のサーバーからの明確な失敗応答である。クライアントは、変更なしに同じリクエストを再試行すべきではない（SHOULD NOT）（例えば、適切な認証を追加するなど）。しかし、異なるサーバーへの同じリクエストは成功するかもしれない。
21.4.1 400 Bad Request
リクエストは、不正な形式の構文のために理解できなかった。Reason-Phrase は、構文の問題をより詳細に識別すべきである（SHOULD）。例えば「Call-ID ヘッダフィールドがありません」。
21.4.2 401 Unauthorized
リクエストはユーザー認証を必要とする。この応答は UAS およびレジストラによって発行され、407（Proxy Authentication Required）はプロキシサーバーによって使用される。
21.4.3 402 Payment Required
将来の使用のために予約されている。
21.4.4 403 Forbidden
サーバーはリクエストを理解したが、それを実行することを拒否している。認証は役立たず、リクエストを繰り返すべきではない（SHOULD NOT）。
21.4.5 404 Not Found
サーバーは、Request-URI で指定されたドメインにユーザーが存在しないという決定的な情報を持っている。このステータスは、Request-URI 内のドメインがリクエストの受信者の処理するドメインのいずれとも一致しない場合にも返される。
21.4.6 405 Method Not Allowed
Request-Line で指定されたメソッドは理解されているが、Request-URI で識別されるアドレスに対しては許可されていない。
応答は、指示されたアドレスに対する有効なメソッドのリストを含む Allow ヘッダフィールドを含まなければならない（MUST）。
21.4.7 406 Not Acceptable
リクエストによって識別されたリソースは、リクエストで送信された Accept ヘッダフィールドに従って受け入れられないコンテンツ特性を持つ応答エンティティを生成することのみが可能である。
21.4.8 407 Proxy Authentication Required
このコードは 401（Unauthorized）と類似しているが、クライアントが最初にプロキシで自身を認証しなければならないことを示す。SIP アクセス認証は、セクション 26 および 22.3 で説明される。
このステータスコードは、呼び出し先ではなく通信チャネル（例えば電話ゲートウェイ）へのアクセスに認証が必要なアプリケーションで使用できる。
21.4.9 408 Request Timeout
サーバーは、適切な時間内に応答を生成できなかった。例えば、時間内にユーザーの位置を決定できなかった場合。クライアントは、後の任意の時刻に変更なしでリクエストを繰り返してもよい（MAY）。
21.4.10 410 Gone
要求されたリソースはサーバー上で既に利用できず、転送先アドレスも既知ではない。この状態は永続的であると見なされることが期待される。サーバーがその状態が永続的であるかどうかを知らない、または決定する機能がない場合、代わりにステータスコード 404（Not Found）を使用すべきである（SHOULD）。
21.4.11 413 Request Entity Too Large
サーバーは、リクエストエンティティボディがサーバーが処理することを望む、または処理できるサイズより大きいためにリクエストの処理を拒否している。サーバーは、クライアントがリクエストを継続するのを防ぐために接続を閉じてもよい（MAY）。
条件が一時的な場合、サーバーは、それが一時的であり、クライアントがいつ再試行できるかを示すために Retry-After ヘッダフィールドを含めるべきである（SHOULD）。
21.4.12 414 Request-URI Too Long
サーバーは、Request-URI がサーバーが解釈することを望む長さより長いためにリクエストの処理を拒否している。
21.4.13 415 Unsupported Media Type
サーバーは、リクエストのメッセージボディが、要求されたメソッドに対してサーバーがサポートしていないフォーマットであるため、リクエストの処理を拒否している。サーバーは、コンテンツの具体的な問題に応じて、Accept、Accept-Encoding、または Accept-Language ヘッダフィールドを使用して、受け入れ可能なフォーマットのリストを返さなければならない（MUST）。この応答の UAC 処理はセクション 8.1.3.5 で説明される。
21.4.14 416 Unsupported URI Scheme
サーバーは、Request-URI 内の URI のスキームがサーバーにとって未知であるため、リクエストを処理できない。この応答のクライアント処理はセクション 8.1.3.5 で説明される。
21.4.15 420 Bad Extension
サーバーは、Proxy-Require（セクション 20.29）または Require（セクション 20.32）ヘッダフィールドで指定されたプロトコル拡張を理解しなかった。サーバーは、応答内の Unsupported ヘッダフィールドにサポートされていない拡張のリストを含まなければならない（MUST）。この応答の UAC 処理はセクション 8.1.3.5 で説明される。
21.4.16 421 Extension Required
UAS はリクエストを処理するために特定の拡張を必要とするが、この拡張はリクエスト内の Supported ヘッダフィールドにリストされていない。このステータスコードを持つ応答は、必要な拡張をリストする Require ヘッダフィールドを含まなければならない（MUST）。
UAS は、クライアントに有用なサービスを実際に提供できない場合を除き、この応答を使用すべきではない（SHOULD NOT）。代わりに、望ましい拡張が Supported ヘッダフィールドにリストされていない場合、サーバーはベースライン SIP 機能およびクライアントがサポートする拡張を使用してリクエストを処理すべきである（SHOULD）。
21.4.17 423 Interval Too Brief
サーバーは、リクエストによって更新されるリソースの有効期限が短すぎるため、リクエストを拒否している。この応答は、Contact ヘッダフィールドの有効期限が小さすぎた登録を拒否するためにレジストラによって使用できる。この応答および関連する Min-Expires ヘッダフィールドの使用は、セクション 10.2.8、10.3、および 20.23 で説明される。
21.4.18 480 Temporarily Unavailable
被呼者のエンドシステムは正常に接続されたが、被呼者は現在利用できない（例えばログインしていない、ログインしているが被呼者との通信を妨げる状態にある、または「呼び出し拒否」機能を有効にしている）。応答は、Retry-After ヘッダフィールドでより良い呼び出し時刻を示してもよい（MAY）。ユーザーは他の場所でも利用可能かもしれない（このサーバーには知られていない）。Reason-Phrase は、被呼者が利用できない正確な原因を示すべきである（SHOULD）。この値は UA によって設定可能であるべきである（SHOULD）。ステータス 486（Busy Here）を使用して、呼び出し失敗の特定の理由をより正確に示してもよい（MAY）。
このステータスはまた、Request-URI で識別されるユーザーを認識するが、現在其ユーザーに対する有効な転送場所を持たないリダイレクトまたはプロキシサーバーによって返される。
21.4.19 481 Call/Transaction Does Not Exist
このステータスは、UAS が既存のダイアログまたはトランザクションのいずれにも一致しないリクエストを受信したことを示す。
21.4.20 482 Loop Detected
サーバーはループを検出した（セクション 16.3 項目 4）。
21.4.21 483 Too Many Hops
サーバーは、値がゼロの Max-Forwards（セクション 20.22）ヘッダフィールドを含むリクエストを受信した。
21.4.22 484 Address Incomplete
サーバーは、Request-URI が不完全なリクエストを受信した。追加情報は、Reason-Phrase で提供されるべきである（SHOULD）。
このステータスコードはオーバラップダイヤリングを許可する。オーバラップダイヤリングでは、クライアントはダイヤル文字列の長さを知らない。より多くの入力をユーザーに促しながら、長さを増やした文字列を送信し、484（Address Incomplete）ステータス応答を受信しなくなるまで続ける。
21.4.23 485 Ambiguous
Request-URI は曖昧であった。応答は、Contact ヘッダフィールド内の明確な可能性のあるアドレスのリストを含んでもよい（MAY）。代替案を明らかにすることは、ユーザーまたは組織のプライバシーを侵害する可能性がある。曖昧な Request-URI に対して 404（Not Found）で応答するか、可能性のある選択肢のリストを抑制するようにサーバーを設定できることが可能でなければならない（MUST）。
Request-URI が sip:[email protected] であるリクエストに対する応答の例：
SIP/2.0 485 Ambiguous
Contact: Carol Lee `<sip:[email protected]>`
Contact: Ping Lee `<sip:[email protected]>`
Contact: Lee M. Foote `<sips:[email protected]>`
一部の電子メールおよびボイスメールシステムはこの機能を提供する。3xx とは異なるセマンティクスを持つため、3xx とは別のステータスコードが使用される。300 の場合、提供された選択肢によって同じ人物またはサービスに到達すると想定される。自動選択または順次検索は 3xx 応答に対して意味をなすが、485（Ambiguous）応答にはユーザーの介入が必要である。
21.4.24 486 Busy Here
被呼者のエンドシステムは正常に接続されたが、被呼者は現在他の呼び出しを受け入れる意思または能力がない。応答は、Retry-After ヘッダフィールドでより良い呼び出し時刻を示してもよい（MAY）。ユーザーは、ボイスメールサービスなど、他の場所でも利用可能かもしれない。他のエンドシステムがこの呼び出しを受け入れられないことをクライアントが知っている場合、600（Busy Everywhere）を使用すべきである（SHOULD）。
21.4.25 487 Request Terminated
リクエストは、BYE または CANCEL リクエストによって終了された。この応答は、CANCEL リクエスト自体に対して返されることは決してない。
21.4.26 488 Not Acceptable Here
応答は 606（Not Acceptable）と同じ意味を持つが、Request-URI で宛てられた特定のリソースにのみ適用され、リクエストは他の場所で成功するかもしれない。
INVITE 内の Accept ヘッダフィールド（または存在しない場合は application/sdp）に従ってフォーマットされたメディア機能の記述を含むメッセージボディが応答内に存在してもよい（MAY）。これは、OPTIONS リクエストに対する 200（OK）応答内のメッセージボディと同じである。
21.4.27 491 Request Pending
リクエストは、同じダイアログ内に保留中のリクエストを持つ UAS によって受信された。このような「グレア」状況がどのように解決されるかは、セクション 14.2 で説明される。
21.4.28 493 Undecipherable
リクエストは、受信者が適切な復号キーを所有していない、または提供しない暗号化された MIME ボディを含む UAS によって受信された。この応答は、この UA に送信される MIME ボディを暗号化するために使用すべき適切な公開鍵を含む単一のボディを持ってもよい（MAY）。この応答コードの使用の詳細はセクション 23.2 で見つかる。
21.5 サーバー失敗 5xx
5xx 応答は、サーバー自身がエラーを起こした場合に与えられる失敗応答である。
21.5.1 500 Server Internal Error
サーバーは、リクエストを実行することを妨げる予期しない状態に遭遇した。クライアントは、特定のエラー状態を表示してもよく（MAY）、数秒後にリクエストを再試行してもよい（MAY）。
条件が一時的な場合、サーバーは、クライアントがいつリクエストを再試行できるかを Retry-After ヘッダフィールドを使用して示してもよい（MAY）。
21.5.2 501 Not Implemented
サーバーは、リクエストを満たすために必要な機能をサポートしていない。これは、UAS がリクエストメソッドを認識せず、いかなるユーザーに対してもそれをサポートできない場合の適切な応答である。（プロキシは、メソッドに関係なくすべてのリクエストを転送する。）
サーバーがリクエストメソッドを認識するが、そのメソッドが許可されていない、またはサポートされていない場合、405（Method Not Allowed）が送信されることに注意。
21.5.3 502 Bad Gateway
サーバーは、ゲートウェイまたはプロキシとして機能している間、リクエストを満たすためにアクセスしたダウンストリームサーバーから無効な応答を受信した。
21.5.4 503 Service Unavailable
サーバーは、一時的な過負荷またはサーバーのメンテナンスのためにリクエストを一時的に処理できない。サーバーは、クライアントがいつリクエストを再試行すべきかを Retry-After ヘッダフィールドで示してもよい（MAY）。Retry-After がない場合、クライアントは、500（Server Internal Error）応答を受信したかのように動作しなければならない（MUST）。
503（Service Unavailable）を受信したクライアント（プロキシまたは UAC）は、代替サーバーにリクエストを転送しようとすべきである（SHOULD）。（存在する場合）Retry-After ヘッダフィールドで指定された期間中、そのサーバーに他のリクエストを転送すべきではない（SHOULD NOT）。
サーバーは、503（Service Unavailable）で応答する代わりに、接続を拒否するか、リクエストを破棄してもよい（MAY）。
21.5.5 504 Server Time-out
サーバーは、リクエストを処理するためにアクセスした外部サーバーからタイムリーな応答を受信しなかった。アップストリームサーバーからの Expires ヘッダフィールドで指定された期間内に応答がなかった場合は、代わりに 408（Request Timeout）を使用すべきである（SHOULD）。
21.5.6 505 Version Not Supported
サーバーは、リクエストで使用された SIP プロトコルバージョンをサポートしない、またはサポートを拒否する。サーバーは、このエラーメッセージ以外では、クライアントと同じメジャーバージョンを使用してリクエストを完了することができない、または望んでいないことを示している。
21.5.7 513 Message Too Large
サーバーは、メッセージ長がその能力を超えていたため、リクエストを処理できなかった。
21.6 グローバル失敗 6xx
6xx 応答は、サーバーが Request-URI で示された特定のインスタンスだけでなく、特定のユーザーに関する決定的な情報を持っていることを示す。
21.6.1 600 Busy Everywhere
被呼者のエンドシステムは正常に接続されたが、被呼者はビジーであり、現在他の呼び出しを受けたくない。応答は、Retry-After ヘッダフィールドでより良い呼び出し時刻を示してもよい（MAY）。被呼者が呼び出しを断る理由を明らかにしたくない場合、被呼者は代わりにステータスコード 603（Decline）を使用する。このステータス応答は、他のエンドポイント（ボイスメールシステムなど）がリクエストに応答しないことをクライアントが知っている場合にのみ返される。それ以外の場合は、486（Busy Here）を返すべきである（SHOULD）。
21.6.2 603 Decline
被呼者のマシンは正常に接続されたが、ユーザーは明示的に参加したくない、またはできない。応答は、Retry-After ヘッダフィールドでより良い呼び出し時刻を示してもよい（MAY）。このステータス応答は、他のエンドポイントがリクエストに応答しないことをクライアントが知っている場合にのみ返される。
21.6.3 604 Does Not Exist Anywhere
サーバーは、Request-URI で示されたユーザーがどこにも存在しないという権威ある情報を持っている。
21.6.4 606 Not Acceptable
ユーザーのエージェントは正常に接続されたが、要求されたメディア、帯域幅、またはアドレッシングスタイルなど、セッション記述のいくつかの側面が受け入れられなかった。
606（Not Acceptable）応答は、ユーザーが通信したいが、記述されたセッションを適切にサポートできないことを意味する。606（Not Acceptable）応答は、記述されたセッションがサポートできない理由を説明する Warning ヘッダフィールド内の理由のリストを含んでもよい（MAY）。Warning 理由コードはセクション 20.43 にリストされている。
INVITE 内の Accept ヘッダフィールド（または存在しない場合は application/sdp）に従ってフォーマットされたメディア機能の記述を含むメッセージボディが応答内に存在してもよい（MAY）。これは、OPTIONS リクエストに対する 200（OK）応答内のメッセージボディと同じである。
ネゴシエーションが頻繁に必要とならないことが望まれる。そして、新しいユーザーが既存の会議に招待されている場合、ネゴシエーションは不可能かもしれない。606（Not Acceptable）応答に基づいて行動するかどうかを決定するのは、招待の開始者の責任である。
このステータス応答は、他のエンドポイントがリクエストに応答しないことをクライアントが知っている場合にのみ返される。