對講業務對講過程當中的幾個狀態

對基於VOIP業務的對講有一點了解以後，那咱們再來看看要完成一次對講須要多少狀態來表示。大概有下面幾種狀態：

1.granted：當你向服務器申請講話的時候，並非你申請了就必定會成功，由於在一個羣組裏面能講話的只能是一我的，若是當前有人在講話那麼你確定就不能講了，因此當你申請以後服務器會給一個返回表示是否能夠講話，那麼若是服務器返回了granted那麼說明你當前能夠講話了。可是若是你收到了grant可是你沒有發送語音，那麼在幾秒以後服務器可能會把你斷掉。

2.idle：顧名思義就是空閒的意思，空閒就說明當前沒有人在說話。

3.revoke：對於revoke消息有不少種狀況，例如你講話超時服務器會給你返回一個revoke表示你的話語權被剝奪，還有多是由於別人的優先級比你高因此你也被剝奪了。通常被剝奪以後會有一個被剝奪的緣由。

4.deny：deny拒絕，當服務器返回granted的時候表示你能夠講話了，那若是不能講話的時候返回什麼呢，那就是deny了。還有一些其餘的狀況也會出現deny了，好比服務器設置了你當前是僅聽的狀態，也就是你的發言被禁了。

5.taken：taken消息表示當前有人要發言了，在收到這個消息以後就可能收到語音了。

這些狀態看起來比較簡單，可是對於多會話以及網絡的影響，就顯得不那麼簡單了。

首先是消息丟失的問題：你們都知道，基於數據業務的對講使用UDP的居多，由於UDP比較及時。那麼相信你們也知道UDP有一個致命的缺點那就是丟包的問題。那你們就會想了若是在傳輸過程當中把消息丟了那該怎麼辦呢？爲此客戶端和服務端都作了相應的改進。在服務端那就是連續發同一個消息，例如將granted連續發送5次，若是5次都丟了那說明網絡環境真的很很差。服務端的改進能夠解決一大部分丟包的問題，可是並不能徹底解決，對於接收方若是恰巧就發送消息的時間短網絡很差把消息全丟了。可是服務器並不知道你沒有收到taken的消息，仍是繼續給你發語音，那就會出現一長串的語音發送到你。因此這個時候客戶端若是隻是根據有沒有收到taken消息來判斷是否要收聽是否是有點武斷呢，可能真的會丟失信息。但是若是咱們用是否收到語音爲判斷的標準，那麼是否會更合理呢，儘管在有的時候可能看不到講話人的信息，可是總比把語音丟掉比較好吧。因此這個時候可能不單單要判斷消息還要檢測語音的狀況來判斷是否要播放。

實際上是網絡亂序：最主要的就是語音消息和控制消息的混亂，例如語音先來控制消息後來，那就會致使客戶端的判斷錯誤。

再次對於多會話：對於同一終端，在同一時間只能有一我的說或者一我的聽，若是聽多我的的講話，那麼就會比較混亂，這個時候就必需要有一個控制的策略。