Sip 響應狀態碼功能對照詳解 - 程式人生

如果沒有Retry-After指出，客戶端必須就像收到了一個500（Server Internal Error）應答一樣處理。

客戶端（proxy或者UAC）收到503（Service Unavailable） ... 程式人生>>Sip響應狀態碼功能對照詳解 Sip響應狀態碼功能對照詳解 阿新••發佈：2018-03-05 sip錯誤碼SIP應答消息狀態碼與類型狀態碼狀態說明臨時應答(1XX)100Trying正在處理中180Ringing振鈴181callbeingforwarder呼叫正在前向182queue排隊181*sessionprogress會話進行會話成功(2XX)200OK會話成功重定向(3XX)300multiple多重選擇301movedpermanently永久移動302movedtemporaily臨時移動305useproxy用戶代理380alternativeservice替代服務請求失敗(4XX)400badrequest錯誤請求401unauthorized未授權402paymentrequired付費要求403forbidden禁止404notfound未發現405methodnoallowed方法不允許406notacceptable不可接受407proxyauthenticationrequired代理需要認證408requesttimeout請求超時410gone離開413requestentitytoolarge請求實體太大414request-urltoolong請求URL太長415unsupportedmediatype不支持的媒體類型416unsupportedurlscheme不支持的URL計劃420badextension不良擴展421extensionrequired需要擴展423intervaltoobrief間隔太短480temporarilyunavailable臨時失效481call/transactiondoesnotexist呼叫/事務不存在482loopdetected發現環路483toomanyhops跳數太多484addressincomplete地址不完整485ambiguous不明朗486busyhere這裏忙487requestterminated請求終止488notacceptablehere這裏請求不可接受491requestpending未決請求493undecipherable不可辨識服務器失敗(5XX)500serverinternalerror服務器內部錯誤501notimplemented不可執行502badgateway壞網關503serviceunavailable服務無效504servertime-out服務器超時505versionnotsupported版本不支持513messagetoolarge消息太大全局性錯誤(6XX)600busyeverywhere全忙603decline丟棄604doesnotexistanywhere不存在606notacceptable不可接受SIP應答代碼(以下是詳細內容)應答碼是包含了，並且擴展了HTTP/1.1應答碼。

並不是所有的HTTP/1.1應答碼都適當應用，只有在折裏指出的是適當的。

其他HTTP/1.1應答碼不應當使用。

並且，SIP也定義了新的應答碼系列，6xx。

1臨時應答1xx臨時應答，也就是消息性質的應答，標誌了對方服務器正在處理請求，並且還沒有決定最後的應答。

如果服務器處理請求需要花200ms以上才能產生終結應答的時候，它應當發送一個1xx應答。

註意1xx應答並不是可靠傳輸的。

他們不會導致客戶端傳送一個ACK應答。

臨時性質的（1xx）應答可以包含消息體，包含會話描述。

1.1100Trying這個應答表示下一個節點的服務器已經接收到了這個請求並且還沒有執行這個請求的特定動作（比如，正在打開數據庫的時候）。

這個應答，就像其他臨時應答一樣，種植了UAC重新傳送INVITE請求。

100(Trying)應答和其他臨時應答不同的是，在這裏，它永遠不會被有狀態proxy轉發到上行流中。

1.2180RingingUA收到INVITE請求並且試圖提示給用戶。

這個應答應當出世化一個本地回鈴。

1.3818CallisBeingForwarded(呼叫被轉發)服務器可以用這個應答代碼來表示呼叫正在轉發到另一個目的地集合。

1.4182Queued當 呼叫的對方暫時不能接收呼叫的時候，並且服務器決定將呼叫排隊等候，而不是拒絕呼叫的時候，那麽就應當發出這個應答。

當被叫方一旦恢復接收呼叫，他會返回 合適的終結應答。

對於這個呼叫狀態，可以有一個表示原因的短語，比如：”5callsqueued;expectedwaitingtime is15minutes”。

服務器可以給出好幾個182（Queued）應答告訴呼叫方排隊的情況（比如排隊靠前了等等）。

1.5183會話進度183（SessionProgress）應答用於提示建立對話的進度信息。

Reason-Phrase（表達原因的句子）、頭域或者消息體可以用於提示呼叫進度的更消息的信息。

2成功信息2xx這個應答表示請求是成功的。

2.1200OK請求已經處理成功。

