CN101658011B

CN101658011B - 一种部署方法、sip业务的处理方法与设备

Info

Publication number: CN101658011B
Application number: CN200880000005.7A
Authority: CN
Inventors: 施广宇; 廖兴亚; 张民卫
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2008-02-05
Filing date: 2008-02-05
Publication date: 2013-11-06
Anticipated expiration: 2028-02-05
Also published as: WO2009100619A1; CN101658011A

Abstract

本发明的实施例公开了一种部署方法、SIP业务的处理方法以及对应的设备。通过使用本发明提供的实施例，使用标签在SSP中描述会话业务逻辑，配置SSP并部署在SIP Servlet容器中，由SIP Servlet容器根据部署的SSP生成SIP Servlet程序并来处理接收到的SIP业务请求，大大简化了SIP业务开发的复杂度和开发工作量。

Description

一种部署方法、SIP业务的处理方法与设备

技术领域

本发明涉及网络技术领域，尤其涉及一种部署方法、SIP(SessionInitiation Protocol，会话发起协议)业务的处理方法与设备。

背景技术

目前在SIP领域中，SIP应用业务本身十分复杂，例如：多方通话业务会话中的消息交互会很多，通常情况下，SIP应用业务对特定的请求的处理逻辑也不相同，对每个消息，业务开发者需要编写不同的代码逻辑来处理，而且一个会话会包含多个消息，如何保证收到一个消息后，能找到合适的业务逻辑来处理该消息是一件困难的事情。

SIP Servlet(基于SIP协议的运行在Web服务器上的Java程序)规范提供了一系列的Java API(Application Programming Interface，应用程序接口)和一个基于容器(Container)的开发模型，用于提高服务器端SIP应用的开发效率。SIP Servlet容器提供SIP Servlet应用的部署、运行和管理环境。通过SIP Servlet，开发人员可以开发出复杂的SIP应用程序，如同HTTP Servlet在Web应用开发中起到的作用一样。

通常情况下，一个会话会包含多个消息，业务对特定的请求的处理逻辑也不相同。在SIP Servlet中，SIP Servlet API仅提供了几个通用的消息回调接口。如：

protected void doAck(SipServletRequest req)

Invoked by the server(via the service method)to handle incomingACK requests.

//表示SIP容器收到消息，当消息头是ACK时，将消息进行回调。

类似的消息回调接口还包括doBye、doCancel、doErrorResponse、doInfo等，在此不进行一一列举。

发明人在实现本发明的过程中，发现现有技术中：

为了对收到的“method”字段相同的请求或“status code”相同的应答找到合适的业务逻辑来处理，开发人员必须根据SIP会话当前的上下文，设计大量代码维护特定的SIP消息到相应的业务逻辑的映射。

当要从通话流程中删除某个消息或是增加某个消息时，开发人员需要理解这些复杂逻辑加入相应的维护映射的代码，因此导致目前SIP应用的业务开发仍然比较复杂。

发明内容

本发明的实施例提供一种开发方法、部署方法、SIP业务的处理方法与设备，以简化基于SIP的业务开发的复杂性与繁琐性。

为达到上述目的，本发明的实施例提供一种部署方法，包括以下步骤：

SIP Servlet容器启动时，读取SIP应用的部署描述符，其中，所述SIP应用的部署描述符中包括SSP的部署信息；

对所述SIP应用的部署描述符进行解析，在解析所述SIP应用的部署描述符的过程中，遇到SSP的部署信息；

根据所述SSP的部署信息对相应的SSP进行部署。

本发明的实施例还提供一种通信系统，所述通信系统包括SIPServlet容器，所述SIP Servlet容器包括部署单元和缓存单元，

所述部署单元，用于在启动时，读取并解析SIP应用的部署描述符，其中，所述SIP应用的部署描述符中包括SSP的部署信息；在解析所述SIP应用的部署描述符的过程中，遇到SSP的部署信息时，根据所述SSP的部署信息将相应的SSP装载到所述缓存单元中。

本发明的实施例还提供一种SIP业务的处理方法，包括以下步骤：

接收SIP消息，该SIP消息中携带有信息，获取所述SIP消息中的信息；

根据所述SIP消息的信息，以及预设的匹配规则，获取处理所述SIP消息所使用的SSP实例；

由所述获取的SSP实例处理所述SIP消息。

本发明的实施例还提供一种通信系统，所述通信系统包括SIPServlet容器，所述SIP Servlet容器包括处理单元和缓存单元；

所述处理单元用于获取接收到的SIP消息中的信息；并根据所述信息，以及预设的匹配规则，获取处理所述SIP消息所使用的SSP实例；由所述获取的SSP实例处理所述SIP消息。

本发明的实施例还提供一种应用服务器，包括SIP Servlet容器，所述SIP Servlet容器包括处理单元、部署单元和缓存单元；

所述处理单元用于接收SIP消息，获取接收到的SIP消息中的信息；并根据所述SIP消息中的信息，以及预设的匹配规则，获取处理所述SIP消息所使用的SSP实例；由所述获取的SSP实例处理所述SIP消息；

所述部署单元，用于根据SSP的部署信息将相应的SSP装载到所述缓存单元。

本发明的实施例中，配置SSP并部署在SIP Servlet容器中，当接收到SIP请求时，由SIP Servlet容器根据部署的SSP处理该接收到的SIP请求，大大简化了业务开发的复杂度和开发工作量。

附图说明

图1是本发明实施例中SSP的组成结构示意图；

图2是本发明实施例中功能标签的开发流程示意图；

图3是本发明实施例中在SIP Servlet中部署SSP的流程图；

图4是本发明实施例中SSP部署在SIP容器上的示意图；

图5是本发明实施例中SIP消息的处理方法流程图；

图6是本发明实施例中应用场景中的信令交互图；

图7是本发明实施例中的Invite事务状态机的功能实现流程示意图；

图8是本发明实施例中的Bye事务-发送Bye请求状态机的功能实现流程示意图；

图9是本发明实施例中的Bye事务-接收Bye请求状态机的功能实现流程示意图；

图10是本发明实施例中SSP文件配置路径的示意图；

图11是本发明实施例中通信系统的结构示意图；

图12是本发明实施例中通信系统的结构示意图；

图13是本发明实施例中应用服务器的结构示意图。

具体实施方式

本发明的实施例提供一种部署方法、SIP业务的处理方法与设备。具体的，在SSP(SIP Server Pages，SIP服务端页面)中使用标签进行SIP业务逻辑的描述，将SSP编译为SIP Servlet程序并部署在SIPServlet容器中，用于SIP消息的处理。

