您可以列出所有已知的SIP應答嗎？
已知的SIP應答列表
- 400 錯誤的請求
- 401 未經授權
- 402 要求付費（預訂為將來使用）
- 403 被禁止的
- 404 未發現(未發現用戶)
- 405 不允許的方法
- 406 不可接受
- 407 需要代理身份授權
- 408 請求超時(預定時間內無法找到用戶)
- 410 已失消 (用戶曾經存在)
- 413 呼叫實體過大
- 414 呼叫URI過長
- 415 不支持的媒體類型
- 416 不支持的URI方案
- 420 不良擴展
- 421 需要擴展
- 422 會議定時器間隔太小
- 423 時間間隔過短
- 480 暫時不可用
- 481 通話/事務不存在
- 482 檢測到循環
- 483 跳數過多
- 484 地址不全
- 485 模糊不清
- 486 此處佔線
- 487 請求終止
- 488 此處不可接受
- 491 呼叫待批
- 493 無法解讀(S / MIME文體)
SIP協議應答碼
應答代碼
應答碼是包含了，並且擴展了HTTP/1.1應答碼。並不是所有的HTTP/1.1應答碼都適當應用，只有在折裏指出的是適當的。其他HTTP/1.1應答碼不應當使用。並且，SIP也定義了新的應答碼系列，6xx。
臨時應答1xx
臨時應答，也就是消息性質的應答，標誌了對方伺服器正在處理請求，並且還沒有決定最後的應答。如果伺服器處理請求需要花200ms以上才能產生終結應答的時候，它應當發送一個1xx應答。
注意1xx應答並不是可靠傳輸的。他們不會導致客戶端傳送一個ACK應答。臨時性質的（1xx）應答可以包含消息體，包含會話描述。
1. 100 Trying
這個應答表示下一個節點的伺服器已經接收到了這個請求並且還沒有執行這個請求的特定動作（比如，正在打開數據庫的時候）。這個應答，就像其他臨時應答一樣，種植了UAC重新傳送INVITE請求。100(Trying)應答和其他臨時應答不同的是，在這裏，它永遠不會被有狀態proxy轉發到上行流中。
2. 180 Ringing
UA收到INVITE請求並且試圖提示給用戶。這個應答應當出世化一個本地回鈴。
3. 181 Call is Being Forwarded
伺服器可以用這個應答代碼來表示呼叫正在轉接到另一個目的地集合。
4. 182 Queued
當呼叫的對方暫時不能接收呼叫的時候，並且伺服器決定將呼叫排隊等候，而不是拒絕呼叫的時候，那麼就應當發出這個應答。當被叫方一旦恢復接收呼叫，他會返回合適的終結應答。對於這個呼叫狀態，可以有一個表示原因的短語，比如：”5 calls queued;expected waiting time is 15minutes”。伺服器可以給出好幾個182（Queued）應答告訴呼叫方排隊的情況（比如排隊靠前了等等）。
5. 183 通話進展
183（Session Progress）應答用於提示建立對話的進度信息。Reason-Phrase（表達原因的句子）、頭域或者消息體可以用於提示呼叫進度的更消息的信息。
成功應答 2xx
這個應答表示請求是成功的。
1. 200 接受
- 用於接受會話邀請。
- 它表示成功完成的請求或接受。
1. 202 接受
表示該UAS已經接收並理解的請求，但該請求可能沒有被授權或由伺服器處理。它常用於響應訂閱。
轉發請求3XX
3xx系列的應答是用於提示用戶的新位置信息的，或者爲了滿足呼叫而轉發的額外服務地點。
1. 300 Multiple Choices
請求的地址有多個選擇，每個選擇都有自己的地址，用戶或者（UA）可以選擇合適的通訊終端，並且轉發這個請求到這個地址。
應答可以包含一個具有每一個地點的在Accept請求頭域中允許的資源特性，這樣用戶或者UA可以選擇一個最合適的地址來轉發請求。沒有未這個應答的消息體定義MIME類型。
這些地址選擇也應當在Contact頭域中列出。不同於HTTP，SIP應答可以包含多個Contact頭域或者一個Contact頭域中具有一個地址列表。UA可以使用Contact頭域來自動轉發或者要求用戶確認轉發。不過，本規範沒有定義自動轉發的標準。
如果被叫方可以在多個地址被找到，並且伺服器不能或者不願意轉發請求的時候，可以使用這個應答來給呼叫方。
2. 301 Moved Permently
當不能在Request-URI指定的地址找到用戶的時候，請求的客戶端應當使用Contact頭域所指出的新的地址重新嘗試。請求者應當用這個新的值來更新本地的目錄，地址本，和用戶地址cache，並且在後續請求中，發送到這個/這些列出的地址。
3.302 Moved Temporarily
請求方應當把請求重新發到這個Contact頭域所指出的新地址。新請求的Request-URI應當用這個應答的Contact頭域所指出的值。
在應答中的Expires或者Contact頭域的expires參數定義了這個Contact URI的生存週期。UA或者proxy在這個生存週期內cache這個URI。如果沒有嚴格的有效時見，那麼這個地址僅僅本次有效，並且不能在以後的事務中保存。
如果cache的Contact頭域的值失敗了，那麼被轉發請求的Request-URI應當再次嘗試一次。臨時URI可以比超時時間更快的失效，並且可以有一個新的臨時URI。
4. 305 Use Proxy
請求的資源必須通過Contact頭域中指出的proxy來訪問。Contact頭域指定了一個proxy的URI。接收到這個應答的對象應當通過這個proxy重新發送這個單個請求。305（UseProxy）必須是UAS產生的
5.380 Alternative Service
呼叫不成功，但是可以嘗試另外的服務。另外的服務在應答的消息體中定義。消息體的格式在這裏沒有定義，可能在以後的規範中定義。
請求失敗4xx
4xx應答定義了特定伺服器響應的請求失敗的情況。客戶端不應當在不更改請求的情況下重新嘗試同一個請求。（例如，增加合適的認證信息）。不過，同一個請求交給不同伺服器也許就會成功。
由於一些錯誤是從側面UAC確認的要求不能得到滿足，響應代碼由UAS通常發送。在接收到出錯消息時，客戶端應該通過修改其基於所述響應重新發送請求。下面討論的是一些重要的客戶端錯誤響應：
1. 400 Bad Request
請求中的語法錯誤。Reason-Phrase應當標誌這個詳細的語法錯誤，比如”Missing Call-ID header field”。
2. 401 Unauthorized
請求需要用戶認證，只供註冊機構使用，這個應答是由UAS和註冊伺服器產生的，代理伺服器應用代理伺服器授權407，407（Proxy Authentication Required）是proxy伺服器產生的。
3. 402 Payment Required
保留/以後使用。
4. 403 Forbidden
服務端支持這個請求，但是拒絕執行請求。增加驗證信息是沒有必要的，並且請求應當不被重試。
5. 404 Not Found
伺服器返回最終信息：用戶在Request-URI指定的域上不存在。當Request-URI的domain和接收這個請求的domain不匹配的情況下，也會產生這個應答。
6. 405 Method Not Allowed
伺服器支持Request-Line中的方法，但是對於這個Request-URI中的地址來說，是不允許應用這個方法的。
應答必須包括一個Allow頭域，這個頭域包含了指定地址允許的方法列表。
7. 406 Not Acceptable
請求中的資源只會導致產生一個在請求中的Accept頭域外的，內容無法接收的錯誤。
8. 407 Proxy Authentication Required
這個返回碼和401（Unauthorized）很類四，但是標誌了客戶端應當首先在proxy上通過認證。SIP對認證的訪問請參見26節和22.3節。
這個返回碼用於應用程序訪問通訊網關（比如，電話網關），而很少用於被叫方要求認證。P
9. 408 Request Timeout
在一段時間內，伺服器不能產生一個終結應答，例如，如果它無法及時決定用戶的位置。客戶端可以在稍後不更改請求的內容然後重新嘗試請求。
10. 410 Gone
請求的資源在本伺服器上已經不存在了，並且不知道應當把請求轉發到哪裏。這個問題將會使永久性的。如果伺服器不知道，或者不容易檢測，這個資源消失是臨時性質的還是永久性質的，那麼應當返回一個404（Not Found）。
11. 413 請求實體過大
伺服器拒絕處理請求，因爲這個請求的實體超過了伺服器希望或者能夠處理的大小。這個伺服器應當關閉連接避免客戶端重發這個請求。
如果這個情況是暫時的，那麼服務端應當包含一個Retry-After頭域來表明這是一個暫時的故障，並且客戶端可以過一段時間再次嘗試。
12. 414 Request-URI Too Long
伺服器拒絕這個請求，因爲Request-URI超過了伺服器能夠處理的長度。
13. 415 Unsupported Media Type
伺服器由於請求的消息體的格式本伺服器不支持，所以拒絕處理這個請求。這個伺服器必須根據內容的故障類型，返回一個Accept，Accpet-Encoding,或者Accept-Language頭域列表。
14. 416 Unsupported URI Scheme
伺服器由於不支持Request-URI中的URI方案而終止處理這個請求。
4.415 Bad Extension
伺服器不知道在請求中的Proxy-Require(20.29)或者Require(20.32)頭域所指出的協議擴展。伺服器必須在Unsupported頭域中列出不支持的擴展。：使用了不當SIP協議擴展，伺服器無法理解該擴展。
16. 421 Extension Required
UAS需要特定的擴展來處理這個請求，但是這個擴展並沒有在請求的Supported頭域中列出。具有這個應答碼的應答必須包含一個Require頭域列出所需要的擴展。
UAS不應當使用這個應答除非它真的不能給客戶端提供有效的服務。相反，如果在Support頭域中沒有列出需要的擴展，伺服器應當根據基準的SIP兼容的方法和客戶端支持的擴展來進行處理。
17. 423 Interval Too Brief
伺服器因爲在請求中設置的資源刷新時間（或者有效時間）過短而拒絕請求。這個應答可以用於註冊伺服器來拒絕那些Contact頭域有效期過短的註冊請求。
18. 480 Temporarily Unavailable
請求成功到達被叫方的終端系統，但是被叫方當前不可用（例如，沒有登陸，或者登陸了但是狀態是不能通訊，或者有”請勿打擾”的標記）。應答應當在Retry-After中標誌一個合適的重發時間。這個用戶也有可能在其他地方是有效的（在本伺服器中不知道）。Reason-Phrase(原因短句)應當提示更詳細的原因，爲什麼被叫方暫時不可用。這個值應當是可以被UA設置的。狀態碼486（Busy Here）可以用來更精確的表示本請求失敗的特定原因。
這個狀態碼也可以是轉發服務或者 proxy 伺服器返回的，因爲他們發現 Request-URI 指定的用戶存在，但是沒有一個給這個用戶的合適的當前轉發的地址。
19. 481 Call/Transaction Does Not Exist
這個狀態表示了UAS接收到請求，但是沒有和現存的對話或者事務匹配。
20. 482 Loop Detected
伺服器檢測到了一個循環(16.3/4)。
21. 483 Too Many Hops
伺服器接收到了一個請求包含的Max-Forwards頭域是0。
22. 484 Address InComplete
伺服器接收到了一個請求，它的Request-URI是不完整的。在原因短語中應當有附加的信息說明。這個狀態碼可以和撥號交疊。在和撥號交疊中，客戶端不知道撥號串的長度。它發送增加長度的字串，並且提示用戶輸入更多的字串，直到不在出現484（Address Incomplete）應答爲止。
23. 485 Ambiguous
Request-URI是不明確的。應答可以在Contact頭域中包含一個可能的明確的地址列表。這個提示列表肯囊個在安全性和隱私性對用戶或者組織造成破壞。必須能夠由配置決定是否以404（NotFound）代替這個應答，又或者禁止對不明確的地址使用可能的選擇列表。
給帶有Request-URI的請求的一個應答例子：
sip:
dcs-nets@example.com
:
SIP/2.0 485 Ambiguous
Contact: DCS-NETS
Contact: DCS NETWORKS
Contact: DCS
部分email和語音郵箱系統提供了這個功能。這個狀態碼和3xx狀態碼不同：對於300來說，它是假定同一個人或者服務有不同的地址選擇。所以對3xx來說，自動選擇系統或者連續查找就有效，但是對485（Ambiguous）應答來說，一定要用戶的干預。
24. 486 Busy Here
當成功聯繫到被叫方的終端系統，但是被叫方當前在這個終端系統上不能接聽這個電話，那麼應答應當回給呼叫方一個更合適的時間在Retry-After頭域重試。這個用戶也許在其他地方有效，比如電話郵箱系統等等。如果我們知道沒有其他終端系統能夠接聽這個呼叫，那麼應當返回一個狀態碼600（Busy Everywhere）。
25. 487 Request Terminated
請求被BYE或者CANCEL所終止。這個應答永遠不會給CANCEL請求本身回覆。
26. 488 Not Acceptable Here
這個應答和606（Not Acceptable）有相同的含義，但是隻是應用於Request-URI所指出的特定資源不能接受，在其他地方請求可能可以接受。
包含了媒體兼容性描述的消息體可以出現在應答中，並且根據INVITE請求中的Accept頭域進行規格化（如果沒有Accept頭域，那麼就是application/sdp）。這個應答就像給OPTIONS請求的200(OK)應答的消息體一樣。
27. 491 Request Pending
在同一個對話中，UAS接收到的請求有一個依賴的請求正在處理。
28. 493 Undecipherable
UAS接收到了一個請求，包含了一個加密的MIME,並且不知道或者沒有提供合適的解密密鑰。這個應答可以包含單個包體，這個包體包含了合適的公鑰，這個公鑰用於給這個UAS通訊中加密包體使用的。
Server Failure 5xx
5xx應答是當伺服器本身故障的時候給出的失敗應答。
此類響應用於表示該請求不能因爲與伺服器中的錯誤處理。伺服器無法完成顯然有效的請求。所述響應可包含一個Retry-After頭字段。該請求可以在其它位置受審，因爲沒有在請求中指示的誤差。
一些重要的服務器故障響應的討論如下:
1. 500 Server Internal Error
伺服器遇到了未知的情況，並且不能繼續處理請求。客戶端可以顯示特定的錯誤情況，並且可以在幾秒種以後重新嘗試這個請求。
如果這個情況是臨時的，伺服器應當在Retry-After頭域標誌客戶端過多少秒鐘之後重新嘗試這個請求。
Try it Yourself
2. 501 Not Implemented
伺服器沒有實現相關的請求功能。當UAS不認識請求的方法的時候，並且對每一個用戶都無法支持這個方法的時候，應當返回這個應答。（proxy不考慮請求的方法而轉發請求）。
注意405（Method Not Allowed）是因爲伺服器實現了這個請求方法，但是這個請求方法在特定請求中不被支持。
3. 502 Bad Gateway
如果伺服器，作爲gateway或者proxy存在，從下行伺服器上接收到了一個非法的應答（這個應答對應的請求是本伺服器爲了完成請求而轉發給下行伺服器的）。
4. 503 Service Unavailable
由於臨時的過載或者伺服器管理導致的伺服器暫時不可用。這個伺服器可以在應答中增加一個Retry-After來讓客戶端重試這個請求。如果沒有Retry-After指出，客戶端必須就像收到了一個500（Server Internal Error）應答一樣處理。
客戶端（proxy或者UAC）收到503（Service Unavailable）應當嘗試轉發這個請求到另外一個伺服器處理。並且在Retry-After頭域中指定的時間內，不應當轉發其他請求到這個伺服器。
作爲503(Service Unavaliable)的替代，伺服器可以拒絕連接或者把請求扔掉。
5. 504 Server Time-out
伺服器在一個外部伺服器上沒有收到一個及時的應答。這個外部伺服器是本伺服器用來訪問處理這個請求所需要的。如果從上行伺服器上收到的請求中的Expires頭域超時，那麼應當返回一個408（Request TimeOut）錯誤。
6. 505 Version Not Supported
伺服器不支持SIP協議的這個版本，伺服器是無法處理具有客戶端提供的相同主版本號的請求，就會導致這樣的錯誤信息。
7. 513 Message To Large
伺服器無法處理請求，因爲消息長度超過了處理的長度。
8. 580 Message To Large
此響應被用來拒絕一個SDP供給中需要的前提條件不能得到滿足。
Global Failures 6xx
此響應類表示伺服器知道該請求將失敗的地方是嘗試。其結果是，該請求不應該被發送到其他地點，6xx應答意味這伺服器給特定用戶有一個最終的信息，並不只是在Request-URI的特定實例有最終信息。
只有在其每一個可能的情況下由Request-URI的用戶明確知識應該伺服器發送一個全局的錯誤類響應。否則，客戶端錯誤類響應應該發送。
Retry-After頭字段可以被用來指示何時請求可能是成功的。一些重要的響應的討論如下：
1. 600 Busy Everywhere
成功聯繫到被叫方的終端系統，但是被叫方處於忙線狀態，並不打算接聽電話。這個應答可以通過增加一個Retry-After頭域更明確的告訴呼叫方多久以後可以繼續呼叫。如果被叫方不希望提示拒絕的原因，被叫方應當使用603（Decline）。只有當終端系統知道沒有其他終端節點（比如語音郵箱系統）能夠訪問到這個用戶的時候才能使用這個應答。否則應當返回一個486（Busy Here）的應答。
2. 603 Decline
當成功訪問到被叫方的設備，但是用戶明確的不想應答。這個應答可以通過增加一個Retry-After頭域更明確的告訴呼叫方多久以後可以繼續呼叫。只有當終端知道沒有其他任何終端設備能夠響應這個呼叫的勢能才能給出這個應答。
3. 604 Does Not Exists Anywhere
伺服器驗證了在請求中Request-URI的用戶信息，哪裏都不存在。
4. 606 Not Acceptable
當成功聯繫到一個UA,但是會話描述的一些部分比如請求的媒體、帶寬、或者地址類型不被接收。
606（NotAcceptable）應答意味着用戶希望通訊，但是不能充分支持會話描述。606（Not Acceptable）應答可以在Warning頭域中包含一個原因列表，用於解釋爲何會話描述不能被支持。
在應答中，可以出現一個包含媒體兼容性描述的消息體，這個消息體的格式根據INVITE請求中的Accept頭域指出的格式進行規格化（如果沒有Accept頭域，那麼就是application/sdp），就像給OPTIONS親求的200(OK)應答中的消息一樣。
我們希望這些媒體協商不要經常需要，並且當一個新用戶被邀請加入已經存在的會話的時候，這個媒體協商可能不需要。這取決於邀請的初始化者是否需要對606（Not Acceptable）進行處理。
這個應答只有當客戶端知道沒有其他終端能夠處理這個請求的時候才能發出。