這個信息取決於不同方法的請求的應答。

3轉發請求3XX3xx系列的應答是用於提示用戶的新位置信息的，或者為了滿足呼叫而轉發的額外服務地點。

3.1300MultipleChoices請求的地址有多個選擇，每個選擇都有自己的地址，用戶或者（UA）可以選擇合適的通訊終端，並且轉發這個請求到這個地址。

應答可以包含一個具有每一個地點的在Accept請求頭域中允許的資源特性，這樣用戶或者UA可以選擇一個最合適的地址來轉發請求。

沒有未這個應答的消息體定義MIME類型。

這些地址選擇也應當在Contact頭域中列出（20.10節）。

不同於HTTP，SIP應答可以包含多個Contact頭域或者一個Contact頭域 中具有一個地址列表。

UA可以使用Contact頭域來自動轉發或者要求用戶確認轉發。

不過，本規範沒有定義自動轉發的標準。

如果被叫方可以在多個地址被找到，並且服務器不能或者不願意轉發請求的時候，可以使用這個應答來給呼叫方。

3.2301MovedPermently當不能在Request-URI指定的地址找到用戶的時候，請求的客戶端應當使用Contact頭域(20.10)所指出的新的地址重新嘗試。

請求者應當用這個新的值來更新本地的目錄，地址本，和用戶地址cache，並且在後續請求中，發送到這個/這些列出的地址。

3.3302MovedTemporarily請求方應當把請求重新發到這個Contact頭域所指出的新地址(20.10)。

新請求的Request-URI應當用這個應答的Contact頭域所指出的值。

在應答中的Expires(20.19節)或者Contact頭域的expires參數定義了這個Contact URI的生存周期。

UA或者proxy在這個生存周期內cache這個URI。

如果沒有嚴格的有效時見，那麽這個地址僅僅本次有效，並且不能在以後的事務 中保存。

如果cache的Contact頭域的值失敗了，那麽被轉發請求的Request-URI應當再次嘗試一次。

臨時URI可以比超時時間更快的失效，並且可以有一個新的臨時URI。

3.4305UseProxy請求的資源必須通過Contact頭域中指出的proxy來訪問。

Contact頭域指定了一個proxy的URI。

接收到這個應答的對象應當通過這個proxy重新發送這個單個請求。

305（UseProxy）必須是UAS產生的。

3.5380AlternativeService呼叫不成工，但是可以嘗試另外的服務。

另外的服務在應答的消息體中定義。

消息體的格式在這裏沒有定義，可能在以後的規範中定義。

4請求失敗4xx4xx應答定義了特定服務器響應的請求失敗的情況。

客戶端不應當在不更改請求的情況下重新嘗試同一個請求。

（例如，增加合適的認證信息）。

不過，同一個請求交給不同服務器也許就會成功。

4.1400BadRequest請求中的語法錯誤。

Reason-Phrase應當標誌這個詳細的語法錯誤，比如”MissingCall-IDheaderfield”。

4.2401Unauthorized請求需要用戶認證。

這個應答是由UAS和註冊服務器產生的，當407（ProxyAuthenticationRequired）是proxy服務器產生的。

4.3402PaymentRequired保留/以後使用4.4403Forbidden服務端支持這個請求，但是拒絕執行請求。

增加驗證信息是沒有必要的，並且請求應當不被重試。

4.5404NotFound服務器返回最終信息：用戶在Request-URI指定的域上不存在。

當Request-URI的domain和接收這個請求的domain不匹配的情況下，也會產生這個應答。

4.6405MethodNotAllowed服務器支持Request-Line中的方法，但是對於這個Request-URI中的地址來說，是不允許應用這個方法的。

應答必須包括一個Allow頭域，這個頭域包含了指定地址允許的方法列表。

4.7NotAcceptable請求中的資源只會導致產生一個在請求中的Accept頭域外的，內容無法接收的錯誤。

4.8407ProxyAuthenticationRequired這個返回碼和401（Unauthorized）很類四，但是標誌了客戶端應當首先在proxy上通過認證。

SIP對認證的訪問請參見26節和22.3節。

這個返回碼用於應用程序訪問通訊網關（比如，電話網關），而很少用於被叫方要求認證。

4.9408RequestTimeout在一段時間內，服務器不能產生一個終結應答，例如，如果它無法及時決定用戶的位置。

