• 通信人家園

     找回密碼
     注冊

    只需一步,快速開始

    搜索

    軍銜等級:

      新兵

    注冊時間:
    2009-8-11
    跳轉到指定樓層
    1#
    發表于 2019-8-5 00:14:44 |只看該作者 |倒序瀏覽
    SIP協議消息代碼解釋詳
    內容

    1XX=通知性應答
    100 正在嘗試
    180 正在撥打
    181 正被轉接
    182 通話進展

    2XX= 成功答應
    200OK
    202 被接受:用于轉介

    3xx=轉接應答
    300 多項選擇
    301 被永久遷移
    302 被暫時遷移
    304 not modified
    305 使用代理服務器
    380 替代服務

    4xx = 呼叫失敗
    400 呼叫不當
    401 未經授權:只供注冊機構使用,代理服務器應使用代理服務器授權407
    402 要求付費(預定為將來使用)
    403 被禁止的
    404 未發現:未發現用戶
    405 不允許的方法
    406 不可接受
    407 需要代理服務器授權
    408呼叫超時:在預定時間內無法找到用戶
    410 已消失:用戶曾經存在,但已從此處消失
    413 呼叫實體過大
    414 呼叫URI過長
    415 不支持的媒體類型
    416 不支持的URI方案
    420 不當擴展:使用了不當SIP協議擴展,服務器無法理解擴展
    421 需要擴展
    423時間間隔過短
    480 暫時不可使用
    481 通話/事務不存在
    482 檢測到循環
    485 模糊不清
    486 此處太忙
    487 呼叫被禁止
    488此處不可接受
    489 bad  event
    491 呼叫待批
    493 無法解讀:無法解讀S/MIME文本

    5xx=服務器失敗
    500 服務器內部錯誤
    501 無法實施:SIP呼叫方法在此處無法實施
    502 不當網關
    503 服務器不使用
    504 服務器超時
    505 不支持該版本:服務器不支持SIP協議的這個版本
    513 消息過長

    6xx =全局失敗
    600 各處均忙
    603 拒絕
    604 無處存在
    606 不可使用
    代碼詳解:
    SIP協議應答碼
    應答代碼
    應答碼是包含了,并且擴展了HTTP/1.1應答碼。并不是所有的HTTP/1.1應答碼都適當應用,只有在折里指出的是適當的。其他HTTP/1.1應答碼不應當使用。并且,SIP也定義了新的應答碼系列,6xx。

    1 臨時應答1xx
    臨時應答,也就是消息性質的應答,標志了對方服務器正在處理請求,并且還沒有決定最后的應答。如果服務器處理請求需要花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: turbot.xu@lanyears.com

    SIP/2.0 485 Ambiguous
    Contact: David.Qian
    Contact: Leo Huu
    Contact: 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)進行處理。
    這個應答只有當客戶端知道沒有其他終端能夠處理這個請求的時候才能發出。
    已有 1 人評分家園幣 收起 理由
    liucmonkey + 1

    總評分: 家園幣 + 1   查看全部評分

    軍銜等級:

      新兵

    注冊時間:
    2017-12-18
    2#
    發表于 2019-8-5 09:37:34 |只看該作者

    點評

    Daisy1123  很好  詳情 回復 發表于 2019-8-8 13:50

    軍銜等級:

      二級軍士長

    注冊時間:
    2018-10-11
    3#
    發表于 2019-8-5 10:17:38 |只看該作者

    軍銜等級:

      一級通信軍士

    注冊時間:
    2015-8-12
    4#
    發表于 2019-8-5 10:31:52 |只看該作者
    好,收藏了。

    軍銜等級:

      上等兵

    注冊時間:
    2013-11-26
    5#
    發表于 2019-8-5 11:21:07 |只看該作者

    軍銜等級:

      少校

    注冊時間:
    2005-1-26
    6#
    發表于 2019-8-5 16:32:54 |只看該作者
    搞VOLTE所必須學習的。。。

    軍銜等級:

      新兵

    注冊時間:
    2019-8-5
    7#
    發表于 2019-8-6 00:00:06 來自手機 |只看該作者
    emmmmm,請問有什么基礎原理是可以推薦給準大一了解的嗎?

    軍銜等級:

      一級通信軍士

    注冊時間:
    2019-4-7
    8#
    發表于 2019-8-6 09:39:24 來自手機 |只看該作者
    本帖最后由 移動科技 于 2019-8-6 09:40 編輯

    2.6G是最好的5G頻段了,聯通電信建10個5G基站,移動只要建6個就可以達到聯通電信的效果,再說憑移動這樣的基站數量一定把電信聯通打得滿地找牙。

    現在2.6G用的64收64發 240W大功率AAU,下半年還有320W的

    現在不是有錢就能贏了,3.5G需要比2.6G多建1.5倍甚至更多的基站, 恕我直言、現在電聯夾在一起未必是移動對手

    軍銜等級:

      新兵

    注冊時間:
    2017-12-18
    9#
    發表于 2019-8-6 21:00:04 |只看該作者

    軍銜等級:

      新兵

    注冊時間:
    2018-12-5
    10#
    發表于 2019-8-8 13:50:06 |只看該作者
    sky888999 發表于 2019-8-5 09:37

    很好

    軍銜等級:

      上士

    注冊時間:
    2008-8-5
    11#
    發表于 2019-8-9 22:14:31 |只看該作者
    好!

    軍銜等級:

      一級軍士長

    注冊時間:
    2018-2-2
    12#
    發表于 2019-8-10 19:33:04 |只看該作者
    看起來那么像http狀態碼

    您需要登錄后才可以回帖 登錄 | 注冊 |

    Archiver|手機版|C114 ( 滬ICP備12002292號 )|聯系我們 |網站地圖  

    GMT+8, 2019-8-22 00:19 , Processed in 0.062500 second(s), 18 queries , Gzip On.

    Copyright © 1999-2019 C114 All Rights Reserved

    Discuz Licensed

    回頂部
    嫩妹妹