以下分别对开发方法、部署方法以及SIP业务的处理方法进行描述。

本发明实施例涉及的开发方法中，使用标签开发SSP，SSP是包含了业务逻辑描述的页面，其组成示意图如图1所示：SSP的内容可以由一组标签聚合而成，不同的标签聚合之后能够描述不同的应用业务逻辑。在基于SSP开发SIP应用的过程中，定义应用程序所处的各种状态以及状态之间的转换关系，在收到SIP消息后对应用程序应处的状态和应进行的业务逻辑进行控制。

本发明的实施例中，为了对应用程序所处的状态模式和业务逻辑进行控制，提供了以下几种标签，包括但不限于：

(1)用于定义业务状态的标签：可用于定义应用程序在发送/收到消息后，应该处于的业务状态，其包括状态定义标签。

(2)控制状态跳转的标签：可用于定义应用程序在发送/收到消息后，应该跳转到哪个业务状态，其包括跳转标签。

(3)业务动作标签：可用于定义当应用程序进入业务状态后/离开业务状态前，所应该触发的业务逻辑。业务逻辑可由以下功能标签来描述，也可以由JAVA程序来实现。其包括进入动作标签和离开动作标签。

(4)功能标签：可用于描述处理特定消息的业务逻辑。如表1所示，其包括：

表1.功能标签中包括的内容

标签名	标签功能
		赋值	为SIP Servlet容器中的Session/ApplicationSession/request域中的变量赋值。
删除	删除SIP Servlet容器中的Session/ApplicationSession/request域中的变量
		判断	用于判断包含在该标签体内的逻辑是否被执行
复杂判断	用途同判断标签，不过能够支持判断分支。比如：如果a大于1则执行b＝3如果a大于0则执行b＝4如果a大于-1则执行b＝5否则执行b＝0
		循环控制	迭代访问一个集合中的元素
分割字符	可根据某个分隔符分隔指定的字符串。
		选择	从集合中选择出符合要求的元素

(5)流程模板标签：可用于定义一个模板业务会话流程，该业务会话流程一般是指可复用的一段业务会话流程。

(6)流程标签：可用于定义一个业务会话流程。

(7)应用标签：可用于定义一个应用，一个应用中可包含多个会话流程。

(8)导入其他SSP标签：可用于导入其他包含流程定义或流程模板定义或应用定义的SSP。

(9)导入标签定义标签：可用于导入自定义标签的标签配置文件，以使后续能够使用自定义标签。

除了可用标签描述业务逻辑之外，还可以直接在SSP中使用JAVA语言实现复杂业务逻辑，这些JAVA语句可以包括在“＜％”与“％＞”中间。

除了上述可以预先定义的功能标签外，不同的使用者也可以根据实际应用的需要开发自己的功能标签。本发明的实施例中，与标签开发的相关过程如图2所示，具体步骤如下：

步骤s201、根据预先设定的标签格式，描述要实现的功能逻辑，从而实现要完成的功能逻辑的标签。

步骤s202、在标签配置文件中配置该标签的相关信息。

在一个实施例中，具体配置内容包括：标签的名称，其实现标签要完成的功能逻辑类的全路径，标签的属性，以及属性值类型，属性是否为必须等信息。

之后，在SSP页面中可以引入该标签配置文件，该引入过程包括在SSP页面中引入包括标签配置文件的路径、标签配置文件中定义的标签前缀等信息。

之后，使用者就可以在SSP中以<前缀：标签名/>的方式调用自己开发的自定义标签。

上述开发SSP的步骤之后，需要在SIP Servlet容器中部署开发出的SSP，该部署过程如图3所示，包括以下步骤：

步骤s301、在SIP Servlet应用的部署描述符中配置SSP的部署信息。

具体的，在SIP Servlet应用的部署描述符中配置SSP的部署信息，该部署信息可以包括SSP的名称、SSP文件的相对路径、SSP的映射信息、以及是否在SIP Servlet容器启动的时候加载该SSP中的一种或多种。SSP中可以包括不同的标签，不同的标签聚合之后可以描述不同的应用业务逻辑。其中，SSP的映射信息是指对于所有接收到的消息，具有何种信息的请求由该SSP处理，该信息可以包括消息体的内容、消息的发送方等。SSP的部署示意图如图4所示，其中，SSP可以和SIP Servlet一样部署在SIP容器上，完成和SIP Servlet同样的功能。

基于SIP容器的一个SIP应用可以完全由SIP Servlet组成，可以完全由SSP组成，也可以由SSP和SIP Servlet共同组成。包含在SIP应用中的SSP可以和SIP Servlet一样处理用户设备发过来的SIP消息。SSP的部署方式跟SIP Servlet的部署方式的区别在于，可以使用不同的消息体结构进行部署，其一个可能的部署实现如下所示：

<！--在部署描述符中配置SSP的部署信息-->

<ssp>

<！--为ssp文件指定一个名称-->

<ssp-name>multipartycall</ssp-name>

<！--指定该ssp文件的路径-->

<ssp-path>Navigator.ssp</ssp-path>

<！—指定该SSP是否应该在SIP Servlet容器启动的时候加载完毕。其内容如果是负的或者为空，则当该SSP被请求时由容器加载；如果其内容是正的或者是0，则在应用部署时应该加载该SSP完毕。-->

<load-on-startup>1</load-on-startup>

</ssp>

<！--指定ssp文件的映射规则，该规则定义形式与SIP Servlet的映射形式定义一致。请参考JSR116规范。-->

<ssp-mapping>

<ssp-name>multipartycall</ssp-name>

<or>

<！--这里以映射规则为对request中uri的user字段的内容进行匹配为例，对于user字段为xiaowang或xiaoli的SIP消息，通过名为multipartycall的ssp进行处理-->

<equal>

<var>request.uri.user</var>

<value>xiaowang</value>

</equal>

<equal>

<var>request.uri.user</var>

<value>xiaoli</value>

</equal>

</or>

</pattern>

</ssp-mapping>

对于上述部署方式的简要说明如下：对于SSP的部署，可以采用放置在<ssp></ssp>所定义的消息体之间来实现。部署一个名为multipartycall的ssp文件，该ssp文件的路径为Navigator.ssp。另外，通过一个标识位指示该SSP是否应该在SIP Servlet容器启动的时候加载完毕。例如，当标识位内容是负的或者为空时，该SSP在被SIPServlet容器请求时由容器加载；当标识位内容是正的或者是0时，则在SIP Servlet容器启动的时候时加载该SSP完毕。本例中的映射规则为：对request中uri的user字段的内容进行匹配，对于user字段为xiaowang或xiaoli的SIP消息，通过名为multipartycall的ssp进行处理。