客戶端可以在稍後不更改請求的內容然後重新嘗試請求。

4.10410Gone請求的資源在本服務器上已經不存在了，並且不知道應當把請求轉發到哪裏。

這個問題將會使永久性的。

如果服務器不知道，或者不容易檢測，這個資源消失是臨時性質的還是永久性質的，那麽應當返回一個404（NotFound）。

4.11413請求實體過大。

服務器拒絕處理請求，因為這個請求的實體超過了服務器希望或者能夠處理的大小。

這個服務器應當關閉連接避免客戶端重發這個請求。

如果這個情況是暫時的，那麽服務端應當包含一個Retry-After頭域來表明這是一個暫時的故障，並且客戶端可以過一段時間再次嘗試。

4.12414Request-URITooLong服務器拒絕這個請求，因為Request-URI超過了服務器能夠處理的長度。

4.13415UnsupportedMediaType服務器由於請求的消息體的格式本服務器不支持，所以拒絕處理這個請求。

這個服務器必須根據內容的故障類型，返回一個Accept，Accpet-Encoding,或者Accept-Language頭域列表。

UAC根據8.1.3.5節定義的方法處理這個應答。

4.14416UnsupportedURIScheme服務器由於不支持Request-URI中的URI方案而終止處理這個請求。

客戶端處理這個應答參照8.1.3.5。

4.15BadExtension服務器不知道在請求中的Proxy-Require(20.29)或者Require(20.32)頭域所指出的協議擴展。

服務器必須在Unsupported頭域中列出不支持的擴展。

UAC處理這個應答請參見8.1.3.54.16421ExtensionRequiredUAS需要特定的擴展來處理這個請求，但是這個擴展並沒有在請求的Supported頭域中列出。

具有這個應答碼的應答必須包含一個Require頭域列出所需要的擴展。

UAS不應當使用這個應答除非它真的不能給客戶端提供有效的服務。

相反，如果在Support頭域中沒有列出需要的擴展，服務器應當根據基準的SIP兼容的方法和客戶端支持的擴展來進行處理。

4.17423IntervalTooBrief服務器因為在請求中設置的資源刷新時間（或者有效時間）過短而拒絕請求。

這個應答可以用於註冊服務器來拒絕那些Contact頭域有效期過短的註冊請求。

這個應答的用法和相關的Min-Expires頭域在10.2.8,10.3,20.23節中介紹和說明。

4.18480TemporarilyUnavailable請求成功到達被叫方的終端系統，但是被叫方當前不可用（例如，沒有登陸，或者登陸了但是狀態是不能通訊，或者有”請勿打擾”的標記）。

應答應當在 Retry-After中標誌一個合適的重發時間。

這個用戶也有可能在其他地方是有效的（在本服務器中不知道）。

Reason-Phrase(原因短句) 應當提示更詳細的原因，為什麽被叫方暫時不可用。

這個值應當是可以被UA設置的。

狀態碼486（Busy Here）可以用來更精確的表示本請求失敗的特定原因。

這個狀態碼也可以是轉發服務或者proxy服務器返回的，因為他們發現Request-URI指定的用戶存在，但是沒有一個給這個用戶的合適的當前轉發的地址。

4.19481Call/TransactionDoesNotExist這個狀態表示了UAS接收到請求，但是沒有和現存的對話或者事務匹配。

4.20482LoopDetected服務器檢測到了一個循環(16.3/4)4.21483TooManyHops服務器接收到了一個請求包含的Max-Forwards(20.22)頭域是04.22484AddressInComplete服務器接收到了一個請求，它的Request-URI是不完整的。

在原因短語中應當有附加的信息說明。

這個狀態碼可以和撥號交疊。

在和撥號交疊中，客戶端 不知道撥號串的長度。

它發送增加長度的字串，並且提示用戶輸入更多的字串，直到不在出現484（AddressIncomplete）應答為止。

4.23485AmbiguousRequest-URI是不明確的。

應答可以在Contact頭域中包含一個可能的明確的地址列表。

這個提示列表肯囊個在安全性和隱私性對用戶或者組織造 成破壞。

必須能夠由配置決定是否以404（NotFound）代替這個應答，又或者禁止對不明確的地址使用可能的選擇列表。

給帶有Request-URI的請求的一個應答例子：sip:[email protected]:SIP/2.0485AmbiguousContact:CarolLeeContact:PingLeeContact:LeeM.Foote部分email和語音郵箱系統提供了這個功能。

