WO2021104198A1 - 一种呼叫处理系统、呼叫处理方法以及通信装置 - Google Patents

一种呼叫处理系统、呼叫处理方法以及通信装置 Download PDF

Info

Publication number
WO2021104198A1
WO2021104198A1 PCT/CN2020/130790 CN2020130790W WO2021104198A1 WO 2021104198 A1 WO2021104198 A1 WO 2021104198A1 CN 2020130790 W CN2020130790 W CN 2020130790W WO 2021104198 A1 WO2021104198 A1 WO 2021104198A1
Authority
WO
WIPO (PCT)
Prior art keywords
call
event
calling
called
call processing
Prior art date
Application number
PCT/CN2020/130790
Other languages
English (en)
French (fr)
Inventor
叶进洲
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP20893664.1A priority Critical patent/EP4054142A4/en
Publication of WO2021104198A1 publication Critical patent/WO2021104198A1/zh
Priority to US17/826,781 priority patent/US20220295256A1/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/02—Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1083—In-session procedures
    • H04L65/1093—In-session procedures by adding participants; by removing participants
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1046—Call controllers; Call servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/16—Communication-related supplementary services, e.g. call-transfer or call-hold

Abstract

本申请提供了一种呼叫处理系统、呼叫处理方法以及通信装置，该系统包括呼叫处理设备和事件管理器，所述呼叫处理设备，用于为主叫用户设备发起的呼叫进行接通和路由处理，还用于针对所述呼叫进行事件检测，并且将检测到的事件上报给所述事件管理器；其中，所述检测到的事件用于请求触发针对所述呼叫的更新处理；所述事件管理器，用于根据所述呼叫处理设备上报的事件，管理所述呼叫的更新处理。本申请通过剥离基本通话为呼叫处理设备来实现简化的2B行业音视频框架，能够满足当前2B应用场景的使用需求，使得2B的应用能够快速部署。

Description

