IMS网络中实现合法监听的方法、装置及应用服务器与流程

本发明涉及通信技术领域，特别是涉及一种IMS网络中实现合法监听的方法、装置及应用服务器。

背景技术：

IP多媒体子系统多媒体子系统IMS(IP Multimedia Subsystem)是第三代合作伙伴计划(The 3rd Generation Partner Project，简称3GPP)提出的IP多媒体业务的子系统。IMS采用了独立于接入技术的体系架构，具有如下技术特点：基于会话初始协议(Session Initiation Protocol，简称SIP)的会话控制，与接入无关，业务与控制分离，提供丰富的组合业务等。其中业务与控制分离的特点主要体现在它们分别由应用服务器(Application Server，简称AS)和呼叫会话控制功能(Call Session Control Function，简称CSCF)两个网元来实现。SIP AS是一种基于SIP协议的应用服务器，提供广泛的增值多媒体业务、呈现、消息和会议业务。

图1是根据相关技术的IMS网络中一次典型的呼叫流程图，如图1所示，呼叫请求消息被送到服务-呼叫会话功能实体(Serving CSCF，简称S-CSCF)后，S-CSCF根据初始过滤规则(Initial Filter Criteria，简称iFC)，将起呼(Mobile Origination，简称MO)阶段或终呼(Mobile Termination，简称MT)阶段的业务请求分别触发到相应的AS，AS实施相应阶段的业务逻辑后将业务请求环回到S-CSCF，由S-CSCF继续呼叫处理过程。根据所处理的业务的不同，AS从逻辑上可以分为主叫AS(Originating Application Server，简称O-AS)和被叫AS(Terminating Application Server，简称T-AS)，其中O-AS处理主叫侧业务， 由S-CSCF在MO阶段触发；而T-AS处理被叫侧业务，由S-CSCF在MT阶段触发。

在IMS中，由于不同的终端或者网元采用的编解码格式(简称：编解码)不同，因此有可能呼叫双方媒体协商不成功，导致呼叫失败。例如固网用户一般支持G.711，而在CDMA2000网络中，移动终端一般支持EVRC，这两个用户呼叫时由于支持的编解码格式不同，因此呼叫会失败。对此需要有网元来进行编解码转换(TransCoding，简称TC)。TransCoding在3GPP的TS23.228(8.8.0)的5.14.4以及Annex P中进行了定义，采用了多媒体资源功能实体(Multimdia Resource Function，简称MRF)来完成，其方式分为预先TransCoding以及媒体协商失败后TransCoding。

图2是根据相关技术的3GPP中定义的预先TransCoding的流程图，如图2所示，IMS系统检测到主被叫编码不同，需要进行TransCoding时，控制MRF准备2份媒体，其中一份媒体的对端媒体为主叫用户A的媒体描述信息SDP_A，媒体的编解码格式为主叫用户A支持的格式(codec-A)，另一份媒体支持的编解码格式为被叫支持的编解码格式(codec-B),系统使用MRF准备的两份媒体分别完成与主被叫的媒体协商。由于MRF上这两个媒体是连接的且可以进行TransCoding的即两者是可以互通的。因此经过MRF网元TransCoding后，主被叫通话可以建立。这种使用了编解码转换建立的呼叫，叫做编解码转换呼叫。

媒体协商失败后TransCoding的过程是：呼叫经过主叫侧网络的处理和被叫侧网络处理后，请求消息被发到被叫用户后，被叫用户不支持主叫侧给出的编解码格式回异常响应消息488或者606，表明主叫侧的媒体编解码格式不被被叫侧所接受。IMS系统根据被叫用户给出的异常响应消息判断出呼叫需要进行TransCoding，其后续流程与预先TransCoding的流程相同。

所谓合法监听(LI，Lawful Interception)是在经相应的授权机关批准的前提下，由执法机构(LEA，Law Enforcement Agency)向网络运营商(NWO，Net Work Operator)/接入提供商(AP，Access Provider)/服务提供商(SvP， Service Provider)发出监听请求命令，由NWO/AP/SvP将被监听对象的相关信息进行复制并发送给LEA的一项信息安全技术。在协助执法机构打击犯罪方面，合法监听起着极其重要的作用，是网络和信息安全的重要课题。

图3是根据相关技术的一种实现对应用服务器合法监听的架构图，如图3所示，IMS网络中对应用服务器的监听，一般采用符合3GPP欧洲电信标准化组织(European Telecommunication Standards Institute，简称ETSI)监听协议的网络架构。在此架构中，运营商(NWO/AP/SvP Domain)与监听中心(LEA Domain)之间的提交接口(Handover Interfacer，简称HI)分为HI1，HI2以及HI3：HI1接口传递监控对象设置、取消、查询等相关指令；HI2接口传递监控对象的通讯相关事件(Intercept Related Information；简称IRI)信息；HI3接口传递通讯内容(Content of Communication，简称CC)，包括信令和媒体。在运营商(NWO/AP/SvP Domain)内部，与HI接口对应的是X1、X2、X3接口。X1和X2接口位于应用服务器和合法监听网关(Lawful Interception Gateway，简称LIG)之间；X3的信令接口位于应用服务器和媒体网关控制功能实体之间；X3的媒体接口位于监听媒体资源处理器和提交功能网关之间。

随着用户对多媒体通讯越来越多的使用，通讯终端类型和编解码格式更加的丰富，终端间的通讯越来越多的需要编解码转换，因此这一技术的应用正日益广泛。在编解码转换呼叫中，如何对主被叫的媒体进行转发、复制和传递从而实现合法监听成为一个难题。

针对当前编解码转换呼叫方案中，如何对主被叫的媒体进行转发、复制和传递从而实现合法监听的问题，目前尚未提出有效的解决方案。

技术实现要素：

针对当前编解码转换呼叫方案中，如何对主被叫的媒体进行转发、复制和传递从而实现合法监听的问题，本发明提供了一种IMS网络中实现合法监听的方法、装置及应用服务器，用以解决上述技术问题。

根据本发明的一个方面，本发明提供了一种IMS网络中实现合法监听的方法，应用于应用服务器AS管理实体，其中，该方法包括：在接收到服务-呼叫会话功能实体S-CSCF发起的呼叫请求消息后，基于预设条件，确定一个待触发AS序列；将所述呼叫请求消息转化为内部呼叫请求消息，依次触发所述待触发AS序列中的每个AS，并将该内部呼叫请求消息依次发送至每个AS，在每个AS触发完成后，接收每个AS回送的内部呼叫请求响应消息；将接收到最后一个AS回送的内部呼叫请求响应消息转化为呼叫请求响应消息，并发送至所述S-CSCF；管理进行所述呼叫请求响应消息之后的后续呼叫消息的传递和发送，通过媒体协商，使主被叫侧通过编解码转换后建立正常通话，且通话被监听。

优选地，管理通过媒体协商，使主被叫侧通过编解码转换后建立正常通话，包括：完成主被叫媒体、监听媒体和编解码转换媒体之间的媒体协商，使主被叫用户通过编解码转换后建立正常通话。

优选地，所述预设条件包括：所述呼叫请求消息消息中是否携带起呼MO指示或终呼MT指示，主叫侧业务是否为多方通话业务，主叫用户或被叫用户是否被监听，或者，通过判断被叫用户的媒体编解码与主叫用户是否有交集，来确定是否进行预先编解码转换。

优选地，基于预设条件，确定一个待触发AS序列，包括：如果所述呼叫请求消息消息中携带MO指示，则将主叫应用服务器O-AS加入所述待触发AS序列，如果携带MT指示，则将被叫应用服务器T-AS加入所述待触发AS序列；如果主叫侧业务是多方通话业务，则不将编解码转换应用服务器TC-AS加入所述待触发AS序列，不再进行是否进行预先编解码转换的判断；基于主叫用户或被叫用户是否被监听，确定是否触发监听应用服务器LI-AS，如果是，则将LI-AS加入所述待触发AS序列，如果否，则不将LI-AS加入所述待触发AS序列；基于是否进行预先编解码转换，确定是否触发编解码转换应用服务器TC-AS，如果是，则将LI-AS加入所述待触发AS序列，如果否，则不将 TC-AS加入所述待触发AS序列。

优选地，是否需要预先编解码转换，通过以下方式进行判断：根据查询到的数据库中记录的业务用户的属性的媒体模板，或者号码分析中记录的被叫用户号码段的媒体模板，判断是否需要预先编解码转换。

