VoLTE SIP代碼意義及流程圖解

提交

我的留言

加載中

已留言

VoLTE SIP代碼意義及流程圖解 網(wǎng)優(yōu)雇傭軍  

微信號 hr_opt

功能介紹 通信、科技、未來！通信路上，一起走！

一 VOLTE SIP代碼意義

SIP應答消息狀態(tài)碼與功能

類型 狀態(tài)碼 狀態(tài)說明

臨時應答(1XX) 100 Trying 正在處理中

180 Ringing 振鈴

181 call being forwarder 呼叫正在前向

182 queue 排隊

181* session progress 會話進行

會話成功(2XX) 200 OK 會話成功

重定向(3XX) 300 multiple 多重選擇

301 moved permanently 永久移動

302 moved temporaily 臨時移動

305 use proxy 用戶代理

380 alternative service 替代服務

請求失敗(4XX) 400 bad request 錯誤請求

401unauthorized 未授權(quán)

402 payment required 付費要求

403 forbidden 禁止

404 not found 未發(fā)現(xiàn)

405 method no allowed 方法不允許

406 not acceptable 不可接受

407 proxy authentication required 代理需要認證

408 request timeout 請求超時

410 gone 離開

413 request entity too large 請求實體太大

414 request-url too long 請求URL太長

415 unsupported media type 不支持的媒體類型

416 unsupported url scheme 不支持的URL計劃

420 bad extension 不良擴展

421 extension required 需要擴展 

423 interval too brief 間隔太短

480 temporarily unavailable 臨時失效

481 call/transaction does not exist 呼叫/事務不存在

482 loop detected 發(fā)現(xiàn)環(huán)路

483 too many hops 跳數(shù)太多

484 address incomplete 地址不完整

485 ambiguous 不明朗

486 busy here 這里忙

487 request terminated 請求終止

488 not acceptable here 這里請求不可接受

491 request pending 未決請求

493 undecipherable 不可辨識

服務器失敗(5XX) 500 server internal error 服務器內(nèi)部錯誤

501 not implemented 不可執(zhí)行

502 bad gateway 壞網(wǎng)關

503 service unavailable 服務無效

504 server time-out 服務器超時

505 version not supported 版本不支持

513 message too large 消息太大

全局性錯誤(6XX) 600 busy everywhere 全忙

603 decline 丟棄

604 does not exist anywhere 不存在

606 not acceptable 不可接受

SIP應答代碼(以下是詳細內(nèi)容)

應答碼是包含了，并且擴展了HTTP/1.1應答碼。并不是所有的HTTP/1.1應答碼都適當應用，只有在折里指出的是適當?shù)�。其�?/span>HTTP/1.1應答碼不應當使用。并且，SIP也定義了新的應答碼系列，6xx。

1 臨時應答1xx 

臨時應答，也就是消息性質(zhì)的應答，標志了對方服務器正在處理請求，并且還沒有決定最后的應答。如果服務器處理請求需要花200ms以上才能產(chǎn)生終結(jié)應答的時候，它應當發(fā)送一個1xx應答。 

注意1xx應答并不是可靠傳輸?shù)�。他們不會導致客戶端傳送一個ACK應答。臨時性質(zhì)的（1xx）應答可以包含消息體，包含會話描述。 

1.1 100 Trying 

這個應答表示下一個節(jié)點的服務器已經(jīng)接收到了這個請求并且還沒有執(zhí)行這個請求的特定動作（比如，正在打開數(shù)據(jù)庫的時候）。這個應答，就像其他臨時應答一 樣，種植了UAC重新傳送INVITE請求。100(Trying)應答和其他臨時應答不同的是，在這里，它永遠不會被有狀態(tài)proxy轉(zhuǎn)發(fā)到上行流中。 

1.2 180 Ringing 

UA收到INVITE請求并且試圖提示給用戶。這個應答應當出世化一個本地回鈴。

1.3 818 Call is Being Forwarded(呼叫被轉(zhuǎn)發(fā)) 

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

1.4 182 Queued 

當 呼叫的對方暫時不能接收呼叫的時候，并且服務器決定將呼叫排隊等候，而不是拒絕呼叫的時候，那么就應當發(fā)出這個應答。當被叫方一旦恢復接收呼叫，他會返回 合適的終結(jié)應答。對于這個呼叫狀態(tài)，可以有一個表示原因的短語，比如：”5 calls queued;expected waiting time is 15minutes”。服務器可以給出好幾個182（Queued）應答告訴呼叫方排隊的情況（比如排隊靠前了等等）。

