SDK version - housekeeper-software/soft GitHub Wiki

1. 重写了android SDK 接口，修改了JNI 对象引用的问题与内存使用的问题，可以持续通话数十个小时。  
2. 将HttpRequest调整为异步，不影响SDK正常退出，否则在网络不通的情况下，会等待数秒，可能导致ANR
3. 可以持续通话数十个小时。  
4. 增加了底座和平板的串口支持。

1. 从Chromium仓库引入 75.0.3770.80 版本的Capture代码，使用新的摄像头实现
2. 增加了摄像头错误的上层通知：onCameraError， onCameraStateChanged
3. 修改了摄像头编码参数，提高编码质量：
   抛弃固定码率编码模式，采用固定质量编码，将CRF默认设置为23
   将gotsize设置为30，每30帧编码一个关键帧，减少带宽使用率。gotsize还可以继续增大到300，对网络
资源占用将继续减少，但花屏恢复较慢  
4. 摄像头的输出格式不需要预先设定，由系统来决定。Camera 1支持YV12/NV21，Camera 2支持I420输出 
5. 优化了OpenGL渲染的一个缓冲区的实现机制，渲染效率提高，更少的内存消耗
6. 摄像头输出格式不需要预先指定，由IOS底层实现自行选择 
7.支持Linux V4L2 摄像头接口，对于OpenWRT，可以集成H264摄像头，直接输出H264视频流  
8.支持Linux下的视频编解码

> 1.优化日志输出

1. 修改了一体机不能正常控制灯光的bug  
2. 修改了IOS不能切换前后摄像头的bug  
3. 增加了视频丢包策略，通过设置video_qos_discard_level可以控制丢包的程度  
4. 增加了VFU策略，但是因为我们目前设置的gotsize较小，
所以没有必要开启这个功能，请设置为false  
5. 增加云端对讲（只在平板和平板，平板和手机端基于云端呼叫的时候生效）的视频冗余
编码传输机制，与旧版本通讯时，会自动禁止此功能。 video_qos_red_payload_type=116，video_qos_ulpfec_payload_type=117。  
6. 增加了根据丢包率和RTT时延参数动态调整冗余编码因子和视频压缩的帧率。
当丢包率很高时，冗余编码因子最大不超过50%，默认为20%。根据RTT大小，
逐步增大或者减少视频压缩的帧率，以缓解网络拥塞。最低帧率控制在5帧/秒。

1.优化平板的回音消除的各项参数，在RK3288平板上具体的参数如下：
 latency_delay: 80ms
 MIC输出功率调制 30%( tinymix 16 30)
 手机端继续使用 150ms（因为机型不同，只能使用Google推荐值）  
 IOS不用关心，IOS使用内置的回音消除  
2.对普通的室外机（比如全时通）呼叫，如果通过互联网接听的话，代理自动会为室外机视频增加冗余，在一般的丢包场景下
不会造成马赛克。此功能要求接听端使用新版本SDK，并且代理中关于此室外机的配置要强制使用RTP接收device.ini[base]force_video_use_rtp=1

1.与上个版本没有变化，只是版本号改变了
2.当两个平板靠的很近的时候，无法消除啸叫（专业说法叫 howling supression),试过均衡器，FFT滤波，
VAD检测然后使用静音数据替代等方法，均宣告失败，so，到此为止。

1.调整了android回音消除play buffer 和 rec buffer对齐方式，效果更好点

1.融合龙信修订版的功能，避免组播包泄漏到外网中
2.修改了底座和平板串口通讯的部署功能的bug
3.修改了deploy模块超时重连的功能
4.目前已知3.0版本的最终版

1.解决终端(Intercom)一体机中只连接eth1网口不能发现总机的问题。此问题由于我们后期版本屏蔽了eth1的组播和广播包，导致
  只有eth1网口工作时，无法识别到本机的总机。解决方法是增加通过127.0.0.1回环地址来发现本机安装的总机APP。
  此处修改影响到OpenWRT、Linux、android，其他平台不受影响
2.所有的移动设备终端master device = false。只有一体机、分体机button_key=01的才是主机。分体机通过load.ini中button_key判断
  android一体机必须通过 Intercom Java层传递master_device标识判断。
3.【主机上安装的分机模块原则上禁止使用组播和广播使用eth1(android),eth0.3(openwrt),使用此接口将导致发现包泄漏到社区网络中，并
   最终影响到核心交换机的工作】，室内其他的设备不受此规则影响。注意，室内如有多个设备，非直接接入社区网络的设备不需要屏蔽接口，
   容易导致室内通无法正常工作。
4.修改代码块位于: /housekeeper/proxy/client/client_proxy.cc(line 101~110)
  #if defined(OS_ANDROID) || defined(OS_OPENWRT) || defined(OS_LINUX)
  {
    net::IPAddressNumber address;
    net::ParseIPLiteralToNumber("127.0.0.1", &address);
    net::IPEndPoint endpoint(address, client_conf_.lan_udp_broadcast_port_);
    net::SockaddrStorage storage;
    endpoint.ToSockAddr(storage.addr, &storage.addr_len);
    udp_send_queue_->AddQueue(storage, udp_send_buffer_);
  }
  #endif
  因为总机侦听到任意接口，所以，总机可以在127.0.0.1地址上发现分机。此刻双方通讯都基于此ip。
  对于一体机，如果只接入eth1，其他网口均没有接入，此刻，是无法使用室内通。

此版本只针对OpenWRT
1.解决通话结束Mediaplay形成僵尸进程
2.新版本固件可以不适用mediaplay对讲，而是使用dooraccess内置声音录放模块。
  在conf/intercom_client.json去掉"audio_bus_path": "/tmp/audio_bus_server"，即使用内置声音模块
  否则仍然使用mediaplay
3 修改位置：/housekeeper/stream/remote_audio_device.cc, /housekeeper/stream/audio_manager.cc
  主要修改remote_audio_device.cc中 LetAudioServiceQuit
  

此版本只针对OpenWRT
1.别墅解决方案中，auto设备，因为没有开机DHCP没有及时拿到IP地址，导致组播侦听失败，从而无法收到室外机的自动发现包
  解决方法在server/src/intercom/device/auto/device_inventory.cc
  周期性检查eth0.2,eth0.3(openwrt)或 eth0,eth1(android)两个接口的ip地址变化情况，一旦发现有变化，则重启侦听  