对于SIP Servlet的部署，可以采用放置在<SIP Servlet>和</SIPServlet>所定义的消息体之间来实现。对于映射规则的定义方式与上述SSP的映射规则的定义所采用的方式相同。应当理解的是：在本实施例中，当基于SIP容器的一个SIP Servlet应用完全由SSP组成时，在该SIP Servlet应用的部署描述符中采用放置在<ssp></ssp>所定义的消息体之间来实现SSP的部署；当基于SIP容器的一个SIP Servlet应用由SSP和SIP Servlet共同组成时，在该SIP Servlet应用的部署描述符中采用放置在<ssp></ssp>所定义的消息体之间来实现该SSP的部署或采用放置在<SIP Servlet>和</SIP Servlet>所定义的消息体之间来实现该SIP Servlet的部署。

步骤s302、打包SIP Servlet应用。

具体的，SSP文件可以置于SIP Servlet应用的任意目录中，则对SIP Servlet应用进行打包时包括了对SSP文件的打包，该打包过程的要求与JSR116规范中定义的SIP Servlet应用标准打包方式一致。

步骤s303、将打包后的SIP Servlet应用放置于SIP Servlet容器的应用目录下，以便SIP Servlet容器在启动时能够对该SIP Servlet应用进行自动部署。

步骤s304、启动SIP Servlet容器。

步骤s305、SIP Servlet容器解析SIP Servlet应用的部署描述符，在解析到以<ssp></ssp>描述的SSP的部署信息，则顺序执行步骤s306。否则按照现有JSR116规定进行处理。

步骤s306、根据该SSP的部署信息判断是否需要在SIP Servlet容器启动时装载SSP，如果需要在SIP Servlet容器启动时装载，则执行步骤s308；如果不需要在SIP Servlet容器启动时装载，则执行步骤s307。

在本实施例中，根据该SSP的部署信息判断是否需要在SIP容器启动时装载该SSP，具体实现如下：

在解析以<ssp></ssp>描述的SSP的部署信息的过程中，发现以<load-on-startup></load-on-startup>描述的标识位为1时，确定在SIP容器启动时装载该SSP。

步骤s307、将该SSP的部署信息存储到SIP Servlet容器中并结束。

步骤s308、根据该SSP的部署信息获得对应的SSP文件，并调用SSP编译器将该SSP文件编译为SIP Servlet Java文件；

例如：在本实施例中，在解析SIP Servlet应用的部署描述符的过程中，当解析到以<ssp-path></ssp-path>描述的该ssp文件的路径时，根据该路径获得对应的SSP文件，如：Navigator.ssp。

步骤s309、调用Java编译器将该SIP Servlet Java文件编译成SIPServlet字节码文件；

步骤s310、调用类装载器装载该字节码文件；

步骤s311、实例化该字节码代表的类，得到一个实例；

步骤s312、将该实例缓存到SIP Servlet容器中。

步骤s313、判断部署描述符是否解析完毕，如果解析完毕，则SIP Servlet容器部署该SIP Servlet应用完毕；否则，进行步骤s305，即继续解析SIP Servlet应用部署描述符。

至此，完成了部署描述符的部署。

本发明实施例还提供一种SIP会话业务的处理方法，如图5所示，其具体步骤包括：

步骤s501、接收SIP消息，该SIP消息中携带有信息；

具体可以是：SIP Servlet容器接收会话业务的SIP消息，该消息中的信息可以为消息中携带的request.uri.user信息。步骤s502、使用部署描述符中配置的映射规则来匹配该消息，如果匹配成功则继续，该匹配规则可以参考JSR116规范。

根据映射规则，确定与该接收的sip消息中携带的用户信息对应的ssp-name；SSP的映射信息是指对于所有接收到的消息，具有何种信息的请求由该SSP处理，该信息可以包括消息体的内容、消息的发送方等。

本实施例中，在部署描述符中以<ssp-mapping></ssp-mapping>描述ssp的映射规则，可以将request.uri.user和ssp-name映射起来，例如：接收的sip消息中的request.uri.user为xiaowang，根据部署描述符中预先定义的request.uri.user和ssp-name之间的映射规则，确定与request.uri.user＝xiaowang对应的ssp-name＝multipartycall，亦即：根据映射规则，对request中uri的user字段的内容进行匹配得到对应的ssp-name，例如：对于user字段为xiaowang或xiaoli的SIP消息，匹配得到ssp-name为multipartycall，从而由名为multipartycall的ssp进行处理；

步骤s503、根据确定的与该sip消息对应的实例(为SSP实例或SIP Servlet实例)的名称从缓存中查找实例，如果找到则转到步骤s510，使用该实例处理容器收到的请求，否则顺序执行步骤s504。

步骤s504、判断是由SSP处理该请求还是由SIP Servlet处理该请求，如果是由SIP Servlet处理，那么处理步骤与JSR116定义的一致，用现有的SIP Servlet处理消息的机制处理，否则执行步骤s505。

步骤s505、根据部署时缓存的ssp部署信息(例如：<ssp-path></ssp-path>描述的该ssp文件的路径)获得对应的ssp文件，调用SSP编译器将获得的SSP文件编译为SIP Servlet Java文件。

步骤s506、SIP Servlet容器调用Java编译器将SIP Servlet Java文件编译为SIP Servlet字节码文件。

步骤s507、SIP Servlet容器调用类装载器来装载步骤s506中生成的字节码文件。

步骤s508、待步骤s507完成后，就可以实例化该字节码代表的类，得到一个实例。

步骤s509、缓存该实例；

步骤s510、使用该实例来处理该SIP消息，结束流程。

以下结合一个具体的应用场景，说明本发明实施例的具体实施方式。

假设存在下列应用场景：小王的秘书早上9点钟通过电话会议管理系统预订了一个下午3点钟的电话会议，该电话会议由小王和小李参与。下午三点的时候，电话系统自动呼叫小王和小李，然后二者开始通话。该应用场景中的流程如图6所示，与现有技术相比，业务流程没有发生变化：

步骤s601、SIP应用发送Invite消息给小王的终端。

步骤s602、小王的终端收到Invite消息后振铃，同时响应一个180Ring的应答给SIP应用。

步骤s603、小王的终端响应一个200OK应答给SIP应用，该应答中包含有小王的地址信息。

