呼叫处理方法及装置与流程

本发明涉及通信技术，尤其涉及一种呼叫处理方法及装置。

背景技术：

在通信系统的演进过程中，新旧系统的通信网络往往需要共存一定时间，发展用户是往往需要考虑到支持新系统的终端和号码以及和旧系统的兼容性，因此同时支持两张卡，多种模式的双卡双待终端也应运而生。

对于使用双卡双待终端来说，每次发起呼叫时，都需要用户根据各卡的当前使用状况来手动选择使用哪一张卡进行呼叫，操作繁琐，效率低下，给用户带来不便。

技术实现要素：

本发明提供一种呼叫处理方法及装置，用以解决现有技术中用户每次发起呼叫时都需要手动选择进行本次呼叫的卡导致的呼叫效率低下的技术问题。

本发明提供一种呼叫处理方法，包括：

向应用服务器发送订阅请求，以使所述应用服务器根据所述订阅请求向业务运营支持系统发送查询请求，从而订阅各卡的业务状态；

接收所述业务运营支持系统根据所述查询请求通过所述应用服务器返回的至少一个卡的业务状态信息；

当需要发起呼叫时，根据所述至少一个卡的业务状态信息，确定发起呼叫的卡。

进一步地，根据所述至少一个卡的业务状态信息，确定发起呼叫的卡，包括：

根据所述至少一个卡的业务状态信息，判断是否能够确定语音套餐余量最多的卡；

若能够确定语音套餐余量最多的卡，则以所述语音套餐余量最多的卡发起呼叫。

进一步地，在向应用服务器发送订阅请求之前，还包括：

接收用户输入的余量预设阈值；

相应地，所述订阅请求中携带有所述余量预设阈值，以使所述业务运营支持系统在卡的语音套餐余量小于或等于所述余量预设阈值时发送所述业务状态信息；

所述根据所述至少一个卡的业务状态信息，判断是否能够确定语音套餐余量最多的卡，包括：

若多个卡中仅有一个未接收到业务状态信息，则判断所述未接收到业务状态信息的卡为语音套餐余量最多的卡，反之则判断不能确定语音套餐余量最多的卡。

进一步地，所述方法还包括：

若不能确定语音套餐余量最多的卡，则获取各卡的无线制式信息；

根据各卡的无线制式信息，确定发起呼叫的卡。

进一步地，所述方法还包括：

若不能确定语音套餐余量最多的卡，则确定正在进行数据业务的卡，并以所述正在进行数据业务的卡作为发起呼叫的卡。

本发明还提供一种呼叫处理装置，包括：

发送模块，用于向应用服务器发送订阅请求，以使所述应用服务器根据所述订阅请求向业务运营支持系统发送查询请求，从而订阅各卡的业务状态；

接收模块，用于接收所述业务运营支持系统根据所述查询请求通过所述应用服务器返回的至少一个卡的业务状态信息；

确定模块，用于在需要发起呼叫时，根据所述至少一个卡的业务状态信息，确定发起呼叫的卡。

进一步地，所述确定模块，包括：

判断单元，用于在需要发起呼叫时，根据所述至少一个卡的业务状态信息，判断是否能够确定语音套餐余量最多的卡；

呼叫单元，用于在能够确定语音套餐余量最多的卡时，以所述语音套餐余量最多的卡发起呼叫。

进一步地，所述发送模块还用于：在向应用服务器发送订阅请求之前，接收用户输入的余量预设阈值；

相应地，所述订阅请求中携带有所述余量预设阈值，以使所述业务运营支持系统在卡的语音套餐余量小于或等于所述余量预设阈值时发送所述业务状态信息；

所述判断单元具体用于：在需要发起呼叫时，若多个卡中仅有一个未接收到业务状态信息，则判断所述未接收到业务状态信息的卡为语音套餐余量最多的卡，反之则判断不能确定语音套餐余量最多的卡。

进一步地，所述呼叫单元还用于：

