基于SIP协议的IP电话增值业务实现技术
王瑜,乐正友
（清华大学电子工程系，北京 100084）
摘 要：讨论了SIP协议以及基于SIP协议的IP电话增值业务实现技术，并对SIP CGI、CPL、SIP Serv-lets、JAIN APIs等几种SIP编程技术进行了分析与比较，归纳总结了开发IP电话增值业务的一般方法。
关键词：智能网；IP电话；协议；增值业务
一、引言
近年来随着Internet的日益普及，基于分组交换的IP电话技术得到了迅速的发展。最初的IP电话只能实现PC到PC的简单呼叫，随着H.323、SIP等相关IP电话协议的出现，IP电话技术中的控制和信令体系日趋完善，几乎所有的传统电信业务都能够在IP网上得以实现。不仅如此，IP电话技术还能够将传统电信业务与Internet应用相结合，例如在Web中集成800呼叫，用媒体流技术实现语音信箱等等，从而提供比传统电信网更加丰富的业务类型。如何在现有IP电话协议的基础上方便快捷地开发IP电话应用、实现各种IP电话增值业务，已成为现今IP电话技术中的核心问题之一。
本文将以SIP协议为例，讨论IP电话增值业务的开发及实现方案，然后结合具体实例介绍SIP CGI、CPL、SIP Servlets、JAIN APIs等SIP编程技术，并对它们各自的特点及应用范围加以比较与分析，从而归纳总结出开发IP电话增值业务的一般方法。
二、SIP协议简介
SIP（Session Initiation Protocol）协议由IETF（Internet Engineering Task Force）的MMUSIC（Multi-party Multimedia Session Control）工作组提出，是一个用于建立和控制多媒体会话的应用层协议，其中的多媒体会话包括多媒体会议、远程教育、IP电话以及类似的应用。SIP协议支持单播和多播通信，支持名称映射和重定向业务，支持类似呼叫转发、呼叫拒绝等电信业务的实现，支持用户移动性。
1SIP的功能及组件
总体说来，SIP协议支持多媒体通信中以下几个方面的功能：
(1)用户定位：确定通信中终端系统的位置；
(2)用户可用性：确定被叫方是否愿意参与通信；
(3)性能协商：确定通信中所用媒体及媒体参数；
(4)会话建立：呼叫双方会话参数的建立；
(5)会话管理：包括会话转移和中止、会话参数变更、调用新业务等内容。
采用SIP协议的通信系统应该包括2种组件：SIP用户代理（User Agent简写为UA）和SIP网络服务器。SIP用户代理是终端系统组件，而SIP网络服务器是处理大量呼叫信令的网络设备。
SIP用户代理UA又分为用户代理客户端（User Agent Client，简写为UAC）和用户代理服务器（User Agent Server，简写为UAS），前者发起呼叫，后者应答呼叫。
SIP网络服务器包括SIP代理服务器（SIP proxy server）、SIP重定向服务器（SIP redirect server）和SIP注册服务器（SIP registrar）3种。SIP代理服务器接收到呼叫请求后，通过地址解析确定被叫方位置，然后将请求转发至下一跳服务器。而SIP重定向服务器则是在完成地址解析后将被叫方的地址信息发给呼叫方，让呼叫方直接向下一跳服务器发送请求。SIP注册服务器用于接受客户端的注册请求，并提供定位服务。
2SIP的消息机制
SIP是一个基于文本的协议，它的消息分为两大类：从客户端到服务器的请求（Request）和从服务器到客户端的响应（Response）。
无论请求消息还是响应消息都是由起始行（Start-Line）、消息头部（Message-Header）和可选的消息体（Message-Body）构成。SIP消息的头部字段主要有From、To、Call-ID、Cseq、Via、Contact等，用于标识会话的各种相关参数，而可选的消息体部分通常用于描述会话双方的通信能力。
请求消息的起始行称为请求行（Request-Line），其中的“方法”（Method）字段表明了请求消息的功能。
SIP协议定义了6种方法：
(1)REGISTER：用于登记联系信息；
(2)INVITE：用于邀请用户加入会话；
(3)ACK：用于对邀请作出响应；
(4)CANCEL：用于取消未完成的请求；
(5)BYE：用于终止会话；
(6)OPTIONS：用于询问服务器的性能。
响应消息的起始行称为状态行（Status-Line），其中的状态码字段指示了被叫方对请求的响应结果。
SIP协议定义的状态码是一个3位整数，同样也分为6大类：
(1)1xx（100～199之间的状态码用1xx表示，以下类推）：暂时响应——呼叫处理中；
(2)2xx：成功响应——请求被成功接收、理解并接受；
(3)3xx：重定向响应——需要采取进一步动作以完成请求；
(4)4xx：客户端出错——客户端的请求包含语法错误或无法在服务器完成该请求；
(5)5xx：服务器出错——服务器无法完成合法请求；
(6)6xx：全局故障——任何服务器均无法完成请求。
3SIP呼叫举例
图1描述了一个典型的SIP呼叫。[email protected]作为UAC希望同[email protected]通话，他首先发出一个INVITE请求，本地的SIP代理服务器sip1.com接受到这个INVITE请求后，经过地址解析，将其发送至SIP代理服务器sip2.com，同时sip1.com返回给user1一个100 Trying消息。sip2.com接收到sip1.com的INVITE请求后，将其转发给[email protected]，并返回给sip1.com一个Trying消息。user2接受到INVITE请求后，在应答之前，将返回给sip2.com一个180 Ringing消息，此Ringing消息将依次转发给sip1.com、user1。如果user2决定应答呼叫，则返回一个200 OK消息，此消息经过sip2.com、sip1.com最后到达user1。user1在收到200OK消息后，直接发送一个ACK确认消息给user2。至此呼叫建立过程完成，user1和user2之间可以建立媒体通道进行对话。当一方想结束通话时，发送一个BYE消息给对方，对方返回一个200 OK消息，SIP呼叫即被终止。
三、基于SIP的IP电话增值业务实现方案
1电话增值业务简介
传统电信网的电话业务分为3类：仅具有呼入呼出功能的传统电话业务，包含呼叫转移、三方通话、语音信箱等功能的程控电话新业务，以及近年来得到广泛应用的电话增值业务。
目前电信部门提供的电话增值业务有电话投票业务、记帐卡呼叫业务、800业务和200卡业务等。传统电信网的电话增值业务主要是通过智能网（Intelligent Network，简写为IN）实现的。智能网是在原有通信网络基础上为快速提供新业务而设置的附加网络结构，它的最大特点是将网络的交换功能与控制功能相分离，把电话网中原来位于各个端局交换机中的网络智能集中到若干个新设的功能部件——称为智能网的业务控制点的大型计算机上，而让原有的交换机仅完成基本的接续功能。
而对于IP电话来说，由于它架构在Internet之上，其增值业务的内容要丰富得多，实现方式也与传统电信网有所不同。以800业务为例，在传统的800业务模式中，用户只能通过电话机终端拨打800号码，而IP电话则可以将800业务与Web服务相结合，实现“click-to-dial”，也就是用户可以在浏览网页时通过点击享受800服务，而企业也可以将更多的信息资源通过Internet融入到800业务中去。
2SIP增值业务实现技术
SIP协议可以说是为IP电话量身定做的协议，事实上，在SIP协议的设计中也处处体现出它在实现电话新业务方面的优势。举例来说，如果要在基于SIP协议的IP电话业务中实现呼叫转移，几乎不用再做其它的工作，因为SIP协议本身就包含了对呼叫转移以及用户移动性的支持，用户只需用他当前的终端在SIP定位服务器上注册，所有指向该用户的呼叫即可方便地转移到当前终端上。SIP协议还借用了HTTP和SMTP协议的成功方法，引入了许多扩充性能，而且SIP协议本身又是基于文本的，这些都给SIP增值业务的实现提供了方便。
然而，仅仅靠SIP协议本身的特性来实现不断涌现的各种IP电话增值业务是远远不够的。在采用SIP协议的IP电话网中，实现功能繁多的增值业务必须依靠业务功能模块对网络系统元件的动作加以控制。仍以前面提到的“click-to-dial”800业务为例，如果某个企业希望对使用“click-to-dial”方式呼叫800业务的用户进行分类，根据用户提出的问题按照售前咨询、技术支持和售后服务3个类别将呼叫转移至不同的客户服务代表，那么只需在用户点击800呼叫时提供问题类别信息，在提交SIP呼叫请求时将问题类别信息一同发送至SIP服务器，服务器端通过业务功能模块对用户信息加以判断并与相应的客服代表的SIP地址对应，这样便可以方便地实现800呼叫的分类功能。
实现基于SIP协议的IP电话增值业务的基本模型如图2所示。当SIP服务器接受到请求或响应时，将信息通过程序接口传递给业务功能模块，业务功能模块基于收集到的信息发出指令再传递给SIP服务器，SIP服务器依据得到的指令继续执行。
上面所说的将业务功能模块和服务器相分离的模型其实并不是SIP增值业务所独有的，在前面提及的智能网中就用到了类似的思想。当呼叫建立消息到达智能网的交换机时，交换机并不直接处理，而是将其传递给另一个分离的设备——业务控制端（Service Control Point，简写为SCP），继而等待SCP传回的指令。在Internet上的Web业务中也有类似的情形，Web服务器接收到用户浏览器传来的请求信息后，有时并不能直接输出用户所需访问的内容（例如要做数据库查询、后台数据处理等），这时Web服务器就会通过CGI（Common Gateway Interface）、ASP（Active Server Pages）、JSP（Java Server Pages）来完成数据库的访问等工作。
由于SIP与HTTP等文本协议有很强的相似性，所以在设计业务功能模块及其与SIP服务器之间程序接口时，我们完全可以参考Web业务中的做法，甚至可以将CGI等成熟的技术直接拿来使用。当然，我们也可以根据SIP协议以及IP电话的特点，另外制定一套技术规范来实现基于SIP的IP电话增值业务。下面我们将对几种主要的SIP编程技术依次作一分析。
四、几种SIP编程技术的分析与比较
1SIP CGI
在Internet领域中，CGI一直是进行Web编程的有效手段，即使与后来大行其道的ASP、JSP相比，CGI在Web编程的灵活性上依然有着自己的优势。前面也提到过，由于SIP与HTTP的相似性，我们很自然的会想到用CGI来作为开发SIP业务的工具。
具体说来，用CGI来开发SIP业务有以下几点优势：
(1)语言独立性：CGI可以用Perl、C、VisualBasic以及很多其他语言来开发，只要它们支持环境变量的获取即可；
(2)头部信息的获取：CGI可以获取HTTP请求的所有头部信息，这对SIP业务来讲同样非常重要，因为SIP的头部信息几乎包含了呼叫的全部有用信息，例如呼叫方、被叫方、主题、地址、呼叫状态等；
(3)响应的生成：CGI的另一个优势在于它除了能够生成消息体之外，可以生成响应的任何一个部分，包括头部、状态码等，而其他的一些编程机制，比如Java servlets只是考虑消息体部分。对于SIP协议来说，消息体并不是新业务开发中最重要的部分，因此能否生成响应的所有部分就显得尤为关键；
(4)组件重用：由于SIP协议重用了很多HTTP的语法，因此针对SIP开发的CGI可以重用HTTP CGI的很多有用工具；
(5)熟悉的开发环境：很多Web程序员对CGI都相当熟悉，这也有助于他们转到SIP的开发中来；
(6)方便的扩展性：由于CGI是接口而不是语言，它能够很容易的被扩展和重用于类似SIP这样的协议。
为此，IETF的Network工作组提出了SIP CGI。尽管SIP与HTTP在基本语法和请求-响应模型上非常类似，但它们之间也存在着很多区别，例如SIP可以将一个请求转发为多个请求，可以支持注册等附加功能，这些都是HTTP所没有的。SIP与HTTP的这些区别导致了SIP CGI的设计必然也与HTTP CGI有所不同，例如SIP CGI允许脚本执行一些特殊的消息功能，SIP CGI还引入了一种持续性模型，允许脚本在消息交换时保持控制，而HTTP CGI并没有这些功能。
SIP CGI的基本模型如图3所示。以呼叫转发业务为例，服务器接收到客户端的请求之后，要通过CGI程序来决定何时、向何处转发多少请求，以及何时返回给客户端一个响应。CGI程序还可以更改和创建SIP消息的头部信息，这也使得SIP增值业务的实现变得更加灵活。
2CPL
CPL（Call Processing Language）是由IETF的IPTEL（IP Telephony）工作组提出的一种用于描述和控制IP电话业务的语言。CPL并不局限于某种特定的信令体系或协议，采用SIP或是H.323的IP电话系统都可以利用CPL来开发新业务。
CPL的设计参考了智能网业务的创建模型。首先我们可以用决策图模拟IP电话的业务流程，决策图的节点表示CPL语言的原语，它们之间用有方向性的箭头相连，从而完整地描述了业务流程。图4是一个简单的基于呼叫方的呼叫转发或重定向业务决策图，当呼叫到达服务器后，根据呼叫方地址的域名作判断：如果是example.com（即与被呼叫方地址域名相同，意味着可能是公司同事的来电），那么就直接将呼叫转发给被叫方；如果不是example.com，则呼叫被重定向至被叫方的语音邮件地址。如果前一类情形遇到忙音、超时或呼叫失败，呼叫也将被重定向至被叫方的语音邮件地址。
在完成业务流程的决策图之后，我们还需要把图表转化为服务器可读的CPL脚本。CPL是在XML（Extended Markup Language）基础上设计而成的，而没有用诸如Perl、Tcl、Python的脚本语言，也没有用Java这样的编程语言，这是因为XML的特点非常符合CPL的设计需求。首先，XML很适合表示结构化的数据，特别是选择性的树状结构。其次，XML脚本既可以用机器分析、生成，也能够直接被人阅读理解。另外，XML也具有良好的扩展性，这对于用于开发IP电话业务的CPL来说也是非常重要的。
CPL的呼叫处理是由一系列的节点和输出组成的，这些节点和输出都由XML标记来描述。CPL的节点分为四大类：switches，用于表示CPL脚本可能的决策及后续动作；location modifiers，用于在地址集合中添加或删除地址；signalling operations，用于控制下层信令协议的动作；non-signalling operations，用于触发与信令无关的动作。
与SIP CGI相比，CPL的优势在于对业务流程的描述非常清晰明了，给开发人员也带来了很大方便，甚至终端用户都可以通过设计CPL脚本来实现简单的呼叫控制。然而，CPL这样的设计思路，使得开发人员要额外考虑其安全性和完整性，否则CPL脚本将极易对服务器产生破坏性的冲击。这也导致了CPL方法在灵活性上比SIP CGI有所欠缺，因此SIP CGI适合用于开发较为复杂的SIP业务，而CPL适合用于开发业务流程清晰的IP电话应用。
3SIP Servlets
Servlets是用Java编写的、协议和平台独立的服务器端组件，它采用"请求/响应"模式， 提供了一种基于Java的网络服务器的解决方案，可以动态地扩展支持Java的网络服务器。如同Web业务中的HTTP Servlets是HTTP CGI的替代品一样，对于SIP业务开发者来说，SIP Servlets也是除了SIP CGI之外的一个很好的选择。
IETF组织于1999年9月提出了SIP Servlets的草案，作为SIP服务器的Java扩展API，SIP Servlets可以扩展SIP服务器的功能、控制SIP消息的处理，从而实现更为丰富的SIP业务。
利用SIP Servlets扩展SIP业务的基本模型如图5所示，可以看出它与SIP CGI的模型非常类似。当呼叫请求到达SIP服务器后，由服务器将SIP消息封装成SIP对象，发送给SIP Servlets，SIP Servlets可以读取或更改SIP头部信息、消息体、状态行等，通过对SIP对象的控制，SIP Servlets便能够决定如何响应及转发请求。另外，SIP Servlets还可以自行发起新的SIP事务处理。
ervlets技术与CGI相比，其最大的优势在于Servlets对于客户端来的多个请求只需创建一个进程来处理，当Servlets被客户端的第一个请求激活后，将继续运行于后台，每个后来的请求只会产生一个线程而不是进程，因此多个客户能够在同一进程同时被服务。而CGI针对每个请求都会分别创建一个进程，显然后者的开销要大得多，并且在同一个进程中不能服务多个客户。另外，由于SIP Servlets是基于Java的扩展API，因此它也有着很好的可移植性和跨平台特性。
4JAIN APIs
JAIN APIs是由JCP（Java Community Process）组织推动开发的一套基于Java技术的API，主要用于在Java平台上快速开发下一代电信产品及业务。JAIN APIs包含一系列API，其中与SIP协议有关的API有3种：JAIN SIP、JAIN SIP Lite和SIP Servlets。SIP Servlets在前面已经详细介绍过，这里不再重复。
JAIN SIP API完全基于IETF的SIP规范（RFC 2543）制定， 它提供了SIP协议栈到SIP应用之间的接口，从而使得SIP应用能够与封装了SIP协议栈的对象进行交互。JAIN SIP的体系结构如图6所示，SIP消息被封装在Event Objects中，并且只在JAIN SIP Listener和JAIN SIP Provider之间传递，JAIN SIP Provider为应用程序提供了获取SIP协议栈服务的接口，JAINSIP Listerner则用于获取JAIN SIP Provider提供的服务。因此，JAIN SIP API必须提供Listener和Provider的接口定义、与SIP消息对应的消息接口定义，以及Listener和Provider之间传递消息的方式。
JAIN SIP API是直接对SIP协议栈进行操作的底层API，需要开发者对SIP协议有较为深刻的理解，这无疑又加大了SIP开发的难度，因此JAIN APIs又为开发者提供了一套高层API——JAIN SIP Lite，开发人员无需深入了解SIP的细节就可以进行SIP应用的开发。目前JAIN SIP Lite的规范正在制定之中。
五、结束语
将传统电信网与Internet应用相结合是当今IP电话技术的发展趋势，两者的融合也使得更多IP电话增值业务的实现成为可能。同时，我们也应该看到，目前开发IP电话业务的技术是多种多样的，前面提到的基于SIP协议的开发标准就有四、五种之多，而它们的技术特点、应用范围以及实现难度又不尽相同。因此，如何根据应用的规模、特点来选择合适的开发技术，也是在开发IP电话增值业务时需要仔细考虑的问题。
参考文献
［１］糜正琨．IP网络电话技术［Ｍ］．人民邮电出版社，2000．
［２］M Handley，et al．SIP:Session Initiation Protocol［Ｓ］．RFC2543，IETF，March 1999．
［３］J Rosenberg，et al．Programming Internet Telephony Services［Ａ］．IEEE Internet Computing［Ｃ］，May～June 1999．
［４］J Lennox，H Schulzrinne．CPL: A Language for User Control of Internet Telephony Services［Ｓ］．Internet Draft，IETF，Jan.2002．
［５］J Lennox，et al．Common Gateway Interface for SIP［Ｓ］．RFC3050，IETF，Jan.2001．
［６］A Kristensen，A Byttner．The SIP Servlet API［Ｓ］．Internet Draft，IETF，Sept.1999．
［７］JAIN SIP Release 1.0 Specification［Ｓ］．
本文地址：http://com.8s8s.com/it/it34042.htm