步骤s604、SIP应用收到小王的应答之后，给小李的终端发送一个Invite消息，并且将小王的地址信息附在该Invite消息里面。

步骤s605、小李的终端收到该Invite消息之后振铃，同时响应一个180Ring的应答给SIP应用。

步骤s606、小李的终端将小王的地址记录下来，然后向SIP应用响应一个200OK应答，并且把自己的地址信息附在该应答中。

步骤s607、SIP应用收到小李的应答之后，给小王发送一个ACK消息，并且将小李的地址信息附在该消息中。然后，SIP应用再给小李发送一个ACK消息。SIP应用开始计费。

步骤s608、小王的终端收到SIP应用发送的ACK消息之后，得到小李的地址信息。

步骤s609、小王和小李都有了对方的地址信息后，他们的终端就会建立连接开始通话。

步骤s610、通话结束，小王挂机。小王的终端发送bye消息到SIP应用。

步骤s611、SIP应用发送Bye消息到小李的终端。

步骤s612、小李的终端向SIP应用发送200OK应答。

步骤s613、SIP应用收到小李终端的200OK应答后，停止计费，并且向小王的终端发送200OK应答。

下面详细阐述上面的例子中的SIP应用如何来基于SSP的技术实现。

从图6所示的消息交互流程中，可以归纳出三个可以进行复用的状态机，每个状态机都可以通过标签进行定义：

Invite事务状态机，功能实现流程图如图7所示，其中涉及到从“发送Invite”、“等待应答”、“收到最终应答”三个状态间跳转的条件。

具体描述如下：当发送Invite时，状态机转到“发送Invite”状态；

当收到小于200的应答时，由“发送Invite”的状态跳转到“等待应答”的状态；

当收到不小于200的应答时，由“等待应答”的状态跳转到“收到最终应答”的状态；

Bye事务-发送Bye请求状态机的功能实现流程图如图8所示，其中涉及到从“发送Bye”到“收到最终应答”两个状态间跳转的条件。

具体描述如下：

当发送Bye请求后，状态机转到“发送Bye”状态；

当“收到最终应答后”，状态机由“发送Bye”状态转到“收到最终应答”状态。

Bye事务-接收Bye请求状态机的功能实现流程图如图9所示，其中涉及到从“收到Bye”到“发送最终应答”两个状态间跳转的条件。

具体描述如下：

当“收到跳转命令后”，状态机由“收到Bye”状态转到“发送最终应答”状态；

当进入“发送最终应答”状态后，进入此状态后发送一个最终应答。

另外一个状态机与请求序列相关，负责调度上述三个状态机。收到一个请求后，调用相应的状态机来处理，这里称为调度状态机。在其他应用场景中，可以不设置单独的调度状态机用于状态机调用。

如下详细介绍了利用SSP描述这几个状态机的过程，其中，在每个实例所包括的注释中对每个配置命令的作用进行了说明。

1)创建一个名称为inviteFSM.ssp的页面，在该页面中描述Invite状态机的定义，如下所示：

<！--定义一个状态机模板，这里为party-->

<flow-template id＝″party″> //flow-template为流程模板标签；

<！--为了使此状态机定义可复用，这里将每个具体的应用中的可能变化的部分定义成变量.变量用”$变量名”的形式定义。在使用该状态机的时候将给这些变量赋值。-->

<var name＝″toUrl″value＝″$toUrl″/>//var为用于定义变量的功能标签；

<start-state ref＝″sendInviteToparty″/>//start-state为开始状态标签；

<state id＝″sendInviteToparty″>//state为状态定义标签；

<！--当进入该状态时，进入动作(entry-action)将马上执行。动作可以为Java类，也可以是Spring容器管理的bean，还可以利用SSP内置的逻辑标签来描述-->

<！--该进入动作的sendRequest方法会接受一个叫toUrl的参数，创建一个Invite请求，并发送给参与者的终端。-->

<entry-action class＝″RequestSender″method＝″sendRequest″>//entry-action为进入动作的标签

<！--从session域中取出toUrl的变量值赋给sendRequest方法的toUrl方法-->

<param name＝″toUrl″value＝″#{session.toUrl}″></param>//参数名称标签

<param name＝″sdp″value＝″#{application.SDP}″></param>//参数名称标签

</entry-action>

<！--

存在三种存储区域，application，session，request.

application域：可访问范围为整个app，存储在该区域内的变量能够被一个app内的多个状态机中的逻辑访问，对应到SIP Servlet中的applicationSession；

session域：可访问范围为单个状态机，存储在该区域内的变量能够被该状态机内的逻辑访问，对应到SIP Servlet中的session；

request域：可访问范围为单个请求，存储在该区域内的变量能够被处理该请求的逻辑访问，对应到SIP Servlet中的request。

-->

<！--

当本状态的动作被执行后(当stateengine.doAction()被调用后)，会跳转到下一个状态。可以配置多个transition，当某个transition的跳转条件满足时，就会执行该跳转。″application.response.code″为从application域中取出叫response的变量，然后取得该变量的code属性。注意：&lt；为″<″符号，&gt；为″>″符号。

-->

<！--当收到小于200的应答时，跳转到waitres状态-->

<transition on＝″#{application.response.code}&lt；200″//transition为跳转标签

to＝″waitres″/>

<！--当收到大于等于200的应答时，跳转到bearing状态-->

<transition on＝″#{application.response.code}&gt；＝200″//transition为跳转标签

to＝″bearing″/>

<！--当条件transition和无条件transition同时配置时，优先执行条件transition。-->

<transition to＝″end-state″/>//transition为跳转标签

</state>

<state id＝″waitres″>//state为状态定义标签

<entry-action class＝″IntermediateResponseProcessor″

method＝″process″>//entry-action为进入动作的标签

</entry-action>//参数名称标签

<transition on＝″#{application.response.code}&lt；200″

to＝″waitres″/>//transition为跳转标签

<transition on＝″#{application.response.code}&gt；＝200″

to＝″bearing″/>

</state>

<entry-action class＝″$FinalResponseProcessor″

method＝″process″>

<！--执行完该动作的方法后，将该方法的返回值用“SDP”作为变量名存储到application域中-->

<result name＝″SDP″scope＝″application″/>//result为赋值标签

</entry-action>

<！--当离开此状态时，离开动作会触发-->

<exit-action class＝″ACKSender″method＝″process″></exit-action>//exit-action为离开动作标签

</state>

<end-state id＝″end-state″/>//end-state为终止状态标签

