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