HTTP狀態500表示服務器出錯。
500是服務器錯誤。
400是Clinet誤差。
300次路線變更
200好吧
響應代碼雖然是SIP，但也適用於HTTP，只是增加了壹些內容。
回答代碼
包含答案代碼，擴展了HTTP/1.1答案代碼。並非所有的HTTP/1.1響應代碼都被正確應用，只有文件夾中指出的那些代碼才是合適的。不應使用其他HTTP/1.1答案代碼。此外，SIP還定義了壹系列新的響應代碼6xx。
1臨時響應1xx
臨時回復，即消息性質的回復，表示另壹個服務器正在處理請求，尚未決定最終的回復。如果服務器處理請求生成最終回復的時間超過200毫秒，它應該發送1xx回復。
請註意，1xx回復無法可靠傳輸。它們不會導致客戶端發送ACK回復。臨時(1xx)回復可以包含消息正文，包括會話描述。
1.1 100正在嘗試
這個響應表明下壹個節點的服務器已經接收到這個請求，並且還沒有執行這個請求的特定動作(例如，當數據庫正在被打開時)。像其他臨時響應壹樣，該響應被植入UAC以重新發送INVITE請求。100(嘗試中)回復和其他臨時回復的區別在於，它永遠不會被有狀態代理轉發到上遊。
1.2 180振鈴
UA接收INVITE請求並嘗試提示用戶。這個響應應該是本地回鈴。
1.3 818電話正在轉接。
服務器可以使用這個應答碼來指示呼叫正被轉移到另壹個目的地設備。
1.4 182排隊
當呼叫者暫時無法接收呼叫，並且服務器決定將呼叫排隊而不是拒絕它時，則應該發送此回復。當被叫方恢復接收呼叫時，他將返回適當的終止響應。對於這種呼叫狀態，可以有壹個短語表示原因，如:“5個呼叫排隊；預計等待時間為15分鐘.服務器可以給出幾個182(排隊)響應來告訴調用者關於隊列的情況(比如隊列高等等。).
1.5 183會話進度
183(會話進度)響應用於提示建立對話的進度信息。原因短語、標題字段或消息正文可用於指示呼叫的進度。
2成功消息2xx
此響應表明請求成功。
2.1 200沒問題
請求已成功處理。該信息取決於對不同方法的請求的響應。
3轉發請求3XX
3xx系列的響應用於提示用戶新的位置信息，或者轉發附加的服務地點以滿足呼叫。
3.1 300多選
請求的地址有多個選擇，每個選擇都有自己的地址。用戶或(UA)可以選擇適當的通信終端並將請求轉發到該地址。
回復可以包含每個位置的接受請求報頭字段中允許的資源特征，以便用戶或UA可以選擇最合適的地址來轉發請求。如果沒有此回復，則消息正文中沒有定義MIME類型。
這些地址選擇也應列在聯系人標題字段中(第20.10節)。與HTTP不同，SIP響應可以包含多個Contact頭字段，或者在Contact頭字段中包含壹個地址列表。UA可以使用Contact頭字段自動轉發或要求用戶確認轉發。但是，該規範沒有定義自動轉發的標準。
如果可以在多個地址找到被叫方，並且服務器不能或不願意轉發該請求，則可以將該回復用於主叫方。
3.2 301永久移動
當在請求URI指定的地址找不到用戶時，發出請求的客戶端應該使用聯系報頭字段指示的新地址(20.10)重試。請求者應該用這個新值更新本地目錄、地址簿和用戶地址緩存，並在後續請求中將其發送到這個/這些列出的地址。
3.3 302臨時移動
請求者應將請求重新發送到該聯系人標題字段中指示的新地址(20.6438+00)。新請求的請求URI應該使用該回復的聯系人報頭字段中指示的值。
回復中的到期時間(第20.19節)或聯系人題頭字段中的到期時間參數定義了此聯系人URI的生命周期。UA或代理在此生命周期中緩存此URI。如果沒有嚴格的有效性，那麽這個地址只在這次有效，在以後的交易中不能保存。
如果緩存的Contact頭字段的值失敗，則轉發請求的請求URI應該重試。臨時URIs可以比超時更快到期，並且可以有新的臨時URI。
3.4 305使用代理
請求的資源必須通過Contact頭字段中指示的代理來訪問。聯系人報頭字段指定代理的URI。接收這個回復的對象應該通過這個代理重新發送這個請求。305(UseProxy)必須由UAS生成。
3.5 380替代役
這個電話打不通，但是妳可以試試別的服務。附加服務在回復的消息體中定義。這裏不定義消息體的格式，可能在以後的規範中定義。
4請求失敗4xx
4xx響應定義了特定服務器響應的請求失敗的情況。客戶端不應在不更改請求的情況下重試相同的請求。(例如，添加適當的身份驗證信息)。但是，對不同服務器的相同請求可能會成功。
4.1 400錯誤請求
請求中的語法錯誤。Reason-Phrase應該標記這個詳細的語法錯誤，例如“缺少Call-ID頭字段”。
4.2 401未經授權
該請求需要用戶身份驗證。當407(需要代理認證)由代理服務器生成時，此響應由UAS和註冊服務器生成。
4.3 402要求付款
保存/以後使用
4.4 403禁止
服務器支持這個請求，但拒絕執行它。沒有必要添加身份驗證信息，也不應該重試請求。
4.5未找到404
服務器返回最終消息，表明用戶不存在於請求-URI指定的域中。當請求URI的域與接收請求的域不匹配時，也會生成此回復。
4.6不允許405方法
服務器支持請求行中的方法，但不允許將此方法應用於此請求-URI中的地址。
回復必須包含Allow頭字段，該字段包含指定地址允許的方法列表。
4.7不能接受
請求中的資源只會導致壹個錯誤，即不能在請求中的Accept報頭字段之外接收內容。
4.8 407需要代理認證
這個返回代碼類似於401(未授權)，但是它表示應該首先在代理上對客戶端進行身份驗證。SIP接入認證請參考第26節和第22.3節。
此返回代碼用於應用程序訪問通信網關(例如，電話網關)，很少用於被叫方請求身份驗證。
4.9 408請求超時
在壹段時間內，服務器無法生成最終的回復，比如不能及時確定用戶的位置。客戶端可以稍後再次嘗試請求，而不更改請求的內容。
4.10
請求的資源不再存在於此服務器上，我不知道將請求轉發到哪裏。這個問題將是永久性的。如果服務器不知道，或者不容易檢測到，這個資源的消失是暫時的還是永久的，它應該返回404(未找到)。
請求的實體太大。
服務器拒絕處理該請求，因為請求的實體超出了服務器希望或能夠處理的大小。此服務器應關閉連接，以防止客戶端重新發送此請求。
如果這種情況是暫時的，服務器應該包含壹個Retry-After頭字段，以表明這是壹個暫時的故障，客戶端可以在壹段時間後重試。
請求-URI時間太長
服務器拒絕了該請求，因為請求URI超出了服務器可以處理的長度。
4.13 415不支持的媒體類型
服務器拒絕處理該請求，因為服務器不支持所請求的郵件正文的格式。該服務器必須根據內容的失敗類型返回Accept、Accpet-Encoding或Accept-Language頭字段的列表。UAC根據第8.1.3.5節中定義的方法處理該響應。
不支持的URI方案
服務器停止處理此請求，因為它不支持請求-URI中的URI方案。客戶端參照8.1.3.5處理此回復。
4.15錯誤的擴展名
服務器不知道請求中的Proxy-Require(20.29)或Require(20.32)報頭字段中指示的協議擴展。服務器必須在不支持的頭字段中列出不支持的擴展名。UAC對此回復的處理見8.1.3.5。
4.16 421需要延期
UAS需要壹個特定的擴展來處理此請求，但是此擴展沒有列在請求的“支持的標頭”字段中。帶有此答案代碼的回復必須包含壹個要求頭字段，以列出所需的擴展名。
UAS不應該使用這種回復，除非它真的不能為客戶提供有效的服務。相反，如果所需的擴展沒有在Support頭字段中列出，服務器應該根據基準SIP兼容方法和客戶端支持的擴展來處理它。
4.17 423間隔太短
服務器拒絕了請求，因為請求中設置的資源刷新時間(或有效時間)太短。註冊服務器可以使用該響應來拒絕那些Contact報頭字段的有效期太短的註冊請求。第10.2.8、10.3和20.23節介紹並解釋了此響應和相關Min-Expires報頭字段的用法。
4.18 480暫時不可用
該請求成功到達被叫方的終端系統，但是被叫方當前不可用(例如，未登錄，或者登錄但是狀態無法通信，或者標記為“請勿打擾”)。回復應在重試後標記適當的重新傳輸時間。此用戶在其他地方也可能有效(在此服務器中未知)。原因短語應該指出被叫方暫時不可用的更詳細的原因。該值應可由UA設置。狀態代碼486(此處為Busy)可用於更準確地指示該請求失敗的具體原因。
該狀態碼也可以由轉發服務或代理服務器返回，因為它們發現由請求-URI指定的用戶存在，但是對於該用戶沒有合適的當前轉發地址。
4.19 481呼叫/交易不存在
此狀態表示UAS收到了請求，但它與現有的會話或事務不匹配。
4.20檢測到482回路
服務器檢測到壹個循環(16.3/4)。
4.21 483跳數過多
服務器收到最大轉發數(20.22)頭字段為0的請求。
4.22 484地址不完整
服務器收到壹個不完整的請求-URI。原因短語中應該有附加信息。此狀態代碼可能與撥號重疊。在撥號時，客戶端不知道撥號字符串的長度。它發送增加長度的字符串，並提示用戶輸入更多的字符串，直到484(地址不完整)響應不再出現。
4.23 485不明確
這個請求——URI是模棱兩可的。回復可以在聯系人頭字段中包含可能的顯式地址列表。這個提示列表可能會在安全和隱私方面對用戶或組織造成損害。配置必須能夠決定是否用404(NotFound)替換此回復，或者禁止對不明確的地址使用可能的選擇列表。
用請求回答請求的例子——URI:
sip: lee@example.com:
SIP/2.0 485不明確
聯系人:卡羅爾·李
聯系人:李平
聯系人:李·富特
壹些電子郵件和語音郵件系統提供這種功能。此狀態代碼不同於3xx狀態代碼:對於300，假設同壹個人或服務有不同的地址選擇。因此，對於3xx，自動系統選擇或連續搜索是有效的，但對於485(不明確)響應，用戶幹預是必要的。
4.24 486這裏很忙
當成功聯系到被叫方的終端系統，但被叫方目前無法在該終端系統上應答呼叫時，應在更合適的時間將應答反饋給主叫方，以便在“重試後”報頭字段中重試。這個用戶在其他地方可能是有效的，比如電話郵箱系統等等。如果我們知道沒有其他終端系統可以應答這個呼叫，我們應該返回壹個狀態碼600(到處都忙)。
487請求終止
請求被BYE或CANCEL終止。此回復將永遠不會回復取消請求本身。
4.26 488此處不可接受
此回復與606(不可接受)具有相同的含義，但它僅對於請求所指示的特定資源(URI)是不可接受的，該請求在其他地方可能是可接受的。
包含媒體兼容性描述的消息體可以出現在響應中，並根據INVITE請求中的Accept報頭字段進行規範化(如果沒有Accept報頭字段，則為application/sdp)。這個響應就像對OPTIONS請求的200(OK)響應的消息體。
4.27 491請求待定
在同壹個對話中，UAS收到的請求有壹個正在處理的相關請求。14.2描述了這種情況應該如何解決。
無法辨認
UAS收到壹個包含加密MIME的請求，但不知道或沒有提供合適的解密密鑰。該回復可以包含單個數據包，並且該數據包包含適當的公鑰，該公鑰用於加密該UAS通信中的數據包。詳情見第23.2節。
5服務器故障5xx
5xx響應是服務器本身出現故障時給出的故障響應。
5.1 500服務器內部錯誤
服務器遇到未知情況，無法繼續處理請求。客戶端可以顯示特定的錯誤情況，並在幾秒鐘後重試請求。
如果這種情況是暫時的，服務器應該在Retry-After標頭指示客戶端經過多少秒後重試請求。
5.2 501未實施
服務器沒有實現相關的請求功能。當UAS不知道請求的方法並且不能為每個用戶支持這個方法時，它應該返回這個回復。(無論請求的方法如何，代理都會轉發請求)。
註意405(不允許方法)是因為服務器實現了這個請求方法，但是在特定的請求中不支持這個請求方法。
5.3 502不良網關
如果服務器作為網關或代理存在，它會收到來自下遊服務器的非法回復(對應於該回復的請求由該服務器轉發到下遊服務器，以便完成該請求)。
5.4 503服務不可用
由於臨時過載或服務器管理，服務器暫時不可用。服務器可以在回復中添加Retry-After，讓客戶端重試請求。如果沒有Retry-After，客戶端必須將其視為收到500(服務器內部錯誤)響應。
客戶端(代理或UAC)應該在收到503(服務不可用)後嘗試將請求轉發到另壹個服務器。和其他請求不應在“重試後”標頭字段中指定的時間內轉發到此服務器。
作為503(服務不可用)的替代方案，服務器可以拒絕連接或丟棄請求。
5.5 504服務器超時
服務器沒有收到外部服務器的及時回復。此服務器需要此外部服務器來訪問和處理此請求。如果從上遊服務器收到的請求中的Expires頭字段超時，則應返回408(請求超時)錯誤。
不支持5.6 505版本
服務器不支持相應的SIP版本。服務器無法處理與客戶端提供的主版本號相同的請求，這將導致這樣的錯誤消息。
5.7消息到大
服務器無法處理該請求，因為消息長度超過了處理長度。
6個全球故障6xx
6xx回復意味著服務器有給特定用戶的最終消息，而不僅僅是請求的特定實例-URI。
6.1 600到處忙
成功聯系被叫方終端系統，但被叫方處於占線狀態，不打算接電話。通過添加重試後報頭字段，該回復可以更清楚地告訴呼叫者繼續呼叫需要多長時間。如果被叫方不想被提示拒絕的原因，被叫方應該使用603(拒絕)。只有當終端系統知道沒有其他終端節點(如語音郵件系統)可以訪問該用戶時，才能使用該回復。否則，應該返回壹個486(此處繁忙)回復。
6.2 603下降
當被叫方設備接入成功，但用戶明確不想接聽時。通過添加重試後報頭字段，該回復可以更清楚地告訴呼叫者繼續呼叫需要多長時間。只有當終端知道沒有其他終端設備可以響應這個呼叫的勢能時，才能給出這個回復。
6.3 604不存在於任何地方
服務器在請求中驗證了請求的用戶信息-URI，它在任何地方都不存在。
6.4 606不可接受
成功聯系UA，但未收到會話描述的某些部分，如請求的媒體、帶寬或地址類型。
606(NotAcceptable)響應表示用戶想要交流，但不能完全支持對話描述。606(不可接受)回復可以在警告報頭字段中包括原因列表，以解釋為什麽不支持會話描述。第20.43節列出了警告原因代碼。
在響應中，可以出現包含媒體兼容性描述的消息體，該消息體的格式按照INVITE請求中Accept頭字段指示的格式進行規範化(如果沒有Accept頭字段，則為application/sdp)，就像OPTIONS的200(OK)響應中的消息壹樣。
我們希望不經常需要這些媒體協商，並且當新用戶被邀請加入現有會話時，可能不需要該媒體協商。這取決於邀請的發起者是否需要處理606(不接受)。