</flow-template>

2)创建一个名称为byeSenderFSM.ssp的页面，在该页面中描述发送bye的事务的状态机，如下所示：

<！--定义一个状态机模板，这里为sendBye-->

<start-state ref＝″sendBye″/>//start-state为开始状态标签

<state id＝″sendBye″>//state为状态定义标签；

<entry-action class＝″com.huawei.isap.test.sendByeAction″

method＝″send″>//entry-action为进入动作的标签

</entry-action>//参数名称标签

<transition on＝″#{application.currentresponse.code}&gt；＝200″

to＝″recvFinalRes″/>//transition为跳转标签

</state>

<transition to＝″endstate″/>//transition为跳转标签

</state>

<end-state id＝″endstate″/>//end-state为终止状态标签

</flow>

3)创建一个名称为byeRecvFSM.ssp的页面，在该页面中描述接收bye的事务的状态机。如下所示：

<！--定义一个状态机模板，这里为recvBye-->

<start-state ref＝″recvBye″/>//start-state为开始状态标签

<state id＝″recvBye″>//state为状态定义标签；

<entry-action class＝″com.huawei.isap.test.ByeProcessor″

method＝″process″>//entry-action为进入动作的标签

<param name＝″bye″value＝″#{application.currentrequest}″/>//参数名称标签

</entry-action>

<transition to＝″respondRes″/>//transition为跳转标签

<！--当动作执行出现异常的时候，可以根据异常的类型跳转到相应的状态进行处理-->

<transition on-exception＝″java.lang.Exception″to＝″end-state″/>//transition为跳转标签

</state>

<state id＝″respondRes″>//state为状态定义标签；

<entry-action class＝″com.huawei.isap.test.ResResponder″

method＝″process″>//entry-action为进入动作的标签

<param name＝″bye″value＝″#{application.lastrequest}″/>//参数名称标签

</entry-action>

<transition to＝″endstate″/>//transition为跳转标签

</state>

<end-state id＝″endstate″/>//end-state为终止状态标签

</flow>

4)创建一个名称为Navigator.ssp的页面，然后在该页面中描述调度状态机。如下所示：

<！--一个SIP应用配置，id为这个应用的名称，entry的值表示该应用的入口状态机。当收到消息时，会调用入口状态机来处理消息-->

<！--引入inviteFSM.ssp中的状态机定义-->

<include file＝″inviteFSM.ssp″/>//include为导入标签

<！--定义变量，这些变量会存入application域中-->

//var为用于定义变量的功能标签；

<！--新建一个状态机定义，该定义引用模板party-->

<flow id＝″xiaowang″template＝″party″>//template为模板标签

<！--为party模板中的变量(如$toUrl)赋值。-->

<set name＝″toUrl″value＝″#{application.toXiaowangUrl}″/>//set为赋值标签

<set name＝″FinalResponseProcessor″

value＝″com.huawei.isap.test.FinalResponseProcessorForXiaowang″/>

<set name＝″response″

value＝″#{application.finalresponseofxiaowang}″/>

</flow>

<！--新建一个状态机定义，该定义引用模板party-->

<set name＝″FinalResponseProcessor″

value＝″com.huawei.isap.test.FinalResponseProcessorForXiaoli″/>

</flow>//flow为流程标签

//set为赋值标签

<！--定义一个状态机模板，这里为navigator-->

<flow id＝″navigator″>//flow为流程标签

<start-state ref＝″sendReqToxiaowang″/>//start-state为开始状态标签

<state id＝″sendReqToxiaowang″>//state为状态定义标签

<entry-action>//entry-action为进入动作标签

<executor flowid＝″xiaowang″/>//功能标签

</entry-action>

<transition on＝″#{application.currentresponse.code}&lt；200″

to＝″recvIntermediateResFromXiaowang″/>

//transition为跳转标签

<transition on＝″#{application.currentresponse.code}&gt；＝200″

to＝″recvFinalResFromXiaowang″/>

</state>

<entry-action>

</entry-action>

<transition on＝″#{application.response.code}&lt；200″

to＝″recvIntermediateResFromXiaowang″/>

<transition on＝″#{application.response.code}&gt；＝200″

to＝″recvFinalResFromXiaowang″/>

</state>

<entry-action>

</entry-action>

<transition on＝″#{application.response.code}&gt；＝200″

to＝″recvFinalResFromXiaoli″/>

<transition on＝″#{application.response.code}&lt；200″

to＝″recvIntermediateResFromXiaoli″/>

</state>

<entry-action>

</entry-action>

<transition on＝″#{application.response.code}&lt；200″

to＝″recvIntermediateResFromXiaoli″/>

<transition on＝″#{application.response.code}&gt；＝200″

to＝″recvFinalResFromXiaoli″/>

</state>

<entry-action>

<executor flowid＝″xiaoli″/>//功能标签

</entry-action>

<transition on＝″#{application.request.method}＝＝′bye′″

to＝″recvBye″/>//transition为跳转标签

</state>

<entry-action>

<if test＝″#{application.request.uri.user}＝＝′xiaowang′″>//功能函数

<setvar name＝″byeToUrl″

value＝″#{application.toXiaoliUrl}″scope＝″application″/>

<executor flowid＝″recvBye″/>//功能标签

</if>

<if test＝″#{application.request.uri.user}＝＝′xiaoli′″>//功能函数

<setvar name＝″byeToUrl″

value＝″#{application.toXiaowangUrl}″scope＝″application″/>

//set为赋值标签

</if>

</entry-action>

<transition on＝″#{application.response.code}&gt；＝200″

to＝″recvFinalR es″/>

</state>

<state id＝″recvFinalRes″>//state为状态定义标签

<entry-action>//进入动作标签

<executor flowid＝″sendBye″/>//功能标签

<executor flowid＝″recvBye″/>//功能标签

</entry-action>

<transition to＝″end″/>//transition为跳转标签

</state>

<end-state id＝″end″/>//end-state为终止状态标签

</flow>

</app>

至此，就完成了ssp文件的开发；

另外，还需要在SIP Servlet应用的部署描述符sip.xml中配置该ssp以及映射规则，配置方法如下所示：

<sip-app>

<app-name>multipartycall</app-name>

<display-name>multipartycall</display-name>

<！--配置一个ssp文件-->

<ssp>

<！--为ssp文件指定一个名称-->

<ssp-name>multipartycall</ssp-name>

<！--指定该ssp文件的路径-->

<ssp-path>Navigator.ssp</ssp-path>

</ssp>