若不能确定语音套餐余量最多的卡，则获取各卡的无线制式信息；

根据各卡的无线制式信息，确定发起呼叫的卡。

进一步地，所述呼叫单元还用于：

若不能确定语音套餐余量最多的卡，则确定正在进行数据业务的卡，并以所述正在进行数据业务的卡作为发起呼叫的卡。

本发明提供的呼叫处理方法及装置，通过向应用服务器发送订阅请求，以使所述应用服务器根据所述订阅请求向业务运营支持系统发送查询请求，从而订阅各卡的业务状态，并接收所述业务运营支持系统根据所述查询请求通过所述应用服务器返回的至少一个卡的业务状态信息，在需要发起呼叫时，根据所述至少一个卡的业务状态信息，确定发起呼叫的卡，无需用户手动进行选择，简化了呼叫操作，提高了呼叫效率，为用户提供了便利。

附图说明

图1为本发明实施例一提供的呼叫处理方法的流程图；

图2为本发明实施例二提供的呼叫处理方法的流程图；

图3为本发明实施例三提供的呼叫处理方法的流程图；

图4为本发明实施例四提供的呼叫处理装置的结构框图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在本申请实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本发明。在本申请实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。

应当理解，本文中使用的术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

取决于语境，如在此所使用的词语“如果”、“若”可以被解释成为“在……时”或“当……时”或“响应于确定”或“响应于检测”。类似地，取决于语境，短语“如果确定”或“如果检测(陈述的条件或事件)”可以被解释成为“当确定时”或“响应于确定”或“当检测(陈述的条件或事件)时”或“响应于检测(陈述的条件或事件)”。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的商品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种商品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的商品或者系统中还存在另外的相同要素。

实施例一

本发明实施例一提供一种呼叫处理方法。图1为本发明实施例一提供的呼叫处理方法的流程图。如图1所示，本实施例中的呼叫处理方法，可以包括：

步骤101、向应用服务器发送订阅请求，以使所述应用服务器根据所述订阅请求向业务运营支持系统发送查询请求，从而订阅各卡的业务状态。

本实施例中方法的执行主体可以为用户设备，所述用户设备可以为手机、平板设备等，所述用户设备中设置有至少两张卡，相应的，所述用户设备为多卡多待终端，例如，若用户设备中设置有两张卡，则所述用户设备为双卡双待终端，若设置有三张卡，则所述用户设备为三卡三待终端。

本实施例中，用户设备的功能可以基于IP多媒体子系统(IP Multimedia Core Network Subsystem，IMS)来实现，IMS是由第三代合作伙伴计划(3rd Generation Partnership Project，3GPP)提出的一种基于IP的网络架构，构建了一个开放而灵活的业务环境，支持多媒体应用，能够为用户提供丰富的多媒体业务。在IMS体系中，控制层和业务层是分离的，控制层不提供具体业务，只负责向业务层提供必要的触发、路由和计费等控制功能。控制层的控制功能是由呼叫会话控制功能(Call Session Control Function，简称CSCF)完成的。CSCF分为代理呼叫会话控制功能(Proxy Call Session Control Function，P-CSCF)、查询呼叫会话控制功能(Interrogating Call Session Control Function，I-CSCF)和服务呼叫会话控制功能(Serving Call Session Control Function，S-CSCF)三种类型。业务层由应用服务器(Appl ication Server，AS)组成，能提供具体业务服务。S-CSCF根据用户的签约信息控制业务触发，调用AS上的业务，实现业务功能。AS和S-CSCF可以统称为服务设备(Server Equipment，简称SE)。会话中的端到端设备称为用户设备(User Equipment，UE)，负责与使用者的交互。在IMS中各功能实体之间使用SIP(初始会话协议)进行通讯。SIP协议的灵活扩展性保证了终端能够基于IP添加新的功能。

SIP协议中的订阅流程：

