Asterisk權威指南/第十一章 保持和轉移

本章集中討論PBX系統的兩個重要方面：Parking一個呼叫並允許它在另外一部分機上恢復，以及Paging功能。利用paging功能，我們可以通報這個呼叫時找誰的以及如何接聽這個呼叫。

在Asterisk中，這兩個功能是彼此獨立的，並且都可以單獨使用。一些擁有大型倉庫，或者那些員工在辦公室中不斷移動而不需要整天坐在辦公桌旁的商業機構可以利用 paging and parking功能在辦公室中轉接電話。在本章中，我們將向你展示如何在傳統環境中利用parking and paging，以及一些對這一常用功能的更現代用法。

features.conf

Asterisk支持所有現代PBX系統的通用特性。許多這些特性都需要一些可選得配置參數。features.conf就是Asterisk中用於修改或定義特性參數的文件。

基於DTMF的特性

在features.conf里定義的許多參數只有當呼叫已經通過Dialplan中的Dial()或Queue()應用程式伴隨K,k,H,h,T,t,W,w,X,x等參數被成功橋接之後才能生效。用這種方法使用的特性稱為基於DTMF的特性（意思是它們不可以通過SIP消息使用，而只能通過語音通道的信號音才能觸發）。

SIP channel的呼叫轉移（例如從一部SIP電話機上）可以被SIP話機自身的功能處理，不會受到features.conf中的任何定義影響。

The [general] section

在features.conf的[general]部分，你可以定義一些選項微調Asterisk中park和transfer的一些行為。這些選項參見表格1

表格 1 features.conf [general] section

根據comebacktoorigin選項處理超時Parked Calls

這個選項配置當parked call超時情況下的行為。comebacktoorigin可能的取值包括：

yes(default)

當parked call超時後，Asterisk會嘗試將呼叫轉回發起這個parked call的channel。如果這個channel不再可用，Asterisk會掛斷這個呼叫。

no

當你希望對於超時的parked call執行一些客戶化的dialplan功能時，可以使用這個選項。這個parked call會在超後被轉給dialplan中的特定位置，在那裡會完美的處理這個呼叫（這可能是簡單的把這個呼叫轉給另一部分機，或者按某種排序做查找）。

你也許需要顧及這樣一些parked calls，即無法把這些parked call返回到發起它們的channel。舉例來說，當發起這個parked call的channel同時也是另一個系統的trunk時，將沒有足夠的信息把這個parked call返回到另一個系統中的正確用戶。超時後實際要求的處理會比comebacktoorigin=yes能夠處理的情況要複雜得多。 當comebacktooriginal=no時超時的parked calls會被轉到parkedcallstimeout context 處理。

Dialplan（和contexts）的細節參見第六章。

轉回的目標分機由parked這個呼叫的channel名構成。例如，如果名為0004F2040808的SIPpeer parked了這個呼叫，則轉回的目標分機是SIP_0004F2040808。

如果這個分機不存在，這個呼叫會被轉到parkedcallstimeout context中的s分機。最後，如果parkedcallstimeout的s分機也不存在，呼叫會被轉到default context的s分機。

另外，對於配置comebacktooriginal=no的呼叫，Asterisk會在park-dial context下創建一個SIP_0004F2040808分機。這個分機用於利用Dial()拔打SIP/0004F2040808。

The [featuremap] Section

在這部分可以定義特定的DTMF序列，它們將觸發連接的Channel上的不同特性，通過Dial()或Queue()應用程式的選項。請參見表格

默認的blindxfer和disconnect特性碼分別是#和*。通常，你可能想要修改它們的默認值，因為它們可能用於你希望做的其它事（例如，如果你在你的Dial()命令中使用了Tt選項，每次你按下#時都會發起一個transfer）。

The [applicationmap] Section

features.conf的這部分用於映射DTMF碼到dialplan應用程式。主叫將進入hold狀態，直到相應的應用程式完全執行完。

定義一個應用程式映射的語法如下所示（必須被寫在同一行，換行是不允許的）：

<FeatureName> => <DTMF_sequence>,<ActivateOn>[/<ActivatedBy>],<Application>([<AppArguments>])[,MOH_Class]

你需要做下述事宜：

