虽然现有的FreeSWITCH功能已经很强大,但是很多情况下,为了配合业务上的功能,还需要做一些定制开发。
有一个基本需求是:如何控制fs外呼,并跟踪外呼后的一系列状态。
下面我就把自己现有的解决方案跟大家分享下,以便抛砖引玉,引出大家更好的方案。
我的方案也简单,在呼叫之前,指定呼叫的uuid,然后根据该uuid跟踪呼叫到完整状态。
所以说freeswitch考虑比较周到,连获取uuid的方法都提供了!
当然,你也可以使用自己到方式来生成uuid。不过,一旦uuid出现重复,可是会出现比较麻烦的问题,所以还是使用freeswitch的官方提供的方法比较靠谱。
命令如下:
create_uuid
该命令会返回一个可用的uuid。
无需多说,此处originate命令登场,不过和平时使用区别的地方是需要指定呼叫的uuid。
下面是两种指定方法,可选择性试用:
方案一:在呼叫时,指定A腿uuid
originate {origination_uuid=xxxxx}user/60401 60402
方案二:在呼叫时,同时指定A腿和B腿的UUID
originate {origination_uuid=xxxxx}user/60401 &bridge({origination_uuid=yyyyy}user/60402)
在使用该命令后,通过命令show channels就可看到两个新创建的通道和指定的通道uuid,xxxxx和yyyyy。
此处留给大家自己去验证了!
同时也感谢杜老大的书,这条命令是从他的书上学来的。
跟踪呼叫,说白了,其实很简单,只是有的人可能没留意到而已,就是利用FreeSWITCH的事件机制进行跟踪。关于事件如何订阅,不是这里的重点,略去不说。
下面先说说一些基本常识:
1、跟呼叫相关的通道事件有如下几个:
Channel_Create:通道创建事件
Channel_Progress:通道振铃事件
Channel_Answer:通道应答事件
Channel_Bridge:通道桥接事件
Channel_Hangup:通道挂断事件
2、通道事件的Unique_ID字段与我们呼叫前指定的UUID相同,这个也是我们能跟踪的前提。
有了上面两个条件之后,跟踪就变得简单和美妙起来!在呼叫开始前,将呼叫对象与uuid的对应关系存到数据库中,在收到不同的事件后,根据事件的Unique_ID找到对应的呼叫对象,然后更新它的呼叫状态即可。
1)Channel_Create事件比较特殊,含有的内容比较少,所以处理起来要特别注意。
该事件是在呼叫开始Routing之前就被抛出来,换句话说,你在dialplan中定义的任何变量都不会被读取到。如果这点没注意到的话,会导致判断逻辑出现问题。
2)Channel_Bridge事件中同时含有A腿和B腿的UUID,具体字段我是不打了,感兴趣的可以自己看看