所谓事件通告机制是指网络中的一些实体可以订阅网络中某些资源或呼叫的状态信息，当那些被订阅的资源的状态发生改变时，负责这一资源的网络实体将向订阅者发送通告，通报当前资源状态的变化情况。在规范中定义了两个扩展方法：订阅(SUBSCRIBE)和通告(NOTIFY)。SUBSCRIBE方法用于发起订阅请求，NOTIFY方法用于通告当前资源状态。会话启动协议事件通告机制涉及以下几个部分：

(1)订阅者

订阅者负责接收NOTIFY消息的会话启动协议用户代理(SIP UA)。这些NOTIFY消息中包含订阅者订阅的资源信息。订阅者典型的动作是向通告者发送SUBSCRIBE消息以请求创建一次订阅关系。

(2)通告者

通告者负责产生NOTIFY请求的SIP UA。通告者在NOTIFY消息中向订阅者回馈当前资源的状态。通告者典型的动作是接收SUBSCRIBE消息并创建相应的订阅关系。

(3)订阅

所谓订阅就是一组与某个对话相关联的应用状态的集合。订阅关系既存在于订阅者中，又存在于通告者中。

(4)事件包

事件包是通告者向订阅者发送的一组资源的状态信息。RFC 3265中给出了抽象的事件包模板定义，对应具体业务可定义相应的事件包类型，例如：在席事件包、对话事件包等，这些事件包可使用不同的语法并具有各自的语义。这种框架赋予会话启动协议事件通告机制极大的生命力和灵活性，有助于快速提供新的业务。

SUBSCRIBE方法和会话启动协议基本规范中定义的邀请(INVITE)方法都可以创建一个对话。当订阅者想得到网络中某一资源的状态时，便向负责这一资源的会话启动协议实体发起SUBSCRIBE请求。SUBSCRIBE消息中的请求统一资源标识符(Request-URI)就是所要请求的资源的统一资源标识符(URI)，这一URI同时还为会话启动协议代理服务器路由请求提供线索。SUBSCRIBE请求中必须包含一个扩展的Event头部，其中注明要订阅的事件类型，即事件包标记，如，dialog(用于代答业务)、refer(用于呼叫转交)等。还可包含扩展的Allowed-Event头部，指示本节点能够支持的事件包类型。

对于订阅者来说，它总是在一定的时间段内对它感兴趣的某一资源进行观察，因此，SUBSCRIBE消息中应包含expires头部，这一头部值表明订阅者期望的有效订阅时长。为了延长某一订阅的时间，订阅者可以在有效期内再次发送SUBSCRIBE消息来刷新这一订阅。具体某次订阅的有效时长，最终是由对SUBSCRIBE请求的2XX响应中的expires头部值或NOTIFY消息中的Subscription-State头部的expires参数决定的。expires头部值等于0的SUBSCRIBE请求表示撤消订阅。如果订阅关系能够建立，SUBSCRIBE消息将会触发通告资源状态的NOTIFY消息立即回送。订阅者想要获得的资源状态信息封装在后继通告消息NOTIFY的消息体中，为了能够正确地解释这部分信息，订阅者应该向通告者指明自己支持的消息体格式，因此，在SUBSCRIBE消息中应携带Accept头部，比如：Accept:application/dialog-info+xml，这表明订阅者支持用可扩展标识语言(XML)描述的对话事件包，实际上就是一种通用Internet邮件扩展(MIME)格式消息体。如果SUBSCRIBE消息中没有携带Accept头部，则通告者根据SUBSCRIBE消息中Event头部指明的事件包标记选择默认的格式传送资源状态信息。

SUBSCRIBE请求通过2XX响应确认。不同的2XX响应具有不同的语义：

(1)200OK表示订阅已被接受且用户已被授权订阅请求的资源。

(2)202Accepted(接受)是事件通知机制扩展的响应码，表示订阅请求已被理解，但是否授权给订阅者未确定。

2XX响应中必须包含expires头部，这个值指明通告者确定的此次订阅的有效时长，且必须满足：expires 200OK<＝expires SUBSCRIBE，即禁止通告者延长订阅时长。如果返回非2XX响应，则表示订阅失败，将没有后继的NOTIFY消息。