1.5 183 會話進度 

183（Session Progress）應答用于提示建立對話的進度信息。Reason-Phrase（表達原因的句子）、頭域或者消息體可以用于提示呼叫進度的更消息的信息。

2 成功信息2xx 

這個應答表示請求是成功的。 

2.1 200 OK 

請求已經(jīng)處理成功。這個信息取決于不同方法的請求的應答。 

3 轉(zhuǎn)發(fā)請求3XX 

3xx系列的應答是用于提示用戶的新位置信息的，或者為了滿足呼叫而轉(zhuǎn)發(fā)的額外服務地點。 

3.1 300 Multiple Choices 

請求的地址有多個選擇，每個選擇都有自己的地址，用戶或者（UA）可以選擇合適的通訊終端，并且轉(zhuǎn)發(fā)這個請求到這個地址。 

應答可以包含一個具有每一個地點的在Accept請求頭域中允許的資源特性，這樣用戶或者UA可以選擇一個最合適的地址來轉(zhuǎn)發(fā)請求。沒有未這個應答的消息體定義MIME類型。 

這些地址選擇也應當在Contact頭域中列出（20.10節(jié)）。不同于HTTP，SIP應答可以包含多個Contact頭域或者一個Contact頭域 中具有一個地址列表。UA可以使用Contact頭域來自動轉(zhuǎn)發(fā)或者要求用戶確認轉(zhuǎn)發(fā)。不過，本規(guī)范沒有定義自動轉(zhuǎn)發(fā)的標準。 

如果被叫方可以在多個地址被找到，并且服務器不能或者不愿意轉(zhuǎn)發(fā)請求的時候，可以使用這個應答來給呼叫方。 

3.2 301 Moved Permently 

當不能在Request-URI指定的地址找到用戶的時候，請求的客戶端應當使用Contact頭域(20.10)所指出的新的地址重新嘗試。請求者應當用這個新的值來更新本地的目錄，地址本，和用戶地址cache，并且在后續(xù)請求中，發(fā)送到這個/這些列出的地址。

3.3 302 Moved Temporarily 

請求方應當把請求重新發(fā)到這個Contact頭域所指出的新地址(20.10)。新請求的Request-URI應當用這個應答的Contact頭域所指出的值。 

在應答中的Expires(20.19節(jié))或者Contact頭域的expires參數(shù)定義了這個Contact URI的生存周期。UA或者proxy在這個生存周期內(nèi)cache這個URI。如果沒有嚴格的有效時見，那么這個地址僅僅本次有效，并且不能在以后的事務 中保存。 

如果cache的Contact頭域的值失敗了，那么被轉(zhuǎn)發(fā)請求的Request-URI應當再次嘗試一次。臨時URI可以比超時時間更快的失效，并且可以有一個新的臨時URI。 

3.4 305 Use Proxy 

請求的資源必須通過Contact頭域中指出的proxy來訪問。Contact頭域指定了一個proxy的URI。接收到這個應答的對象應當通過這個proxy重新發(fā)送這個單個請求。305（UseProxy）必須是UAS產(chǎn)生的。 

3.5 380 Alternative Service 

呼叫不成工，但是可以嘗試另外的服務。另外的服務在應答的消息體中定義。消息體的格式在這里沒有定義，可能在以后的規(guī)范中定義。 

4 請求失敗4xx 

4xx應答定義了特定服務器響應的請求失敗的情況�？蛻舳瞬粦�當在不更改請求的情況下重新嘗試同一個請求。（例如，增加合適的認證信息）。不過，同一個請求交給不同服務器也許就會成功。 

4.1 400 Bad Request 

請求中的語法錯誤。Reason-Phrase應當標志這個詳細的語法錯誤，比如”Missing Call-ID header field”。 

4.2 401 Unauthorized 

請求需要用戶認證。這個應答是由UAS和注冊服務器產(chǎn)生的，當407（Proxy Authentication Required）是proxy服務器產(chǎn)生的。 

4.3 402 Payment Required 

保留/以后使用 

4.4 403 Forbidden 

