sip錯(cuò)誤代碼報(bào)告

lxx=通知性應(yīng)答100正在嘗試180正在撥打181正被轉(zhuǎn)接182正在排隊(duì)183通話進(jìn)展2xx=勝利應(yīng)答2000K202被接受：用于轉(zhuǎn)介3xx=轉(zhuǎn)接應(yīng)答.300多項(xiàng)選擇301被永久遷移302被短暫遷移305運(yùn)用代理服務(wù)器380替代服務(wù)4xx=呼叫失敗Accpet-Encoding,或者Accept-Language頭域列表。UAC依據(jù)8.1.3.5節(jié)定義的方法處理這個(gè)應(yīng)答。14416UnsupportedURIScheme服務(wù)器由于不支持Request-URI中的URI方案而終止處理這個(gè)懇求?？蛻舳颂幚磉@個(gè)應(yīng)答參照8.。BadExtension服務(wù)器不知道在懇求中的Proxy-Require(20.29)或者Require(20.32)頭域所指出的協(xié)議擴(kuò)展。服務(wù)器必需在Unsupported頭域中列出不支持的擴(kuò)展。UAC處理這個(gè)應(yīng)答請(qǐng)參見421ExtensionRequiredUAS須要特定的擴(kuò)展來處理這個(gè)懇求，但是這個(gè)擴(kuò)展并沒有在懇求的Supported頭域中列出。具有這個(gè)應(yīng)答碼的應(yīng)答必需包含一個(gè)Require頭域列出所須要的擴(kuò)展。UAS不應(yīng)當(dāng)運(yùn)用這個(gè)應(yīng)答除非它真的不能給客戶端供應(yīng)有效的服務(wù)。相反,假如在Support頭域中沒有列出須要的擴(kuò)展，服務(wù)器應(yīng)當(dāng)依據(jù)基準(zhǔn)的SIP兼容的方法和客戶端支持的擴(kuò)展來進(jìn)行處理。423IntervalTooBrief服務(wù)器因?yàn)樵趹┣笾性O(shè)置的資源刷新時(shí)間(或者有效時(shí)間)過短而拒絕懇求。這個(gè)應(yīng)答可以用于注冊服務(wù)器來拒絕那些Contact頭域有效期過短的注冊懇求。這個(gè)應(yīng)答的用法和相關(guān)的Min-Expires頭域在2.8,10.3,20.23節(jié)中介紹和說明。懇求勝利到達(dá)被叫方的終端系統(tǒng)，但是被叫方當(dāng)前不行用（例如，沒有登陸，或者登陸了但是狀態(tài)是不能通訊，或者有“請(qǐng)勿打攪”的標(biāo)記）。應(yīng)答應(yīng)當(dāng)在Retr-After中標(biāo)記一個(gè)合適的重發(fā)時(shí)間。這個(gè)用戶也有可能在其他地方是有效的（在本服務(wù)器中不知道）。Reason-Phrase（緣由短句）應(yīng)當(dāng)提示更具體的緣由，為什么被叫方短暫不行用。這個(gè)值應(yīng)當(dāng)是可以被UA設(shè)置的。狀態(tài)碼486（BusyHere）可以用來更精確的表示本懇求失敗的特定緣由。這個(gè)狀態(tài)碼也可以是轉(zhuǎn)發(fā)服務(wù)或者proxy服務(wù)器返回的，因?yàn)樗麄儼l(fā)覺Request-URI指定的用戶存在，但是沒有一個(gè)給這個(gè)用戶的合適的當(dāng)前轉(zhuǎn)發(fā)的地址。481Call/TransactionDoesNotExist這個(gè)狀態(tài)表示了UAS接收到懇求，但是沒有和現(xiàn)存的對(duì)話或者事務(wù)匹配。482LoopDetected服務(wù)器檢測到了一個(gè)循環(huán)（16.3/4）483TooManyHops服務(wù)器接收到了一個(gè)懇求包含的Max-Forwards（20.22）頭域是022484AddressInComplete服務(wù)器接收到了一個(gè)懇求，它的Request-URI是不完整的。在緣由短語中應(yīng)當(dāng)有附加的信息說明。這個(gè)狀態(tài)碼可以和撥號(hào)交疊。在和撥號(hào)交疊中，客戶端不知道撥號(hào)串的長度。它發(fā)送增加長度的字串，并且提示用戶輸入更多的字串，直到不在出現(xiàn)484（AddressIncomplete）應(yīng)答為止。Request-URI是不明確的。應(yīng)答可以在Contact頭域中包含一個(gè)可能的明確的地址列表。這個(gè)提示列表肯囊個(gè)在平安性和隱私性對(duì)用戶或者組織造成破壞。必需能夠由配置確定是否以404(NotFound)代替這個(gè)應(yīng)答，又或者禁止對(duì)不明確的地址運(yùn)用可能的選擇列表。給帶有Request-URI的懇求的一個(gè)應(yīng)答例子：sip:turbot.xu@lanyearsSIP/2.0485AmbiguousContact:David.QianContact:LeoHuuContact:M.Foote部分email和語音郵箱系統(tǒng)供應(yīng)了這個(gè)功能。這個(gè)狀態(tài)碼和3xx狀態(tài)碼不同：對(duì)于300來說，它是假定同一個(gè)人或者服務(wù)有不同的地址選擇。所以對(duì)3xx來說，自動(dòng)選擇系統(tǒng)或者連續(xù)查找就有效，但是對(duì)485(Ambiguous)應(yīng)答來說，肯定要用戶的干預(yù)。4.24486BusyHere當(dāng)勝利聯(lián)系到被叫方的終端系統(tǒng)，但是被叫方當(dāng)前在這個(gè)終端系統(tǒng)上不能接聽這個(gè)電話，那么應(yīng)答應(yīng)當(dāng)回給呼叫方一個(gè)更合適的時(shí)間在Retry-After頭域重試。這個(gè)用戶或許在其他地方有效，比如電話郵箱系統(tǒng)等等。假如我們知道沒有其他終端系統(tǒng)能夠接聽這個(gè)呼叫，那么應(yīng)當(dāng)返回一個(gè)狀態(tài)碼600(BusyEverywhere)。懇求被BYE或者CANCEL所終止。這個(gè)應(yīng)答恒久不會(huì)給CANCEL懇求本身回復(fù)。26488NotAcceptableHere這個(gè)應(yīng)答和606(NotAcceptable)有相同的含義，但是只是應(yīng)用于Request-URI所指出的特定資源不能接受，在其他地方懇求可能可以接受。包含了媒體兼容性描述的消息體可以出現(xiàn)在應(yīng)答中，并且依據(jù)INVITE懇求中的Accept頭域進(jìn)行規(guī)格化(假如沒有Accept頭域，那么就是application/sdp)。這個(gè)應(yīng)答就像給OPTIONS懇求的200(0K)應(yīng)答的消息體一樣。4.27491RequestPending在同一個(gè)對(duì)話中，UAS接收到的懇求有一個(gè)依靠的懇求正在處理。14.2描述了這種狀況應(yīng)當(dāng)怎樣解決。4.28493UndecipherableUAS接收到了一個(gè)懇求，包含了一個(gè)加密的MIME,并且不知道或者沒有供應(yīng)合適的解密密鑰。這個(gè)應(yīng)答可以包含單個(gè)包體，這個(gè)包體包含了合適的公鑰，這個(gè)公鑰用于給這個(gè)UAS通訊中加密包體運(yùn)用的。細(xì)微環(huán)節(jié)描述在23.2節(jié)。5ServerFailure5xx5xx應(yīng)答是當(dāng)服務(wù)器本身故障的時(shí)候給出的失敗應(yīng)答。500ServerInternalError服務(wù)器遇到了未知的狀況，并且不能接著處理懇求?？蛻舳丝梢燥@示特定的錯(cuò)誤狀況，并且可以在幾秒種以后重新嘗試這個(gè)懇求。假如這個(gè)狀況是臨時(shí)的，服務(wù)器應(yīng)當(dāng)在Retry-After頭域標(biāo)記客戶端過多少秒鐘之后重新嘗試這個(gè)懇求。2501NotImplemented服務(wù)器沒有實(shí)現(xiàn)相關(guān)的懇求功能。當(dāng)UAS不相識(shí)懇求的方法的時(shí)候，并且對(duì)每一個(gè)用戶都無法支持這個(gè)方法的時(shí)候，應(yīng)當(dāng)返回這個(gè)應(yīng)答。(proxy不考慮懇求的方法而轉(zhuǎn)發(fā)懇求)。留意405(MethodNotAllowed)是因?yàn)榉?wù)器實(shí)現(xiàn)了這個(gè)懇求方法，但是這個(gè)懇求方法在特定懇求中不被支持。3502BadGateway假如服務(wù)器，作為gateway或者proxy存在，從下行服務(wù)器上接收到了一個(gè)非法的應(yīng)答(這個(gè)應(yīng)答對(duì)應(yīng)的懇求是本服務(wù)器為了完成懇求而轉(zhuǎn)發(fā)給下行服務(wù)器的)。4503ServiceUnavailable由于臨時(shí)的過載或者服務(wù)器管理導(dǎo)致的服務(wù)器短暫不行用。這個(gè)服務(wù)器可以在應(yīng)答中增加一個(gè)Retry-After來讓客戶端重試這個(gè)懇求。假如沒有Retry-After指出，客戶端必需就像收到了一個(gè)500(ServerInternalError)應(yīng)答一樣處理?？蛻舳?proxy或者UAC)收到503(ServiceUnavailable)應(yīng)當(dāng)嘗試轉(zhuǎn)發(fā)這個(gè)懇求到另外一個(gè)服務(wù)器處理。并且在Retry-After頭域中指定的時(shí)間內(nèi)，不應(yīng)當(dāng)轉(zhuǎn)發(fā)其他懇求到這個(gè)服務(wù)器。作為503(ServiceUnavaliable)的替代，服務(wù)器可以拒絕連接或者把懇求扔掉。5.5504ServerTime-out服務(wù)器在一個(gè)外部服務(wù)器上沒有收到一個(gè)與時(shí)的應(yīng)答。這個(gè)外部服務(wù)器是本服務(wù)器用來訪問處理這個(gè)懇求所須要的。假如從上行服務(wù)器上收到的懇求中的Expires頭域超時(shí)，那么應(yīng)當(dāng)返回一個(gè)408(RequestTimeOut)錯(cuò)誤。6505VersionNotSupported服務(wù)器不支持對(duì)應(yīng)的SIP版本。服務(wù)器是無法處理具有客戶端供應(yīng)的相同主版本號(hào)的懇求，就會(huì)導(dǎo)致這樣的錯(cuò)誤信息。7MessageToLarge服務(wù)器無法處理懇求，因?yàn)橄㈤L度超過了處理的長度。GlobalFailures6xx6xx應(yīng)答意味這服務(wù)器給特定用戶有一個(gè)最終的信息，并不只是在Request-URT的特定實(shí)例有最終信息。600BusyEverywhere勝利聯(lián)系到被叫方的終端系統(tǒng)，但是被叫方處于忙的狀態(tài)，并不準(zhǔn)備接聽電話。這個(gè)應(yīng)答可以通過增加一個(gè)Retry-After頭域更明確的告知呼叫方多久以后可以接著呼叫。假如被叫方不希望提示拒絕的緣由，被叫方應(yīng)當(dāng)運(yùn)用603(Decline)o只有當(dāng)終端系統(tǒng)知道沒有其他終端節(jié)點(diǎn)(比如語音郵箱系統(tǒng))能夠訪問到這個(gè)用戶的時(shí)候才能運(yùn)用這個(gè)應(yīng)答。否則應(yīng)當(dāng)返回一個(gè)486(BusyHere)的應(yīng)答。603Decline當(dāng)勝利訪問到被叫方的設(shè)備，但是用戶明確的不想應(yīng)答。這個(gè)應(yīng)答可以通過增加一個(gè)Retry-After頭域更明確的告知呼叫方多久以后可以接著呼叫。只有當(dāng)終端知道沒有其他任何終端設(shè)備能夠響應(yīng)這個(gè)呼叫的勢能才能給出這個(gè)應(yīng)答。604DoesNotExistsAnywhere服務(wù)器驗(yàn)證了在懇求中Request-URI的用戶信息，哪里都不存在4606NotAcceptable當(dāng)勝利聯(lián)系到一個(gè)UA,但是會(huì)話描述的一些部分比如懇求的媒體，帶寬，或者地址類型不被接收。606(NotAcceptable)應(yīng)答意味著用戶希望通訊，但是不能充分支持會(huì)話描述。606(NotAcceptable)應(yīng)答可以在Warning頭域中包含一個(gè)緣由列表，用于說明為何會(huì)話描述不能被支持。警告緣由代碼在20.43節(jié)中列出。在應(yīng)答中，可以出現(xiàn)一個(gè)包含媒體兼容性描述的消息體，這個(gè)消息體的格式依據(jù)INVITE懇求中的Accept頭域指出的格式進(jìn)行規(guī)格化(假如沒有Accept頭域，那么就是application/sdp),就像給OPTIONS親求的200(0K)應(yīng)答中的消息一樣。我們希望這些媒體協(xié)商不要常常須要，并且當(dāng)一個(gè)新用戶被邀請(qǐng)加入已經(jīng)存在的會(huì)話的時(shí)候，這個(gè)媒體協(xié)商可能不須要。這取決于邀請(qǐng)的初始化者是否須要對(duì)606(NotAcceptable)進(jìn)行處理。這個(gè)應(yīng)答只有當(dāng)客戶端知道沒有其他終端能夠處理這個(gè)懇求的時(shí)候才能發(fā)出。400呼叫不當(dāng)401未經(jīng)授權(quán)：只供注冊機(jī)構(gòu)運(yùn)用，代理服務(wù)器應(yīng)運(yùn)用代理服務(wù)器授權(quán)407402要求付費(fèi)（預(yù)訂為將來運(yùn)用）403被禁止的404未發(fā)覺：未發(fā)覺用戶405不允許的方法406不行接受407須要代理服務(wù)器授權(quán)408呼叫超時(shí)：在預(yù)定時(shí)間內(nèi)無法找到用戶410已消逝：用戶曾經(jīng)存在，但已從今處消逝413呼叫實(shí)體過大414呼叫URI過長415不支持的媒體類型416不支持的URI方案420不當(dāng)擴(kuò)展：運(yùn)用了不當(dāng)SIP協(xié)議擴(kuò)展，服務(wù)器無法理解該擴(kuò)展421須要擴(kuò)展423時(shí)間間隔過短480短暫不行運(yùn)用481通話/事務(wù)不存在482檢測到循環(huán)483跳數(shù)過多484地址不全485模糊不清486此處太忙487呼叫被終止488此處不行接受491呼叫待批493無法解讀：無法解讀S/MIME文體部分5xx=服務(wù)器失敗500服務(wù)器內(nèi)部錯(cuò)誤501無法實(shí)施：SIP呼叫方法在此處無法實(shí)施502不當(dāng)網(wǎng)關(guān)503服務(wù)不行運(yùn)用504服務(wù)器超時(shí)505不支持該版本：服務(wù)器不支持SIP協(xié)議的這個(gè)版本513消息過長6xx=全局失敗600各處均忙.603拒絕604無處存在606不行運(yùn)用代碼詳解:SIP協(xié)議應(yīng)答碼應(yīng)答代碼應(yīng)答碼是包含了，并且擴(kuò)展了HTTP/1.1應(yīng)答碼。并不是全部的HTTP/1.1應(yīng)答碼都適當(dāng)應(yīng)用，只有在折里指出的是適當(dāng)?shù)?。其他HTTP/L1應(yīng)答碼不應(yīng)當(dāng)運(yùn)用。并且，SIP也定義了新的應(yīng)答碼系列，6xxo1臨時(shí)應(yīng)答lxx臨時(shí)應(yīng)答，也就是消息性質(zhì)的應(yīng)答，標(biāo)記了對(duì)方服務(wù)器正在處理懇求，并且還沒有確定最終的應(yīng)答。假如服務(wù)器處理懇求須要花200ms以上才能產(chǎn)生終結(jié)應(yīng)答的時(shí)候，它應(yīng)當(dāng)發(fā)送一個(gè)lxx應(yīng)答。留意lxx應(yīng)答并不是牢靠傳輸?shù)?。他們不?huì)導(dǎo)致客戶端傳送一個(gè)ACK應(yīng)答。臨時(shí)性質(zhì)的（lxx）應(yīng)答可以包含消息體，包含會(huì)話描述。100Trying這個(gè)應(yīng)答表示下一個(gè)節(jié)點(diǎn)的服務(wù)器已經(jīng)接收到了這個(gè)懇求并且還沒有執(zhí)行這個(gè)懇求的特定動(dòng)作（比如，正在打開數(shù)據(jù)庫的時(shí)候）。這個(gè)應(yīng)答，就像其他臨時(shí)應(yīng)答一樣,種植了UAC重新傳送INVITE懇求。100（Trying）應(yīng)答和其他臨時(shí)應(yīng)答不同的是，在這里，它恒久不會(huì)被有狀態(tài)proxy轉(zhuǎn)發(fā)到上行流中。180RingingUA收到INVITE懇求并且試圖提示給用戶。這個(gè)應(yīng)答應(yīng)當(dāng)出世化一個(gè)本地回鈴。1.3818CallisBeingForwarded（呼叫被轉(zhuǎn)發(fā)）服務(wù)器可以用這個(gè)應(yīng)答代碼來表示呼叫正在轉(zhuǎn)發(fā)到另一個(gè)目的地集合。1.4182Queued當(dāng)呼叫的對(duì)方短暫不能接收呼叫的時(shí)候，并且服務(wù)器確定將呼叫排隊(duì)等候，而不是拒絕呼叫的時(shí)候，那么就應(yīng)當(dāng)發(fā)出這個(gè)應(yīng)答。當(dāng)被叫方一旦復(fù)原接收呼叫，他會(huì)返回合適的終結(jié)應(yīng)答。對(duì)于這個(gè)呼叫狀態(tài)，可以有一個(gè)表示緣由的短語，比如："5callsqueued;expectedwaitingtimeis15minutes"。服務(wù)器可以給出好幾個(gè)182（Queued）應(yīng)答告知呼叫方排隊(duì)的狀況（比如排隊(duì)靠前了等等）。5183會(huì)話進(jìn)度183（SessionProgress）應(yīng)答用于提示建立對(duì)話的進(jìn)度信息。Reason-Phrase（表達(dá)緣由的句子）、頭域或者消息體可以用于提示呼叫進(jìn)度的更消息的信息。2勝利信息2xx這個(gè)應(yīng)答表示懇求是勝利的。12000K懇求已經(jīng)處理勝利。這個(gè)信息取決于不同方法的懇求的應(yīng)答。3轉(zhuǎn)發(fā)懇求3XX3xx系列的應(yīng)答是用于提示用戶的新位置信息的，或者為了滿意呼叫而轉(zhuǎn)發(fā)的額外服務(wù)地點(diǎn)。1300MultipleChoices懇求的地址有多個(gè)選擇，每個(gè)選擇都有自己的地址，用戶或者(UA)可以選擇合適的通訊終端，并且轉(zhuǎn)發(fā)這個(gè)懇求到這個(gè)地址。應(yīng)答可以包含一個(gè)具有每一個(gè)地點(diǎn)的在Accept懇求頭域中允許的資源特性，這樣用戶或者UA可以選擇一個(gè)最合適的地址來轉(zhuǎn)發(fā)懇求。沒有未這個(gè)應(yīng)答的消息體定義MIME類型。這些地址選擇也應(yīng)當(dāng)在Contact頭域中列出(20.10節(jié))。不同于HTTP,SIP應(yīng)答可以包含多個(gè)Contact頭域或者一個(gè)Contact頭域中具有一個(gè)地址列表。UA可以運(yùn)用Contact頭域來自動(dòng)轉(zhuǎn)發(fā)或者要求用戶確認(rèn)轉(zhuǎn)發(fā)。不過，本規(guī)范沒有定義自動(dòng)轉(zhuǎn)發(fā)的標(biāo)準(zhǔn)。假如被叫方可以在多個(gè)地址被找到，并且服務(wù)器不能或者不情愿轉(zhuǎn)發(fā)懇求的時(shí)候，可以運(yùn)用這個(gè)應(yīng)答來給呼叫方。3.2301MovedPermently當(dāng)不能在Request-URI指定的地址找到用戶的時(shí)候，懇求的客戶端應(yīng)當(dāng)運(yùn)用Contact頭域(20.10)所指出的新的地址重新嘗試。懇求者應(yīng)當(dāng)用這個(gè)新的值來更新本地的書目，地址本，和用戶地址cache,并且在后續(xù)懇求中，發(fā)送到這個(gè)/這些列出的地址。3.3302MovedTemporarily懇求方應(yīng)當(dāng)把懇求重新發(fā)到這個(gè)Contact頭域所指出的新地址(20.10)。新懇求的Request-URI應(yīng)當(dāng)用這個(gè)應(yīng)答的Contact頭域所指出的值。在應(yīng)答中的Expires(20.19節(jié))或者Contact頭域的expires參數(shù)定義了這個(gè)ContactURI的生存周期。UA或者proxy在這個(gè)生存周期內(nèi)cache這個(gè)URL假如沒有嚴(yán)格的有效時(shí)見，那么這個(gè)地址僅僅本次有效，并且不能在以后的事務(wù)中保存。假如cache的Contact頭域的值失敗了，那么被轉(zhuǎn)發(fā)懇求的Request-URI應(yīng)當(dāng)再次嘗試一次。臨時(shí)URI可以比超時(shí)時(shí)間更快的失效，并且可以有一個(gè)新的臨時(shí)URI。4305UseProxy懇求的資源必需通過Contact頭域中指出的proxy來訪問。Contact頭域指定了一個(gè)proxy的URIo接收到這個(gè)應(yīng)答的對(duì)象應(yīng)當(dāng)通過這個(gè)proxy重新發(fā)送這個(gè)單個(gè)懇求。305(UseProxy)必需是UAS產(chǎn)生的。3.5380AlternativeService呼叫不成工，但是可以嘗試另外的服務(wù)。另外的服務(wù)在應(yīng)答的消息體中定義。消息體的格式在這里沒有定義，可能在以后的規(guī)范中定義。4懇求失敗4xx4xx應(yīng)答定義了特定服務(wù)器響應(yīng)的懇求失敗的狀況?？蛻舳瞬粦?yīng)當(dāng)在不更改懇求的狀況下重新嘗試同一個(gè)懇求。(例如，增加合適的認(rèn)證信息)。不過，同一個(gè)懇求交給不同服務(wù)器或許就會(huì)勝利。懇求中的語法錯(cuò)誤。Reason-Phrase應(yīng)當(dāng)標(biāo)記這個(gè)具體的語法錯(cuò)誤，比如“MissingCall-IDheaderfield”。4.2401Unauthorized懇求須要用戶認(rèn)證。這個(gè)應(yīng)答是由UAS和注冊服務(wù)器產(chǎn)生的，當(dāng)407(ProxyAuthenticationRequired)是proxy服務(wù)器產(chǎn)生的。3402PaymentRequired保留/以后運(yùn)用4403Forbidden服務(wù)端支持這個(gè)懇求，但是拒絕執(zhí)行懇求。增加驗(yàn)證信息是沒有必要的，并且懇求應(yīng)當(dāng)不被重試。4.5404NotFound服務(wù)器返回最終信息：用戶在RequestTJRI指定的域上不存在。當(dāng)Request-URI的domain和接收這個(gè)懇求的domain不匹配的狀況下，也會(huì)產(chǎn)生這個(gè)應(yīng)答。4