HTTP 狀態碼 錯誤清單

如果向您的伺服器發出了某項請求要求顯示您網站上的某個網頁（例如，當使用者通過瀏覽器訪問您的網頁或在 Googlebot 抓取該網頁時），那麼，您的伺服器會返回 HTTP 狀態碼以響應該請求。

此狀態碼提供了有關請求狀態的資訊，且為 Googlebot 提供了有關您網站和請求的網頁的資訊。

一些常見的狀態碼為：

• 200 - 伺服器成功返回網頁
• 404 - 請求的網頁不存在
• 503 - 伺服器暫時不可用

以下提供了 HTTP 狀態碼的完整列表。點選連結可瞭解詳細資料。您也可以訪問有關 HTTP 狀態碼的 W3C 頁來瞭解詳細資料。

1xx（臨時響應）
用於表示臨時響應並需要要求者執行操作才能繼續的狀態碼。

代碼	說明
100（繼續）	要求者應當繼續提出請求。伺服器返回此代碼則意味著，伺服器已收到了請求的第一部分，現正在等待接收其餘部分。
101（切換協議）	要求者已要求伺服器切換協議，伺服器已確認並準備進行切換。

2xx（成功）

用於表示伺服器已成功處理了請求的狀態碼。

代碼	說明
200（成功）	伺服器已成功處理了請求。通常，這表示伺服器提供了請求的網頁。如果您的 robots.txt 檔案顯示為此狀態，那麼，這表示 Googlebot 已成功檢索到該檔案。
201（已建立）	請求成功且伺服器已建立了新的資源。
202（已接受）	伺服器已接受了請求，但尚未對其進行處理。
203（非授權資訊）	伺服器已成功處理了請求，但返回了可能來自另一來源的資訊。
204（無內容）	伺服器成功處理了請求，但未返回任何內容。
205（重設內容）	伺服器成功處理了請求，但未返回任何內容。與 204 響應不同，此響應要求要求者重設文檔視圖（例如清除表單內容以輸入新內容）。
206（部分內容）	伺服器成功處理了部分 GET 請求。

3xx（已重新導向） 
要完成請求，您需要進一步進行操作。通常，這些狀態碼是永遠重新導向的。Google 建議您在每次請求時使用的重新導向要少於 5 個。您可以使用網站管理員工具來查看 Googlebot 在抓取您已重新導向的網頁時是否會遇到問題。診斷下的抓取錯誤頁中列出了 Googlebot 由於重新導向錯誤而無法抓取的網址。

代碼	說明
300（多種選擇）	伺服器根據請求可執行多種操作。伺服器可根據要求者 (User agent) 來選擇一項操作，或提供巨集指令清單供要求者選擇。
301（永久移動）	請求的網頁已被永久移動到新位置。伺服器返回此響應（作為對 GET 或 HEAD 請求的響應）時，會自動將要求者轉到新位置。您應使用此代碼通知 Googlebot 某個網頁或網站已被永久移動到新位置。
302（臨時移動）	伺服器目前正從不同位置的網頁響應請求，但要求者應繼續使用原有位置來進行以後的請求。此代碼與響應 GET 和 HEAD 請求的 301 代碼類似，會自動將要求者轉到不同的位置。但由於 Googlebot 會繼續抓取原有位置並將其編入索引，因此您不應使用此代碼來通知 Googlebot 某個頁面或網站已被移動。
303（查看其他位置）	當要求者應對不同的位置進行單獨的 GET 請求以檢索響應時，伺服器會返回此代碼。對於除 HEAD 請求之外的所有請求，伺服器會自動轉到其他位置。
304（未修改）	自從上次請求後，請求的網頁未被修改過。伺服器返回此響應時，不會返回網頁內容。 如果網頁自要求者上次請求後再也沒有更改過，您應當將伺服器配置為返回此響應（稱為 If-Modified-Since HTTP 標題）。由於伺服器可以告訴 Googlebot 自從上次抓取後網頁沒有更改過，因此可節省頻寬和開銷 。
305（使用代理）	要求者只能使用代理訪問請求的網頁。如果伺服器返回此響應，那麼，伺服器還會指明要求者應當使用的代理。
307（臨時重新導向）	伺服器目前正從不同位置的網頁響應請求，但要求者應繼續使用原有位置來進行以後的請求。此代碼與響應 GET 和 HEAD 請求的 301 代碼類似，會自動將要求者轉到不同的位置。但由於 Googlebot 會繼續抓取原有位置並將其編入索引，因此您不應使用此代碼來通知 Googlebot 某個頁面或網站已被移動。