服務端支持這個請求，但是拒絕執(zhí)行請求。增加驗證信息是沒有必要的，并且請求應當不被重試。 

4.5 404 Not Found 

服務器返回最終信息：用戶在Request-URI指定的域上不存在。當Request-URI的domain和接收這個請求的domain不匹配的情況下， 也會產(chǎn)生這個應答。

4.6 405 Method Not Allowed 

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

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

4.7 Not Acceptable 

請求中的資源只會導致產(chǎn)生一個在請求中的Accept頭域外的，內(nèi)容無法接收的錯誤。 

4.8 407 Proxy Authentication Required 

這個返回碼和401（Unauthorized）很類四，但是標志了客戶端應當首先在proxy上通過認證。SIP對認證的訪問請參見26節(jié)和22.3節(jié)。 

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

4.9 408 Request Timeout 

在一段時間內(nèi)，服務器不能產(chǎn)生一個終結(jié)應答，例如，如果它無法及時決定用戶的位置。客戶端可以在稍后不更改請求的內(nèi)容然后重新嘗試請求。 

4.10 410 Gone 

請求的資源在本服務器上已經(jīng)不存在了，并且不知道應當把請求轉(zhuǎn)發(fā)到哪里。這個問題將會使永久性的。如果服務器不知道，或者不容易檢測，這個資源消失是臨時性質(zhì)的還是永久性質(zhì)的，那么應當返回一個404（Not Found）。 

4.11 413請求實體過大。 

服務器拒絕處理請求，因為這個請求的實體超過了服務器希望或者能夠處理的大小。這個服務器應當關閉連接避免客戶端重發(fā)這個請求。 

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

4.12 414 Request-URI Too Long 

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

4.13 415 Unsupported Media Type 

服務器由于請求的消息體的格式本服務器不支持，所以拒絕處理這個請求。這個服務器必須根據(jù)內(nèi)容的故障類型，返回一個Accept，Accpet-Encoding,或者Accept-Language頭域列表。UAC根據(jù)8.1.3.5節(jié)定義的方法處理這個應答。 

4.14 416 Unsupported URI Scheme 

服務器由于不支持Request-URI中的URI方案而終止處理這個請求�？蛻舳颂幚磉@個應答參照8.1.3.5。 

4.15 Bad Extension 

服務器不知道在請求中的Proxy-Require(20.29)或者Require(20.32)頭域所指出的協(xié)議擴展。服務器必須在Unsupported頭域中列出不支持的擴展。UAC處理這個應答請參見8.1.3.5 

4.16 421Extension Required 

UAS需要特定的擴展來處理這個請求，但是這個擴展并沒有在請求的Supported頭域中列出。具有這個應答碼的應答必須包含一個Require頭域列出所需要的擴展。 

UAS不應當使用這個應答除非它真的不能給客戶端提供有效的服務。相反，如果在Support頭域中沒有列出需要的擴展，服務器應當根據(jù)基準的SIP兼容的方法和客戶端支持的擴展來進行處理。 

4.17 423 Interval Too Brief 

服務器因為在請求中設置的資源刷新時間（或者有效時間）過短而拒絕請求。這個應答可以用于注冊服務器來拒絕那些Contact頭域有效期過短的注冊請求。這個應答的用法和相關的Min-Expires頭域在10.2.8,10.3,20.23節(jié)中介紹和說明。 

4.18 480 Temporarily Unavailable 

請求成功到達被叫方的終端系統(tǒng)，但是被叫方當前不可用（例如，沒有登陸，或者登陸了但是狀態(tài)是不能通訊，或者有”請勿打擾”的標記）。應答應當在 Retry-After中標志一個合適的重發(fā)時間。這個用戶也有可能在其他地方是有效的（在本服務器中不知道）。Reason-Phrase(原因短句) 應當提示更詳細的原因，為什么被叫方暫時不可用。這個值應當是可以被UA設置的。狀態(tài)碼486（Busy Here）可以用來更精確的表示本請求失敗的特定原因。 

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

4.19 481 Call/Transaction Does Not Exist 

這個狀態(tài)表示了UAS接收到請求，但是沒有和現(xiàn)存的對話或者事務匹配。 

4.20 482 Loop Detected 

服務器檢測到了一個循環(huán)(16.3/4) 

4.21 483 Too Many Hops 

服務器接收到了一個請求包含的Max-Forwards(20.22)頭域是0 