1.android Intercom SDK工作目录未初始化，导致无法在conf目录下建立多个家庭的缓存目录
  解决方法在android../../main/android_intercom_manager.cc line(371) 
  work_dir_ = utils::GetAppConfPath(); 
  此处修改对系统工作没有影响
2.intercom每次启动时从服务器获取sip配置，由于缓存，第二次获取会使用缓存的用户名和密码去请求，导致服务器直接返回该账号，
  如果此刻移动端切换了账号，会导致服务器返回先前家庭的sip账号。
  解决方案在：housekeeper/client/intercom_client_main.cc,line(212),将从缓存读取sip账号和密码注释掉即可。
  具体注释214-222行。
  修改之后，终端每次登录都将从服务器获取完整的账号。此处修改影响所有平台。

1.增加MCU版本信息上报到管理平台，Android平台和底座之间GetInfo可以获得MCU版本信息，解决方法：
  （1）保存mcu的startup命令消息到conf/mcu.info文件，以备其他组件读取
  （2）housekeeper/src/utils/util.cc增加解析 mcu.info的接口，在与管理平台登录时，附带mcu版本和类型信息
2.解决IOS 13一个兼容性问题，此问题导致语音通话没有声音。解决方法如下：
  framework/src/media/audio/ios/audio_device_ios.mm，注释掉332,333行

1.智能家居云端协议将cmd="message"改成cmd=智能家居真实的消息名称。代码位于：
  /server/src/smarthome/smarthome_proxy.cc line(221)  
  proxy_message.cmd_ = "message" to proxy_message.cmd_=message->cmd_;  
  中转服务器和移动端不需要解析payload，即可知道消息的命令名称。
2.修改了android DNS获取的机制，SDK version >=MARSHMALLOW(6.0)即可通过android Framework获取本机active network的DNS，  
  其他版本依然使用__system_property_get获取。
  代码位于: /framework/net/base/dns_resoler.cc, 96-118行，同时新增AndroidNetworkLibrary.java, DnsStatus.java  
3.此版本同时修改了中转服务器的消息推送规则，改成根据预先配置的规则来推送  

1. 优化了OpenWRT 18声卡驱动，同时将上个版本dooraccess的松开按键播放声音改回原先的按下播放声音。
2. 龙信升级到此版本。

此版本只针对IOS
1.  if ([UIApplication sharedApplication].applicationState !=
      UIApplicationStateBackground) 如在子线程调用，在调试的时候触发警告。
    解决方案，可以关闭主线程检测，或者无视之。
2.在UI层创建 OpenGLSurface，见createSurfaceIfNeed
3.在销毁的时候采用异步方式进行

1.增加无室内机方案的支持，具体看对应的WIKI介绍
2.优化对天地伟业摄像机的非标准SDP的的支持
3.优化远程修改摄像机的配置信息

本地修改主要针对总机SDK，其他端不受影响
1.DeployServer增加开启和关闭升级部署功能的方法

本地修改主要针对IPC的处理
1.基础框架的改进，SIP模块在接收到ringing,accepet增加了对非标Header的处理，以便可以接收IPC的某些参数  
2.对IPC设备的管理结构进行了优化，增加了对NVR类型设备的支持。  
3.完善RTSP协议的实现，增加心跳机制，以及更细致的错误处理。  
4.集成lua脚本实现对设备的兼容性和扩展性，可以支持后期对设备类型的扩展。  

1.exosip2在android一体机上无法获取到eth1接口的IP地址，从而SDP中设置的地址
为127.0.0.1(c=IN IP4 127.0.0.1)，导致门铃的视频发送到错误的地址上。
现在改成使用门铃的地址来分析应该使用哪个接口  
2.修正一个Auto设备的自动发现的bug，之后热插拔网线切换网口，依然可以重新发现门铃。  
3.修正了RTP传输的关于telephone_event的一个bug，如果SDP中没有设置此项，导致telephone_event payloadtype和ULAW相同，从而忽略了音频接收。  
4.全时通双目门口机在查看监控的时候，SIP信令不完整，SDK提供了兼容性支持  
5.增加了exosip2 的TLS支持，目前尚未使用，也未经验证。  
6.修改media_helper.cc，在SDP中增加telephone_event payload，方便扩展支持DTMF  
7.Android中更新了TarUtil.java，解决从服务器下载错误的tar包解压时崩溃。未验证
8.客户端SDK增加语音留言功能，场景是室内机无人接听时，会自动接听，然后播放一段语音留言，只需要室内机实现即可

1.将针对auto设备的android一体机无法获得IP地址的修正推广到所有的SIP device

1.sip_request资源释放的一个修正
SipRequest::~SipRequest() {
  weak_factory_.InvalidateWeakPtrs();
  http_request_.reset();
}
2.修改了Intercom和outdoor中的视频编码和解码的架构，目的是方便扩展解码和编码引擎，并和Render模块深度整合，以便提高性能  
  新版本在Android上增加MediaCodec编解码，可以充分利用硬件加速性能。在低配平台上效果比较显著。  
  同时还集成了RK平台的MPP平台，但是在android上尚未达到商用的性能，因为MPP平台使用的是物理内存，目前是将编解码输出复制到虚拟内存  
  再通过EGL渲染。从物理内存复制大块数据到虚拟内存，中间的耗时非常长，据测，在PX30，复制一帧视频耗时100毫秒，在3288上最长需要20MS  
  因为，MPP引擎一般不需要启用，在RK平台，MediaCodec底层使用的也是MPP平台，所以，性能是足够的。  
  另外，需要注意是的，因为MediaCodec需要针对各个厂家进行适配和验证才能广泛使用，目前只在RK平台上测试过，所以移动端依然需要使用FFMPEG  
  作为编解码引擎。实际上，手机的性能一般比我们的平台要高，所以，使用FFMPEG不会有什么影响。

3.修改了Android上的渲染方式  
  以前使用Surface的NativeWindowBuffer，直接复制RGB数据进行渲染，效率也是一般般。新版本在android上使用EGL渲染，可以充分利用GPU的渲染  
  能力，性能进一步得到很大的提升。IOS平台一直都是使用OpenglES渲染，所以不存在效率问题。  
  唯一的问题，这个地方需要在很多Android移动端上测试，不知道是否存在平台差异化的问题。

4.因为上述修改从而导致上层一些调用方法的改变，这个在群里已经详细描述过了。