通告者收到SUBSCRIBE请求时，首先判定是否理解消息中的Event头部，如果不理解，则通告者返回扩展的“489Bad Event”(错误事件)响应。通告者还会检查消息中的expires头部，如果其值满足：(0<expires SUBSCRIBE<1hour)&&(0<expires SUBSCRIBE<Min通告者-config)，其中，Min通告者-config为通告者最小配置订阅时长，则通告者向订阅者返回“423Interval too small”(时间间隔太短)响应，表示提出的订阅时长太短。此外，通告者还应根据本地策略对提出SUBSCRIBE请求的用户进行鉴权。

与订阅相关的信息由NOTIFY消息传送。通告者在成功创建订阅关系后，必须立即发送NOTIFY消息，向订阅者通告当前订阅资源的状态，。通告者使用SUBSCRIBE消息中Accept头部明确允许的或者Event头部隐含指明的消息体格式将资源的状态信息或指向该资源状态的URI封装在消息中。消息也可包含扩展的Al lowed-Events头部，指示本节点能够支持的事件包类型。NOTIFY消息中必须包含扩展的Subscription-State头部，指示创建的订阅的状态。共有3种订阅状态，分别是：

(1)active：订阅已被接受且授权成功。

(2)pending：SUBSCRIBE请求已收到，但还没有足够的信息决定接受或拒绝此次订阅。

(3)terminated：订阅未激活，或创建的订阅关系终止。

对应active状态或peding状态，该头部还带有expires参数指示此次订阅的有效时长。对应terminated状态，该头部应包含reason参数指示订阅被终止的原因，或者包含Retry-After参数，指示订阅者过一段时间后重新发起订阅请求。

订阅者收到通告者NOTIFY请求后，将进行匹配检查。如果找到相应的匹配，且NOTIFY消息中的Subscription-State头部指示的订阅状态是active或pending，订阅者创建新的订阅或对话，并对NOTIFY请求回送200OK响应。如果匹配失败，则发送“481Subscription does not exist”(订阅不存在)响应。

在订阅有效期内，如果资源状态发生变化，则通告者使用NOTIFY请求及时将变化信息通告订阅者。

扩展的SUBSCRIBE方法和基本的INVITE方法都可以创建对话。在某一对话中，SUBSCRIBE请求将创建和该对话关联的订阅，而该对话有可能是由INVITE建立起来的。因此，如果订阅终止，且当前无其他应用状态(如由INVITE请求建立起来的应用状态)和该对话关联，则该对话结束。如果仍有订阅和该对话关联，虽然其他的应用状态已结束，但该对话并没有结束。换句话说，由INVITE创建的对话并不会因为收到或发送了再见请求而结束，因为仍有订阅关系和此对话相关联。与此类似，当多个订阅和同一对话关联时，必须当与此对话相关联的所有订阅都结束时，该对话才结束。这一概念非常类似于程序设计里对文件描述符的引用，其中文件描述符相当于对话，对文件描述符引用的进程相当于建立的订阅关系。

SUBSCRIBE请求可以触发通告者对其资源状态的立即回送，因此，订阅者可以利用这一特性实现对资源状态的轮询。当订阅处于激活状态时，订阅者在SUBSCRIBE请求的expires头部写入当前剩下的订阅有效时长的秒数，这样，能够立即触发通告者产生NOTIFY消息，将当前资源的状态通告给订阅者。需要指出的是，这种对资源的轮询会导致网络、通告者和订阅者负荷的增加。在如移动通信这样的特定应用中，订阅者一般是数据处理能力较慢、需要额外供电的移动终端设备，随着事件通告频度的增加和通告事件包的增大，将消耗很多宝贵的带宽资源，造成网络拥塞和订阅者的过载。因此，订阅者需要对通告者的状态通告频率作出限制。另外，订阅者还可以在SUBSCRIBE消息中指定一些事件包的过滤规则，使得通告者能够根据这一过滤规则产生通告事件，而不是任何状态发生变化时都发起通告。