4.22 484 Address InComplete 

服務器接收到了一個請求，它的Request-URI是不完整的。在原因短語中應當有附加的信息說明。這個狀態(tài)碼可以和撥號交疊。在和撥號交疊中，客戶端 不知道撥號串的長度。它發(fā)送增加長度的字串，并且提示用戶輸入更多的字串，直到不在出現(xiàn)484（Address Incomplete）應答為止。 

4.23 485 Ambiguous 

Request-URI是不明確的。應答可以在Contact頭域中包含一個可能的明確的地址列表。這個提示列表肯囊個在安全性和隱私性對用戶或者組織造 成破壞。必須能夠由配置決定是否以404（NotFound）代替這個應答，又或者禁止對不明確的地址使用可能的選擇列表。 

給帶有Request-URI的請求的一個應答例子： 

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和語音郵箱系統(tǒng)提供了這個功能。這個狀態(tài)碼和3xx狀態(tài)碼不同：對于300來說，它是假定同一個人或者服務有不同的地址選擇。所以對3xx來說，自動選擇系統(tǒng)或者連續(xù)查找就有效，但是對485（Ambiguous）應答來說，一定要用戶的干預。 

4.24 486 Busy Here 

當成功聯(lián)系到被叫方的終端系統(tǒng)，但是被叫方當前在這個終端系統(tǒng)上不能接聽這個電話，那么應答應當回給呼叫方一個更合適的時間在Retry-After頭域 重試。這個用戶也許在其他地方有效，比如電話郵箱系統(tǒng)等等。如果我們知道沒有其他終端系統(tǒng)能夠接聽這個呼叫，那么應當返回一個狀態(tài)碼600（Busy Everywhere）。 

4.25 487 Request Terminated 

請求被BYE或者CANCEL所終止。這個應答永遠不會給CANCEL請求本身回復。 

4.26 488 Not Acceptable Here 

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

包含了媒體兼容性描述的消息體可以出現(xiàn)在應答中，并且根據(jù)INVITE請求中的Accept頭域進行規(guī)格化（如果沒有Accept頭域，那么就是application/sdp）。這個應答就像給OPTIONS請求的200(OK)應答的消息體一樣。 

4.27 491 Request Pending 

在同一個對話中，UAS接收到的請求有一個依賴的請求正在處理。14.2描述了這種情況應當怎樣解決。 

4.28 493 Undecipherable 

UAS接收到了一個請求，包含了一個加密的MIME,并且不知道或者沒有提供合適的解密密鑰。這個應答可以包含單個包體，這個包體包含了合適的公鑰，這個公鑰用于給這個UAS通訊中加密包體使用的。

5 Server Failure 5xx 

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

5.1 500 Server Internal Error 

服務器遇到了未知的情況，并且不能繼續(xù)處理請求�？蛻舳丝梢燥@示特定的錯誤情況，并且可以在幾秒種以后重新嘗試這個請求。 

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

5.2 501 Not Implemented 

服務器沒有實現(xiàn)相關的請求功能。當UAS不認識請求的方法的時候，并且對每一個用戶都無法支持這個方法的時候，應當返回這個應答。（proxy不考慮請求的方法而轉(zhuǎn)發(fā)請求）。 

注意405（Method Not Allowed）是因為服務器實現(xiàn)了這個請求方法，但是這個請求方法在特定請求中不被支持。 

5.3 502 Bad Gateway 

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

5.4 503 Service Unavailable 

由于臨時的過載或者服務器管理導致的服務器暫時不可用。這個服務器可以在應答中增加一個Retry-After來讓客戶端重試這個請求。如果沒有Retry-After指出，客戶端必須就像收到了一個500（Server Internal Error）應答一樣處理。 

客戶端（proxy或者UAC）收到503（Service Unavailable）應當嘗試轉(zhuǎn)發(fā)這個請求到另外一個服務器處理。并且在Retry-After頭域中指定的時間內(nèi)，不應當轉(zhuǎn)發(fā)其他請求到這個服務器。 

作為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 

成功聯(lián)系到被叫方的終端系統(tǒng)，但是被叫方處于忙的狀態(tài)，并不打算接聽電話。這個應答可以通過增加一個Retry-After頭域更明確的告訴呼叫方多久以 后可以繼續(xù)呼叫。如果被叫方不希望提示拒絕的原因，被叫方應當使用603（Decline）。只有當終端系統(tǒng)知道沒有其他終端節(jié)點（比如語音郵箱系統(tǒng)）能 夠訪問到這個用戶的時候才能使用這個應答。否則應當返回一個486（Busy Here）的應答。