1.重新设计了媒体传输和媒体处理流程，以实现音频的低延迟  
2.部分接口做了修正，增删一些参数  
3.所有的平台都受到影响，需要重新集成，并注意接口的变化 

1.代理的变更  
  (1) device中的 [media]段落不再使用，但为了兼容以前的版本，还需要正确配置 
  (2) 代理支持G722音频编码，也兼容旧版本的G711，通过信令协商达成最终的编码格式  
  (3) 这次修改没有对device.ini做变更，照搬以前的即可  
  (4) 自由品牌室外机在代理中的设备名称为:jingxi, 在load.ini中可以这么配置  
      jingxi=icom,commonsip,genius  
      代理只有在p2p,ext,jingxi这些设备上才会启用G722音频编码，其他的如quanshitong,ipc,camera等都没有这个选项  
  (5) device_video_format中的early_media一般都需要配置成true  
2. 终端的变更  
  (1)openwrt的intercom_client.json中 sample_rate 由8000 变成 16000，其他就是新增
     max_audio_delay_us=4000， max_audio_playout_waiting_us=8000  
  (2)其他所有平台，但凡sample_rate都变成16000  
  (3) 移动端max_audio_delay_us=80000,因为大部分场景都是互联网传输，需要高缓冲以得到更好的语音品质  
  (4) 只有确定是局域网连接的时候才可以设置为40000.
3.室外机的变更  
  (1) 室外机的SIP信令处理的比较严格，包括SDP协商，既可以支持G711,也可以支持G722  
  (2) 如室内机需要早期媒体，请在Invite之后回复183，否则只有pickup之后才会视频  

1.代理的变更  
  同上个版本  
2. 终端的变更  
  (1) 上层配置音频采样频率所有平台一律为16000（包含outdoor)，其他不变。  
  (2)  访客日志保存的都是16000采样率。
  (3) 优化各个平台音频录制和播放，根据平台特点调整播放和录音采样率(二者可能不完全相同)  
~~~
android:由系统决定什么样的采样率，一般为44K，硬件架构不同有差别。
IOS: 48K
Win：44K
OpenWRT/linux: 48K
~~~
3.室外机的变更  
  (1) VOIP通话，可以在室外机端识别手机上按下的键盘，同时报告给UI层  
  (2) 支持手机接通之后，自动播放一段语音：比如：开门请按星号键  
4. 自动留言文件格式  
  不管是室内机还是室外机，语音留言的文件格式必须为 16K,mono，16bit，PCM格式(pcm格式就是裸数据，无头),  
  文件大小不超过1024KB。 
5. Intercom.addIntercom,支持type=2的模型，此种模式仅仅为了产品评测，可以不需要启动代理，直接对接室外机。 
   室外机的devicename必须是quanshitong ,或者 jingxi两种。可以获得音频的最低延迟。

1. Intercom & Outdoor的变更  
  (1) 上层配置音频采样频率所有平台一律为8000（包含outdoor)，其他不变。  
  (2) 增加音频低延迟配置，可以在评测版本中获得最低的延迟(intercomconfig.audio_low_latency=true)，项目上不适用, 
      其他平台没有这个设置

1. 所有平台  
  (1) 去掉了max_audio_playout_waiting_us 配置项,音频不再需要等待缓冲区充满。  
  (2) 一般情况下，所有平台 max_audio_delay_us配置不低于 80000(这个时间值依然用来控制音频的延迟最大范围)  
      ***正式版本：max_audio_delay_us=120000(120MS),可以保证云端呼叫丢弃的概率不超过5%，通话很连续 ****  
      ***评测版本：max_audio_delay_us=20000(20MS),可以保证直连室外机的情况下正常通话，丢弃概率低于5%，通话连续，用全时通双目通话延迟可以控制在300MS以内***  
      SDK底层有最长两个播放周期的动态缓冲区缩放，当出现播放欠载的时候会增加缓冲，以适应网络的抖动。 
      如果用Java音频架构，max_audio_delay_us=120000,延迟一般在400MS左右。 
  (3) unlock的变更，全时通和公司自有室外机都是采用原先的unlock方式，但是某些厂家的设备需要其他方式，比如DNAKE的室外机通过RFC2833协议开门，这个  
      开门动作需要在Intercom里完成，新版代理无法完成(新版代理完全是UDP透传)，具体方法如下：  
      首先在IntercomClientManager增加一个方法： public String findDeviceConfigure(String proxy_id, String device_name, String key)  
      通过proxy_id, device_name,key三个参数获取代理中配置的开锁指令，DNAKE室外机的指令是: dtmf=rfc2833:*,480  
      要想读出这个指令，需要 findDeviceConfigure("xxx","dnake","dtmf"),这里假设室外机的名字是 dnake.  这个方法返回 rfc2833:*,480  
      *：表示星号键开锁，如果是其他就换一下，480是标准配置，可以不用修改。  
      具体的开锁是： intercom.sessionManager.sendDTMF(session_id, "rfc2833:#,480");  
      如果上述方法没有读取到 dtmf的配置，则用intercom.sessionManager.unlock(session_id)即可。否则用新的方法  
2. android  
   android 室外机和室内机增加 audio_low_latency参数，只是在产品评测的时候设置为true，其他情况一律不要管(默认为false)，移动端不需要设置  
   android平板和室外机依然推荐使用 opensles音频架构，目前应该不会出现抖动现象。音频的品质和时延要好过AudioTrack/AudioRecord。   
   android移动端依然采用Java音频架构，确保兼容性。  
3. 这个版本增加了音频Packet loss concealment (PLC)算法，可以对audio传输过程中的丢包进行适当的补偿，从而增加音频的连续性。  
   通过静态测试，随机丢包在30%以内，依然可以恢复出相对流畅的音频    
4. 优化了录像回放，声音比较流畅。 
5. 声音保存  
   无需在SDK中设置，只需要在指定位置创建record.mark  
   android: /sdcard/data/audio/record.mark
   openwrt: /etc/config/jxapp/audio/record.mark  
   other: application dir/audio/record.mark  
   IOS: not support  
   远端声音文件名: far_当前时间.pcm  
   近端声音文件名: near_当前时间.pcm  
   均保存在 record.mark同级目录下  
6. 除了openwrt,所有平台都集成WebRTC 3A模块(增益，去噪，回声消除)，openwrt依然使用speexdsp.  
   增加： audio_play_agc_compression_gain_db，audio_send_agc_compression_gain_db两个参数，用作增益之用。 
   play,send可以设置不同的参数，因为对端设备和本机设备喇叭的功率未必相同。compression_gain_db对音量提升作用很大。webrtc官方默认为9，SDK默认为20  

