呼叫處理語言的構架與必要條件

1介紹

現在,一些協議已經被創建出來,來允許把電話通信轉變成IP網絡,尤其是SIP[1],和H.323[2].這些現存的標準協議,將電話服務的分配進行了廣闊并且成地區集中的分布,以便于使用者可以控制它們.

許多Internet電話服務可以,或者說應該在它們的終端設備上進行操作.比如說,會議通話,或者占線等待中的忙音,或者集中服務都是完全依靠終端系統的狀態,和細節流的具體內容,以及那些只有對終端系統有效的信息.多種多樣的服務,但是--有一些服務被用戶所在的地區限制,所以在終端系統忙是,就得呼叫分類操作,等等--是不依賴與某個特殊終端設備的,或者需要操作,即使是這個終端設備并不能夠信賴.這些服務還是在網絡上才能表現出它們的最佳狀態,而不是終端系統.

傳統上說,以網絡為基礎的服務只能被服務提供者創造出來.創造服務通常是依靠一些私人的,有限制的工具,所以終端用戶幾乎不能相其中添加什么東西.但是,在Internet環境中,這點就改變了.全球的連通和開放性的協議允許終端用戶或者第三方,來設計并操作新的或用戶化的服務,并且可以升級并修改這些服務.這期間并不需要一個協議提供者來扮演一個仲裁者的角色,他們可以自行完成.

大多數Internet應用程序都有這樣的用戶化的環境--就象環球網的CGI[3],和電子郵件的SIEVE[4],或者PROCMAIL.為了給Internet電話創造一個開放式用戶化的開發環境,我們需要一個安全并且標準的方法，以便這些新服務的創造者可以簡單的描述網絡服務器所希望完成的工作.

這篇文檔描述了一種構架,在這種構架下,網絡設備會對呼叫信號事件作出回應,也就是激活用戶所創造的程序,當然這些程序都是用上文所述的簡單,靜態,并且沒有歧異的語言寫成的,就象[5]中所描述的.大體上說,當這篇文檔提到"呼叫處理語言"時,它就意味著這樣一種語言,遵循這些規則;"thecallprocessinglanguage"或者"THECPL"就意味著這樣一種專業語言.

2術語

在這部分,我們會定義一些術語,以便下面使用.

STP[1]常用術語簡介:

invitation:原始請求方.SIP交換時的請求,是從發起呼叫一端到另一端

redirectserver:SIP設備的回應,當有invitation送來,或者以請求方式發送來的地址交換,SIP設備就會發送請求的對方以回應.

proxyserver:一個SIP設備,當它收到了invitation,或者其他形式的請求,并且將它們繼續向前傳給其他SIP設備時.它不久就會收到一個對它繼續前傳的回應,然后把它們發還給發送請求的一方.

useragent:創造并接收請求的SIP設備.同樣可以建立一個呼叫,或者可以影響一個呼叫.例如,電話,或者聲音郵件系統.

useragentclient:發送請求的useragent的端口.

useragentserver:回應請求的useragent的端口.

H.323[2]常用術語簡介:

terminal:一個可以發送,接收呼叫,以及它們之間媒體的H.323設備.

gatekeeper:網絡上的一個H.323終端,它可以提供地址交換,并且同時控制網絡的使用權,而控制對象就是H.323終端或者其他終端.它也可以為其他終端提供服務,比如查找網關或是帶寬管理.

gateway:可以從H.323網絡和其他網絡之間傳輸呼叫的設備,通常是公用帶寬的電話網.

RAS:連接在兩個H.323之間的注冊,認證和狀態信息,比如endpoint和gatekeeper之間.

本文中常用術語簡介:

userlocation:通過它,Internet電話設備可以確定使用了特殊地址的用戶的位置.

CPL:一種呼叫處理語言,一種簡單的語言,用來描述Internet電話是如何處理呼叫請求的.

script:一種CPL的特殊形式,描述服務所需的特殊集合.

endsystem:一個可以發出信息,或是終結信息的設備.它創造或者接收呼叫媒體(視覺,聽覺,以及其他等等).它可能是SIP用戶的代理或者是H.323的終端.

signallingserver:處理呼叫請求路由的設備.它并不處理或者影響呼叫媒體本身.它可能是SIP代理服務器,或者間接代理服務器,或者是一個H.323gatekeeper.

3關于服務的一些例子

為了激發更深的討論,在文章的這個部分,我們提供了幾個特殊的服務的例子,我們希望用戶可以自己來創建它們.首先要聲明的是,它們中的一些是故意安排的較復雜,并以次來證明決策的邏輯一定要應該合理.

@向前呼叫卻得到了忙或者沒有回答

當一個新的呼叫傳來時,呼叫就會在使用者的電話機響起鈴聲.如果電話機忙,呼叫就會改變道路,發送到用戶的聲音郵箱中.如果,不這樣,四聲響之后,還沒有回答,那它也應該轉入到聲音郵箱中,除非是從管理員那里發出來的,在這種情況下,它就應該代理轉到用戶的電話,如果他已經注冊了的話.