一般说来，订阅者使用SUBSCRIBE请求建立一次订阅，称为显式订阅创建，与此相对应的还有一种隐式的订阅创建，即订阅者不是通过SUBSCRIBE请求来创建订阅。而是通过转交(REFER)方法，一种由RFC3515定义的用于实现呼叫转交等业务的方法。REFER请求隐式地在被转交用户处创建订阅，所要观察的资源是转交请求的状态。

业务运营支持(Business&Operation Support System，BOSS)系统，面对客户是统一的；面对业务运营商，它融合了业务支撑系统(BSS)与运营支撑系统(OSS)，是一个综合的业务运营和管理支撑平台，同时也是真正融合业务(不同的运营商有不同业务的融合，如传统网络接入业务、IP数据业务、内容提供业务与移动增值业务等)的综合管理平台。

针对不同的运营商(如固定网络经营者，移动网络经营者，IP网络经营者，数据网络经营者等)，以及不同的服务对象，BOSS系统通常有以下几类主要业务及其功能。

面向多种业务的功能：多种业务有固定话音及数据、无线话音及数据、无线数据等，功能主要有工单调度、资源管理等融合的营业系统、多业务融合的计费系统与账务系统、统一的客户服务系统、统一的客户关系管理(CRM)系统、业务开通与保障、业务开发与决策、SLA(服务水平协议)/QoS(服务质量保证)管理以及应用集成等。面向一般消费者及大众化IP业务的功能主要有：营业系统、账务系统、计费系统、客户服务、客户分析、业务开发与规划、业务激活、业务保障和应用集成等。面向企业和个人用户的数据业务的功能：针对个人用户特别是大客户的企业用户所需的个性化服务，其流程复杂，多样化，主要功能有：营业系统、工单调度、资源管理、计费系统、账务系统、客户服务系统、CRM系统、业务开通与保障、业务开发与决策、SLA/QoS管理以及应用集成等。

本实施例中，所述用户设备开机后，各卡均开始进行IMS初始注册，完成鉴权及注册流程后，各卡可以分别向应用服务器发送订阅请求。具体地，可以通过IMS中的P-CSCF和S-CSCF向AS发送所述订阅请求。

所述AS收到所述订阅请求后，可以通过网关向BOSS系统发送查询请求，以订阅卡的业务状态。所述卡的业务状态可以包括但不限于：卡的套餐状况、卡的归属地、卡的资费、卡是否处于漫游状态等等。

步骤102、接收所述业务运营支持系统根据所述查询请求通过所述应用服务器返回的至少一个卡的业务状态信息。

具体地，所述BOSS系统可以将业务状态信息发送给应用服务器，再由所述应用服务器将所述业务状态信息发送给用户设备。

步骤103、当需要发起呼叫时，根据所述至少一个卡的业务状态信息，确定发起呼叫的卡。

为了便于详细说明，本实施例中以所述业务状态用于表征卡所订阅的套餐中的语音套餐余量的多少为例来进行描述。

一般在用户设备初始IMS注册结束后，用户设备会发起订阅流程，此时订阅的事件(Event)，一般为registration state event package(注册状态事件包)，是为重注册、重鉴权等功能做准备的。

为了能够使用SIP协议中的订阅机制来订阅当前卡的业务状态，可以引入一个新的event：voice plan usage(语音计划命令)，作为所述订阅信息。具体地，可以定义Event：voice plan usage的语义为，查询当前BOSS系统中该卡的语音套餐余量是否小于余量预设阈值，即，所述业务状态信息用于表示卡的语音套餐余量是否小于余量预设阈值。若卡内的语音套餐余量大于余量预设阈值，则不需要通知用户设备，若卡内的语音套餐余量小于余量预设阈值，则可以通过Notify(通知)消息通知用户设备。