<！--指定ssp文件的映射规则，该规则定义形式与SIP Servlet的映射形式定义一致。请参考JSR116规范。本例中的映射规则为：对request中uri的user字段的内容进行匹配，对于user字段为xiaowang或xiaoli的SIP消息，通过名为multipartycall的ssp进行处理。-->

<ssp-mapping>

<ssp-name>multipartycall</ssp-name>

<and>

<equal>

<var>request.uri.user</var>

<value>xiaowang</value>

</equal>

<equal>

<var>request.uri.user</var>

<value>xiaoli</value>

</equal>

</and>

</pattern>

</ssp-mapping>

</sip-app>

根据上面的配置，ssp可以放于SIP Servlet应用的根目录下，如图10所示。部署描述符中的<ssp-path>配置应该反映真实的SSP文件的路径。把该SIP Servlet应用打包成sar文件部署到SIP Servlet容器中后，当容器启动时会部署该应用。部署该应用的时候，如果容器发现部署描述符中配置了SSP文件，则将该文件编译成Sip Servlet程序。该部署过程参考上述步骤s301～步骤s309，在此不作重复描述。部署完毕后，可以使用该应用进行SIP消息的处理。当收到SIP消息时，应用程序按照SSP文件中描述定义的流程，在不同的状态机定义的不同的状态中进行跳转，并进行相应的消息处理。

本发明实施例提供的上述方案中通过SSP技术，在Sip Servlet技术的基础上，进一步简化了基于SIP的业务的开发。

进一步的，开发者可以使用标签来描述SIP会话业务，并在SSP中描述业务逻辑而不用写SIP Servlet程序，SIP Servlet容器会自动将SSP编译成SIP Servlet程序，而消息和业务处理逻辑之间的映射关系由Sip Servlet容器维护，简化了SIP Servlet应用的开发，大大减轻了开发工作量。

SSP技术包括能够用标签来描述SIP会话应用，应用包括的会话流程，流程中间的各种状态，状态之间的跳转，进入或离开状态发生的动作等。SSP技术不仅提供了常用的功能标签，使得描述业务逻辑成为可能，还提供了自定义标签和定义流程模板的标签，使得一些常用的可复用的业务逻辑能以标签的形式复用和流程定义可以复用。SSP还可以直接作为SIP Servlet应用的一部分直接部署在SIP Servlet容器上，部署简单，灵活。

本发明的实施例还提供一种通信系统，如图11所示，包括SIPServlet容器10，SIP Servlet容器10进一步包括部署单元11和缓存单元12，

部署单元11用于在所述SIP Servlet容器10启动时，读取并解析SIP应用的部署描述符，所述SIP应用的部署描述符中包括SSP的部署信息；在解析所述SIP应用的部署描述符的过程中，确定遇到SSP的部署信息时，根据所述SSP的部署信息将相应的SSP部署到缓存单元12中。当部署单元11根据SSP的部署信息判断需要在SIP Servlet容器启动时就装载SSP时，将所述SSP实例化后存储到所述缓存单元12中；否则将SSP部署信息存储到容器中。

该通信系统还包括：存储单元20，用于存储SIP应用的部署描述符并提供给所述SIP Servlet容器中的部署单元。此时部署单元11为第一部署单元，用于在所述SIP Servlet容器启动时，从所述存储单元20读取SIP应用的部署描述符并解析所述SIP应用的部署描述符，所述SIP应用的部署描述符中包括SSP的部署信息；在解析所述SIP应用的部署描述符的过程中，遇到SSP的部署信息时，根据所述SSP的部署信息将相应的SSP装载到所述缓存单元中。

所述通信系统还包括：SSP编译单元30，用于当所述部署单元11判断需要在SIP Servlet容器启动时就装载SSP时，将所述SSP编译为SIP Servlet Java文件；

Java编译单元40，用于将所述SSP编译单元30编译得到的SIPServlet Java文件编译成SIP Servlet字节码文件；

类装载单元50，用于装载所述Java编译单元40得到的SIP Servlet字节码，并实例化所述字节码代表的类，所述缓存单元用于将得到的实例存储。

其中，上述的通信系统可以为部署设备，该部署设备包括SIPServlet容器，该SIP Servlet容器包括部署单元和缓存单元，该SIPServlet容器、部署单元以及缓存单元的功能及连接关系与上述阐述一致，这里不再阐述。更进一步，该部署设备还可以包括SSP编译单元、Java编译单元、以及类装载单元，其功能与连接关系与上述一致，这里也不再详述。

本发明的实施例还提供一种通信系统，如图12所示，包括SIPServlet容器60，所述SIP Servlet容器进一步包括处理单元61和用于存储有实例的缓存单元62；

具体的，处理单元61用于获取接收到的SIP消息中携带的信息；并根据所述信息以及预设的匹配规则，获取处理所述SIP消息所使用的SSP实例；由所述获取的SSP实例处理所述SIP消息。

该SIP Servlet容器60还包括：部署单元63，用于当所述处理单元61发现处理SIP消息所使用的SSP实例没有在所述缓存单元中时，将所述SSP的实例装载到所述缓存单元62中。

该通信系统还包括：

SSP编译单元70，用于当所述部署单元63判断需要装载处理SIP消息所使用的SSP时，将所述SSP编译为SIP Servlet Java文件；

Java编译单元80，用于将所述SSP编译单元70编译得到的SIPServlet Java文件编译成SIP Servlet字节码文件；

类装载单元90，用于装载所述Java编译单元80得到的SIP Servlet字节码，并实例化所述字节码代表的类，所述缓存单元62将得到的实例存储。

其中，图12中的通信系统可以为处理设备，该处理设备包括SIPServlet容器，所述SIP Servlet容器包括处理单元和缓存单元，该SIPServlet容器、处理单元以及缓存单元的功能与连接关系与上述参考图12的阐述一致，这里不再详述。更进一步，该SIP Servlet容器还可以包括部署单元，其功能与连接关系与上述描述一致，这里不再详述；更进一步，该处理设备还可以包括SSP编译单元、Java编译单元以及类装载单元，其功能与连接关系与上面阐述一致，这里不再详述。

本发明的实施例还提供一种应用服务器，用于接收到SIP消息时，获取所述SIP消息中携带的信息；根据所述信息，以及预设的匹配规则，获取处理所述SIP消息所使用的SSP实例并由所述获取的SSP实例处理所述SIP消息。如图13所示，包括SIP Servlet容器100，所述SIP Servlet容器进一步包括处理单元101、部署单元102和缓存单元103；

