《FreeSWITCH: VoIP實戰(zhàn)》：撥號計劃- Dialplan

2012-08-17 15:51:59 作者：杜金房來源：CTI論壇評論：0 　點擊：

　　可以看到，由于我們呼叫的是 1235，它在第三行測試 My Echo Test 的 1234 的時候失敗了，接在接下來測試 1235的時候成功了，便執(zhí)行相對應(yīng)的 Action - info 這個APP。它的作用就是把所有 Channel Variables 都打印到 Log 中。

　　所有的 Channel Variable 都是可以在 Dialplan 中訪問的，使用格式是 ${變量名}，如 ${destination_number}。將下列配置加入 Dialplan 中（存盤，reloadxml 不用再說了吧？）:

這次我們呼叫 1236789，看看結(jié)果：

Processing Seven <1000>->1236789 in context default
parsing [default->Echo Test] continue=false
Regex (FAIL) [Echo Test] destination_number(1236789) =~ /^echo|1234$/ break=on-false
parsing [default->Show Channel Variable] continue=false
Regex (FAIL) [Show Channel Variable] destination_number(1236789) =~ /^1235$/ break=on-false
parsing [default->Accessing Channel Variable] continue=false
Regex (PASS) [Accessing Channel Variable] destination_number(1236789) =~ /^1236(\d+)$/ break=on-false
Action log(INFO Hahaha, I know you called ${destination_number})
Action log(NOTICE The Last few digists is 789)
Action log(ERR This is not actually an error, just jocking)
Action hangup()

[DEBUG] switch_core_state_machine.c:157 sofia/internal/1000@192.168.7.10 Standard EXECUTE

EXECUTE sofia/internal/1000@192.168.7.10 log(INFO Hahaha, I know you called 1236789)
[INFO] mod_dptools.c:1152 Hahaha, I know you called 1236789
EXECUTE sofia/internal/1000@192.168.7.10 log(NOTICE The Last few digists is 789)
[NOTICE] mod_dptools.c:1152 The Last few digists is 789
EXECUTE sofia/internal/1000@192.168.7.10 log(ERR This is not actually an error, just jocking)
[ERR] mod_dptools.c:1152 This is not actually an error, just jocking
EXECUTE sofia/internal/1000@192.168.7.10 hangup()

　　跟前面一樣，我們還是從綠色的行開始看。這一次，1236789 匹配了正則表達(dá)式 ^1236(\d+)，并將 789 存儲在變量 $1 中。然后在 8-11 行看到它解析出的四個 Action（三個 log 一個 hangup）。到這里為止，Channel 的狀態(tài)一直沒有變，還處在路由查找的階段。在所有 Dialplan 解析完成后，Channel 狀態(tài)才進(jìn)行 Standard Execute 階段。理解這一點是非常重要的，我們后面再做詳細(xì)說明，但是在這里你要記住路由查找（解析）和執(zhí)行分屬于不同的階段。當(dāng) Channel 狀態(tài)進(jìn)入執(zhí)行階段后，它才開始依次執(zhí)行所有的 Action。log() 的作用就是將信息寫到 Log 中，它的第一個參數(shù)是 leglevel，就是 Log 的級別，有 INFO、Err、DEBUG等，不同的級別在彩色的終端上能以不同的顏色顯示。（詳細(xì)的級別請參考http://wiki.freeswitch.org/wiki/Mod_logfile#Log_Levels）。

　　你肯定看到彩色的 Log 了，同時也看到了用 $ 表示的 Channel Variable 被替換成了相應(yīng)的值。

　　同時你也看到，這次實驗我們特意增加了幾個 Action。一個 Action 通常有兩個參數(shù)，一個是 application，代表要執(zhí)行的 APP，另一個是 data，就是 APP 的參數(shù)，當(dāng) APP 沒有參數(shù)時，data也可能省略。

　　一個 Action 必須是一個合法的 XML 標(biāo)簽，在前面，你看到的 context，extension 等都是成對出現(xiàn)的，如。但由于 Action 比較簡單，一般彩用簡寫的形式來關(guān)閉標(biāo)簽，即。注意大于號前面的“/”，如果不小漏掉，在 reloadxml 時將會出現(xiàn)類似“+OK [[error near line 3371]: unexpected closing tag ]” 的錯誤，而實際的錯誤位置又通常不是出錯的那一行。這是在編輯 XML 文件時經(jīng)常遇到的問題，又比較難于查找。因此在修改時要多加小心，并推薦使用具有語法高亮的功能的編輯器來編輯。