4xx（請求錯誤） 
這些狀態碼表示，請求可能出錯，已妨礙了伺服器對請求的處理。

代碼	說明
400（錯誤請求）	伺服器不理解請求的文法。
401（未授權）	請求要求進行身分識別驗證。登入後，伺服器可能會返回對頁面的此響應。
403（已禁止）	伺服器拒絕請求。如果在 Googlebot 嘗試抓取您網站上的有效網頁時顯示此狀態碼（您可在 Google 網站管理員工具中診斷下的網路抓取頁面上看到此狀態碼），那麼，這可能是您的伺服器或主機拒絕 Googlebot 對其進行訪問。
404（未找到）	伺服器找不到請求的網頁。例如，如果請求是針對伺服器上不存在的網頁進行的，那麼，伺服器通常會返回此代碼。 如果您的網站上沒有 robots.txt 檔案，而您在 Google 網站管理員工具"診斷"標籤的 robots.txt 頁上發現此狀態，那麼，這是正確的狀態。然而，如果您有 robots.txt 檔案而又發現了此狀態，那麼，這說明您的 robots.txt 檔案可能是命名錯誤或位於錯誤的位置。（該檔案應當位於頂級網域名稱上，且應當名為 robots.txt）。 如果您在 Googlebot 嘗試抓取的網址上發現此狀態（位於"診斷"標籤的 HTTP 錯誤頁上），那麼，這表示 Googlebot 所追蹤的可能是另一網頁中的無效連結（舊連結或輸入有誤的連結）。
405（方法禁用）	禁用請求中所指定的方法。
406（不接受）	無法使用請求的內容特性來響應請求的網頁。
407（需要代理授權）	此狀態碼與 401（未授權）類似，但卻指定了要求者應當使用代理進行授權。如果伺服器返回此響應，那麼，伺服器還會指明要求者應當使用的代理。
408（請求逾時）	伺服器等候請求時逾時。
409（衝突）	伺服器在完成請求時發生衝突。伺服器必須包含有關響應中所發生的衝突的資訊。伺服器在響應與前一個請求相衝突的 PUT 請求時可能會返回此代碼，同時會提供兩個請求的差異列表。
410（已刪除）	如果請求的資源已被永久刪除，那麼，伺服器會返回此響應。該代碼與 404（未找到）代碼類似，但在資源以前有但現在已經不複存在的情況下，有時會替代 404 代碼出現。如果資源已被永久刪除，那麼，您應當使用 301 代碼指定該資源的新位置。
411（需要有效長度）	伺服器不會接受包含無效內容長度標題欄位的請求。
412（未滿足前提條件）	伺服器未滿足要求者在請求中設定的其中一個前提條件。
413（請求實體過大）	伺服器無法處理請求，因為請求實體過大，已超出伺服器的處理能力。
414（請求的 URI 過長）	請求的 URI（通常為網址）過長，伺服器無法進行處理。
415（不支援的媒體類型）	請求的格式不受請求頁面的支援。
416（請求範圍不符合要求）	如果請求是針對網頁的無效範圍進行的，那麼，伺服器會返回此狀態碼。
417（未滿足期望值）	伺服器未滿足"期望"請求標題欄位的要求。

5xx（伺服器錯誤）
這些狀態碼表示，伺服器在嘗試處理請求時發生內部錯誤。這些錯誤可能是伺服器本身的錯誤，而不是請求出錯。

代碼	說明
500（伺服器內部錯誤）	伺服器遇到錯誤，無法完成請求。
501（尚未實施）	伺服器不具備完成請求的功能。例如，當伺服器無法識別要求方法時，伺服器可能會返回此代碼。
502（錯誤網關）	伺服器作為網關或代理，從上遊伺服器收到了無效的響應。
503（服務不可用）	目前無法使用伺服器（由於超載或進行停機維護）。通常，這隻是一種暫時的狀態。
504（網關逾時）	伺服器作為網關或代理，未及時從上遊伺服器接收請求。
505（HTTP 版本不受支援）	伺服器不支援要求中所使用的 HTTP 協議版本。

 

 

       一般情況下，錯誤資訊代碼的頭一位或頭兩位元字代表錯誤的類型，其中第一位為1表示一般性資訊，第一位為2表示成功的資訊，如請求被成功地執行完成，第一位為3表示重新導向錯誤，比如要訪問的目標已經被轉移到其它位置，第一位為4表示是用戶端的錯誤，比如使用者身份不合法或請求的文法不正確，第一位為5表示是服務端的錯誤，如Proxy 伺服器故障或者不支援使用者的請求，前兩位為10表示串連錯誤，如串連被斷開或逾時，前兩位為11表示是主機的錯誤，比如找不到主機，前兩位為12表示是代理錯誤，如遞迴代理等 
