Asterisk Software PBX 學習筆記

朋友，有沒有想過你現在正追求什麼？

Read more »

如果行過旺角，你便要小心了！

這是我昨晚的親身經歷。

時間係 4/18 晚上八時左右。地點係先達側面花園街黃大仙小巴站對出。

當我係花園街行去搭車途中，突然有人向我迎面衝過來，其實我已經嘗試避開佢，但都係避唔開。係佢撞向我肩膀時，係佢身上跌出一副太陽眼鏡，接著佢好大聲話：呢副太陽眼鏡好貴嫁。其實我都無為意照直行，但我發現佢追過來，所以我便急向花園街街市跑！當其時我開始確實我遇見到屈錢黨了（六合彩又唔見我中？！）！跑到街市後，呢個時間佢想兜截我，但我逃脫了，還上了一架小巴，而這時我發覺原來有一個同黨的。我心想呢個時候佢應該知難而退，但佢竟然跟我上車（SHIT!），佢指住我講：係男人就落車！我見佢唔放棄，我便拿起電話然後對佢講：我報警。當其時我開始按鍵打９９９，佢應該覺得自己不能夠得逞，所以佢落車然後同佢的同黨離去。

所以如果大家行過旺角真係要小心小心。

參考:http://hostseries.com/agentcallbacklogin-alternative/

AgentCallBackLogin()這個Dialplan 功能在 Asterisk 1.6.x 後已經被删去了。因此，用 Asterisk 1.6.x 的 ACD 功能的話這部分便需要自己用 dialplan 解決了。以下的 source code 是小弟自己在 Google 找出來的。功能有待驗證。

voicemail.conf

[agent]
1050 => 1234,Robert,agents@hostseries.com,attach=yes|saycid=yes|envelope=yes|delete=yes|nextaftercmd=no

extensions.conf

[internal]
exten => 701,1,VMAuthenticate(@agent|)
exten => 701,n,AddQueueMember(SALES|local/${AUTH_MAILBOX}@agents/n)
exten => 701,n,AddQueueMember(SUPPORT|local/${AUTH_MAILBOX}@agents/n)
exten => 701,n,Read(AGENT_SIP|agent-newlocation)
exten => 701,n,Set(DB(agent_sip/${AUTH_MAILBOX})=${AGENT_SIP})
exten => 701,n,Playback(agent-loginok)
exten => 701,n,Playback(goodbye)
exten => 701,n,Hangup

exten => 702,1,VMAuthenticate(@agent|)
exten => 702,n,RemoveQueueMember(SALES|local/${AUTH_MAILBOX}@agents/n)
exten => 702,n,RemoveQueueMember(SUPPORT|local/${AUTH_MAILBOX}@agents/n)
exten => 702,n,Set(oldvar=${DB_DELETE(agent_sip/${AUTH_MAILBOX})})
exten => 702,n,Playback(agent-loggedoff)
exten => 702,n,Playback(goodbye)
exten => 702,n,Hangup

[agents]
exten => 1050,1,Set(AGENT_SIP=${DB(agent_sip/1050)})

exten => 1050,n,Dial(SIP/${AGENT_SIP})

IAX2 (Inter-Asterisk eXchange Version 2) 現已成為 RFC-5456

全文：

http://www.rfc-editor.org/authors/rfc5456.txt

Asterisk 1.6 初試啼聲！

實作環境如下：

T1 是用香港某大電信供應商，所以今次並不是實驗室環境下工作，是直接接駁街線，一個完全真實的環境下工作。

關於 T1 下的Switch type 和 Protocol的設定如下：

/etc/dahdi/system.conf　的內容節錄：

span=1,1,0,esf,b8zs
bchan=1-23
dchan=24
echocanceller=mg2,1-23

/etc/asterisk/chan_dahdi.conf 　的內容節錄：

switchtype=4ess
allow=ulaw
signalling=pri_cpe
echocancel=yes

實作1： 收發傳真，Asterisk 作為一台 Fax Server 的實作

