专利名称：叉簧类业务的处理方法和应用服务器的制作方法
技术领域：
本发明涉及数据网络通信领域，尤其涉及一种叉簧类业务的处理方法和应用服务O
背景技术：
IP 多媒体子系统(IP Multimedia Core Network Subsystem，简称为 IMS)是由 第三代合作伙伴计划(3rd Generation Partnership Pro ject，简称3GPP)组织提出的一 种基于IP的网络架构，其构建了一个开放而灵活的业务环境，支持多媒体应用，并为用户 提供丰富的多媒体业务。仿真子系统(公共交换电话网络(Public Switched Telephone Network，简称为 PSTN)/综合业务数字网 Qntegrated Services Digital Network，简称 为ISDN)Emulation Subsystem，简称为PES)则是电信和互联网融合业务及高级网络协议 (Telecommunications and Internet converged Services and Protocols for Advanced Networking，简称为TISPAN)将传统终端接入IMS网络提出的一种基于IP的网络架构。下面对现有技术中接入网关控制功能(Access Gateway Control Function，简称 为AGCF)用户叉簧业务的紧耦合实现方式进行简单的描述。在AGCF实现紧耦合方式的叉簧业务的过程中，需要判断业务的触发类型，并根据 不同的触发类型进行相应的逻辑控制处理。并且，当AGCF用户为业务用户时，在多方业务 通话、呼叫等待、呼叫转移等过程中，只要AGCF用户还有多个远端用户与之对应，则需要在 网络中(例如，在AGCF与应用服务器(Application Server，简称为AS)之间)建立并保持 与每个远端对应的多个呼叫(可称为呼叫)，而且这些呼叫往往仍然需要进行周期性的呼 叫检测。这样就增加了网络中网元之间的消息交互和网元的业务实现复杂度，并且会降低 网元的性能。针对相关技术中，实现叉簧类业务时，非核心控制网元(例如AGCF、P_CSCF、终端) 需要管理复杂的多方业务逻辑、长时间保留不必要的会话，所导致的非核心控制网元实现 复杂、增加网络负担的问题，目前尚未提出有效的解决方案。
发明内容
针对相关技术中叉簧类业务的处理复杂度高、效率低的问题，本发明提出一种叉 簧类业务的处理方法，能够以简单的方式实现叉簧类业务，并降低网络负担。针对相关技术中叉簧类业务的处理复杂度高、效率低的问题，本发明还提出一种 应用服务器，能够以简单的方式实现叉簧类业务，并降低网络负担。本发明的技术方案是这样实现的一种叉簧类业务的处理方法，包括在用户触发拍叉簧操作的情况下，应用服务器将与所述用户相关的全部呼叫中的 部分呼叫取消，其中，所述呼叫表示用户与所述应用服务器之间已经建立和待建立的呼叫。其中，所述网络中的呼叫包括应用服务器与所述用户归属的接入网关控制功能实体之间已经建立和待建立的呼叫。其中，取消所述部分呼叫的处理具体包括所述应用服务器接收由所述接入网关控制功能实体发送的所述用户的标识；所述应用服务器根据所述标识查找所述全部呼叫，并将查找到的所述全部呼叫中 的部分呼叫释放。优选地，释放所述部分呼叫的处理具体包括在所述用户触发所述拍叉簧操作之后，所述应用服务器根据所述用户的命令执行 相应的叉簧业务，并在所述叉簧业务完成后进行所述部分呼叫的释放。优选地，释放所述部分呼叫的处理具体包括在所述用户触发所述拍叉簧操作之后、所述应用服务器根据所述用户的命令执行 相应的叉簧业务之前，所述应用服务器释放所述全部呼叫中的部分呼叫。优选地，释放所述部分呼叫的处理具体包括在所述用户触发所述拍叉簧操作时，所述应用服务器释放所述全部呼叫中的部分 呼叫。其中，所述叉簧业务包括呼叫等待业务、呼叫转移业务、多方会议业务等其它类 似业务。优选地，释放的所述部分呼叫的数量为N-1，其中，N为所述全部呼叫的数量。一种应用服务器，用于在用户触发拍叉簧操作的情况下，将与所述用户相关的全 部呼叫中的部分呼叫释放，其中，所述全部呼叫是指网络中，业务用户与应用服务器之间的 已经建立和正在建立的呼叫。借助于本发明的上述技术方案，通过在呼叫的任何紧耦合流程中，保留网络中的 部分呼叫连接，并将其余的呼叫释放，从而能够降低网元处理叉簧业务的复杂度，减少网元 之间的消息交互量，有利于提高网元的性能，节省网络资源，能够广泛适用于各种拍叉簧业 务。
图1是根据本发明实施例的叉簧类业务的处理方法的步骤流程图；图2是根据现有技术的ETSI 183. 043中的呼叫等待业务的处理流程图；图3是根据本发明实施例的呼叫等待业务的流程图；图4是根据现有技术的ETSI 183. 043中的三方业务的处理流程图；图5为本发明提供的三方业务的处理流程图。
具体实施例方式为了解决叉簧类业务处理复杂度高、呼叫检测在网元之间的消息交互量大的问 题，本发明提供了不同于ETSI 183. 043的AGCF用户叉簧业务的紧耦合实现方式，最大程度 上减少网络中的呼叫检测，能够适用于各种不同紧耦合实现方式的叉簧业务(例如，包括 呼叫等待业务、呼叫转移业务、多方会议业务等)。图1是本发明实施例的叉簧类业务的处理方法的步骤流程图，如图1所示，包括以 下处理
步骤S101，在用户触发拍叉簧操作的情况下，应用服务器确定与用户相关的全 部呼叫，其中，呼叫表示用户与应用服务器之间已经建立和待建立的呼叫。其中，拍叉簧 操作即可以是传统终端的拍叉动作，也可以是拍叉动作后在系统提示下的拨号操作，还 可以是会话初始化协议(Session Initiation Protocol，简称为SIP)、综合业务数字网 (Integrated Services Digital Network, ISDN)等终端发起的转接、3方、会议，或呼叫等 待中进行的会话切换等操作，呼叫可以为语音会话，也可以为视频会话。步骤S102，AS将与用户相关的全部呼叫中的部分呼叫释放。其中，呼叫可以存在于网络中的多个位置，本发明关注的呼叫主要位于AS与非核 心控制网元(例如AGCF、P-CSCF、终端)之间，例如，呼叫可以包括以下之一 AS与用户归属 的AGCF之间已经建立和待建立的呼叫、AS与P-CSCF之间已经建立和待建立的呼叫、AS与 终端之间已经建立和待建立的呼叫、下面将以AGCF与AS之间的呼叫为例，描述本发明对叉 簧类业务的处理过程。在具体实现过程中，用户触发拍叉簧操作，AGCF判断出该用户触发拍叉簧操作，会 将该用户的用户标识发送给AS ；之后，AS根据该用户标识查找与该用户相关的AS与AGCF 之间全部呼叫，并将查找到的全部呼叫中的部分呼叫释放。优选地，释放的部分呼叫的数量 可以根据实际需要进行配置，优选地，可以释放N-I个呼叫，其中，N为全部呼叫的数量，即， 可以仅保留AS与AGCF之间的一个呼叫(该呼叫可以是已有呼叫，也可以是正在建立且未 释放的呼叫)，其他呼叫全部释放。可选地，释放部分呼叫的处理可以在用户触发拍叉簧操作之后执行。具体地，在用 户触发拍叉簧操作之后，AS可以根据用户的命令执行相应的叉簧业务，并在叉簧业务完成 后进行部分呼叫的释放。其中，拍叉簧业务可以包括呼叫等待业务、呼叫转移业务、多方会 议业务等。也就是说，假设用户1和用户2正在通话，此时AS与AGCF之间存在对应于用户 1与用户2呼叫的呼叫连接，如果此时用户3呼叫用户1，用户1可以选择与用户2或用户 3通话，也可以让用户2和用户3 —同进行多方会议，AS与AGCF之间就会建立新的呼叫，此 时就可以将AS与AGCF之间对应于用户1和用户2的呼叫，以及对应于用户1和用户3的 呼叫删除。可选地，还可以在用户触发拍叉簧操作时，AS取消全部呼叫中的部分呼叫。S卩，如 果用户3在用户1与用户2进行通话期间呼叫用户1，在用户1拍叉簧后，AS可以直接删除 其与AGCF之间对应于用户1和用户2的呼叫，也可以取消其与AGCF之间对应于用户1和 用户3的呼叫建立。另外，可选地，在用户触发拍叉簧操作之后、AS根据用户的命令执行相应的叉簧业 务之前的任意时间点，AS释放全部呼叫中的部分呼叫，即，删除已有的呼叫和/或释放政治 建立的呼叫，仅在AS与AGCF之间保留较少数量的呼叫。并且，在进行呼叫释放时，可以不考虑已有呼叫的数量，也就是说，可以在AS与 AGCF之间已经存在与用户1相关的5条呼叫的情况下删除其中的4 (或小于5的其他数量) 条呼叫，也可以在第6条呼叫准备建立时取消这六条呼叫中的一部分呼叫。此外，如果AS 可以顺利的实现关联呼叫的查找，也可以在AGCF没建新的呼叫时就释放原来的呼叫，以简 化AGCF的控制，可以用一个基本呼叫来实现叉簧业务。通过上述处理，能够在呼叫的任何紧耦合流程中，保留AS与AGCF之间的部分呼叫连接，其余AGCF与AS之间的呼叫将在业务实现的过程中相继由AS控制释放，从而能够降 低AGCF与AS查找和处理关联呼叫的复杂度；并且，由于减少了 AGCF与AS之间的消息交 互，有利于提高AGCF的性能，增加网络资源。本领域技术人员应当能够理解，在采用本发明的处理后，不仅能够减少AS与AGCF 之间的呼叫检测，对于网络中其他网元之间存在的呼叫检测同样能够进行简化，从而达到 降低网络复杂度和处理负担、减少网络中消息交互的目的。以下结合附图对本发明的优选实施例进行说明，应当理解，此处所描述的优选实 施例仅用于说明和解释本发明，并不用于限定本发明。在下列附图中，D(非业务用户侧)和D’(业务用户所在的AGCF与CSCF之间的对 话索引)表示各个编号标识对应的对话(或成为会话、呼叫)索引，且与各自对应的消息共 同表示该消息所存在的对话。图2是根据现有技术的ETSI 183. 043中的呼叫等待业务的处理流程图，如图2所 示，包括以下处理步骤S201，AGCF用户A与用户B (用户B可以为AGCF用户，也可以不为AGCF用 户)之间已经建立通话。步骤S202至步骤S204，用户C呼叫用户A，具体地，用户C经由AS和S-CSCF将呼 叫请求发送至AGCF，其中，该呼叫请求可以为SIP协议的invite消息(会话邀请)。步骤S205，AGCF判断出用户A用户处于忙状态(用户A正在与用户B通话)，在 AGCF的控制下PES网络给用户A放回铃音或等待提示音。步骤S206至步骤S208，AGCF经由S_CSCF、AS向用户C发送临时响应消息，其中， 该临时响应消息可以为SIP协议的18x消息(振铃响应)。步骤S209，用户A拍叉簧，AGCF接收到叉簧类事件，该叉簧事件可以为H248协议 的NOTIFY消息。步骤S210至步骤S211，AGCF经由S-CSCF向AS网元发送会话邀请消息，该会话邀 请消息中可以携带有用户A的标识，其中，该会话邀请消息可以为SIP协议的invite消息。步骤S212至步骤S213，由于该会话邀请消息中没有携带有效的被叫URI，且AS不 能根据叉簧事件确定业务流程，这时，AS经由CSCF向AGCF发送号码不全的失败响应消息， 其中，该失败响应消息可以为SIP协议的484消息。步骤S214，在AGCF的控制下PES网络给用户A放拨号提示音。步骤S215，用户A接收到拨号提示音之后，可以根据自己的意愿向AGCF拨入相应 的号码。步骤S216至步骤S217，AGCF根据接收到的步骤S215中的拨入号码，AGCF经由 S-CSCF向AS发送会话邀请消息，该会话邀请消息中携带有拨入号码，其中，该会话邀请消 息可以为SIP协议的invite消息。步骤S218，AS根据invite消息中携带的拨入号码判断业务逻辑。例如，AS判断 出用户A准备应答用户C，且保持用户B。AS经由S-CSCF向发送AGCF新的呼叫应答消息， 其中，该呼叫应答消息可以为SIP协议的200 ok消息。需要说明的是，在该步骤中，AS会 根据invite消息中携带的拨入号码，进行相应的业务逻辑判断，并做不同的处理，选择与C 通话并保持B仅为其中的一种业务逻辑，其余的业务流程与此类似，这里不再详细描述。
步骤S219，AS向用户B发送保持请求，其中，该保持请求可以为SIP协议的 re-invite 消息。步骤S220，用户B接收到上述保持请求，可以听到保持音，并向AS发送保持响应消 息，其中，该保持响应消息可以为200ok消息。步骤S221至步骤S222，AGCF经由S-CSCF和AS向用户C发送应答相应消息、C用 户回确认消息，其中，该应答相应消息可以为SIP协议的200ok;之后，用户C经由S-CSCF和 AS向AGCF发送应答，AGCF回确认消息。步骤S223，在AS的控制下，实现用户A和用户C的媒体协商，实现用户A和用户C 的通话。步骤S2M至步骤S225，AS经由S-CSCF发起释放AGCF为呼叫等待业务创建的新 呼叫。步骤，AGCF与AS之间进行会话检测(Dl，)。步骤S227，AGCF与AS之间进行会话检测(D2’)。需要说明的是，在上述流程中，如果AS能够仅仅依靠叉簧事件业务流程(比如判 断出是用户准备应答C，保持B)或者由AS自己控制媒体服务器实现收号，则不需要执行步 骤S212至步骤S217。图3是根据本发明实施例的呼叫等待业务的实现流程图，如图3所示，包括以下处 理步骤S301，AGCF用户A与用户B (用户B可以为AGCF用户，也可以不为AGCF用 户)之间已经建立通话。步骤S302至步骤S304，用户C呼叫用户A，具体地，用户C经由AS和S-CSCF将呼 叫请求发送至AGCF，其中，该呼叫请求可以为SIP协议的invite消息(会话邀请)。步骤S305，AGCF判断出用户A用户处于忙状态(用户A正在与用户B通话)，在 AGCF的控制下PES网络给用户A放回铃音或等待提示音。步骤S306至步骤S308，AGCF经由S_CSCF、AS向用户C发送临时响应消息，其中， 该临时响应消息可以为SIP协议的18x消息(振铃响应)。步骤S309，用户A拍叉簧，AGCF接收到叉簧类事件，该叉簧事件可以为H248协议 的NOTIFY消息。步骤S310至步骤S311，AGCF经由S-CSCF向AS网元发送会话邀请消息，该会话邀 请消息中可以携带有用户A的标识，其中，该会话邀请消息可以为SIP协议的invite消息。步骤S312至步骤S313，由于该会话邀请消息中没有携带有效的被叫URI，且AS在 不能根据叉簧事件确定业务流程，这时，AS经由CSCF向AGCF发送号码不全的失败响应消 息，其中，该失败响应消息可以为SIP协议的484消息。步骤S314，在AGCF的控制下PES网络给用户A放拨号提示音。步骤S315，用户A接收到拨号提示音之后，可以根据自己的意愿向AGCF拨入相应 的号码。步骤S316至步骤S317，AGCF根据接收到的步骤S315中的拨入号码，AGCF经由 S-CSCF向AS发送会话邀请消息，该会话邀请消息中携带有拨入号码，其中，该会话邀请消 息可以为SIP协议的invite消息。
步骤S318，AS向用户B发送保持请求，其中，该保持请求可以为SIP协议的 re-invite 消息。步骤S319，用户B接收到上述保持请求，可以听到保持音，并向AS发送保持响应消 息，其中，该保持响应消息可以为200ok消息。步骤S320至步骤S321，AS分别给用户C(D2)和AGCF(AGCF创建的新呼叫D3，)发 送应答响应消息，该应答响应消息可以为SIP协议的200ok消息，用户C(D2)和AGCF(D3’) 回确认消息。步骤S322，在AS的控制下，进行用户A和用户C的媒体协商，实现用户A和用户C 之间的通话。步骤S323至步骤，AS发起释放AGCF与AS之间的A-B呼叫，从而减少了呼叫的数量。步骤S327，AGCF与AS之间进行会话检测(D3，)。需要说明的是，在上述流程中，如果AS能够仅仅依靠叉簧事件就能够判断业务逻 辑(比如判断出是用户准备应答C，保持B)或者由AS自己控制媒体服务器实现收号，则不 需要执行S312至步骤S317。通过将图3与图2所示的处理相比较即可看出，步骤S323至步骤，As释放了 AGCF与AS之间的A-B与A-C呼叫，当然，也可以在步骤S311与步骤S323之间的任何时间 点释放这两个呼叫。图4是根据现有技术的ETSI 183. 043中实现三方业务的处理流程图，如图4所 示，包括以下步骤步骤S401，AGCF用户A与用户B (用户B可以为AGCF用户，也可以不为AGCF用 户)之间已经建立通话。步骤S402，用户A拍叉簧，AGCF接收到叉簧类事件，该叉簧事件可以为H248协议 的NOTIFY消息。步骤S403至步骤S404，AGCF经由S-CSCF向AS网元发送会话邀请消息，该会话邀 请消息中携带有用户A的标识，其中，该会话邀请消息可以为SIP协议的invite消息。步骤S405，AS向用户B发送保持请求，其中，该保持请求可以为SIP协议的 re-invite 消息。步骤S406，用户B接收到上述保持请求，可以听到保持音，并向AS发送保持响应消 息，其中，该保持响应消息可以为200ok消息。步骤S407至步骤S408，由于AS在步骤S404中接收到的会话邀请消息中没有有 效的被叫URI，AS经由S-CSCF向AGCF发送号码不全的失败响应，其中，该失败响应可以为 SIP协议的484消息。步骤S409，在AGCF的控制下PES网络给用户A放拨号提示音。步骤S410，用户A接收到拨号提示音之后，可以根据自己的意愿向AGCF拨入相应 的号码。步骤S411至步骤S412，AGCF根据接收到的步骤S410中的拨入号码，AGCF经由 S-CSCF向AS发送会话邀请消息，该会话邀请消息中携带有拨入号码，其中，该会话邀请消 息可以为SIP协议的invite消息。
步骤S413，AS根据会话邀请消息中的被叫号向用户C发起呼叫。步骤S414，在AS的控制下，执行现有技术的相关操作后实现A与C的通话。步骤S415，用户A拍叉簧，AGCF接收到叉簧类事件，该叉簧事件可以为H248协议 的NOTIFY消息。步骤S416至步骤S417，AGCF经由S-CSCF向AS网元发送会话邀请消息，该会话邀 请消息中携带有用户A的标识，其中，该会话邀请消息可以为SIP协议的invite消息。步骤S418，AS向用户C发送保持请求，其中，该保持请求可以为SIP协议的 re-invite 消息。步骤S419，用户C接收到上述保持请求，可以听到保持音，并向AS发送保持响应消 息，其中，该保持响应消息可以为200ok消息。步骤S420至步骤S421，由于接收到的会话邀请消息中没有有效的被叫URI，AS通 过CSCF向AGCF发送号码不全的失败响应，其中，该失败响应可以为SIP协议的484消息。 这里，如果AS能够仅仅依靠叉簧事件能够判断出业务逻辑(比如进入3方通话)，或者由 AS自己控制媒体服务器实现收号，则不需要执行步骤S420至步骤S425。步骤S422，在AGCF的控制下PES网络给用户A放拨号提示音。步骤S423，用户A接收到拨号提示音之后，可以根据自己的意愿向AGCF拨入相应 的号码。步骤S4M至步骤S425，AGCF利用接收到的拨入号码经由S-CSCF向AS网元发会 话邀请消息，其中，该会话邀请消息可以为SIP协议的invite消息。步骤S似6，AS通过S-CSCF为AGCF创建新的呼叫回应答消息，其中，该呼叫回应答 消息可以为SIP协议的200ok消息，AGCF向AS发送呼叫应答确认消息。步骤S427，在AS的控制下，将用户A、用户B、用户C加入到三方会议中。步骤S429，AS释放AGCF创建的新呼叫。步骤S430，AGCF与AS之间进行会话检测(Dl，)。步骤S431，AGCF与AS之间进行会话检测(D3，)。需要说明的是，在上述流程中，如果由AS自己控制媒体服务器实现收号，则不需 要执行步骤S407至步骤S412。图5为根据本发明实施例的多方会议业务的实现流程图。如图5所示，步骤S501，AGCF用户A与用户B (用户B可以为AGCF用户，也可以不为AGCF用 户)之间已经建立通话。步骤S502，用户A拍叉簧，AGCF接收到叉簧类事件，该叉簧事件可以为H248协议 的NOTIFY消息。步骤S503至步骤S504，AGCF经由S-CSCF向AS网元发送会话邀请消息，该会话邀 请消息中携带有用户A的标识，其中，该会话邀请消息可以为SIP协议的invite消息。步骤S505，AS向用户B发送保持请求，其中，该保持请求可以为SIP协议的 re-invite 消息。步骤S506，用户B接收到上述保持请求，可以听到保持音，并向AS发送保持响应消 息，其中，该保持响应消息可以为200ok消息。步骤S507至步骤S508，由于AS在步骤S504中接收到的会话邀请消息中没有有效的被叫URI，AS经由S-CSCF向AGCF发送号码不全的失败响应，其中，该失败响应可以为SIP 协议的484消息。这里，如果由AS自己控制媒体服务器实现收号，则不需要执行步骤S507 至步骤S512。步骤S509，在AGCF的控制下PES网络给用户A放拨号提示音。步骤S510，用户A接收到拨号提示音之后，可以根据自己的意愿向AGCF拨入相应 的号码。步骤S511至步骤S512，AGCF根据接收到的步骤S510中的拨入号码，AGCF经由 S-CSCF向AS发送会话邀请消息，该会话邀请消息中携带有拨入号码，其中，该会话邀请消 息可以为SIP协议的invite消息。步骤S513，AS根据会话邀请消息中的被叫号向用户C发起呼叫。步骤S514，在AS的控制下，执行现有技术的相关操作后实现A与C的通话。步骤S515，AS释放AGCF与AS之间的A-B呼叫。步骤S516，用户A拍叉簧，AGCF接收到叉簧类事件，该叉簧事件可以为H248协议 的NOTIFY消息。步骤S517至步骤S518，AGCF经由S-CSCF向AS网元发送会话邀请消息，该会话邀 请消息中携带有用户A的标识，其中，该会话邀请消息可以为SIP协议的invite消息。步骤S519，AS向用户B发送保持请求，其中，该保持请求可以为SIP协议的 re-invite 消息。步骤S520，用户B接收到上述保持请求，可以听到保持音，并向AS发送保持响应消 息，其中，该保持响应消息可以为200ok消息。步骤S521至步骤S522，由于接收到的会话邀请消息中没有有效的被叫URI，AS通 过CSCF向AGCF发送号码不全的失败响应，其中，该失败响应可以为SIP协议的484消息。 这里，如果AS能够仅仅依靠叉簧事件能够判断出业务逻辑(比如进入3方通话)，或者由 AS自己控制媒体服务器实现收号，则不需要执行步骤S521步骤步骤S523，在AGCF的控制下PES网络给用户A放拨号提示音。
步骤S5M，用户A接收到拨号提示音之后，可以根据自己的意愿向AGCF拨入相应 的号码。步骤S525至步骤，AGCF利用接收到的拨入号码经由S-CSCF向AS网元发会 话邀请消息，其中，该会话邀请消息可以为SIP协议的invite消息。步骤S527至步骤，在AS的控制下，将用户A、用户B、用户C加入到三方会议中。步骤S529, AS释放AGCF与AS之间的A-C呼叫。步骤S530，AGCF与AS之间进行会话检测(D5，)。通过将图5与图4所示的处理相比较即可看出，在步骤S515中，As释放了 AGCF与 AS之间的A-B、A-C呼叫，也可以在步骤S503与步骤S514之间的任何时间点释放该呼叫。根据本发明的基本原理，上述实施例通过合理的组合、变化与使用，能够适用于 AGCF用户的不同注册和业务管理方式，例如，在AS与非业务用户侧(AGCF侧)的网元的交 互流程与消息，可以根据的AS控制策略做适当的调整。当叉簧业务中AGCF创建一个叉簧呼叫时，AS就发起释放与AGCF中的叉簧业务用10户原来所存在的呼叫的实现方法。其主要体现在释放流程提前，其它无区别，所以没有另用 附图与流程给予描述。应当注意，尽管之前参照附图及流程只描述了呼叫等待和3方业务的个别典型流 程，但是本领域的技术人员应当理解，其他叉簧业务均可以采用根据本发明的方法对不必 要长期存在的呼叫进行释放，其它流程与相关规范中所规定的流程相同，本文不再一一列 举和详述。在以上描述中以举例的方式列举了 AGCF、S-CSCF, AS网元及其间传输的消息，其 目的是为了清楚的表示PES网络支持AGCF用户叉簧类业务实现的思想，而本发明的实现过 程并不局限于这些网元和消息。并且，对于各种流程中出现的异常情况、在适当的情况下可 以改变某些消息的先后顺序、以及网元内部的具体实现，本发明对此并不做具体的限制。以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精 神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
权利要求
1.一种叉簧类业务的处理方法，其特征在于，包括在用户触发拍叉簧操作的情况下，应用服务器将与所述用户相关的全部呼叫中的部分 呼叫取消，其中，所述呼叫表示用户与所述应用服务器之间已经建立和待建立的呼叫。
2.根据权利要求1所述的方法，所述呼叫包括应用服务器与所述用户归属的接入网 关控制功能实体之间已经建立和待建立的呼叫。
3.根据权利要求2所述的方法，其特征在于，取消所述部分呼叫的处理具体包括 所述应用服务器接收由所述接入网关控制功能实体发送的所述用户的标识；所述应用服务器根据所述标识查找所述全部呼叫，并将查找到的所述全部呼叫中的部 分呼叫释放。
4.根据权利要求1所述的方法，其特征在于，所述部分呼叫的处理具体包括在所述用户触发所述拍叉簧操作之后，所述应用服务器根据所述用户的命令执行相应 的叉簧业务，并在所述叉簧业务完成后进行所述部分呼叫的释放。
5.根据权利要求1所述的方法，其特征在于，取消所述部分呼叫的处理具体包括在所述用户触发所述拍叉簧操作之后、所述应用服务器根据所述用户的命令执行相应 的叉簧业务之前，所述应用服务器取消所述全部呼叫中的部分呼叫。
6.根据权利要求1所述的方法，其特征在于，取消所述部分呼叫的处理具体包括 在所述用户触发所述拍叉簧操作时，所述应用服务器取消所述全部呼叫中的部分呼叫。
7.根据权利要求3或4所述的方法，其特征在于，所述拍叉簧业务包括呼叫等待业 务、呼叫转移业务、多方会议业务。
8.根据权利要求1至5中的任一项所述的方法，其特征在于，释放的所述部分呼叫的数 量为N-I，其中，N为所述业务用户所创建的全部呼叫的数量。
9.一种应用服务器，其特征在于，所述应用服务器用于在用户触发拍叉簧操作的情况 下，将与所述用户相关的全部呼叫中的部分呼叫取消，其中，所述呼叫表示用户与所述应用 服务器之间已经建立和待建立的呼叫。
10.根据权利要求9所述的应用服务器，其特征在于，所述呼叫包括应用服务器与所 述用户归属的接入网关控制功能实体之间已经建立和待建立的呼叫。
全文摘要
本发明公开了一种叉簧类业务的处理方法和应用服务器，其中，该方法包括在用户触发拍叉簧操作的情况下，应用服务器将与用户相关的全部呼叫中的部分呼叫取消，其中，呼叫表示用户与应用服务器之间已经建立和待建立的呼叫。借助于本发明的上述技术方案，通过在呼叫的任何紧耦合流程中，保留网络中的部分呼叫连接，并将不必要的呼叫释放，从而能够降低网元处理叉簧类业务的复杂度，减少网元之间的消息交互量，有利于提高网元的性能，节省网络资源，能够广泛适用于各种拍叉簧业务。
文档编号H04L29/06GK102055756SQ200910236909
公开日2011年5月11日 申请日期2009年10月27日 优先权日2009年10月27日
发明者杨强, 王忱 申请人:中兴通讯股份有限公司