1. Intercom  
  (1) IntercomSession增加peer_device_name,保存呼叫的设备名称,类似quanshitong,可用于FindDeviceConfigure。  
      FindDeviceConfigure(proxy_id,device_name,key),返回value,proxy_id:就是该呼叫走的哪个代理,intercomsession中有记录  
      device_name：peer_device_name  
      key:"dtmf"  
      value:返回通过dtmf开锁的字串  
      然后使用IntercomSessionManager.sendDTMF(session_id,value)即可开锁。  
      类似： String value =intercom.clientManager.findDeviceConfigure(proxy.proxy_id, session.peerDeviceName, "dtmf"); 
            if(value != null){
                 intercom.sessionManager.sendDTMF(session_id, value);
            }else{
                 intercom.sessionManager.unLock(session_id); 
            }
      全时通设备实际上也支持这种方式开锁，是星号键，有别于DNAKE的#。  
      sendDTMF也可以用于发送任意的按键，如果有需要的话。  
  (2) IOS版本修正一个bug
  (3) outdoor也支持DTMF开锁(可以定义是 *,#)

1. Intercom  
  (1) SDK API 去掉 SmartHomeManager.sendMCUMessage 方法，可以通过SmartHomeManager.sendMessage直接发送自定义消息  
      MCU消息收发在过去的版本一直存在，但从未使用过。 收发过程如下： 
      先说在分体机上工作原理： 

      比如底座或者一体机通过串口外接485协议设备。  
      单片机收到485协议消息(一般是二进制)，需要转换成16进制字符串，并打包到 json的data=节点中。由底座intercom终端接收到并再次打包到Smarthome消息中  
      转发给代理模块。 代理模块转发给这个家庭中所有在线的终端。 终端通过callback收到上述消息，解包还原即可获得485的消息内容。  
      
      一体机： 
      一体机由java端直接控制MCU，所以可以直接通过callback收到 485协议内容，也可以直接写入MCU，MCU再转给485设备。  
      但是，此刻就没有转发其他设备的功能，只能由当前接入485设备的直接控制。  
      如果需要转发，只能将消息再次打包成智能家居消息，然后通过SMarthome接口发出去。  
~~~   
  void MainApp::OnMCUMessageArrival(uint8_t type, bool ack, uint8_t result,
                                  const std::string &message) {
  if (!loop_->task_runner()->BelongsToCurrentThread()) {
    loop_->PostTask(FROM_HERE, base::Bind(&MainApp::OnMCUMessageArrival,
                                          weak_factory_.GetWeakPtr(),
                                          type,
                                          ack,
                                          result,
                                          message));
  } else {
    if (type == mcu::MESSAGE_TYPE_STARTUP_NUM) {
      base::FilePath mark = utils::CombineFilePath(work_dir_, "auto_restart.dat");
      if (!base::PathExists(mark)) {
        LightOn(3);
      } else {
        base::DeleteFile(mark, false);
      }

      Json::Value root;
      Json::Reader reader(Json::Features::strictMode());
      if (!reader.parse(message, root, true)) {
        return;
      }
      std::string cmd = root["cmd"].asString();
      if (cmd == "startup") {
        context_->device_start_count_ = root["num"].asUInt();
        LOG(INFO) << "embedded restart count:" << context_->device_start_count_;
        {
          base::FilePath mcu_conf_file = utils::GetAppConfPath("mcu.info");
          base::WriteFile(mcu_conf_file, message.data(), message.size());
        }

        if (context_->device_start_count_ > 0) {
          return;
        }
      }
    } else if (type == mcu::MESSAGE_TYPE_MCU) {
      /**
      * MCU消息我们包装到智能家居消息体中
      */
      IntercomInstance *instance = GetIntercom(std::string());
      if (instance == nullptr)
        return;
      
      //一体机应该从本机代理直接转发，所以首先要查找到本地代理， 底座也是通过本机代理转发的    
      const client::IntercomProxy *proxy = instance->GetProxyId(utils::SystemIdentity::GetInstance()->system_id());
      if (proxy) {
        std::vector<client::NetDeviceItem> device = proxy->getdevice("security");
        if (!device.empty()) {
          std::unique_ptr<smarthome::SmartHomeMessage> smarthome_message(
            new smarthome::SmartHomeMessage());
          smarthome_message->from_ = context_->net_client_.client_id_;
          smarthome_message->cmd_ = smarthome_switchs::kmcudevice;
          smarthome_message->content_ = message;
          smarthome_message->proxy_id_ = proxy->proxy_id_;
          smarthome_message->to_ = device[0].name_;
          smarthome_message->message_source_ = smarthome::SmartHomeMessage::SOURCE_DEVICE;
          if (instance->client_.get()) {
            std::unique_ptr<base::Bundle> bundle(new base::Bundle());
            bundle->PutString("scheme", smarthome_switchs::kScheme);
            if (proxy->lan_online()) {
              bundle->PutInt("router", (int) protocol::Router::LAN);
              bundle->PutString("client", proxy->lan_proxy_->net_client_->ToJson());
            } else if (proxy->wan_online()) {
              bundle->PutInt("router", (int) protocol::Router::PROXY);
              bundle->PutString("client", proxy->wan_proxy_->net_client_->ToJson());
            }
            bundle->PutString("message", smarthome_message->ToJson());
            instance->client_->SendIntercomMessage(std::move(bundle));
          }
        }
      }
    }
  }
}
~~~ 
 (2) 设备配置中包含level.ini文件，以前只是配置安防设备的掩码，现在增加配置外部串口的波特率。  
 (3) 优化各个平台的音频启动顺序    
     windows platform: DirectX DMO support: audio session call sequence:  
     InitRecording->InitPlayout->AttachAudioBuffer->StartPlayout->StartRecording       
     IOS platform: audio session call sequence:  
     AttachAudioBuffer->InitRecording->InitPlaytout->StartPlaytout->StarRecording    
(4) 修改WebRTC的编译控制  
    不再通过平台来区分编译选项，改成由编译宏来控制  
    1.移动端： -DENABLE_WEBRTC -DWEBRTC_USE_MOBILE  
    2.Desktop(windows, linux)  -DENABLE_WEBRTC  
    3.Openwrt：openwrt也有libwebrtc.a，但是需要编译到libframework.so中， 编译宏： -DENABLE_WEBRTC -DWEBRTC_USE_MOBILE  
    以上平台如果不提供上述宏，则默认使用speexdsp。   目前openwrt不需要音频处理，所以不用编译进去。  
    -DWEBRTC_USE_MOBILE: 表示fixed point工作模式，没有这个宏，则使用浮点。   
    通过-DEAC_FORCE_USE_SPEEX,可以强制平台使用 speexdsp 做为回音消除的引擎。  
(5) 室外机自动发现功能修改了一个bug，此bug在室内机部分由袁东修复。 此bug导致无法准确探测对端设备的离线。    
(6) 完善android AAudio引擎。  
    AAudio在 API 26 (android 8.0) 才引入的新的音频架构,具有比Opensles更高的性能和更低的延迟(初步估计延迟减少30~40MS)， 
    通过动态加载方式引入libaaudio.so, 并从android最新 source code中导入AAudio.h，在具体使用中，通过API Level来控制方法的使用。  

1. Camera在移动平台上缩放优化  
   Android平台增加CaptureConfig.screen_portrait ,如果是平板，并且要设置为竖屏工作模式的场景下设置为true，其他任何场景都是false  
   竖屏模式下，摄像头分辨率的选择要高于640X480，以便在剪裁之后图像角度不至于太过狭窄。  
2. android surface绿边的问题优化  
  

1. 室内机通过SIP服务器与室外机通讯，但没有启用ICE，如果此刻存在单向媒体流，则需要在路由器NAT上打洞，此版本仅仅针对视频流打洞
2. VideoRender中定时渲染改成立即渲染 
  

1. 修改了代理中关于NAT穿透的一个bug，在会话没有被接听的时候，代理并不会将视频转发给室外机，从而导致NAT穿透无法完成。  
   此版本改成判断包的长度，如果长度不超过12个字节(RTP空包），则允许发送到SIP服务器，从而完成NAT穿透
  

1. 适配天猫精灵版本，天猫精灵版本主要有两个问题：  
   （1）CPU占用高，这个通过启用MTK的硬件编解码进行优化  
   （2）通话一段时间资源耗尽。这个应该按照天猫精灵的要求，语音采样率必须使用32K，其他频率会导致MTK音频服务内存泄漏。  
2. Android版本IntercomConfigure.VideoCodecConfig,增加media_codec_encoder_color_format参数  
   在android平台，但凡用到MediaCodec编解码视频的都需要配置这个参数： 
   RK平台：media_codec_encoder_color_format = 0x15 
   MTK平台：media_codec_encoder_color_format = 0x13  
   硬件编码H264，要求输入的原始视频图像的格式。 0x15:等价于NV12, 0x13等价于YUV420P  

1. 重新优化了与视频有关的功能(影响所有平台)  
   (1)主要优化视频转码的效率，采用google libyuv替代ffmpeg，转码效率显著提升。  
   (2) 优化视频编解码方法，提升内存使用效率  
   (3) 优化视频渲染，同时解决某些视频分辨率绿边的问题   
2. 增加授权管理  
   (1) android和IOS移动端需要联网激活才能使用云端对讲功能。  
   (2) LAN呼叫不受影响  
3. 室外机SDK  
   (1)去掉了修改摄像头设置的功能，没有用途  
   (2)提高图像转码效率  
   (3)优化了音视频录制

1. 解决ARMV7上的内存对齐问题  
   在ARMV7上，ffmpeg解码输出的内存有对齐要求，此版本修复此问题。  
   只在GPU渲染时使用严格内存布局，避免画面出现绿边。      
2. 修复授权管理一个问题  
   (1) 服务器返回300的时候没有设置激活成功标识  
3. 优化了云端连接的时间间隔  
   (1) 通过web service获取中转服务器地址，如果不成功，初始6次，间隔为2秒，之后为1分钟  
4. 关于移动端切换网络，无法快速收到呼叫问题的原因分析  
   移动端先在室内机网络，此刻代理认为移动端在LAN中。  
   移动端切换到外网，通过云端上线，但此刻室外机呼叫移动端不会马上响应，大概需要1分多钟才能有响应。  
   原因是移动端强行切换到外网，代理中的LAN连接并未及时中断，依然认为移动端LAN在线，即使有呼叫也不能通知云端  
   这是设计使然，况此种场景比较极端，可以不予考虑。  

1. Outdoor 录制MP4修正一个bug。    

1. 优化了代理中关于切换网络的问题。  
   移动端从内网切换到外网，此刻代理中还保留内网连接，此刻如果呼叫，则会优先通知内网  
   这样会导致通知内网失败，但又不会通知外网，鸿雁发现这个问题  
   修正的方法是：当发现移动端从外网上线，我们立即断开内网连接

1. 更换授权加密KEY。  
   由于给客户提供了通用KEY工具，所以，在授权过程中更换了新的KEY

1. 修正ffmpeg的一个bug。  
  old:   
inline void ScopedPtrAVFreePacket::operator()(void *x) const {
  AVPacket *packet = static_cast<AVPacket *>(x);
  av_packet_unref(packet);
  delete packet;
}
newest:  
   inline void ScopedPtrAVFreePacket::operator()(void *x) const {
  AVPacket *packet = static_cast<AVPacket *>(x);
  av_packet_free(&packet);
}  
  chromium 使用 new AVPacket，由old方式可以释放，housekeeper使用av_packet_alloc，则必须通过下面的方式释放，否则存在内存异常

1.优化激活方式。  
  改成激活一次，中途不再验证。除非激活信息变更。  
  第一次激活必须要完成，否则无法使用云端功能。 
  跟随服务器调整了错误码。   
  

1.解决视频捕获的一个bug。  
  在redmi Note 5A手机上发现摄像头输出的图像呈现花瓶或者绿屏。  
  原因是google libyuv库工作异常。在将摄像头视频转码并旋转的时候   
  libyuv::ConvertToI420方法在上述机型上存在bug。  
  修正方法：  
  先将视频转码成YUV420P格式，然后再根据当前摄像头的角度进行旋转  
  此刻图像正常。  
  此bug影响到所有移动端以及室外机版本。非可视设备以及室内机不受影响，因为室内机不需要旋转摄像头视频    
  经测试，在小米手机上硬件编解码可以正常工作，但为保险起见，依然需要在  
  移动端选择使用FFMPEG 软件编解码。  

1. 修正摄像头预览一个地方的优化(根据视频尺寸调整遮挡图片的尺寸,svn Revision:66405)
2. 天猫精灵在切换摄像头隐私开关的时候，会导致无法打开摄像头。原因是天猫精灵在Android Camera2架构上固件存在缺陷  
   解决方案是强制天猫精灵使用Android Camera1架构。具体实现在VideoCaptureFactory.java提供静态方法，可以强制指定使用camera1架构)(svn Revision:66742)  

1. 完善自定义消息发送方式，提供两种场景  
   (1) 家庭内部发消息，可以走proxy命名空间发送，不依赖于设备  
   (2) 给其他家庭发消息，必须配置户户通，可以从户户通发送消息，此消息直接走SIP协议。    

1. 版本回退到 3.0.0.66742，最近部分修改撤销。  
2. 保留通过户户通发自定义消息功能  

1. SDK 4.0第一个发布版本  
2. 具体功能变化见其他文件说明  

1. 为了方便跟踪调试，对每通会话进行记录。client，server,outdoor在log目录下生成响应前缀+session_id.msg文件  
   该文件记录指定会话的呼叫和应答信息。此功能只有loglevel=0的时候生效。    

1. 修正JPEG解码的兼容性问题，在某些平台上JPEG解码输出格式为AV_PIX_FMT_YUVJ444P,需要转码。下一个版本考虑使用libjpeg-turbo作为JPEG编解码器。  
2. 修正切换前后摄像头的问题。  
3. 室外机SDK 增加Opengl 渲染视频图像。支持YUV420P、NV21、RGBA格式输入。  
4. 所有平台支持外部视频编码。 因而在SDK层增加一个回调方法:   
   ~~~
   底层需要上层提供编码数据的会产生这个callback，结束编码也会callback，state不同。  
   如果MediaConfig设置编码宽高为0，此刻width,height=0。此刻上层可以用任意分辨率编码。
   void onRequestExternalVideoFrameEncode(int state, int width, int height);  
  
   同时：  
    public boolean start(String intercom_conf,
                       String sip_conf,
                       String port_conf,
                       boolean use_extern_encoder);  
    室内机和移动端 use_extern_encoder =false即可。还是由SDK内部实现。  
   ~~~ 
   此方法目前可能用于地平线平台的室外机。因为底层编码考虑到通用性，效率有所损失，而地平线平台硬件性能很差，所以需要上层提供更加高效的编码。

1.和后台对接了纯云方案接口。  
2.调整 onExternalVideoFrameAvailable：参数  
  经过测试，此接口可用。  
  在地平线平台，需要用到此接口。  
3.室外机版本：  
  （1）优化了opengl实现。  
  （2）在org.chromium.media和 org.chromium.renderer包中增加如下内容：   
      a)VideoReceiver：可以从底层接收到指定格式的视频数据（这些数据来自摄像头）。  
      b)增加YuvHelper：提供各个图像格式转换，缩放，剪裁等功能。底层为google libyuv，ARM上基于NEON指令集。  

