DOCS FOLDER

wrcp 主要负责和MCU服务端通讯部分的

1.协议上 senddata是顶层协议壳。所有消息包都嵌套打在 这个 pdu中

2. 从会议流程上看，分以下几类： 1、connectprovider(内部嵌套joinconference包）：加入会议协议，分为request和response两组。 2、joinsession（内部嵌套注册表的操作包）：加入应用，分为request和response 3、joinchannel：加入channel 4、adapterpdu 中嵌套注册表操作pdu mcu中的注册表是有客户端通过adapterpdu来维护的，mcu本身不维护这个数据 我特别强调这个，就是想说明，会议的所有控制逻辑不是mcu完成的，而是客户端完成的

3.每个应用就是一个session，（joinsession就是加入这个应用），客户端加入这个应用后，就能从mcu的注册标中活的这个应用的所有信息。 conference这个应用会保留会议的主要信息如用户列表等，而且很多会议控制我觉得也会在这个应用中。

然后特定应用如聊天就是负责聊天的数据转发，需要先joinsession然后在joinchannel（相当于聊天的数据通道），这样客户端会通过senddatapdu嵌套chatsenddatapdu来发送聊天channel的消息，其他客户端只要加入了聊天应用的聊天channel，就会收到聊天消息。

每个应用在joinsession时会嵌套adapterpdu，其中带上了需要维护的注册表信息（定义 registrykey和object） 注册表常用的就是 table，几乎所有app都维护了一个table

比如一个会议中会维护三个视频通道，这样在table中就会有三条记录（以视频channel id作为索引

所有用户加入视频应用后都会获得这个信息，且记录发生改变时会广播给全网用户。

具体到这个表格的存储呢，mcu仅仅知道 id 和 一个 pdu生成的字符串还有owner信息。具体这个记录的内容，mcu没有关心。

比如想定义一个会议的控制行为，很可能的操作就是：在conference这个应用的某个表格下插入一个特定id的string值。然后通过修改这个值，然后与会的人知道当前是什么行为

再比如，tabbar中的多个tab选项，每个选项对应一个id，其属性可以保存在conference中一个表中，这样属性值中可以有visble选项，老师切换时，将相关id属性同步成true，mcu会广播给所有客户端，这样所有的与会人员就知道切换tab了。