优选地，在所述AS管理实体使主被叫侧通过编解码转换后建立正常通话之后，所述方法还包括：在异常通话场景下，动态触发LI-AS或者TC-AS；把动态触发的AS加入到已触发AS序列，并重新排序；管理后续消息的传递和发送顺序，完成整个呼叫。

优选地，在异常通话场景下，动态触发LI-AS或者TC-AS，包括：根据呼叫过程中的特殊场景动态触发LI-AS，或者根据收到的异常响应消息动态触发TC-AS；其中，所述特殊场景是正常通话出现异常时的场景。

优选地，接收的所述呼叫请求消息是：由所述S-CSCF发起，经过协议适配实体解码和适配的呼叫请求消息。

根据本发明的另一方面，本发明还提供了一种IMS网络中实现合法监听的装置，应用于AS管理实体，其中，该装置包括：序列建立模块，用于在接收到服务-呼叫会话功能实体S-CSCF发起的呼叫请求消息后，基于预设条件，确定一个待触发AS序列；静态触发模块，用于将所述呼叫请求消息转化为内部呼叫请求消息，依次触发所述待触发AS序列中的每个AS，并将该内部呼叫请求消息依次发送至每个AS，在每个AS触发完成后，接收每个AS回送的内部呼叫请求响应消息；再将接收到最后一个AS回送的内部呼叫请求响应消息转化为呼叫请求响应消息，并发送至所述S-CSCF；建立通话模块，用于进行所述呼叫请求响应消息之后的后续呼叫消息的传递和发送，通过媒体协商，使主被叫侧通过编解码转换后建立正常通话，且通话被监听。

优选地，所述预设条件包括：所述呼叫请求消息消息中是否携带起呼MO指示或终呼MT指示，主叫侧业务是否为多方通话业务，主叫用户或被叫用户是否被监听，或者，通过判断被叫用户的媒体编解码与主叫用户是否有交集， 来确定是否进行预先编解码转换。

优选地，所述序列建立模块基于预设条件确定一个待触发AS序列，包括：如果所述呼叫请求消息消息中携带MO指示，则将主叫应用服务器O-AS加入所述待触发AS序列，如果携带MT指示，则将被叫应用服务器T-AS加入所述待触发AS序列；如果主叫侧业务是多方通话业务，则不将编解码转换应用服务器TC-AS加入所述待触发AS序列，不再进行是否进行预先编解码转换的判断；基于主叫用户或被叫用户是否被监听，确定是否触发监听应用服务器LI-AS，如果是，则将LI-AS加入所述待触发AS序列，如果否，则不将LI-AS加入所述待触发AS序列；基于是否进行预先编解码转换，确定是否触发编解码转换应用服务器TC-AS，如果是，则将LI-AS加入所述待触发AS序列，如果否，则不将TC-AS加入所述待触发AS序列。

优选地，所述装置还包括：动态触发模块，用于在异常通话场景下，所述AS管理实体动态触发LI-AS或者TC-AS；把动态触发的AS加入到已触发AS序列，并重新排序；管理后续消息的传递和发送顺序，完成整个呼叫。

优选地，所述动态触发模块，还用于根据呼叫过程中的特殊场景动态触发LI-AS，或者根据收到的异常响应消息动态触发TC-AS；其中，所述特殊场景是正常通话出现异常时的场景。

根据本发明的又一方面，本发明还提供了一种IMS网络中的应用服务器，其中，该应用服务器包括：AS管理实体，协议适配实体，以及逻辑上相互独立的业务应用服务器O-AS或者T-AS、监听应用服务器LI-AS、编解码转换应用服务器TC-AS，其中，所述AS管理实体，用于根据静态触发和动态触发管理机制，触发逻辑上相关独立的O-AS、T-AS、LI-AS、和/或TC-AS；保存和管理整个呼叫的相关信息；管理呼叫消息的发送和传递；所述协议适配实体，包括SIP协议子系统和H.248协议子系统，用于执行所述应用服务器接收到的其他网元的消息的解码，转换为内部消息发送给所述AS管理实体；所述O-AS、所述T-AS，用于执行业务用户的主叫侧或者被叫侧的增值业务逻辑；所述 LI-AS，用于执行监听的业务逻辑；所述TC-AS，用于执行编解码转换的业务逻辑，控制编解码转换媒体资源处理器准备编解码转换媒体，以及主被叫用户的媒体的协商。

本发明有益效果如下：

1)本发明通过AS管理实体对O-AS或者T-AS、LI-AS、TC-AS静态和动态两种触发管理机制，实现了预先TransCoding和媒体协商失败后TransCoding两种呼叫场景下的合法监听，扩大了合法监听的监听范围。

2)本发明提供的技术方案中，各个AS逻辑上相互独立，结构清晰，模块耦合性低，便于维护和扩展。

3)本发明提供的技术方案中，对S-CSCF只呈现出一个应用服务器，一次触发就可以实现业务、监听和编解码转换，减少了网元间消息的交互，保证了整个IMS系统运行的性能和效率不会下降。

4)本发明提供的方法不改变IMS系统的处理规则，对已有IMS系统不会造成任何影响，有效保证了本发明方法的可实施性，以及向后兼容性。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

图1是根据相关技术的IMS网络中一次典型的呼叫流程图；

图2是根据相关技术的3GPP中定义的预先TransCoding的流程图；

图3是根据相关技术的一种实现对应用服务器合法监听的架构图；

图4是根据本发明实施例一的IMS网络中实现合法监听的方法流程图；

图5是根据本发明实施例二的IMS网络中实现合法监听的装置结构框图；

图6是根据本发明实施例三的IMS网络中的应用服务器的结构示意图；

图7是根据本发明实施例四的在IMS网络中实现合法监听的方法流程图；

图8是根据本发明实施例五的在IMS网络中实现合法监听的方法流程图；

图9是根据本发明实施例六的在IMS网络中实现合法监听的方法流程图；

图10是根据本发明实施例六的在IMS网络中实现合法监听的方法流程图；

图11是根据本发明实施例七的在IMS网络中实现合法监听的方法流程图；

图12是根据本发明实施例八的在IMS网络中实现合法监听的方法流程图；

图13是根据本发明实施例八的在IMS网络中实现合法监听方法的媒体连接示意图。

具体实施方式

为了解决当前编解码转换呼叫方案中，如何对主被叫的媒体进行转发、复制和传递从而实现合法监听的问题，本发明提供了一种IMS网络中实现合法监听的方法、装置及应用服务器，以下结合附图以及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不限定本发明。

在本发明中，应用服务器(Application Server，简称AS)包含逻辑上相互独立的业务应用服务器(O-AS或者T-AS)、监听应用服务器(Lawful Interception Application Server，简称LI-AS)、编解码转换应用服务器(TransCoding Application Server，简称TC-AS)，以及协议适配实体和AS管理实体。AS管理实体既可以在接收到呼叫请求消息时，按照一定的顺序静态触发AS，也可以在后续的某些场景下按照一定的原则动态地触发相应的AS。这种AS相互独立，由AS管理实体统一进行触发管理的架构，清晰、灵活、易于实现；AS管理实体和各AS之间使用内部消息实现交互使得系统开销少，运行效率高。

实施例一

图4是根据本发明实施例一的IMS网络中实现合法监听的方法流程图，如图4所示，该方法包括以下步骤：

步骤S402，AS管理实体在接收到S-CSCF发起的呼叫请求消息后，基于预设条件，确定一个待触发AS序列；其中，该呼叫请求消息是：由S-CSCF发起，经过协议适配实体解码和适配的呼叫请求消息。

步骤S404，AS管理实体将呼叫请求消息转化为内部呼叫请求消息，依次触发待触发AS序列中的每个AS，并将该内部呼叫请求消息依次发送至每个AS，在每个AS触发完成后，接收每个AS回送的内部呼叫请求响应消息；AS管理实体将接收到最后一个AS回送的内部呼叫请求响应消息转化为呼叫请求响应消息，并发送至S-CSCF。

步骤S406，AS管理实体管理进行呼叫请求响应消息之后的后续呼叫消息的传递和发送，通过媒体协商，使主被叫侧通过编解码转换后建立正常通话，且通话被监听。

在本实施例中，步骤S402中的预设条件包括：呼叫请求消息消息中是否携带起呼MO指示或终呼MT指示，主叫侧业务是否为多方通话业务，主叫用户或被叫用户是否被监听，或者，通过判断被叫用户的媒体编解码与主叫用户是否有交集，来确定是否进行预先编解码转换。