处理单元101用于获取接收到的SIP消息中携带的信息；并根据所述信息以及预设的匹配规则，获取处理所述SIP消息所使用的SSP实例；由所述获取的SSP实例处理所述SIP消息；

部署单元102，用于在所述SIP Servlet容器100启动时，根据SSP的部署信息将相应的SSP部署到缓存单元103。

该部署单元102具体可以为第二部署单元，用于在所述SIPServlet启动时，读取并解析SIP应用的部署描述符；在解析到SSP的部署信息时，根据SSP的部署信息确定需要在SIP Servlet容器启动时装载SSP时，将所述SSP实例化后存储到所述缓存单元中；否则将SSP部署信息存储到所述缓存单元中。

该部署单元102具体还可以为第三部署单元，用于当处理单元101发现处理SIP消息所使用的SSP实例没有在所述缓存单元中时，将所述SSP实例装载到缓存单元103中。该应用服务器还包括：

SSP编译单元200，用于当所述部署单元需要将SSP装载到缓存单元103时，将所述SSP编译为SIP Servlet Java文件；

Java编译单元300，用于将所述SSP编译单元200编译得到的SIP Servlet Java文件编译成SIP Servlet字节码文件；

类装载单元400，用于装载所述Java编译单元300得到的SIPServlet字节码，并实例化所述字节码代表的类，所述缓存单元103用于将得到的实例存储。

存储单元500，用于存储SIP应用的部署描述符并提供给所述SIPServlet容器中的部署单元102。此时部署单元102具体可以为第一部署单元，用于在SIP Servlet容器启动时，从存储单元500读取SIP应用的部署描述符并解析；在解析所述SIP应用的部署描述符的过程中，遇到SSP的部署信息时，根据所述SSP的部署信息将相应的SSP装载到缓存单元103中。

在本发明实施例中，通过SSP技术，在Sip Servlet技术的基础上，进一步简化了基于SIP的业务的开发。使得用户能够使用标签来描述SIP会话业务，而消息和业务处理逻辑之间的映射关系由Sip Servlet容器维护，大大减轻了开发工作量。SSP技术包括能够用标签来描述SIP会话应用，应用包括的会话流程，流程中间的各种状态，状态之间的跳转，进入或离开状态发生的动作等。SSP技术不仅提供了常用的功能标签，使得描述业务逻辑成为可能，还提供了自定义标签和定义流程模板的标签，使得一些常用的可复用的业务逻辑能以标签的形式复用和流程定义可以复用。开发者可以在SSP中描述业务逻辑而不用写SIP Servlet程序，SIP Servlet容器会自动将SSP编译成SIP Servlet程序，简化了SIP Servlet应用的开发。SSP还可以直接作为SIP Servlet应用的一部分直接部署在SIP Servlet容器上，部署简单，灵活。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：ROM、RAM、磁盘或光盘等。

以上对本发明实施例所提供的方法和相应的装置进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

以上公开的仅为本发明的几个具体实施例，但本发明并非局限于此，任何本领域的技术人员能思之的变化都应落入本发明保护范围。

Claims

1.一种部署方法，其特征在于，包括：

会话发起协议SIP Servlet容器启动时，读取SIP应用的部署描述符，其中，所述SIP应用的部署描述符中包括SIP服务端页面SSP的部署信息；

对所述SIP应用的部署描述符进行解析；

在解析到SSP的部署信息，根据所述SSP的部署信息对相应的SSP进行部署。

2.如权利要求1所述部署方法，其特征在于，在所述SIP应用的部署描述符中，所述SSP的部署信息包括：

SSP的名称、SSP文件的相对路径、SSP的映射信息、以及是否在SIP Servlet容器启动的时候加载所述SSP，其中的一种；或

SSP的名称、SSP文件的相对路径、SSP的映射信息、以及是否在SIP Servlet容器启动的时候加载所述SSP，其中的多种。

3.如权利要求2所述部署方法，其特征在于，所述根据SSP的部署信息对相应的SSP进行部署的步骤具体为：

判断是否在SIP Servlet容器启动时装载SSP；

当判断结果为是时，SIP Servlet容器装载所述SSP；否则将SSP的部署信息缓存。

4.如权利要求3所述部署方法，其特征在于，所述SIP Servlet容器装载SSP的步骤具体为：

调用SSP编译器将所述SSP编译为SIP Servlet Java文件；

调用Java编译器将所述SIP Servlet Java文件编译成SIP Servlet字节码文件；

调用类装载器装载所述字节码并实例化所述字节码代表的类，得到一个实例；

将所述实例化得到的实例缓存。

5.一种通信系统，其特征在于，所述通信系统包括SIP Servlet容器，所述SIP Servlet容器包括部署单元和缓存单元，

所述部署单元，用于在所述SIP Servlet容器启动时，读取并解析SIP应用的部署描述符，其中，所述SIP应用的部署描述符中包括SSP的部署信息；在解析到所述SSP的部署信息时，根据所述SSP的部署信息将相应的SSP装载到所述缓存单元中。

6.如权利要求5所述通信系统，其特征在于，所述通信系统还包括：

存储单元，用于存储SIP应用的部署描述符，所述SIP应用的部署描述符中包括SSP的部署信息；

所述部署单元为第一部署单元，用于在所述SIP Servlet容器启动时，从所述存储单元读取SIP应用的部署描述符并解析所述SIP应用的部署描述符；在解析到所述SSP的部署信息时，根据所述SSP的部署信息将相应的SSP装载到所述缓存单元中。

7.如权利要求5所述通信系统，其特征在于，

所述部署单元为第二部署单元，用于在所述SIP Servlet容器启动时，读取并解析SIP应用的部署描述符，所述SIP应用的部署描述符中包括SSP的部署信息；在解析到SSP的部署信息时，根据SSP的部署信息判断是否在启动时装载SSP，当确定需要在所述SIP Servlet容器启动时装载SSP时，将所述SSP实例化得到实例，并将所述实例存储到所述缓存单元中；否则将所述SSP的部署信息存储到所述缓存单元中。

8.如权利要求7所述通信系统，其特征在于，所述通信系统还包括：

SSP编译单元，用于在所述部署单元确定需要在所述SIP Servlet容器启动时就装载SSP时，将所述SSP编译为SIP Servlet Java文件；

Java编译单元，用于将所述SSP编译单元编译得到的SIP ServletJava文件编译成SIP Servlet字节码文件；

类装载单元，用于使用类装载器装载所述Java编译单元得到的SIP Servlet字节码，并实例化所述字节码代表的类得到实例；

