VoIP軟交換協議適配的目標是將不同的協議轉換成統一的BCSM到用戶的接入指示，以驅動BCSM按照其預定義的方式運轉，并實現與外部網絡設備之間的交互。簡單地說，就是將接收的不同信令消息解釋成呼叫模型可以識別的BCSM指示，并將呼叫模型發出的BC?SM指示轉換為相應的協議行為。不同協議的信令流程是有差別的，通過一定的映射關系，就可以轉換成統一的BCSM指示。但是，由千協議是多樣的，它們與標準BCSM指示之間的適配方式并不固定，如果適配模式設計不合理，就會導致呼叫處理操作與用戶設備實際執行動作之間的偏差，這就需要盡可能采用規范化的模式來處理不同協議與BCSM模型之間的適配規則。
協議適配的核心是消息映射以及過程匹配，因此可以認為協議適配需要實現兩方面的功能：靜態映射和動態交互。靜態映射主要是實現特定協議的消息／事件到BCSM指示／事件的映射，這種映射包括消息格式、消息名稱、消息參數的轉換等；動態交互則主要考慮如何使協議處理過程適應標準化的BCSM處理過程的需要，比如在呼叫掛起時，實現協議處理過程的暫停和恢復等，尤其是在需要接入外部業務的時候。概括地說，上述靜態映射和動態交互功能，就是以BCSM為基礎，對特定協議的語義和語法進行解釋的過程。
UniNet軟交換設備的設計中，協議適配功能也是以有限狀態機為基礎進行實現的，可以稱之為協議映射狀態機。首先通過狀態等價映射的方式找出協議消息與BCSM指示的對應方式（靜態匹配）；然后通過FSM疊加的方式實現兩者狀態遷移的聯動過程（動態匹配）。
-
協議映射狀態機設計
協議適配的核心就是映射狀態機的設計，協議映射狀態機設計的難點是對其狀態的設定。通常情況下，通信協議采用有限狀態機的方式對協議功能進行形式化描述，并實現對協議消息收發上下文的管理。在一定程度上，可以認為這個狀態機就是針對該協議的“基本呼叫狀態模型”。因此，在協議適配的實現機制中，可以在各協議已定義的協議狀態機的基礎上，首先實現它們與BCSM之間的狀態映射，這是進行消息映射的基礎。顯而易見，如果兩個狀態機在某個狀態上是等價的，那么它們的輸入事件和輸出事件都應該是等價的，因此只要找出協議狀態機與BCSM在狀態上的對應關系，就可以很容易給出協議消息與BCSM指令之間的對應關系。
在前文中已提到，UniNetBCSM是通過提取各協議呼叫處理流程的共性部分所形成的。在功能上，BCSM所代表的呼叫處理功能與各協議本身所具有的功能是不完全一致的。比如，H.323和SIP都具有處理多媒體呼叫的功能，但是在處理簡單語音呼叫時，只需要它們提供BCSM所要求的功能就可以，其他的功能可以認為是這個協議的特殊能力，只是暫時不需要。而且，不同的協議由于應用環境的不同，其協議的定義方式也各有特點。比如SIP協議主要是針對無傳輸保證的IP網設計的，在協議中設計了“三次握手”的機制。而在H.323以及IUSP協議中就沒有這種機制，所以在BCSM中也不會采用。因此，由于協議特點的不同以及協議本身處理能力的不同，在協議狀態機與BCSM狀態機對等映射過程中，經常出現的情況是兩個FSM(狀態模型）不具有同樣數目的狀態，或者說，在兩個狀態模型之間不存在完全等價關系。在這種情況下，就需要根據應用目標對映射方式進行補償。對千軟交換設備的設計而言，協議映射的最終目的是按照BCSM的要求進行呼叫處理，所以當存在不完全等價映射時，應以BCSM為基準進行補償。這就可能導致某協議狀態機中的多個狀態會被映射到BCSM中的單一狀態（即忽略VoIP軟交換協議處理中的某些特殊能力），或者反之，BCSM中的單一狀態被映射到協議狀態機中的多個狀態（即對協議處理進行一定的擴展，一般用千業務提供的需要）。下圖進一步解釋了FSM狀態映射的幾種表現方式。
呼叫模型狀態映射方式示意圖
在上圖中，以FSMA(基本呼叫狀態模型）為基準，FSMA與FSMB(協議狀態模型）之間的狀態映射有4種方式：
? 一對一，如Q到l;
? 一對多，如P到G、H;
? 多對一，如T、U到K;
? 多對多，如R、S到J和K。
在上述映射方式中，多個狀態之間的交叉映射（即出現多對多映射的情況）是我們所不希望出現的情況，因為它可能帶來二義性問題。比如在上圖中，FSMA中的狀態S被分別映射到FSMB的狀態J和狀態K,但是FSMB中的狀態J與FSMA中的狀態R也存在一個映射。這樣，在將FSMA中的狀態R到狀態S的遷移過程映射到FSMB時，存在二義性的解釋方式，FSMB將不存在唯一的遷移方式：它可能從狀態J遷移到狀態K,也可能繼續停留在狀態J上。
如果確實存在這種映射結果，并且不可避免，那么在映射過程中可以采取兩種補償方式：一種是協議狀態機(FSMB)保持不變，將基本呼叫狀態模型(FSMA)中的狀態S拆分成兩個子狀態Sl和S2來處理，并在這兩個狀態之間加入一個轉移，其中Sl對應FSMB中的狀態J'而S2對應K,如圖7.19(a)所示；另一種是保持基本呼叫狀態模型(FSMA)不變，將協議狀態機(FSMB)中的狀態J和狀態K合并成一個狀態來處理，并映射到FSMA中的狀態R和狀態s,如圖所示。
由此所得到的兩種簡化映射在語義上與初始的復雜映射是等價的。在協議映射狀態機的設計中，除非是通過這種狀態映射發現BCSM設計上存在的缺陷（比如某種重要的網絡操作方式在BCSM中沒有反映出來），而需要對BCSM的狀態做出調整外，一般情況下，還是采取修改協議狀態機的方式，使協議的處理向BCSM靠攏，即通過限制某些協議所具有的特殊能力，以保證BCSM的設計對千所有（或者絕大多數）協議都是適用的。
基于上述原理，可以在各種軟交換信令的協議狀態機基礎上，設計出與BCSM等價（這里所謂的等價是指從控制基本語音呼叫的角度實現的等價）的協議映射狀態機，它是維系協議接入與呼叫控制的紐帶，負責將收到的協議消息按照目前所處的呼叫狀態進行映射，轉換成相應的BCSM指示。這一過程可能是將一條協議消息分解成若干條BCSM接入指示序列，或者將多條協議消息序列組合成一條BCSM接入指示，甚至對某些協議消息序列進行屏蔽，完全由協議映射狀態機自行處理而不用上報基本呼叫狀態模型。盡管從協議處理的角度，這種映射有些“削足適履＂的含義，導致一些協議自身功能的缺失，也可能會引入對協議功能的局部擴充，但從呼叫控制過程來說，這種映射保證了呼叫控制功能的一致性（即保證了軟交換設備呼叫處理過程中每一步操作含義的一致性），并且實現了不同協議之間基千呼叫控制能力的等價性，這是為了實現多協議的統一接入不得不付出的代價。
需要說明的是，由千BCSM包含兩個有限狀態自動機：O_BCSM和T_BCSM,與此對應，每一種協議的適配器最終也要包括兩種協議映射狀態機，分別完成該協議消息與O_BCSM指示的適配以及與T_BCSM指示的適配。H.323協議映射狀態機的一個例子，如圖7.20所示。左側是發端側H.323協議映射狀態機，右側是終端側H.323協議映射狀態機，以及它們與BCSM在狀態上的對應方式。
-
協議適配的實現
從協議適配的角度，將一個協議體系結構中的事件一個接一個單獨地映射到另一個協議體系結構中的事件是不夠的。一般來說，應該將一個體系中的事件序列映射為另一體系中的事件序列，而且有時這樣的事件序列的時間跨度很大。不同協議的適配功能，不僅要完成消息的映射／轉換，還需要根據呼叫處理的進展對不同消息的發送和接收時序做出明確的規定，這實際上是一個動態的過程。另一方面，如前文所述，在呼叫控制功能中，為了提供業務的需要，通常需要進行DP點的處理以及呼叫的掛起、恢復等操作，這種特性是各種協議處理本身所沒有的，而且在協議映射過程中也難以體現出來，它們更多地涉及到的是一種過程化的操作，或者說涉及的是協議處理與呼叫處理過程的動態映射過程，稱之為狀態機的同步遷移過程。
在UniNet軟交換設備的設計中，協議適配器的實現采用了有限狀態機CFSM)疊加原理，將協議映射狀態機與呼叫狀態模型進行狀態遷移同步鎖定，并保證這一過程對千所有協議都是可用的。所謂有限狀態機疊加方式，就是指在呼叫的處理過程中，以BCSM為基礎，實現協議映射狀態機與BCSM在等價狀態上的同步遷移。換句話說，由BCSM的狀態遷移來同步驅動協議映射狀態機的遷移，在呼叫處理的任意特定時刻，保持兩者處于等價的狀態，從而使得協議行為與預定的呼叫控制行為保持一致性，也就是軟交換設備所要求的呼叫控制服務以及它所能觀察到的服務性質與特定協議內部機制所表現出的總體行為和性質是一致的。這種一致性包括兩方面：協議應該提供語音呼叫控制要求的服務；協議無需提供語音呼叫控制沒有要求的服務。此外，更重要的是使協議的處理過程滿足業務提供的需要，尤其是DP處理的需要。
綜上所述，如果要有效地實現呼叫控制和協議處理的一致操作，就必須保證當BCSM發生從一個狀態到另一個狀態的遷移時，協議映射狀態機也必須進行等價的遷移，反之亦然。例如，假設圖7.19(b)中，FSMA位千狀態Q(此時隱含FSMB位千狀態1)'現在FSMB收到一個事件，導致到狀態J的一個狀態遷移（假定這種遷移是合法的）。FSMB的這一狀態改變將導致FSMA遷移到狀態RC因為R對應千FSMB中狀態J的開始）。
當兩個被集成在一起的FSM中只有其中一個接收到一個外部事件時，事件的處理是很容易描述的。例如，圖7.19(h)中，如果FSMA在狀態P,FSMB在狀態H,假定一個事件EC記為)將導致協議映射狀態機(FSMB)從狀態H到I的一個遷移，則基本呼叫狀態模型(FSMA)將被驅動轉移到狀態Q。
但是這種情況并不總能夠被保證。在很多情況下，被集成的協議映射狀態機和BC?SM可能會同時收到多個事件，例如，如果FSMA在狀態P,FSMB在狀態H,并且FSMA收到業務事件e'W>和,而FSMB同時收到協議事件,當進行映射時，就必須詳細定義一些規則，以說明：
? 允許哪一個FSM首先處理事件；
? 這些事件可能以什么樣的順序被處理；
? 這些事件中的每一個是否允許以及允許什么樣的狀態遷移；
? 被同步的狀態機是否也能夠處理事件，它能夠處理什么樣的事件，以及按照什么樣的順序處理事件。
可以在不同種類的事件之間定義一個依賴關系，這些事件是每一個FSM在給定的當前狀態可以接收的，并在FSM之間建立起一個先后關系。當事件被異步接收時，就能夠擁有一個定義明確的、合理的遷移集合。但是也可能存在一些例外的情況，它們是在執行FSM疊加時需要明確給出的一些復雜性的指示。
一般而言，協議映射狀態機中的遷移可能是由于接收到外部實體發送的消息產生的?？紤]這樣的情況：兩個狀態機FSM_A和FSM_B被緊密地集成在一起。在FSM_B中狀態Nl和NZ映射到FSM_A中的狀態Ml和M2,并且在FSM_B中支持從Nl到NZ的一個轉移。假定在正常情況下，FSM_A中從狀態Ml到狀態M2的遷移是由接收到外部實體的消息引起的。
現在，當FSM_B首先發生一個從Nl到NZ的轉移時，為了保待狀態同步，FSM_A會被要求實現從Ml到M2的一個相應的轉移，即使沒有接收到正在等待中的消息。但是該消息可能包含了進一步的呼叫處理所需要的信息，而FSM_A現在還沒有，這樣就需要定義一些附加規則以決定是否允許這種情況發生。
另一方面，當一些基于FSM_A的狀態遷移標準達到時，作為FSM_A操作的一部分，如果從Ml到M2的轉移要求在遷移發生的同時必須發送一條消息到一些外部實體，那么也會存在同樣的問題。因此，如果在這兩個FSM被疊加以后，FSM_A進行這種狀態轉移是作為FSM_B狀態改變的一個結果時，就需要決定：
? 在FSM_A中是否有足夠的信息來生成它在正常（獨立）的操作條件下需要發送的消息；
? 并且給定當前的呼叫上下文，這樣的一條消息是否確實需要被發送。
需要注意的是，FSM疊加的最終目的是使協議狀態機的遷移行為按照BCSM預期的方式進行。因此，在模型集成中，如果協議狀態機呼叫模型狀態與BCSM狀態之間存在非等價關系或者在事件處理上存在沖突，則需要在映射過程中進行補償。一般情況下是保證BCSM的正常行為，而對協議狀態機的行為進行一定的限制。如何補償和限制，則需要在各種具體情況的基礎上仔細考慮和處理。
- H.323信令與呼叫模型的集成舉例
下圖描述了在一次完整的呼叫建立過程中，發端側和收端側在FSM疊加的情況下，BCSM和H.323協議映射狀態機之間的同步遷移關系。下圖中，H.323協議映射狀態機狀態與BCSM狀態之間的箭頭指向代表同步點，BCSM或者H.323呼叫控制狀態內的箭頭指向代表各自內部狀態遷移的方向。圖中連接協議映射狀態機以及BCSM的線條代表了一次完整的呼叫建立過程中，收端側和發端側呼叫模型所有主要狀態之間的同步遷移順序。
下面以發端側呼叫模型的集成為例，詳細說明H.323發端協議映射狀態機與O_BC?SM之間的同步遷移關系，以及在呼叫建立過程中，控制關系的轉移過程。首先，H.323發端協議映射狀態機處千"NULL"狀態，O_BCSM處千"O_NULL"狀態，表示呼叫尚未發起。當H.323發端協議映射狀態機接收到來自用戶終端的H.323消息"Setup"后，驅動狀態遷移到"CallInitiated",并將該消息轉換成O_BCSM可識別的BCSM接入指示，然后發送給O_BCSM中。O_BCSM首先分析H.323發端協議映射狀態機送上來的BCSM指示包含的信息，并發生一系列的狀態遷移，當這一分析過程結束后，O_BCSM遷移到PIC"Selecte_Route",同時向H.323協議映射狀態機發送BCSM指示，驅動后者的狀態遷移至"IncomingCallProcessing",在該狀態上，H.323發端協議映射狀態機將向主叫終端發送H.323消息"CallProceeding"。
隨后，O_BCSM繼續下一步處理，狀態遷移至PIC"SendCall",此時終端側T_BCSM被激活，O_BCSM則停留在"Send_Call"狀態，等待T_BCSM發送來的處理指示，此時H. 323發端協議映射狀態機也將繼續停留在"IncomingCallProcessing"狀態。當O_BCSM接收到T_BCSM側發送來的被叫振鈴事件后，狀態遷移至"O_Alerting"PIC,同時向H.323發端協議映射狀態機發送BCSM指示，帶動后者狀態遷移至"CallDelivered",并將BCSM指示轉換成H.323消息"Alerting",發送給主叫終端。
最后，當O_BCSM接收到T_BCSM側發送來的被叫摘機指示后，狀態遷移至"O_Active"PIC,同時向H.323發端協議映射狀態機發送BCSM指示，帶動后者遷移至"Active"狀態，并向主叫終端發送H.323消息"Connect"。至此完成主、被叫終端之間的呼叫建立過程。
在上述過程中，當BCSM中的PIC發生遷移時，如果相應的DP點被配置，就會觸發外部業務邏輯請求，掛起呼叫處理過程并等待外部業務指示。
