2019獨角獸企業(yè)重金招聘Python工程師標(biāo)準(zhǔn)>>>

對基于VOIP業(yè)務(wù)的對講有一點了解之后，那我們再來看看要完成一次對講需要多少狀態(tài)來表示。大概有下面幾種狀態(tài)：

1.granted：當(dāng)你向服務(wù)器申請講話的時候，并不是你申請了就一定會成功，因為在一個群組里面能講話的只能是一個人，如果當(dāng)前有人在講話那么你肯定就不能講了，所以當(dāng)你申請之后服務(wù)器會給一個返回表示是否可以講話，那么如果服務(wù)器返回了granted那么說明你當(dāng)前可以講話了。但是如果你收到了grant但是你沒有發(fā)送語音，那么在幾秒之后服務(wù)器可能會把你斷掉。

2.idle：顧名思義就是空閑的意思，空閑就說明當(dāng)前沒有人在說話。

3.revoke：對于revoke消息有很多種情況，例如你講話超時服務(wù)器會給你返回一個revoke表示你的話語權(quán)被剝奪，還有可能是因為別人的優(yōu)先級比你高所以你也被剝奪了。一般被剝奪之后會有一個被剝奪的原因。

4.deny：deny拒絕，當(dāng)服務(wù)器返回granted的時候表示你可以講話了，那如果不能講話的時候返回什么呢，那就是deny了。還有一些其他的情況也會出現(xiàn)deny了，比如服務(wù)器設(shè)置了你當(dāng)前是僅聽的狀態(tài)，也就是你的發(fā)言被禁了。

5.taken：taken消息表示當(dāng)前有人要發(fā)言了，在收到這個消息之后就可能收到語音了。

這些狀態(tài)看起來比較簡單，但是對于多會話以及網(wǎng)絡(luò)的影響，就顯得不那么簡單了。

首先是消息丟失的問題：大家都知道，基于數(shù)據(jù)業(yè)務(wù)的對講使用UDP的居多，因為UDP比較及時。那么相信大家也知道UDP有一個致命的缺點那就是丟包的問題。那大家就會想了如果在傳輸過程中把消息丟了那該怎么辦呢？為此客戶端和服務(wù)端都做了相應(yīng)的改進。在服務(wù)端那就是連續(xù)發(fā)同一個消息，例如將granted連續(xù)發(fā)送5次，如果5次都丟了那說明網(wǎng)絡(luò)環(huán)境真的很不好。服務(wù)端的改進可以解決一大部分丟包的問題，但是并不能完全解決，對于接收方如果恰巧就發(fā)送消息的時間短網(wǎng)絡(luò)不好把消息全丟了。但是服務(wù)器并不知道你沒有收到taken的消息，還是繼續(xù)給你發(fā)語音，那就會出現(xiàn)一長串的語音發(fā)送到你。所以這個時候客戶端如果只是根據(jù)有沒有收到taken消息來判斷是否要收聽是不是有點武斷呢，可能真的會丟失信息。可是如果我們用是否收到語音為判斷的標(biāo)準(zhǔn)，那么是否會更合理呢，盡管在有的時候可能看不到講話人的信息，但是總比把語音丟掉比較好吧。所以這個時候可能不僅僅要判斷消息還要檢測語音的情況來判斷是否要播放。

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

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

?

轉(zhuǎn)載于:https://my.oschina.net/u/1013544/blog/2992244

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。