多媒體軟交換技術的探討

2019-11-03 10:23:58

字體：大中小

來源：轉載

供稿：網友

　　趙慧玲現任中國電信北京研究院副院長，信息產業部郵電科技委委員，國家網絡與交換標準研究組主席，國家ip與多媒體標準研究組副主席，國家863通信主題專家組成員，國家863‘中國高速信息示范網’技術總體組副組長。曾任信息產業部傳輸研究所副所長，99年被國家人事部授予中青年有突出貢獻專家的稱號。從事寬帶網技術標準和ISDN技術的標準和測試工作。曾有8部技術專著。

　　葉華中國電信北京研究院技術部網絡交換研究室主任，高級工程師。主要從事并負責軟交換、IP電話、電路交換等技術的研究，是我國“軟交換設備總體技術要求”行業標準的主要起草人。

　　導讀：本文主要概述了基于多媒體軟交換的體系架構、設備功能、開放接口以及應用面臨的問題。作為下一代網絡的重要技術特點和要求之一，是向第三方提供標準的開放的API接口，從而能由第三方開發業務并提供業務。PARLAY API就是一個重要的API，是目前最具有影響的一個API。本文重點介紹了PARLAY API的特性、體系結構以及提供的業務，最后提出了多媒體軟交換應用應研究的有關問題。一、引言

　　未來的通信業務都將會是多媒體業務，多媒體業務一般泛指語音、文本、圖象、視頻等業務或者這些業務的合成，多媒體業務種類繁多。與傳統話音業務的單一性要求不同，多媒體業務對通信系統提出了更高的要求，如對集成性、交互性、同步等特性的支持。

　　作為未來發展方向的軟交換系統，不但應支持語音業務的所有功能，而且具有多種媒體信息交換的控制功能，可以控制音頻、視頻、數據信息的實時交換和傳送。我國高科技863計劃開始列項有關軟交換系統在移動和多媒體應用的研究。

　　作為新興電信運營商，在沒有話音基礎設施的情況下，特別重視利用分組數據平臺提供綜合的解決方案，而傳統運營商為了增強競爭實力，更加重視提供增值業務和新業務的能力，所以人們越來越重視網絡提供多媒體業務（含話音業務）的能力。

　　為了達到在公眾電信網中提供實用的多媒體業務，就需要對問題認真地加以研究和解決，以實現真正意義上的融合網絡。本文將探討有關基于軟交換的多媒體技術相關問題。二、支持多媒體業務的軟交換系統總體框架結構

　　1、體系結構

　　如圖1，支持多媒體業務的NGN系統仍遵循開放的四層體系結構。

圖１基于軟交換的網絡體系架構示意圖

　　其中：

　　■ 接入層：支持多媒體業務和用戶的接入。

　　■ 傳送層：采用分組技術，提供一個綜合傳送平臺。

　　■ 控制層：是軟交換系統的控制核心。完成多媒體呼叫和業務的控制等功能。

　　■ 業務層：提供各種增值服務、多媒體業務和第三方業務。

　　2、相關設備

　　在整個支持多媒體業務的軟交換網絡體系中，除了核心的軟交換設備以外，還有許多與多媒體業務相關的網元設備，其功能分述如下：

　　1）軟交換。它是多種邏輯功能實體的集合，提供綜合業務的呼叫控制、連接以及部分業務功能，是下一代電信網中語音/數據/視頻業務呼叫、控制、業務提供的核心設備。軟交換設備與媒體服務器、各種媒體網關、終端、應用服務器以及其它軟交換設備間采用標準協議相互通信。

　　2）應用服務器。它負責各種增值業務和智能業務的邏輯產生和管理，并且還提供各種開放的API，為第三方業務的開發提供創作平臺。應用服務器是一個獨立的組件，與控制層的軟交換無關，從而實現了業務與呼叫控制的分離，有利于新業務的引入。

