FreeSWITCH 使用指北(2)-多段音频顺序播放的设置

1. 多段音频顺序播放的设置

在 FreeSWITCH 中涉及到放音的 APP 有不少，比较典型的是播放录音文件的 playback 和 play_and_detect_speech 。这两个 APP 播放录音的功能都依赖于 switch_ivr_play_say.c#switch_ivr_play_file() 函数，而该函数可以借助 file_string 实现多段音频播放，示例如下：

originate user/1000 &playback(file_string://ivr/8000/ivr-welcome1.wav!ivr/8000/welcome2.wav)

file_string:// 前缀不能省略，这个代表的是 FreeSWITCH 中的一个文件管理模块，多个音频文件用 ! 拼起来即可。注意如果文件名中含有 ! 符号，也可以使用通道变量 playback_delimiter 来修改文件间的分隔符号

2. uuid_bridge 时机问题

在 FreeSWITCH 外呼系统中，常驻坐席拨打用户时接通双方的 uuid_bridge 命令执行时机很关键。通常如果坐席不需要听用户的早媒体，那么在收到 CHANNEL_ANSWER 事件时执行 uuid_bridge 最稳妥，几乎不会产生什么问题。 但是当坐席需要听早媒体的时候，就需要在 SIP 交互更早期 bridge 坐席和用户，比较合适的事件是 CHANNEL_PROGRESS_MEDIA

CHANNEL_PROGRESS_MEDIA 的产生时机是 FreeSWITCH 收到被叫 180/183 响应并且响应中带了 sdp 时，一般这时候已经开始拉起 RTP 传输早媒体了，但是使用这个事件也有以下几个问题：

1. 线路商直到 200 响应才带 sdp
   生产环境发现线路商返回的 SIP 响应中偶现 180 不带 sdp，183 直接不发，直到 200 才把 sdp 带过来，这就直接导致 FreeSWITCH 根本不会发出 CHANNEL_PROGRESS_MEDIA 事件，进而导致 uuid_bridge 未执行，坐席和用户互相听不到对方的声音。对于这种情况，一个解决方案是在收到 CHANNEL_ANSWER 事件时根据相关通道变量判断当前坐席和用户是否已经 bridge 上，如果没有对接上，则兜底执行 uuid_bridge 即可
2. 用户拒接导致坐席挂断
   在收到 CHANNEL_PROGRESS_MEDIA 事件执行 uuid_bridge 后，如果被叫拒接 FreeSWITCH 会偶现 DESTINATION_OUT_OF_ORDER 挂断异常，并导致常驻坐席也被挂断。这个问题多方查找资料未找到原因，大致猜测是 FreeSWITCH 执行 uuid_bridge 命令时会修改坐席会话状态，被叫拒接动作也会修改主叫坐席的会话状态，二者同时发生时可能有多线程操作造成坐席会话状态机流转异常，进而造成坐席会话提前挂断。这个暂时没有什么好的解决方案，一个 workaround 是在收到 CHANNEL_PROGRESS_MEDIA 事件后延时执行 uuid_bridge，可以降低问题发生的频率