对讲业务对讲过程当中的几个状态

对基于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消息来判断是否要收听是否是有点武断呢，可能真的会丢失信息。但是若是咱们用是否收到语音为判断的标准，那么是否会更合理呢，尽管在有的时候可能看不到讲话人的信息，可是总比把语音丢掉比较好吧。因此这个时候可能不单单要判断消息还要检测语音的状况来判断是否要播放。

实际上是网络乱序：最主要的就是语音消息和控制消息的混乱，例如语音先来控制消息后来，那就会致使客户端的判断错误。

再次对于多会话：对于同一终端，在同一时间只能有一我的说或者一我的听，若是听多我的的讲话，那么就会比较混乱，这个时候就必需要有一个控制的策略。