1.升级libyuv到最新版  
2.新增android端的外部编码器
3.新增静态图片编码成视频的模块  
4.修改YuvHelper，提供几个新的方法    

1.  为方便测试，客户端 proxyconf.proxy_server可以直接指定中转服务器地址  
    具体方法是：proxy_server= "119.3.5.12:17888"，即可强制指定中转服务器使用这个地方，此刻将绕过web接口请求。  
    底座的修改方法：在 inet.ini中 server=119.3.5.12:17888 即可。  
    记住，不要加http之类的scheme。
2.  对TCP连接实现进行了优化，在实际使用中并无特别改进。

1.  管理平台与客户端通讯的时候，发现在包头增加4个无用的字节。4.0版本由于更换了解包方式，因而发现了这个问题。  
    采用3.0的解包方式可以回避这个问题。就是逐字节比较，直到发现真正的包头开始解包。  
2.  安防的周期性report消息不再走云端转发，只在LAN中转发。  

1. 网络通讯中的一些关于libevent的TCP基础架构中关于错误处理的一些优化，避免误判  

1. 安防中对于强制报警没有处理布防之后的超时，因而可能立即报警。此问题在3.0中一直存在。目前在4.0中修正  

1. 在以下位置放置一个debug.mark，可以阻止在部署之后删除 update目录  
   openwrt: /etc/config/jxapp  
   android: /sdcard/data/doorkeeper/server  