這個狀態碼和3xx狀態碼不同：對於300來說，它是假定同一個人或者服務有不同的地址選擇。

所以對3xx來說，自動選擇系統或者連續查找就有效，但是對485（Ambiguous）應答來說，一定要用戶的幹預。

4.24486BusyHere當成功聯系到被叫方的終端系統，但是被叫方當前在這個終端系統上不能接聽這個電話，那麽應答應當回給呼叫方一個更合適的時間在Retry-After頭域 重試。

這個用戶也許在其他地方有效，比如電話郵箱系統等等。

如果我們知道沒有其他終端系統能夠接聽這個呼叫，那麽應當返回一個狀態碼600（Busy Everywhere）。

4.25487RequestTerminated請求被BYE或者CANCEL所終止。

這個應答永遠不會給CANCEL請求本身回復。

4.26488NotAcceptableHere這個應答和606（NotAcceptable）有相同的含義，但是只是應用於Request-URI所指出的特定資源不能接受，在其他地方請求可能可以接受。

包含了媒體兼容性描述的消息體可以出現在應答中，並且根據INVITE請求中的Accept頭域進行規格化（如果沒有Accept頭域，那麽就是application/sdp）。

這個應答就像給OPTIONS請求的200(OK)應答的消息體一樣。

4.27491RequestPending在同一個對話中，UAS接收到的請求有一個依賴的請求正在處理。

14.2描述了這種情況應當怎樣解決。

4.28493UndecipherableUAS接收到了一個請求，包含了一個加密的MIME,並且不知道或者沒有提供合適的解密密鑰。

這個應答可以包含單個包體，這個包體包含了合適的公鑰，這個公鑰用於給這個UAS通訊中加密包體使用的。

細節描述在23.2節。

5ServerFailure5xx5xx應答是當服務器本身故障的時候給出的失敗應答。

5.1500ServerInternalError服務器遇到了未知的情況，並且不能繼續處理請求。

客戶端可以顯示特定的錯誤情況，並且可以在幾秒種以後重新嘗試這個請求。

如果這個情況是臨時的，服務器應當在Retry-After頭域標誌客戶端過多少秒鐘之後重新嘗試這個請求。

5.2501NotImplemented服務器沒有實現相關的請求功能。

當UAS不認識請求的方法的時候，並且對每一個用戶都無法支持這個方法的時候，應當返回這個應答。

（proxy不考慮請求的方法而轉發請求）。

註意405（MethodNotAllowed）是因為服務器實現了這個請求方法，但是這個請求方法在特定請求中不被支持。

5.3502BadGateway如果服務器，作為gateway或者proxy存在，從下行服務器上接收到了一個非法的應答（這個應答對應的請求是本服務器為了完成請求而轉發給下行服務器的）。

5.4503ServiceUnavailable由於臨時的過載或者服務器管理導致的服務器暫時不可用。

這個服務器可以在應答中增加一個Retry-After來讓客戶端重試這個請求。

如果沒有Retry-After指出，客戶端必須就像收到了一個500（ServerInternalError）應答一樣處理。

客戶端（proxy或者UAC）收到503（ServiceUnavailable）應當嘗試轉發這個請求到另外一個服務器處理。

並且在Retry-After頭域中指定的時間內，不應當轉發其他請求到這個服務器。

作為503(ServiceUnavaliable)的替代，服務器可以拒絕連接或者把請求扔掉。

5.5504ServerTime-out服務器在一個外部服務器上沒有收到一個及時的應答。

這個外部服務器是本服務器用來訪問處理這個請求所需要的。

如果從上行服務器上收到的請求中的Expires頭域超時，那麽應當返回一個408（RequestTimeOut）錯誤。

5.6505VersionNotSupported服務器不支持對應的SIP版本。

服務器是無法處理具有客戶端提供的相同主版本號的請求，就會導致這樣的錯誤信息。

5.7MessageToLarge服務器無法處理請求，因為消息長度超過了處理的長度。

6GlobalFailures6xx6xx應答意味這服務器給特定用戶有一個最終的信息，並不只是在Request-URI的特定實例有最終信息。

6.1600BusyEverywhere成功聯系到被叫方的終端系統，但是被叫方處於忙的狀態，並不打算接聽電話。