在步骤S402中，基于不同的预设条件确定待触发AS序列，包括以下优选实施方式：

1)如果呼叫请求消息消息中携带MO指示，则将主叫应用服务器O-AS加入待触发AS序列，如果携带MT指示，则将被叫应用服务器T-AS加入待触发AS序列；

2)如果主叫侧业务是多方通话业务，则不将编解码转换应用服务器TC-AS加入待触发AS序列，不再进行是否进行预先编解码转换的判断；

3)基于主叫用户或被叫用户是否被监听，确定是否触发监听应用服务器LI-AS，如果是，则将LI-AS加入待触发AS序列，如果否，则不将LI-AS加入待触发AS序列；

4)基于是否进行预先编解码转换，确定是否触发编解码转换应用服务器 TC-AS，如果是，则将LI-AS加入待触发AS序列，如果否，则不将TC-AS加入待触发AS序列。其中，对于是否需要预先编解码转换，可以通过以下优选实施方式进行判断：AS管理实体根据查询到的数据库中记录的业务用户的属性的媒体模板，或者号码分析中记录的被叫用户号码段的媒体模板，判断是否需要预先编解码转换。

在步骤S406中，AS管理实体管理通过媒体协商，使主被叫侧通过编解码转换后建立正常通话，包括：AS管理实体完成主被叫媒体、监听媒体和编解码转换媒体之间的媒体协商，使主被叫用户通过编解码转换后建立正常通话。

步骤S406在AS管理实体使主被叫侧通过编解码转换后建立正常通话之后，上述方法还包括：

1)在异常通话场景下，AS管理实体动态触发LI-AS或者TC-AS。具体地，AS管理实体根据呼叫过程中的特殊场景动态触发LI-AS，或者根据收到的异常响应消息动态触发TC-AS；其中，特殊场景是正常通话出现异常时的场景。

2)AS管理实体把动态触发的AS加入到已触发AS序列，并重新排序。

3)AS管理实体管理后续消息的传递和发送顺序，完成整个呼叫。

实施例二

图5是根据本发明实施例二的IMS网络中实现合法监听的装置结构框图，如图5所示，该装置应用于AS管理实体，该装置包括：

序列建立模块10，用于在接收到S-CSCF发起的呼叫请求消息后，基于预设条件，确定一个待触发AS序列；

静态触发模块20，将呼叫请求消息转化为内部呼叫请求消息，依次触发待触发AS序列中的每个AS，并将该内部呼叫请求消息依次发送至每个AS，在每个AS触发完成后，接收每个AS回送的内部呼叫请求响应消息；再将接收到最后一个AS回送的内部呼叫请求响应消息转化为呼叫请求响应消息，并发 送至S-CSCF；

建立通话模块30，用于进行呼叫请求响应消息之后的后续呼叫消息的传递和发送，通过媒体协商，使主被叫侧通过编解码转换后建立正常通话，且通话被监听。

在本实施例中，上述预设条件包括：呼叫请求消息消息中是否携带起呼MO指示或终呼MT指示，主叫侧业务是否为多方通话业务，主叫用户或被叫用户是否被监听，或者，通过判断被叫用户的媒体编解码与主叫用户是否有交集，来确定是否进行预先编解码转换。

优选地，序列建立模块基于预设条件确定一个待触发AS序列，包括：

如果呼叫请求消息消息中携带MO指示，则将主叫应用服务器O-AS加入待触发AS序列，如果携带MT指示，则将被叫应用服务器T-AS加入待触发AS序列；

如果主叫侧业务是多方通话业务，则不将编解码转换应用服务器TC-AS加入待触发AS序列，不再进行是否进行预先编解码转换的判断；

基于主叫用户或被叫用户是否被监听，确定是否触发监听应用服务器LI-AS，如果是，则将LI-AS加入待触发AS序列，如果否，则不将LI-AS加入待触发AS序列；

基于是否进行预先编解码转换，确定是否触发编解码转换应用服务器TC-AS，如果是，则将LI-AS加入待触发AS序列，如果否，则不将TC-AS加入待触发AS序列。

上述装置还包括：动态触发模块，用于在异常通话场景下，AS管理实体动态触发LI-AS或者TC-AS；把动态触发的AS加入到已触发AS序列，并重新排序；管理后续消息的传递和发送顺序，完成整个呼叫。

上述动态触发模块，还用于根据呼叫过程中的特殊场景动态触发LI-AS，或者根据收到的异常响应消息动态触发TC-AS；其中，特殊场景是正常通话出现异常时的场景。

实施例三

图6是根据本发明实施例三的IMS网络中的应用服务器的结构示意图，如图6所示，该应用服务器包括：AS管理实体，协议适配实体，以及逻辑上相互独立的业务应用服务器O-AS或者T-AS、监听应用服务器LI-AS、编解码转换应用服务器TC-AS，其中，

协议适配实体，包括SIP协议子系统和H.248协议子系统。完成应用服务器接收到的其他网元的消息的解码，转换为内部消息发送给AS管理实体；并完成对应用服务器需要发送到其他网元的消息的协议编码。

AS管理实体，主要完成以下几方面的功能：1)根据静态触发和动态触发管理机制，触发逻辑上相关独立的O-AS或者T-AS、LI-AS、TC-AS；2)保存和管理整个呼叫的相关信息包括呼叫进展信息、主被叫媒体描述信息等；3)管理呼叫消息的发送和传递；

O-AS或者T-AS，业务应用服务器，执行业务用户的主叫侧或者被叫侧的增值业务逻辑。主叫侧的业务主要有号码显示类(主叫号码显示限制、被连接号码显示)、权限类业务(呼出限制、被叫目的码限制、被叫目的码接续)等；被叫侧的业务有：前转类(无条件前转、遇忙前转、无应答前转等)、号码显示类(主叫号码显示等)、权限类、被叫一号通、彩铃、免打扰等。

依据S-CSCF发起的呼叫请求消息中携带的MO或者MT的指示，确定本次触发呼叫中业务应用服务器的角色。携带的指示如果是MO，表明本次触发是MO阶段触发，即主叫侧触发，则此时AS的角色是O-AS，用来执行业务用户的主叫侧业务；携带的指示如果是MT，表明本次触发是MT阶段触发，即被叫侧触发，则此时AS的角色是T-AS，用来执行业务用户的主叫侧业务。O-AS或者T-AS根据系统数据库中用户相关业务的登记情况或者呼叫过程中用户执行某些操作而发送给系统的某些消息执行相关的增值业务逻辑。

LI-AS，合法监听应用服务器，执行监听的业务逻辑。包括：监控对象设 置；通讯相关事件上报；控制监听媒体资源处理器准备监听媒体，与监听提交网关之间媒体协商以及与主被叫用户的媒体的协商，传递通讯内容。

TC-AS，编解码转换应用服务器，执行编解码转换的业务逻辑。控制编解码转换媒体资源处理器准备编解码转换媒体，以及主被叫用户的媒体的协商。

下面通过几个优选实施例和附图，对本发明的技术方案进行详细介绍。

实施例四

图7根据本发明实施例四的在IMS网络中实现合法监听的方法流程图，如图7所示，本实施例提供了AS管理实体静态和动态的触发O-AS或者T-AS、LI-AS，TC-AS，保存和管理整个呼叫的相关信息包括呼叫进展信息、主被叫媒体描述信息，并管理呼叫消息的发送和传递，实现对编解码转换呼叫的合法监听的流程，具体包括如下步骤：

步骤S701，AS管理实体接收到S-CSCF发起的呼叫请求消息，消息中携带MO或者MT的指示。

本步骤具体为S-CSCF根据iFC规则将MO阶段或MT阶段的业务请求触发到AS，呼叫请求消息的Route字段会携带mode参数来区分：如果mode＝mo，表明本次触发是MO阶段触发，即主叫侧触发，则此时AS的角色是O-AS，用来执行业务用户的主叫侧业务；如果mode＝mt，表明本次触发是MT阶段触发，即被叫侧触发，则此时AS的角色是T-AS，用于执行业务用户的被叫侧业务。该呼叫请求消息在经过AS的协议适配层实体的解码和适配后，被发送到AS管理实体。

步骤S702，AS管理实体根据MO或者MT的指示、是否多方通话业务、是否被监听、是否需要预先编解码转换等信息，进行判断和分析，确定一个待静态触发的AS序列。