以往，Asterisk 在收發傳真這一功能上一直不合格。雖然Asterisk可以安裝 SpanDSP 這一 library 來支援傳真的功能，但可惜SpanDSP 在傳真這功能上一直未如理想。以往我們會倚靠一套老牌的 OpenSource Fax Server 名叫 Hylafax 來收發傳真。如果在 1.4.x 下而 linux kernel ver. 是 2.6.x 以上，我們可以選擇 Third party 的 module 來支援 Asterisk傳真例如 PikaFax這一個收費的 asterisk module。

現在，Asterisk 1.6.x 如支持傳真功能的話便要安裝 SpanDSP 0.0.5 。實作上也確定 Asterisk 1.6.x 的收發傳真功能是成功的。我自己會用以下四個方式來測試傳真。

1. 經由 T1 Trunk 直接收發傳真
2. 用最新版本的 ZoIPER (http://www.attractel.com/)經T.38 Protocol
3. 架設兩部Asterisk。用第一部 Asterisk 經由 T1 Trunk 作Gateway，Fax traffic 會由 T1經第一部 Asterisk 再經 T.38 轉接到 第二部Asterisk收發傳真 。
4. 架設兩部Asterisk。用第一部 Asterisk 經由 T1 Trunk 作Gateway，Fax traffic 會由 T1經第一部 Asterisk 再經SIP轉接到 第二部Asterisk收發傳真 。SIP 的 CODEC 會用 uLaw。

無論系統是經由 T1 Trunk或T.38 Fax Over IP 收發傳真也沒有問題。但如果對方沒有 T.38 Protocol 而是經由 SIP 再用 muLaw 來收發傳真的話也可以，但是 SIP + muLaw 我發現會有 loss Frame 的情況出現。但總括來說，今次Asterisk 收發傳真的實作是相當成功的。她現在已不須要用其他 Fax Server 比如 HylaFax 和其他 Third Party Module，自己已經 native support 傳真。我們也可以用 Dialplan 或是用 AGI 來直接管理收發傳真的功能。在Fax Server 或將來的Unified Messaging 系統上的實作上有很大的幫助！

Asterisk 1.6.x的傳真的實作有一樣要注意。在Dialplan 內呼叫 Fax application 與以往有所不同。以前收發傳真的 application 是 rxfax 和 txfax，但現在已經改為 ReceiveFax 和 TransmitFax 了。

實作2：Asterisk 1.6.x Manager API 的 Originate打不到電話的問題

Manager API 有一個 Originate 的功能，可以指示 Asterisk 打電話，但發覺 Asterisk 1.6.x 的 Originate 無論我怎樣呼叫她也會傳回錯誤回來。

這應該是 Asterisk Manager 的錯誤了。

Asterisk Manager 的 source code 是在：

/asterisk-1.6.0.3/main/manager.c

在 manager.c 大約 2140 行有一 function 名：

static int action_originate(struct mansession *s, const struct message *m)

這裏便是 Asterisk Manager  Originate 的真身了。

再看第2166 行，這裡是用作測試 channel name 是否 empty string，如果是empty string便傳回錯誤，否則便繼續。原本的 sorrce code 是這樣：

[2140] static int action_originate(struct mansession *s, const struct message *m)
{
[2142]    const char *name = astman_get_header(m, “Channel”);
[2143]    const char *exten = astman_get_header(m, “Exten”);
[2144]    const char *context = astman_get_header(m, “Context”);
[2145]    const char *priority = astman_get_header(m, “Priority”);
[2146]    const char *timeout = astman_get_header(m, “Timeout”);
[2147]    const char *callerid = astman_get_header(m, “CallerID”);
[2148]    const char *account = astman_get_header(m, “Account”);
[2149]    const char *app = astman_get_header(m, “Application”);
[2150]    const char *appdata = astman_get_header(m, “Data”);
[2151]    const char *async = astman_get_header(m, “Async”);
[2152]    const char *id = astman_get_header(m, “ActionID”);
[2153]    const char *codecs = astman_get_header(m, “Codecs”);
[2154]    struct ast_variable *vars = astman_get_variables(m);
[2155]    char *tech, *data;
[2156]    char *l = NULL, *n = NULL;
[2157]    int pi = 0;
[2158]    int res;
[2159]    int to = 30000;
[2160]    int reason = 0;
[2161]    char tmp[256];
[2162]    char tmp2[256];
[2163]    int format = AST_FORMAT_SLINEAR;

[2165]    pthread_t th;
[2166]    if (!ast_strlen_zero(name)) {
[2167]        astman_send_error(s, m, “Channel not specified”);
[2168]        return 0;
[2169]    }

看來第2166行應該錯了。這裡應該改為：

[2165]    pthread_t th;
[2166]    if (ast_strlen_zero(name)) {
[2167]        astman_send_error(s, m, “Channel not specified”);
[2168]        return 0;
[2169]    }

改好了後，再compile 和 install。Originate 便可以正常工作了。

實作3：Asterisk 1.6.x FastAGI和 Asterisk Java 與舊版本的小小不同

如果你的 Asterisk Java(http://asterisk-java.org/) FastAGI Server 要和新的Asterisk 1.6.x 實作時便要注意。以往如果 Asterisk 有 channel hangup 時，因為 FastAGI Server 的TCP connect 在 cahnnel hangup 後同時中斷的關係，AsteriskJava會throw一個org.asteriskjava.fastagi.AgiNetworkException。但現在 Asterisk 1.6.x 在 channel hangup 後 TCP channel 仍然保持連線，所以這個 exception 便收不到了。如果你的 FastAGI Server 用Asterisk Java 的話，這點要注意。而channel hangup 後用 getChannelStatus() 這一個 function 會傳回 -1來代表 channel down。這點好Asterisk Java像沒有 doucment 到。而她們的 doucment 只說getChannelStatus()會傳回 0 來代表 channel down。但實作上這效果並不是這樣。

實作4：Asterisk 1.6.x 大量關於設定的 Syntax不能與前版本相容

比方以下的例子：

exten => _X.,n,SetTransferCapability(SPEECH)

在 Asterisk 1.6 以後便不能再使用了。這應改為：

exten => _X.,1,Set(TRANSFERCAPABILITY=SPEECH)

相關的資訊如下：

http://www.voip-info.org/wiki/view/Asterisk+variables

結論：

作為一部 IP-PBX來說，Asterisk 的功能絶對超班！而 Asterisk 1.6.x 絶對有當 Unified Messaging Service 的 IP-PBX 的潛力。問題是在較複雜的 Call Centre環境下，ACD 需要作較大的修改來支持Unified Messaging，而且作為一部IP-PBX ，穩定絶對是第一位！這點Asterisk 1.2.x 表現很優秀！Asterisk 1.6 必須通過數以年計的穩定性試煉。無論我們的 IP-PBX的功能是何等強大，始終電話已經是必須品，現在有很多緊急服務也需要用電話提供重要服務，客戶是很難容許一套不穩定的電話系統。所以把 Asterisk 納入你的專案時，不要當 Asterisk 是一套普通的電腦系統來看待，電話系統的 Service Level 的要求是相比其他的 IT 系統高出很多很多很多！所以如果開始計劃 Asterisk 作為你的 Key System時，不要吝嗇硬件的支出。稳定的系統是有利 Asterisk 的發揮。

http://www.cww.net.cn/manufacture/html/2009/1/13/2009113829472432.htm

作 者：丘慧慧

中国3G——这个看似宏大的命题，对于征战全球市场多年的华为而言，这只不过是其全球战略的一个自然延续。

2009年1月12日，华为技术有限公司(下称华为)首度召开公司创立以来的年度媒体沟通汇报会，并试图以相对开放的姿态，解构多年来被外界强加于自身的种种神秘。

当天，华为公布的数据显示，2008年，华为取得了233亿美元的合同销售额，其中海外销售占比达75%。与此同时，华为2008年全年纳税总额高达 120亿元。在全球通讯设备巨头纷纷遭遇滑坡、亏损、重组的当下，这毫无疑问是一份漂亮的成绩单，尤其是纵观华为自2004年以来的成长柱状图，其进取尽 收眼底——2004-2008年，华为合同销售额从56亿美元快速上升至233亿美元，海外销售占比从43%上升至75%，年均增速高于40%。

此时，距离中国发放3G牌照仅5日之隔，而距离华为国际化征途开始，已过去整整十年。

华为回应“地狱价”招标

对于华为而言，刚刚揭晓的中国3G格局——中移动运营TD-SCDMA、中国联通运营WCDMA、中国电信运营CDMA2000——或许并不是预期当中最为理想的排列组合。显然，华为赌注最重的WCDMA并没有落到最值得期待的中移动身上，相反中移动的最终使命是承担本土标准TD的大任，而TD并非华为的强项。

但是这似乎已经不重要了，尤其是在华为从CDMA上掰回一局之后。

事实上，对于不久前的那场CDMA招标“地狱价”风波，身为湖南人的华为高级副总裁徐直军，以其特有的爽直毫不回避地回应记者：“大家都知道，华为过去在 联通C网的市场份额几乎为零，我们奋力争夺，抓住这轮设备以旧换新的机会，给了一些优惠，作了一些免费替换，将来扩容和新建市场利润还是可观的。”

他同时强调圈地只是一种行业惯性，“我们是一个在市场经济环境下成长起来的公司，我们知道要赚钱企业才能成长上去，但并不是做一单子就要挣一单子的钱，电信市场是一个长期投资行业，任何一个企业都会算这笔账”。徐同时表示，华为CDMA产品线目前是盈利的。

有人把2008年中兴通讯与华为(下称中华)在中国“准3G”战役上的剑拔弩张归结为两家中国本土企业一贯“血拼”的延续，尤其是在中国的3G棋局出人意 料地被打乱之后——由于TD的关系，中兴未来与中移动的合作必然越发紧密，而事实上，在此之前，中移动是中兴通讯国内运营商最坚硬的堡垒，与华为此前在GSM上则是与中移动越走越近。

毫无悬念，因格局错位而加剧的“中华”之战，还将再延续到接下来的3G建网高峰中。

然而，从另一个角度看，“中华”的3G恶战，在很大程度上反映了中国本土设备商的狂欢。中国从2008年开始的电信建设高潮几乎是处于谨慎投资的全球市场屈指可数的几个亮点之一。但是由于本土设备商的崛起，一度在中国占据主要市场份额的国外设备巨头则日渐势微，北电、摩托罗拉、诺-西、阿朗由于整体实力的下滑，老设备被大量替代。

遍览全球通讯厂商，能分别在WCDMA、TD、CDMA2000三大技术上都具备全业务研发及解决方案能力的厂商，似乎只余下华为、中兴，以及欧系的爱立信、诺-西(其已实质退出CDMA市场)。摩托罗拉、北电等目前仅能偏安于CDMA一隅，但整体实力已乏善可陈。

在如此大背景下，未来中国3G舞台上，声音最为高亢的表演，可能在中国本土企业中展开，这是因为从大方向上看，他们拥有相同的技术成本优势，相同人才基础环境，相似的产品线和市场战略。

“行业洗牌并不意味着价格战。”对于记者的“价格战是否会加剧”的追问，徐直军快速回答说，“洗牌意味着运营商的‘短名单’更少，我们的机会更多。”

除此之外，2008年，华为适时地针对TD的市场战略上做出重大改变，“我们把鼎桥重新定义为一个研发中心，这是因为，长期研发、运维能力和针对运营商的 支持部门等会影响到运营商的选择，这种能力鼎桥没有，而华为和诺-西有”。这可视为华为对过去战略判断失误的一次重要纠错。

2009年突破300亿美元

但挑战依旧巨大。

对于这几年快速发展的华为而言，现金流是一个绕不过去的话题。根据2007年的销售规模测算，华为已成功超越北电，晋级全球通讯设备前五名，与此同时，位 居前五的设备商中，诺-西、摩托罗拉已显出下滑或亏损的疲态——在庞大的机会市场面前，华为能否平衡好快速扩长与短期财务稳健的关系？

有观点认为，在过去的一年，华为对金融杠杆的运作“是在钢丝上行走”，尤其是2007年，其营业利润率已经从2003年的19%下降到了2007年的 7%，净利润率则从14%下降到了5%；与此同时，华为过去相对低的资产负债率也在攀升，2005年之前，华为负债率控制在50%以下，2007年已经达 到67%的高位。

徐直军表示，华为2008年的财务报表目前正在经由KPMG进行财务审计，详细数据将于今年4月公布，“华为2008年经营性利润预计将达到10%以上”，同时净利润以及资产负债率等情况均比“优于上一年”。对于这一点，徐直军显得很有信心。

徐亦坦陈，作为非上市公司的华为，在财务杠杆上“会让我们更关注公司的长远利益，而不仅是短期效益”。他同时也强调说，华为2009年合同销售额或将突破300亿美元，“成长速度会有所下降”。

他说，华为近年也在着力控制自己的节奏，尤其是2008年，华为开始引入Accenture顾问公司，加强了华为在CRM(客户关系管理)上的执行力。他 解释说，华为试图将IPD(集成产品开发)上的成功复制到CRM上。过去，华为一直在自己进行CRM管理流程的设置，专业化不强，引入Accenture 公司后，主要解决的问题是全球回款效率提高的问题，“我们强调，要把机会变为合同，把合同变为现金”。

有消息称，华为去年第四季度的回款理想，似乎CRM改善已初见成效。

Microsoft Office Communication Server 2007 (OCS)  是一套整合企業內即時性通訊系統。大家可以想像它是 Microsoft 所生產的 PABX 系統。

http://www.microsoft.com/taiwan/promo/ocs/

我嘗試過OCS 與 Asterisk 作系統整合是可行的。事前需要注意三東西：

1. OCS 是利用 Mediation Server 來與各大 PABX 系統作整合橋樑。如果她需要與 Asterisk 作整合，這東西不可少。
2. OCS 的通訊協定(Protocol)是 TCP SIP。而 Asterisk 只有 1.6.x 才有 TCP SIP 的支援。所以，Asterisk 1.6.x 是唯一的選擇。
3. 注意 E.164 的電話號碼格式。OCS 是嚴格使用E.164 標準。

注意以上三點，Asterisk 和 OCS 的整合應該沒有什麼難度。但因為 OCS 的系統很大很大，所以我建議去 Amazon 買一本 OCS resources kit 作參考。

三百年前有個小女孩，愛穿紅披肩, 大家都稱她”小紅帽”。那年平安夜，小紅帽到森林裡探望外婆, 途中被大灰狼一口吃掉了(！) (咁快???) 之後大灰狼發現自己還未吃飽, 連忙趕到外婆家，一口把外婆吃掉了。吃飽的大灰狼躺在床上想睡覺，卻被突如其來的肚痛折磨得生不如死, 忍不住跑到河邊，嘔吐大作，把外婆和小紅帽原封不動地吐出來(！) 小紅帽和外婆得救了，大灰狼也從此不敢再暴飲暴食了。

三百年前有個牧童每天到山上放羊。由於覺得很悶很無聊，他時常跑到山下唱衰大灰狼(？) 訛稱牠吃掉自己的羊云云。謠言傳到大灰狼耳邊, 使牠非常生氣，決定要找牧童算帳。那年聖誕節，大灰狼來到山上，看見牧童的羊群就二話不說先吃掉三幾隻，吃不完就用自備麻包袋打包，帶回去給狼媽狼爸享 用。結果牧童損失好慘重，再也不敢亂講是非了。

三百年前有個貧窮的豬家庭。大豬, 二豬和小豬都長大了，但豬媽媽沒有錢幫牠們買屋置業，只好叫牠們出去省城(!!!)碰運氣。大豬在路上遇到一個富商, 馬上向富商募捐, 籌得首期。二豬也遇到同一位富商, 牠留在富商身邊工作，每月取得固定工資。小豬同樣遇到那位富商，並將身上僅有的衣物都送給他，請求富商收他為徒，教牠做生意。那年boxing day，大灰狼入城。大豬找不到善長人翁, 房子早就斷供了, 流落街頭, 被大灰狼吃掉了。二豬的工資全都用來供樓，足襟見肘，沒有錢吃飯結果餓暈在街頭，也被大灰狼吃掉了。小豬學會做生意後，憑著富商的幫忙賺了很多錢，還買了 一棟別墅，一次過付清，安居樂業。

http://tabodiary.blogspot.com/2008/12/blog_25.html

Happy new year