　　3）多點控制器(MC)。它主要完成會議電話及視頻會議的控制功能，對會議進行集中管理。它可以控制多點處理器與各終端進行語音、視頻、數據編解碼的能力協商，優先權設置等。

　　4）多點處理器(MP)。它主要負責多媒體會議的語音、視頻、數據的混合、切換和同步等功能。還具有語音編碼的轉換功能。

　　5）會議電視網關。負責接收和處理來自非數據用戶終端的信令和音頻、視頻等媒體流。可以處理一種或多種媒體流，經過相關處理后發送到相應的MP或用戶終端，用戶終端發送的信令消息映射成相應的消息經網關轉發給軟交換設備。

　　6）媒體網關。其主要功能是將一種網絡中的媒體轉換成另一種網絡所要求的媒體格式。它提供多種接入方式，如數據用戶接入、模擬用戶接入、ISDN接入、V5接入、中繼接入等。

　　7）媒體服務器。它提供專用媒體資源功能，例如語音通知、數字接收器等。同時為滿足電信新業務需求，還可以支持個性化動態語音編程、支持資源的動態加載和修改。

　　8）SIP/H.323智能終端設備。這些設備支持音頻、視頻、數據等功能。如：可視電話、會議終端、內置多媒體功能的PC、PDA等。三、多媒體業務要求

　　最基本的要求是要支持聲音、圖像、圖形、數據以及文本等方式信息的傳遞或交互。包括如下幾類（不限于所列業務）：

　　1、會話型業務。一般泛指人和人之間的信息傳遞或信息交互，包括點對點的可視電話業務、點對多點的視頻教育業務、多點對多點的會議電視業務等。這些業務需要傳遞視頻、聲音、圖形、數據以及文本中的一種媒體流或幾種媒體流的組合和交互處理。

　　2、分配型業務。泛指信息源對人群之間的信息傳遞，是一種點對多點的業務。不同于傳統的電視業務，它既可以是廣播型業務，也可以是點播型業務，如VOD。

　　3、檢索型業務。泛指個人對多信息源之間的信息檢索，用戶可以隨時從不同地點的多媒體數據庫中檢索到需要的多媒體信息，如文字信息、音頻信息、圖象或視頻信息。

　　4、消息轉發型業務。泛指人和人之間信息的轉發，可以是點對點、點對多點、多點對點。轉發的信息可以是文字、圖象、聲音和視頻信息，無對實時性要求，一般可以用存儲轉發。四、組網設備及功能

　　1、基于多媒體的軟交換功能

　　多媒體軟交換設備是各種多媒體業務邏輯的“控制中樞”，要具有對各種類型業務的控制、接續以及其他與業務邏輯完成有關的能力。要求支持如下功能。

　　■ 呼叫處理控制功能；

　　■ 接入協議適配功能；

　　■ 互聯互通功能；

　　■ SIP代理功能；

　　■ 路由、地址解析和認證功能；

　　■ H.248終端、SIP終端、H.323終端、MGCP終端的控制和管理功能；

　　2、MC的功能

　　MC可完成會議控制功能，支持多媒體會議，實現多方通信。能夠給申請發言的終端分配“令牌”，按照“令牌”持有者的指令來控制MP切換視頻信號。在通信過程中隨時增加或刪除通信參與方，而不中斷其它呼叫連接。

　　MC具有信息交換的控制功能。它可以通過H.248協議，控制MP完成對各路音頻、視頻、數據信息的實時交換和傳送；可以控制各種智能終端、音頻網關、視頻網關的實時信息交換。

　　MC的邏輯功能可以在軟交換設備中實現。

　　3、MP的功能

　　■ 語言處理功能

　　■ 視頻處理功能

　　■ 數據流處理功能

　　■ 媒體流同步功能

　　4、多媒體服務器功能

　　■ 播放錄音通知

　　■ DTMF數字接受功能

　　■ 語音識別功能

　　■ 文本至語音的轉換功能

　　■ 會議電話功能（可選）

　　■ 視頻會議功能（可選）五、PARLAY API