MO指示表明本次触发是MO阶段触发，即主叫侧触发，则此时AS的角色是O-AS，用来执行业务用户的主叫侧业务，需要触发O-AS。MT指示表明 本次触发是MT阶段触发，即被叫侧触发，则此时AS的角色是T-AS，用来执行业务用户的主叫侧业务，需要触发T-AS。

多方通话业务由于需要预先触发到会议媒体资源处理器准备会议媒体资源，而会议媒体资源处理器支持的编解码是足够丰富的，因此不再需要AS对主被叫进行TransCoding操作；同时，针对多方通话业务的监听，只要监听了会议的主席用户，则可以监听到全部的用户。这两种特性使得AS管理实体触发和管理O-AS、LI-AS和TC-AS时，必须要把多方通话业务和非多方通话业务分开处理。

AS管理实体根据用户是否被布控判断是否触发LI-AS，如果需要触发，则把LI-AS加入到待触发AS序列。

AS管理实体根据查询到的数据库中记录的业务用户的属性的媒体模板或者号码分析中记录的被叫用户号码段的媒体模板进行判断是否触发TC-AS，如果需要触发，则把TC-AS加入到待触发AS序列。

AS管理实体依据以上判断和分析，确定一个待静态触发的AS序列。序列中AS的顺序取决于进行AS逻辑判断的先后顺序，而进行AS逻辑判断的先后顺序主要是考虑了呼叫所处的阶段不同以及主叫侧业务和被叫侧业务的特点不相同，目的是尽量避免重复、交叉、多次、以及不必要的AS触发，减少消息的交互，避免资源的浪费。

步骤S703，AS管理实体依次触发AS序列中的AS，完成监听媒体和编解码转换媒体的准备；静态触发完成后，把呼叫请求消息环回到S-CSCF，呼叫继续。

本步骤具体为AS管理实体依次触发AS，由该AS执行相应的业务逻辑，执行完成后通知AS管理实体。O-AS或者T-AS根据系统数据库中用户相关业务的登记情况或者呼叫过程中用户执行某些操作而发送给系统的某些消息执行相关的增值业务逻辑。LI-AS主要完成通讯相关事件上报，以及在LI MRFP上预留监听通道资源，使主被叫用户的媒体都经过LI MRFP的转发。监听中 心通过对监听通道的侦听，达到监听主被叫用户媒体的目的。TC-AS主要完成控制编解码转换资源处理器准备TransCoding媒体资源的功能。

AS管理实体保存和管理整个呼叫的相关信息，包括呼叫进展信息、主被叫媒体描述信息等。触发某个AS时，呼叫的相关信息发送给AS，AS执行各自的业务逻辑修改了呼叫的相关信息后，再回送给AS管理实体，AS管理实体更新并保存这些信息。

步骤S704，AS管理实体管理呼叫请求消息之后的振铃、应答等后续呼叫消息的传递和发送，完成主被叫媒体、监听媒体和编解码转换媒体之间的媒体协商，使主被叫通过编解码转换后可建立通话，并且通话可被监听。

按照反向串行的原则，AS管理实体把呼叫请求消息之后的振铃、应答等后续呼叫消息按照已触发AS序列的反向依次发送给各AS。TC-AS和LI-AS分别指示TC MRFP、LI MRFP更新编解码转换媒体和监听媒体的对端被叫侧媒体描述信息，以及与主被叫媒体之间的协商，达到整个呼叫过程中各个网元上媒体的请求和应答平衡，使主被叫通过编解码转换后可建立通话，并且通话可被监听。

步骤S705，AS管理实体根据呼叫过程中的特殊场景动态触发LI-AS，或者根据收到的异常相应消息动态触发TC-AS；AS管理实体把动态触发的AS加入到已触发AS序列，并重新排序，管理后续消息的传递和发送顺序，完成整个呼叫。

本步骤具体为AS管理实体根据呼叫过程中的特殊场景动态触发LI-AS，这个场景主要是：O-AS对主叫用户异常放音。根据AS管理实体静态触发各个AS的顺序，MO触发时如果主叫侧的业务不是多方通话业务，则LI-AS位于O-AS的后向；此时，当O-AS执行业务逻辑过程中，如果需要O-AS对主叫用户异常放音，由于之前LI-AS还没有被触发，就会导致LEA监听不到这个放音，因此必须在此时动态触发LI-AS，以便监听到这个放音。

TC-AS需要支持预先TransCoding和媒体协商失败后TransCoding两种方 式，实际对应AS管理实体则是存在预先静态触发以及由后续响应消息动态触发两种方式。由于系统中没有配置被叫用户的媒体能力模板或者配置错误，会导致没有执行预先TransCoding，而当后续呼叫请求发送到被叫用户，被叫用户回488或者606响应消息表明编解码不同导致呼叫无法建立时，需要动态触发TC-AS，进行编解码转换，使主被叫可以通话。呼叫过程中主叫或者被叫对于媒体更新请求消息回的488或者606响应消息同样会触发TC-AS。

AS管理实体把动态触发的AS加入到已触发AS序列并重新排序，保证后续呼叫过程中的消息经过动态触发的AS。

本实施例提供了在IMS网络中实现合法监听的方法，通过以上步骤，在AS管理实体对O-AS或者T-AS、LI-AS、TC-AS静态和动态两种触发方式的有效管理下，实现了预先TransCoding和媒体协商失败后TransCoding两种呼叫场景下的合法监听。

实施例五

图8是根据本发明实施例五的在IMS网络中实现合法监听的方法流程图，如图8所示，本实施例提供了AS管理实体从接收到S-CSCF发起的呼叫请求消息开始，到对LI-AS、TC-AS是否需要触发进行判断并确定待触发AS序列，再到依次触发AS序列中的AS，完成AS序列的静态触发，最终把呼叫请求消息环回到S-CSCF的整个流程。具体包括如下步骤：

步骤S801，AS管理实体接收到S-CSCF发起的呼叫请求消息，消息中携带MO或者MT的指示。S-CSCF根据iFC规则将MO阶段或MT阶段的业务请求触发到AS，该呼叫请求消息在经过AS的协议适配层实体的解码和适配后，被发送到AS管理实体。

步骤S802，AS管理实体判断本次S-CSCF的触发请求为主叫侧触发。呼叫请求消息中的Route字段会携带mode参数是mode＝mo，表明本次触发是MO阶段触发，即主叫侧触发，则此时AS的角色是O-AS，用来执行业务用户 的主叫侧业务。需要完成主叫用户的增值业务，比如主叫号码显示限制、呼出限制、SUBSCRIBE订阅(遇忙回叫)、三方通话、会议、呼叫转接等业务。

步骤S803，AS管理实体判断主叫侧业务为非多方通话业务。AS管理实体在判断需要进行主叫侧触发后，根据用户标识，查询主叫业务用户的业务信息。对于主叫侧的业务，除了多方通话业务，都不会进行分叉而导致同时发起多路呼叫。多方通话业务由于需要预先触发到会议媒体网关准备会议媒体资源，而会议媒体网关支持的编解码是足够丰富的，因此不再需要AS对主被叫进行TransCoding操作；同时，针对多方通话业务的监听，只要监听了会议的主席用户，则可以监听到全部的用户。这两种特性使得AS管理实体触发和管理O-AS、LI-AS和TC-AS时，必须要把多方通话业务和非多方通话业务分开处理。

步骤S804，AS管理实体判断主叫用户被监听。监听中心通过布控命令布控需要监听的用户，布控命令发送到AS后，AS以数据表的形式把被布控用户的用户标识存放在AS的数据库后台。在这一步，AS管理实体查询后台数据库，根据用户标识来匹配数据库表中的记录从而确定业务主叫有没有被监听。如果主叫用户被监听，则需要触发LI-AS；如果未被监听，则不需要触发LI-AS。此步骤中主叫用户被监听，需要触发LI-AS，因此把LI-AS加入到待触发AS序列。

本步骤中未标出NO的部分流程(即未被监听的流程)是本例的简化流程，可参照本例实施。图8中其他判断的步骤中未标出NO的流程也是如此。

步骤S805，AS管理实体判断主被叫支持的编解码不同。在对被叫进行号码分析时，会对呼叫消息中携带的主叫的媒体编码能力与被叫用户号码段配置中被叫媒体能力模板里的被叫媒体编码能力进行比对，如果没有交集，则说明主被叫编解码不同，需要执行TC-AS的业务逻辑，以便使用TC MFRP进行媒体编解码转换。此步骤中主被叫编解码不相同，需要触发TC-AS，因此把TC-AS加入到待触发AS序列。