6.2 603 Decline 

當成功訪問到被叫方的設備，但是用戶明確的不想應答。這個應答可以通過增加一個Retry-After頭域更明確的告訴呼叫方多久以后可以繼續(xù)呼叫。只有當終端知道沒有其他任何終端設備能夠響應這個呼叫的勢能才能給出這個應答。

6.3 604 Does Not Exists Anywhere 

服務器驗證了在請求中Request-URI的用戶信息，哪里都不存在 

6.4 606 Not Acceptable 

當成功聯(lián)系到一個UA,但是會話描述的一些部分比如請求的媒體，帶寬，或者地址類型不被接收。 

606（NotAcceptable）應答意味著用戶希望通訊，但是不能充分支持會話描述。606（Not Acceptable）應答可以在Warning頭域中包含一個原因列表，用于解釋為何會話描述不能被支持。警告原因代碼在20.43節(jié)中列出。 

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

我們希望這些媒體協(xié)商不要經(jīng)常需要，并且當一個新用戶被邀請加入已經(jīng)存在的會話的時候，這個媒體協(xié)商可能不需要。這取決于邀請的初始化者是否需要對606（Not Acceptable）進行處理。 

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

二 VoLTE-SIP完整信令解析

1. 主叫與被叫之間的 SIP 呼叫業(yè)務流程如下:

2. SIP 信令完整解析:

(1). 用戶 A ,摘機對用戶 B 發(fā)起呼叫,用戶 A 首先向 AS 服務器發(fā)起 INVITE 請求。

 (2). AS 服務器回復 100 Trying 給用戶 A 說明收到 INVITE 請求。

(3). AS 服務器通過認證確認用戶認證已通過后,向被叫終端 B 轉(zhuǎn)送 INVITE 請求。 (4). 用戶 B 向 AS 服務器送呼叫處理中的應答消息, 100 Trying 。

(5). 用戶 B 向 AS 服務器送 183 Session Progress 消息, 提示建立對話的進度信息 。 (此時被 叫 QCI1 專用承載建立)

(6). AS 服務器向主叫終端 A 轉(zhuǎn)送 183 Session Progress 消息,終端 A 了解到整個 Session 的建 立進度消息。

(7). 終端 A 向 AS 服務器回復臨時應答消息 PRACK ,表示收到 183 Session Progress 消息。 (此時主叫 QCI1 專用承載建立)

(8). AS 服務器向被叫終端 B 轉(zhuǎn)送臨時應答消息 PRACK ,終端 B 了解到終端 A 收到 183 Session Progress 消息。

(9). 被叫終端 B 向 AS 服務器發(fā)送 200OK 消息,表示 183SessionProgress 請求已經(jīng)處理成功。 

(10). AS 服務器向主叫終端 A 轉(zhuǎn)送 200 OK 消息。

(11). 主叫終端 A 向 AS 服務器發(fā)送 UPDATE 消息,意在與被叫終端 B 協(xié)商相關 SDP 信息。 

(12). AS 服務器向被叫終端 B 轉(zhuǎn)送 UPDATE 消息。

(13). 被叫終端 B 向 AS 服務器發(fā)送 200 OK 消息,表示 UPDATE 請求已經(jīng)處理成功。

(14).AS 服務器向主叫用戶 A 轉(zhuǎn)送 200 OK 消息,通知用戶 A UPDATE 請求已經(jīng)處理成功。 

(15).被叫用戶 B 振鈴,用戶振鈴后,向 AS 服務器發(fā)送 180 Ringing 振鈴信息。

(16).AS 服務器向主叫終端 A 轉(zhuǎn)送 180 Ringing 振鈴信息。

(17).被叫終端 B 向 AS 服務器發(fā)送 200 OK 消息,表明主叫最初的 INVITE 請求已經(jīng)處理成功。

(18). AS 服務器向主叫終端 A 轉(zhuǎn)送 200OK 消息,通知主叫終端 A ,被叫終端 B 已經(jīng)對 INVITE 請求處理成功。