1. 修改激活机制，只保留 http://auth.house-keeper.cn/api/activeCode 激活地址，详细见wiki  
2. 增加了外部视频解码器的机制，但目前平台上用不到，可能会在linux上用到。  

1. 修改了IOS下的JPEG编码问题，Videotoolbox不支持JPEG编码，切换到软编码  
2. 增加包名白名单，这样可以不用激活  

1. 室外机OnSIPDTMF增加 from参数，用于知道发送DTMF的源地址  

1. android 版本(intercom,outdoor)回音消除引擎升级到webrtc 2021版本，对对方的音频流不做任何处理  
   只对录制流进行回音消除，去噪，高通滤波，如有必要，上层可打开增益，默认不开启。  
   详细参数如下：  
~~~
  dictionary_set(d, APM_PRE_AMPLIFIER_ENABLED, "1");
  dictionary_set(d, APM_HIGH_PASS_FILTER_ENABLED, "1");
  dictionary_set(d, APM_ECHO_CANCELLER_ENABLED, config_.enable_aec ? "1" : "0");
  //一般情况下，不需要使用 AECM，未来可能被google废弃，我们直接使用 AEC3
  //dictionary_set(d, APM_ECHO_CANCELLER_MOBILE_MODE, "1");
  dictionary_set(d, APM_NOISE_SUPPRESSION_ENABLED, "1");
  dictionary_set(d, APM_TRANSIENT_SUPPRESSION_ENABLED, "1");
  if (config_.capture_agc_level > 0) {
    dictionary_set(d, APM_GAIN_CONTROL_ENABLED, "1");
    dictionary_set(d, APM_GAIN_CONTROLLER2_ENABLED, "1");
    dictionary_set(d, ADAPTIVE_DIGITAL_ENABLED, "1");
  }

  dictionary_set(d, APM_VOICE_DETECTION_ENABLED, "1");
  dictionary_set(d, APM_RESIDUAL_ECHO_DETECTOR_ENABLED, "1");
  dictionary_set(d, APM_LEVEL_ESTIMATION_ENABLED, "1");
~~~  
   IOS和底座依然使用旧的引擎
