當1999年第一次創(chuàng)建Asterisk的時候，當初的設計想法是針對獨立的Private Branch eXchange （PBX），它可以通過static.conf 文件來實現(xiàn)控制。呼叫控制是通過extensions.conf文件來實現(xiàn)，我們稱之為撥號規(guī)則。
撥號規(guī)則的腳本通知Asterisk來執(zhí)行呼叫流程中的應用程序。這種模式工作了很久時間。當然，隨著技術的不斷演進，現(xiàn)在的功能比以前更加靈活，同時也支持了更多的功能模塊。
這些撥號規(guī)則的很多應用是由C語言開發(fā)，它們可以直接和Asterisk進行通信交換。這些應用可以訪問通道，媒體，橋和endpoints和其他的對象，通過這些對象來實現(xiàn)電話通信。
關于 AMI 和 AGI
Asterisk項目創(chuàng)建不久， 兩個應用程序接口就已經支持了Asterisk：Asterisk Gateway Interface （AGI） 和 Asterisk Manager Interface （AMI）。這兩種接口是為了實現(xiàn)不同的目的：- AGI 和Apache中的CGI類似。AGI 提供了Asterisk撥號規(guī)則和外部程序通信的接口，它可以用來操作撥號規(guī)則中的通道。一般情況下，這個接口是同步的，從AGI程序中發(fā)起的對通道進行操作，流程完成后才能返回結果。
- AMI 則提供了一種在撥號規(guī)則中控制通道的機制。不像AGI，AMI 是異步的，是一種事件驅動的接口。大部分情況下，AMI 不負責控制通道執(zhí)行-它提供通道狀態(tài)信息，也提供在什么地方發(fā)起通道執(zhí)行。
兩個接口都非常強大，提供了多種集成度可能性。使用AGI的話，可以開啟遠端撥號規(guī)則的執(zhí)行，這樣就可以允許開發(fā)人員使用不同的程序語言PHP，Python，Java和其他的語言來集成Asterisk。使用AMI的話，可以顯示Asterisk狀態(tài)，發(fā)起的呼叫和被控制的通道地址。如果同時使用兩種接口的話，可以把Asterisk當成是一種引擎來開發(fā)其他的應用。
但是使用這兩個接口來開發(fā)自定義的通信應用程序時，這兩種接口仍然存在一些缺點：
- AGI 是同步的方式來工作的，當對通道進行處理時，它會阻塞線程服務的AGI。當開發(fā)人員創(chuàng)建一個新的通信程序時，用戶經常會需要獲得通道的響應（DTMF事件，通道狀態(tài)，等等）；所以AGI操作就會變得非常困難，如果配合AMI來進行操作的話，對開發(fā)人員是一個非常大的挑戰(zhàn)。
- 撥號規(guī)則可能是一個局限。無論是使用 AMI 或者 AGI，用戶的基本操作會限定在通道執(zhí)行中。如果需要更加強大的功能支持，很多基本的APIs接口功能都不能獲得很好的支持，例如這些APIs： bridges，endpoints，device state，message waiting indications，和通道中的實際媒體流處理。如果想通過AMI 和AGI來控制它們的話會變得非常困難，通常需要引入非常復雜的撥號規(guī)則控制流程來達到這些目的。
最后，兩種接口AMI和AGI都是Asterisk項目的早期接口，他們具有一定的生命周期。盡管這兩種接口非常強大，但是今天使用的技術中已不在是非常主要的手段。一些技術概念，例如SOAP， XML/JSON-RPC和REST也使用的不是非常多。因此需要一種原生態(tài)的，能夠快速適應新技術開發(fā)Asterisk的技術來支持最新的技術發(fā)展潮流。
在Asterisk 12之前，如果用戶需要開發(fā)一套自定義的通信程序的話，用戶需要：
- 使用C語言開發(fā)一個Asterisk模塊，或者
- 自己使用AGI或者AMI寫一個自定義的程序來實現(xiàn)，可能有時需要兩種接口同時使用來實現(xiàn)一個功能或使用一些小技巧修改撥號規(guī)則來實現(xiàn)這個功能。
ARI: 支持通信應用開發(fā)的接口
Asterisk RESTful Interface （ARI） 的出現(xiàn)就是為了解決用戶的這些擔心的。AMI的優(yōu)勢在于對呼叫的控制，AGI 的優(yōu)勢是通過外部程序來執(zhí)行撥號規(guī)則的應用程序，它們都不是為開發(fā)人員設計支持開發(fā)人員創(chuàng)建自己的通信應用程序。ARI是一種異步工作方式，可以支持開發(fā)人員通過訪問Asterisk中的原始對象實體來開發(fā)自己的通信應用程序，ARI可以通過REST接口訪問，例如channels，bridges，endpoints和 media等等原始數(shù)據。對象實體的控制則通過WebSocket來訪問JSON 事件來實現(xiàn)。
- ARI 不是通知通道執(zhí)行VoiceMail撥號規(guī)則的application或在撥號規(guī)則中轉發(fā)一個通道到VoiceMail。
- ARI可以支持用戶創(chuàng)建一個自己的VoiceMail 應用程序。
- ARI 基礎
- ARI 由3個部分組成。它們是：
- 一個 RESTful 接口支持終端來控制Asterisk的資源。
- 一個WebSocket，它在JSON中傳輸Asterisk資源到終端。
Stasis 撥號規(guī)則的應用模塊，它來處理從Asterisk通道到終端的控制。
通過以上3個部分的結合，開發(fā)人員就可以實現(xiàn)對Asterisk基礎資源的控制，實現(xiàn)自定義通信應用的開發(fā)。
什么是REST?
Representational State Transfer （REST） 是一種軟件架構，它具有以下幾個方面的特點：
- 通信方式是通過client-server 模式進行的。
- 通信是stateless的方式。服務器端不保存請求中的客戶端狀態(tài)。
- 連接分層，支持中間層實現(xiàn)路由和均衡負載。
- 非正式接口。請求中的資源和消息可以自己定義描述。
ARI 沒有嚴格限定在一個REST API。Asterisk作為一個獨立的應用，它同樣建議狀態(tài)信息，可以通過ARI修改。例如，SIP電話可能掛機，Asterisk就會對通道執(zhí)行掛機命令，盡管終端通過ARI沒有通知Asterisk對此SIP話機掛機。Asterisk以異步，state-ful 的工作方式工作：因此，ARI是RESTful。
什么是WebSocket?
WebSockets 是一種相對比較新的協(xié)議標準（RFC 6455），它可以支持客戶端和服務器端的雙向通信。此協(xié)議標準的主要目的是對基于瀏覽器的應用提供一種支持雙向通信機制，不依賴于HTTP長時間的服務器查詢或者其他非標準的機制。連接是用來傳遞從Asterisk到客戶端的異步事件。這些事件是和RESTful 接口相關，但是它在技術上是獨立的。Asterisk可以通知客戶端本身的狀態(tài)修改，在原來狀態(tài)下，因為客戶端混合使用了ARI。
什么是Stasis?
Stasis 是Asterisk撥號規(guī)則中的一個應用模塊。它的機制是Asterisk 使用這個應用模塊在撥號規(guī)則中實現(xiàn)通道控制。通常來說，ARI 應用程序在Stasis 撥號規(guī)則中控制通道和Asterisk的其他資源。不在Stasis 撥號規(guī)則中的通道不能被ARI來控制，總體來說，ARI的目的是用戶創(chuàng)建自己的撥號規(guī)則應用程序，不是來控制當前存在的程序。
進一步了解
這里多個頁面文檔介紹ARI和一些舉例。正常情況下，我們假設：
- 用戶已經注冊了一些SIP電話終端，可能使用chan_pjsip 或者 chan_sip。
- 用戶已經對Asterisk有一定的基本了解。
- 對Python，JavaScript或者其他的高級開發(fā)語言有一定的了解。
大部分的經歷不是直接創(chuàng)建HTTP REST 的結構，目前已經有很多開發(fā)包封裝了這些接口。
獲得有價值的技術分享：請訪問www.freesip.org 技術論壇，關注公眾號：asterisk-cn