　　讀到這里，你或許還有疑問，既然我們在 info APP 的輸出里沒看到 destination_number這一變量，它到底是從哪里來的呢？是這樣的，它在 info 中的輸出是 Caller-Destination-Number，但你在引用的時候就需要使用 destination_number。還有一些變量，在 info 中的輸出是 variable_xxxx，如 variable_domain_name，而實際引用時要去掉 variable_ 前綴。不要緊張，這里有一份對照表： http://wiki.freeswitch.org/wiki/Channel_Variables#Info_Application_Variable_Names_.28variable_xxxx.29

測試條件 - Conditions
動作與反動作 - Action & Anti-Action
工作機(jī)制進(jìn)階
實例解析
...

　　以上的論述應(yīng)該涵蓋了 Dialplan 的所有概念，當(dāng)然，要活學(xué)活用，還需要一些經(jīng)驗。下面，我們講幾個真實的例子。這些例子大部分來自默認(rèn)的配置文件。

　　 Local_Extension

　　我們要看的第一個例子是 Local_Extension。 FreeSWITCH 默認(rèn)的配置提供了 1000 - 1019 共 20 個 SIP 賬號，密碼都是 1234 。

<extension name="Local_Extension">
    <condition field="destination_number" expression="^(10[01][0-9])$">
    //actions
    </condition>
</extension>

　　這個框架說明，用正則表達(dá)式 (10[01][0-9])$ 來匹配被叫號碼，它匹配所有 1000 - 1019 這 20 個號碼。

　　這里我們假設(shè)在 SIP 客戶端上，用 1000 和 1001 分別注冊到了 FreeSWITCH 上，則 1000 呼叫 1001 時，F(xiàn)reeSWITCH 會建立一個 Channel，該 Channel 構(gòu)成一次呼叫的 a-leg（一條腿）。初始化完畢后，Channel 進(jìn)入 ROUTING 狀態(tài)，即進(jìn)入 Dialplan。由于被叫號碼 1001 與這里的正則表達(dá)式匹配，所以，會執(zhí)行下面這些 Action。另外，由于我們在正則表達(dá)式中使用了 “( )”，因此，匹配結(jié)果會放入變量 $1 中，因此，在這里，$1 = 1001。

　　set 和 export 都是設(shè)置一個變量，該變量的名字是 dialed_extension，值是 1001。

　　關(guān)于 set 和 export 的區(qū)別我們在前面已經(jīng)講過了。這里再重復(fù)一次： set 是將變量設(shè)置到當(dāng)前的 Channel 上，即 a-leg。而 export 則也將變量設(shè)置到 b-leg 上。當(dāng)然，這里 b-leg 還不存在。所以在這里它對該 Channel 的影響與 set 其實是一樣的。因此，使用 set 完全是多余的。但是除此之外，export 還設(shè)置了一個特殊的變量，叫 export_vars，它的值是dialed_extension。所以，實際上。上面的第二行就等價于下面的兩行：

<action application="bind_meta_app" data="1 b s execute_extension::dx XML features"/>
<action application="bind_meta_app" data="2 b s record_session::$${recordings_dir}/${caller_id_number}.${strftime(%Y-%m-%d-%H-%M-%S)}.wav"/>
<action application="bind_meta_app" data="3 b s execute_extension::cf XML features"/>
<action application="bind_meta_app" data="4 b s execute_extension::att_xfer XML features"/>

bind_meta_app 的作用是在該 Channel 是綁定 DTMF。上面四行分別綁定了 1、2、3、4 四個按鍵，它們都綁定到了 b-leg上。注意，這時候 b-leg 還不存在。所以，請記住這里，我們下面再講。

設(shè)置回鈴音是美音（不同國家的回鈴音是有區(qū)別的），${us-ring} 的值是在 vars.xml 中設(shè)置的。

設(shè)置呼叫轉(zhuǎn)移時，用戶聽到的回鈴音。

設(shè)置呼叫超時。

這些變量影響呼叫流程，詳細(xì)說明見下面的 bridge。