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点被配置，就会触发外部业务逻辑请求，挂起呼叫处理过程并等待外部业务指示。