2. 修改底座从3.0升级到4.0的一个bug  

1. 主要针对回音消除做了进一步优化：  
   (1)通过观察，发现回音消除(包括两次音频重采样)，整体耗费时间可能超过4毫秒。  
      在android上，如果使用低延迟音频，则可能出现声卡每隔2.x毫秒就输出样本(或者播放样本)，  
      在这种情况下，上述的耗费时间就会引起声卡欠载。  
      因而，解决方案是使用单独的线程来处理回音消除，这样可以确保采样线程在每次调用不超过2毫秒，可以达到实时要求。    
2. 对播放音频增加agc的支持，配置方式如同以前。此部分使用早期版本的webrtc AGC 处理。但是不建议开启AGC，容易导致  
   回音消除效果减弱，并在近距离场景下引起啸叫。  

1. 完善webrtc APM模块，同时增加基于Speexdsp的回音消除。   
   一般情况下用不到speexdsp 回音消除，平板和手机可以直接使用webrtc  
   低端设备如MT7628，因为主频和性能太低，无法正常使用（CPU跑满），只能使用DSP消回声。  
   
2. 更新speexdsp到 1.2.0,可以支持 arm64 neon。    

1. android各SDK进一步优化声音处理。已经验证过了armv7-A, arm64两个平台。  
   修改了java上层接口，增加两个关于音频的高级定制参数：    
    public String audio_render_apm_config;  
    public String audio_capture_apm_config;  
    可以使用 name=value;name=value;...组合多个参数。一旦设置audio_capture_apm_config,以前的参数设置均无效。  
    只在公司自研设备上使用定制化的音频处理参数。手机端依然使用以前的配置方法。 
    以下的配置只是实例，实际上还包含其他很多参数，可以精确控制音频处理的机制：  
       mediaConfig.audio_capture_apm_config = "apm:pre_amplifier_enabled=1;" +
      "apm:high_pass_filter_enabled=1;" +
     "apm:echo_canceller_enabled=1;" +
     "apm:echo_canceller_mobile_mode=0;" +
      "apm:noise_suppression_enabled=1;" +
      "apm:noise_suppression_level=2;" +
      "apm:transient_suppression_enabled=1;" +
     "apm:gain_control_enabled=1;" +
     "apm:gain_control_mode=2;" +
     "apm:gain_controller2_enabled=1;" +
      "apm:gain_controller2_fixed_digital_gain_db=20;" +
     "apm:adaptive_digital_enabled=1;" +
     "apm:adaptive_digital_level_estimator=1;" +
     "apm:residual_echo_detector_enabled=1;" +
      "apm:voice_detection_enabled=1;" +
      "apm:level_estimation_enabled=1;";

    mediaConfig.audio_render_apm_config = "apm:noise_suppression_enabled=1;" +
      "apm:noise_suppression_level=2;" +
      "apm:gain_controller2_enabled=1;" +
      "apm:gain_controller2_fixed_digital_gain_db=20;" +  
      "apm:adaptive_digital_enabled=1;";   

2.此版本在android平台上增加对远端音频（即将用来播放）的增益和去噪功能。手机端切莫使用。  
  自研设备谨慎使用，除非声音太小。通过配置： mediaConfig.audio_render_apm_config即可。  
  

1. 主要优化webrtc参数和方法。  
   intercom，outdoor可以将audio samplerate改成16000，以提高音频品质。  
   16K的采样率将使用G722编码。但可以支持对端8K的采样率（通过SIP协商）  
2. linux(x86/arm)采用alsa的硬件延迟作为webrtc的延迟参数，这样效果更好。  
   但是android只能使用固定延迟。  
  

1. 此版本将所有第三方库都是自动构建，并且大部分库都升级到较新的版本，同时优化了编译参数。具体可见相关的WIKI。    
2. 第三方库全部使用clang 编译，不再使用 gcc。  
3. android使用 NDK 20b版本编译，支持最低版本依然是android 5.0。只支持armv7-a, armv8-a两种架构
4. IOS 第三方库最低版本支持 IOS 8.0，但SDK最低支持 IOS 9.0, xcode版本不低于 11.3.1。支持 i386,x86_64,armv7,armv7s,arm64。  
   目前还不支持arm64e(Apple A12处理器架构),不过应该向下兼容到arm64。  
5. android 回音消除使用2020年底的主干。  
6. IOS废弃speexdsp 重采样，从webrtc提取SINC算法作为高品质的音频重采样  
7. MT7628依然使用 speexdsp重采样，因为处理器性能很低，无法处理复杂算法。  

1. exsoip2 在-O2优化的情况下，在linux平台出现偶发性崩溃，其他平台未见，保险起见，所有平台使用-O0优化(不优化)  
   这是exosip2自身的问题。   

1. 将采样频率调整到16K，拨打阿里云电话时SDK使用了16K频率，导致呼叫失败。此问题只影响室外机版本。     

1. 所有平台都可以支持G722，16K得音频编码。     

1. 主要优化室外机SDK接口，可支持多路SIP协议栈。
2. 实现软件音量，目前只适用于linux平台。     

1. sip_device.cc中解决一个bug，此bug导致不接听没有视频   

1. 所有平台更新第三方库 exosip2到最新版本，旧版本存在缺陷，当一个SIP会话未正常接听后，其他会话将出现故障。  
2. 室内机连接管理平台增加websocket方式。  
   原室内机代理配置中的server.json增加websocket配置： 

   {
  "server": [
    {
      "url": "http://install.house-keeper.cn:42333",
      "key": "19880306"
    },
    {
      "url": "wss://192.168.16.175:18889/indoor", //服务器配置证书，则wss，否则:ws, indoor为path，服务器自行定义
      "key": "" //不支持传输内容对称加密。如需加密，使用 wss
    }
  ]
}

1. 修正代理中的一个bug，导致室内机无法开锁。

此版本修正代理中关于IPC的两个问题
1. libcurl新版本对RTSP支持存在bug，https://github.com/curl/curl/pull/4750
2. IPC device代码中的一个bug

此版本增加室外机代理SDK工程，其他未改。 

1.RTP传输协议中增加对重复包的处理，应付龙信项目的交换机发送重复RTP的问题。
2.室外机代理少许修改 

1.Intercom增加两种MCU的控制对象，一种是GPIO队列，通过定时轮询方式查询IO口的值，第二种是FAKE，需要外部提供防区事件
2.RTP传输对重复包优化，减少了缓冲队列(从40到10)

