论文部分内容阅读
摘 要：本文通过基于B2BUA下的SIP服务器呼叫处理机制的抽象分析和归纳总结，提出SIP呼叫处理的六层模型，并深入探讨了基于六层模型的呼叫处理的设计模式，推动SIP协议的实际应用与实践推广。
关键词：SIP；B2BUA；六层模型；模式设计
中图分类号：TP393.05
当今，SIP的诸多业务，例如IP电话技术、即时通讯技术、SIP消息短信技术、IP PBX交换机、多媒体会议等都已经在众多的电信运营商、ITSP（IP 电话服务商）和CLEC（竞争本地运营商）的商业运营网络中得到了广泛应用。
SIP协议理论虽已广为人知，但在实践的应用还存在较大成长空间，将SIP协议成功的转换为软交换应用软件，还需要在遵循SIP协议基本原则的基础上，设计出其体系架构。因此，本文重点描述基于B2BUA模式抽象出来的SIP 服务器设计模式，通过体系及流程的分析，将通过实践证明其稳定性和可行性的设计模式方案与大家分享，指导SIP实践应用。
1 B2BUA模式
SIP（Session Initiation Protocol，会话发起协议）是由IETF制定的基于英特网多媒体业务应用的一系列重要协议之一。SIP协议建立在简单邮件传送协议SMTP和超文本传送协议HTTP基础之上，用来描述一个或多个参与者创建、修改和终止会话的应用层控制（信令）协议。
SIP 会话定义了四个主要逻辑组件：用户代理、注册服务器、代理服务器和重定向服务器。这些组件间通过传输承载了 SDP 协议的SIP消息来完成一个基本会话。根据协议描述，进行呼叫处理的逻辑组件是代理服务器，其通过简单控制SIP消息来控制UAC和UAS之间通话的建立和终止，不对UAC和UAS的通话进行控制和干预。若按SIP协议实现代理服务器的话，实现业务流程和用户计费将极为困难，因此，商业化系统的呼叫处理必须采用B2BUA的模式，B2BUA实质UAC和UAS两个逻辑实体的集合，其中一端使用UAS连接主叫，另外一端使用UAS连接被叫，两者通过呼叫控制的逻辑组件进行连接。通过呼叫控制组件，B2BUA服务器能够在内部建立通信链路，因而成为了SIP协议实际应用过程中被普遍采用的设计模式。
2 SIP系统架构
我们需要了解下SIP系统的设计思路，SIP系统的设计，除遵循SIP协议和B2BUA模式，还要参照通信的业务需求。因此，系统设计为5大功能和2大数据功能子系统，除常规SIP服务器所需的注册、呼叫处理功能外，还加入了计费、冷热备份及负载均衡。
离线数据模块：离线数据的设计对象是数据库，离线数据就是将实际运营所需要的用户数据（号码计划、终端类型、业务配置等）及用户状态（信道状态、呼叫记录、业务状态、呼叫类型、计费信息等）储存于数据库中。存储的设计必须考虑到系统的兼容性、移植性，独立性等特征，例如：需要支持支持多平臺下的各种数据库，需要支持数据库与SIP 应用系统分离。
在线数据模块：在线数据的设计对象是物理内存，用户在呼叫过程中需要频繁的访问用户数据，如果将大量数据存放在数据库中，会造成呼叫处理模块对数据库的频繁调度，数据库访问和内存访问的速度差异，将会成为系统性能瓶颈。为了保证呼叫的高速处理，设计上必须在系统启动后，将离线数据镜像映射到内存，再封装到不同的数据对象中，呼叫处理模块通过访问数据对象来实现对在线数据的调用管理和离线数据的实施更新。
呼叫处理模块：呼叫处理模块，整个SIP Server服务器的核心构件，其主要任务是完成呼叫过程的所有用户事务处理，并对处于通话过程进行管理和控制，这在后续的呼叫处理的设计模式的探讨中将进一步详述。
注册模块：终端注册处理模块，提供终端用户的在线注册、注销管理、用户鉴权管理。
备份冗余模块：针对主动系统进行监控，并实时进行数据备份，当主动系运行出现故障时，备用系需要及时监控出主动系统的障碍并切换（热备份）或者启动（冷备份），以保障用户的通话畅通。
计费模块：根据呼叫处理记录的用户的呼叫信息以及用户属性、业务类型等信息参照计费标准进行话费核算
负载均衡模块：通过集群服务器监控所有的SIP Server，协调服务器的通话负荷，当服务器的负荷到达服务器的处理极限时，将部分用户呼叫分流到呼叫负荷较低的服务器上，既保证了服务器的稳定性，又提高了服务器的利用率。
本文的重点是基于B2BUA的SIP呼叫处理模式，接下我们将深入探讨呼叫处理核心子系统的设计与实现。
3 呼叫处理模式设计
呼叫处理模块是整个SIP服务器的系统核心，模式设计的核心工作就是抽象，因此，借鉴网络设计的7层OSI模型，我在此将SIP 服务器的呼叫处理过程设计为六个层次：协议栈层、协议层、接续层、连接层、控制层、业务层。分成设计的目标是为了将协议、消息、事务、控制、业务进行分离，以便有效的管理呼叫处理的整个过程，整个呼叫处理就依照着这六层模型的定位展开其具体的分层模式和流程设计的介绍。
3.1 SIP六层模式设计
协议栈设计：设计目的是为采用不同信令协议的终端加载不同类型的协议栈。
主要提供各种终端连接所需的协议库的自动识别与调用，为了提高系统接入不同设备的兼容性，协议层支持调用不同类型的协议栈，如SIP，H323。
SIP协议栈由静态库和动态库构成，支撑开源或定制的标准协议栈，能够为协议层提供RFC3261和RFC3265中所定义的所有SIP协议基本消息的构造。
协议层设计：设计目的是根据不同协议，建立和终端机协议相匹配的对象，并实现基于消息体层面的消息接收与发送。
协议层对象SIP Stack Cntl主要是接受来自终端或者UA的消息，并根据消息，生成终端管理对象，选择消息分发的对象（对内或对外）。 协议层具有较强的协议相关性，支持不同协议的终端的消息总是有与之对应的协议层对象接受并转发给接续层。
接续层：设计主要考虑的是终端的接续，并对终端对象进行状态控制及超时控制
Partial Call对象，针对呼叫用户信息（即SIP消息中的FROM Head中的用户号码）生成的唯一对应的对象，每个对象通过调用用户状态数据表Line Status Man以及超时计时器Timer来控制呼叫过程的用户状态以及呼叫超时。
接续层具有弱协议相关性，系统会根据不同的协议设计连接管理对象Partial Call，例如SIP协议层会选择SIP Partical Call进行SIP消息的处理，而H323协议层会选择H323PartialCall对象来进行H323消息的处理。
连接层：为了实现不同协议终端的连接，导致接续层设计也需要考虑协议的差异性。而连接层的设计目标，就是实现协议无关性，连接层的主要作用就是连接不同的协议对象，将协议消息翻译成为协议无关的内部呼叫控制信令，保证控制层对下层对象的控制的同时，实现不同协议之间的连通性。
每个Connect对象都应当和相同协议的接续层对象Partial Call相对应，例如：SIP Partial Call对象就应当生成SIP Connect Cntl对象与之对应，H323PartialCall就应当和H323ConnectCntl对象对应。
控制层：控制层主要为SIP基础呼叫事务的处理以及基础场景（连接、呼叫、断开）的控制，并实现呼叫状态的控制、记录、以及变更。
控制层根据每一个呼叫场景建立自己独立的Call Control对象，对象下挂接有该通话所属的所有SIP Connect Cntl，并对其呼叫状态进行控制管理。
由于一些呼叫并不只限于两方，比如会议，转移、等待业务等，这时候，就需要控制层能够接收业务层的调用，通过对SIP基础呼叫场景以及基础事务的重组，实现多个Connect Cntl對象的互连互通。
业务层：每一个呼叫业务的处理核心，设计目的是通过Call Flow和Scenario对象实现呼叫处理和场景变化。
Call Flow对象是呼叫处理的核心对象，主要工作是接受来自Connect Cntl对象的协议无关的消息，并根据业务类型创建不同的场景对象（scenario）进行对应的处理。一次呼叫过程有且只能有一个Call Flow来唯一分配处理该次呼叫中的任何消息。
Scenario对象针对业务设计的，提供业务执行所需要的消息状态机，实现业务消息的处理和流程的扭转。（1）不同的业务有着自己不同的消息流程，因此Scenario要根据业务的消息流程创建一个独立的消息状态机，该状态机能自行处理消息流程中的各种正常和异常消息。因此，场景对象Scenario就能通过Call Flow使用独立的消息状态机来灵活控制业务流程。（2）Scenario对象能够通过解析用户消息所携带的业务信息，来判定需要向用户提供的业务，并在不同的场景对象之间进行切换，保证用户希望的业务能够被顺利执行。（3）即存的基于No.7信令的传统电话业务流程，都可将呼叫信令转化为SIP消息时序图，并设计为对应该业务场景的消息状态机，来实现传统话机业务向SIP呼叫业务的转移。
3.2 呼叫处理流程设计
上节描述了六层SIP呼叫处理的设计模式，接下来将基于该呼叫处理模式给出基于该系统架构的SIP简单呼叫过程的处理流程：（1）SIP Stack Cntl收到来自终端的请求消息（INVITE），调用SIP协议栈解析消息的合法性，并根据消息的FROM Head中的终端信息，从SIP Partial Call的对象管理表中创建或选择匹配对象，并将该解析完成的消息做成消息镜像送到该SIP Partial Call。（2）SIP Partial Call在收到SIP Stack Cntl的消息之后，将根据消息中的TO Head，访问Dec Device（在线局数据，用户号码信息），对用户号码进行解析。如果用户号码存在，则通过链路状态管理表Line Status Man获取对应号码的链路状态。如果该号码链路状态为空，则创建Call Flow呼叫流程管理对象，并将消息发送给Call Flow。如果线路状态为忙，则Partial Call直接返回408 Busy Reject给终端，并结束SIP Partial Call对象以结束通话。（3）Call Flow在收到消息之后，根据消息类型，创建所需业务场景对象Scenario，通过场景消息状态机着手处理呼叫流程（例如：发送100Trying消息给呼叫端，状态跃迁至180 waiting态）。（4）Scenario对象创建并关联呼叫控制对象Call Control，并将Call Flow对象与Call Control对象，以及主、被叫的连接对象SIP Connect Cntl关联。（5）Scenario会根据被叫信息访问SIP Partial Call的对象管理表，若被叫对象已存在，就不再创建新对象，仅将两对象关联。若被叫还没创建对象，该场景对象 Sceanrio会根据解析出来的号码信息创建被叫的SIP Partail Call，并同时关联到SIP Connect Cntl和Call Flow，保证回程消息能够正确的送到Call Flow。（6）消息经由Call Flow送到被叫SIPConnect Cntl对象并转译成SIP协议消息需求送至被叫SIP Partail Call对象。被叫SIP Partail Call对象在收到消息发送指令后，由SIP Stack Cntl将消息按照指令需求重构后发送给被叫。
4 结束语
至此，我们描述了基于B2BUA模式设计的六层模型，对SIP呼叫处理进行初步的抽象化和模式化，并通过一个INVITE发呼的过程，让读者能够清晰六层模型的划分原则和意义，并进一步叙述了模式中每个逻辑层所设计的对象及其所需要完包含的功能。本文归纳总结了基于B2BUA的SIP呼叫处理的六层模型以及设计模式，就是希望与读者一起探讨SIP系统模式化的可行性，为SIP实践推广和NGN的来临抛砖引玉。
参考文献：
[1]会话发起协议IETF RFC3261中文版[EB/OL].http：//wenku.baidu.com/view/3e59517b1711cc7931b71654.html.
[2]B.Roach，Session Initiation Protocol （SIP）-Specific Event Notification.RFC3265，June，2002.
作者简介：施伟峰（1977.11.17-），男，福建晋江人，本科，研究方向：云计算、NGN软交换。
作者单位：福建富士通信息软件股份有限公司，福州 350013
关键词：SIP；B2BUA；六层模型；模式设计
中图分类号：TP393.05
当今，SIP的诸多业务，例如IP电话技术、即时通讯技术、SIP消息短信技术、IP PBX交换机、多媒体会议等都已经在众多的电信运营商、ITSP（IP 电话服务商）和CLEC（竞争本地运营商）的商业运营网络中得到了广泛应用。
SIP协议理论虽已广为人知，但在实践的应用还存在较大成长空间，将SIP协议成功的转换为软交换应用软件，还需要在遵循SIP协议基本原则的基础上，设计出其体系架构。因此，本文重点描述基于B2BUA模式抽象出来的SIP 服务器设计模式，通过体系及流程的分析，将通过实践证明其稳定性和可行性的设计模式方案与大家分享，指导SIP实践应用。
1 B2BUA模式
SIP（Session Initiation Protocol，会话发起协议）是由IETF制定的基于英特网多媒体业务应用的一系列重要协议之一。SIP协议建立在简单邮件传送协议SMTP和超文本传送协议HTTP基础之上，用来描述一个或多个参与者创建、修改和终止会话的应用层控制（信令）协议。
SIP 会话定义了四个主要逻辑组件：用户代理、注册服务器、代理服务器和重定向服务器。这些组件间通过传输承载了 SDP 协议的SIP消息来完成一个基本会话。根据协议描述，进行呼叫处理的逻辑组件是代理服务器，其通过简单控制SIP消息来控制UAC和UAS之间通话的建立和终止，不对UAC和UAS的通话进行控制和干预。若按SIP协议实现代理服务器的话，实现业务流程和用户计费将极为困难，因此，商业化系统的呼叫处理必须采用B2BUA的模式，B2BUA实质UAC和UAS两个逻辑实体的集合，其中一端使用UAS连接主叫，另外一端使用UAS连接被叫，两者通过呼叫控制的逻辑组件进行连接。通过呼叫控制组件，B2BUA服务器能够在内部建立通信链路，因而成为了SIP协议实际应用过程中被普遍采用的设计模式。
2 SIP系统架构
我们需要了解下SIP系统的设计思路，SIP系统的设计，除遵循SIP协议和B2BUA模式，还要参照通信的业务需求。因此，系统设计为5大功能和2大数据功能子系统，除常规SIP服务器所需的注册、呼叫处理功能外，还加入了计费、冷热备份及负载均衡。
离线数据模块：离线数据的设计对象是数据库，离线数据就是将实际运营所需要的用户数据（号码计划、终端类型、业务配置等）及用户状态（信道状态、呼叫记录、业务状态、呼叫类型、计费信息等）储存于数据库中。存储的设计必须考虑到系统的兼容性、移植性，独立性等特征，例如：需要支持支持多平臺下的各种数据库，需要支持数据库与SIP 应用系统分离。
在线数据模块：在线数据的设计对象是物理内存，用户在呼叫过程中需要频繁的访问用户数据，如果将大量数据存放在数据库中，会造成呼叫处理模块对数据库的频繁调度，数据库访问和内存访问的速度差异，将会成为系统性能瓶颈。为了保证呼叫的高速处理，设计上必须在系统启动后，将离线数据镜像映射到内存，再封装到不同的数据对象中，呼叫处理模块通过访问数据对象来实现对在线数据的调用管理和离线数据的实施更新。
呼叫处理模块：呼叫处理模块，整个SIP Server服务器的核心构件，其主要任务是完成呼叫过程的所有用户事务处理，并对处于通话过程进行管理和控制，这在后续的呼叫处理的设计模式的探讨中将进一步详述。
注册模块：终端注册处理模块，提供终端用户的在线注册、注销管理、用户鉴权管理。
备份冗余模块：针对主动系统进行监控，并实时进行数据备份，当主动系运行出现故障时，备用系需要及时监控出主动系统的障碍并切换（热备份）或者启动（冷备份），以保障用户的通话畅通。
计费模块：根据呼叫处理记录的用户的呼叫信息以及用户属性、业务类型等信息参照计费标准进行话费核算
负载均衡模块：通过集群服务器监控所有的SIP Server，协调服务器的通话负荷，当服务器的负荷到达服务器的处理极限时，将部分用户呼叫分流到呼叫负荷较低的服务器上，既保证了服务器的稳定性，又提高了服务器的利用率。
本文的重点是基于B2BUA的SIP呼叫处理模式，接下我们将深入探讨呼叫处理核心子系统的设计与实现。
3 呼叫处理模式设计
呼叫处理模块是整个SIP服务器的系统核心，模式设计的核心工作就是抽象，因此，借鉴网络设计的7层OSI模型，我在此将SIP 服务器的呼叫处理过程设计为六个层次：协议栈层、协议层、接续层、连接层、控制层、业务层。分成设计的目标是为了将协议、消息、事务、控制、业务进行分离，以便有效的管理呼叫处理的整个过程，整个呼叫处理就依照着这六层模型的定位展开其具体的分层模式和流程设计的介绍。
3.1 SIP六层模式设计
协议栈设计：设计目的是为采用不同信令协议的终端加载不同类型的协议栈。
主要提供各种终端连接所需的协议库的自动识别与调用，为了提高系统接入不同设备的兼容性，协议层支持调用不同类型的协议栈，如SIP，H323。
SIP协议栈由静态库和动态库构成，支撑开源或定制的标准协议栈，能够为协议层提供RFC3261和RFC3265中所定义的所有SIP协议基本消息的构造。
协议层设计：设计目的是根据不同协议，建立和终端机协议相匹配的对象，并实现基于消息体层面的消息接收与发送。
协议层对象SIP Stack Cntl主要是接受来自终端或者UA的消息，并根据消息，生成终端管理对象，选择消息分发的对象（对内或对外）。 协议层具有较强的协议相关性，支持不同协议的终端的消息总是有与之对应的协议层对象接受并转发给接续层。
接续层：设计主要考虑的是终端的接续，并对终端对象进行状态控制及超时控制
Partial Call对象，针对呼叫用户信息（即SIP消息中的FROM Head中的用户号码）生成的唯一对应的对象，每个对象通过调用用户状态数据表Line Status Man以及超时计时器Timer来控制呼叫过程的用户状态以及呼叫超时。
接续层具有弱协议相关性，系统会根据不同的协议设计连接管理对象Partial Call，例如SIP协议层会选择SIP Partical Call进行SIP消息的处理，而H323协议层会选择H323PartialCall对象来进行H323消息的处理。
连接层：为了实现不同协议终端的连接，导致接续层设计也需要考虑协议的差异性。而连接层的设计目标，就是实现协议无关性，连接层的主要作用就是连接不同的协议对象，将协议消息翻译成为协议无关的内部呼叫控制信令，保证控制层对下层对象的控制的同时，实现不同协议之间的连通性。
每个Connect对象都应当和相同协议的接续层对象Partial Call相对应，例如：SIP Partial Call对象就应当生成SIP Connect Cntl对象与之对应，H323PartialCall就应当和H323ConnectCntl对象对应。
控制层：控制层主要为SIP基础呼叫事务的处理以及基础场景（连接、呼叫、断开）的控制，并实现呼叫状态的控制、记录、以及变更。
控制层根据每一个呼叫场景建立自己独立的Call Control对象，对象下挂接有该通话所属的所有SIP Connect Cntl，并对其呼叫状态进行控制管理。
由于一些呼叫并不只限于两方，比如会议，转移、等待业务等，这时候，就需要控制层能够接收业务层的调用，通过对SIP基础呼叫场景以及基础事务的重组，实现多个Connect Cntl對象的互连互通。
业务层：每一个呼叫业务的处理核心，设计目的是通过Call Flow和Scenario对象实现呼叫处理和场景变化。
Call Flow对象是呼叫处理的核心对象，主要工作是接受来自Connect Cntl对象的协议无关的消息，并根据业务类型创建不同的场景对象（scenario）进行对应的处理。一次呼叫过程有且只能有一个Call Flow来唯一分配处理该次呼叫中的任何消息。
Scenario对象针对业务设计的，提供业务执行所需要的消息状态机，实现业务消息的处理和流程的扭转。（1）不同的业务有着自己不同的消息流程，因此Scenario要根据业务的消息流程创建一个独立的消息状态机，该状态机能自行处理消息流程中的各种正常和异常消息。因此，场景对象Scenario就能通过Call Flow使用独立的消息状态机来灵活控制业务流程。（2）Scenario对象能够通过解析用户消息所携带的业务信息，来判定需要向用户提供的业务，并在不同的场景对象之间进行切换，保证用户希望的业务能够被顺利执行。（3）即存的基于No.7信令的传统电话业务流程，都可将呼叫信令转化为SIP消息时序图，并设计为对应该业务场景的消息状态机，来实现传统话机业务向SIP呼叫业务的转移。
3.2 呼叫处理流程设计
上节描述了六层SIP呼叫处理的设计模式，接下来将基于该呼叫处理模式给出基于该系统架构的SIP简单呼叫过程的处理流程：（1）SIP Stack Cntl收到来自终端的请求消息（INVITE），调用SIP协议栈解析消息的合法性，并根据消息的FROM Head中的终端信息，从SIP Partial Call的对象管理表中创建或选择匹配对象，并将该解析完成的消息做成消息镜像送到该SIP Partial Call。（2）SIP Partial Call在收到SIP Stack Cntl的消息之后，将根据消息中的TO Head，访问Dec Device（在线局数据，用户号码信息），对用户号码进行解析。如果用户号码存在，则通过链路状态管理表Line Status Man获取对应号码的链路状态。如果该号码链路状态为空，则创建Call Flow呼叫流程管理对象，并将消息发送给Call Flow。如果线路状态为忙，则Partial Call直接返回408 Busy Reject给终端，并结束SIP Partial Call对象以结束通话。（3）Call Flow在收到消息之后，根据消息类型，创建所需业务场景对象Scenario，通过场景消息状态机着手处理呼叫流程（例如：发送100Trying消息给呼叫端，状态跃迁至180 waiting态）。（4）Scenario对象创建并关联呼叫控制对象Call Control，并将Call Flow对象与Call Control对象，以及主、被叫的连接对象SIP Connect Cntl关联。（5）Scenario会根据被叫信息访问SIP Partial Call的对象管理表，若被叫对象已存在，就不再创建新对象，仅将两对象关联。若被叫还没创建对象，该场景对象 Sceanrio会根据解析出来的号码信息创建被叫的SIP Partail Call，并同时关联到SIP Connect Cntl和Call Flow，保证回程消息能够正确的送到Call Flow。（6）消息经由Call Flow送到被叫SIPConnect Cntl对象并转译成SIP协议消息需求送至被叫SIP Partail Call对象。被叫SIP Partail Call对象在收到消息发送指令后，由SIP Stack Cntl将消息按照指令需求重构后发送给被叫。
4 结束语
至此，我们描述了基于B2BUA模式设计的六层模型，对SIP呼叫处理进行初步的抽象化和模式化，并通过一个INVITE发呼的过程，让读者能够清晰六层模型的划分原则和意义，并进一步叙述了模式中每个逻辑层所设计的对象及其所需要完包含的功能。本文归纳总结了基于B2BUA的SIP呼叫处理的六层模型以及设计模式，就是希望与读者一起探讨SIP系统模式化的可行性，为SIP实践推广和NGN的来临抛砖引玉。
参考文献：
[1]会话发起协议IETF RFC3261中文版[EB/OL].http：//wenku.baidu.com/view/3e59517b1711cc7931b71654.html.
[2]B.Roach，Session Initiation Protocol （SIP）-Specific Event Notification.RFC3265，June，2002.
作者简介：施伟峰（1977.11.17-），男，福建晋江人，本科，研究方向：云计算、NGN软交换。
作者单位：福建富士通信息软件股份有限公司，福州 350013