@信息地址

工廠做廣告,只是簡單的一個"信息"地址,留個那些預期的顧客.當有呼叫傳入他的地址,如果它正在工作,呼叫者就會被給予一個想接收那個"信息"的人員的名單.如果它并不在工作時間,呼叫者就會得到一個網頁,從中可以得知什么時候可以呼叫.

@智能用戶地址

當一個新的呼叫傳來時,用戶注冊的地址名單應該要考慮.然后根據呼叫的類型(業務,私人,等等),呼叫應該以一種已經注冊的地區的特定的子集響鈴,根據注冊的信息.如果用戶是從一種狀態開始,那么這種起始狀態應該被發送會呼叫會所.

@帶媒體信息的智能用戶地址

當一個新的呼叫傳來時,呼叫應該由代理轉給用戶所注冊的那個地址,從那里媒體性能可以在呼叫名單中很好的發揮出來.如果用戶在這種狀態下響了四聲還沒接,那么呼叫就會從代理服務轉向其他工作站,在那里,他或者她注冊過,進而減少匹配的狹窄.

@客戶端次序--"律師事務所"

當一個新的呼叫傳來時,被呼叫的地址就與相關的客戶端連接,并且與客戶端名字,地址,和呼叫時間都有關系.如果,相應的客戶端沒有找到,那么呼叫就會傳給律師事務所.

4用法簡介

CPL對于在不同情況下操作控制服務是有一定用處的.

@由enduser建立的script

在大多數直接創建CPL服務的方法中,一個enduser可以簡單的創建一個腳本來描述他們的服務.他或她只是來決定他或者她需要的是什么服務,然后用CPL腳本語言描述它,并把它傳給服務器.

@第三方的外部方案

由于CPL是一種標準化的語言,因此它可以允許第三方來創建或者定制服務,為了客戶端服務.這些腳本既可以在終端用戶所屬的服務器上執行,也可以在服務提供者上執行.

@管理員的服務定義

服務器的管理員同樣可以使用CPL,建立一些簡單的服務,或者可以他們所控制的服務器的方針.如果服務器正在執行CPL服務,那么就需要延伸服務構架,使得管理員可以象用戶一樣創建腳本.

@WEB中間設備

最后,這里為創建服務以及用web界面定制服務,提供幾條建議.下列環境中,CPL可以用后--尾(back--end):為了使用者的利益,一個網絡應用程序可以自行建立一個CPL腳本,然后電話服務就可以執行服務,而不需要理解其他相關的細節.

5CPL的構造

CPL腳本的創建其實還有很多方法.就象HTML有很多中構造方法一樣,我們可以為一個CPL腳本構想很多中構造方法.

@手動

實在是相當的簡單直接,CPL的腳本是可以由有一定知識的用戶手動編寫的.[5]中所描述的CPL,可以用文本方式以一種并不復雜的方式描述,因此手動編寫也是相當方便的.

@自動操作腳本

CPL的控制可以由自動操作的方法來創建,舉個例子,就象前面所描述的網絡中間件.用一個簡單的,以文本方式為語法的,標準的文本處理語言,就可以非常簡單的編輯CPL腳本.

@圖形用戶界面工具

最后,用戶可以使用圖形用戶界面工具來編輯CPL腳本.我們希望,如果CPL變的流行的話,大多數中等水平的用戶可以使用這種方法.事實上,CPL很快就會用這個工具來開發,以后,腳本語言強有力的表達能力就會簡單用圖形方法表現出來.

6網絡模型

呼叫處理語言是要在一個基礎上工作的,所謂的基礎就是要以一個標準的Internet電話網絡模型.盡管多種協議的細節會出現不同,但抽象的說,所有主要的Internet電話網絡構架都是十分相似的,它們的主要特點都相差不多.這篇文檔主要使用了SIP術語,因為它的經驗與協議的都一樣.

6.1模型組成

在呼叫處理語言的網絡模型中,Internet電話網絡包含兩個部分.

6.1.1終端系統

終端系統是一種設備,它可以產生或者接收信號信息和媒體.它包含簡單,復雜的電話設備,PC電話客戶端,自動語音系統.CPL抽象理解,不用理會這些設備的細節性能.一個終端系統可以發出一個呼叫,同時也可以接收,續傳或者舍棄一個呼叫.過程的細節(響鈴,多重接線,等等)對于CPL來說,并不重要.

出于對CPL的目的性,網關--舉例來說,一個設備可以連接IP電話網絡和PSTN--同樣可以認為是一個終端系統.其他設備,比如混合器,防火墻,并不直接由CPL控制,所以這里暫不討論.

6.1.2信號服務器

