tornado http basic and digest auth handler

 

python tornado微信公众号开发者认证示例代码

svn: E200015 error proxy servers config

SVN E200015错误代理服务器配置文件位置
WIN:%APPDATA%Subversionservers
其它:~/.subversion/servers

如果是用TortoiseSVN,还有更直观的GUI设置

urllib2 vs tornado.httpclient and proxy vs auth

SPA3102基础上的OBi110准新手入门到熟悉心得分享

如果说SPA3000/3102的精髓就是Dial Plan的话,那其实OBi110也还是它
只不过它将Dial Plan分成了DigitMap与OutboundCallRoute两大类,而这两大类又包含了embedded-digit-map
也就是说,任何SPA的Dial Plan都可以根据原则分成DigitMap部分与OutboundCallRoute部分,反之也可
就像OBi110的DisconnectTonePattern与SPA3102的Disconnect Tone一样,本质是相同的,但是需要格式转换

这样的好处是解决了原有Dial Plan承载了太多太多东西的负担,什么都在里面,之前一个复杂些的DP复制出来都要分好几行,而且维护成本很高,一不小心一个语法格式错误就挂了
于是OBi将Dial Plan的非线路网关(包括默认Line1、gw0-4及其它自定义DP网关)部分单独划分出来称之为DigitMap,这个就非常类似很多编程语言里的Regular Expressions,中文叫正则表达式,只用于匹配、转换或限制,我先称之为预处理,或者一级处理
DigitMap又继续优化为可以单独成为一种embedded-digit-map,包括系统的(Msp1、Msp2、Mpp、Mli等,详细AdminGuide P118有介绍)与User Defined Digit Maps,并且可以互相嵌套(谨慎使用防止递归),每个(Mlabel)单独维护并做专一的事情,提高了可易阅读性,最终还使得主DigitMap变得很小且容易维护
比如我的PHONE Port DigitMap经过合理优化,最终就只有(#[012] | (MStar) | (Mpli))这些了,而Auto Attendant DigitMap也就(<0 : $1> | (MStar) | (Mpli))那样,非常容易维护,每次新增规则只需要改一个孙子级的DigitMap即可

经过DigitMap的划分,原来Dial Plan剩下的线路网关部分就自然成为了OutboundCallRoute,这个初看貌似很复杂的东西,如果你要知道其实这只是原来很熟悉Dial Plan的一部分那就很有信心去征服它了
我也将这个工作称之为后处理,或者二级处理,因为需要结合预处理才能组合成一个完整的Dial Plan,于是其也包含了embedded-digit-map,用于衔接两者的纽带,否则就只能靠一个个预先确定好的callee number号码来前呼后应了
当然关于这个,我觉得褒贬不一,还很有争论,因为细分带来的好处我例子中已经显而易见,但同时也增加了不少冗余,我就拿系统默认的也是大家最熟悉的**9来说吧,DigitMap需要有**9(Mpp)规则用于预处理OBiTalk号码的合法性,而OutboundCallRoute也需要有{(<**9:>(Mpp)):pp}规则,而其中都包含相同的DigitMap这就是冗余,而且预处理匹配了**9前缀,后处理用于消除**9前缀,本来简单一步的事情要分两步做,增加了设置的负担,与理解的难度
比如系统默认的OBiTALK Service DigitMap为(<ob>xxxxxxxxx|obxxxxxxxxx),一开始我始终不能理解后一个规则的作用,直到后来因为上述的一二级处理机制我才慢慢明白,后个规则是给后处理用的,因为预处理已经将9位数字提前增加的前缀,这个时候如果没有后一个规则允许的话,二级处理那里是不允许通过的,这些就是所谓有很小很小弊端的地方,但总体可以用前紧后松或前松后紧的原则来避免,总之这个划分我认为是利远远大于弊的

正因为有了OutboundCallRoute,于是对应出了InboundCallRoute,这与SPA3102如何对应呢,很简单,那就是SPA PSTN Line的两个Gateway功能分别对应OBi110 SP2 Service InboundCallRoute与LINE Port InboundCallRoute的部分功能,其他两个InboundCallRoute则是独一无二无法对应的,这和SPA Line1线很单纯有关,而且OBiTALK也是横空出世的
注意对应过来的功能在OBi110这里其实是雕虫小技了,因为SPA PSTN Line线在现在看来其实就只有可怜的VoIP-To-PSTN与PSTN-To-VoIP两个小功能,这在OBi时代就不过是很简单的SP2 InboundCallRoute{li(To-PSTN-Number)}与LINE InboundCallRoute{sp2(To-VoIP-Number)}基础上的扩展,其大部分的参数细节控制都可以一一对应过来,但肯定也有一些是还不行的,比如VoIP Access List这个,用于限制安全IP地址范围的,但目前的InboundCallRoute体系里似乎就没有考虑到这点,毕竟VOIP里的号码欺骗是非常容易的,仅凭匿名或指定号码来做匹配是很不安全的
当然退一步从更高一层次的角度来看,这个也不是问题,因为同级的还有Auto Attendant,而且可以UsePIN做最后保障,可松可紧,控制方便

最后总结,OBi110按照模块划分为7个基础部分,其中
四条独立的线路,即SP1 Service、SP2 Service、OBiTALK Service、LINE Port,其基本特征是拥有InboundCallRoute而没有OutboundCallRoute
两个独立的终端,分别是PHONE Port与Auto Attendant,前者是有形的,后则是无形的,其基本特征与线路相反,拥有OutboundCallRoute而没有InboundCallRoute
一个特殊的终端,即Auto Attendant2或AA2,官方称之为local device configuration IVR,其比AA更无形,什么都没有就是它的基本特征

前面六个部分都有自己的DigitMap,特别是这么多的地方可以设置DigitMap这让初学者很畏惧,其实最关键的是终端的DigitMap,特别是有形的那个我们最常用,只要控制好了终端的DigitMap,线路的DigitMap其实是浮云
从某种角度看也可以将一紧一松的思想适用于这里,就是终端紧就线路松,反之亦然,因为一个正常的主叫通话肯定是先由终端DigitMap拨号,之后在由线路DigitMap拨出,任何一级做精确控制都是可以的
线路特有的InboundCallRoute其实就是控制将线路的来电转移到指定终端上,包括但不限于那两个基本终端,因为对于线路拨打出去的号码所对应的其实也可以理解成是一个远程终端。比如ph与li(另外一个电话的号码),就分别为本地与远程终端,只不过前者直接连接,后者用网关桥接
终端特有的OutboundCallRoute其实就是将终端DigitMap一级处理过的拨号,再经过OutboundCallRoute二级匹配后通过线路拨打出去给其他终端,包括但不限于那四条基本线路,其实这里隐含了第五条本地线路,用于AA拨打PH或PH拨打AA,甚至特殊的AA2终端也是依靠这条本地线访问

总之,OBi110是站在SPA3000的基础上深化改良并与时俱进的,如果您还在SPA时代,请不要畏惧进入OBi时代,其实这非常简单,完全可以做到除了对您本人这个Admin外的其他使用者的透明转换,包括使用习惯,当然也许目前还有一些不足,但至少持续不断的Firmware更新让我们看到了希望,在这点上是停滞许久不前的SPA3000系列所无法比拟的