　　Parlay API的特點是能夠使得第三方用戶不用了解基礎網絡的具體技術和協議，只要知道基礎網絡能夠提供什么樣的能力并利用這些能力，就可以開發出多種多樣的業務。同時應用服務器通過一定的鑒權機制就可以利用基礎電信運營商的網絡來提供業務。Parlay API的版本較多，比較具有影響力的版本是2.1和3.0，Parlay標準化組織以后的版本只對版本3.0具有向后兼容性而對2.1版本沒有后相兼容性。

　　1、Parlay API概述

　　1998年4月，Parlay工作組成立，撰寫API說明，提供企業接入網絡信息和允許企業控制一定范圍網絡能力，這個API，仍在發展，被稱為Parlay API。

　　最初的版本于1998年12月出版，此時，Parlay 工作組由英國電信、Ulticom 、微軟、北電、西門子組成，1999年5月，6個成員加入，它們是 AT&T、Cegetel、Cisco、EriCSSon、IBM和Lucent，共11個成員，2000年1月API2.0出版，僅6個月后，2.1出版，2000年10月和2001年3月，2.1修訂版出版，沒有主要的改變，實際上，主要修改了以前版本的書寫錯誤。

　　從2000年4月，Parlay工作組鼓勵新成員加入，已經有相當的影響。在2001年2月，Parlay工作組成員列表有24個成員和13個新加入的成員。此時，版本為3.0。

　　Parlay工作組的目標是通過規范開放應用程序接口，聯合IT應用和通信應用的開發能力，促使通信應用數量的飛速發展。

　　2、Parlay API特性

　　Parlay APIs規范是開放的，獨立于技術的，它不局限于特定的編程語言和結構。規范本身是以與技術獨立的統一模型語言UML定義的。基于UML規范，Parlay工作組已經有兩個接口定義語言IDL文件集，一是Microsoft IDL，另一是CORBA IDL，描述了Parlay所有操作和消息。

　　既然API規范是開放和獨立于技術的，就能最大范圍的應用于電信市場，由網絡之外的第三方業務開發商、獨立軟件提供商，可以建立、測試和運行應用，去開發和提供高級電信服務。

　　Parlay API本身是抽象于網絡協議的。網絡運營商必須實現網絡中的Parlay網關，以使別人和自己能夠使用Parlay API。網關隨后將Parlay API調用翻譯成底層網絡理解的低級操作。對于應用開發商來說，Parlay API應用的優點是網絡間的便攜性。

　　Parlay工作組選擇了面向對象設計方法去實現這些目標。Parlay API可以通過分布式技術如COM或CORBA發布。

　　Parlay API的特性如下：

　　● API支持不同媒體類型的服務，不僅局限于電話。例如，Parlay能用于實現在幾個實體間的會議呼叫，將音頻和視頻或僅僅音頻提供給呼叫中的實體，這依賴于終端能力。

　　● API支持可管理性，如果網絡運營商準備發布API，API的可管理性是最基本的特性。Parlay API提供方法去提交服務級別協議(SLA)給客戶應用程序（即定義了最大可使用的資源）這必須被客戶應用程序數字簽名，通過這種方式，網絡運營商能夠判斷它想提供給第三方服務提供商資源的多少和當請求比允許的更多資源時采取正確的行動。Parlay API的最近版本也希望提供管理接口。

　　● API被設計為安全的。這是一個基本的特性。在API應用之前，服務提供商和網絡運營商必須確保各自域內的安全和完整。

　　● API支持服務的發現，發現是客戶應用程序在事先不知道服務地址的條件下，獲得Parlay網關所能提供服務的方法。

　　● API最重要的特性是對呼叫的控制，當入呼到達后，不是直接將其路由到實現所需服務的應用，去做進一步的處理。

　　3、 Parlay API在網絡中的位置

　　由圖2可見，ParlayAPI位于現有網絡之上，現有網絡的網絡單元通過Parlay網關與應用服務器進行交互，從而提供第三方業務或綜合的業務，Parlay網關與應用服務器之間的接口為Parlay API。Parlay網關于現有網絡的網絡單元之間的協議采用各個網絡的現有協議。

　　

　　