信號服務器是一種設備,它可以暫緩或者控制信號信息.在SIP中,它們是代理服務器,重寄服務器,或者是注冊器;在H.323中,它們就是網關.

在執行安裝信息時,信號服務器有三種事情要做.它們可以:

代理:向前將信息繼續傳遞給其他網絡,或者其他終端,或者可以將回復傳回.

重寄:將一個回復信息傳回給發送請求的那個服務器.

舍棄:通知正在發送的系統,安裝請求并沒有完成.

RFC[2543][1]有代理和重寄的詳細功能說明.終端系統有時也可以完成其他操作:完全拒絕與可能重寄.

信號服務器也可以正常的斷定用戶的位置.不管是用注冊方法(SIP注冊,或者H.323RAS信息),靜態構造,還是動態搜索,信號服務器一定要確定一種方法,通過這種方法,它可以確定用戶當前的具體位置,并以次來決定是代理,還是重寄.

6.2成分沖突

當終端設備處理一個呼叫,呼叫的實施請求可以處理多線稱,通過網絡的各個組成.開始時,起始的終端設備一定要先決定向那里發送請求.有兩種可能性:發起人可能由于某種配置,那么它所有的請求都會發送到一個單一的當地的服務器;或者也有可能改變目的地地址,查找遠方的信號服務器或者終端,以便找到向那里發送.

一旦請求到達信號服務器,服務器就會使用它當地的用戶的數據庫,它的當地的方針,DNS決議,或者其他方法,來決定向下一個發送服務器或者終端系統.一個請求可能會經過幾個信號服務器:從零開始(如果終端系統直接相連的化),按理來說,傳遞到其他信號服務器.另外,終端系統或者信號服務器(按理來說)都可以接收或者發送請求給其他任何一個.

例如,第一種情況(圖[1]),有兩條可供呼叫信息選擇的路徑,對于第一條路徑,呼叫發出者只知道一個用戶的地址,因為這個用戶正在試圖連接,并且它被配置成向外發送信息,通過本地的一個向外發送代理服務器.因此,它會把請求傳給當地的服務器,服務器可以通過地址,找到要發往的那個服務器,然后把請求傳過去.

如果是這樣,目的地用戶組織就可以使用多重配置來尋找用戶.社團服務器會識別這個用戶是那個部分的,然后把請求發給它所屬部分的服務器,而用戶就在當地服務器附近.(這與經常配置的電子郵件路由是相似的)對于這個請求的回復會按照原路返回.

但是,對于第二條路徑,呼叫發出者知道它正試圖連接的特殊設備的地址,并且它沒有設置成使用本地向外發送代理服務器.這種情況時,呼叫發出者就會直接連接目的地,而不通過任何服務器中轉.

那么,我們可以考慮一下,Internet電話信號服務器通常并不了解他們所"控制"的終端設備的狀態,因為信號信息可能只是把它當成中轉.由于結構學的局限性,造成了一些服務在執行時,會有很多限制.舉例來說,網絡系統并不可能確實的知道一個終端系統是忙還是閑;呼叫也可能根本不通過網絡直接傳遞.因此,信號信息一定要明白的傳遞給終端系統來判定它們的忙閑;比如終端系統會恢復一個忙的信號.


向外發送伙伴區域
代理服務器服務器
_______輸出代理連接______________
||伙伴服務器||||
||------------------------->||--------->||
|_____||_____||_____|
Route1^\尋找用戶
/\
發送給代/\
理服務器/_|
______________
||Route2||
||--------------------------------------------------->||
|_____|起始者直接連接目的地|_____|

起始端目的地
圖[1]:呼叫傳遞的可能路徑

7CPL與網絡模型的交互

7.1腳本的作用

CPL腳本是在信號服務器上運行的,控制方面:比如代理,重寄以及遺棄都是為了特殊的呼叫.它并不試圖改變或調整多重信號服務器的行為,或者象"GLOBALFUNCTIONALPLANE"只能網絡構架[6]中描述的那樣.

更多細節,腳本信號服務器的用戶坐標功能.就象6.1.2中描述的那樣,信號服務器通?？梢源_定用戶通常使用的本地的數據庫.CPL腳本取代了這種基本數據庫查找功能;它能夠提供注冊信息,呼叫請求的細節,以及它想查找的額外信息,并且還可以選擇那些信號動作來執行.

理論上,腳本可以看做是條件/動作對的列表;如果注冊,請求,額外信息的一些特征,與已知的條件相符,然后相應的動作(或者其他合適的動作集合)就會被執行.在這些環境中,以第一個動作和其他輔助動作為結果的附加動作會被執行.如果沒有條件符合請求,信號服務器的標準動作--當地的數據庫查找,舉例--會被執行.

7.2哪一個腳本在執行

CPL腳本通常是與特殊的Internet電話地址相連的.當一個呼叫確立的請求到達了CPL服務器時,那么那個服務器相連的資源,與目的地的地址,就是CPL腳本的數據庫請求中列出的;如果一個匹配,相應的腳本就會被執行.