步骤S806，AS管理实体确定待静态触发的AS序列依次为O-AS、LI-AS、TC-AS。

由于各个AS都是受AS管理实体的触发控制和管理，而各个AS又都会把呼叫相关信息传递给AS管理实体，因此不管多复杂的呼叫模型和场景，只要在需要时触发到相应的AS，相应的业务都可以实现。但这就可能带来有时会重复、交叉、多次的触发各个AS，逻辑上是混乱的。如何在保证基本的呼叫场景的同时，兼顾考虑特殊呼叫场景，合理的确定静态触发顺序，减少这种重复、交叉、多次的逻辑混乱的触发，就很重要了。

本次触发为主叫侧触发，表明AS的角色为O-AS；主叫侧业务为非多方通话业务，表明呼叫中没有会议媒体资源参与，还需要进一步判断是否主被叫的编解码不同；主叫被监听，表明需要触发LI-AS；主被叫编解码不同，表明需要触发TC-AS；综合以上几点，AS管理实体确定待静态触发的AS序列依次为O-AS、LI-AS、TC-AS。这种静态触发顺序的优点在于：

1)这种顺序可以减少TC-AS不必要的触发。主叫侧呼叫鉴权类业务比如呼出限制业务、黑白名单等业务，先触发O-AS，经过鉴权，发现主叫用户无权呼出，则后续就不再需要触发TC-AS了。而如果每次呼叫先触发TC-AS，指示TC MRFP准备媒体资源，后面触发O-AS时才发现用户无权呼出，则还要发送释放消息给TC-AS释放掉前面准备的媒体资源。因此TC-AS放在O-AS后面可以减少TC-AS不必要的触发，从而避免了浪费TC MRFP的媒体资源，并减少了消息交互，提高了系统性能。

2)这种顺序便于实现对呼叫转接类业务的监听。下面具体说明。用户A登记有呼叫转接业务，且已被LEA布控为监听用户。用户A与用户B通话过程中，转接业务用户A发起转接到用户C，用户A与用户C通话后，用户A挂机，用户B与用户C继续通话。按照监听要求，仍然需要监听用户B和用户C之间的通话。如果O-AS在LI-AS之前触发，则按照后续的响应消息反向串行发送的原则，用户A挂机释放消息是先发到LI-AS，LI-AS可以立即控制 主叫侧监听媒体与此时将要进入通话的用户B的媒体建立连接，把B用户的媒体经监听通道发送到LEA，然后再把释放信息传递给AS管理实体和O-AS，由O-AS完成用户A的释放流程。相同的情形下，如果A挂机释放消息先发送到O-AS，则O-AS的正常的业务逻辑就是释放掉用户A的呼叫，而此时还没有经过LI-AS的控制，即将进入通话的用户B没有与监听通道建立连接，因此无法实现对用户B和用户C的监听。如果要实现对用户B和用户C通话的监听，则O-AS要在此处增加逻辑判断，触发到LI-AS，并经AS管理实体的传递再重新触发到O-AS，这种交叉触发增加了内部消息的传递，逻辑混乱，且很难对定时器进行管理。

3)这种顺序便于对增值业务实现过程中的监听的通讯事件上报。编解码转换功能只是针对媒体方面的操作，而监听需要同时完成媒体和通讯事件的上报。在O-AS检测到某个通讯事件发生后，为方便LI-AS实现监听业务逻辑中的通讯事件上报，需要把LI-AS紧靠在O-AS之后触发。

步骤S807，AS管理实体触发O-AS，O-AS执行完业务逻辑后通知AS管理实体。

本步骤具体为AS管理实体创建O-AS相关数据区，发送呼叫相关信息给O-AS，O-AS执行完主叫用户的主叫侧业务序列后，通知AS管理实体O-AS已完成触发，并把修改过的呼叫相关信息回送给AS管理实体。其中主叫业务用户的主叫业务序列可以有：号码显示类(主叫号码显示限制、被连接号码显示)、权限类业务(呼出限制、被叫目的码限制、被叫目的码接续)、主叫一号通、彩像、新业务登记、激活等、SUBSCRIBE订阅(遇忙回叫)、带接入码的呼叫(例如代答、跨越、接续)、呼叫保持、refer类(呼叫接续、呼叫转接)等。

O-AS执行主叫侧业务的过程：(以主叫号码显示限制业务为例)：

1)O-AS查找主叫用户的业务属性，发现主叫用户登记了主叫号码显示限制业务。

2)O-AS在呼叫请求消息中，插入一个Privacy头部字段，并置其值为“id”； 同时把From字段修改为匿名。

O-AS完成上述主叫业务逻辑后，发送呼叫进展消息给AS管理实体。

步骤S808，AS管理实体触发LI-AS，LI-AS执行完业务逻辑后通知AS管理实体。

本步骤具体为AS管理实体创建LI-AS相关数据区，发送监听请求和呼叫相关信息给LI-AS，LI-AS执行完监听业务逻辑后，通知AS管理实体LI-AS已完成触发，并把修改过的呼叫相关信息尤其是主叫的媒体描述信息回送给AS管理实体。

LI-AS执行监听业务逻辑的过程是:

1)AS管理实体发送监听请求和呼叫相关信息给LI-AS，其中包含的主叫的媒体描述信息为用户A的媒体描述信息SDP_A且媒体编码格式为codec-A。

2)LI-AS控制协议适配层实体的H.248子系统向LI MRFP网元发出2个ADD操作命令，指示LI MRFP网元在同一个上下文Context中添加两个RTP，其中一个RTP的对端媒体描述信息指向主叫A的媒体描述信息SDP_A。LI MRFP回复LI-AS创建两个RTP成功，为描述方便，本实例中分别把它们称之为RTP1_LI和RTP2_LI，其中RTP1_LI的对端媒体描述信息指向主叫A的媒体描述信息SDP_A。

3)LI-AS控制协议适配层实体的H.248子系统再次向LI MRFP网元发出2个ADD操作命令，指示LI MRFP网元在与步骤2中的同一个上下文Context中添加两个RTP。LI MRFP回复LI-AS创建两个RTP成功，分别为RTP1_COPY和RTP2_COPY。

4)LI-AS控制协议适配层实体的H.248子系统向LI MRFP网元发出Modify操作命令，通过Topology{RTP1_LI,RTP1_COPY,Oneway}，Topology{RTP2_LI,RT2_COPY,Oneway}}的方式指定RTP1_COPY只接收来自RTP1_LI的媒体流，RT2_COPY只接收来自RTP2_LI的媒体流。

5)LI-AS发送呼叫请求INVITE消息给媒体网关控制功能实体，消息中携 带相应的CCCID1和RTP1_COPY的媒体描述信息。媒体网关控制功能实体指示提交功能网关MGW添加RTP1_MGW，并回200OK响应消息携带RTP1_MGW的媒体描述信息。LI-AS发送CC消息给LIG，告知监听媒体通道1已打开。同理，创建RTP2_MGW，并发送CC消息给LIG，告知监听媒体通道2已打开。

6)LI-AS控制协议适配层实体的H.248子系统向LI MRFP网元分别发出两个Modify操作命令，修改RTP1_COPY的对端媒体描述信息为RTP1_MGW的媒体描述信息，RTP2_COPY对端媒体描述信息为RTP2_MGW的媒体描述信息。

7)LI-AS把上述更新后的媒体描述信息和呼叫进展消息一起发送给AS管理实体，通知AS管理实体，LI-AS的业务逻辑已执行完成。

8)AS管理实体把主叫的媒体描述信息替换为RTP2_LI的媒体描述信息。

通过上述操作，LI-AS在LI MRFP上创建和预留了监听通道资源，并完成了和监听提交功能网关的媒体协商。LI-AS把修改过的呼叫相关信息尤其是主叫的媒体描述信息回送给AS管理实体。AS管理实体把主叫侧的媒体描述信息替换为RTP2_LI的媒体描述信息。

步骤S809，AS管理实体触发TC-AS，TC-AS执行完业务逻辑后通知AS管理实体。

本步骤具体为AS管理实体创建TC-AS相关数据区，发送呼叫相关信息给TC-AS，TC-AS执行完TransCoding业务逻辑后，通知AS管理实体TC-AS已完成触发，并把修改过的呼叫相关信息尤其是主叫侧的媒体描述信息回送给AS管理实体。