(19). 主叫終端 A 向 AS 服務器發(fā)送 ACK 消息,意在通知被叫終端 B ,主叫側(cè)已經(jīng)了解被叫側(cè)處 理 INVITE 請求成功。

(20). AS 服務器向被叫終端 B 轉(zhuǎn)送 ACK 信息。

(21). 用戶 A 主動掛機, A 向 AS 服務器發(fā)起通話結(jié)束 BYTE 信息。

(22). AS 服務器向被叫終端 B 轉(zhuǎn)送 BYTE 信息。

(23). 被叫終端 B 向 AS 服務器發(fā)送 200 OK 消息,表示對 BYTE 信息處理成功。

(24). AS 服務器向用戶 A 轉(zhuǎn)送 200 OK 信息。整個通話結(jié)束。

(25). 被叫用戶 B 主動掛機流程同步驟 21—24 。

三 SIP呼叫流程典型流程圖解及其詳細解釋

1 注冊流程

2 注銷流程

3 基本呼叫建立過程

4 會話更改流程

5 正常呼叫釋放過程

6 被叫忙呼叫釋放

7 被叫無應答流程一

8 被叫無應答流程二

9 遇忙呼叫前轉(zhuǎn)

10 無應答呼叫前轉(zhuǎn)流程

11 呼叫保持

12 呼叫等等精選留言

SIP響應是由一個用戶代理服務器(UAS)或SIP服務器生成回復由客戶端生成的請求的消息。它可能是一個正式的確認，以防止請求由UAC重發(fā)。

響應可能包含需要一個UAC信息一些額外的頭字段

SIP有六個響應

1xx - 5xx已經(jīng)借由HTTP，而6xx系列在SIP介紹。

1XX被認為是一個臨時響應，其余的最終響應。

類別描述動作

1xx 信息 這表明調(diào)用之前完成也被稱為臨時響應的狀態(tài)。

2xx 成功 請求已成功。如果這是一個邀請，確認應發(fā)送;否則，停止請求的重發(fā)。

3xx 重定向 服務器返回的可能位置�？蛻舳藨�該重試另一個服務器的請求。

4xx 客戶端錯誤 請求已經(jīng)由客戶端失敗，原因是一個錯誤�？蛻舳丝梢灾卦囌埱�，如果它是根據(jù)響應擬訂。

5xx 服務器故障 請求已經(jīng)由該服務器失敗，原因是一個錯誤。請求可以在另一臺服務器退出。

6xx 全局失敗 請求已失敗。該請求不應該在這個或其他服務器再次嘗試。

信息(1xx)

信息響應用于指示呼叫進程。通常情況下，響應是端對端（除100嘗試）。信息的響應的主要目的是阻止INVITE請求的重發(fā)。

信息響應包括以下對策：

100 嘗試

這種特殊的情況下的響應僅僅是一個逐跳請求。

它永遠不會轉(zhuǎn)發(fā)，不得包含郵件正文。

它被用于避免INVITE請求的重傳。

180 響鈴

此響應被用來指示一個INVITE已經(jīng)接收由用戶代理和警報正在發(fā)生。

181 呼叫被轉(zhuǎn)發(fā)

此響應用于指示該呼叫已被轉(zhuǎn)發(fā)到另一端點。

它發(fā)送的信息有可能會使用到呼叫者。

它給該呼叫者的狀態(tài)，作為一個轉(zhuǎn)發(fā)操作可以導致在呼叫同時較長時間來回答。

182 呼叫隊列

此響應被用來指示該INVITE已經(jīng)接收并且將在一個隊列進行處理。

183 會話進度

它表明，有關會話的進度的信息可以存在于消息主體或媒體流。

不像100嘗試響應，183端到端的響應，并建立一個對話。

一個典型的使用這種反應是為了讓UAC通過網(wǎng)關進入PSTN聽到手機鈴聲，忙音，或在通話錄音通知。

成功(2xx)

此類反應是指用于指示一個請求已被接受。它包括以下對策：

200 OK

200OK用于接受會話邀請。

它表示成功完成的請求或接受。

202 接受

202接受表示該UAS已經(jīng)接收并理解的請求，但該請求可能沒有被授權(quán)或由服務器處理。

它是常用響應訂閱，請參閱方法。

重定向(3xx)

通常，這些類響應由重定向服務器響應INVITE發(fā)送。它們也被稱為類重定向響應。它包括以下對策：