一旦腳本被執行,如果它已經選擇要執行一個代理動作,一個新的Internet電話地址就會作為代理的目的地.一旦事情發生,那么服務器就會重新檢查腳本的數據庫,看看是否還有其他相關的地址;如果有,那么腳本就會被執行(聲明腳本不會嘗試去代理發送給一個服務器已經連接過的地址).如果想深入了解這個過程的細節,以及一個服務器運行腳本時到底做了些什么,也就是腳本起始地址與目的地地址的關系,請看9.2.

大體上說,在Internet電話網絡中,一個地址就意味著兩件事:用戶或者設備.用戶的地址涉及到特殊的個體;例如sip:joe@example.com,不管那個用戶現在在那里,或者他或她在使用什么樣的設備.設備地址,相比較而言,涉及到一個特殊的物理設備,例如:sip:x26063@phones.example.com.另外,中間(intermediate)的地址類型同樣是可行的,并且有一定的用途(比如一個地址"我的電話,不管它在那里,它已經注冊了.").但我們不希望它們頻繁使用.CPL腳本對于當前所連接的地址類型是不知道的;讓腳本與用戶地址相連是大多數服務器的工作,所以沒有理由讓腳本與其他形式的地址相連.遞歸的作用過程允許一個腳本與幾個用戶地址相連;因此,一個腳本可以執行一個動作"試著在我的電話上執行.",而一個設備腳本則可以說"如果我不在家,就不接聽電話."

對于一個CPL腳本而言,也可以不只與一個特殊的Internet電話地址相連,而是與整個信號服務器所有的地址相連,或者與更大的集合相連.例如,管理員可以配置一個防止呼叫的系統,或者列出一個禁止呼叫的地址清單;這就會對所有人都適用,但同時,用戶還是擁有他自己的常用腳本.準確的說,當這種腳本要在遞歸過程中執行時,它就要準確的按照管理員的腳本執行.9.2節有詳細論述.

7.3腳本在那里執行

用戶可以在任何一個網絡服務器上運行腳本,只要他們的呼叫確定請求可以通過,并且可以通過服務器建立互信的關系.舉例來說,就象圖[1]中描述的那樣,起始用戶在輸出代理上運行一個腳本,目的地用戶同時在伙伴服務器和部分服務器運行腳本.這些腳本通常是包含不同函數的,只是連接在它們所運行的服務器;在總服務器上運行的腳本可以用來定制用戶希望找到的那部分,這樣,不管腳本在哪個部分服務器,都可以使用.一些服務,比如過濾不想接收的呼叫,可以在任何的服務器上運行.詳情請看9.3節.

這個模型不只指定了用戶所在的網絡服務器.大體上說,這可以通過它們所在的當地的Internet電話服務器注冊它們自己;當然也可以通過外型指南,或者通過自動處理手段,就象本地服務協議[7].有人提議,上述服務器的自動處理手段應該包含一個區域,來判斷是否允許用戶升級他們的CPL.

8呼叫處理語言腳本的創建和傳輸

用戶創建呼叫語言處理腳本,通常是在終端設備上,然后通過網絡傳輸給信號服務器.腳本將堅持服務于信號服務器,知道被改變或者刪除,除非它被賦予一個有效時限;支持CPL腳本的網絡系統需要非常穩定的存儲.

終端設備,用戶以它為基礎創建腳本,不需要承擔任何到其他終端的連接,在那里呼叫被處理.例如,CPL腳本可能在PC上創建,但是,呼叫可能只設定為在電話上接收.事實上,以它為基礎創建腳本的設備并不一定是終端設備.詳情請看6.1.1;例如,用戶可以在一個獨立的終端上創建和升級一個CPL腳本.

CPL同樣不需要在網上的終端設備和信號服務器附近的設備才能創建.例如,用戶可以繼續向前傳遞他或她的呼叫,傳個更遠的地方.

具體的方法,通過它可以傳遞腳本去服務器,還需要確定;還有好多方法需要進一步解決.建議的方法,包括網絡文件升級,SIP注冊信息的有效載荷,遙遠方法的調用,SNMP,ACAP,LDAP,以及遙遠文件系統,比如NFS.

用戶可以得到當前腳本,不管是從網絡,還是終端設備,從而進行編輯.信號服務器可以報告錯誤,并且與用戶,腳本相連.靜態錯誤可能在升級時被檢測出來,運行的錯誤也可能發生.

用戶可以相信與多重信號服務器之間的友好關系(詳情請看7.3).用戶可以選擇升級任何一個服務器的腳本.這些腳本可能是完全獨立的.

9特征沖突(interactions)操作

特征沖突是一個術語,通常是在電話系統中使用的,尤其是當兩個或更多的請求特征發生沖突或是不明確時[8].特征沖突的重點:就是它在和呼叫處理腳本語言一起執行時,大致分成三類:同一個服務器上的特征--特征,同一個服務器上的腳本--腳本,服務器--服務器.