TC-AS执行TransCoding业务逻辑过程是:

1)AS管理实体发送TransCoding请求和呼叫相关信息给TC-AS，其中包含的主叫的媒体描述信息为RTP2_LI的媒体描述信息。

2)TC-AS控制协议适配层实体的H.248子系统向TC MRFP网元发出ADD 操作命令，指示TC MRFP网元添加一个RTP且其对端媒体描述信息指向RTP2_LI的媒体描述信息，TC MRFP网元回复TC-AS创建RTP成功。为方便描述，称这个RTP为RTP1_TC。

3)TC-AS控制协议适配层实体的H.248子系统向TC MRFP网元再发一个ADD操作命令，指示TC MRFP网元在与RTP1_TC所在的上下文中添加另外一个RTP，其对端媒体描述信息中的媒体编码格式为被叫B的媒体模板上记录的媒体编码格式，TC MRFP网元回复TC-AS创建RTP成功。为方便描述，称这个RTP为RTP2_TC。

4)TC-AS把上述更新后的媒体描述信息和呼叫进展消息一起发送给AS管理实体，通知AS管理实体，LI-AS的业务逻辑已执行完成。

5)AS管理实体把主叫的媒体描述信息替换为RTP2_TC的媒体描述信息，其中主叫的媒体编码格式修改为codec-A加上被叫B的媒体模板上记录的媒体编码格式codec-B。

通过上述操作，TC-AS指示TC MRFP上创建了TransCoding所需要的媒体资源。TC-AS把修改过的呼叫相关信息尤其是主叫的媒体描述信息回送给AS管理实体。AS管理实体把主叫侧的媒体描述信息替换为RTP2_TC的媒体描述信息。

步骤S810，AS管理实体完成AS序列的静态触发，把呼叫请求消息环回到S-CSCF，继续管理后续呼叫消息的发送和传递。在LI-AS和TC-AS触发完成后，LI MRFP里的RTP2_LI与TC MRFP里的RTP1_TC建立了连接。AS管理实体将业务请求消息经过协议适配层实体SIP子系统编码后环回到S-CSCF，消息中包含主叫侧媒体描述信息为RTP2_TC的媒体描述信息。

以上步骤S801-S810为主叫侧非多方通话业务触发时，AS管理实体完成AS序列的静态触发的处理流程。

下面的步骤S811-814为主叫侧多方通话业务时，AS管理实体完成AS序列的静态触发的处理流程。步骤S815-820为被叫侧触发时，AS管理实体完成 AS序列的静态触发的处理流程，这些流程与主叫侧非多方通话业务触发的处理流程类似，分别介绍如下：

步骤S811，AS管理实体判断业务用户被监听，与步骤S804相同，把LI-AS加入到待触发AS序列。

步骤S812，AS管理实体确定待静态触发的AS序列依次为LI-AS、O-AS。

多方通话业务由于需要预先触发到会议媒体网关准备会议媒体资源，而会议媒体网关支持的编解码是足够丰富的，因此不再需要AS对主被叫进行TransCoding操作；同时，针对多方通话业务的监听，只要监听了会议的主席用户，则可以监听到全部的用户，因此，需要先触发LI-AS，再触发O-AS，即AS的触发顺序分别为：LI-AS、O-AS。

步骤S813，AS管理实体触发LI-AS，LI-AS执行完业务逻辑后通知AS管理实体。与步骤S808相同。

步骤S814，AS管理实体触发O-AS，O-AS执行完业务逻辑后通知AS管理实体。

本步骤与步骤S807类似，具体为AS管理实体创建O-AS相关数据区，发送呼叫相关信息给O-AS，O-AS执行完多方通话业务后，通知AS管理实体O-AS已完成触发，并把修改过的呼叫相关信息回送给AS管理实体。

以上步骤S811-814为主叫侧多方通话业务时，AS管理实体完成AS序列的静态触发的处理流程。

下面的步骤S815-820为被叫侧触发时，AS管理实体完成AS序列的静态触发的处理流程，介绍如下：

步骤S815，AS管理实体判断主被叫支持的编解码不同。在步骤S802的判断逻辑中，如果mode＝mt，表明本次触发是MT阶段触发，即被叫侧触发，则此时AS的角色是T-AS，用于执行业务用户的被叫侧业务。AS管理实体在主叫侧触发与被叫侧触发时执行LI-AS和TC-AS是否要触发的判断逻辑的优先级顺序是不同的。在本步骤，需要先判断主被叫支持的编解码是否相同。

与步骤S805类似，AS管理实体在对被叫进行号码时，会对呼叫消息中携带的主叫的媒体编码能力与被叫用户号码段配置中被叫媒体能力模板里的被叫媒体编码能力进行比对，如果没有交集，则说明主被叫编解码不相同，需要触发TC-AS，以便使用TC MRFP进行媒体编解码转换。与步骤S805不同的是，这一步还可以通过查询被叫用户的用户属性，获知被叫用户的媒体编解码能力。本步骤中主被叫编解码不相同，需要触发TC-AS，因此把TC-AS加入到待触发AS序列。

步骤S816，AS管理实体判断被叫用户被监听。方法与步骤S804类似，只是此处是判断被叫用户是否被监听。本步骤中被叫用户被监听，需要触发LI-AS，因此把LI-AS加入到待触发AS序列。

步骤S817，AS管理实体确定待静态触发的AS序列依次为TC-AS、LI-AS、T-AS。

在判断本次触发为被叫侧触发后，AS管理实体确定待静态触发的AS序列依次为TC-AS、LI-AS、T-AS。这种静态触发顺序的优点在于：

1)这种顺序便于实现对呼叫前转类业务的监听。假设被叫业务用户B登记有无条件前转业务，前转到用户C；用户B已被LEA布控为监听用户。用户A呼叫用户B的呼叫请求发送到AS后，如果先触发到T-AS，则T-AS在判断B用户有无条件前转业务后，把被叫用户更新为用户C，而把用户B作为原被叫号码储存，这时再触发到LI-AS，则LI-AS无法根据被叫号码判断用户B被监听。因此必须在触发T-AS之前，先触发LI-AS，由LI-AS先完成对被叫用户B的监听业务逻辑，再触发到T-AS，由T-AS完成前转业务。

2)减少对T-AS的无效触发。在被叫侧触发时，既可以通过被叫号码分析也可以通过查询被叫用户的用户属性，获知被叫用户的媒体编解码能力，因此可以准确判断主被叫的编解码是否相同。在TC-AS触发失败或者TC-AS指示TC MRFP准备媒体失败后，可根据开关配置决定终止呼叫。在这种终止呼叫的场景下，如果T-AS在TC-AS之前触发，则T-AS所做的业务逻辑是无意义 的，属于无效触发。为减少这种对T-AS的无效触发，必须把T-AS排在TC-AS后面，视TC-AS的执行结果来决定是否实际触发T-AS。

3)与主叫侧触发时LI-AS紧靠在O-AS之后触发相似，把T-AS紧靠在LI-AS之后触发也便于对增值业务实现过程中的监听的通讯事件上报。

步骤S818，AS管理实体触发TC-AS，TC-AS执行完业务逻辑后通知AS管理实体。本步骤的处理过程与步骤S809类似。

步骤S819，AS管理实体触发LI-AS，LI-AS执行完业务逻辑后通知AS管理实体。本步骤的处理过程与步骤S808类似。

步骤S820，AS管理实体触发T-AS，T-AS执行完业务逻辑后通知AS管理实体。

本步骤具体为AS管理实体AS管理实体创建T-AS相关数据区，发送呼叫相关信息给T-AS，T-AS执行完被叫业务用户的被叫业务序列后，通知AS管理实体T-AS已完成触发，并把修改过的呼叫相关信息回送给AS管理实体。其中被叫业务用户的被叫业务序列可以有：前转类(无条件转、遇忙前转、无应答前转等)、号码显示类(主叫号码显示等)、权限类、被叫一号通、彩铃、免打扰、呼叫等待、呼叫保持业务等。

T-AS执行被叫侧业务的过程(以无条件前转业务为例)：

1)T-AS查找被叫用户B的业务属性，发现被叫用户B登记了无条件前转业务并获取到被叫用户的无条件前转号码C。

2)T-AS使用内部格式的消息发起新的呼叫请求给协议适配层实体的SIP子系统，新的呼叫请求消息里的主叫号码B，被叫号码是C，并带有前转信息。