臨時應答，也就是訊息性質的應答，標誌了對方伺服器正在處理請求，並且還沒有決定最後的應答。如果伺服器處理請求需要花200ms以上才能產生終結應答的時候，它應當發送一個1xx應答。 
注意1xx應答並不是可靠傳輸的。他們不會導致用戶端傳送一個ACK應答。臨時性質的（1xx）應答可以包含訊息體，包含會話描述。 
1.1 100 Trying 
這個應答表示下一個節點的伺服器已經接收到了這個請求並且還沒有執行這個請求的特定動作（比如，正在開啟資料庫的時候）。這個應答，就像其他臨時應答一樣，種植了UAC重新傳送INVITE請求。100(Trying)應答和其他臨時應答不同的是，在這裡，它永遠不會被有狀態proxy轉寄到上行流中。 
1.2 180 Ringing 
UA收到INVITE請求並且試圖提示給使用者。這個應答應當出世化一個本地回鈴。 
1.3 818 Call is Being Forwarded(呼叫被轉寄) 
伺服器可以用這個應答代碼來表示呼叫正在轉寄到另一個目的地集合。 
1.4 182 Queued 
當呼叫的對方暫時不能接收呼叫的時候，並且伺服器決定將呼叫排隊等候，而不是拒絕呼叫的時候，那麼就應當發出這個應答。當被叫方一旦恢複接收呼叫，他會返回合適的終結應答。對於這個呼叫狀態，可以有一個表示原因的短語，比如：”5 calls queued;expected waiting time is 15minutes”。伺服器可以給出好幾個182（Queued）應答告訴來電者排隊的情況（比如排隊靠前了等等）。 
1.5 183 會話進度 
183（Session Progress）應答用於提示建立對話的進度資訊。Reason-Phrase（表達原因的句子）、頭域或者訊息體可以用於提示呼叫進度的更訊息的資訊。 
2 成功資訊2xx 
這個應答表示請求是成功的。 
2.1 200 OK 
請求已經處理成功。這個資訊取決於不同方法的請求的應答。 
3 轉寄請求3XX 
3xx系列的應答是用於提示使用者的新位置資訊的，或者為了滿足呼叫而轉寄的額外服務地點。 
3.1 300 Multiple Choices 
請求的地址有多個選擇，每個選擇都有自己的地址，使用者或者（UA）可以選擇合適的通訊終端，並且轉寄這個請求到這個地址。 
應答可以包含一個具有每一個地點的在Accept要求標頭域中允許的資源特性，這樣使用者或者UA可以選擇一個最合適的地址來轉寄請求。沒有未這個應答的訊息體定義MIME類型。 
這些地址選擇也應當在Contact頭域中列出（20.10節）。不同於HTTP，SIP應答可以包含多個Contact頭域或者一個Contact頭域中具有一個地址清單。UA可以使用Contact頭域來自動轉寄或者要求使用者確認轉寄。不過，本規範沒有定義自動轉寄的標準。 
如果被叫方可以在多個地址被找到，並且伺服器不能或者不願意轉寄請求的時候，可以使用這個應答來給來電者。 
3.2 301 Moved Permently 
當不能在Request-URI指定的地址找到使用者的時候，請求的用戶端應當使用Contact頭域(20.10)所指出的新的地址重新嘗試。要求者應當用這個新的值來更新本地的目錄，地址本，和使用者地址cache，並且在後續請求中，發送到這個/這些列出的地址。 
3.3 302 Moved Temporarily 
請求方應當把請求重新發到這個Contact頭域所指出的新地址(20.10)。新請求的Request-URI應當用這個應答的Contact頭域所指出的值。 
在應答中的Expires(20.19節)或者Contact頭域的expires參數定義了這個Contact URI的生存周期。UA或者proxy在這個生存周期內cache這個URI。如果沒有嚴格的有效時見，那麼這個地址僅僅本次有效，並且不能在以後的事務中儲存。 
如果cache的Contact頭域的值失敗了，那麼被轉寄請求的Request-URI應當再次嘗試一次。臨時URI可以比逾時時間更快的失效，並且可以有一個新的臨時URI。 
3.4 305 Use Proxy 
請求的資源必須通過Contact頭域中指出的proxy來訪問。Contact頭域指定了一個proxy的URI。接收到這個應答的對象應當通過這個proxy重新發送這個單個請求。305（UseProxy）必須是UAS產生的。 
3.5 380 Alternative Service 
呼叫不成工，但是可以嘗試另外的服務。另外的服務在應答的訊息體中定義。訊息體的格式在這裡沒有定義，可能在以後的規範中定義。 
4 請求失敗4xx 
4xx應答定義了特定伺服器響應的請求失敗的情況。用戶端不應當在不變更要求的情況下重新嘗試同一個請求。（例如，增加合適的認證資訊）。不過，同一個請求交給不同伺服器也許就會成功。 
4.1 400 Bad Request 
請求中的語法錯誤。Reason-Phrase應當標誌這個詳細的語法錯誤，比如”Missing Call-ID header field”。 
4.2 401 Unauthorized 
請求需要使用者認證。這個應答是由UAS和註冊伺服器產生的，當407（Proxy Authentication Required）是proxy伺服器產生的。 
4.3 402 Payment Required 
保留/以後使用 
4.4 403 Forbidden 
服務端支援這個請求，但是拒絕執行請求。增加驗證資訊是沒有必要的，並且請求應當不被重試。 
4.5 404 Not Found 
伺服器返回最終資訊：使用者在Request-URI指定的域上不存在。當Request-URI的domain和接收這個請求的domain不匹配的情況下， 也會產生這個應答。 
4.6 405 Method Not Allowed 
伺服器支援Request-Line中的方法，但是對於這個Request-URI中的地址來說，是不允許應用這個方法的。 
應答必須包括一個Allow頭域，這個頭域包含了指定地址允許的方法列表。 
4.7 Not Acceptable 
請求中的資源只會導致產生一個在請求中的Accept頭域外的，內容無法接收的錯誤。 
4.8 407 Proxy Authentication Required 
這個返回碼和401（Unauthorized）很類四，但是標誌了用戶端應當首先在proxy上通過認證。SIP對認證的訪問請參見26節和22.3節。 
這個返回碼用於應用程式訪問通訊網關（比如，電話網關），而很少用於被叫方要求認證。 
4.9 408 Request Timeout 
在一段時間內，伺服器不能產生一個終結應答，例如，如果它無法及時決定使用者的位置。用戶端可以在稍後不變更要求的內容然後重新嘗試請求。 
4.10 410 Gone 
請求的資源在本伺服器上已經不存在了，並且不知道應當把請求轉寄到哪裡。這個問題將會使永久性的。如果伺服器不知道，或者不容易檢測，這個資源消失是臨時性質的還是永久性質的，那麼應當返回一個404（Not Found）。 
4.11 413請求實體過大。 
伺服器拒絕處理請求，因為這個請求的實體超過了伺服器希望或者能夠處理的大小。這個伺服器應當關閉串連避免用戶端重發這個請求。 
如果這個情況是暫時的，那麼服務端應當包含一個Retry-After頭域來表明這是一個暫時的故障，並且用戶端可以過一段時間再次嘗試。 
4.12 414 Request-URI Too Long 
伺服器拒絕這個請求，因為Request-URI超過了伺服器能夠處理的長度。 
4.13 415 Unsupported Media Type 
伺服器由於請求的訊息體的格式本伺服器不支援，所以拒絕處理這個請求。這個伺服器必鬚根據內容的故障類型，返回一個Accept，Accpet-Encoding,或者Accept-Language頭域列表。UAC根據8.1.3.5節定義的方法處理這個應答。 
4.14 416 Unsupported URI Scheme 
伺服器由於不支援Request-URI中的URI方案而終止處理這個請求。用戶端處理這個應答參照8.1.3.5。 
4.15 Bad Extension 
伺服器不知道在請求中的Proxy-Require(20.29)或者Require(20.32)頭域所指出的協議擴充。伺服器必須在Unsupported頭域中列出不支援的擴充。UAC處理這個應答請參見8.1.3.5 
4.16 421Extension Required 
UAS需要特定的擴充來處理這個請求，但是這個擴充並沒有在請求的Supported頭域中列出。具有這個應答碼的應答必須包含一個Require頭域列出所需要的擴充。 
UAS不應當使用這個應答除非它真的不能給用戶端提供有效服務。相反，如果在Support頭域中沒有列出需要的擴充，伺服器應當根據基準的SIP相容的方法和用戶端支援的擴充來進行處理。 
4.17 423 Interval Too Brief 
伺服器因為在請求中設定的資源重新整理時間（或者有效時間）過短而拒絕請求。這個應答可以用於註冊伺服器來拒絕那些Contact頭域有效期間過短的註冊請求。這個應答的用法和相關的Min-Expires頭域在10.2.8,10.3,20.23節中介紹和說明。 
4.18 480 Temporarily Unavailable 
請求成功到達被叫方的終端系統，但是被叫方當前不可用（例如，沒有登陸，或者登陸了但是狀態是不能通訊，或者有”請勿打擾”的標記）。應答應當在Retry-After中標誌一個合適的重發時間。這個使用者也有可能在其他地方是有效（在本伺服器中不知道）。Reason-Phrase(原因短句)應當提示更詳細的原因，為什麼被叫方暫時不可用。這個值應當是可以被UA設定的。狀態代碼486（Busy Here）可以用來更精確的表示本請求失敗的特定原因。 
這個狀態代碼也可以是轉寄服務或者proxy伺服器返回的，因為他們發現Request-URI指定的使用者存在，但是沒有一個給這個使用者的合適的當前轉寄的地址。 
4.19 481 Call/Transaction Does Not Exist 
這個狀態表示了UAS接收到請求，但是沒有和現存的對話或者事務匹配。 
4.20 482 Loop Detected 
伺服器檢測到了一個迴圈(16.3/4) 
4.21 483 Too Many Hops 
伺服器接收到了一個請求包含的Max-Forwards(20.22)頭域是0 
4.22 484 Address InComplete 
伺服器接收到了一個請求，它的Request-URI是不完整的。在原因短語中應當有附加的資訊說明。這個狀態代碼可以和撥號交疊。在和撥號交疊中，用戶端不知道撥號串的長度。它發送增加長度的字串，並且提示使用者輸入更多的字串，直到不在出現484（Address Incomplete）應答為止。 
4.23 485 Ambiguous 
Request-URI是不明確的。應答可以在Contact頭域中包含一個可能的明確的地址清單。這個提示列表肯囊個在安全性和隱私性對使用者或者組織造成破壞。必須能夠由配置決定是否以404（NotFound）代替這個應答，又或者禁止對不明確的地址使用可能的挑選清單。 
給帶有Request-URI的請求的一個應答例子： 
sip: lee@example.com: 
SIP/2.0 485 Ambiguous 
Contact: Carol Lee 
Contact: Ping Lee 
Contact: Lee M.Foote 
部分email和語音郵箱系統提供了這個功能。這個狀態代碼和3xx狀態代碼不同：對於300來說，它是假定同一個人或者服務有不同的地址選擇。所以對3xx來說，自動選擇系統或者連續尋找就有效，但是對485（Ambiguous）應答來說，一定要使用者的幹預。 
4.24 486 Busy Here 
當成功聯絡到被叫方的終端系統，但是被叫方當前在這個終端系統上不能接聽這個電話，那麼應答應當回給來電者一個更合適的時間在Retry-After頭域重試。這個使用者也許在其他地方有效，比如電話郵箱系統等等。如果我們知道沒有其他終端系統能夠接聽這個呼叫，那麼應當返回一個狀態代碼600（Busy Everywhere）。 
4.25 487 Request Terminated 
請求被BYE或者CANCEL所終止。這個應答永遠不會給CANCEL請求本身回複。 
4.26 488 Not Acceptable Here 
這個應答和606（Not Acceptable）有相同的含義，但是只是應用於Request-URI所指出的特定資源不能接受，在其他地方請求可能可以接受。 
包含了媒體相容性描述的訊息體可以出現在應答中，並且根據INVITE請求中的Accept頭域進行規格化（如果沒有Accept頭域，那麼就是application/sdp）。這個應答就像給OPTIONS請求的200(OK)應答的訊息體一樣。 
4.27 491 Request Pending 
在同一個對話中，UAS接收到的請求有一個依賴的請求正在處理。14.2描述了這種情況應當怎樣解決。 
4.28 493 Undecipherable 
UAS接收到了一個請求，包含了一個加密的MIME,並且不知道或者沒有提供合適的解密密鑰。這個應答可以包含單個包體，這個包體包含了合適的公開金鑰，這個公開金鑰用於給這個UAS通訊中加密包體使用的。細節描述在23.2節。 
5 Server Failure 5xx 
5xx應答是當伺服器本身故障的時候給出的失敗應答。 
5.1 500 Server Internal Error 
伺服器遇到了未知的情況，並且不能繼續處理請求。用戶端可以顯示特定的錯誤情況，並且可以在幾秒種以後重新嘗試這個請求。 
如果這個情況是臨時的，伺服器應當在Retry-After頭域標誌用戶端過多少秒鐘之後重新嘗試這個請求。 
5.2 501 Not Implemented 
伺服器沒有實現相關的請求功能。當UAS不認識請求的方法的時候，並且對每一個使用者都無法支援這個方法的時候，應當返回這個應答。（proxy不考慮請求的方法而轉寄請求）。 
注意405（Method Not Allowed）是因為伺服器實現了這個要求方法，但是這個要求方法在特定請求中不被支援。 
5.3 502 Bad Gateway 
如果伺服器，作為gateway或者proxy存在，從下行伺服器上接收到了一個非法的應答（這個應答對應的請求是本伺服器為了完成請求而轉寄給下行伺服器的）。 
5.4 503 Service Unavailable 
由於臨時的過載或者伺服器管理導致的伺服器暫時不可用。這個伺服器可以在應答中增加一個Retry-After來讓用戶端重試這個請求。如果沒有Retry-After指出，用戶端必須就像收到了一個500（Server Internal Error）應答一樣處理。 
用戶端（proxy或者UAC）收到503（Service Unavailable）應當嘗試轉寄這個請求到另外一個伺服器處理。並且在Retry-After頭域中指定的時間內，不應當轉寄其他請求到這個伺服器。 
作為503(Service Unavaliable)的替代，伺服器可以拒絕串連或者把請求扔掉。 
5.5 504 Server Time-out 
伺服器在一個外部伺服器上沒有收到一個及時的應答。這個外部伺服器是本伺服器用來訪問處理這個請求所需要的。如果從上行伺服器上收到的請求中的Expires頭域逾時，那麼應當返回一個408（Request TimeOut）錯誤。 
5.6 505 Version Not Supported 
伺服器不支援對應的SIP版本。伺服器是無法處理具有用戶端提供的相同主要版本號的請求，就會導致這樣的錯誤資訊。 
5.7 Message To Large 
伺服器無法處理請求，因為訊息長度超過了處理的長度。 
6 Global Failures 6xx 
6xx應答意味這伺服器給特定使用者有一個最終的資訊，並不只是在Request-URI的特定執行個體有最終資訊。 
6.1 600 Busy Everywhere 
成功聯絡到被叫方的終端系統，但是被叫方處於忙的狀態，並不打算電話中。這個應答可以通過增加一個Retry-After頭域更明確的告訴來電者多久以後可以繼續呼叫。如果被叫方不希望提示拒絕的原因，被叫方應當使用603（Decline）。只有當終端系統知道沒有其他終端節點（比如語音郵箱系統）能夠訪問到這個使用者的時候才能使用這個應答。否則應當返回一個486（Busy Here）的應答。 
6.2 603 Decline 
當成功訪問到被叫方的裝置，但是使用者明確的不想應答。這個應答可以通過增加一個Retry-After頭域更明確的告訴來電者多久以後可以繼續呼叫。只有當終端知道沒有其他任何終端裝置能夠響應這個呼叫的勢能才能給出這個應答。 
6.3 604 Does Not Exists Anywhere 
伺服器驗證了在請求中Request-URI的使用者資訊，哪裡都不存在 
6.4 606 Not Acceptable 
當成功聯絡到一個UA,但是會話描述的一些部分比如請求的媒體，頻寬，或者地址類型不被接收。 
606（NotAcceptable）應答意味著使用者希望通訊，但是不能充分支援會話描述。606（Not Acceptable）應答可以在Warning頭域中包含一個原因列表，用於解釋為何會話描述不能被支援。警告原因代碼在20.43節中列出。 
在應答中，可以出現一個包含媒體相容性描述的訊息體，這個訊息體的格式根據INVITE請求中的Accept頭域指出的格式進行規格化（如果沒有Accept頭域，那麼就是application/sdp），就像給OPTIONS親求的200(OK)應答中的訊息一樣。 
我們希望這些媒體協商不要經常需要，並且當一個新使用者被邀請加入已經存在的會話的時候，這個媒體協商可能不需要。這取決於邀請的初始化者是否需要對606（Not Acceptable）進行處理。 
這個應答只有當用戶端知道沒有其他終端能夠處理這個請求的時候才能發出。