所述语音套餐余量是指卡的套餐中的剩余语音通话时间，例如，卡1的套餐包括100分钟免费语音通话，本月已使用60分钟，则卡1的语音套餐余量为40分钟，卡2的套餐包括200分钟免费语音通话，本月已使用180分钟，则卡2的语音套餐余量为20分钟。

所述余量预设阈值可以根据实际需要来设置，例如可以为30分钟，或者，所述余量预设阈值可以由用户手动输入，满足用户的个性化需求。相应地，所述订阅请求中可以携带有所述余量预设阈值，以使所述BOSS系统在卡的语音套餐余量小于或等于所述余量预设阈值时发送所述业务状态信息。

BOSS系统在接收到AS发送的查询请求后，可以设置卡的语音套餐余量不足余量预设阈值时，通过AS向用户设备发送相关的业务状态信息。若此时卡仍处于IMS注册状态，AS会将BOSS系统的业务状态信息以Notify消息的格式发送给用户设备；若此时该卡不处于IMS注册状态，AS上查不到该卡的信息，则等到下一次该卡进行IMS注册后再推送该业务状态信息。

这样，通过引入新的Event，就可以实现AS向BOSS系统发送订阅请求，BOSS系统返回相应的业务状态信息。

相应的，步骤103中的根据所述至少一个卡的业务状态信息，确定发起呼叫的卡，可以包括：

根据所述至少一个卡的业务状态信息，判断是否能够确定语音套餐余量最多的卡；若能够确定语音套餐余量最多的卡，则以所述语音套餐余量最多的卡发起呼叫。

具体地，若多个卡中仅有一个未接收到业务状态信息，则判断所述未接收到业务状态信息的卡为语音套餐余量最多的卡，反之则判断不能确定语音套餐余量最多的卡。

例如，用户设备中有三张卡，其中卡1和卡2都收到了业务状态信息，说明卡1和卡2中的语音套餐余量都不足余量预设阈值了，而卡3没有收到，说明卡3的语音套餐余量大于余量预设阈值，因此可以判定卡3为语音套餐余量最多的卡，当需要发起呼叫时，可以用卡3进行呼叫。

若不能确定语音套餐余量最多的卡，则可以使用默认的卡来进行呼叫，或者，使用其他规则判断由哪张卡发起呼叫，例如使用剩余话费较多的卡来发起呼叫。

除了语音套餐余量的多少以外，业务状态信息还可以用于表示卡的其它状态信息，相应的，在步骤103中发起呼叫时，可以根据其它状态信息的预设规则选择由哪张卡进行呼叫。

例如，所述业务状态信息可以用于表示卡是否处于漫游状态，需要发起呼叫时，可以优先使用不处于漫游状态的卡进行呼叫。或者，所述业务状态信息用于表示卡的归属地，用户设备可以根据各卡的归属地和用户当前所在地理位置来确定由哪张卡发起呼叫，若用户当前所在地理位置属于某卡的归属地，则优先使用该卡发起呼叫。或者，所述业务状态信息可以用于表示卡的资费，在发起呼叫时，可以使用资费较多的卡进行呼叫。

在实际应用中，通过与AS和BOSS系统的交互，用户设备能够获得各卡的业务状态信息，在需要发起呼叫时，用户设备可以根据各卡的业务状态信息，自动选择相应的卡进行呼叫。

本实施例提供的呼叫处理方法，通过向应用服务器发送订阅请求，以使所述应用服务器根据所述订阅请求向业务运营支持系统发送查询请求，从而订阅各卡的业务状态，并接收所述业务运营支持系统根据所述查询请求通过所述应用服务器返回的至少一个卡的业务状态信息，在需要发起呼叫时，根据所述至少一个卡的业务状态信息，确定发起呼叫的卡，无需用户手动进行选择，简化了呼叫操作，提高了呼叫效率，为用户提供了便利。

实施例二