3)协议适配层实体的SIP子系统发送INVITE消息给C用户，并把C用户的呼叫状态和呼叫信息上报给T-AS。

4)T-AS把新呼叫的呼叫状态和呼叫信息传递给原来的主叫A。

5)T-AS完成上述被叫业务后，发送呼叫进展消息给AS管理实体。

以上步骤S815-820介绍了被叫侧触发时，AS管理实体完成AS序列的静 态触发的处理流程。

实施例六

图9是根据本发明实施例六的在IMS网络中实现合法监听的方法流程图，如图9所示，本实施例提供了AS管理实体管理呼叫请求消息之后的振铃、应答等后续呼叫消息的传递和发送，分别更新TC MRFP上的编解码转换媒体和LI MRFP上的监听媒体的对端媒体描述信息，完成整个呼叫过程中各个网元上媒体的请求和应答平衡，使主被叫通过TransCoding后可建立通话，并且通话可被正常监听的整个流程。具体包括如下步骤：

步骤S901，AS管理实体接收到S-CSCF发送过来的呼叫应答消息，消息中携带被叫用户B的媒体描述信息SDP_B。

AS管理实体完成AS序列O-AS、LI-AS、TC-AS的静态触发后，将业务请求INVITE消息经过协议适配层实体SIP子系统编码后环回到S-CSCF，消息中包含主叫侧媒体描述信息为RTP2_TC的媒体描述信息。

S-CSCF把该呼叫请求路由到被叫侧网络呼叫被叫用户B，B振铃，应答，应答消息携带被叫用户B的媒体描述信息SDP_B，其中编解码格式为codec-B。S-CSCF把这个应答消息发送给AS，经协议适配层实体解码后传递给AS管理实体。

步骤S902，AS管理实体把应答消息和相关媒体描述信息发给TC-AS。TC-AS指示TC MRFP网元修改RTP2_TC的对端媒体描述信息为被叫用户B的媒体描述信息SDP_B。

按照响应消息反向串行发送的原则，AS管理实体把应答消息和相关媒体描述信息先发给TC-AS，其中被叫侧媒体描述信息为被叫用户B的媒体描述信息SDP_B。TC-AS控制协议适配层实体的H.248子系统向TC MRFP网元发送Modify操作命令，修改RTP2_TC的对端媒体描述信息为被叫用户B的媒体描述信息SDP_B。TC MRFP网元回复TC-AS修改成功后，TC-AS把上述更新后 的媒体描述信息和呼叫进展消息一起发送给AS管理实体，通知AS管理实体TC-AS已完成对应答消息处理。AS管理实体更新被叫侧媒体信息为RTP1_TC。

步骤S903，AS管理实体把应答消息和相关媒体描述信息发给LI-AS。LI-AS指示LI MRFP网元修改RTP2_LI的对端媒体描述信息为被叫侧的媒体描述信息RTP1_TC。

AS管理实体把应答消息和相关媒体描述信息发给LI-AS，其中的被叫侧媒体信息已经被更新为为RTP1_TC。LI-AS控制协议适配层实体的H.248子系统向LI MRFP网元发送Modify操作命令，修改RTP2_LI的对端媒体描述信息为被叫侧的媒体描述信息RTP1_TC。LI MRFP网元回复LI-AS修改成功后，LI-AS把上述更新后的媒体描述信息和呼叫进展消息一起发送给AS管理实体，通知AS管理实体LI-AS已完成对应答消息的处理。AS管理实体更新被叫侧媒体信息为RTP1_LI。

步骤S904，AS管理实体把应答消息和相关媒体描述信息发给O-AS。O-AS完成业务逻辑的处理。

步骤S905，AS管理实体把应答消息环回到S-CSCF，消息中携带的媒体描述信息为RTP1_LI的媒体描述信息，由S-CSCF把应答消息经过P-CSCF发送给主叫用户A。

至此，完成了整个呼叫过程中各个网元上媒体的请求和应答平衡，现在主被叫通过TransCoding后建立了通话，并且通话可被LEA正常监听到。图10是根据本发明实施例六的在IMS网络中实现合法监听方法的媒体连接示意图，如图10所示，主叫用户A的媒体与LI MRFP上的监听媒体RTP1_LI建立连接；监听媒体RTP1_LI与监听媒体RTP2_LI是互通的；监听媒体RTP2_LI与编解码转换资源处理器上的编解码转换媒体RTP1_TC；编解码转换媒体RTP1_TC与编解码转换媒体RTP2_TC经编解码转换后是互通的；编解码转换媒体RTP2_TC与被叫用户B的媒体建立连接。由此，主被叫用户的媒体经过监听资源媒体处理器和编解码转换资源处理器后，建立了连接，可以建立通话。而 LI MRFP上的监听媒体RTP1_LI和RTP2_LI分别复制一份媒体，并发送到监听功能提交网关上，实现了对这个呼叫通话双方的媒体的监听。

实施例七

图11是根据本发明实施例七的在IMS网络中实现合法监听的方法流程图，如图11所示，本实施例提供了AS管理实体如何动态的触发TC-AS，实现媒体协商失败后的TransCoding，特别提供了如何在主叫用户或者被叫用户被监听的情况下实现媒体协商失败后的TransCoding的过程，也就是对媒体协商失败后的TransCoding呼叫场景实现监听。具体包括如下步骤：

步骤S1101，AS管理实体接收到S-CSCF发起的呼叫请求消息，请求消息中携带的媒体描述信息为主叫A的媒体描述信息。AS管理实体完成AS序列的静态触发的过程可参照实施例五的步骤S801-810。而在步骤S805中，AS管理实体没有判断出被叫支持的编解码与主叫不同，没有判断出的原因可能是没有配置被叫媒体能力模板，或者被叫媒体能力模板中被叫媒体编解码能力与主叫媒体编码能力有交集，因此AS管理实体没有把TC-AS加入到待触发AS序列中。AS管理实体触发的AS序列为：O-AS、LI-AS。LI-AS执行完监听业务逻辑后，更新了媒体描述信息。AS管理实体把主叫侧的媒体描述信息替换为RTP2_LI的媒体描述信息。

步骤S1102，AS将业务请求INVITE消息环回到S-CSCF，消息中包含主叫的媒体描述信息。S-CSCF把该呼叫请求路由到被叫侧网络呼叫被叫用户。被叫用户不支持主叫用户的媒体编解码格式，发送488或者606失败响应消息，并携带被叫用户B的媒体描述信息，包括支持的媒体编解码格式codec-B。

步骤S1103，AS管理实体接收到由488或者606失败响应消息经协议适配层解码转换而成的内部释放消息后，分析并判断出呼叫失败的原因是由于主被叫双方的编解码能力不同所致，因此拦截该释放消息，触发TC-AS，并启动定时器等待TC-AS执行TC业务逻辑。

步骤S1104，AS管理实体触发TC-AS。与步骤S809相同，AS管理实体创建TC-AS相关数据区，发送呼叫相关信息给TC-AS，TC-AS指示TC MRFP准备TransCoding媒体资源，执行完成后，通知AS管理实体TC-AS已完成触发，并把修改过的呼叫相关信息尤其是主叫侧的媒体描述信息回送给AS管理实体。

步骤S1105，AS管理实体把把主叫侧媒体描述信息替换为RTP2_TC的媒体描信息。同时把TC-AS加入到已触发AS序列，并重新排序。这样，后续呼叫过程中的响应消息都会经过TC-AS。

步骤S1106，AS管理实体发送新的呼叫请求消息给S-CSCF，消息中携带新的即经过TransCoding操作后的主叫的媒体描述信息，该媒体描述信息中的媒体编码格式与被叫用户的媒体编码格式有交集，即主被叫可以进行正常通话。

以上步骤讲述了如何在主叫用户被监听的情况下实现编解码协商失败后的TransCoding的过程。这个过程还有以下几种场景的变化，这些变化都可以被做类似的处理：

1)以呼叫经过的网元的先后顺序不同来定义，在本网元之前的叫前向网元(简称前向)，在本网元之后的叫后向网元(简称后向)。图11中的流程是在接收到后向对INVITE请求消息的488或者606响应消息动态触发的TC-AS。如果呼叫过程中，接收到后向对媒体协商UPDATE请求消息的488或者606响应消息，则参照图9做同样的动态触发TC-AS处理。这两种情形都是后向回的488或者606响应消息，触发完成后，AS管理实体把TC-AS加入到已触发AS序列的最后端。这样，后续的响应消息也是先经过TC-AS，使得已触发的AS感知不到后向触发了TC-AS，避免了对已触发AS的影响，。