1. 給定映射一個名字，從而可以通過使用channel變量DYNAMIC_FEATURES來使用它；
2. 定義一個DTMF序列來激活這個特性（我們建議至少使用兩個按鍵）；
3. 定義這個特性在哪個channel上起作用，以及（這是可選項）哪一方可以激活這個特性（默認是雙方都可以激活）；
4. 給出這個映射激活的應用程式的名字，以及相關參數；
5. 給這個特性分配一個呼叫保留音樂組（MOH,Music On Hold），這樣對端用戶就會在應用程式執行時聽到這個音樂。如果你沒有定義MOH組，對端用戶則聽不到任何聲音。

下面是觸發一個AGI腳本的應用程式映射的例子：

agi_test => *6,self/callee,AGI(agi-test.agi),default

由於通過應用程式映射執行的應用程式是在PBX核心程序之外的，所以你不能執行任何觸發dialplan的應用程式（例如Goto()，Macro()，Background()，等等）。如果你希望利用應用程式映射執行一些外部處理（包括執行dialplan代碼），你需要通過AGI()或System()應用程式來觸發外部應用程式。要特別指出的是，如果你希望利用應用程式映射做一些複雜的工作，你需要非常小心的測試，因為並不是所有事情都會像你期望的那樣執行。

為了使用一個應用程式映射，你必須在dialplan中通過在Dial()命令執行前設置DYNAMIC_FEATURES變量來聲明它。在變量名前使用雙下劃線是為了保證應用程式映射在呼叫生命周期內的兩個channels中都有效。舉例：

exten => 101,n,Set(__DYNAMIC_FEATURES=agi_test)

exten => 101,n,Dial(SIP/0000FFFF0002)

如果你需要在一個呼叫中允許多於一個的應用程式映射，你需要使用#做為多個映射名之間的分隔符：