　　圖２　ＰＡＲＬＡＹ　ＡＰＩ示意圖

　

　　4、Parlay API體系結構

　　在Parlay API2.1中，三個實體起到重要的角色：客戶應用，Parlay框架，Parlay服務（我們把后兩者命名為Parlay網關）。如圖3所示，它是Parlay文檔中給出的體系結構的簡單概述。

　　

　　

　　　圖３　ＰＡＲＬＡＹ接口示意圖

　　Parlay API技術規范共定義了以下五種接口：

　　■ 客戶應用和框架間的接口（接口1）

　　■ 客戶應用和業務能力特性之間的接口（接口2）

　　■ 框架和業務能力特性之間的接口（接口3）

　　■ 框架和企業經營者之間的接口（接口4）

　　■ 框架和第三方業務提供商之間的接口（接口5）

　　Parlay框架和Parlay服務通過服務接口和框架接口暴露它們的行為給客戶應用。圖3對此也有描述。

　　服務接口提供給客戶應用接入一定范圍的網絡能力和與網絡相關的信息，而框架接口提供必要的支持能力使服務接口安全、可定位、可管理。例如，為了使用Parlay服務，客戶應用必須首先與框架認證自己然后發現合適的服務。框架也提供故障管理、負載管理和完整性管理。

　　(1)在Parlay API中，區分為以下四組服務接口：

　　■ 呼叫處理。呼叫處理服務接口包括呼叫控制和用戶交互以及終端能力和數據會話。這些接口允許呼叫的路由和計費（從普通電話呼叫到多媒體視頻會議呼叫）和用戶交互（播放信息給用戶，從用戶收集DTMF或語音輸入）以及獲得指定終端的能力。

　　■ 基本消息。這個服務接口考慮處理電子郵件和語音信息。包括當新郵件到達時的通知操作和發送接受消息。

　　■ 移動管理。由一組實現與移動相關應用的接口。它們有允許應用獲得固定用戶、移動用和IP電話用戶的地理位置和狀態的功能。也能在緊急呼叫中，用以自動接受地理位置信息。

　　■ 連通性管理。有一組能用以服務質量目的的接口，建立具有保證帶寬的連接。

　　(2)在ParlayAPI中，分為以下三類框架接口：

　　應用服務器與框架之間的接口、網絡業務能力服務器與框架之間的接口、企業經營者與框架之間的接口。

　　應用與框架之間接口的基本機制為：

　　■ 鑒權：在被允許使用任何OSA接口前，應用必須通過鑒權。

　　■ 授權：鑒權后，應用被授權接入確定的業務。

　　■ 框架和網絡業務能力特征的發現：鑒權成功后，應用可以獲得可用的框架接口并使用開發接口獲得被授權的網絡業務能力特征的信息。鑒權成功后，發現接口可以在任何時候使用。

　　■ 業務協議的建立：在任何應用與網絡業務能力特征與網絡業務能力特征交互之前，必須建立業務協議。業務協議包含離線部分和在線部分。應用在被使用接入任何網絡業務能力特征前需要簽訂在線部分的業務協議。

　　■ 接入網絡業務能力特征：框架通過指定的安全級、上下文、域等為應用的API方法提供批準接入業務能力特征或業務數據的接入控制能力。

　　框架與業務能力服務器之間的基本機制為：

　　■ 網絡業務能力特征的注冊：由業務能力服務器提供的SCFs可以在框架上注冊。

　　框架與企業經營者之間接口的基本機制為：

　　■ 業務訂購功能：此功能代表企業經營者和框架之間的合同。在訂購商業模型之中，企業經營者代表業務的訂購者，客戶應用代表業務使用者，框架代表業務的銷售者。

　　5、Parlay API提供的業務

　　通過Parlay提供的第三方業務主要分為以下幾類：