2)如果呼叫过程中，接收到前向对媒体协商UPDATE请求消息的488或者606响应消息，也是做同样的动态触发TC-AS的处理，区别在于触发完成后，AS管理实体把TC-AS加入到已触发AS序列的最前端。即已触发的AS感知不到前向触发了TC-AS，避免了对已触发AS的影响。

3)在被叫侧，被叫用户被监听，前向或者后向接收到INVITE请求或者UPDATE请求的488或者606响应消息，则参照图9做同样的动态触发TC-AS处理。

4)如果被叫用户B在488或者606消息中没有携带自身支持的媒体编解码格式，则TC-AS指示TC MRFP准备的媒体描述信息中的媒体编码格式为TC MRFP所支持的全部的编解码格式，新的呼叫请求消息即携带这个媒体描述信息。

实施例八

图12是根据本发明实施例八的在IMS网络中实现合法监听的方法流程图，如图12所示，本实施例提供了AS管理实体如何动态的触发LI-AS，实现对主叫侧呼叫异常放音场景下的监听，是对AS管理实体静态的监听触发和管理机制的完善。

根据实施例五里描述的AS管理实体静态触发的基本方案，在主叫侧且为非多方通话业务触发时，LI-AS位于O-AS的后向，此时O-AS如果对主叫用户异常放音，由于LI-AS尚未触发，放音的媒体资源网关和LI MRFP之间没有建立连接，则LI-AS无法监听到这个放音。为了解决这个问题，AS管理实体可以采用下面实施例五动态触发LI-AS的方式进行优化。具体包括如下步骤：

步骤S1201，与步骤S801-S806相同，AS管理实体接收到呼叫请求消息，判断本次S-CSCF的触发请求为主叫侧且为非多方通话业务触发，确定待静态触发的AS序列依次为O-AS、LI-AS、TC-AS；

步骤S1202，AS管理实体触发O-AS，而在O-AS执行业务逻辑时发现需要对主叫用户进行异常放音，比如用户欠费停机或者有呼出限制业务，需要给用户放响应的业务提示音。O-AS先指示MRFP准备放音的媒体：控制协议适配层实体的H.248子系统向MRFP网元发出一个ADD操作命令，指示MRFP网元添加一个RTP，其对端媒体描述信息指向主叫用户A的媒体描述信息 SDP_A，MRFP回复O-AS创建RTP成功，为描述方便，本实例中称之为RTP_MRFP。此时，由于需要监听到这个放音，因此O-AS不再继续完成主叫A和异常放音媒体的媒体协商过程，而是把这一呼叫进展消息以及异常放音媒体RTP_MRFP的媒体描述信息通知AS管理实体，以便由AS管理实体动态触发LI-AS，来实现对这个放音的监听。

步骤S1203，AS管理实体判断主叫用户A被监听。方法同步骤S804。

步骤S1204，AS管理实体创建LI-AS相关数据区，发送呼叫相关信息给LI-AS，其中包括异常放音的媒体RTP_MRFP的媒体描述信息。LI-AS执行监听业务逻辑，方法同步骤S808。LI MRFP创建的监听媒体为：RTP1_LI和RTP2_LI，其中RTP1_LI的对端媒体描述信息指向异常放音媒体RTP_MRFP的媒体描述信息。LI-AS通知AS管理实体LI-AS已完成触发，并把LI MRFP的媒体描述信息发送给AS管理实体。

步骤S1205，AS管理实体把监听媒体的媒体描述信息发送给O-AS。O-AS指示MRFP修改RTP_MRFP的对端媒体描述信息为RTP1_LI的媒体描述信息。这样就完成了监听媒体和异常放音媒体的媒体协商。执行完成后，O-AS通知AS管理实体。

步骤S1206，AS管理实体把主叫用户A的媒体描述信息发送给LI-AS，LI-AS控制修改RTP2_LI的对端媒体描述信息为主叫用户A的媒体描述信息。执行完成后，LI-AS通知AS管理实体。

步骤S1207，AS管理实体通知协议适配层实体的SIP子系统，使用183消息携带RTP2_LI的媒体描述信息给主叫用户A放音。

通过以上步骤，AS管理实体动态触发LI-AS，和正在执行业务逻辑的O-AS一起，完成MRFP上的异常放音媒体和LI MRFP上的监听媒体之间的媒体协商，使得MRFP上的语音包流向LI MRFP，然后再完成LI MRFP上的监听媒体和主叫用户之间的媒体协商，使得LI MRFP上的语音包流向主叫用户，从而监听到该异常放音。

图13是根据本发明实施例八的在IMS网络中实现合法监听方法的媒体连接示意图，如图13所示，异常放音媒体资源处理器上的媒体RTP_MRFP与LI MRFP上的监听媒体RTP1_LI建立连接；监听媒体RTP1_LI与监听媒体RTP2_LI是互通的；监听媒体RTP2_LI与主叫用户A的媒体建立连接。由此，异常放音媒体经过监听资源媒体处理器的转发后与主叫用户A的媒体建立了连接，主叫用户A可以听到这个异常放音。而LI MRFP上的监听媒体RTP1_LI和RTP2_LI分别复制一份媒体，并发送到监听功能提交网关上，实现了对这个异常放音媒体的监听。

在本发明的实施例中，多媒体资源功能控制器MRFC(Multimdia Resource Controller，简称MRFC)功能与各个AS是合设的，即O-AS或者T-AS、LI-AS和TC-AS均可以作为MRFC控制各自的多媒体资源处理器(Multimdia Resource Processor，简称MRFP)。而为描述方便，MFRP按照功能和作用，被叫做相应功能的媒体资源处理器：编解码转换媒体资源处理器(简称TC MRFP)，监听媒体资源处理器(简称LI MRFP)，异常放音媒体资源处理器。

从以上的描述中可知，本发明提供的一种在IMS网络中实现合法监听的技术方案大致如下：

从接收到从S-CSCF发起的，经过协议适配实体解码和适配的呼叫请求消息开始，AS管理实体先根据MO或者MT的指示、是否多方通话业务、是否被监听、是否需要预先编解码转换等信息，进行判断和分析，确定一个待静态触发的AS序列；

然后AS管理实体依次触发AS序列中的AS，完成监听媒体和编解码转换媒体的准备。触发某个AS时，呼叫的相关信息发送给AS，AS执行各自的业务逻辑修改了呼叫的相关信息后，再回送给AS管理实体，AS管理实体更新并保存这些信息。待触发AS序列中的AS全部触发完成后，把呼叫请求消息环回到S-CSCF，呼叫继续；

再然后AS管理实体管理呼叫请求消息之后的振铃、应答等后续呼叫消息 的传递和发送，完成主被叫媒体、监听媒体和编解码转换媒体之间的媒体协商，使主被叫通过编解码转换后可建立通话，并且通话可被监听

最后，AS管理实体根据呼叫过程中的特殊场景动态触发LI-AS，或者根据收到的异常响应消息动态触发TC-AS，AS管理实体把动态触发的AS加入到已触发AS序列，并重新排序；管理后续消息的传递和发送顺序，完成整个呼叫。

通过以上步骤，在AS管理实体对O-AS或者T-AS、LI-AS、TC-AS静态和动态两种触发方式的有效管理下，实现了预先TransCoding和媒体协商失败后TransCoding两种呼叫场景下的合法监听，扩大了合法监听的监听范围。

基于上述技术方案，本发明达到了如下技术效果：

1)本发明通过AS管理实体对O-AS或者T-AS、LI-AS、TC-AS静态和动态两种触发管理机制，实现了预先TransCoding和媒体协商失败后TransCoding两种呼叫场景下的合法监听，扩大了合法监听的监听范围。

2)本发明提供的技术方案中，各个AS逻辑上相互独立，结构清晰，模块耦合性低，便于维护和扩展。

3)本发明提供的技术方案中，对S-CSCF只呈现出一个应用服务器，一次触发就可以实现业务、监听和编解码转换，减少了网元间消息的交互，保证了整个IMS系统运行的性能和效率不会下降。

4)本发明提供的方法不改变IMS系统的处理规则，对已有IMS系统不会造成任何影响，有效保证了本发明方法的可实施性，以及向后兼容性。

尽管为示例目的，已经公开了本发明的优选实施例，本领域的技术人员将意识到各种改进、增加和取代也是可能的，因此，本发明的范围应当不限于上述实施例。