這個應答可以通過增加一個Retry-After頭域更明確的告訴呼叫方多久以 後可以繼續呼叫。

如果被叫方不希望提示拒絕的原因，被叫方應當使用603（Decline）。

只有當終端系統知道沒有其他終端節點（比如語音郵箱系統）能 夠訪問到這個用戶的時候才能使用這個應答。

否則應當返回一個486（BusyHere）的應答。

6.2603Decline當成功訪問到被叫方的設備，但是用戶明確的不想應答。

這個應答可以通過增加一個Retry-After頭域更明確的告訴呼叫方多久以後可以繼續呼叫。

只有當終端知道沒有其他任何終端設備能夠響應這個呼叫的勢能才能給出這個應答。

6.3604DoesNotExistsAnywhere服務器驗證了在請求中Request-URI的用戶信息，哪裏都不存在6.4606NotAcceptable當成功聯系到一個UA,但是會話描述的一些部分比如請求的媒體，帶寬，或者地址類型不被接收。

606（NotAcceptable）應答意味著用戶希望通訊，但是不能充分支持會話描述。

606（NotAcceptable）應答可以在Warning頭域中包含一個原因列表，用於解釋為何會話描述不能被支持。

警告原因代碼在20.43節中列出。

在應答中，可以出現一個包含媒體兼容性描述的消息體，這個消息體的格式根據INVITE請求中的Accept頭域指出的格式進行規格化（如果沒有Accept頭域，那麽就是application/sdp），就像給OPTIONS親求的200(OK)應答中的消息一樣。

我們希望這些媒體協商不要經常需要，並且當一個新用戶被邀請加入已經存在的會話的時候，這個媒體協商可能不需要。

這取決於邀請的初始化者是否需要對606（NotAcceptable）進行處理。

這個應答只有當客戶端知道沒有其他終端能夠處理這個請求的時候才能發出。

Sip響應狀態碼功能對照詳解 ansible之script模塊 «上一篇 9.1裝飾器前提下一篇» 相關推薦 Sip響應狀態碼功能對照詳解 sip錯誤碼SIP應答消息狀態碼與類型狀態碼狀態說明臨時應答(1XX)100Trying正在處理中180Ringing振鈴181ca... 響應狀態碼 應該資源二次fonthtml註意顯示不存在ont100客戶端應當繼續發送請求。

這個臨時響應是用來通知客戶... HTTP響應狀態碼【總結】 管理指示get強制opp帶寬行修改accepted代碼常見的狀態碼【1XX】表示【消息】【2XX】表示【成... http響應狀態碼 acceptedhtml數據fin能夠err新的指示found文章摘自：http://hi.baidu.c... HTTP協議---HTTP請求中的常用請求字段和HTTP的響應狀態碼及響應頭 lengthlindiv處理過程o-c繼續意義spanutf基本HTTP協議 打開瀏覽器，輸入服務器... http中響應狀態碼表示的意義? forbidden信息servergpo由於tro永久erro選擇狀態代碼有三位數字組成，第一個數字定義了... 一般的響應狀態碼 0.10原因不可響應狀態禁止啟用要求internclientHTTP400-請求無效HTTP40... http協議響應狀態碼和響應頭     先簡單介紹一下吧，以後自己在實際開發中涉及到這方面會陸續補充。

  三：HTTP... http響應狀態碼總結 響應狀態碼 和請求報文相比，響應報文多了一個“響應狀態碼”，它以“清晰明確”的語言告訴客戶端本次請求的處理結果。

 HTTP的響... 所有HTTP的響應狀態碼 所有HTTP的響應狀態碼 1XX:被請求接收到，繼續處理 100：繼續 101：轉換協議... 搜尋 基礎教學 Mysql入門 Sql入門 Android入門 Docker入門 Go語言入門 Ruby程式入門 Python入門 Python進階 Django入門 Python爬蟲入門 最近訪問 Sip+響應狀態碼功能對照詳解 C#+基礎知識系列-+12+任務和多執行緒 當前上下文中不存在ViewBag 壓縮包裡修改檔案不能直接儲存 正確理解CSS中的margin合併 業務システムの開発ドキュメント標準化++第７回：結合テストと総合テスト 答疑1108晨迪問 linux+系統性能壓測工具簡介 Excel的下載和讀取，部分代碼（大神請路過） 【翻譯】第七章節：順序無關的透明度（關於順序無關的混合）