添加音视频聊天的错误处理逻辑

-##错误处理机制
---------------
+错误处理机制
+----------
 
 
 ###//一般错误都是在教师版处理
 ###//一般错误都是在教师版处理
 只针对教师在线授课发消息失败的情况
 只针对教师在线授课发消息失败的情况
@@ -24,8 +24,10 @@
 学生端基本都是负责收消息,不会有老师版那么多error code.如果学生端有发消息的时候错误处理类比教师端
 学生端基本都是负责收消息,不会有老师版那么多error code.如果学生端有发消息的时候错误处理类比教师端
 #####1.网络问题
 #####1.网络问题
        (1)弱网,无网(给提示,检查网络连接)
        (1)弱网,无网(给提示,检查网络连接)
-#####2.长时间出现和同一条预期顺序不一致的消息
-       (1)将期望顺序的消息发送给教师版，教师版收到消息后可根据顺序index到最近发送的消息里面去找期望重发的消息(TIM会对本地已发送的消息进行缓存)//有待商榷
+#####2.长时间出现和同一条预期顺序不一致的消息 ` deprecated `
+       (1)将期望顺序的消息发送给教师版，教师版收到消息后可根据顺序index到最近发送的消息里面去找期望重发的消息(TIM会对本地已发送的消息进行缓存)//如果把重发消息发给教师端，教师端发现这条消息一经发成功了，并不会再重发一次，如果是发送失败的消息，教师端会有重发机制，so这条并没有太大意义了
      
      
-    
-    
+###//音视频聊天过程中掉线,重新上线打开摄像头等操作`uncertain`
+       如果监测是否掉线上线，自动关闭打开摄像头的话，比如老师监测到学生端掉线后，学生端的视频画面就不在了，这时候把老师的自己的视频画面关掉，学生端重新上线后就不能打开教师的视频画面了，牵涉到了先后顺序。
+       应该是教师端监测到学生重新上线后，打开自己的摄像头，学生又监测到了老师打开了摄像头，这时候去打开自己的摄像头，这时候可以互相请求对方视频画面。或者学生重新上线后打开自己的视频画面，教师监测到学生后打开自己的画面。 
+       造成上面的原因就是对方掉线了就关闭自己的视频画面（摄像头）。建议这些操作都交给用户做。后面是否会有这块的UI设计？