9.1特征--特征之間的沖突

由于前面幾章中討論的事情條件的清晰本質,特征--特征之間的沖突并不能算是一個問題,在呼叫處理語言環境中.然而,一個傳統的電話特征的捐獻者(subscriber),可能不會想到要同時準備對"呼叫等待"和"呼叫忙"服務,用戶創建的CPL腳本只對一個行為有反應"當線路忙時,呼叫到達".
為了有利于創建而提供一個好的用戶界面,或者提供一個CPL服務器可以在升級腳本時檢測沒有達到目的的代碼,反對的條件/動作對是可能被避免的.

9.2腳本--腳本之間的沖突

只有當一個服務器為一個呼叫提供多重腳本時,腳本--腳本之間的沖突才會出現,就象7.2中講的一樣.這可能在下列情況中發生:如果呼叫發出者和目的地在各自不同的服務器上,有不一樣的腳本;
當一個腳本向前傳遞一個請求時,那個地址有也有一個腳本;或者一個管理員級的腳本被認為是一個用戶的腳本.

對這種沖突的解決方法,就是要在正在執行的腳本中決定一個順序.在這個順序中,"第一個"腳本最先執行;如果腳本允許呼叫代理,腳本傳遞到的另一方地址,同樣會被執行.當"第一個"腳本向前傳遞請求時,這些在"第二個"腳本抵達的行為就會被認為是新的請求.當第二個腳本發送回復時,回復就會以相同的方式抵達第一腳本,就象呼叫抵達在網絡之外.注意:在一些情況中,向前傳遞可能會是遞歸的,CPL腳本一定要對向前(foreword)的循環特別小心.

理論上,這也可以看成是互不相連的服務器上執行各自的腳本.由于CPL腳本的構架設計成允許腳本在多重信號服務器上執行,在尋找用戶期間,概念上,我們可以把腳本--腳本之間的沖突轉變為服務器--服務器之間的沖突,就象下部分中講的那樣,應該盡量減少我們需要面對的沖突種類.

接下來,要解決的問題,就要將腳本正確的進行排序.為了處理這樣一種情況,當一個腳本向一個地址傳遞時,該地址同時有另外一個腳本,順序是明顯的;另外的一些情況就較為敏感了.當起始者和目的地同時有兩個腳本,起始者的腳本應該在目的地的腳本執行前執行;這就意味著起始者可以做地址傳輸,呼叫過濾,等等,在目的地地址和順序被確定之前.

更為復雜的情況是要確定管理員級的腳本.許多管理員級的腳本,比如,某些限制資源和目的地地址的管理員級腳本,需要在起始者之后執行,在目的地之前執行.這主要是為了防止用戶腳本越過管理員級腳本;但是,另外的情況中,比如全球的地址轉移功能,就需要或早或晚的執行.允許服務器級腳本運行的服務器就得要管理員來配置,尤其是當腳本執行過程中,特殊的管理員級腳本可能會失敗.

9.3服務器--服務器之間的沖突

第三種情況的特征交互性,服務器--服務器之間的沖突,是三種之間最復雜的.這種沖突中,規則的例子如下,就是起始呼叫和繼傳的沖突:用戶(或者是管理員)可能不想讓呼叫傳到某個特殊的地址,但是當地的腳本可能并沒有這項功能,它并不知道呼叫將傳往何處,合法的地址將被代理傳輸給較遠的服務器,同樣可以傳輸到一個被禁止的地址.這種類型的問題,即使在管理員級的網絡中也不能夠解決,就算是較低級別的網絡,就象現存的電話網中也不能夠解決.CPL還沒有聲明對它的解決方法,當然這個問題也并非只對CPL腳本產生效應,它對所有研發服務都有害.

服務器--服務器之間的沖突的另外一個類型,被下面的信號協議很好的解決了.因為它們可以升級,不管這個信號服務器是不是被呼叫處理語言或者其他方式控制.舉一個例子,就是向前的循環,假設某個地方,用戶X想把呼叫繼續向前傳給用戶Y,而Y又會把它傳回給X.SIP有一個機制,可以檢測這種續傳循環.因此,呼叫處理語言服務器根本不需要定義特殊的機制來防止這種情況的發生;但是,還是會引發不同形式的呼叫處理行為,在那里循環被發現,然后就發回一個錯誤信息給腳本的所有者,通過一些標準的錯誤回報機制.

9.4信號模糊

補充說明,[8]討論得出了電話網絡中的第四類型的特征沖突,信號模糊.這通常會發生在這樣一種時候,當若干個特征過載一個相同操作,在一個從終端出發的有限信號路徑,在一個網絡中:快速轉變(switch--hook)同時意味著兩樣東西.一個是"增加一個第三方",另外一個是"轉向呼叫等待".由于Internet電話協議的信號的外在特性,就象上面討論的那樣,這種情況應該不會發生.