Set(__DYNAMIC_FEATURES=agi_test#my_other_map)

使用#而不是簡單的使用逗號作為分隔符的原因是，老版本的Set()對於逗號的解釋與新近的版本不同，而應用程式映射的語法一直沒有升級。

不要忘記在修改了features.conf文件後重現加載features module：

*CLI> features reload

你可以通過CLI命令features show來確認你的修改是否生效。請確保你在將你設計的應用程式映射交付客戶前測試過它們！

繼承Channel變量

Channel變量總是與最初設置它們的channel關聯，並且一旦這個channel被呼轉則變量不再有效。

為了允許channel變量能夠跟隨這個channel在系統內呼轉，必須使用channel變量繼承。有兩種修飾符可以讓channel變量能夠跟隨channel:單下劃線和雙下劃線。

單下劃線使channel變量可以再一次呼轉中被繼承，而在其後的呼轉中將不再有效。如果你使用雙下劃線，channel變量將在這個channel的整個生命周期中被繼承。

設置channel變量繼承只需要簡單的在channel名前增加一個單下劃線或雙下劃線前綴。不過channel變量仍然採用不加前綴之前的方法來引用（例如，不要嘗試用帶下劃線的變量名來讀取變量的值）。

下面是設置單次呼轉繼承的channel變量的例子：

exten => example,1,Set(_MyVariable=thisValue)

下面是設置永久呼轉繼承的channel變量的例子：

exten => example,1,Set(__MyVariable=thisValue)

要讀取channel變量的值，不要使用下劃線：

exten => example,1,Verbose(1,Value of MyVariable is: ${MyVariable})

Application Map Grouping

如果你有許多features需要對特定的context或extension使用，你可以在application map grouping中把這樣幾個features組成一組。因此，當用DYNAMIC_FEATURES變量指定組名時相當於設置了組中所有的features到映射中。 這種application map groupings增加在features.conf的最後。每個組指定一個名字，其後跟隨相關的特性列表。

[shifteight]

unpauseMonitor => *1 ; custom key mapping

pauseMonitor => *2 ; custom key mapping

agi_test => ; no custom key mapping

如果你希望在application map grouping中為某個feature指定自定義的按鍵映射，簡單的在=>輸入你希望按鍵映射就可以。如果你沒有指定按鍵映射，則該特性就會使用默認的按鍵映射（在[featuremap]部分定義）。不管你是否指定自定義按鍵映射，=>操作符都是必須的。

在dialplan中，你可以用Set()來設置這個application map grouping：

Set(__DYNAMIC_FEATURES=shifteight)

; use the double underscore if you want to ensure

; both call legs have the variable assigned.

Parking Lots

Parking lot允許呼叫被保留在系統中而不與任何extension關聯。然後這個呼叫還可以被知道對應park code的任何人恢復。這個特性通常與吸頂式廣播系統一起使用。由於這個原因，它一般被稱為park-and-page。然而，需要注意的是實際上parking和paging功能是獨立的。

為了在Asterisk中park一個呼叫，你需要將呼叫呼轉到feature code指定的parking號碼，它通過features.conf文件中的parkext來配置，默認是700：

parkext => 700 ; What extension to dial to park (all parking lots)

你必須等待這個呼轉操作完成，直到你從系統得到一個parking恢復號碼，否則你將無法恢復這個呼叫。默認的呼轉恢復號碼，用features.conf中parkpos指定，編碼範圍是701-720：

parkext => 700 ; What extension to dial to park (all parking lots)

一旦呼叫被parked，任何人都可以通過撥打指定給這個呼叫的恢復號碼（parkpos）來恢復通話。然後這個呼叫就會被橋接到撥打了恢復號碼的channel。

有兩種常用方法來定義怎麼分配恢復號碼。這可以通過features.conf中的findslot來定義。默認的方法（findslot=>first）總是使用最小的空閒號碼。第二種方法（findslot=>next）循環使用恢復號碼並每次指定下一個，當最後一個恢復號碼使用後怎回到第一個恢復號碼。具體選擇哪種方法取決於你的parking系統有多忙。如果你很少使用parking，findslot的默認值first是最佳選擇（人們將會總是使用同一個恢復號碼）。如果你的parking系統很繁忙（例如，當用於一個汽車銷售店時），那麼每個後繼的parking呼叫採用下一個恢復號碼會更好，因為你經常會遇到同時有多個parking呼叫。用戶需要仔細聽用的是哪個恢復號碼（而不是總是701），而且有時會發生意外的恢復了錯誤的呼叫的情況。

如果你使用了parking功能，你大概還需要一個方法宣布這個parked呼叫，從而可以讓接聽人知道如何恢復這個呼叫。當然你也可以跑到大廳大喊「Bob，有你的電話在701線！」，更專業的做法是使用paging系統（更正式的名字是公共廣播系統）

吸頂式和「下巴底下式」 Paging （a.k.a. 公共廣播）

許多PBX系統中，都允許用戶通過電話把他的聲音發送到公共廣播系統中。這一般要求撥打一個feature code或者extension和公共廣播資源建立連接，然後通過電話機的手柄講話，就可以廣播到所有相連的公共廣播設備上。通常，這是一種包括一個連接吸頂式喇叭的放大器的外接廣播設備。然而，通過辦公電話的免提喇叭的廣播系統也非常流行（主要是出於成本原因）。如果你預算足夠（或者已經有了一個吸頂式廣播系統），吸頂式廣播系統一般來說要更好一些，但是基於辦公電話的廣播系統（a.k.a.「下巴底下式」廣播系統）在大多數環境也工作的很好。更常見的情況是混合的廣播系統，在這種方案中，舉例來說，基於辦公電話的廣播系統被用於辦公室環境，而基於吸頂式喇叭的廣播系統被用於倉庫，走廊，以及一些公共區域（食堂，接待處等）。 在Asterisk中，Page()應用程式用於廣播。這個應用程式簡單的用一組channels作為參數，同時呼叫每一個channels，然後，當它們應答後，將每一個都放入會議室。需要注意的是，很明顯，paging系統能工作的一個條件式每個目標channel都可以自動應答來電並能用某種方式把語音輸出到免提喇叭（換句話說，如果所有被叫電話只是振鈴的話，Page()無法工作）。

所以，雖然Page()應用程式本身的使用非常簡單，但讓所有的目標channel都正確的處理來電廣播卻要更麻煩一些。我們將簡要說明如下。

Page()應用程式有三個參數，分別是需要廣播的channel組，選項，以及超時時間：

exten => *724,1,Page(${ChannelsToPage},i,120)

選項給Page()的工作方式提供了一些靈活性，但是大部分這些配置都與目標設備如何處理來電連接有關。我們將在下面的部分研究配置設備接收廣播的不同方法。

由於Page()的工作方式，它是非常消耗資源的。我們怎麼強調這一點都不過分。仔細閱讀本書，我們將討論如何保證paging不會在一個產品環境中導致性能問題（如果沒有正確的設計，這幾乎是必然的）。

發送你的廣播

如我們之前所述，Page()本身是非常簡單的。竅門在於如何把它們組織到一起。廣播可以發送到不同類型的channels中，而且它們都需要不同的配置。

外部廣播系統

如果建築中已經安裝了公共廣播系統，通常的做法是連接電話系統到一個外部放大器並通過一個呼叫發送廣播到公共廣播系統中去。做到這一點的一種方法是在你的伺服器上安裝一個音效卡連接到外部放大器，然後把呼叫發送到名為Console/DSP的channel，但是這是假設你伺服器上的音效卡驅動工作正常並且正確的設置了音量。另一種，更簡單，也更可靠的連接外部廣播設備的方法是使用某種帶有FXS接口的設備（例如ATA），該設備被連接到諸如Bogen UTI1這樣的廣播設備接口上，這樣就連接到外部廣播放大器上了。 在你的dialplan中，向一個外部放大器發送廣播的操作就是簡單的Dial()到連接著廣播設備的設備上。舉例來說，如果你有一個ATA在sip.conf中配置為[PagingATA]，並且你將這個ATA連接到UTI1，你可以這樣來執行廣播：

exten => *724,1,Verbose(2,Paging to external amplifier) ; note the '*' in the

; extension is part of

; what you actually dial

same => n,Set(PageDevice=SIP/PagingATA)

same => n,Page(${PageDevice},i,120)

請注意為了這個系統能正常工作，你必須在sip.conf中將你的ATA作為一個SIP設備註冊，在這個例子中我們命名這個設備為[PagingATA]。你可以用任何你喜歡的名字命名這個設備（例如，通常我們用MAC地址作為SIP設備的名字），但是無論如何它不是一個用戶電話機，使用一個有別於其它設備的名字是有幫助的。

如果你在系統中使用了一張FXS板卡並連接到UNI1上，你可以Dial()到這個channel來代替FXS port：

same => n,Dial(DAHDI/25)

UTI1應答這個呼叫並且打開連接到廣播系統的channel；然後你就可以發表廣播了。

基於電話機的廣播系統

基於電話機的廣播系統第一次變得流行是在按鍵式電話系統中，在那裡辦公電話機的免提喇叭被用作窮人的公共廣播系統。大部分SIP電話機都具備免提自動接聽呼叫的能力，這就實現了基於電話機廣播系統的要求。除此而外，還需要同時把語音送往多餘一部電話機。Asterisk使用它內置的會議引擎處理這些內部細節。你可以通過使用Page()應用程式實現這一目的。 像Dial()一樣，Page()應用程式可以處理多個channels。由於你通常希望Page()一次給多個話機（或者全部的話機）發信號，你可能只能採用如下所示的冗長設備字符串：

Page(SIP/SET1&SIP/SET2&SIP/SET3&SIP/SET4&SIP/SET5&SIP/SET6&SIP/SET7&...

當超過一定規模後，你的Asterisk系統將無法向更多的話機發送廣播。例如，如果一個辦公室有200個電話機，利用SIP來廣播每一個設備是不可能的；你Asterisk伺服器的流量和CPU負荷會變得過重。在這種情況下，你應該考慮或者採用多播廣播或者外部廣播系統。

或許基於SIP的廣播系統的最棘手部分是這樣一件事，你必須告訴每一部話機它必須自動應答，但是不同的SIP話機製造商使用不同的SIP信息來實現這一點。所以，依賴於你所使用的電話型號，用於實現給予SIP話機的廣播命令也會不同。舉例如下：

• For Aastra:

exten => *724,1,Verbose(2,Paging to Aastra sets)

same => n,SIPAddHeader(Alert-Info: info=alert-autoanswer)

same => n,Set(PageDevice=SIP/00085D000000)

same => n,Page(${PageDevice},i)

• For Polycom:

exten => *724,1,Verbose(2,Paging to Polycom sets)

same => n,SIPAddHeader(Alert-Info: Ring Answer)

same => n,Set(PageDevice=SIP/0004F2000000)

same => n,Page(${PageDevice},i)

• For Snom:

exten => *724,1,Verbose(2,Paging to Snom sets)

same => n,Set(VXML_URL=intercom=true)

; replace 'domain.com' with the domain of your system

same => n,SIPAddHeader(Call-Info: sip:domain.com\;answer-after=0)

same => n,Set(PageDevice=SIP/000413000000)

same => n,Page(${PageDevice},i)

• For Cisco SPA (the former Linksys phones, not the 79XX series):

exten => *724,1,Verbose(2,Paging to Cisco SPA sets -- but not Cisco 79XX sets)

same => n,SIPAddHeader(Call-Info:\;answer-after=0) ; Cisco SPA phones

same => n,Set(PageDevice=SIP/0004F2000000)

same => n,Page(${PageDevice},i)

估計你已經發現，如果在你的環境中混合了不同的電話機，會發生什麼？你如何控制哪種信息頭髮送給哪種電話機？

無論你從哪方面考慮，這都不好實現。

幸運的是，許多SIP話機都支持IP組播，這是一種向多個話機發送廣播的好得多的辦法（請仔細閱讀）。然而，如果在你的系統中只有少量電話機並且都來自於同一個供應商，基於SIP的廣播將是最簡單的方法，所以我們並不想完全把你嚇跑。

通過MulticastRTP channel實現多播廣播

如果你認證對待通過話機實現廣播，並且你有超過100個話機，你需要考慮IP多播。IP多播的概念已經存在很長時間了，但它並沒有被廣泛應用。然而，它是在一個地點實現廣播系統的理想方法。

Asterisk有一個channel（chan_multicast_rtp）是設計用於創建RTP多播的。然後這個流會被不同的電話訂閱，結果是當聲音出現在多播流上時，電話機會將這個聲音通過免提喇叭播放出來。

因為MulticastRTP是一個channel驅動，所以它沒有獨立的應用程式。但是你可以在dialplan中任何可以使用channel的地方使用它。在我們的例子中，我們將使用Page()應用程式來初始化我們的多播。

為了使用多播channel，你只要像處理任何其它channel一樣簡單的發送呼叫給它就可以。語法如下：

MulticastRTP/<type>/<ip address:port>[/<linksys address:port>]

其中type可以是basic或linksys。當type是basic時的語法是：

exten => *723,1,Page(MulticastRTP/basic/239.0.0.1:1234)

並不是所有的設備都支持IP多播，但是我們已經在Snom，Linksys/Cisco，Avaya等設備上進行了測試，它們都能正常工作。

在Cisco SPA電話機上使用IP多播廣播

在Cisco SPA電話機上實現IP多播廣播特性的方法有些奇怪，但是一旦我們配置好，它也能很好的工作。竅門在於你在電話機上配置的多播地址並不是Page()中發送的地址，而更像一個信令channel。

我們發現的竅門是，你完全可以把這個地址當作多播地址一樣只用，但是要使用不同的IP埠號。

Dialplan看起來是這樣的：

exten => *724,1,Page(MulticastRTP/linksys/239.0.0.1:1234/239.0.0.1:6061)

在SPA電話機上，你需登錄到它的WEB管理界面的SIP頁面。在這一頁非常靠下的地方，你會找到一個名為Linksys Key System Parameters的部分。你需要配置下列參數：

• Linksys Key System: Yes

• Multicast Address: 239.0.0.1:6061

請注意你在這裡指定的多播地址是你在Asterisk的MulticastRTP channel中定義的第二個地址（在我們的例子中，這一個使用埠6061）。

請注意當你的環境中混合由SPA電話機（過去是Linksys，現在是Cisco）和其它型號的電話機時，你可以像這個例子中一樣書寫Page()命令。其它電話機將使用第一個地址，就像你在命令中用basic替代linksys一樣。

VoIP廣播適配器

最近，市場上出現了一種基於VoIP的廣播喇叭。這種設備在dialplan中的處理與連接到UTI1上的SIP ATA完全相同，但是它們可以被與吸頂式喇叭相同的方法安裝。由於它們是自動應答的，所以不需要像對於SIP話機那樣向它們發送額外的信息。

對於小型應用（可能只需要不到六個喇叭），這種設備可能是不划算的。然而，對任何更大的系統（或者安裝在複雜環境的系統，例如倉庫或停車場）來說，你將在遠低於通過模擬接口（FXS）連接到傳統電話系統的傳統模擬公共廣播系統的成本的情況下獲得更好的性能。

我們不知道這類設備是否支持多播。如果你計劃大量使用這種設備，請記住這一點。

組合廣播

在許多組織中，可能既需要基於話機的廣播系統也需要外部廣播系統。作為一個例子，一家工廠可能希望在辦公區使用基於話機的廣播系統，而在車間和倉庫使用吸頂式喇叭的廣播系統。從Asterisk的觀點看，這非常容易實現。當你調用Page()應用程式時，你可以簡單的指定你希望廣播的不同資源，並利用&字符分隔開，這樣它們就將都被包含在Page()應用程式創建的會議中。

混合在一起應用

這時候，你應該有了一張你希望廣播的不同channels的列表。由於Page()可以同時向多個channel發信號，我們建議首先定義一個包含所有channels列表的全局變量，然後再調用Page()應用程式：

[global]

MULTICAST=MulticastRTP/linksys/239.0.0.1:1234

;MULTICAST=MulticastRTP/linksys/239.0.0.1:1234/239.0.0.1:6061 ; if you have SPA

; (Linksys/Cisco)

; phones

BOGEN=SIP/ATAforPaging ; This assumes an ATA in your sip.conf file named

; [ATAforPaging]

;BOGEN=DAHDI/25 ; We could do this too, assuming we have an analog

; FXS card at DAHDI channel 25

PAGELIST=${MULTICAST}&${BOGEN} ; All of these variable names are arbitrary.

; Asterisk doesn't care what you call these strings

[page_context] ; You don't need a page context, so long as the extension you

; assign to paging is dialable by your sets

exten => *724,1,Page(${PAGELIST},i,120)

依賴於不同的硬體，這個例子提供了幾種可能配置。雖然並不嚴格要求必須定義PAGELIST變量，但我們發現定義該變量有助於簡化管理多種廣播資源，特別是在配置和測試階段。

我們為了這個例子創建了一個用於廣播的context。為了讓它工作，你或者用include將這個context包含到你的分機進入dialplan的context中，或者利用Goto()跳轉過來（例如，Goto(page_context,*724,1)）。另一個選擇是，你可以在每個需要用到廣播的context中寫死一個extension用於這個目的。

分區廣播

分區廣播在像汽車賣場這樣的地方非常流行，在這種地方，新車銷售部門和二手車銷售部門可能都需要用到廣播系統，但並不需要聽到其他部門的廣播信息。

在分區廣播應用中，當一個人發送廣播時需要選擇她希望向哪個區廣播。一般會採用類似PAM2000這樣的分區廣播控制器來允許發送喜好到不同的分區：Page()應用程式發送信號到分區控制器，分區控制器應答，然後一個額外的數字被發送來選擇廣播會發送到哪個區。大部分分區控制器允許向所有分區廣播，以及向部分分區廣播（例如，想新車及二手車銷售部門廣播）。

你也可以在dialplan中使用獨立的extensions來分隔ATAs（或者一組電話機），但是這麼做被證明比簡單購買一個分區控制器帶來更大的複雜性和更高的費用。分區控制器並不需要特別的不同技術，但是它需要有關dialplan和硬體的更多思考和計劃。

結論

在本章中，我們研究了features.conf文件，它包含了很多功能，包括使能基於DTMF的呼叫轉移，使能通話過程中的錄音，為一個或多個公司配置parking號碼。我們也學習了向辦公室廣播信息的不同方法，包括傳統的吸頂式廣播系統和利用辦公電話的多播廣播系統。研究這些利用現代方法實現傳統的parking和paging功能的方法有助於展示Asterisk可以提供的靈活性。

注釋：

注1.是的，我們了解SIP INFO消息事實上是SIP消息，從技術上說並不是語音通道的一部分。但需要指出的是，在呼叫中你不能通過你的SIP電話機上的「transder」或「park」按鍵來使用這些特性。你必須通過發送DTMF來使用這些特性。

注2.多讀兩遍，這是有意義的。

注3.我們希望你了解，實際的extension（分機）命名與parked這個呼叫的channel名相關，但不會真的是SIP_0004F2040808（除非Leif把他實驗室的Polycom電話賣給你了）。

注4.雖然也可以採用一些靈活的語法（你可以從示例文件中找到例子），但是我們的例子都是採用我們推薦的語法書寫的，因為它是最符合典型的dialplan語法的。

注5.Bogen UTI1接口是非常有用的，因為它可以處理各種各樣的輸入和輸出連接器，它幾乎能保證我們能毫不費力的將你的電話系統連接到任何外部廣播設備上，無論它有多老或多少見。

注6.在本書中，我們假設外部廣播設備已經安裝並且是與老式電話系統連接在一起的。

注7.提示：在這裡local channel將是你的朋友。

注8.IP多播有專用的D類地址，從224.0.0.0到239.255.255.255（但是請在使用多播地址前仔細研究IP多播）。部分多播地址是私有的，部分多播地址是公共的，以及部分多播地址是用來設計實現與你所希望的不同目的的。關於多播地址的更多信息，請參考http://en.wikipedia.org/wiki/IP_multicast#IP_multicast_addressing_assignments.

注9.非常大聲，並且無法調整增益。 注10.迄今為止，我們可以說Polycom設備不支持多播。我們確定無法找到辦法來實現。