300 多重選擇

它包含多個聯(lián)系人報頭字段以指示該位置的服務已經(jīng)在Request-URI返回SIP URI多個可能的位置。

301 永久移動

這種重定向響應包含與被叫方的新的永久URI一個Contact頭字段。

地址可以保存并在今后的INVITE請求中使用。

302 臨時移動

這個重定向響應包含一URI，它是當前有效的，但不是永久的。

即，位置是有效的指定的時間的持續(xù)時間。

305 使用代理

這個響應包含指向具有關于呼叫方的權(quán)威信息代理服務器的URI。

這種反應可以由UAS發(fā)出的來電篩選代理發(fā)送。

380 可替代服務

這個響應返回的URI，指示服務的被叫方希望的類型。

例如，一個通話可以被重新定向到一個語音信箱服務器。

客戶端錯誤(4xx)

客戶端錯誤的回應表明，由于一些錯誤是從側(cè)面UAC確認的要求不能得到滿足。響應代碼由UAS通常發(fā)送。在接收到出錯消息時，客戶端應該通過修改其基于所述響應重新發(fā)送請求。下面討論的是一些重要的客戶端錯誤響應。

400 錯誤的請求

這表明該請求不被服務器理解。

請求可能是缺少必要的頭字段，例如收件人，發(fā)件人，呼叫ID，或Cseq。

401 未經(jīng)授權(quán)它表明該請求要求用戶進行認證。

401未授權(quán)通常由一個注冊服務器的注冊請求發(fā)送。

響應包含從主叫用戶代理正確的憑據(jù)請求WWW身份驗證頭字段。

隨后REGISTER將觸發(fā)從用戶代理與正確的憑據(jù)。

403 禁止

403禁止當服務器已經(jīng)理解請求，發(fā)現(xiàn)是正確配制的要求，但將不提供服務的請求被發(fā)送。

這種反應，不使用時需要授權(quán)。

404 未找到

404未找到表明在請求URI標識的SIP URI用戶不能位于由服務器或用戶當前未簽署的用戶代理。

405 不允許的方法

這表明服務器或用戶代理已收到并理解的請求，但就是不愿意履行請求。

例如：注冊請求可能會被發(fā)送到用戶代理。

一個允許域是必需通知UAC什么方法是可以接受的。

406 不接受

該響應指示該請求不能由于在請求消息中的規(guī)定處理。

在請求中的Accept頭域沒有包含在UAS支持的任何選項。

407 需要代理身份驗證

由代理發(fā)送該請求表明了UAC必須首先與代理驗證自身的請求可以被處理之前。

響應應包含有關在代理進行身份驗證頭字段的代理所需憑據(jù)類型的信息。

該請求可以被重新提交與代理-Authorization頭域正確的憑據(jù)。

SIP響應是由一個用戶代理服務器(UAS)或SIP服務器生成回復由客戶端生成的請求的消息。它可能是一個正式的確認，以防止請求由UAC重發(fā)。

響應可能包含需要一個UAC信息一些額外的頭字段

SIP有六個響應

1xx - 5xx已經(jīng)借由HTTP，而6xx系列在SIP介紹。

1XX被認為是一個臨時響應，其余的最終響應。

類別描述動作

1xx 信息 這表明調(diào)用之前完成也被稱為臨時響應的狀態(tài)。

2xx 成功 請求已成功。如果這是一個邀請，確認應發(fā)送;否則，停止請求的重發(fā)。

3xx 重定向 服務器返回的可能位置。客戶端應該重試另一個服務器的請求。

4xx 客戶端錯誤 請求已經(jīng)由客戶端失敗，原因是一個錯誤�？蛻舳丝梢灾卦囌埱�，如果它是根據(jù)響應擬訂。

5xx 服務器故障 請求已經(jīng)由該服務器失敗，原因是一個錯誤。請求可以在另一臺服務器退出。

6xx 全局失敗 請求已失敗。該請求不應該在這個或其他服務器再次嘗試。

信息(1xx)

信息響應用于指示呼叫進程。通常情況下，響應是端對端（除100嘗試）。信息的響應的主要目的是阻止INVITE請求的重發(fā)。

信息響應包括以下對策：

100 嘗試

這種特殊的情況下的響應僅僅是一個逐跳請求。