10同現有語言的關系

這篇文檔將CPL描述成語言,并不是有意要暗示,一門新的語言就必須要用工具操作.服務器可以操作所有上述功能,就象是現存語言的圖書館或者是擴展;java以及其他各種腳本語言(TCL,PERL,PYTHON,GUILE).都是明顯的可能.

但是,創建一種新語言有很多動機.所有現存語言都是一樣的,自然的,完整的;但是有兩個天然的缺點.第一個缺點,任何功能的執行,都要花很長的一段時間,使用相當大的記憶庫,并且從不能間斷.對于呼叫處理,這種資源使用方法是不必要的,就象12.1的描述的那樣,實際上是不可信的.相關的模型,電子郵件過濾語言服務[4],有意與圖靈機區別.

相似的安全與保護級別(盡管不是自動的,也不能分析),同樣可以完成,但是要通過一個"沙盒子"(sandbox),就象java中的Javaapplets.在那里,對一切的要求都很嚴格,比如存儲容量,中央處理器的周期,堆?？臻g,等等,只要程序用的到的,都做了規定.這個方法的難點就在于,它從根本上的不透明和不夠方便:除非這些級別都嚴格按照標準,現在有個并不好的消息,就是程序占用的空間成摩爾數量級的增長,因此,用戶永遠都不能確定到底哪個程序可以在指定的服務器上執行,而不耗光系統資源,并且一個在某臺服務器上可以執行的程序,可能到了另一臺就不會象想象中的那么好用.不能完整表示的語言,換句話說,就是允許腳本作者與服務器之間有協定:在腳本符合語言規范的同時,服務器一定要保證能夠運行腳本.

第二個缺點,對于能完整表示的語言來說,它們能讓腳本自動,分析,但卻相當的麻煩.正如每一個分析工具都有自己的翻譯語言.因此,可以從文檔編寫世界里得到一個規律:如果文檔的組成語言象HTML或者XML一樣,并且可以被熟練的人員輕松編寫,強有力的文檔編程語言,象LaTeX或者Postscript通常是用不到的.當然,現在有字處理系統可以以LaTeX格式保存文檔,但決不能接受任意寫入的LaTeX文檔,不管原文檔的格式,構架.相比較而言,任何一個HTML編輯者都可以通過網絡來編寫HTML文檔,其中高質量的一些還可以在編輯其他文檔的同時保留它們的格式.

11相關工作

11.1在服務創建環境中

國際電信聯盟,對服務創建環境[8]作了抽象的描述.所描述的服務都是在傳統的交換電話網絡中進行的,就象一個非循環圖中的能夠涉及到的行為和決定.許多網絡服務的主顧,使用更改過的或是升級過的版本,為了它們所有者的服務創建環境.

11.2SIPCGI(詳解網關接口)

網關借口[9]是SIP服務器操作服務的接口.跟CPL不同,它是一個非常低級的接口.因此對于那些并不可信的用戶所寫的服務并不能合適的運行.

第十頁上講的"網絡電話服務編程"(ProgrammingInternetTelephonyServices)詳細的討論了SIPCGI與CPL的相似與不同之處.

12必要的語言特征

這部分列舉了呼叫處理語言的幾種工具,我們相信它們對于執行命令是必要的.并且與所描述的構架相符.

12.1語言特征

這里列舉了一些抽象的特性,是所有被提議的呼叫處理語言都應該具有的.

@體積小,效率高,易執行

為什么這點是必須的呢?作為對這個問題答案的補充,網絡服務器應該能夠處理體積巨大的呼叫,但我們不希望CPL的執行成為一個大瓶頸.達到這個目的的有效方法之一,就是在執行之前先編譯它.

@容易實現

對于一個在服務器上運行的腳本,不合理的構造就會導致用戶不能到達,或者使運行時期的錯誤顯示變的困難(盡管雙信道的機制可以緩解這個問題,就象電子郵件一樣).因此,它應該是易于檢驗的,當腳本連接到服務器,那么它在語句上至少是合法的,并且沒有明顯的循環和錯誤模式,同時也不會占用太多的系統資源.

@在安全模式下執行

CPL腳本所做的任何行為,都不會使服務器產生混淆,對于那個服務器來說,用戶是不可以訪問的,或者沒經過允許就影響其他用戶的狀態.作為補充說明,因為CPL腳本通常是在服務器上運行的,而用戶是不可以在那上面運行普通代碼的,因此,每一種語言以及它的運行環境都要經過精心設計,這樣腳本才不會占用太多的網絡資源,服務器的中央處理器的周期,存儲系統和記憶體.

@機器和人都可以輕松的編寫和分析