本发明实施例二提供一种呼叫处理方法。本实施例是在前述实施例提供的技术方案的基础上，在不能确定语音套餐余量最多的卡时，通过各卡的无线制式信息确定由哪张卡发起呼叫。

图2为本发明实施例二提供的呼叫处理方法的流程图。如图2所示，本实施例中的方法，可以包括：

步骤201、向应用服务器发送订阅请求，以使所述应用服务器根据所述订阅请求向业务运营支持系统发送查询请求，从而订阅各卡的业务状态。

步骤202、接收所述业务运营支持系统根据所述查询请求通过所述应用服务器返回的至少一个卡的业务状态信息。

步骤203、当需要发起呼叫时，根据所述至少一个卡的业务状态信息，判断是否能够确定语音套餐余量最多的卡。

步骤201至步骤203的具体实现原理可以参照实施例一，此处不再赘述。

步骤204、若不能确定语音套餐余量最多的卡，则获取各卡的无线制式信息。

步骤205、根据各卡的无线制式信息，确定发起呼叫的卡。

本实施例中，若能够确定语音套餐余量最多的卡，则以所述语音套餐余量最多的卡发起呼叫。若不能，则可以根据各卡的无线制式信息，确定由哪张卡进行呼叫。

具体地，用户设备可以先获取各卡的无线制式信息，所述无线制式信息用于表示卡所处的小区的状态，例如：VoLTE小区、不支持VoLTE的LTE小区(只能使用CSFB发起呼叫)、3G小区、2G小区等等。

由于用户设备中的多张卡可能处于不同的无线技术下，因此发起语音呼叫的语音质量、呼叫时延都有差异。一般来说，VoLTE制式下语音质量最好，接入时延最短，不支持VoLTE的LTE环境下一般使用CSFB发起呼叫，CSFB的接入时延较长，因此直接选择2G/3G发起呼叫会比CSFB更快。

因此，在发起呼叫时，可以优先使用处于VoLTE小区的卡进行呼叫，其次是处于2G/3G小区的卡，最后是只能使用CSFB的卡。

若用户设备中的多张卡的无线制式信息均相同，即各卡都处在相同的无线制式下，则可以选取默认的卡发起呼叫，或者使用任意一张卡发起呼叫，或者使用其他规则确定由哪张卡发起呼叫。

本实施例提供的呼叫处理方法，在不能确定语音套餐余量最多的卡时，可以通过获取各卡的无线制式信息，并根据各卡的无线制式信息，确定发起呼叫的卡，能使用户设备自动使用当前最适宜通话的卡进行呼叫，进一步为用户提供了便利。

实施例三

本发明实施例三提供一种呼叫处理方法。本实施例是在前述实施例提供的技术方案的基础上，在不能确定语音套餐余量最多的卡时，通过数据业务确定由哪张卡发起呼叫。

图3为本发明实施例三提供的呼叫处理方法的流程图。如图3所示，本实施例中的方法，可以包括：

步骤301、向应用服务器发送订阅请求，以使所述应用服务器根据所述订阅请求向业务运营支持系统发送查询请求，从而订阅各卡的业务状态。

步骤302、接收所述业务运营支持系统根据所述查询请求通过所述应用服务器返回的至少一个卡的业务状态信息。

步骤303、当需要发起呼叫时，根据所述至少一个卡的业务状态信息，判断是否能够确定语音套餐余量最多的卡。

步骤301至步骤303的具体实现原理可以参照实施例一，此处不再赘述。

步骤304、若不能确定语音套餐余量最多的卡，则确定正在进行数据业务的卡，并以所述正在进行数据业务的卡作为发起呼叫的卡。

本实施例中，若能够确定语音套餐余量最多的卡，则以所述语音套餐余量最多的卡发起呼叫。若不能，则可以以所述正在进行数据业务的卡作为发起呼叫的卡。具体地，可以通过建立的DRB(Data RB，终端与基站之间的数据承载)来判断哪张卡正在进行数据业务。