　　■ 通信類業務：如點擊撥號、VOIP、點擊傳真、可視電話、會議電話等，以及與位置相關的緊急呼叫業務、路邊助手業務等。

　　■ 消息類業務：如統一消息、短消息、語音信箱、E-Mail、多媒體消息、聊天等。

　　■ 信息類服務：如新聞、體育、旅游、金融、天氣、黃頁、票務等各種信息的查詢、訂制、通知等，以及基于未知的人員跟蹤、找朋友等。

　　■ 支付類業務：如電子商務、移動銀行、網上支付、即時售訂票、收費瀏覽等。

　　■ 娛樂類業務：如游戲、博彩、謎語、教育、廣告等。

　　各類業務可以相對獨立，也可以有機結合，例如可以在查詢信息時根據相應的信息進行支付類業務，再如各種娛樂可以通過不同的消息方式來表現（短消息、Email），將娛樂與消息業務相結合。六、基于多媒體軟交換應研究的問題

　　1、應研究網絡組網的方式，傳統電信網經過長期的運營積累，在網絡組織方面已經具有相當成熟的經驗；而基于軟交換的網絡組織目前國內外尚無成熟的經驗，是采用基于軟交換的全平面結構，還是分區域選路結構等在技術和實踐方面都有待進一步的探索。由于缺乏大范圍的運行網絡，因而對軟交換系統的性能測試只能夠在小型組網中進行，這與大型組網的實際情況有較大的差距，因而如何在實驗型網絡中，真實的作出軟交換系統的性能測試還需要進一步研究。

　　2、應開展協議兼容性的研究，軟交換體系結構基本協議框架已經清晰，基本上分為如下四類協議以提供不同接入設備的需要以及設備間互通的需要：

　　1）媒體控制協議：H.248/MGCP、SIP。

　　2）信令控制協議：ISUP/TCAP/SCCP over IP，主要是指Sigtran中所包含的信令適配協議、信令傳輸協議；如M3UA、SCTP等。

　　3）互通協議：BICC/SIP、BCP-T、H.323。

　　4）應用支持協議：Parlay、RADIUS、COPS。

　　然而上述協議尚未做到兼容性，標準還在發展之中；不同廠家的軟交換在技術標準的選用及協議的兼容性方面還難以做到相互兼容。BICC協議、SIP-T協議和H.248協議也在發展之中，協議的選項需要運營商根據業務的需要來進一步確定。由于協議的不成熟，這給我們在制定測試標準時帶來了一定的困難，特別是在互通性測試方法存在很大問題。

　　3、實現了一定數量的多媒體業務，但業務流程還處于發展之中，非常不成熟；并且這些業務還不十分明朗，作為測試項是否具有典型性還值得進一步推敲。API沒有成熟的產品：基于開放的業務平臺，采用標準的API接口為網絡運營商提供新業務開創了未來美好的前景，但是相應的產品仍在探索和研發之中。因而對API的測試需要進一步深入的研究。

　　4、基于SIP的網絡剛剛起步。SIP已被業界認為是最有希望取代H.323的終端控制協議，基于SIP的網絡也已形成了一套比較完整的體系結構，但其建設和發展在國際上剛剛開始，國內則幾乎是空白，暫時還無法發揮其應有的作用。

　　5、多媒體終端研究有新的進展。最近ITU-T SG16會議上提出的MoIP技術提案，標志著在包交換網上傳送Modem數據信號研究已經啟動。主要應用目標是解決Modem調制數據遠程接入的問題，關鍵是要保證Modem數據傳送的端到端服務質量。

　　6、多媒體軟交換系統的實現方式各不相同，有些采用將多媒體業務直接在軟交換內實現，有些則通過上層的應用服務器實現，支持的業務主要以語音與數據相結合的業務，如電子白板，同步瀏覽以及視頻會議等。

　　7、應開展基于多媒體的軟交換網絡與其他網絡互通性的研究，包括如何跨網提供話音、數據和視頻業務。

----《中國通信》