為了有最大的適應性,我們希望可以允許用戶自行編寫他們自己的腳本,或者通過定制來修改別人的腳本,使之成為自己的.但是,大多數用戶對于同一樣功能的函數都希望設立了相同的接口,然后有一個相關的程序可以專門為它創建腳本.這兩種建議都會很好的實現它:特殊情況中,對于腳本編輯器來說,分析人編寫的代碼和機器自動生成的代碼都很容易.

@擴展

想要給一種語言添加些特性并不難,但要保證一件事,那就是現存的腳本可以繼續工作,現存的服務器可以很容易的識別出那些他們不了解的特征,并且把事情通知給用戶.

@相互獨立的信號細節

只要腳本相同,就應該一樣可以使用,不管是按照什么協議指定的:SIP也好,H.323也好,普通的電話網絡,或者是其他一些建立呼叫的方法.腳本它同時也應該不清楚地址的格式.(在需要進行語言描述時,我們采用SIP的術語,但對于其他系統,它也一樣可以很簡單的,容易的使用.)對于把語言擴展成為其他形式的交流也一樣很有用,就象電子郵件和傳真.

12.2基本特征--呼叫信號

為了使自己有效利用,呼叫處理語言一定要能夠對呼叫信號事件產生反應,并且能夠創造信號事件.

@當呼叫到來時,可以操作動作

詳情請看[7],特別是[7.1]

@應該能夠依照事情的特點做決定

呼叫事件的許多特點都與腳本決定進程有關.下面的這些，只是為了強調它的重要性:

-目的地地址

我們希望能夠以目的地為基礎來安排路由.聲明:在SIP標準中,我們希望能夠過濾每一個地址,特別是在所需的URL中.

-起始地址

相似的,我們希望能夠以起始端為基礎安排路由.

-呼叫者的參數選擇

在SIP標準中,呼叫者可以表示關于將要抵達設備類型的參數選擇--詳情請看[11].腳本應該可以按照相關的信息做決定.

-關于呼叫者或呼叫的信息

SIP擁有原文區域,就象主題,團體,和優先級等等,以及一個可以確定地址的名字;用戶同樣可以添加一些不標準的標題.H.323有一個單獨的播放區域.腳本應該可以以參數為基礎做決定.

-多媒體描述

呼叫邀請可以詳細列出將要流動的媒體類型,它們帶寬的用法,它們的網絡目的地的地址,等等.腳本同樣可以以媒體特征為基礎做決定.

-證明/密碼術狀態

呼叫邀請應該是可以鑒別的.證明的許多道具都是相互關聯的:證明/密碼術的方法,執行證明的人,加密的特殊區域,等等.腳本會通過這些安全參數做決定.

@以呼叫邀請為基礎,采取行動

為了回復引入的呼叫建立請求,我們可以采取很多響應的辦法.我們可以:

-舍棄

我們要指出那個呼叫是不被允許的,或者是不能完成的.我們還可以發出更多的詳細的舍棄代碼,(包括,關于SIP,相關原文的字符串,警告代碼,以及信息的有效載荷).

-重寄

我們可以告訴呼叫創始人,試試另一條路.

-代理

我們可以把呼叫邀請發送給另一個坐標,或者其他一些地方("分叉"的請求),等候回答.當然,也可以詳細列出一個時間值,在那個值之后,我們將放棄接收回復信息.

@以回復代理或者分叉邀請為基礎,而做動作

一旦我們代理了一個邀請,我們就要按照我們接收到的請求做決定.我們應該這樣做:

-考慮信息區域

我們應該考慮相同的回復區域,就象我們考慮原始請求一樣.

-延遲呼叫起始者

如果回答是令人滿意的,它就應該發送回給發送者.

-對于一個叉路,選擇一個延遲回復的

如果我們將請求分叉,我們就是想得到幾個回復.這有幾點要注意:從中選擇回復,如果我們只接收到一個回復,但卻不是所有的,那就要等,但要注意要等多久.

-起始其它行為

如果我們接收不到回復,或者我們喜歡,我們就應該試試其它的.(例如,在忙是向前續傳)

12.3基本特征--無信號

呼叫處理語言有很多其他的特征,跟呼叫信號本質上是沒有關系的;但是,它們也是極其想要執行更多的有效的特征.

提供這些特征的服務器可能是在其他Internet設備中,或者就在服務器里(或者還有其他可能性).這些語言獨立與它們所在的服務器,起碼是在更高的級別上.

@搬運

作為CPL服務器自然移動事件的補充,用戶也就會希望可以移動其他物件.為移動信息所建的存儲庫可以在本地機,也可以在更遠的機器上.

@錯誤報告

如果一個未曾預料的錯誤發生了,腳本就一定要能夠向腳本所有者報告錯誤.這和腳本服務器用來向用戶報告錯誤的機制是相同的.(詳情請看12.5)

@對用戶本地信息的使用

