2019獨角獸企業重金招聘Python工程師標準>>>

對基于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消息來判斷是否要收聽是不是有點武斷呢，可能真的會丟失信息。可是如果我們用是否收到語音為判斷的標準，那么是否會更合理呢，盡管在有的時候可能看不到講話人的信息，但是總比把語音丟掉比較好吧。所以這個時候可能不僅僅要判斷消息還要檢測語音的情況來判斷是否要播放。

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

再次對于多會話：對于同一終端，在同一時間只能有一個人說或者一個人聽，如果聽多個人的講話，那么就會比較混亂，這個時候就必須要有一個控制的策略。

?

轉載于:https://my.oschina.net/u/1013544/blog/2992244

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的对讲业务对讲过程中的几个状态的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。