SIP协议由于具有较高的通用性和可靠性，以及具有在节点间进行会话建立、管理、拆除的功能，所以它被推荐为呼叫控制实体与应用服务器之间的接口协议。除此之外，SIP协议也可用于各个应用服务器之间的接口。这样，应用服务器之间就可以交互，使得两个或多个增值业务可以存放在不同连接的应用服务器中。
一、 应用服务器与软交换设备的交互
SIP应用服务器与软交换设备之间使用SIP协议进行通信。软交换设备可以通过注册机制得知应用服务器的存在，也可以通过在软交换设备上配置应用服务器的地址信息，静态得知应用服务器的存在。软交换设备可以主动建立和取消至应用服务器的呼叫，同样，应用服务器也能主动建立和取消至软交换设备的呼叫，并且应用服务器还具有转换主叫和被叫方信息、保持和恢复连接的功能。基本的SIP协议功能和扩展的呼叫控制功能结合在一起，可使应用服务器进入所有的呼叫控制活动并能传送、重定向和代理呼叫。图5.4说明了SIP应用服务器在实现各种增值业务时控制流的流程。
软交换与应用服务器之间的控制流
根据业务提供所需控制能力的不同，软交换设备和应用服务器间控制流交互的一般流程如下。
1、软交换设备决定是否将呼叫切换至应用服务器进行增值业务处理。触发可基于主叫方地址、被叫方地址或其他的业务触发机制。
2、软交换设备根据触发信息确定应用服务器的地址，并通过发送SIP请求信息（包括适当的呼叫信息）将呼叫转至目标应用服务器。
3、目标应用服务器接收到SIP请求之后，调用相应的增值业务逻辑。为了实现这一功能，应用服务器可进行不同的动作。
• 重定向，应用服务器向软交换设备发送一个新的目的地址，重定向该呼叫（重定向响应中包含新的目的地址）。这种机制可用于面向地址转换和路由的业务。
• 接收和传送，分配媒体资源，命令软交换设备将至媒体资源的路径连接好（用200
OK响应表示）。用户与媒体资源的交互结束以后，应用服务器可将呼叫传至新的目的地，并退出呼叫(BYE的头中包含有新的目的地址）。这种机制可用于面向媒体的业务，如卡类业务和传真存储／转发业务。
• 代理，通过软交换设备将呼叫返回，使得应用服务器可以监视所有的并发呼叫事件。此机制可用于面向事件的业务，如记账卡和计时业务。
二、 应用服务器之间的交互
由于SIP协议的通用性和灵活性，SIP应用服务器之间也可以使用SIP协议进行通信，互相交互信息，这样可以将两个或多个位于不同应用服务器上的业务联系起来，向用户提供一个组合的业务解决方案。SIP应用服务器间的功能交互示意图如下图所示。
应用服务器之间的功能交互
随着SIP应用服务器可以实现对其他SIP应用服务器的控制，相应地就需要引入管理SIP应用服务器之间功能交互的机制，以解决业务之间可能存在的属性冲突问题，这对日益增多的增值业务入网很重要。
属性冲突可以由软交换设备自行管理，如下图所示：
也可通过将呼叫控制权转移到一个应用服务器，把复杂、耗时的功能交互管理功能分派给该应用服务器，由应用服务器自己来管理与其他应用服务器的交互，如下图所示。
三、 SIP应用服务器与媒体服务器的交互
SIP是用于创建、修改和终止呼叫的应用层信令协议。一般而言，SIP应用服务器可以涉及呼叫的控制方面，但不能对媒体资源进行处理，而媒体服务器可以提供这方面的功能。通过媒体服务器与应用服务器的配合（应用服务器处理呼叫的信令流，而媒体服务器负责处理媒体流），就可以支持那些需要控制媒体流的业务，如IVR、会议、传真、媒体混合等。当然，如果业务不需要对媒体流的控制功能，如编号转换、转发、路由相关业务等，那么这些业务仅用SIP应用服务器就能支持。
SIP应用服务器与媒体服务器的基本配合方式有两种：一种是采取内置的方法，将
SIP应用服务器和媒体服务器在物理上合二为一 ，两者之间采用内部接口；另一种方式是
SIP应用服务器和媒体服务器各自独立实现，两者之间的接口也采用SIP协议，如图所示。
应用服务器与媒体服务器之间的通信
需要注意的是，如果应用服务器通过SIP协议控制媒体服务器，SIP协议工作在客户／服务器标准模式，而不是对等模式。此时应用服务器利用第三方呼叫控制来控制媒体服务器，媒体服务器被动地等待软交换设备或应用服务器的"INVITE"消息，并且产生自身的非"INVITE"消息。
四、 SIP应用服务器模式存在的问题分析
1、SIP协议的业务扩展
目前SIP协议的基本功能已经稳定，但由于SIP的简单性，在与传统网络互通和业务实现方面还存在一些问题。通过标准的SIP协议只能实现一些相对简单的增值业务（如路由类业务等），对于复杂的增值业务则需要对SIP协议进行扩充，这就很难保证其标准化。目前针对不同的增值业务对SIP协议进行扩展的方式很多，这也造成了SIP业务互通的困难。在前文中已经提及，IETFMMUSIC工作组正针对SIP协议进行业务能力扩展，其目标是希望能够创建一些独立于具体业务的积木式构成块，通过这些业务构成块可以构建更多特殊的应用，满足一些特殊领域的需求，这非常类似于智能网中的SIB(ServiceIn¬dependentBlock,独立于业务的构件）概念。增加SIP扩展的指导方针应是尽量减少在SIP中增加太多的组件，而通过利用现有的各种协议资源完成更多的功能。
2、协议兼容性问题
众所周知，SIP协议的灵活扩充性使其至今仍是相对不成熟的协议，因而仍面临着通常的互操作性挑战。SIP协议几易其稿，其中涉及的功能繁多，大部分开发商仍只能实现其功能子集。其结果是，选择SIP意味着互操作问题。
SIP协议灵活性的特点决定了不同的厂商在开发SIP应用服务器时会采用许多个性化的实现方式。SIP应用服务器”核心”功能实现方式各异，在具体实现过程中必然带来组网条件和特定功能实现问题。如此一来，产品间的差别越来越大，互操作问题愈发突出。即使是SIP协议解决了互操作问题，并且各厂商完全按标准实现，但要达到目前智能网业务提供能力的水平也不是一朝一夕的事。对SIP来说，要完全实现大范围内业务功能的集中式管理还有很大难度。
3、B2BUA与Proxy之争
对于SIP应用服务器应当采用Proxy还是B2BUA,不同厂家存在不同的产品实现。可以说它们代表了两种基本的业务提供思想。作为电信领域和互联网领域的两大标准组织，IETF以自由的思想引领着Internet的潮流走向，这也是Internet在短短几年得到迅猛发展的原因；与此形成鲜明对比的是，ITU则以严谨、谨慎的态度看待通信技术，因此ITU制定的标准，以严谨、可操作性著称，但却招致保守的批评。
IETF在提出SIP协议(RFC3261)时，认为终端智能化是未来发展的趋势，因此未来的协议也应当是端到端的协议，而SIP恰恰能够满足这个要求。在RFC3261看来，通过Proxy这样一个实体打造的网络，业务功能由终端实现，因此不存在像目前PSTN对交换机不断进行升级的需求。按道理，这样一个思路恰恰应当迎合运营商的需求才是。但不要忘了，Proxy的实现机理仅仅是简单处理和转发消息，只要消息语法正确，就不会拒绝，除非在功能上对设备进行规范。
而将任何业务都集中在终端，这是ITU思想里所不能容忍的。ITU认为，一个电信级的网络，应当是一个可运营、可管理的网络，虽然终端智能化代表未来的方向，但网络设备仍然需要可控性。因此网络层面的设备，不应仅仅完成消息的转发功能。从这个角度看，B2BUA似乎更适合电信运营的要求。但UA的特性决定了一旦有新的业务需求时，就会存在对网络设备升级的需求，这是B2BUA本身存在的难以解决的问题。
4、业务智能的分布性
由于SIP是端到端的对等呼叫信令协议，就某个业务的实现而言，可能需要SIP应用服务器与终端的配合，但对大多数业务而言，可以直接在SIP终端上实现。SIP终端完全秉承了SIP协议的特性，因此在实现个性化业务方面更具有优势。例如像一些重定向业务、修改会话的业务、即时消息业务都可通过SIP终端来实现。这种模式有助于实现网络智能的分布，符合NGN的发展趋势，是SIP业务体系的一个优势。
但是在多种协议并存的软交换网络中，通过SIP终端来实现原有PSTN网络所具有的窄带业务，就显得有些困难，比如操作模式上的困难。原有PSTN终端在实现补充业务时，终端可通过"*"、"#"方式来实现业务的激活，然后由网络启动某类补充业务。但目前的SIP终端并不支持该种操作（没有相应的规范，而且看起来也没有必要），因此在业务启动方面，SIP终端需要与现有的Web方式（通过网页登记的方式）相结合，这与目前的操作方式不同。
另一方面，业务智能在用户终端上的分布也带来了业务管理的困难以及业务安全的隐患。由于SIP终端具有较强的智能性，用户可能会基于SIP终端的恶意扩展能力旁路运营商核心网络设备的监控实现对业务的盗用，或者通过对SIP业务能力的恶意扩展实现对运营商网络的攻击。因此，关键是如何对SIP终端进行定位。SIP终端在一定程度上代表了未来终端的发展方向，但业务智能在SIP终端上的分布与管理方式是SIP业务体系中必须要解决的关键问题。
