IMS本身是一个基于SIP的体系在IP网络之上实现先进的IP业务和应用。IMS为业务的调用提供必要的 功能，该功能称为＂业务提供(ServiceProvision)"。一般来说IMS的业务提供应包含3个基本步骤：
1、定义可能提供的业务或业务集合；
2、当用户订购／修改签约关系时，以初始过滤规则的形式创建用户专有的业务数据；
3、根据到达的初始业务请求选择应用服务器。
其中第一步取决千运营商和业务提供商能够向用户提供什么样的业务，本章不作讨论。下面主要介绍其余两个步骤。
一、业务数据组织
每当用户获得一个IMS订购关系且其订购关系包含一些业务，或运营商将AS作为其IMS基础设施的一部分时，他们需要为用户创建业务专用的数据。
1.用户档案和业务档案
当IMS用户向运营商订购签约业务时，运营商为其分配一个用户档案(UserProfile),它包含了与某个用户相关的业务信息。IMS用户档案的总体结构如图13.3所示。
用户档案至少包含一个私有用户标识和一个业务档案(ServiceProfile)。业务档案是永久地存储在HSS中的用户专有信息的集合，包括公共标识、核心网业务授权和初始过滤规则3部分。
(1)公共标识
公共标识由那些与该业务档案相关联的公共用户标识(SIPURI或TELURL)构成。每个公共用户标识都包含一个相关的禁止指示(BarringIndication)标签，如果禁止指示被设置，S-CSCF将禁止此公共用户标识进入IMS服务（注册和注销除外）。
(2)核心网业务授权
核心网业务授权携带了媒体策略信息，通过这些媒体策略信息，运营商可定义不同的客户等级，比如金、银和铜。根据不同的签约级别，提供相应的媒体配置。比如，一个客户级别为铜的用户可能没有被授权使用视频。这种情况下，如果用户发起了一个包含视频流的会话，则当S-CSCF通过对预定媒体策略信息的评价后，将会拒绝此会话请求。
(3) )初始过滤规则(iFC,initialFilterCriteria)
初始过滤规则表示了业务触发信息，它描述何时使用特定AS来处理特定的业务（即如何根据到来的SIP消息选择特定的AS>。用户业务配置里的每个初始化过滤规则都有一个唯一的优先级标识（整数），当分配多个初始过滤规则时，S-CSCF 将按优先级别的高低顺序进行先后评估，即具有较大优先级数值的初始过滤规则将在有较小优先级数值的初始过滤规则之后被评估。
用户档案采用扩展标记语言(XML,eXtensibleMarkupLanguage)编码，存储在HSS中。当用户第一次注册时，S-CSCF将通过Cx接口下载全部或部分用户档案。当用户在网络中已注册，而HSS中的用户档案发生改变时，HSS也会通过Cx接口来更新S-CSCF中保留的用户档案。
2.过滤规则(FC,FilterCriteria)
过滤规则决定了提供给每个用户的业务，也是用户档案（以及业务档案）中最为重要的一部分。FC包括了用户相关的信息，可以协助S-CSCF决定是否需要转发SIP请求到应用服务器。当S-CSCF收到一条初始SIP请求时，它会一个一个地对FC进行匹配验证。如果SIP请求与FC匹配，S-CSCF就会将SIP请求转发到与该FC对应的应用服务器(SIPAS/IM-SSF/OSASCS)。IMS中的过滤规则包括两类：初始过滤规则(iFC)和后续过滤规则(sFC)。
iFC作为用户档案的一部分存储在HSS中，并通过Cx接口下发到S-CSCF。iFC只应用千初始SIP请求消息。比如，当S-CSCF收到最初的INVITE消息、SUBSCRIBE消息、MESSAGE消息、创建对话或发于对话之外的任何请求时，都会对初始过滤规则进行评估。当S-CSCF收到PACK、NOTIFY、UPDATE或BYE请求时，由于这些请求通常是作为己存在的SIP会话的一部分来发送的，S-CSCF不会对初始过滤规则进行评估。
与iFC不同的是，sFC是从SIPAS/OSASCS/IM-SSF下发到S-CSCF的过滤规则。当S-CSCF在SIP对话中收到后续请求时，可以基千sFC判断是否应进一步联系应用服务器。然而，采用后续过滤规则会导致S-CSCF转发后续SIP请求到应用服务器，这种行为是与SIP代理的路由规则相冲突的。另外，当应用服务器接收到后续请求时，它（很有可能）并没有收到创建SIP对话的初始SIP请求。因此，应用服务器会拒绝本次请求，并将其忽略，结果会是S-CSCF触发了后续过滤规则，但应用服务器并不执行。正是由于存在这些规则上的相互冲突，所以目前只有初始过滤规则在使用，后续过滤规则仍处千理论研究阶段。因此，在IMS中初始过滤规则与过滤规则的术语通常可以交换使用。IMS初始过滤规则的结构如图所示。
初始过滤规则的第一部分是优先级(Priority),主体部分则由0个或1个触发点以及一个应用服务器组成。
(1)优先级
优先级区域决定了对过滤规则进行评估的顺序。优先级采用整数表示，数值越小，代表优先级越高（也就是说，“优先级l"代表最高的优先级）。
为了让S-CSCF能够以正确的顺序依次处理过滤规则，每个过滤规则都必须分配一个优先级。S-CSCF从优先级最高的iFC开始处理，与最初匹配的iFC指定的应用服务器交互。如果联系不到过滤规则指定的应用服务器，S-CSCF将采用默认处理方法。默认的处理方法可以是：
• 继续验证是否有更低优先级的过滤规则与SIP请求匹配；
• 放弃对更低优先级的过滤规则的匹配，并释放对话。
针对一个特定用户，不能给一个以上的初始过滤规则分配相．同的优先级。
(2) )触发点(TP,TriggerPoint)
触发点描述了是否启用与之关联的应用服务器的条件。如果不存在触发点，则表明将对应用服务器进行无条件触发。
每个触发点都包含一个或多个业务点触发器(SPT,ServicePointTrigger),并用逻辑运算符与、或、非(AND、OR、NOT)等联结起来。因此，触发点在形式上是一个布尔表达式，是若干独立过滤规则的逻辑集合，这些过滤规则就称为业务点触发器。业务点触发器可以是：
• 任何已知或未知的SIP初始化方法（如INVITE,MESSAGE等）。
• 注册类型（即Register请求是初始注册、重新注册，还是注销注册）。
• 在SIP消息中出现或缺失任何已知或未知的头域。
• 任何已知或未知头域的内容或Request-URI。内容的值是一个字符串，可用一个正则表达式来表示。
• 会话情形，即相对于业务用户来说的SIP请求的主被叫方向。对于注册用户，可以是去话(UE-originating)或来话(DE-terminating);对千未注册用户，一般会是来话，也有可能是去话（在紧急呼叫的情况下）。去话情形是指S-CSCF当前正在服务的是会话发起侧的UE,来话情形是指S-CSCF当前正在服务的是会话终止侧的UE。
• 会话描述信息，定义针对SIP方法体内的任何SDP字段内容的业务点触发器。举例来说，一个匹配所有到用户A的会话发起请求的触发点可以如下表达：CMethod=INVITE)AND(Request-URI=sip:userA@bupt.edu.en)在这个例子中，该触发点包含两个业务点触发器，其中之一是"Method=INVITE",另一个是"Request-URI=sip:userA@bupt.edu.en"。
(3)应用服务器(AS)
应有服务器定义当触发点匹配时应该启用哪一个特定的应用服务器。应用服务器的地址用SIPURI标识。应用服务器部分包含了零或一条业务信息。业务信息是一些透明的数据（对HSS和S-CSCF而言是透明的），它不能被HSS和S-CSCF处理。业务信息是iFC中可选的部分。如果它出现在iFC中，S-CSCF将把它包含在SIP请求的消息体内发往该iFC所指定的应用服务器，但是这种行为在标准的SIP代理机制中是不允许发生的，因此使用这条业务信息的唯一可能是：触发市C的S-CSCF充当UAC的角色，向应用服务器发送一个第三方Register请求，业务信息才可能被包含在其中（如果应用服务器需要的话）。
二、 业务触发结构
IMS业务的提供模式可以概括为：用户终端（发送请求到)-S-CSCF(触发业务到）AS(处理业务并返回处理结果）。从业务提供的角度，S-CSCF提供业务接入功能，识别业务呼叫，请求应用服务器中相关业务逻辑支持。其中核心的环节就是业务在S-CSCF中的触发机制。图13.5是IMS体系中业务触发的总体结构。从图中可以看到，IMS会话首先在S-CSCF中通过SPT处理，然后经过S-CSCF中过滤规则的匹配，最后转发到应用服务器处理。
前面提到，S-CSCF中的过滤规则来源有两个：从HSS下载的iFC,以及来自于AS的sFC。由千存在路由机制上的冲突，在IMS中目前唯一应用的过滤规则就是iFC。因此，S-CSCF仅向HSS请求并获取用户所有的iFC集合。
当用户向S-CSCF注册时，或者当S-CSCF收到一个来话初始请求（即被叫侧会话请求），而且本地又没有这个被叫用户的有效iFC时，S-CSCF就会从HSS下载用户的iFC。iFC在用户的整个注册生命周期内或者在用户档案被更改之前都是有效的。如果sCSCF已经有合法的iFC集合（例如，来自上一次对HSS的请求），S-CSCF就不需要请求一个新的iFC集合了。
2.业务触发流程
(1)对Register消息的处理
当S-CSCF接收到Register请求时，在用户注册成功之后从HSS下载iFC。如果从HSS获取的iFC中有和Register方法匹配的，则S-CSCF发送一个第三方Register请求到这个FC指定的应用服务器。第三方Register请求的目的不是让用户再去AS注册，而是告诉AS,用户已在S-CSCF注册过，AS可以从第三方Register请求中获取一些重要的用户业务数据。
(2)对其他SIP请求的处理
当接收到其他的任何请求（除了Register请求）时，S-CSCF应该按如下步骤处理。心检查公共用户标识是否被禁止，如果不是，则继续。A检查该请求是一个去话请求还是一个来话请求。B根据会话情形（注册终端去话、注册终端来话或未注册终端来话）选择初始过滤规则。C根据过滤规则的优先级为这个请求建立起对应的FC列表，在S-CSCF处理该请求期间，这一列表中FC的顺序不应被更改。D解析收到的请求，找出包含于其中的SPT。E检查SPT是否与未进行匹配的过滤规则中优先级最高的FC中的触发点相匹配，如果不匹配，S-CSCF应立即执行步骤(J);如果匹配，S-CSCF应该：
I.在该请求中增加一个标识，S-CSCF使用这一标识来关联接收到的消息（即关联最初收到的SIP请求和从AS返回的SIP请求），即使对话标识(DialogID)被更改（例如应用服务器执行三方通话控制时），S-CSCF也可以在接收时识别这个消息。
II.通过ISC接口转发该请求到当前FC中指定的AS。AS执行业务逻辑，可能对请求进行修改，并且可能将该请求通过ISC接口返回S-CSCF。
m.如果S-CSCF在ISC接口收到从AS返回的请求，执行步骤＠。
F重复上面的步骤＠和＠，直到最后一个FC被检查过为止。
G按照正常的SIP路由方式对该请求进行路由。
在S-CSCF对去话和来话请求的初始过滤规则的处理上，存在一个明显的区别。在来话情形下，当S-CSCF发现有一个AS已经更改了Request-URI时，则会停止检查，并基于更改过的Request-URI值来对该请求进行路由。而在去话情形下，S-CSCF将会继续评估初始过滤规则，直至所有初始过滤规则均被评估过为止。换句话说，在去话情形下，S-CSCF可以在一次请求的处理过程中多次触发不同的应用服务器。当然，如果应用服务器决定在本地终结收到的请求，并且通过ISC接口向S-CSCF返回对该请求的最终响应，S-SCF应该放弃对列表中剩余FC的匹配验证。最终的响应应该包含步骤＠中提及的标识，从而使S-CSCF可以将收到的最终响应和请求消息关联起来。
应用服务器在收到初始的SIP请求时会为了继续接收后续请求而生成或修改请求中Record-Route/Route头域。通过Record-Route/Route头域的设置，应用服务器／业务逻辑可以表明是否希望参与对会话中后续请求的处理（若希望就在Record-Route中加入自己的地址，若不希望就不加）。一旦应用服务器决定不接收会话的后续请求，就意味着在该会话生命周期中所有后续的请求都不会再被路由到这个应用服务器中。
如果所联系的AS没有响应，则S-CSCF遵从与初始过滤规则相关联的缺省处理过程，即基千过滤规则中的信息，或者终止会话，或者让会话继续。如果初始过滤规则没有包含在联系AS失败后S-CSCF如何操作的指令，则S-CSCF的默认行为是让呼叫继续。
三、 AS基本操作模式
当SIP请求由S-CSCF触发到AS后，AS可以使用4种基本操作模式（即来话用户代理模式、重定向服务器模式、SIP代理模式、第三方呼叫控制/B2BUA模式）对其进行处理。除了上述4种模式之外，AS还能充当去话用户代理(UA),主动向用户发送SIP请求。IMS业务可以基于这5种模式的组合来创建。应用服务器在它所管理的多媒体会话的生存周期内，可以从一个操作模式跃迁到另一个。
1.应用服务器充当来话UA,或者重定向服务器
应用服务器充当来话UA,或者重定向服务器的操作模式如图13.6所示。在这一操作模式中，S-CSCF将其接收的SIP请求转发到目的应用服务器，该应用服务器将执行UA或者是重定向服务器的角色。
该模式可用于提供语音信箱、呼叫前转、号码携带，或者将发起者重定向到某个特定的Web页面等业务。
2. 应用服务器充当去话UA
应用服务器充当去话UA的操作模式如图13.7所示。在这一操作模式中，应用服务器作为UA生成一个SIP请求，发送给S-CSCF,然后由S-CSCF将该请求路由到目的地。
该模式可以用于提供网络叫醒(Alarm)、Dialout会议业务等。例如，一个会议服务器可能在早上9点给一些预先确定的人们发送一条SIPINVITE请求，以建立一个会议呼叫。
3. 应用服务器充当SIP代理
应用服务器充当SIP代理的操作模式如图13.8所示。在这一操作模式下，S-CSCF将其接收的SIP请求转发到充当Proxy的应用服务器。应用服务器进行业务处理后将该SIP请求转发回S-CSCF,再由后者将请求转发到目的地。在充当Proxy模式过程中，应用服务器可以根据IETFRFC3261规定的代理规则添加、删除或修改SIP请求消息头中的内容。
4. 应用服务器作为第三方呼叫控制/B2BUA模式
AS可以充当B2BUA执行第三方呼叫控制。IMS定义了多种第三方呼叫控制模式，举例如下。
(1)路由B2BUA(RoutingB2BUA):AS收到来自S-CSCF的请求，终结该请求并且根据收到的请求生成一个新的请求，如图13.9所示。在这一操作模式下，接收到的SIP请求被S-CSCF转发到应用服务器，应用服务器会生成一个属千另一个对话的SIP请求，这个请求将被发送回S-CSCF,然后S-CSCF将它转发到目的地。在此模式下应用服务器对多个SIP对话(SIPDialog)表现为一个BZBUA。
(2)发起B2BUA<InitiatingB2BUA):AS主动发起两个SIP请求，并在逻辑上将它们连接在一起，如图13.10所示。在此模式下，应用服务器生成属千不同SIP对话的两条请求，并在这两个对话之间进行关联。这两条SIP请求通过S-CSCF转发到目的地。在这一模式下，应用服务器对多个SIP对话表现为一个B2BUA。
5.应用服务器不参与或不再参与会话
无应用服务器参与的SIP会话的操作模式如图所示。
在这一模式下，应用服务器或者是从来没有参与SIP会话请求，或者不再参与会话后续处理。接收的SIP请求由S-CSCF转发到目的地。应用服务器可以通过在RecordRoute头域中加入自己的标识从而一直保持在SIP会话控制的信令路径上。如果应用服务器没有将自己插入Record-Route的头域中，这个SIP对话相关的所有后续请求处理上都属于这个模式。
四、IMS业务执行例子
为了让读者对上述IMS的业务提供原理有一个更清楚的认识，下面以一个具体的例子来阐明业务的过滤规则制定、业务逻辑触发以及业务执行的过程。假设某用户A(其私有用户标识为private_userA@university.edu,公共用户标识为sip:userA@university.edu)申请了一个黑名单业务，若呼叫发起者被用户A列在黑名单之中（例如sip:badguy@company.com),业务会自动将主叫用户连接到自动应答设备（语音服务器）。
1.用户档案的创建
假设用户A只定制了这一个业务，那么其XML编码的用户档案就会如图所示。
在本例中，应用千sip,userA@university.edu的业务档案包含了初始过滤规则（为行文方便，下面将其称为iFCX),并且过滤规则包含TriggerPoint字段，可将列在黑名单中的用户发出的INVITE请求滤出。触发点如图所示。
如果条件满足，S-CSCF会将本次请求发送给SIPURI为asl@university.edu的应用服务器。应用服务器执行黑名单业务逻辑，可以向MRFC转发呼叫请求，并指导MRFC播放预先录制的提示音。
2.业务触发流程
假定用户A已完成IMS注册，iFC以及被指派给AS的地址已经下载到相应的S-CSCF中，而且AS指定的数据也在注册时通过Sh接口下载到AS中。图13.14是iFC触发流程的示意图。
当一个被列入黑名单的用户(SIP:badguy@company.com)发起到用户A的呼叫时，在用户A归属的S-CSCF中业务触发流程如下。
(1)S-CS CF接收到一个初始会话请求，检查其中包含的公共用户标识（即SIP:userA@university.edu)是否被禁止，并检查这是一个去话请求还是一个来话请求。S-CSCF判断接收到的请求属于注册用户OE-terminating请求，将iFC应用于该会话情景，评估SPT并检查它们是否匹配当前用户最高优先级的iFCX。
(2)S-CSCF发现这一请求与iFCX匹配，将该请求转发到iFCX指定的应用服务器ASl(SIP:asl@university.edu)。
(3)AS1通过内部接口功能接收到初始会话请求，根据业务键执行必要的业务逻辑，修改请求（将Request-URI修改为MRFC的URD并发送回S-CSCF。这里AS充当了SIP代理，把自己的URI插入到Record-Route头域中。
(4)S-CSCF接收到AS1返回的SIP请求，发现其Request-URI被更改，停止检查其他的iFC,并根据路由决策将请求转发至下一跳(MRFC)。
3.业务执行流程
下图描述了该业务的具体操作流程。
下图描述了该业务的具体操作流程。
BadGuy发送了一条到用户A的INVITE请求心，该请求最终被路由到为用户A服务的S-CSCF@。S-CSCF判断该呼叫是一个到用户A的来话呼叫，检测其中的SPT,并与用户A业务档案中所有的过滤规则进行匹配。在这个例子中，只有一条过滤规则指导S-CSCF将BadGuy发出的INVITE请求发送给SIP:asl@university.edu。S-CSCF在INVITE中插入双路由报头，一个值是AS的SIPURICasl@university.edu),另一个是其自身的SIPURI,随后S-CSCF将INVITE请求＠传递给该AS。AS接收到INVITE请求并执行这项业务。在这个例子中，执行这项业务意味着将请求路由到一个新的目的地，也就是MRFC。因此，AS作为SIP代理，使用MRFC的SIPURI值sip:announcementBadGuy@mrfc.university.edu(其中＠前的"announcementBadGuy"用千指示MRFC播放哪一个提示音）替换INVITE请求的Request-URI,然后将INVITE请求发送给S-CSCF@。再次收到INVITE请求后，S-CSCF检测到Request-URI与先前接收的INVITE请求有所改变，然后它会把这条请求向前发送到新的目的地MRFC@。MRFC检查Request-URI决定播放哪一条提示音，在本例子中就是announcementBadGuy对应的提示音。最后MRFC向起始点回发一条200OK响应＠，然后向MRFP发送一条H.248命令来播放已存储的提示音。MRFP利用SDP中协商的编解码器播放提示音。
在这个例子中，应用服务器的任务还相对简单。在实际的生活场景中，应用服务器执行的任务要复杂得多。例如，应用服务器可以提供一个HTTP的管理接口CUt接口），使用户可以登录到应用服务器上来管理他们的黑名单。每次用户向他的黑名单中增加或删除要屏蔽的公共用户标识时，应用服务器通过Sh接口将它们回送给HSS。HSS再将更新后的用户档案（包含新的过滤规则）下发给S-CSCF,这样S-CSCF就会实时地应用新业务配置。