所述缓存单元用于将所述实例存储。

9.一种SIP业务的处理方法，其特征在于，包括以下步骤：

接收SIP消息，所述SIP消息中携带有信息；

获取所述SIP消息中的信息；

根据所述SIP消息的信息以及预设的匹配规则，获取处理所述SIP消息所使用的SSP实例，具体包括：会话发起协议SIP Servlet容器在部署开发SSP时在SIP Servlet应用的部署描述符中配置SSP的部署信息；对所述SIP Servlet应用的部署描述符进行解析得到SSP的部署信息；根据获得的SSP部署信息中包含的SSP映射信息，确定与所述SIP消息中的信息对应的SSP名称；根据所述SSP名称从缓存中查找得到对应的SSP实例；或，根据获得的SSP部署信息中包含的SSP映射信息，确定与所述SIP消息中的信息对应的SSP名称；根据所述SSP名称从缓存中查找不到对应的实例并且确定该SIP消息由SSP处理时，将相应的SSP实例化得到实例，装载到缓存；

由所述获取的SSP实例处理所述SIP消息。

10.如权利要求9所述SIP业务的处理方法，其特征在于，所述SIP消息中的信息包括：SIP消息的发送方。

11.如权利要求9所述SIP业务的处理方法，其特征在于，所述将相应的SSP实例化得到实例，装载到缓存的步骤具体为：

调用SSP编译器将获得的SSP文件编译为SIP Servlet Java文件；

将所述实例化得到的实例缓存。

12.一种通信系统，其特征在于，所述通信系统包括SIP Servlet容器，所述SIP Servlet容器包括处理单元和用于存储有实例的缓存单元；

所述处理单元，用于接收SIP消息，获取所述SIP消息中的信息；并根据所述信息以及预设的匹配规则，获取处理所述SIP消息所使用的SSP实例；由所述获取的SSP实例处理所述SIP消息；

其中，根据所述信息以及预设的匹配规则，获取处理所述SIP消息所使用的SSP实例，具体包括：会话发起协议SIP Servlet容器在部署开发SSP时在SIP Servlet应用的部署描述符中配置SSP的部署信息；对所述SIP Servlet应用的部署描述符进行解析得到SSP的部署信息；根据获得的SSP部署信息中包含的SSP映射信息，确定与所述SIP消息中的信息对应的SSP名称；根据所述SSP名称从缓存中查找得到对应的SSP实例；或，根据获得的SSP部署信息中包含的SSP映射信息，确定与所述SIP消息中的信息对应的SSP名称；根据所述SSP名称从缓存中查找不到对应的实例并且确定该SIP消息由SSP处理时，将相应的SSP实例化得到实例，装载到缓存。

13.如权利要求12所述通信系统，其特征在于，所述处理单元具体为用于接收SIP消息并获取所述SIP消息中的信息；根据获得的SSP部署信息中的SSP映射信息确定与所述SIP消息中的信息对应的SSP名称，并根据所述SSP名称从缓存中获取对应的SSP实例，由所述SSP实例处理所述SIP消息的单元。

14.如权利要求12所述通信系统，其特征在于，所述SIP Servlet容器进一步包括：部署单元，用于当所述处理单元发现处理SIP消息所使用的SSP实例没有在所述缓存单元中时，将所述SSP的实例装载到所述缓存单元中；

所述处理单元具体为用于接收SIP消息并获取所述SIP消息中的信息；根据获得的SSP部署信息中的SSP映射信息确定与所述SIP消息中的信息对应的SSP名称，并根据所述SSP名称从缓存中查找不到对应的SSP实例并且确定该SIP消息由SSP处理时，由所述部署单元将所述SSP的实例装载到缓存单元，由所述SSP实例处理所述SIP消息的单元。

15.如权利要求14所述通信系统，其特征在于，所述通信系统进一步包括：

SSP编译单元，用于当所述部署单元需要装载SSP时，将所述SSP编译为SIP Servlet Java文件；

类装载单元，用于使用类装载器装载所述Java编译单元得到的SIP Servlet字节码，并实例化所述字节码代表的类得到实例，所述缓存单元用于将得到的实例存储。

16.一种应用服务器，其特征在于，包括SIP Servlet容器，所述SIP Servlet容器包括处理单元、部署单元和用于存储有实例的缓存单元；

所述处理单元，用于接收SIP消息，获取所述SIP消息中的信息；并根据所述SIP消息中的信息以及预设的匹配规则，获取处理所述SIP消息所使用的SSP实例；由所述获取的SSP实例处理所述SIP消息；

所述部署单元，用于根据SSP的部署信息将相应的SSP实例装载到所述缓存单元，所述SSP的部署信息为所述SIP Servlet容器在部署开发SSP时在SIP Servlet应用的部署描述符中配置的SSP的部署信息。

17.如权利要求16所述应用服务器，其特征在于，所述部署单元为第二部署单元，用于在所述SIP Servlet容器启动时，读取并解析SIP应用的部署描述符；在解析到SSP的部署信息时，根据SSP的部署信息判断是否需要在所述SIP Servlet容器启动时装载SSP，当确定需要在启动时装载SSP时，将所述SSP的实例装载到所述缓存单元中；否则将SSP部署信息存储到所述缓存单元中。

18.如权利要求16所述应用服务器，其特征在于，所述处理单元具体为用于接收SIP消息并获取所述SIP消息中的信息；根据获得的SSP部署信息中的SSP映射信息确定与所述SIP消息中的信息对应的SSP名称，并根据所述SSP名称从缓存中获取对应的SSP实例，由所述SSP实例处理所述SIP消息的单元；其中，所述获得的SSP部署信息为所述SIP Servlet容器在部署开发SSP时在SIP Servlet应用的部署描述符中配置的SSP的部署信息。

19.如权利要求16所述应用服务器，其特征在于，所述部署单元为第三部署单元，用于当所述处理单元发现处理SIP消息所使用的SSP实例没有在所述缓存单元中时，将所述SSP实例装载到所述缓存单元中；

20.如权利要求17或19所述应用服务器，其特征在于，所述应用服务器还包括：

21.如权利要求16所述应用服务器，其特征在于，所述应用服务器还包括：

存储单元，用于存储SIP应用的部署描述符；

所述部署单元为第一部署单元，用于在启动时，从所述存储单元读取SIP应用的部署描述符并解析所述SIP应用的部署描述符；在解析到SSP的部署信息时，根据所述SSP的部署信息将相应的SSP装载到所述缓存单元中。