本实施例可以优选地用于双卡双待单通终端，因为单通终端同时只能使用一张卡进行业务，如果卡1正在进行数据业务，再使用卡2发起呼叫的话，卡1所在进行的数据业务就会中断，直到卡2的通话结束后才能重新接续数据业务。因此，本实施例中设置为数据业务优先，即哪一张卡正在进行数据业务，就使用哪一张卡发起呼叫，而一张卡同时使用数据业务和语音业务是不会受影响的，可以并发进行，提高效率。

本实施例提供的呼叫处理方法，在不能确定语音套餐余量最多的卡时，可以通过确定正在进行数据业务的卡，并以所述正在进行数据业务的卡作为发起呼叫的卡，使得用户正在使用的数据不受影响，进一步提高用户体验度。

上述实施例二和实施例三中的方法还可以组合使用，即可以首先根据语音通话余量选择由哪张卡发起呼叫，在无法确定语音通话余量最多的卡时，可以根据无线制式来选择由哪张卡发起呼叫，在各卡的无线制式相同或者无法获取卡的无线制式的情况下，可以选择正在使用数据业务的卡发起呼叫。或者，可以首先根据语音通话余量选择由哪张卡发起呼叫，在无法确定语音通话余量最多的卡时，可以选择正在使用数据业务的卡发起呼叫，若没有正在使用数据业务的卡，则可以根据各卡的无线制式来选择由哪张卡发起呼叫。

实施例四

本发明实施例四提供一种呼叫处理装置。图4为本发明实施例四提供的呼叫处理装置的结构框图。如图4所述，本实施例中的呼叫处理装置，可以包括：

发送模块401，用于向应用服务器发送订阅请求，以使所述应用服务器根据所述订阅请求向业务运营支持系统发送查询请求，从而订阅各卡的业务状态；

接收模块402，用于接收所述业务运营支持系统根据所述查询请求通过所述应用服务器返回的至少一个卡的业务状态信息；

确定模块403，用于在需要发起呼叫时，根据所述至少一个卡的业务状态信息，确定发起呼叫的卡。

本实施例提供的呼叫处理装置，可以用于执行实施例一所述的呼叫处理方法，其具体实现原理与实施例一类似，此处不再赘述。

本实施例提供的呼叫处理装置，通过向应用服务器发送订阅请求，以使所述应用服务器根据所述订阅请求向业务运营支持系统发送查询请求，从而订阅各卡的业务状态，并接收所述业务运营支持系统根据所述查询请求通过所述应用服务器返回的至少一个卡的业务状态信息，在需要发起呼叫时，根据所述至少一个卡的业务状态信息，确定发起呼叫的卡，无需用户手动进行选择，简化了呼叫操作，提高了呼叫效率，为用户提供了便利。

进一步地，所述确定模块403，可以包括：

判断单元，用于在需要发起呼叫时，根据所述至少一个卡的业务状态信息，判断是否能够确定语音套餐余量最多的卡；

呼叫单元，用于在能够确定语音套餐余量最多的卡时，以所述语音套餐余量最多的卡发起呼叫。

进一步地，所述发送模块401还用于：在向应用服务器发送订阅请求之前，接收用户输入的余量预设阈值；

相应地，所述订阅请求中携带有所述余量预设阈值，以使所述业务运营支持系统在卡的语音套餐余量小于或等于所述余量预设阈值时发送所述业务状态信息；

所述判断单元具体用于：在需要发起呼叫时，若多个卡中仅有一个未接收到业务状态信息，则判断所述未接收到业务状态信息的卡为语音套餐余量最多的卡，反之则判断不能确定语音套餐余量最多的卡。

进一步地，所述呼叫单元还用于：若不能确定语音套餐余量最多的卡，则获取各卡的无线制式信息；根据各卡的无线制式信息，确定发起呼叫的卡。

进一步地，所述呼叫单元还用于：若不能确定语音套餐余量最多的卡，则确定正在进行数据业务的卡，并以所述正在进行数据业务的卡作为发起呼叫的卡。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。