用户上麦流程-cp

7.1返回上麦API响应

10.3.混流失败，踢出用户

8.3即构上麦

9.1.同步结果API响应

5.麦位信息API响应

一:主播上麦流程图

12.提示主播开播结果

5.1.更新麦位UI

1.进房

7.主播身份请求上麦API

3.第10 如果服务器收到请求参数是：SDK操作失败，服务端重置麦位状态，立即响应（10.5）给用户上麦失败。10.5 中用户只处理上麦失败的响应。

APP

10.2.混流api响应结果

2.请求进房API

用户

10.1 - 11注意：1.测试zego响应耗时。2.可以考虑搞异步队列服务处理zego请求，客户端通过长连接接受处理结果3.如果http请求耗时严重，统一走长连接全局通知。10.3：只有混流失败的时候才走。10.4：zego踢人API请求失败，需要有报警机制，特别是踢房间主播的时候。这个出问题需要开发及时响应。（如果能做到根据请求结果，视情况，给被踢的人下发长链接踢用户离房，90s内不能进房这样最好。）10.5：如果即构服务器响应速度很快，直接通过10.5响应结果。如果响应速度过慢，10.5只返回API请求成功失败即可，客户端不做处理。10.6：同上如果zego服务器响应过长考虑使用异步队列处理请求，结果返回后统一走10.6更新结果。

4.1建立长连接

3.进房API响应

8.2.2创建房间成功

2.10.2如果是混流成功，更新麦位状态为以上麦，直接执行10.5/10.6

10.API同步SDK结果(成功/失败)到服务器

6.1非房间主持直接提示

8.2.1SDK请求zego

8.API响应成功

11.上麦成功更新UI

7.2，AP返回失败直提示用户

服务器麦位状态1.第7的请求到达服务器后，标记变更主持位状态，上麦中，收不到后续的结果请求，需要在麦位监控服务中变更房间麦位的状态。

10.5.API响应上麦结果

6.主持点击上麦

8.2.1创建失败

10.4踢人API响应

8.2创建/加入房间

8.3.1同步麦位状态给zego

9.API同步SDK结果

4.2请求麦位信息API

10.5 及10.6两步待响应测试后再详细定

10.6socket全员通知结果给房内用户

8.1初始化SDK

8.4.上麦结果

zego_server

10.1.SDK上麦成功，api请求混流转推

Server