1.部分优化了SDK中 SIP协议栈的代码，修正几个潜在的小问题。调整了SIP调用的方法和部分逻辑。 
2.影响所有平台的SDK，代理，室内机，室外机，室外机代理，移动端
3.此版本需要将所有呼叫的场景都要验证一遍

1.修正了outdoorproxy的一个bug，当与中心管理机对讲时，室内机配置是双向视频，TCL不支持通用的RTP打包格式，  
  所以，需要特殊处理。webrtc RTP 组包时对包的大小有MTU限制，室内机视频包经过组包之后，帧较大，导致webrtc allocate payload memory失败。  
  此处的解决方案有两种，1）在室内机将中心管理机改成单向视频。2）使用最新版本   
2.去掉了整个平台的G722 语音编码支持，因为需要兼容底座，底座的编解码能力有限，处理G722编解码导致CPU资源占用过高。
3.此次修改，影响所有平台

1.最近维护和修改的最终稳定版本  
2.包含去除SIP通话中G722音频编解码支持  
3.outdoorproxy的TCL中心管理机通话的崩溃  
4.outdoor增加YUV处理的接口  

1.android Intercom,Outdoor增加 YuvConvertor,提高yuv转换得效率 

1.android Intercom,Outdoor增加 RgaConvertor,提高yuv转换得效率,此功能只能在rockchip android 8.0之后的平板上使用

1.修正代理中有关rtsp协议的三个问题
  1)sdp检查过于严格，因为rtsp中的sdp没有媒体流地址和端口导致解析失败 
  2)rtsp协议实现中少了指定stream_url
  3)如果没有找到音频流，不再设置

1.修正访客录像的bug，这个bug存在于2021年下半年的所有历史版本中。
2.Intercom音频格式必须是8K，单声道。否则会引起很多不兼容的问题

1.重新编译所有android SDK，不再编译debug版本。sdk包格式也略有变化，java目录包含所有java文件，cmake目录包含v7,v8两个平台的so
2.增加imageproc工程，提供rockchip 平台的RGA Java调用接口。只能在测试过的平台使用。
3.Intercom,outdoor两个项目都继承了RGA 2D图像变换java接口。imageproc库可以独立使用。

1.修改代理模块，使之支持京希梯口机的召梯功能，新的版本支持加前缀的房号格式。  
  在处理号码规则时，首先要将'_'前面的所有字符去除，后面才是真实的房号。

1.4.0版本中通过UDP自动发现方式部署存在bug，现在已经修复。此问题一直存在于4.0版本中，3.0版本无问题。

1. 室外机SDK增加SSDP协议实现，用于在局域网内发现设备。具体用法参考android outdoor demo。  
   最终使用 239.255.255.250:1900 这个标准组播地址，室内机发现室外机通常的包信息如下：   
   
    NOTIFY * HTTP/1.1
    HOST: 239.255.255.250:1900
    CACHE-CONTROL: max-age=60  #60秒超时
    LOCATION: http://192.168.180.70:18080 #http接口地址
    SIP: <sip:[email protected]:5060> #SIP呼叫账号
    NT: urn:genius-intercom:device:outdoor #这里必须按照这种格式进行设置，genius-intercom:表示京希门禁，outdoor：表示室外机
    NTS: ssdp:alive
    USN: uuid:123456 # 这里可用平板SN做MD5即可
    SERVER: Linux/1.0 UPnP/1.1 Villa-Outdoor/1.0.0 # 这里描述OS版本，产品版本等信息

   室内机的信息类似： 
    NOTIFY * HTTP/1.1
    HOST: 239.255.255.250:1900
    CACHE-CONTROL: max-age=60
    LOCATION: http://192.168.180.2:18080
    SIP: <sip:[email protected]:5060>
    NT: urn:genius-intercom:device:indoor
    NTS: ssdp:alive
    USN: uuid:987654321
    SERVER: Android/11 UPnP/1.1 Villa-Indoor/1.0.0

    这里的IP地址已经在收包的时候替换过了，可能和发送端设置的不同。所以，发送端不是很关心自己的IP到底是什么，一般而言，也没法真正确定自己的ip，因为组播  
    发送的时候，需要绑定不同的网卡，网卡可能有多个，ip各不相同。对方看到的ip一定是可达的ip地址。  
    这些都在SDK内部处理了，上层只会收到设备上线或者下线的通知。

1. SSDP协议实现修正几个问题。配置增加 enable_loopback设置，当enable_loopback=false，则不会收到自己发送的组播包。

1. 增加dnake的梯口机的支持。
  (1) 需要增加一个dnake设备在load.ini中
  (2) 增加dnake目录，包含完整的device.ini,ip.dat
  (3) opendoor参数不需要改，梯控支持上行下行召梯，对具体楼层房间号授权
  (4) SIP协议栈中账号支持displayname参数，这样中心管理机可以显示来电可读名称，由 ip.dat中的别名指定
  (5) device.ini中[base]节点可以配置如下参数： 
     group_address=238.9.9.1:8400
     elevator_port=4008
     dnake_key=XXX
     以上三项不配置的就是默认值，目前能工作，如果项目上遇到参数变更，可以直接改这里。

这个版本非常重要，尤其是云对讲来说，在一定的丢包率下，尽力保证视频的流畅
以往的版本并没有这个功能，只要有丢包就可能出现花屏。此版本通过NACK机制可以解决
一定比率的丢包问题。另外，此版本应该不会出现花屏，如果丢包又确实无法重传，则会出现卡顿
1.音频 jitterbuffer优化，音频更加稳定
2.视频 jitterbuffer优化
3.支持 NACK,PLI

优化SIP协议栈的底层功能。主要解决以下几个问题：
1. 在P2P呼叫场景下，自动生成合适的本地SIP账号
2. 完善SDP的本机地址的获取

1.上个版本遗漏了dnake displayname的处理，这个版本修正

1. Intercom SDK中包含一个致命bug，这个版本已修正，前面几个版本都不能用

1. RTP video接收增加一个处理逻辑，如果200毫秒没有收到可解码的帧，则请求对方
   发送关键帧

1. rv1109室外机去掉了opencv的支持，并升级了zxing版本
2. 这个版本包含前面几个版本的所有修改。

1. 解决室内机局域网呼叫兼容性的问题，原因是室内机没有经过SIP，所以没有协商payloadtype
   这个版本去掉了payloadtype的判断