它永遠不會轉(zhuǎn)發(fā)，不得包含郵件正文。

它被用于避免INVITE請求的重傳。

180 響鈴

此響應被用來指示一個INVITE已經(jīng)接收由用戶代理和警報正在發(fā)生。

181 呼叫被轉(zhuǎn)發(fā)

此響應用于指示該呼叫已被轉(zhuǎn)發(fā)到另一端點。

它發(fā)送的信息有可能會使用到呼叫者。

它給該呼叫者的狀態(tài)，作為一個轉(zhuǎn)發(fā)操作可以導致在呼叫同時較長時間來回答。

182 呼叫隊列

此響應被用來指示該INVITE已經(jīng)接收并且將在一個隊列進行處理。

183 會話進度

它表明，有關會話的進度的信息可以存在于消息主體或媒體流。

不像100嘗試響應，183端到端的響應，并建立一個對話。

一個典型的使用這種反應是為了讓UAC通過網(wǎng)關進入PSTN聽到手機鈴聲，忙音，或在通話錄音通知。

成功(2xx)

此類反應是指用于指示一個請求已被接受。它包括以下對策：

200 OK

200OK用于接受會話邀請。

它表示成功完成的請求或接受。

202 接受

202接受表示該UAS已經(jīng)接收并理解的請求，但該請求可能沒有被授權(quán)或由服務器處理。

它是常用響應訂閱，請參閱方法。

重定向(3xx)

通常，這些類響應由重定向服務器響應INVITE發(fā)送。它們也被稱為類重定向響應。它包括以下對策：

300 多重選擇

它包含多個聯(lián)系人報頭字段以指示該位置的服務已經(jīng)在Request-URI返回SIP URI多個可能的位置。

301 永久移動

這種重定向響應包含與被叫方的新的永久URI一個Contact頭字段。

地址可以保存并在今后的INVITE請求中使用。

302 臨時移動

這個重定向響應包含一URI，它是當前有效的，但不是永久的。

即，位置是有效的指定的時間的持續(xù)時間。

305 使用代理

這個響應包含指向具有關于呼叫方的權(quán)威信息代理服務器的URI。

這種反應可以由UAS發(fā)出的來電篩選代理發(fā)送。

380 可替代服務

這個響應返回的URI，指示服務的被叫方希望的類型。

例如，一個通話可以被重新定向到一個語音信箱服務器。

客戶端錯誤(4xx)

客戶端錯誤的回應表明，由于一些錯誤是從側(cè)面UAC確認的要求不能得到滿足。響應代碼由UAS通常發(fā)送。在接收到出錯消息時，客戶端應該通過修改其基于所述響應重新發(fā)送請求。下面討論的是一些重要的客戶端錯誤響應。

400 錯誤的請求

這表明該請求不被服務器理解。

請求可能是缺少必要的頭字段，例如收件人，發(fā)件人，呼叫ID，或Cseq。

401 未經(jīng)授權(quán)它表明該請求要求用戶進行認證。

401未授權(quán)通常由一個注冊服務器的注冊請求發(fā)送。

響應包含從主叫用戶代理正確的憑據(jù)請求WWW身份驗證頭字段。

隨后REGISTER將觸發(fā)從用戶代理與正確的憑據(jù)。

403 禁止

403禁止當服務器已經(jīng)理解請求，發(fā)現(xiàn)是正確配制的要求，但將不提供服務的請求被發(fā)送。

這種反應，不使用時需要授權(quán)。

404 未找到

404未找到表明在請求URI標識的SIP URI用戶不能位于由服務器或用戶當前未簽署的用戶代理。

405 不允許的方法

這表明服務器或用戶代理已收到并理解的請求，但就是不愿意履行請求。

例如：注冊請求可能會被發(fā)送到用戶代理。

一個允許域是必需通知UAC什么方法是可以接受的。

406 不接受

該響應指示該請求不能由于在請求消息中的規(guī)定處理。

在請求中的Accept頭域沒有包含在UAS支持的任何選項。

407 需要代理身份驗證

由代理發(fā)送該請求表明了UAC必須首先與代理驗證自身的請求可以被處理之前。

響應應包含有關在代理進行身份驗證頭字段的代理所需憑據(jù)類型的信息。

該請求可以被重新提交與代理-Authorization頭域

VoLTE-SIP代碼意義及流程圖解.pdf