FreeSWITCH二次开发-CTI接口

根据之前的分析，多个线程操作一个通道就有出现死锁的概率，因为fs的switch_core_session_read_frame和switch_core_session_write_frame的实现存在死锁的可能。就是把 switch_core_session_read_frame和switch_core_session_write_frame里面同步消息改成异步消息switch_core_session_queue_message。每天晚上呼叫结束，通过 status 命令，都可以看到几个无法释放的通道。

如果媒体没初始化，就通过消息 SWITCH_MESSAGE_INDICATE_TRANSCODING_NECESSARY 去执行初始化媒体的代码，上一篇说了，可以再switch_core_session_receive_message之前先解锁session->codec_read_mutex，就可以避免这次死锁，可是switch_core_media_read_frame里面有大量的 switch_core_session_receive_message调用，如果多线程操作一个通道，都有出现死锁的概率。

跟踪FreeSWITCH代码，发现是 switch_xml.c 的函数preprocess，解析xml有问题，为了让mod_cti.so能兼容有bug版本的fs,就不修复这个bug,生成XML的时候保证cmd在data前面就可以了。今天遇到一个FreeSWITCH xml 解析bug ,因为使用的qt的xml库，属性名是用的是QMultiHash。保存，顺序是随机的，有时候生成的vars cmd和data的顺序是这样子。，发现竟然不生效，必须。2023年6月25日。

FreeSWITCH libsofia websocket (wss) js.sip sipjs突然全部掉线注册不上的BUG 最近1年经常有人和我说这个问题，我说你用更老版本的libsofia库就好了，1年过去了，FreeSWITCH官方还没解决这个BUG，我只好自己动手了，经过一上午和一中午的分析和测试，成功定位问题并且解决，如果您也遇到这个问题，可以联系我付费获取修复bug的libsofia库。

最后卡在switch_core_media_set_codec函数里面的switch_core_session_lock_codec_write(session)步骤。Thread 2 (Thread 0x7f9d2f76b700 (LWP 30595)): 的调用堆栈 函数 switch_core_session_read_frame 里面调用了switch_core_session_perform_receive_message，我查看了一下这个提交说明。接下来就是分析代码找出死锁原因了。