【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 
1. Asterisk拨号计划简介
自己查资料
2. Asterisk配置
先添加SIP分机 801，用软电话注册分机后，修改801分机的context=test-inc ，因为我们下面要探究Asterisk 基于类似正则表达式的匹配以及include=>包含指令的优先级。在asterisk拨号计划配置文件extensions.conf 中加入如下拨号规则
[test-inc]
include => inc1
include => inc2
include => inc3
exten => _.,1,NooP(==00==)
[inc1]
exten => _33XX,1,NooP(==11==)
[inc2]
exten => _22.,1,NooP(==22==)
[inc3]
exten => 3333,1,NooP(==3333==)
3. 先直接给出结论
1）在同一个context中，对于正则匹配的规则，分机越详细的规则 对应的APP就会被优先匹配执行。例如：
exten=> _X5X.,n,APP1 和 exten=> _15X.,n,APP2 ,后面的正则匹配表达式“_15X.” 明显就比前面的要详细和明确，所以对于 exten为 1581000000的手机号，那么优先执行后面的拨号计划，也就是执行APP2
2）容器类context(也就是有include=>包含子context的上下文),比如上面的[test-inc]中的明确给出的拨号计划语句，总是比它用 include=> 指令包含的子context中的优先级要高，即使子context里面的正则匹配比它的父context还要详细和明确，只要拨号的分机extension能够匹配父context中的分机正则表达式分机，那么拨号计划的流程绝对不会执行到子context。 例如上面的例子中，父context 有一个 exten => _.,1,NooP(==00==) 这样的_.的全部匹配的分机正则表达式，那么所有sip分机配置中凡是设置了context=test-inc 的分机拨号后都只能执行NooP(==00==)。因为_.是万能匹配的，所有的分机都可以在父context [test-inc]中找到匹配，所以子context中的拨号规则永远也不会执行。
测试：请用801拨打3333测试，你会发现 asterisk CLI> 输出的是执行NooP(==00==) ，而不是 NooP(==3333==) ，请自行测试。
另外：如果父context中匹配不了分机拨打的extension,那么asterisk才会考虑去匹配子context中的规则。
3）某个父context中的include=> 中的优先级是 从上到下而递减的。 举例来说： [test-inc] 中匹配优先级inc1 > inc2 > inc3 。具体体现在某个拨号规则，在父context中没有匹配，那么aterisk将会查找include=>子context 中的拨号规则去寻求匹配，但是是有优先级顺序的。比如某个来电的分机匹配了 inc1中的extension规则，即使在 inc2,inc3中有更加明确的正则表达式匹配，结果也不会去匹配inc2或者inc3中的规则的。
请注释掉上面的“exten => _.,1,NooP(==00==)” ，然后重载拨号规则，再拨打3333 ，你将会发现执行的是[inc1]中的 “NooP(==11==)” 而非“[inc3]”中的 “NooP(==3333==)” 。请自行测试。
4. 明白了上述几点，也就会明白为什么FreePBX生成的拨号规则总会一个 include => XXXX-custom 放在每个context的第一行，而且FreePBX会有调整出局路由优先级的概念了
来源：oschina
链接：https://my.oschina.net/u/939089/blog/147378