一种呼叫处理系统、呼叫处理方法以及通信装置
本申请要求于2019年11月30日提交中国国家知识产权局、申请号为201911208927.3、发明名称为“一种呼叫处理系统、呼叫处理方法以及通信装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及通信技术领域，尤其涉及一种呼叫处理系统、呼叫处理方法以及通信装置。
背景技术
为了满足多媒体通信的需求，第三代合作伙伴计划(3rd generation partnership project，3GPP)组织在原有分组承载网的基础上引入了IP多媒体子系统(IP multimedia subsystem，IMS)，IMS不仅能向用户提供传统语音业务，也能向用户提供丰富的多媒体体验。
随着第五代移动通信技术(the 5th generation mobile communication technology，5G)的演进，5G语音业务(voice over new radio，VoNR)得到越来越多的关注。VoNR的主要需求之一是面向企业(to business，2B)应用。现有的IMS系统架构已经无法满足当前2B应用场景的使用需求，不利于2B应用的快速部署。
发明内容
本申请提供一种呼叫处理系统、呼叫处理方法以及通信装置，能够满足当前2B应用场景的使用需求，使得2B的应用能够快速部署。
第一方面，提供了一种呼叫处理系统，该系统包括：呼叫处理设备和事件管理器，呼叫处理设备，用于为主叫用户设备发起的呼叫进行接通和路由处理，还用于针对该呼叫进行事件检测，并且将检测到的事件上报给事件管理器；其中，检测到的事件用于请求触发针对该呼叫的更新处理；事件管理器，用于根据呼叫处理设备上报的事件，管理该呼叫的更新处理。
根据本申请提供的呼叫系统，呼叫处理设备保留基本的音视频通话功能的“最小核”，能够用于为主叫UE发起的呼叫进行接通和路由处理。并且，呼叫处理设备还用于针对呼叫进行事件检测，并且检测到的事件上报给事件管理器，由事件管理器来对相应的更新处理进行管理。
根据本申请提供的呼叫系统，能够满足当前2B应用场景的使用需求，使得2B的应用能够快速部署。具体地，本申请通过剥离基本通话“最小核”为呼叫处理设备来实现简化的2B行业音视频框架，使得2B的应用能够快速部署，节省不必要的虚拟机，同时可以做到零数据配置增强安全能力。本申请对于呼叫的更新处理采用触发机制，并且由事件管理器对相关更新处理进行管理，基本呼叫不必触发而直接在呼叫处理设备提供，从而减少95％的补充业务资源占用和开销，增加部署的灵活性和快速能力，减少能耗。
可选地，该事件可以是2B类型的事件，即此时呼叫处理设备可以对2B类型的事件进行检测，并且将检测到的2B事件上报给2B事件管理器。
可选地，该事件可以是面向用户(to customer，2C)事件，即此时呼叫处理设备可以对2C类型的事件进行检测，并且将检测到的2C事件上报给2C事件管理器。
在本申请实施例中，呼叫处理设备还能够针对本次呼叫进行事件检测，并且将检测到的事件上报给事件管理器。其中，针对本次呼叫进行事件检测，可以是在呼叫的任意过程中对事件进行检测，也可以是在本次呼叫完成之后对与本次呼叫有关的事件进行检测。
例如，该检测可以是在基本呼叫建立完成之前进行的，也可以是在基本呼叫建立完成和通知被叫UE振铃之间进行的，也可以是在通话进行中执行的，也可以是通话完成(挂机)之后进行的，本申请对此不做限定。
在本申请实施例中，检测到事件用于请求触发针对该呼叫的更新处理。具体地，这里“针对该呼叫的更新处理”，可以理解成对本次呼叫的状态和处理过程进行更新(update)服务，是对本次会话的更新。在这里，更新处理为除了接通和路由处理之外的其他处理。因此，本申请中“请求触发针对该呼叫的更新处理”在一些情况下也可以理解成请求触发针对该呼叫的补充业务。
可选地，该呼叫的更新处理可以为一个更新处理，也可以为多个更新处理。也就是说，可以根据检测到的事件请求触发一个或者多个针对该呼叫的更新处理。
可选地，可以由一个事件请求触发一个更新处理。
可选地，也可以由多个事件请求触发一个更新处理。
呼叫处理设备在检测到事件以后，可以将检测到的事件上报到事件管理器。本申请对上报所使用的接口类型不做限定。对于信令面事件和媒体面事件，呼叫处理设备可以通过相同或者不同的接口进行上报。
可选地，检测到的事件可以通过SIP接口进行上报。
可选地，检测到的事件可以通过非SIP(Non-SIP)接口进行上报。
例如，呼叫处理设备可以通过事件上报接口1(EventReportInt1接口)向事件管理器上报检测到的信令面事件；呼叫处理设备可以通过事件上报接口2(EventReportInt2接口)向事件管理器上报检测到的媒体面事件。
进一步地，事件管理器用于接收该检测到的事件，并且根据接收的事件，管理该呼叫更新处理。例如，触发更新处理、阻止(屏蔽)更新处理、确定为更新处理提供服务的应用服务器、对多个更新处理提供队列管理等等，本申请对此不做限定。
结合第一方面，在第一方面的某些实现方式中，所述事件管理器具体用于：根据所述上报的事件，确定为所述呼叫的更新处理提供服务的应用服务器(application server，AS)。
具体地，检测到的事件能够用于请求触发针对该呼叫的更新处理，事件管理器在决定触发该更新处理以后，可以确定为该更新处理提供服务的应用服务器。此时，事件管理器可以向该应用服务器上报触发指令，该触发指令包括检测到的事件相关的参数集。
可选地，该应用服务器为可以是企业(例如外卖、出租车行业的企业)部署的第三方应用服务器。
可选地，该应用服务器可以是运营商部署的MMTEL服务器。
结合第一方面，在第一方面的某些实现方式中，事件管理器具体用于：获取应用服务器和事件的订阅关系信息；根据所述上报的事件和所述订阅关系信息，确定为所述呼叫的更新处理提供服务的应用服务器。
具体地，该订阅关系能够体现哪些应用服务器订阅了哪些事件，能够体现事件和应用服 务器的对应关系。可选地，该订阅关系可以由企业进行定义，并且存储在本地。
事件管理器能够根据检测到的事件和该订阅关系，确定哪些(或者哪一个)服务器订阅了该事件，并且确定其中的一个或者多个服务器来为该更新处理提供服务。
可选地，若事件管理器在该订阅关系中查询到只有一个AS订阅了该事件，此时事件管理器可以选择该唯一的一个AS来为该更新处理提供服务。
可选地，若事件管理器在该订阅关系中查询到有多个AS订阅了该事件，此时事件管理器可以选择其中的一个或者多个AS来为该更新处理提供服务。
例如，可以选择其中优先级最高的一个AS来为该更新处理提供服务。
可选地，在其他实施例中，若事件管理器在该订阅关系中未查询到订阅该事件的AS，则此时事件管理器可以选择不触发该更新处理。
可选地，也可能由多个事件来请求触发一个更新处理，则此时可以由多个事件的逻辑组合和该订阅关系信息，确定为更新处理提供服务的应用服务器。
本申请基于现有IMS框架，还提供了一种更为灵活的业务触发机制，突破现有IMS仅有IFC Invite基于静态业务发放机制的限制，能够让第三方应用服务器任意定义自己的业务，而无需经过运营商的BSS发放系统，事件处理逻辑解耦，从而保证2B的第三方应用服务器的独立性和灵活性；事件订阅和业务逻辑完全归属于企业本身，确保企业数据和业务的隐私安全。
根据本申请的实施例，提供更为灵活的松耦合的触发机制，便于业务由行业企业自行定义，灵活接插；多事件管理的触发机制，灵活可编程自定义除Invite之外的各种信令和媒体事件，消除静态签约的局限性，同时改静态的IFC签约为基于灵活订阅的事件触发，包括信令事件和媒体事件，从而有利于2B应用的快速、灵活部署。
可选地，本申请的事件管理器还可以提供队列管理机制，能够对上报的多个事件进行队列管理，从而能够更好的针对呼叫进行更新处理。
结合第一方面，在第一方面的某些实现方式中，事件管理器具体用于：根据本地存储的屏蔽策略，对所述上报的事件进行屏蔽管理。
具体地，可以根据存储在本地的屏蔽策略，对上报的事件进行屏蔽操作。例如，对于特定的事件，可以对其进行屏蔽，而不触发该事件所请求触发的更新处理，即此时可以不向应用服务器上报触发指令。通过以上设置，可以对针对呼叫的更新处理进行更好的管理，提高整个呼叫系统的安全使用性能。
结合第一方面，在第一方面的某些实现方式中，事件管理器具体用于：根据上报的事件生成触发指令，并且向应用服务器发送所述触发指令；接收应用服务器反馈的处理结果，所述处理结果由应用服务器根据触发指令生成；管理处理结果。
本申请的事件管理器对该处理结果进行管理，可以是对该处理结果进行审核，确定是否符合要求，在符合要求的情况下才转发至呼叫处理设备，以触发相应的更新处理。若确定不符合要求(即处理结果不合理)，则此时可以不将该处理结果转发至呼叫处理设备，以屏蔽(或者阻止)该更新处理的触发。
可选地，该处理结果可以是“直接的”结果(例如对于修改号码显示，该结果可以直接是被修改后的号码)，也可以是一个调用接口API或者一段可执行脚本，本申请对此不做限定。
结合第一方面，在第一方面的某些实现方式中，呼叫处理设备还用于：获取事件的定义信息；根据所述定义信息对所述事件进行检测。
例如，该呼叫处理设备可以归属于网络运营商，可以通过网络运营商对呼叫处理设备检测的事件进行定义。
结合第一方面，在第一方面的某些实现方式中，呼叫处理设备具体用于：通过会话内修改和/或重邀请的方法为该呼叫进行更新处理。
结合第一方面，在第一方面的某些实现方式中，该呼叫的更新处理包括以下处理中的至少一种：修改号码显示，修改呼叫的方向，媒体修改路径、媒体修改编解码类型等。
可选地，该事件可以包括信令面事件和/或媒体面事件。也就是说，呼叫处理设备还能够针对本次呼叫进行信令面和/或媒体面事件检测。本申请实施例对呼叫处理设备如何对事件进行检测不做限定。
例如，对于信令面事件的检测，呼叫处理设备可以通过检测接收或者发送某条信令确定检测到某一事件。
再例如，对于媒体面事件的检测，呼叫处理设备可以通过检测到某条媒体信息确定检测到某一事件。
再例如，呼叫处理设备可以通过呼叫状态的改变确定检测到某一事件。
第二方面，提供了一种呼叫处理方法，该方法可以由边界控制器SBC执行，也可以是SBC内的芯片执行，该方法包括：主叫侧边界控制器SBC接收主叫用户设备UE的发送的第一呼叫请求消息；主叫侧SBC向用户数据服务器发送第一路由请求消息，第一路由请求消息用于请求所述主叫UE的标识ID和网际互连协议IP，以及，用于请求被叫UE的ID和IP；主叫侧SBC接收用户数据服务器发送的第一路由响应消息，第一路由响应消息携带第一ID、第一IP、第二ID、第二IP；其中，第一ID为主叫UE的ID，第一IP为主叫UE的IP，第二ID为被叫UE的ID，第二IP为被叫UE的IP；主叫侧SBC向呼叫处理设备发送第二呼叫请求消息，所述第二呼叫请求消息携带所述第一ID、第一IP、第二ID、第二IP。
结合第二方面，在第二方面的某些实现方式中，第一ID为所述主叫UE的真实ID或者匿名ID，所述第一IP为所述主叫UE的真实IP或者匿名IP；第二ID为所述被叫UE的真实ID或者匿名ID，所述第二IP为所述被叫UE的真实IP或者匿名IP。
本申请第二呼叫请求消息中携带了主叫UE和被叫UE的ID和IP，并且，该ID和IP可以是真实的，也可以是匿名的，本申请将现有技术中依赖主被叫号码进行逐跳路由替代为数据主权者来提供IP+ID路由，由此能够确保用户数据的主权，呼叫处理设备不会接触用户的隐私数据，从而能够保护用户的隐私。同时，可以屏蔽基于不同运营商的差异，即运营商的编码方案的差异全部被屏蔽，转为更为通用的IP路由和虚拟的统一ID路由。同时也增强了HSS的数据价值。
结合第二方面，在第二方面的某些实现方式中，第一路由响应消息还携带有第一指示信息，第一指示信息用于指示所述第一ID、第二ID是真实ID还是匿名ID，以及用于指示所述第一IP、第二IP是真实IP还是匿名IP。通过以上设置，能够防止主叫侧SBC发生逻辑混乱，有利于主叫侧SBC进行路由决策。
结合第二方面，在第二方面的某些实现方式中，该方法还包括：所述呼叫处理设备根据所述第二ID或者第二IP，向被叫侧SBC发送第三呼叫请求消息，第三呼叫请求消息携带所述第一ID、第一IP、第二ID、第二IP。
结合第二方面，在第二方面的某些实现方式中，该方法还包括：所述呼叫处理设备针对本次呼叫进行事件检测，以获得第一事件集，所述第一事件集包括至少一个事件，所述第一 事件集用于请求触发针对所述呼叫的更新处理；所述呼叫处理设备向事件管理器发送所述第一事件集；所述呼叫处理设备接收所述管理器发送的处理结果；所述呼叫处理设备根据所述处理结果，进行针对所述呼叫的更新处理。
第三方面，提供了一种呼叫处理方法，该方法可以由用户数据服务器执行，也可以是用户数据服务器内的芯片执行，该方法包括：用户数据服务器接收主叫侧边界控制器SBC发送的第一路由请求消息，所述第一路由请求消息用于请求所述主叫用户设备UE的标识ID和网际互连协议IP，以及，用于请求被叫UE的ID和IP；所述用户数据服务器确定第一ID、第一IP、第二ID、第二IP；其中，所述第一ID为所述主叫UE的ID，所述第一IP为所述主叫UE的IP，所述第二ID为所述被叫UE的ID，所述第二IP为所述被叫UE的IP；所述HSS向所述主叫侧SBC发送第一路由响应消息，所述第一路由响应消息携带所述第一ID、第一IP、第二ID、第二IP。
结合第三方面，在第三方面的某些实现方式中，所述第一ID为所述主叫UE的真实ID或者匿名ID，所述第一IP为所述主叫UE的真实IP或者匿名IP；所述第二ID为所述被叫UE的真实ID或者匿名ID，所述第二IP为所述被叫UE的真实IP或者匿名IP。
结合第三方面，在第三方面的某些实现方式中，所述第一路由响应消息还携带有第一指示信息，所述第一指示信息用于指示所述第一ID、第二ID是真实ID还是匿名ID，以及用于指示所述第一IP、第二IP是真实IP还是匿名IP。
第四方面，提供了一种通信装置，该装置包括：接收单元，用于接收主叫用户设备UE的发送的第一呼叫请求消息；发送单元，用于向用户数据服务器发送第一路由请求消息，所述第一路由请求消息用于请求所述主叫UE的标识ID和网际互连协议IP，以及，用于请求被叫UE的ID和IP；接收单元，用于接收所述用户数据服务器发送的第一路由响应消息，所述第一路由响应消息携带第一ID、第一IP、第二ID、第二IP；其中，所述第一ID为所述主叫UE的ID，所述第一IP为所述主叫UE的IP，所述第二ID为所述被叫UE的ID，所述第二IP为所述被叫UE的IP；所述发送单元还用于，向呼叫处理设备发送第二呼叫请求消息，所述第二呼叫请求消息携带所述第一ID、第一IP、第二ID、第二IP。
结合第四方面，在第四方面的某些实现方式中，所述第一ID为所述主叫UE的真实ID或者匿名ID，所述第一IP为所述主叫UE的真实IP或者匿名IP；所述第二ID为所述被叫UE的真实ID或者匿名ID，所述第二IP为所述被叫UE的真实IP或者匿名IP。
结合第四方面，在第四方面的某些实现方式中，所述第一路由响应消息还携带有第一指示信息，所述第一指示信息用于指示所述第一ID、第二ID是真实ID还是匿名ID，以及用于指示所述第一IP、第二IP是真实IP还是匿名IP。
第五方面，提供了一种通信装置，该装置包括：接收单元，用于接收主叫侧边界控制器SBC发送的第一路由请求消息，所述第一路由请求消息用于请求所述主叫用户设备UE的标识ID和网际互连协议IP，以及，用于请求被叫UE的ID和IP；处理单元，用于确定第一ID、第一IP、第二ID、第二IP；其中，所述第一ID为所述主叫UE的ID，所述第一IP为所述主叫UE的IP，所述第二ID为所述被叫UE的ID，所述第二IP为所述被叫UE的IP；发送单元，用于向所述主叫侧SBC发送第一路由响应消息，所述第一路由响应消息携带所述第一ID、第一IP、第二ID、第二IP。
结合第五方面，在第五方面的某些实现方式中，所述第一ID为所述主叫UE的真实ID或者匿名ID，所述第一IP为所述主叫UE的真实IP或者匿名IP；所述第二ID为所述被叫UE 的真实ID或者匿名ID，所述第二IP为所述被叫UE的真实IP或者匿名IP。
结合第五方面，在第五方面的某些实现方式中，所述第一路由响应消息还携带有第一指示信息，所述第一指示信息用于指示所述第一ID、第二ID是真实ID还是匿名ID，以及用于指示所述第一IP、第二IP是真实IP还是匿名IP。
第六方面，提供一种通信装置，该装置可以是边界控制器SBC，也可以是SBC内的芯片。该装置可以包括处理单元和收发单元。当所述装置是SBC时，所述处理单元可以是处理器，所述收发单元可以是收发器；所述SBC还可以包括存储单元，所述存储单元可以是存储器；所述存储单元用于存储指令，所述处理单元执行所述存储单元所存储的指令，以使所述通信装置执行第二方面中的方法。当所述装置是SBC内的芯片时，所述处理单元可以是处理器，所述收发单元可以是输入/输出接口、管脚或电路等；处理单元执行存储单元所存储的指令，以使通信装置执行第二方面中的方法，存储单元可以是所述芯片内的存储单元(例如，寄存器、缓存等)，也可以是所述通信装置内的位于所述芯片外部的存储单元(例如，只读存储器、随机存取存储器等)。
第七方面，提供一种通信装置，该装置可以是用户数据服务器(例如，归属用户服务器HSS)，也可以是用户数据服务器(例如HSS)内的芯片。该装置可以包括处理单元和收发单元。当所述装置是用户数据服务器时，所述处理单元可以是处理器，所述收发单元可以是收发器；所述用户数据服务器还可以包括存储单元，所述存储单元可以是存储器；所述存储单元用于存储指令，所述处理单元执行所述存储单元所存储的指令，以使所述网络设备执行第三方面中的方法。当所述装置是用户数据服务器内的芯片时，所述处理单元可以是处理器，所述收发单元可以是输入/输出接口、管脚或电路等；所述处理单元执行存储单元所存储的指令，以使所述通信装置执行第三方面中的方法，所述存储单元可以是所述芯片内的存储单元(例如，寄存器、缓存等)，也可以是所述通信装置内的位于所述芯片外部的存储单元(例如，只读存储器、随机存取存储器等)。
第八方面，提供一种通信装置，包括至少一个处理器，该至少一个处理器用于与存储器耦合，读取并执行所述存储器中的指令，以实现第二方面或第三方面中的任一种方法。
可选地，该通信装置还包括该存储器。
第九方面，提供了一种计算机程序产品，所述计算机程序产品包括：计算机程序代码，当所述计算机程序代码在计算机上运行时，使得计算机执行上述第二方面或者第三方面中的方法。
需要说明的是，上述计算机程序代码可以全部或者部分存储在第一存储介质上，其中第一存储介质可以与处理器封装在一起的，也可以与处理器单独封装，本申请对此不作具体限定。
第十方面，提供了一种计算机可读介质，所述计算机可读介质存储有程序代码，当所述计算机程序代码在计算机上运行时，使得计算机执行上述第二方面或者第三方面中的方法。
第十一方面，提供了一种芯片系统，包括处理器，用于从存储器中调用并运行计算机程序，使得安装有所述芯片系统的通信设备执行上述第二方面或者第三方面中的方法。
附图说明
图1是现有技术中IMS网络系统的基本架构示意图。
图2是本申请实施例提供的呼叫处理系统的一例的系统架构示意图。
图3是本申请实施例提供的呼叫处理系统的另一例的系统架构示意图。
图4是本申请实施例提供的呼叫处理方法的一例的示意性流程图。
图5是本申请实施例提供的呼叫处理方法的另一例的示意性流程图。
图6是本申请实施例提供的呼叫处理方法的再一例的示意性流程图。
图7是本申请实施例提供的呼叫处理方法的再一例的示意性流程图。
图8是本申请实施例提供的通信装置的一例的示意性框图。
图9是本申请实施例提供的边界控制器的结构示意图。
图10是本申请实施例提供的通信装置的另一例的示意性框图。
图11是本申请实施例提供的用户数据服务器的结构示意图。
具体实施方式
为使本申请要解决的技术问题、技术方案和优点更加清楚，下面将结合附图及具体实施例进行详细描述。
本申请的说明书和权利要求书中的术语“第一”、“第二”、等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包括。例如包括了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于己列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。
在说明本申请实施例提供的呼叫系统之前，首先结合附图对现有技术中的IMS网络系统的基本架构进行介绍。图1是现有技术中IMS网络系统的基本架构示意图，部分网元功能如下：
用户设备(user equipment，UE)，包括主叫用户设备(也可以被称为主叫UE或者Caller)和被叫用户设备(也可以被称为被叫UE或者Callee)，该主叫UE用于对被叫UE发起电话呼叫，该被叫UE用于接收主叫UE的呼叫。
呼叫会话控制功能(call session control function，CSCF)：CSCF是IMS中的会话控制功能体。CSCF在IMS中实现了多媒体呼叫中主要的软交换控制功能。CSCF又可以分为代理呼叫控制实体(proxy-call session control function，P-CSCF)、查询呼叫控制实体(interrogating-call session control function，I-CSCF)和服务呼叫控制实体(serving-call session control function，S-CSCF)。
P-CSCF：可处于UE当前所在的接入网内，作为UE接入IMS网络的第一个联系网元，把UE的初始会话协议(session initiation protocol，SIP)消息转发到IMS核心网，并且将收到的SIP消息转发给UE。
S-CSCF：作为核心的呼叫控制实体，完成基本的呼叫控制功能，基本上任何SIP消息都要经过它的处理，包括路由、应用服务器(application server，AS)业务触发、重走向等主要控制功能。
多媒体电话(multimedia telephony，MMTEL)AS：MMTEL AS用于向用户提供各种业务，例如基本的语音、时频通话业务，以及各种补充业务等，是实现具体业务的服务器。通常MMTEL AS由S-CSCF根据用户请求以及触发条件进行触发。
3GPP定义了MMTEL业务的基本规范，除了基本的语音通话业务，MMTEL还包括20多种补充业务，例如，个性化彩铃业务、呼叫转移业务、语音信箱业务等。对于当前的IMS机制， 上述包括基本的语音通话业务在内的20多种MMTEL业务通常作为一个整体进行提供。
也就是说。由于MMTEL可能包括多种业务(例如现有的20多种)，因此也可能对应多个AS。例如，图1中共包括n(n为大于2的整数)个AS，每个AS用于提供不同的MMTEL业务。
归属用户服务器(home subscriber server，HSS)：HSS记录每个IMS用户的用户信息与业务数据，配合CSCF完成路由功能，并提供认证、授权等功能。用户签约数据保存在HSS中，并在用户注册时被下载到S-CSCF，用户签约数据中保存了用户的初始过滤规则(initial filter criteria，IFC)和提供业务的AS的地址信息。业务数据在用户注册时从HSS下载到AS，供AS完成用户业务处理所用。
如图1所示，当主叫UE发起对被叫UE的音视频呼叫时，主叫UE可以通过P-CSCF向S-CSCF发送呼叫邀请(invite)消息，S-CSCF可以从HSS下载预先静态配置好的针对主叫UE的IFC消息，并且根据IFC触发机制确定本次呼叫触发了哪些补充业务，相应的AS提供该补充业务。
结合上述分析，现有的IMS的基本架构具有如下特点：
(1)根据现有的IMS系统架构，MMTEL共20多种业务作为一个整体提供(即图1中的多个AS作为一个整体进行提供)，主要提供了多种补充业务之间的交互。S-CSCF需要同时具备对这20多种业务的管理能力。
(2)采用IFC的呼叫邀请首消息触发机制以便触发到一个或者多个AS，一般采用预先静态配置方式，并由运营商的业务支撑系统(business support system，BSS)系统发放实现。
(3)MMTEL业务通常由运营商提供，即MMTEL业务采用家网络提供方式，业务需要回到家网络处理以保持业务的一致性。
(4)现有架构提供基于应用程序接口(application programming interface，API)的对外开放接口。
VoNR的主要需求之一是面向2B的应用。在未来2B的应用场景中大量的业务应用是由第三方提供或者企业自己提供，现有的IMS系统架构已经无法满足当前2B应用场景的使用需求，不利于2B应用的快速部署。具体地，现有的IMS架构具有如下局限性：
(1)根据现有的IMS系统架构，MMTEL共20多种业务作为一个整体提供，S-CSCF需要同时具备对这20多种业务的管理能力。使得S-CSCF的业务配置数据复杂，部署时需要大量的虚拟机。在面向未来2B的行业应用中最需要的通常只有基本通话的业务，95％左右的话务都不涉及补充业务，即使涉及到一些补充业务，也可能并不属于上述20多种MMTEL业务，因此现有的IMS系统架构不利于2B应用的灵活、快速部署。
(2)采用IFC的静态配置需要经过运营商的BSS发放系统，导致众多的行业应用的部署不够方便，同时单一的Invite点触发并不能很好的体现业务自定义的灵活性。
(3)IMS采用用户所归属的运营商的家网络来提供业务，在未来2B的应用场景中大量的业务应用是由第三方提供或者企业自己提供，因此业务处理必须回家网络已经不能满足要求。
(4)基于简单孤立的API模式难以满足基于事件序列的时序性逻辑和业务的组织要求，同时API提供的单向被集成模式并不能满足更为丰富的商业行为。
针对上述问题，本申请实施例首先提供一种呼叫系统，通过剥离基本通话为呼叫处理设备来实现简化的2B行业音视频框架，能够满足当前2B应用场景的使用需求，使得2B的应用能够快速部署。图2是本申请实施例提供的呼叫处理系统的一例的系统架构示意图。
如图2所示，本申请实施例提供的呼叫系统包括呼叫处理设备和事件管理器。
呼叫处理设备，用于为主叫UE发起的呼叫进行接通和路由处理，还用于针对该呼叫进行事件检测，并且将检测到的事件上报给事件管理器；其中，检测到的事件用于请求触发针对该呼叫的更新处理；
事件管理器，用于根据上报的事件，管理该呼叫的更新处理。
具体地，在本申请实施例中，呼叫处理设备和事件管理器相互独立设置，并且设置在不同的网路实体上，或者说，二者本身属于不同的网络实体。例如，呼叫处理设备可以是设置于中国境内网络实体，而事件管理器可以是设置于欧洲境内的网络实体，二者可以实现网络通信。
其中，呼叫处理设备保留基本呼叫的接通和路由能力，能够用于为主叫UE发起的呼叫进行接通和路由处理。该呼叫处理设备可以提供媒体的连接能力，提供基于数据主权组织业务逻辑和路由逻辑的能力。
此外，呼叫处理设备还能够针对本次呼叫进行事件检测，并且将检测到的事件上报给事件管理器。本申请对事件的类型并不限定。
例如，该事件可以是2B类型的事件，即此时呼叫处理设备可以对2B类型的事件进行检测，并且将检测到的2B事件上报给2B事件管理器。
再例如，该事件可以是面向用户(to customer，2C)事件，即此时呼叫处理设备可以对2C类型的事件进行检测，并且将检测到的2C事件上报给2C事件管理器。
在本申请实施例中，呼叫处理设备还能够针对本次呼叫进行事件检测，并且将检测到的事件上报给事件管理器。其中，针对本次呼叫进行事件检测，可以是在呼叫的任意过程中对事件进行检测，也可以是在本次呼叫完成之后对与本次呼叫有关的事件进行检测。
例如，该检测可以是在基本呼叫建立完成之前进行的，也可以是在基本呼叫建立完成和通知被叫UE振铃之间进行的，也可以是在通话进行中执行的，也可以是通话完成(挂机)之后进行的，本申请对此不做限定。
可选地，该事件可以包括信令面事件和/或媒体面事件。也就是说，呼叫处理设备还能够针对本次呼叫进行信令面和/或媒体面事件检测。本申请实施例对呼叫处理设备如何对事件进行检测不做限定。
例如，对于信令面事件的检测，呼叫处理设备可以通过检测接收或者发送某条信令确定检测到某一事件。
再例如，对于媒体面事件的检测，呼叫处理设备可以通过检测到某条媒体信息确定检测到某一事件。
再例如，呼叫处理设备可以通过呼叫状态的改变确定检测到某一事件。
在本申请实施例中，检测到事件用于请求触发针对该呼叫的更新处理。具体地，这里“针对该呼叫的更新处理”，可以理解成对本次呼叫的状态和处理过程进行更新(update)服务，是对本次会话的更新。在这里，更新处理为除了接通和路由处理之外的其他处理。因此，本申请中“请求触发针对该呼叫的更新处理”在一些情况下也可以理解成请求触发针对该呼叫的补充业务。
例如，该呼叫的更新更新处理可以包括修改号码显示，修改呼叫的方向，媒体修改路径、媒体修改编解码类型等中的至少一种。
可选地，该呼叫的更新处理可以为一个更新处理，也可以为多个更新处理。也就是说， 可以根据检测到的事件请求触发一个或者多个针对该呼叫的更新处理。
可选地，可以由一个事件请求触发一个更新处理。
可选地，也可以由多个事件请求触发一个更新处理。
呼叫处理设备在检测到事件以后，可以将检测到的事件上报到事件管理器。本申请对上报所使用的接口类型不做限定。对于信令面事件和媒体面事件，呼叫处理设备可以通过相同或者不同的接口进行上报。
可选地，检测到的事件可以通过SIP接口进行上报。
可选地，检测到的事件可以通过非SIP(Non-SIP)接口进行上报。
例如，呼叫处理设备可以通过事件上报接口1(EventReportInt1接口)向事件管理器上报检测到的信令面事件；呼叫处理设备可以通过事件上报接口2(EventReportInt2接口)向事件管理器上报检测到的媒体面事件。
进一步地，事件管理器用于接收该检测到的事件，并且根据接收的事件，管理该呼叫更新处理。例如，触发更新处理、阻止(屏蔽)更新处理、确定为更新处理提供服务的应用服务器、对多个更新处理提供队列管理等等，本申请对此不做限定。
根据本申请实施例提供的呼叫系统，呼叫处理设备保留基本的音视频通话功能的“最小核”，能够用于为主叫UE发起的呼叫进行接通和路由处理。并且，呼叫处理设备还用于针对呼叫进行事件检测，并且检测到的事件上报给事件管理器，由事件管理器来对相应的更新处理进行管理。
根据本申请实施例提供的呼叫系统，能够满足当前2B应用场景的使用需求，使得2B的应用能够快速部署。具体地，本申请通过剥离基本通话“最小核”为呼叫处理设备来实现简化的2B行业音视频框架，使得2B的应用能够快速部署，节省不必要的虚拟机，同时可以做到零数据配置增强安全能力。本申请对于呼叫的更新处理采用触发机制，并且由事件管理器对相关更新处理进行管理，基本呼叫不必触发而直接在呼叫处理设备提供，从而减少95％的补充业务资源占用和开销，增加部署的灵活性和快速能力，减少能耗。
可选地，在本申请实施例中，呼叫处理设备支持信令面和媒体面事件的灵活定义。具体地，呼叫处理设备可以获取事件的定义信息，并且根据该定义信息对事件进行检测。
例如，该呼叫处理设备可以归属于网络运营商，可以通过网络运营商对呼叫处理设备检测的事件进行定义。
可选地，根据具体使用需求，该呼叫处理设备除了保留基本的音视频通话的管理能力，还可以保留至少一种其他2B场景下会经常用到的MMTEL业务的管理能力。也就是说，呼叫处理设备除了能够用于为主叫UE发起的呼叫进行接通和路由处理，还可以用于至少一项其他处理，本申请对此并不限定。
在本申请实施例中，事件管理器用来对相应的更新处理进行管理。下面对事件管理器如何对更新处理进行管理做进一步说明。
可选地，可以通过该事件管理器触发更新处理，此时，事件管理器具体用于：根据呼叫处理设备上报的检测到的事件，确定为该更新处理提供服务的第三方应用服务器。
具体地，检测到的事件能够用于请求触发针对该呼叫的更新处理，事件管理器在决定触发该更新处理以后，可以确定为该更新处理提供服务的应用服务器。此时，事件管理器可以向该应用服务器上报触发指令，该触发指令包括检测到的事件相关的参数集。
可选地，该应用服务器为可以是企业(例如外卖、出租车行业的企业)部署的第三方应 用服务器。
可选地，该应用服务器可以是运营商部署的MMTEL服务器。
作为具体的一例，在图2中，呼叫处理设备检测到事件#1，并且为信令面事件，此时可以通过EventReportInt1接口向事件管理器进行上报，事件管理器确定可以触发该事件#1所请求触发的更新处理#1，此时可以确定由应用方服务器#1来为更新处理#1(例如修改号码显示)提供服务，此时可以向应用服务器#1上报触发指令，该触发指令包括事件#1相关的参数集。该应用服务器#1可以由企业进行部署，例如外卖企业、出租车企业。在其他实施方式中，该应用服务器#1还可以由网络运营商提供。
在本申请实施例中，事件管理器可以根据上报的事件确定哪一个或者多个更新处理被请求触发，此时可以按照任意的控制逻辑选择提供服务的应用服务器，本申请对此不做限定。
作为一种可能的实现方式，在本申请实施例中，事件管理器能够提供事件的订阅管理机制。此时，事件管理器可以获取订阅关系信息，该订阅关系信息反应事件与服务器的对应关系，并且根据检测到的事件和该订阅关系，确定为更新处理提供服务的应用服务器。
具体地，该订阅关系能够体现哪些应用服务器订阅了哪些事件，能够体现事件和应用服务器的对应关系。可选地，该订阅关系可以由企业进行定义，并且存储在本地。
事件管理器能够根据检测到的事件和该订阅关系，确定哪些(或者哪一个)AS订阅了该事件，并且确定其中的一个或者多个AS来为该更新处理提供服务。
可选地，若事件管理器在该订阅关系中查询到只有一个AS订阅了该事件，此时事件管理器可以选择该唯一的一个AS来为该更新处理提供服务。
可选地，若事件管理器在该订阅关系中查询到有多个AS订阅了该事件，此时事件管理器可以选择其中的一个或者多个AS来为该更新处理提供服务。
例如，可以选择其中优先级最高的一个AS来为该更新处理提供服务。
作为具体的一例，若事件管理器确定某一事件请求触发的更新处理为监听，此时事件管理器查询到有多个AS订阅了该事件，则此时事件管理器根据本地控制策略可以选择安全性更高的由政府部署的AS服务器来提供监听服务。
可选地，在其他实施例中，若事件管理器在该订阅关系中未查询到订阅该事件的AS，则此时事件管理器可以选择不触发该更新处理。
作为具体的一例，在图2中，事件管理器接收到该事件#1，并且根据订阅关系确定应用服务器#1订阅了该事件，此时可以确定由应用方服务器#1来为更新处理#1提供服务。
可选地，也可能由多个事件来请求触发一个更新处理，则此时可以由多个事件的逻辑组合和该订阅关系信息，确定为更新处理提供服务的应用服务器。
具体地，对于某一个AS(记作AS#a)，其可以订阅多个事件，例如订阅事件#1、#3、#4，该事件#1、#3、#4一起用于请求触发针对呼叫的某一个更新处理(记作更新处理#a)，此时，当事件管理器确定上报的事件包括#1、#3、#4时，并且查询订阅关系信息，能够确定由AS#a来对本次呼叫提供更新处理#a的服务。
综上所述，本申请基于现有IMS框架，还提供了一种更为灵活的业务触发机制，突破现有IMS仅有IFC Invite基于静态业务发放机制的限制，能够让第三方应用服务器任意定义自己的业务，而无需经过运营商的BSS发放系统，事件处理逻辑解耦，从而保证2B的第三方应用服务器的独立性和灵活性；事件订阅和业务逻辑完全归属于企业本身，确保企业数据和业务的隐私安全。
根据本申请的实施例，提供更为灵活的松耦合的触发机制，便于业务由行业企业自行定义，灵活接插；多事件管理的触发机制，灵活可编程自定义除Invite之外的各种信令和媒体事件，消除静态签约的局限性，同时改静态的IFC签约为基于灵活订阅的事件触发，包括信令事件和媒体事件，从而有利于2B应用的快速、灵活部署。
可选地，本申请的事件管理器还可以提供队列管理机制，能够对上报的多个事件进行队列管理。
具体地，事件管理器可以根据上报的事件以及存储在本地的队列管理策略(例如该队列管理策略包括各个事件的优先级信息)，对该多个事件进行队列管理。进而能够对该多个事件所请求触发的多个更新处理进行队列管理。
可选地，本申请的事件管理器还可以提供事件屏蔽机制，能够对上报的事件进行屏蔽管理。
具体地，可以根据存储在本地的屏蔽策略，对上报的事件进行屏蔽操作。例如，对于特定的事件，可以对其进行屏蔽，而不触发该事件所请求触发的更新处理，即此时可以不向应用服务器上报触发指令。
作为具体的一例，在图2中，事件管理器接收到事件#2(该事件#2为媒体面事件，并且通过EventReportInt2接口上报到事件管理器)，事件管理器根据本地存储的屏蔽策略(例如存在一个屏蔽事件列表)确定该事件#2所请求触发的更新处理(例如为监听)是不被允许的，则此时可以选择屏蔽该事件，而不将事件#2(的触发指令)上报到相应的应用服务器。
本申请对触发指令的上报所使用的接口类型不做限定。对于信令面事件和媒体面事件，事件管理器可以通过相同或者不同的接口向应用服务器进行上报。
可选地，触发指令可以通过SIP接口进行上报。
可选地，触发指令可以通过Non-SIP接口进行上报。
例如，事件管理器可以通过事件触发接口1(EventTriggerInt1接口)向应用服务器触发信令操作；事件管理器可以通过事件触发接口2(EventTriggerInt1接口)向应用服务器触发媒体操作。
进一步地，本申请提供的呼叫处理系统还可以包括应用服务器，该应用服务器可以由企业等第三方提供，或者，也可以由运营商提供。
该应用服务器根据事件管理器上报的触发指令，生成相应的处理结果。该处理结果可以首先发送至事件管理器，该事件管理器能够对该处理结果进行管理，之后将处理结果转发至呼叫处理设备，呼叫处理设备执行针对该呼叫的更新处理。
在本申请实施例中，事件管理器对该处理结果进行管理，可以是对该处理结果进行审核，确定是否符合要求，在符合要求的情况下才转发至呼叫处理设备，以触发相应的更新处理。若确定不符合要求(即处理结果不合理)，则此时可以不将该处理结果转发至呼叫处理设备，以屏蔽(或者阻止)该更新处理的触发。
可选地，该处理结果可以是“直接的”结果(例如对于修改号码显示，该结果可以直接是被修改后的号码)，也可以是一个调用接口API或者一段可执行脚本，本申请对此不做限定。
进一步地，呼叫处理设备在接收到该处理结果以后，可以执行相应的更新处理。可选地，呼叫处理设备可以通过会话内修改(in-call-modify)和/或重邀请(re-invite)的方法为本次呼叫进行更新处理。
进一步地，为了提高呼叫处理设备的通用性，本申请提供的呼叫处理设备能够同时支持 IP路由和ID路由的机制，便于拓展各种类型的第三方应用程序(application，APP)。此时，呼叫处理设备获取的呼叫邀请消息中可以同时包括第一标识(identification，ID)和第一网际互连协议(internet protocol，IP)、第二ID和第二IP；第一ID为主叫UE的ID，第一IP为主叫UE的IP，第二ID为被叫UE的ID，第二IP为被叫UE的IP。此时，呼叫处理设备可以根据需求任意选择通过IP或者ID来进行路由。从而使得本申请的呼叫处理系统能够为不同类型的用户设备提供服务。
进一步地，根据主叫UE的数据主权拥有者(例如主叫UE的HSS)的具体控制策略，第一ID可以为主叫UE的真实ID或者匿名ID，第一IP可以为主叫UE的真实IP或者匿名IP。
类似地，根据被叫UE的数据主权拥有者(例如被叫UE的HSS)的具体控制策略，第二ID可以为被叫UE的真实ID或者匿名ID，第二IP可以为被叫UE的真实IP或者匿名IP。
应理解，被叫UE可能处于漫游状态，因此被叫UE的数据主权拥有者可能拥有两个，例如被叫UE家网络的HSS是ID的数据主权拥有者，被叫UE拜访网络的HSS是IP的数据主权拥有者。
如图2所示，本申请提供的呼叫处理系统还包括边界控制器(session border controller，SBC)，SBC通常位于对等环境中的两个服务提供商网络之间，或者位于接入网络和骨干网络之间，以向个人或企业客户提供服务。它们提供各种功能以启用或增强基于SIP会话的多媒体服务。在一些情况下，SBC也能够用于实现前述的P-CSCF的部分或者全部功能。在一些情况下，P-CSCF也能够用于替换本申请中的SBC。
本申请实施例提供的呼叫处理系统还包括主叫侧SBC和被叫侧SBC，该主叫侧SBC用于传递主叫UE和呼叫处理设备之间的信令交互，该被叫侧SBC用于传递呼叫处理设备和被叫UE之间的信令交互。
图3是本申请实施例提供的呼叫处理系统的另一例的系统架构示意图。
相对于前述实施例，本申请实施例提供的方案主要区别在于针对同一个呼叫处理设备，同时提供了两个事件管理器，该两个事件管理器分别用于管理不同类型的事件。例如，一个用于管理2B事件，一个用于管理2C事件。下文中，将用于管理2B事件的事件管理器称为2B事件管理器，将用于管理2C事件的事件管理器称为2C事件管理器。
具体地，本实施例提供的处理系统包括呼叫处理设备和2B事件管理器、2C事件管理器，该呼叫处理设备能够对2B事件和2C事件进行检测，并且将检测到的2B事件上报到2B事件管理器，将检测到的2C事件上报到2C事件管理器。
类似地，呼叫处理设备可以对2B事件的信令面和媒体面事件进行检测，还可以对2C事件的信令面和媒体面事件进行检测。上述被检测到的事件通过相应的接口上报到各自的事件管理器。
例如，呼叫处理设备可以将检测到的2B事件上报到2B事件管理器，2B事件管理器对相应的更新处理进行管理。例如，可以将触发指令上报到相应的第三方应用服务器，该第三方应用服务器可以由企业等第三方部署，由于2B业务数据属于企业自己，因此由企业自己的第三方应用服务器持有。
再例如，呼叫处理设备可以将检测到的2C事件上报到2C事件管理器，2C事件管理器对相应的更新处理进行管理。例如，可以将触发指令上报到相应的MMTEL服务器，该MMTEL服务器由网络运营商部署，由于2C业务数据属于运营商，因此只能保存在运营商自己部署的服务器和HSS之间。
结合前述分析，本申请实施例还提供一种呼叫处理方法，该方法可以应用于前述实施例提供的呼叫处理系统，也可以应用于其他系统，本申请对此不做限定。
图4是本申请实施例提供的呼叫处理方法100的示意性流程图。以下，结合图4阐述本申请实施例提供的呼叫处理方法100，该方法100包括：
步骤101，主叫UE向主叫侧SBC发送第一呼叫请求消息；
相应地，在步骤101中，主叫侧SBC接收主叫UE发送的第一呼叫请求消息。
步骤102，主叫侧SBC向用户数据服务器发送路由请求消息(SearchRoutingInfo，SRI)，该路由请求消息用于请求主叫UE的ID和IP，以及，用于请求被叫UE的ID和IP。
相应地，在步骤102中，用户数据服务器接收主叫侧SBC发送的路由请求消息。
步骤103，归属用户服务器确定第一ID、第一IP、第二ID、第二IP；其中，所述第一ID为主叫UE的ID，第一IP为主叫UE的IP，第二ID为被叫UE的ID，第二IP为被叫UE的IP。
步骤104，用户数据服务器向主叫侧SBC发送第一路由响应消息(SearchRoutingInfo response，SRI-Rsp)，该第一路由响应消息携带第一ID、第一IP、第二ID、第二IP；
相应地，在步骤104中，主叫侧SBC接收用户数据服务器发送的该路由响应消息。
具体地，在本申请实施例中，主叫UE向主叫侧SBC发送第一呼叫消息，以发起一个呼叫的建立流程，该第一呼叫消息可以携带主叫UE和被叫UE的真实ID。
其中，这里的ID用来标识UE的身份，例如，该ID可以是移动用户国际ISDN/PSTN号码(mobile subscriber international ISDN/PSTN number)，在这里，ISDN是综合业务数字网，全称为integrated services digital network，PSTN是公共交换电话网络，全称为public switched telephone network。这里的IP是指IP地址。
主叫侧SBC在接收到该第一呼叫消息之后，向用户数据服务器发送第一路由请求消息，该第一路由请求消息用于请求路由，具体地，用于请求主叫UE的ID和IP，以及，用于请求被叫UE的ID和IP。该第一路由请求消息可以携带主叫UE和被叫UE的真实ID。
在步骤103中，用户数据服务器确定第一ID、第一IP、第二ID、第二IP。在本申请实施例中，用户数据服务器作为上述数据的数据主权者，可以基于隐私以及安全等方面的考量，确定是否提供真实的ID和IP给主叫侧SBC。也就是说，上述第一ID可以是主叫UE的真实ID，也可以是匿名ID，上述第一IP可以是主叫UE的真实IP，也可以是匿名IP。类似地，上述第二ID可以是被叫UE的真实ID，也可以是匿名ID，上述第二IP可以是被叫UE的真实IP，也可以是匿名IP，作为数据主权者的用户数据服务器可以任意进行确定，本申请对此不做限定。
可选地，该用户数据服务器可以为归属用户服务器HSS。
例如，归属用户服务器发现被叫UE就在本域，本域拥有ID+IP的主权数据，并且确认符合欧盟安全法则，此时可以将被叫UE的真实ID确定为第二ID，将被叫UE的真实IP确定为第二IP，并且发送给主叫侧SBC。
相应地，如果确定不符合欧盟的安全法则，也可以按照预定的策略对被叫UE的ID和IP进行匿名处理，并且将匿名之后的ID发送给主叫侧SBC。
本申请对如何进行ID和IP的匿名处理不做限定，归属用户服务器可以按照预定策略(算法)进行匿名处理，例如，可以在被叫侧SBC的IP附加一个临时扩展随机数以作为该第二IP。
再例如，如果被叫UE为物联网(the internet of things，IoT)场景下的智能设备，则此时主叫UE的ID和IP没有泄露的风险，则此时可以将主叫用户真实的ID和IP确定为第一ID和第一IP，并且返回给主叫侧SBC。
应理解，在本申请实施例中，主叫UE的ID和IP，被叫UE的ID和IP的数据主权可能归属于不同的多个归属用户服务器，为了确定上述第一ID、第一IP、第二ID、第二IP，可能需要该多个归属用户服务器共同确定，也就是说，在步骤103中，“用户数据服务器确定第一ID、第一IP、第二ID、第二IP”中的“用户数据服务器”可能指代多个HSS，该多个HSS可以看作一个分布式的整体。
例如，该用户数据服务器可以包括主叫UE家网络中的HSS(记作HSS#1)和被叫UE家网络中的HSS(记作HSS#2)。此时，HSS#1拥有主叫UE的ID和IP的数据主权，HSS#2拥有被叫UE的ID和IP的数据主权。
再例如，该用户数据服务器除了包括上述HSS#1和HSS#2之外，还可以包括HSS#3，该HSS#3为被叫UE拜访网络中的HSS。此时，HSS#1拥有主叫UE的ID和IP的数据主权，HSS#2拥有被叫UE的ID的数据主权，HSS#3拥有被叫UE的IP的数据主权。
在步骤104中，用户数据服务器向主叫侧SBC发送第一路由响应消息，该第一路由响应消息携带第一ID、第一IP、第二ID、第二IP。
可选地，该第一路由响应消息可以仅指一条消息，此时该唯一的一条消息将第一ID、第一IP、第二ID、第二IP发送至主叫侧SBC。
可选地，该第一路由响应消息也可以(指代)包括多条消息，此时可以分多条消息将第一ID、第一IP、第二ID、第二IP发送至主叫侧SBC，本申请对此不做限定。
进一步地，结合前述的分析可知，用户数据服务器可以包括多个HSS，此时该多条消息可以由同一个或者不同的HSS向主叫侧SBC进行发送，本申请对此不做限定。
相应地，在步骤101中，该第一呼叫请求消息可以仅指一条消息，此时该唯一的一条消息同时对主叫UE、被叫UE的ID和IP进行请求。
可选地，该第一呼叫请求消息也可以(指代)包括多条消息，此时可以分多条消息对主叫UE、被叫UE的ID和IP进行请求，本申请对此不做限定。
例如，可以通过一条第一呼叫请求消息请求主叫UE的ID和IP，通过另外一条第一呼叫请求消息请求被叫UE的ID和IP。
主叫侧SBC在接收到该该第一路由响应消息，可以根据该第一路由响应消息进行路由。
具体地，本申请实施例提供的方法100还包括：
步骤105，主叫侧SBC向呼叫处理设备发送第二呼叫请求消息，该第二呼叫请求消息携带该第一ID、第一IP、第二ID、第二IP。
相应地，在步骤105中，呼叫处理设备接收主叫侧SBC发送的第二呼叫请求消息。
具体地，第二呼叫请求消息中携带了主叫UE和被叫UE的ID和IP，并且，该ID和IP可以是真实的，也可以是匿名的，本申请实施例将现有技术中依赖主被叫号码进行逐跳路由替代为数据主权者来提供IP+ID路由，由此能够确保用户数据的主权，呼叫处理设备不会接触用户的隐私数据，从而能够保护用户的隐私。同时，可以屏蔽基于不同运营商的差异，即运营商的编码方案的差异全部被屏蔽，转为更为通用的IP路由和虚拟的统一ID路由。同时也增强了HSS的数据价值。
可选地，第一路由响应消息还携带有第一指示信息，该第一指示信息用于指示第一ID、 第二ID是真实ID还是匿名ID，以及用于指示第一IP、第二IP是真实IP还是匿名IP。
通过该第一指示信息告诉主叫侧SBC主被叫的ID和IP是真实的还是匿名的，能够防止主叫侧SBC发生逻辑混乱，有利于主叫侧SBC进行路由决策。
可选地，如图4所示，本申请实施例提供的方法100还包括：
步骤106，呼叫处理设备根据第二ID或者第二IP，向被叫侧SBC发送第三呼叫请求消息，该第三呼叫请求消息携带该第一ID、第一IP、第二ID、第二IP；
相应地，在步骤106中，被叫侧SBC接收该第三呼叫请求消息。
步骤107，被叫侧SBC向被叫UE发送第四呼叫请求消息；
相应地，在步骤107中，被叫UE接收被叫侧SBC发送的第四呼叫请求消息。
具体地，呼叫处理设备可以根据具体情况，选择通过第二ID或者第二IP来进行路由，并且将第三呼叫请求消息路由至被叫侧SBC，该被叫侧SBC可以继续向被叫UE发送第、四呼叫请求消息，以进行下一步的呼叫流程。
进一步地，该第三呼叫请求消息携带该第一ID、第一IP、第二ID、第二IP，以帮助被叫侧SBC进行下一步路由。
可选地，该第四呼叫请求消息中可以携带被叫UE的真实ID和IP，即此时被叫侧SBC可以对被叫UE的匿名的ID和IP进行还原，本申请对此不做限定。
可选地，本申请实施例提供的方法100还包括：
步骤108，呼叫处理设备针对本次呼叫进行事件检测，以获得第一事件集，该第一事件集包括至少一个事件，该第一事件集用于请求触发针对本次呼叫的更新处理；
步骤109，呼叫处理设备向事件管理器发送该第一事件集；
步骤110，呼叫处理设备接收管理器发送的处理结果；
步骤111，呼叫处理设备根据该处理结果进行本次呼叫的更新处理。
具体地，呼叫处理设备可以针对本次呼叫进行事件检测，并且将检测到的事件(即第一事件集)上报给事件管理器，由事件管理器来对相应的更新处理进行管理。
此时，事件管理器可以向应用服务器上报触发指令，该触发指令包括检测到的事件相关的参数集。该应用服务器根据事件管理器上报的触发指令，生成相应的处理结果。该处理结果可以首先发送至事件管理器，该事件管理器能够对该处理结果进行管理，之后将处理结果转发至呼叫处理设备，呼叫处理设备执行针对该呼叫的更新处理。
例如，呼叫处理设备可以通过会话内修改和/或重邀请的方法为本次呼叫进行更新处理。
上述步骤108至步骤111可以参照前述对呼叫处理系统有关方面的内容进行理解，本申请在此不再赘述。
图5是本申请实施例提供的呼叫处理方法200的示意性流程图，图5所示实施例可以看作是图4所示实施例中的更进一步说明。在图5所示的实施例中，主要针对多个HSS构成的分布式整体之间如何进行信令交互进行说明。也就是说，图5中由HSS#1和HSS#2构成的分布式整体，可以对应于图4中所示出的用户数据服务器。
为了突出重点，本实施例对图5做了一些简化处理，应理解，图5中还可以包括其他更多的网元，例如包括图4中的主叫UE、被叫UE、呼叫处理设备、事件管理器、被叫侧SBC等，与上述被省略的网元之间的交互流程也未未在图5中示出。
在图5所示的实施例中，被叫侧UE未发生漫游(local break out)，被叫UE家网络中的用户归属服务器HSS#2拥有被叫UE的ID和IP的数据主权。以下，结合图5说明本申请实 施例提供的呼叫处理方法200，方法200包括：
步骤210，主叫侧SBC向主叫UE家网络中的归属用户服务器HSS#1发送第一路由请求消息；
步骤220，HSS1#1向被叫UE家网络中的归属用户服务器HSS#2发送第二路由请求消息，该第二路由请求消息用于请求被叫UE的ID和IP；
步骤230，HSS#2确定第二ID和第二IP；
步骤240，HSS#1确定第一ID和第一IP；
步骤250，HSS#2向HSS#1发送第二路由响应消息，该第二路由响应消息携带第二ID和第二IP；
步骤260，HSS1#1向主叫侧SBC发送第一路由响应消息。
在本申请实施例中，第一路由请求消息、第一路由响应消息可以参照前述方法100中的第一路由请求消息、第一路由响应消息的进行理解，步骤210、260可以分别参照方法100中的步骤101、104进行理解，在此阐述不同之处。
具体地，主叫侧SBC在接收到主叫UE发送的第一呼叫消息之后，向HSS#1发送第一路由请求消息，该第一路由请求消息用于请求主叫UE的ID和IP，以及，用于请求被叫UE的ID和IP。该第一路由请求消息可以携带主叫UE和被叫UE的真实ID。
HSS#1向HSS#2发送第二路由请求消息，该第二路由请求消息用于请求被叫UE的ID和IP。该第二路由请求消息可以携带主叫UE和被叫UE的真实ID。
可选地，可以通过查表的方式获取HSS#2的IP，进而将第二路由请求消息发送至HSS#2。
可选地，该第二路由请求消息的内容该可以和第一路由请求消息的内容相同，此时，HSS#1可以仅起到“转发”的作用。
HSS#2在接收到该第二路由请求消息之后，确定第二ID和第二IP。HSS#2拥有被叫UE的ID和IP的数据主权，因此可以基于隐私以及安全等方面的考量，确定是否提供真实的ID和IP给主叫侧SBC。也就是说，上述第二ID可以是被叫UE的真实ID，也可以是匿名ID，上述第二IP可以是被叫UE的真实IP，也可以是匿名IP，作为数据主权者的HSS#2可以任意进行确定，本申请对此不做限定。
HSS#1在接收到该第一路由请求消息之后，确定第一ID和第一IP。HSS#1拥有主叫UE的ID和IP的数据主权，因此可以可以基于隐私以及安全等方面的考量，确定是否提供真实的ID和IP给主叫侧SBC。也就是说，上述第一ID可以是主叫UE的真实ID，也可以是匿名ID，上述第一IP可以是主叫UE的真实IP，也可以是匿名IP，作为数据主权者的HSS#1可以任意进行确定，本申请对此不做限定。
在步骤250中，HSS#2向HSS#1发送第二路由响应消息，该第二路由响应消息携带第二ID和第二IP。
可选地，该第二路由响应消息还可以包括第二指示信息，该第二指示信息用于指示第二ID是真实ID还是匿名ID，以及用于指示第二IP是真实IP还是匿名IP。
可选地，HSS#1在接收到第二路由响应消息之后，可以存储被叫UE的ID和IP的映射关系。
进一步地，HSS#1可以将第一ID和第一IP、第二ID和第二IP携带于第一路由响应消息中发送给主叫SBC。
在本申请实施例中，步骤240和步骤220、230、250没有逻辑上的先后关系，因此，本 申请不对步骤240和步骤220、230、250的先后关系进行限定。
例如，步骤240可以在步骤220之前执行，也可以在步骤220和步骤230之间执行，也可以在步骤230和步骤250之间执行，也可以在步骤250之后执行。
图6是本申请实施例提供的呼叫处理方法300的示意性流程图，图6所示实施例可以看作是图4所示实施例中的更进一步说明。在图6所示的实施例中，主要针对多个HSS构成的分布式整体之间如何进行信令交互进行说明。也就是说，图6中由HSS#1、HSS#2和HSS#3构成的分布式整体，可以对应于图4中所示出的用户数据服务器。
为了突出重点，本实施例对图6做了一些简化处理，应理解，图6中还可以包括其他更多的网元，例如包括图4中的主叫UE、被叫UE、事件管理器等，与上述被省略的网元之间的交互流程也未未在图6中示出。
在图6所示的实施例中，被叫侧UE发生漫游，被叫UE家网络中的用户归属服务器HSS#2拥有被叫UE的ID的数据主权，被叫UE拜访网络中的HSS#3拥有被叫UE的IP的数据主权。以下，结合图6说明本申请实施例提供的呼叫处理方法300，方法300包括：
步骤301，主叫侧SBC向主叫UE家网络中的归属用户服务器HSS#1发送第一路由请求消息；
步骤302，HSS1#1向被叫UE家网络中的归属用户服务器HSS#2发送第二路由请求消息；
步骤303，HSS#2确定被叫UE不在本域，向被叫UE拜访网络中的归属用户服务器HSS#3发送第三路由请求消息，该第三路由请求消息用于请求被叫UE的IP；
步骤304，HSS#3确定第二IP；
步骤305，HSS#3向HSS#2发送第三路由响应消息，该第三路由响应消息携带第二IP；
步骤306，HSS#2确定第二ID；
步骤307，HSS#1确定第一ID和第一IP；
步骤308，HSS#2向HSS#1发送第二路由响应消息；
步骤309，HSS1#1向主叫侧SBC发送第一路由响应消息。
步骤310，主叫侧SBC向呼叫处理设备发送第二呼叫请求消息。
在本申请实施例中，第一路由请求消息、第一路由响应消息、第二路由请求消息、第二路由响应消息、第二呼叫请求消息可以参照前述方法100、200中的第一路由请求消息、第一路由响应消息、第二路由请求消息、第二路由响应消息、第二呼叫请求消息进行理解，步骤301、309可以分别参照方法100中的步骤101、104以及方法200中的步骤210、260进行理解，步骤310可以参照方法100中的步骤105进行理解，步骤302、307、308可以参照方法200中的步骤220、250、240进行理解，在此阐述不同之处。
在步骤302中，HSS#2在接收到该第二路由请求消息之后，确定被叫UE不在本域，即确定自己不具有被叫UE的IP数据主权，此时可以向被叫UE拜访网络中的归属用户服务器HSS#3发送第三路由请求消息，该第三路由请求消息用于请求被叫UE的IP。
可选地，该第三路由请求消息可以为路由重定向消息(SRI-Redirection)。
HSS#3在接收到该第三路由请求消息之后，确定第二IP。HSS#3拥有被叫UE的IP的数据主权，因此可以可以基于隐私以及安全等方面的考量，确定是否提供真实的IP给主叫侧SBC。也就是说，上述第二IP可以是被叫UE的真实IP，也可以是匿名IP，作为数据主权者的HSS#3可以任意进行确定，本申请对此不做限定。
在步骤305中，HSS#3向HSS#2发送第三路由响应消息，该第三路由响应消息携带第二 IP。
可选地，该第三路由响应消息可以为路由重定向响应消息(SRI-Redirection-Rsp)。
可选地，该第三路由响应消息可以携带第三指示信息，该第三指示信息用于指示第二IP是真实IP还是匿名IP。
在步骤308中，HSS#2由于仅拥有被叫UE的ID的数据主权，因此确定第二ID。在步骤307中，HSS#1拥有主叫UE的ID和IP的数据主权，确定第一ID和第一IP。上述确定过程可以参照方法100和方法200中的相关描述，在此不再赘述。
步骤304、306、307由于由不同的实体进行处理，在逻辑上没有先后的顺序要求，因此本申请不对步骤304、306、307的先后关系进行限定。
本申请提供的方法300还包括：
步骤311，呼叫处理设备向被叫侧SBC发送第三呼叫请求消息。
步骤312，被叫侧SBC接收呼叫处理设备发送的第三呼叫请求消息。
图7是本申请实施例提供的呼叫处理方法400的示意性流程图，图7所示实施例可以看作是图4所示实施例中的更进一步说明。在图7所示的实施例中，主要针对呼叫处理设备如何针对本次呼叫进行更新处理进行说明。
为了突出重点，本实施例对图7做了一些简化处理，应理解，图7中还可以包括其他更多的网元，例如包括图4中的主叫SBC、被叫SBC、归属用户服务器等，与上述被省略的网元之间的交互流程也未未在图7中示出。结合图7说明本申请实施例提供的呼叫处理方法400，方法400包括：
步骤410，基本呼叫建立完成，且指示被叫UE不振铃；
步骤420，呼叫处理设备针对本次呼叫进行事件检测；
步骤430，呼叫处理设备将检测到的第一事件集上报到事件管理器；
步骤440，事件管理器根据第一事件集，管理本次呼叫的更新处理，并且确定为本次呼叫的更新处理提供服务的应用服务器；
步骤450，呼叫处理设备将触发指令发送至该应用服务器，该应用服务器根据该触发指令生成处理结果；
步骤460，应用服务器将该处理结果发送至事件管理器；
步骤470，事件管理器对该处理结果进行管理，并且确定该处理结果符合要求；
步骤480，呼叫处理设备根据该处理结果，进行该呼叫的更新处理。
步骤499，在更新处理完成之后，原会话恢复振铃指示。
本实施例是在前述图5和6的基础上叠加会话内修改过程，实现机制是会话内的重呼叫(re-invite)方法。
具体地，在基本呼叫建立完成，且指示被叫UE不振铃(具体地，可以是基本呼叫完成到183消息，例如主叫UE接收到183消息)之后，呼叫处理设备可以针对本次呼叫进行事件检测，并且将检测到的事件(即第一事件集)上报给事件管理器，由事件管理器来对相应的更新处理进行管理。
此时，事件管理器根据第一事件集管理本次呼叫的更新处理，并且确定为本次呼叫的更新处理提供服务的应用服务器。进一步地，事件管理器可以向应用服务器上报触发指令，该触发指令包括检测到的事件相关的参数集。该应用服务器根据事件管理器上报的触发指令，生成相应的处理结果。该处理结果可以首先发送至事件管理器，该事件管理器能够对该处理 结果进行管理，在确定该处理结果符合要求之后，将处理结果转发至呼叫处理设备，呼叫处理设备执行针对该呼叫的更新处理。
应理解，该第一事件集可以仅包括一个事件，也就是说，呼叫处理设备在检测到一个事件以后，可以立即向事件管理器进行上报，之后进一步完成该事件对应的更新处理的流程。
当下一个事件被检测到是时，可以再次执行上述相同的流程，也就是说，在步骤499之前，步骤420-490可以循环执行多次，本申请对此不做限定。
上述步骤420至步骤490可以参照前述对呼叫处理系统有关方面的内容进行理解，本申请在此不再赘述。
上文结合图1至图7详细描述了本申请实施例的呼叫处理方法，下面结合图7至图10，详细描述本申请实施例的通信装置。应理解，图7至图10所示的通信装置能够实现图4-7所示的方法流程中的一个或者多个的步骤。为避免重复，在此不再详细赘述。
图8是本申请实施例提供的通信装置500的示意性框图。如图8所示，该装置500包括：
接收单元510，用于接收主叫用户设备UE的发送的第一呼叫请求消息；
发送单元520，用于向归用户数据服务器发送第一路由请求消息，所述第一路由请求消息用于请求所述主叫UE的标识ID和网际互连协议IP，以及，用于请求被叫UE的ID和IP；
接收单元510，用于接收所述用户数据服务器发送的第一路由响应消息，所述第一路由响应消息携带第一ID、第一IP、第二ID、第二IP；其中，所述第一ID为所述主叫UE的ID，所述第一IP为所述主叫UE的IP，所述第二ID为所述被叫UE的ID，所述第二IP为所述被叫UE的IP。
发送单元510，还用于向呼叫处理设备发送第二呼叫请求消息，所述第二呼叫请求消息携带所述第一ID、第一IP、第二ID、第二IP。
可选地，所述第一ID为所述主叫UE的真实ID或者匿名ID，所述第一IP为所述主叫UE的真实IP或者匿名IP；所述第二ID为所述被叫UE的真实ID或者匿名ID，所述第二IP为所述被叫UE的真实IP或者匿名IP。
可选地，所述第一路由响应消息还携带有第一指示信息，所述第一指示信息用于指示所述第一ID、第二ID是真实ID还是匿名ID，以及用于指示所述第一IP、第二IP是真实IP还是匿名IP。
具体地，该通信装置500可对应于根据本申请实施例的呼叫处理方法100、200、300、400中的主叫侧SBC，或配置于该主叫侧SBC中的芯片。该通信装置500可以包括用于执行图4-7中的主叫侧SBC执行的方法的单元。并且，该通信装置500中的各单元和上述其他操作和/或功能分别为了实现呼叫处理方法100、200、300、400中的主叫侧SBC的相应流程，各单元执行上述相应步骤的具体过程在方法100、200、300、400中已经详细说明，为了简洁，在此不再赘述。
在一种可能的实现方式中，上述通信装置500可以为主叫侧SBC，所述接收单元510和发送单元520可以是收发器，或收发电路。可选的，所述收发器也可以为输入/输出电路或者接口。
所述通信装置500还可以为芯片。所述接收单元510和发送单元520可以为芯片的输入/输出电路或者接口。
在一种可能的实现方式中，上述通信装置500可以为边界控制器，例如下文中的边界控制器60，其中接收单元510和发送单元520的功能可以通过边界控制器60的收发器602实 现。下文结合图9介绍本申请实施例的边界控制器60的结构。
图9是本申请实施例提供的边界控制器的结构示意图。如图9所示，该边界控制器60包括包括处理器601和收发器602。可选地，边界控制器60还包括存储器603。其中，处理器601、收发器602和存储器603之间通过内部连接通路互相通信，传递控制和/或数据信号，该存储器603用于存储计算机程序，该处理器601用于从该存储器603中调用并运行该计算机程序，以控制该收发器602收发信号。
上述处理器601和存储器603可以合成一个处理装置，处理器601用于执行存储器603中存储的程序代码来实现上述功能。具体实现时，该存储器603也可以集成在处理器601中，或者独立于处理器601。
图10是本申请实施例提供的通信装置700的示意性框图。如图10所示，该装置700包括：接收单元710、确定单元720和发送单元730。
接收单元710，用于接收主叫侧边界控制器SBC发送的第一路由请求消息，所述第一路由请求消息用于请求所述主叫用户设备UE的标识ID和网际互连协议IP，以及，用于请求被叫UE的ID和IP；
处理单元720，用于确定第一ID、第一IP、第二ID、第二IP；其中，所述第一ID为所述主叫UE的ID，所述第一IP为所述主叫UE的IP，所述第二ID为所述被叫UE的ID，所述第二IP为所述被叫UE的IP；
发送单元730，用于向所述主叫侧SBC发送第一路由响应消息，所述第一路由响应消息携带所述第一ID、第一IP、第二ID、第二IP。
可选地，所述第一ID为所述主叫UE的真实ID或者匿名ID，所述第一IP为所述主叫UE的真实IP或者匿名IP；所述第二ID为所述被叫UE的真实ID或者匿名ID，所述第二IP为所述被叫UE的真实IP或者匿名IP。
可选地，所述第一路由响应消息还携带有第一指示信息，所述第一指示信息用于指示所述第一ID、第二ID是真实ID还是匿名ID，以及用于指示所述第一IP、第二IP是真实IP还是匿名IP。
具体地，该通信装置700可对应于根据本申请实施例的通信方法100、200、300、400中的用户数据服务器(例如各个归属用户服务器HSS)，或配置于用户数据服务器中的芯片(例如HSS中的芯片)。该通信装置700可以包括用于执行方法100、200、300、400中的HSS执行的方法的单元。并且，该通信装置700中的各单元和上述其他操作和/或功能分别为了实现方法100、200、300、400的相应流程，各单元执行上述相应步骤的具体过程在方法100、200、300、400中已经详细说明，为了简洁，在此不再赘述。
在一种可能的实现方式中，上述通信装置700可以为用户数据服务器，所述接收单元710和发送单元730可以是收发器，或收发电路。可选的，所述收发器也可以为输入/输出电路或者接口。
所述通信装置700还可以为芯片。所述接收单元710和发送单元730可以为芯片的输入/输出电路或者接口。
在一种可能的实现方式中，上述通信装置700可以为用户数据服务器(例如HSS)，例如下文中的用户数据服务器80，其中处理单元820的功能可以由用户数据服务器80中的处理器801实现，接收单元710和发送单元730的功能可以通过用户数据服务器80的收发器802实现。下文结合图11介绍本申请实施例的用户数据服务器的结构。
图11是本申请实施例提供的用户数据服务器的结构示意图。如图11所示，该用户数据服务器80包括包括处理器801和收发器802。可选地，该用户数据服务器80还包括存储器803。其中，处理器801、收发器802和存储器803之间通过内部连接通路互相通信，传递控制和/或数据信号，该存储器803用于存储计算机程序，该处理器801用于从该存储器803中调用并运行该计算机程序，以控制该收发器802收发信号。
上述处理器801和存储器803可以合成一个处理装置，处理器801用于执行存储器803中存储的程序代码来实现上述功能。具体实现时，该存储器803也可以集成在处理器801中，或者独立于处理器801。
应理解，在本申请实施例中的处理器可以是中央处理单元(Central Processing Unit，CPU)，该处理器还可以是其他通用处理器、数字信号处理器(digital signal processor，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现成可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
还应理解，本申请实施例中的存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的随机存取存储器(random access memory，RAM)可用，例如静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data rate SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM，DR RAM)。
根据本申请实施例提供的方法，本申请还提供一种计算机程序产品，该计算机程序产品包括：计算机程序代码，当该计算机程序代码在计算机上运行时，使得该计算机执行图4-7所示实施例中任意一个实施例的方法。
根据本申请实施例提供的方法，本申请还提供一种计算机可读介质，该计算机可读介质存储有程序代码，当该程序代码在计算机上运行时，使得该计算机执行图4-7所示实施例中任意一个实施例的方法。
上述实施例，可以全部或部分地通过软件、硬件、固件或其他任意组合来实现。当使用软件实现时，上述实施例可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令或计算机程序。在计算机上加载或执行所述计算机指令或计算机程序时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以为通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集 合的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质。半导体介质可以是固态硬盘。
为了便于理解，下文中对本申请介绍方案的过程中涉及的名词进行说明。
在本申请实施例中，“指示”可以包括直接指示和间接指示，也可以包括显式指示和隐式指示。将某一信息(如前文中的“指示信息”)所指示的信息称为待指示信息，则具体实现过程中，对待指示信息进行指示的方式有很多种，例如但不限于，可以直接指示待指示信息，如待指示信息本身或者该待指示信息的索引等。也可以通过指示其他信息来间接指示待指示信息，其中该其他信息与待指示信息之间存在关联关系。还可以仅仅指示待指示信息的一部分，而待指示信息的其他部分则是已知的或者提前约定的。例如，还可以借助预先约定(例如协议规定)的各个信息的排列顺序来实现对特定信息的指示，从而在一定程度上降低指示开销。
在本申请实施例中，“第一”、“第二”、“第三”以及各种数字编号仅为描述方便进行的区分，并不用来限制本申请实施例的范围。例如，区分不同的指示信息信息等。
本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
本申请中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a,b,或c中的至少一项(个)，可以表示：a,b,c,a-b,a-c,b-c,或a-b-c，其中a,b,c可以是单个，也可以是多个。
在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (21)

  1. 一种呼叫处理系统，其特征在于，包括呼叫处理设备和事件管理器，
    所述呼叫处理设备，用于为主叫用户设备发起的呼叫进行接通和路由处理，还用于针对所述呼叫进行事件检测，并且将检测到的事件上报给所述事件管理器；其中，所述检测到的事件用于请求触发针对所述呼叫的更新处理；
    所述事件管理器，用于根据所述呼叫处理设备上报的事件，管理所述呼叫的更新处理。
  2. 根据权利要求1所述的系统，其特征在于，所述事件管理器具体用于：
    根据所述上报的事件，确定为所述呼叫的更新处理提供服务的应用服务器。
  3. 根据权利要求2所述的系统，其特征在于，所述事件管理器具体用于：
    获取应用服务器和事件的订阅关系信息；
    根据所述上报的事件和所述订阅关系信息，确定为所述呼叫的更新处理提供服务的应用服务器。
  4. 根据权利要求1-3中任一项所述的系统，其特征在于，所述事件管理器具体用于：
    根据本地存储的屏蔽策略，对所述上报的事件进行屏蔽管理。
  5. 根据权利要求2-4中任一项所述的系统，其特征在于，所述事件管理器具体用于：
    根据所述上报的事件生成触发指令，并且向所述应用服务器发送所述触发指令；
    接收所述应用服务器反馈的处理结果，所述处理结果由所述应用服务器根据所述触发指令生成；
    管理所述处理结果。
  6. 根据权利要求1-5中任一项所述的系统，其特征在于，所述呼叫处理设备还用于：
    获取事件的定义信息；
    根据所述定义信息对所述事件进行检测。
  7. 根据权利要求1-6中任一项所述的系统，其特征在于，所述呼叫处理设备具体用于：
    通过会话内修改和/或重邀请的方法为所述呼叫进行更新处理。
  8. 根据权利要求1-7中任一项所述的系统，其特征在于，所述上报的事件包括多个，所述呼叫处理设备具体用于：
    根据本地存储的队列管理策略，对所述上报的事件进行队列管理。
  9. 根据权利要求1-8中任一项所述的系统，其特征在于，所述呼叫的更新处理包括以下处理中的至少一种：
    修改号码显示，修改呼叫的方向，媒体修改路径、媒体修改编解码类型。
  10. 根据权利要求1-9中任一项所述的系统，其特征在于，所述事件包括媒体面事件和/或信令面事件。
  11. 一种呼叫处理方法，其特征在于，包括：
    主叫侧边界控制器SBC接收主叫用户设备UE发送的第一呼叫请求消息；
    所述主叫侧SBC向用户数据服务器发送第一路由请求消息，所述第一路由请求消息用于请求所述主叫UE的标识ID和网际互连协议IP，以及，用于请求被叫UE的ID和IP；
    所述主叫侧SBC接收所述用户数据服务器发送的第一路由响应消息，所述第一路由响应消息携带第一ID、第一IP、第二ID、第二IP；其中，所述第一ID为所述主叫UE的ID，所 述第一IP为所述主叫UE的IP，所述第二ID为所述被叫UE的ID，所述第二IP为所述被叫UE的IP；
    所述主叫侧SBC向呼叫处理设备发送第二呼叫请求消息，所述第二呼叫请求消息携带所述第一ID、所述第一IP、所述第二ID、所述第二IP。
  12. 根据权利要求11所述的方法，其特征在于，所述第一ID为所述主叫UE的真实ID或者匿名ID，所述第一IP为所述主叫UE的真实IP或者匿名IP；
    所述第二ID为所述被叫UE的真实ID或者匿名ID，所述第二IP为所述被叫UE的真实IP或者匿名IP。
  13. 根据权利要求12所述的方法，其特征在于，所述第一路由响应消息还携带有第一指示信息，所述第一指示信息用于指示所述第一ID、所述第二ID是真实ID还是匿名ID，以及用于指示所述第一IP、所述第二IP是真实IP还是匿名IP。
  14. 根据权利要求11-13中任一项所述的方法，其特征在于，所述方法还包括：
    所述呼叫处理设备根据所述第二ID或者所述第二IP，向被叫侧SBC发送第三呼叫请求消息，所述第三呼叫请求消息携带所述第一ID、所述第一IP、所述第二ID、所述第二IP。
  15. 根据权利要求11-14中任一项所述的方法，其特征在于，所述方法还包括：
    所述呼叫处理设备针对本次呼叫进行事件检测，以获得第一事件集，所述第一事件集包括至少一个事件，所述第一事件集用于请求触发针对所述呼叫的更新处理；
    所述呼叫处理设备向事件管理器发送所述第一事件集；
    所述呼叫处理设备接收所述管理器发送的处理结果；
    所述呼叫处理设备根据所述处理结果，进行针对所述呼叫的更新处理。
  16. 一种呼叫处理方法，其特征在于，包括：
    用户数据服务器接收主叫侧边界控制器SBC发送的第一路由请求消息，所述第一路由请求消息用于请求所述主叫用户设备UE的标识ID和网际互连协议IP，以及，用于请求被叫UE的ID和IP；
    所述用户数据服务器确定第一ID、第一IP、第二ID、第二IP；其中，所述第一ID为所述主叫UE的ID，所述第一IP为所述主叫UE的IP，所述第二ID为所述被叫UE的ID，所述第二IP为所述被叫UE的IP；
    所述用户数据服务器向所述主叫侧SBC发送第一路由响应消息，所述第一路由响应消息携带所述第一ID、所述第一IP、所述第二ID、所述第二IP。
  17. 根据权利要求16所述的方法，其特征在于，所述第一ID为所述主叫UE的真实ID或者匿名ID，所述第一IP为所述主叫UE的真实IP或者匿名IP；
    所述第二ID为所述被叫UE的真实ID或者匿名ID，所述第二IP为所述被叫UE的真实IP或者匿名IP。
  18. 根据权利要求17所述的方法，其特征在于，所述第一路由响应消息还携带有第一指示信息，所述第一指示信息用于指示所述第一ID、所述第二ID是真实ID还是匿名ID，以及用于指示所述第一IP、所述第二IP是真实IP还是匿名IP。
  19. 一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，当所述计算机程序在计算机上运行时，使得所述计算机执行如权利要求11至18中任意一项所述的方法。
  20. 一种芯片系统，其特征在于，包括：处理器，用于从存储器中调用并运行计算机程 序，使得安装有所述芯片系统的通信设备执行如权利要求11至18中任意一项所述的方法。
  21. 一种通信装置，其特征在于，包括至少一个处理器，所述至少一个处理器用于与存储器耦合，读取并执行所述存储器中的指令，以实现如权利要求11至18中任一项所述的方法。
PCT/CN2020/130790 2019-11-30 2020-11-23 一种呼叫处理系统、呼叫处理方法以及通信装置 WO2021104198A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP20893664.1A EP4054142A4 (en) 2019-11-30 2020-11-23 CALL HANDLING SYSTEM, CALL HANDLING METHOD AND COMMUNICATION DEVICE
US17/826,781 US20220295256A1 (en) 2019-11-30 2022-05-27 Call processing system, call processing method, and communications apparatus

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201911208927.3A CN112887496B (zh) 2019-11-30 2019-11-30 一种呼叫处理系统、呼叫处理方法以及通信装置
CN201911208927.3 2019-11-30

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/826,781 Continuation US20220295256A1 (en) 2019-11-30 2022-05-27 Call processing system, call processing method, and communications apparatus

Publications (1)

Publication Number Publication Date
WO2021104198A1 true WO2021104198A1 (zh) 2021-06-03

Family

ID=76039336

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/130790 WO2021104198A1 (zh) 2019-11-30 2020-11-23 一种呼叫处理系统、呼叫处理方法以及通信装置

Country Status (4)

Country Link
US (1) US20220295256A1 (zh)
EP (1) EP4054142A4 (zh)
CN (1) CN112887496B (zh)
WO (1) WO2021104198A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116708380A (zh) * 2022-02-28 2023-09-05 华为技术有限公司 一种执行呼叫相关业务的方法、装置及系统

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101960779A (zh) * 2007-10-01 2011-01-26 惠普开发有限公司 用于管理分布在不同网络上的虚拟协作系统的系统和方法
CN102025723A (zh) * 2009-09-18 2011-04-20 皇家Kpn公司 在服务供应网络中提供企业服务
CN102984405A (zh) * 2012-12-21 2013-03-20 华为技术有限公司 一种实现呼叫路由的方法及系统
US9054909B2 (en) * 2006-06-30 2015-06-09 Microsoft Technology Licensing, Llc Forwarding calls in real time communications
CN106961321A (zh) * 2016-01-12 2017-07-18 中国移动通信集团浙江有限公司 长期演进的语音信令采集和业务关联的方法及装置
CN109510906A (zh) * 2017-09-15 2019-03-22 中国移动通信集团公司 上网业务实现方法、装置、系统、实体、服务器及存储介质

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6779030B1 (en) * 1997-10-06 2004-08-17 Worldcom, Inc. Intelligent network
GB9925070D0 (en) * 1999-10-22 1999-12-22 Nokia Networks Oy Communication control in a telecommunications system
CN100531194C (zh) * 2004-09-07 2009-08-19 华为技术有限公司 分组域业务信号处理系统及其方法
CN101132405A (zh) * 2006-08-21 2008-02-27 华为技术有限公司 提供业务代理功能的通信网络系统和方法及业务代理装置
CN101330449B (zh) * 2007-07-02 2011-07-13 中兴通讯股份有限公司 一种ip多媒体子系统业务交互的实现方法

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9054909B2 (en) * 2006-06-30 2015-06-09 Microsoft Technology Licensing, Llc Forwarding calls in real time communications
CN101960779A (zh) * 2007-10-01 2011-01-26 惠普开发有限公司 用于管理分布在不同网络上的虚拟协作系统的系统和方法
CN102025723A (zh) * 2009-09-18 2011-04-20 皇家Kpn公司 在服务供应网络中提供企业服务
CN102984405A (zh) * 2012-12-21 2013-03-20 华为技术有限公司 一种实现呼叫路由的方法及系统
CN106961321A (zh) * 2016-01-12 2017-07-18 中国移动通信集团浙江有限公司 长期演进的语音信令采集和业务关联的方法及装置
CN109510906A (zh) * 2017-09-15 2019-03-22 中国移动通信集团公司 上网业务实现方法、装置、系统、实体、服务器及存储介质

Also Published As

Publication number Publication date
EP4054142A4 (en) 2023-01-04
CN112887496B (zh) 2022-08-09
EP4054142A1 (en) 2022-09-07
CN112887496A (zh) 2021-06-01
US20220295256A1 (en) 2022-09-15

Similar Documents

Publication Publication Date Title
Poikselkä et al. The IMS: IP multimedia concepts and services
US9467964B2 (en) System and method of providing a user with a registration review in IMS system
US8767717B2 (en) System and method of providing IMS services to users on terminating non IMS devices
US8305983B2 (en) Method and apparatus for enabling registration of endpoint devices through provisioning
US8948752B2 (en) System and method of providing IMS services to users on originating non IMS devices and other devices that do not have a previous relationship with the user
US9350769B2 (en) SIP device-level call/session/service management
US11063990B2 (en) Originating caller verification via insertion of an attestation parameter
US8423652B2 (en) Service templates for an IP multimedia subsystem
US20170163803A1 (en) Methods, systems, and computer readable media for nuisance call management
US10348781B2 (en) Method and apparatus for enabling registration of aggregate end point devices through provisioning
US20090122794A1 (en) Packet network and method implementing the same
KR20090074817A (ko) 최종－사용자들로의 인터넷 멀티미디어 서브시스템 서비스들의 제공을 위한 방법
WO2021104198A1 (zh) 一种呼叫处理系统、呼叫处理方法以及通信装置
WO2013159623A1 (zh) 通信监听的指示、实现方法及装置
WO2023011057A1 (zh) 一种通信方法及装置
US20150016448A1 (en) Session Establishment in an IP Multimedia Subsystem Network
WO2008036008A1 (en) Multiple response options for incoming communication attempts
US11166327B1 (en) Session initiated protocol (SIP) session establishment with a home subscriber server (HSS) outage
EP2876858B1 (en) Call transfer with network spanning back-to-back user agents
US10027798B2 (en) Connection of a user device to multiple accounts or phone numbers
WO2017113071A1 (zh) 一种补充业务实现方法、终端设备和ims服务器
CN106888444A (zh) 实现基于lte的语音漫游用户做被叫的方法和业务系统
US20130121212A1 (en) Method and apparatus for supporting location-aware services
WO2022068251A1 (zh) 呼叫方法、装置及系统
CN104159290A (zh) 注册多联系装置的方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20893664

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2020893664

Country of ref document: EP

Effective date: 20220603

NENP Non-entry into the national phase

Ref country code: DE