代理服務器通常會收集用戶本地的信息,通過SIP注冊信息,H.323的全部信息,或者其他有些機制(詳情請看6.2).CPL是與這個信息相關的,因此呼叫可以向前續傳到注冊的地址,或者是它的子集.

@數據庫訪問

關于CPL控制的信息,被安排在額外的數據庫中.例如,更廣的地址數據庫,或者認可信息,在管理員控制下.語言列出了一些數據庫的訪問協議(如果SQL,LDAP),或者其他類別.

@其他的信息

腳本可以訪問的其他信息,包括網頁,尤其是在SIP信息中被發送回來的;或者一個清潔的接口可以施行函數調用,比如Corba,RMI,或者DCOM,例如可以訪問額外的帳單數據庫.但是,為了簡單,這些接口不一定在原始的版本協議中.

12.4語言特征

有一些特征,與CPL運行環境的操作一點關系都沒有,但對于一些標準服務的執行,卻是必要的.(下面的,并不完全):

@模式匹配

它應該可以為地址和文章的字符串提供特殊處理.這些字符串不只是完整的字符,還有部分匹配的字符.

@地址過濾

一旦用12.3中提到的方法,得到了一個地址集合,用戶就應該從它們之中選擇一些出來做為它們的子集.這就要以它們的地址與參數為基礎.

@隨機選擇

呼叫分類的一些形式是隨機的,就象它們結束的地方一樣.

@數據/時間信息

用戶可能希望以一些服務為條件(舉例來說,呼叫續傳,和呼叫分類),比如時間,日期等等.

12.5控制

就象第八部分中討論的,我們必須有一個體制,來發送和接收CPL腳本,以及相關的數據,向或者從一個信號服務器.這個方法一定要能夠支持將上載時間的錯誤報告給用戶;當然,我們同樣需要一些體制,當腳本執行時把錯誤報告給用戶.鑒定是最重要的,加密術是相當有效的.關于這種體制的詳情,可能是(應該就是),呼叫處理語言本身的一個詳細說明.

13安全考慮

關于CPL腳本的安全考慮就象[8]與[12.5]中討論的那樣.關于語言執行的考慮在[12.1]中進行了詳細的討論.

14感謝

我們很高興的感謝TomLaPorta和JonathanRosenberg對我們的支持,以及對文檔的注釋.

15作者地址

JonathanLennox
Dept.ofComputerScience
ColumbiaUniversity
1214AmsterdamAvenue,MC0401
NewYork,NY10027
USA

EMail:lennox@cs.columbia.edu

HenningSchulzrinne
Dept.ofComputerScience
ColumbiaUniversity
1214AmsterdamAvenue,MC0401
NewYork,NY10027
USA


EMail:schulzrinne@cs.columbia.edu

16參考書目


[1]Handley,M.,Schulzrinne,H.,Schooler,E.andJ.Rosenberg,
"SIP:SessionInitiationProtocol",RFC2543,March1999.

[2]InternationalTelecommunicationUnion,"Packetbasedmultimedia
communicationsystems,"RecommendationH.323,Telecommunication
StandardizationSectorofITU,Geneva,Switzerland,Feb.1998.

[3]K.CoarandD.Robinson,"TheWWWcommongatewayinterface
version1.1",WorkinProgress.

[4]T.Showalter,"Sieve:Amailfilteringlanguage",Workin
Progress.

[5]J.LennoxandH.Schulzrinne,"CPL:alanguageforusercontrol
ofinternettelephonyservices",WorkinProgress.

[6]InternationalTelecommunicationUnion,"Generalrecommendations
ontelephoneswitchingandsignaling--intelligentnetwork:
Introductiontointelligentnetworkcapabilityset1,"
RecommendationQ.1211,TelecommunicationStandardizationSector
ofITU,Geneva,Switzerland,Mar.1993.

[7]Guttman,E.,Perkins,C.,Veizades,J.andM.Day,"Service
LocationProtocol,Version2",RFC2608,June1999.

[8]E.J.Cameron,N.D.Griffeth,Y.-J.Lin,M.E.Nilson,W.K.
Schure,andH.Velthuijsen,"Afeatureinteractionbenchmarkfor
INandbeyond,"FeatureInteractionsinTelecommunications
Systems,IOSPress,pp.1-23,1994.

[9]J.Lennox,J.Rosenberg,andH.Schulzrinne,"Commongateway
interfaceforSIP",WorkinProgress.

[10]J.Rosenberg,J.Lennox,andH.Schulzrinne,"Programming
internettelephonyservices,"TechnicalReportCUCS-010-99,
ColumbiaUniversity,NewYork,NewYork,Mar.1999.

[11]H.SchulzrinneandJ.Rosenberg,"SIPcallerpreferencesand
calleecapabilities",WorkinProgress.

17版權說明

Copyright(C)TheInternetSociety(2000).AllRightsReserved.

Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseexplainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsuchcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurposeof
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.

Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuclearcase/" target="_blank" >ccessorsorassigns.

Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.