CN115499415A - 一种呼叫请求处理方法、网络节点及存储介质 - Google Patents
一种呼叫请求处理方法、网络节点及存储介质 Download PDFInfo
- Publication number
- CN115499415A CN115499415A CN202211442260.5A CN202211442260A CN115499415A CN 115499415 A CN115499415 A CN 115499415A CN 202211442260 A CN202211442260 A CN 202211442260A CN 115499415 A CN115499415 A CN 115499415A
- Authority
- CN
- China
- Prior art keywords
- network element
- cscf
- call request
- hss
- cscf network
- Prior art date
- Legal status (The legal status 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 status listed.)
- Granted
Links
- 238000003672 processing method Methods 0.000 title claims abstract description 24
- 238000000034 method Methods 0.000 claims abstract description 38
- 230000008569 process Effects 0.000 claims abstract description 19
- 230000001960 triggered effect Effects 0.000 claims abstract description 10
- 230000006870 function Effects 0.000 claims description 57
- 238000012545 processing Methods 0.000 claims description 24
- 238000004422 calculation algorithm Methods 0.000 claims description 12
- 238000004364 calculation method Methods 0.000 claims description 4
- 230000004044 response Effects 0.000 description 31
- 230000011664 signaling Effects 0.000 description 8
- 238000004590 computer program Methods 0.000 description 6
- 230000005856 abnormality Effects 0.000 description 4
- 238000010586 diagram Methods 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 238000012986 modification Methods 0.000 description 4
- 238000004891 communication Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000011022 operating instruction Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
Images
Classifications
-
- 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
- H04L65/1083—In-session procedures
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
本申请提供一种呼叫请求处理方法、网络节点及存储介质。方法包括：在接收到用户设备UE发起的呼叫请求后，确定是否触发核心‑呼叫会话控制功能S‑CSCF网元的辅助定位功能。若触发所述辅助定位功能，则将所述呼叫请求转发至应用服务器AS网元。接收所述AS网元基于所述呼叫请求反馈的所述UE对应的S‑CSCF网元的信息，其中，所述AS网元预先存储有所述UE与S‑CSCF网元之间的对应关系。基于所述AS网元提供的所述S‑CSCF网元的信息，将所述呼叫请求转发至所述UE对应的S‑CSCF网元，以由所述UE对应的S‑CSCF网元处理所述呼叫请求。本申请实施例的方案能够确保UE的呼叫请求能够在IMS网络中续接，从而提高呼叫请求完成的成功率，以满足用户基本的呼叫需求。
Description
技术领域
本申请涉及通信技术领域，尤其涉及一种呼叫请求处理方法、网络节点及存储介质。
背景技术
IP多媒体系统（IP Multimedia Subsystem，IMS）是一种全新的多媒体业务形式，它能够满足的终端客户更新颖、更多样化多媒体业务的需求。IMS被认为是下一代通信网络的核心技术，也是解决移动与固网融合，引入语音、数据、视频三重融合等差异化业务的重要方式。
目前IMS网络包含有大量的网元，用户设备的呼叫请求需要经过多个网元相互配合才能完成，其中任何一个网元或网络链路异常都会导致呼叫请求失败。为满足用户正常的呼叫需求，当前亟需一种能够避免因网元或网络链路异常而导致呼叫请求失败的技术方案。
发明内容
本申请目的是提供一种呼叫请求处理方法、网络节点及存储介质，能够降低因网元或网络链路异常而导致用户设备的呼叫请求失败的概率。
为了实现上述目的，本申请实施例是这样实现的：
第一方面，提供一种呼叫请求处理方法，应用于I-CSCF网元，包括：
在接收到用户设备UE发起的呼叫请求后，确定是否触发核心-呼叫会话控制功能S-CSCF网元的辅助定位功能；
若触发所述辅助定位功能，则将所述呼叫请求转发至应用服务器AS网元；
接收所述AS网元基于所述呼叫请求反馈的所述UE对应的S-CSCF网元的信息，其中，所述AS网元预先存储有所述UE与S-CSCF网元之间的对应关系；
基于所述AS网元提供的所述S-CSCF网元的信息，将所述呼叫请求转发至所述UE对应的S-CSCF网元，以由所述UE对应的S-CSCF网元处理所述呼叫请求。
第二方面，提供一种呼叫请求处理方法，应用于AS网元，包括：
接收I-CSCF网元转发的呼叫请求，所述呼叫请求是用户设备UE所发起的；
基于本地预先存储的所述UE与核心-呼叫会话控制功能S-CSCF网元之间的对应关系，确定所述UE对应的S-CSCF网元；
将所述UE对应的S-CSCF网元的信息发送至所述I-CSCF网元，使得所述I-CSCF网元基于所述S-CSCF网元的信息，将所述呼叫请求转发至所述UE对应的S-CSCF网元进行处理。
第三方面，提供一种网络节点，包括：处理器；以及被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时实现第一方面或第二方面所述的呼叫请求处理方法。
第四方面，提供一种计算机可读存储介质，所述计算机可读存储介质存储一个或多条程序，所述一个或多条程序当被包括多条应用程序的网络节点执行第一方面或第二方面所述的呼叫请求处理方法
本申请实施例的方案由AS网元预先存储UE与S-CSCF网元之间的对应关系，从而向I-CSCF网元提供针对S-CSCF网元的辅助定位功能。当I-CSCF网元接收到UE发起的呼叫请求后，如果无法向HSS网元查询UE对应的S-CSCF网元的信息，则触发S-CSCF网元的辅助定位功能，由AS网元基于本地UE与S-CSCF网元之间的对应关系，将UE对应的S-CSCF网元的信息提供给I-CSCF网元，从而使得I-CSCF网元能够将呼叫请求转发至UE对应的S-CSCF网元，以由UE对应的S-CSCF网元处理呼叫请求，也就是完成呼叫请求在被叫侧的接续。在实际应用中，I-CSCF网元可以基于与HSS之间实际的链路环境，来决策判断是否向HSS网元查询UE对应的S-CSCF网元信息。如果I-CSCF网元与HSS之间的链路环境并不理想，则I-CSCF网元及时放弃向HSS网元查询，转而触发S-CSCF网元的辅助定位功能，向AS网元查询UE对应的S-CSCF网元信息，从而确保UE发起的呼叫请求能够成功接续，进而提高了呼叫请求的成功率，以满足用户正常的呼叫需求。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请实施例中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1为传统的呼叫请求的流程示意图；
图2为本申请实施例的呼叫请求处理方法的流程示意图；
图3为本申请实施例的呼叫请求处理方法的另一流程示意图；
图4为本申请实施例的呼叫请求处理方法对应示例一中的流程示意图；
图5为本申请实施例的呼叫请求处理方法对应示例二中的流程示意图；
图6为本申请实施例的呼叫请求处理方法对应示例三中的流程示意图；
图7为本申请实施例的呼叫请求处理方法对应示例四中的流程示意图；
图8为本申请实施例的呼叫请求处理方法对应示例五中的流程示意图；
图9为本申请实施例的呼叫请求处理方法对应示例六中的流程示意图；
图10为本申请实施例的呼叫请求处理方法对应示例七中的流程示意图。
图11为本申请实施例的网络节点的结构示意图。
具体实施方式
为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本说明书一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本说明书保护的范围。
如前文所述，目前IMS网络包含有大量的网元，用户设备的呼叫请求需要经过多个网元相互配合才能完成，其中任何一个网元或网络链路异常都会导致呼叫请求失败。为满足用户正常的呼叫需求，当前亟需一种能够避免因网元或网络链路异常而导致呼叫请求失败的技术方案。
图1是传统的基于IMS网络的呼叫请求流程示意图。正常情况下，UE向P-CSCF网元发送呼叫请求，由P-CSCF网元将呼叫请求转发至主叫侧S-CSCF网元，由主叫侧S-CSCF网元触发AS网元执行主叫业务。之后，主叫侧S-CSCF网元将呼叫请求转发给I-CSCF网元。I-CSCF网元网元在接收到呼叫请求后，通过签约位置功能（Subscription Locator Functional，SLF）网元或者Diameter代理路由（Diameter Routing Agent，DRA）网元向HSS网元获取UE对应的被叫侧S-CSCF网元的地址。之后，I-CSCF网元基于获得地址，将呼叫请求转发至UE对应的被叫侧S-CSCF网元，由被叫侧S-CSCF网元触发AS网元执行被叫业务，被叫侧S-CSCF网元再经过P-CSCF网元将呼叫请求发送到被叫侧UE，完成呼叫请求的接续。
从上述图1所示的呼叫请求流程可以看出，I-CSCF网元需要通过SLF网元或DRA网元向HSS网元查询UE对应的S-CSCF网元。如果I/S-CSCF到SLF/HSS（或DRA/HSS）之间链路闪断、全断、SLF/HSS（或DRA/HSS）超负荷、拥塞或设备故障等情况下，则I-CSCF无法确定UE对应的S-CSCF，从而导致无法转发呼叫请求，进而导致被叫侧呼叫接续失败。而目前IMS现网的S-CSCF网元一般是POOL方式部署，会有数十套S-CSCF网元，如果I-CSCF网元遍历查找S-CSCF网元，查询消耗的性能和时间成本高，无法满足呼叫接续的性能要求。
针对上述问题，本申请旨在提出一种呼叫请求处理方法，由AS网元预先存储UE与S-CSCF网元之间的对应关系，从而向I-CSCF网元提供针对S-CSCF网元的辅助定位功能。当I-CSCF网元接收到UE发起的呼叫请求后，如果无法向HSS网元查询UE对应的S-CSCF网元的信息，则触发S-CSCF网元的辅助定位功能，由AS网元基于本地UE与S-CSCF网元之间的对应关系，将UE对应的S-CSCF网元的信息提供给I-CSCF网元，从而使得I-CSCF网元能够将呼叫请求转发至UE对应的S-CSCF网元，以由UE对应的S-CSCF网元处理呼叫请求，也就是完成呼叫请求在被叫侧的接续。在实际应用中，I-CSCF网元可以基于与HSS之间实际的链路环境，来决策判断是否向HSS网元查询UE对应的S-CSCF网元信息。如果I-CSCF网元与HSS之间的链路环境并不理想，则I-CSCF网元及时放弃向HSS网元查询，转而触发S-CSCF网元的辅助定位功能，向AS网元查询UE对应的S-CSCF网元信息，从而确保UE发起的呼叫请求能够成功接续，进而提高了呼叫请求的成功率，以满足用户正常的呼叫需求。
其中，图2是呼叫请求处理方法应用于在I-CSCF网元的流程示意图，具体包括以下步骤：
S202，在接收到用户设备UE发起的呼叫请求后，确定是否触发S-CSCF网元的辅助定位功能。
参考前文所述，本申请实施例中，I-CSCF网元在确定不向HSS网元获取UE对应的S-CSCF网元的信息时，确定触发S-CSCF网元的辅助定位功能。
其中，I-CSCF网元可以基于与HSS网元之间的链路环境，来判断是否向HSS网元获取UE对应的S-CSCF网元的信息。比如，在 I-CSCF网元与HSS网元之间的链路环境良好的情况下，通过HSS网元获取UE对应的S-CSCF网元的信息，在I-CSCF网元与HSS网元之间的链路环境较差的情况下，则触发S-CSCF网元的辅助定位功能，通过AS网元来定位UE对应的S-CSCF网元。
参考图1所示，在IMS网络中，I-CSCF网元通过SLF网元或DRA网元向HSS网元查询UE对应的S-CSCF网元的信息。
具体地，如果I-CSCF网元是通过SLF网元连接HSS网元，则可以基于本地针对SLF网元的负载均衡策略，以及与HSS网元之间的链路环境，来判断是否通过SLF网元向HSS网元获取UE对应的S-CSCF网元的信息。
其中：
SLF网元的负载均衡策略可以包括：单用户策略、用户群策略、局向策略、整设备策略等，也可以是这些策略的组合。作为示例性介绍，单用户策略可以指：48小时（可配置）内只查询一次SLF、随机查询SLF、按照配置比例（比如20%）查询SLF网元等；用户群策略、局向策略可以指：在配置时间内查询配置次数的SLF（比如1小时查询1000次），随机查询SLF、按照配置比例（比如20%）查询SLF等；整设备策略可以指：超过配置消息量（或流量）后开始按比例查询SLF网元（比如每分钟收到5万条消息，80%查询SLF；每分钟收到10万条消息，60%查询SLF网元；每分钟收到20万条消息，不查询SLF网元等）、超过配置CPU后开始按比例查询SLF（比如CPU超过60%，80%查询SLF；CPU超过70%，60%查询SLF网元；CPU超过95%，不查询SLF网元等）。
I-CSCF网元与HSS网元之间的链路环境可以通过I-CSCF网元-SLF网元的消息应答情况、SLF网元-HSS网元的消息应答情况来判断，比如应答超时则表示I-CSCF网元与HSS网元之间的链路环境较差。
也就是说，基于上述判断策略，I-CSCF网元可以灵活根据SLF网元实际的负载，以及与HSS网元之间实际的链路环境，来决定是否放弃向HSS网元查询UE对应的S-CSCF网元的信息。
同理，如果I-CSCF网元是通过DRA网元连接HSS网元，则可以基于本地针对DRA网元的负载均衡策略，以及与HSS网元之间的链路环境，来判断是否通过DRA网元向HSS网元获取UE对应的S-CSCF网元的信息。这里不再举例赘述。
S204，若触发辅助定位功能，则将呼叫请求转发至应用服务器AS网元。
本申请实施例中，AS网元可以在接收UE在注册IMS域后所发起的第三方注册请求后，向HSS网元获取UE对应的S-CSCF网元的信息，并基于UE对应的S-CSCF网元的信息，存储UE与S-CSCF网元之间的对应关系。
也就是说，I-CSCF网元需要向之前处理过UE第三方注册请求的AS网元来转发呼叫请求，这样AS网元才能提供UE对应的S-CSCF网元的信息。
这里，本申请实施例通过一致性算法，来保证处理UE第三方注册请求的AS网元，与之后接收呼叫请求的AS网元保持强一致性。
即，UE将第三方注册请求发送到S-CSCF网元后，由S-CSCF网元基于一致性算法，对第三方注册携带的UE标识进行一致性计算，以确定出与UE标识匹配的AS网元；之后，S-CSCF网元将第三方注册请求转给与UE标识匹配的AS网元负责处理，使得与UE标识匹配的AS网元在第三方注册请求后，向HSS网元获取UE对应的S-CSCF网元的信息，以存储UE与S-CSCF网元之间的对应关系。
对应地，本步骤中，当I-CSCF网元将呼叫请求转发至AS网元时，也基于相同的一致性算法，对呼叫请求携带的UE标识进行一致性计算，以确定出与UE标识匹配的AS网元；之后，I-CSCF网元将呼叫请求转发与UE标识匹配的AS网元。
S206，接收AS网元基于呼叫请求反馈的UE对应的S-CSCF网元的信息，其中， AS网元预先存储有UE与S-CSCF网元之间的对应关系。
具体地，本步骤中，AS网元可以基于呼叫请求中的UE标识进行S-CSCF网元的匹配查询。如果查询命中，则将命中的S-CSCF网元的信息反馈给I-CSCF网元。
S208，基于AS网元提供的S-CSCF网元信息，将呼叫请求转发至UE对应的S-CSCF网元，以由UE对应的S-CSCF网元处理呼叫请求。
需要说明的是，本步骤所述的S-CSCF网元是指图1中被叫侧S-CSCF网元。
S-CSCF网元的信息可以是S-CSCF网元的地址，也可以是能够确定S-CSCF网元的地址的其他信息，这里本文不作具体限定。
参考图1所示流程，被叫侧S-CSCF网元在接收到理呼叫请求后，即可触发AS网元执行被叫业务，并再经过P-CSCF网元将呼叫请求发送到被叫侧UE，以完成呼叫请求的接续。
对应地，图3是本申请实施例的呼叫请求处理方法应用于在AS网元的流程示意图，具体包括以下步骤：
S302，接收I-CSCF网元转发的呼叫请求，呼叫请求是用户设备UE所发起的。
如前文所述，I-CSCF网元在接收到UE发起的呼叫请求后，先基于与HSS网元之间的链路环境，判断是否向HSS网元获取所述UE对应的S-CSCF网元的信息；如果判断不向HSS网元获取所述UE对应的S-CSCF网元的信息，则确定触发辅助定位功能，以将呼叫请求转发至AS网元。
S304，基于本地预先存储的UE与S-CSCF网元之间的对应关系，确定UE对应的S-CSCF网元。
本申请实施例中，UE可以主动申请辅助定位功能的业务。AS网元在收到UE成功申请辅助定位功能后，可以本地存储UE针对辅助定位功能的签约信息。当AS网元收到UE发起呼叫请求后，先根据本地存储的辅助定位功能的签约信息，来判断UE对应的用户是否为辅助定位功能的签约用户；如果确定是签约用户，则在基于本地存储的UE与S-CSCF网元之间的对应关系，查找到UE对应的S-CSCF网元。
S306，将UE对应的S-CSCF网元的信息发送至I-CSCF网元，使得I-CSCF网元基于S-CSCF网元信息，将呼叫请求转发至UE对应的S-CSCF网元进行处理。
同理，本步骤所述的S-CSCF网元是指被叫侧S-CSCF网元。参考图1所示流程，被叫侧S-CSCF网元在接收到呼叫请求后，即可触发AS网元执行被叫业务，并再经过P-CSCF网元将呼叫请求发送到被叫侧UE，以完成呼叫请求的接续。
下面结合不同的示例，对本申请实施例的呼叫请求处理方法进行详细介绍。
示例一
示例一中，由业务运营支撑系统（Business and Operation Support System，BOSS）负责为UE提供S-CSCF网元的辅助定位功能的签约。BOSS的业务发放是指操作员配置用户业务数据的过程，用来实现各项业务的签约，修改和撤销。
其中，图4所示是辅助定位功能的签约流程，包括：
步骤1：BOSS基于用户授权，发起签约请求，指示开通S-CSCF网元的辅助定位功能（LOCSCSCF）。
步骤2：AS网元根据开户请求的号码，向HSS网元查询当前的用户业务数据；
步骤3：HSS网元返回该用户的业务数据查询结果。
步骤4：AS网元根据查询结果和请求消息，向HSS网元发起针对用户的业务数据更新，其中，需要更新的业务数据包括用户针对辅助定位功能的签约数据。
步骤5：HSS网元向AS网元反馈业务更新响应。
步骤6：AS根据更新结果，向BOSS反馈辅助定位功能的签约开通响应。
说明说明的是：
步骤1举例的是用户开户请求，对于已开户用户，可以发起修改业务请求，在用户现有业务发放基础上，增加S-CSCF查找业务。
步骤4举例的是VoLTE业务发放，配合的网元是HSS网元，如果是VoNR，则配合网元是UDM网元。
示例二
示例二中，UE进行第三方注册时，AS网元支持S-CSCF查找业务流程。UE成功注册到IMS域后，S-CSCF网元会触发第三方注册。AS网元收到第三方注册请求，从HSS网元查询签约的辅助定位功能业务，如果有S-CSCF查找业务，则存储S-CSCF地址信息。对应流程如图5所示，包括：
步骤1：UE发起第三方注册请求，经过中间网元处理后送到S-CSCF网元。
步骤2：S-CSCF网元成功完成注册流程给UE反馈200OK成功响应。
步骤3：S-CSCF网元采用一致性算法，按照UE的号码hash确定一个AS网元，并将第三方注册请求转发至该AS网元。
步骤4：AS网元收到第三方注册请求后，向HSS网元查询UE对应的用户数据。
步骤5：AS网元收到HSS反馈的用户数据，发现UE对应的用户签约了辅助定位功能，在本地存储用户数据中的UE和S-CSCF的对应关系。
步骤6：AS网元向S-CSCF网元反馈第三方注册成功的200OK响应。
需要说明的是：
现网AS网元是pool部署，多则数十套。S-CSCF网元必须采用一致性算法，选择一个第三方注册的AS网元。UE后续发起呼叫请求时，I-CSCF网元可以采用相同致性算法，将呼叫请求触发给相同的AS网元。
示例三
示例三中，I-CSCF网元通过SLF网元向HSS网元查询UE对应的S-CSCF网元。当I-CSCF网元到SLF网元之间链路闪断、全断、SLF超负荷、拥塞或设备故障等情况下，通过I-CSCF网元、AS网元相互配合，呼叫请求能够正确转发给S-CSCF网元的容错处理。对应流程如图6所示，流程包括：
步骤1：UE的呼叫请求经过其他网元发送至I-CSCF网元。
步骤2：I-CSCF网元判断SLF在线，则向SLF发送查询用户对应HSS网元的请求，并设置等待响应的定时器。
步骤3：I-CSCF网元没有从SLF网元收到响应（即定时器超时）或者收到错误响应。
步骤4：I-CSCF网元根据策略把呼叫请求转发到第三方注册的AS网元。呼叫请求信令有被叫用户的号码，I-CSCF可以采用采用一致性算法，如按UE号码hash，选择一个AS网元，将呼叫请求发送给AS网元，并通过信令指示AS网元执行S-CSCF查找的辅助定位功能（LOCSCSCF）
步骤5：AS网元收到呼叫请求，判断出是S-CSCF网元查找请求，且该用户签约了S-CSCF查找的辅助定位功能，根据本地存储的用户和S-CSCF网元对应关系，通过302重定向响应的contact地址将对应的S-CSCF网元地址返回给I-CSCF网元。
步骤6：I-CSCF网元收到302重定向响应，根据contact获取到用户注册所在的S-CSCF网元，将呼叫请求发送给该S-CSCF网元。
步骤7：S-CSCF网元继续呼叫处理。
需要说明的是：
步骤2、3是可选的，下述两种情况可以跳过这两步，直接进入步骤4：
1）I-CSCF网元判断出SLF网元故障；
2）I-CSCF网元判断出SLF网元人工by pass等。
示例四
示例四中，I-CSCF网元通过SLF网元向HSS网元查询UE对应的S-CSCF网元。当I-CSCF网元到HSS网元之间链路闪断、全断、HSS网元超负荷、拥塞或设备故障等情况下，通过I-CSCF网元、AS网元相互配合，呼叫请求能够正确转发给S-CSCF网元的容错处理。对应流程如图7所示，包括：
步骤1：UE的呼叫请求经过其他网元发送给I-CSCF网元。
步骤2：I-CSCF网元判断SLF在线，则向SLF发送查询用户对应HSS的请求，并设置等待响应的定时器。
步骤3：I-CSCF网元收到SLF发送查询用户对应HSS的响应，杀掉步骤3设置的定时器。
步骤4：I-CSCF网元向HSS发送查询用户注册所在S-CSCF的请求，并设置等待响应的定时器。
步骤5：I-CSCF网元没有从HSS网元收到响应（即定时器超时）或者收到错误响应。
步骤6：I-CSCF网元根据策略把呼叫请求转发到第三方注册的AS网元。呼叫请求信令有被叫用户的号码，I-CSCF可以采用采用一致性算法，如按UE号码hash，选择一个AS网元，将呼叫请求发送给AS网元，并通过信令指示AS网元执行S-CSCF查找的辅助定位功能（LOCSCSCF）。
步骤7：AS网元收到呼叫请求，判断出是S-CSCF网元查找请求，且该用户签约了S-CSCF查找的辅助定位功能，根据本地存储的用户和S-CSCF网元对应关系，通过302重定向响应的contact地址将对应的S-CSCF网元地址返回给I-CSCF网元。
步骤8：I-CSCF网元收到302重定向响应，根据contact获取到用户注册所在的S-CSCF网元，将呼叫请求发送给该S-CSCF网元。
步骤9：S-CSCF网元继续呼叫处理。
需要说明的是：
步骤5、6是可选的，下述两种情况可以跳过这两步，直接进入步骤7：
1）I-CSCF判断出HSS网元故障；
2）I-CSCF网元判断出HSS人工bypass等。
示例五
示例五是示例四的另外一种实施方式。其中，图8是实例五的流程示意图，示例五与示例四的区别在于：
示例四在步骤7中，AS收到呼叫请求，判断出是S-CSCF查找请求，通过302重定向响应的contact地址将S-CSCF地址返回给I-CSCF，由I-CSCF根据Contact转发呼叫到S-CSCF。
示例五在步骤7中，AS收到呼叫请求判断出是S-CSCF查找请求，且该用户签约了S-CSCF网元查找业务的辅助定位功能，根据本地存储的用户和S-CSCF网元对应关系，直接将呼叫请求发送给S-CSCF网元。
需要说明的是：
示例四和实施例示例五都能完成呼叫请求的接续，区别是示例四不需要I-CSCF支持302，而是由AS网元直接转发呼叫请求到S-CSCF网元。
AS网元转呼叫请求时不添加Record-Route，这样仅INVITE的呼叫请求事务（INVITE及后续的183、180、200 OK响应）经过AS转发，后续事务（PRACK、UPDATE等）可以跳过AS网元，因此降低了对AS网元的性能要求。而示例四中，AS网元给I-CSCF回302后，呼叫请求处理就结束了，因此具有更高的处理性能。
示例六
示例六中，I-CSCF网元通过DRA网元向HSS网元查询UE对应的S-CSCF网元。这里将DRA网元和HSS网元合并为一个DRA /HSS网元进行介绍，在I-CSCF到DRA/HSS之间链路闪断、全断、DRA超负荷、拥塞或设备故障等情况下，通过I-CSCF网元、AS网元相互配合，呼叫请求能够正确转发给S-CSCF网元的容错处理。对应流程如图9所示，包括：
步骤1：UE的呼叫请求经过其他网元发送给I-CSCF网元。
步骤2：I-CSCF网元判断DRA/HSS网元在线，则向DRA网元发送查询用户注册所在S-CSCF的请求，并设置等待响应的定时器。
步骤3：I-CSCF网元没有从DRA/HSS网元收到响应（即定时器超时）或者收到错误响应。
步骤4：I-CSCF网元根据策略把呼叫请求转发到第三方注册的AS网元。呼叫请求信令有被叫用户的号码，I-CSCF可以采用采用一致性算法，如按UE号码hash，选择一个AS网元，将呼叫请求发送给AS网元，并通过信令指示AS网元执行S-CSCF查找的辅助定位功能（LOCSCSCF）
步骤5：AS网元收到呼叫请求，判断出是S-CSCF网元查找请求，且该用户签约了S-CSCF查找的辅助定位功能，根据本地存储的用户和S-CSCF网元对应关系，通过302重定向响应的contact地址将对应的S-CSCF网元地址返回给I-CSCF网元。
步骤6：I-CSCF网元收到302重定向响应，根据contact获取到用户注册所在的S-CSCF网元，将呼叫请求发送给该S-CSCF网元。
步骤7：S-CSCF网元继续呼叫处理。
说明：
1、步骤2、3是可选的，下述两种情况可以跳过这两步，直接进入步骤4：
1）I-CSCF网元判断出DRA/HSS网元故障；
2）I-CSCF网元判断出DRA/HSS网元人工bypass等。
示例七
示例七中，UE发起的呼叫请求替换为即时消息请求。总，I-CSCF网元通过DRA网元向HSS网元查询UE对应的S-CSCF网元。这里将DRA网元和HSS网元合并为一个DRA /HSS网元进行介绍，在I-CSCF到DRA/HSS之间链路闪断、全断、DRA超负荷、拥塞或设备故障等情况下，通过I-CSCF网元、AS网元相互配合，即时消息请求能够正确转发给S-CSCF网元的容错处理。对应流程如图10所示，包括：
步骤1：UE的即时消息请求经过其他网元发送给I-CSCF网元。
步骤2：I-CSCF网元判断DRA/HSS网元在线，则向DRA网元发送查询用户注册所在S-CSCF的请求，并设置等待响应的定时器。
步骤3：I-CSCF网元没有从DRA/HSS网元收到响应（即定时器超时）或者收到错误响应。
步骤4：I-CSCF网元根据策略把呼叫请求转发到第三方注册的AS网元。即使消息请求信令有被叫用户的号码，I-CSCF可以采用采用一致性算法，如按UE号码hash，选择一个AS网元，将呼叫请求发送给AS网元，并通过信令指示AS网元执行S-CSCF查找的辅助定位功能（LOCSCSCF）。
步骤5：AS网元收到即时消息后，判断出是S-CSCF网元查找请求，且该用户签约了S-CSCF查找的辅助定位功能，根据本地存储的用户和S-CSCF网元对应关系，通过302重定向响应的contact地址将对应的S-CSCF网元地址返回给I-CSCF网元。
步骤6：I-CSCF网元收到302重定向响应，根据contact获取到用户注册所在的S-CSCF网元，将即时消息请求发送给该S-CSCF网元。
步骤7：S-CSCF网元继续即时消息请求。
图11是本说明书的一个实施例网络节点的结构示意图。请参考图11，在硬件层面，该网络节点包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(Random-Access Memory，RAM)，也可能还包括非易失性存储器（non-volatile memory），例如至少1个磁盘存储器等。当然，该网络节点还可能包括其他业务所需要的硬件。
处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是ISA(Industry Standard Architecture，工业标准体系结构）总线、PCI(PeripheralComponent Interconnect，外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture，扩展工业标准结构）总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图11中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。
存储器，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器，并向处理器提供指令和数据。
可选地，处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成上述图2所示的I-CSCF网元。对应地，处理器，执行存储器所存放的程序，并具体用于执行以下操作：
在接收到用户设备UE发起的呼叫请求后，确定是否触发核心-呼叫会话控制功能S-CSCF网元的辅助定位功能；
若触发所述辅助定位功能，则将所述呼叫请求转发至应用服务器AS网元。
接收所述AS网元基于所述呼叫请求反馈的所述UE对应的S-CSCF网元的信息，其中，所述AS网元预先存储有所述UE与S-CSCF网元之间的对应关系。
基于所述AS网元提供的所述S-CSCF网元的信息，将所述呼叫请求转发至所述UE对应的S-CSCF网元，以由所述UE对应的S-CSCF网元处理所述呼叫请求。
或者，处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成上述图2所示的AS网元。对应地，处理器，执行存储器所存放的程序，并具体用于执行以下操作：
接收I-CSCF网元转发的呼叫请求，所述呼叫请求是用户设备UE所发起的。
基于本地预先存储的所述UE与核心-呼叫会话控制功能S-CSCF网元之间的对应关系，确定所述UE对应的S-CSCF网元。
将所述UE对应的S-CSCF网元的信息发送至所述I-CSCF网元，使得所述I-CSCF网元基于所述S-CSCF网元的信息，将所述呼叫请求转发至所述UE对应的S-CSCF网元进行处理。
基于本申请实施例的电子节点， AS网元预先存储UE与S-CSCF网元之间的对应关系，从而向I-CSCF网元提供针对S-CSCF网元的辅助定位功能。当I-CSCF网元接收到UE发起的呼叫请求后，如果无法向HSS网元查询UE对应的S-CSCF网元的信息，则触发S-CSCF网元的辅助定位功能，由AS网元基于本地UE与S-CSCF网元之间的对应关系，将UE对应的S-CSCF网元的信息提供给I-CSCF网元，从而使得I-CSCF网元能够将呼叫请求转发至UE对应的S-CSCF网元，以由UE对应的S-CSCF网元处理呼叫请求，也就是完成呼叫请求在被叫侧的接续。在实际应用中，I-CSCF网元可以基于与HSS之间实际的链路环境，来决策判断是否向HSS网元查询UE对应的S-CSCF网元信息。如果I-CSCF网元与HSS之间的链路环境并不理想，则I-CSCF网元及时放弃向HSS网元查询，转而触发S-CSCF网元的辅助定位功能，向AS网元查询UE对应的S-CSCF网元信息，从而确保UE发起的呼叫请求能够成功接续，进而提高了呼叫请求的成功率，以满足用户正常的呼叫需求。
上述如本说明书所示实施例揭示的呼叫请求处理方法可以应用于处理器中，由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器（Central Processing Unit，CPU）、网络处理器（Network Processor，NP）等；还可以是数字信号处理器（Digital Signal Processor，DSP）、专用集成电路（Application Specific Integrated Circuit，ASIC）、现场可编程门阵列（Field－Programmable Gate Array，FPGA）或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。
当然，除了软件示例之外，本说明书的网络节点并不排除其他示例，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。
此外，本申请实施例还提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序包括指令。
可选地，上述指令当被包括多个应用程序的便携式网络节点执行时，能够使该便携式网络节点执行图2所示方法中对应I-CSCF网元的步骤，包括：
在接收到用户设备UE发起的呼叫请求后，确定是否触发核心-呼叫会话控制功能S-CSCF网元的辅助定位功能。
若触发所述辅助定位功能，则将所述呼叫请求转发至应用服务器AS网元。
接收所述AS网元基于所述呼叫请求反馈的所述UE对应的S-CSCF网元的信息，其中，所述AS网元预先存储有所述UE与S-CSCF网元之间的对应关系。
基于所述AS网元提供的所述S-CSCF网元的信息，将所述呼叫请求转发至所述UE对应的S-CSCF网元，以由所述UE对应的S-CSCF网元处理所述呼叫请求。
或者，上述指令当被包括多个应用程序的便携式网络节点执行时，能够使该便携式网络节点执行图1所示方法中对应AS网元的步骤，包括：
接收I-CSCF网元转发的呼叫请求，所述呼叫请求是用户设备UE所发起的。
基于本地预先存储的所述UE与核心-呼叫会话控制功能S-CSCF网元之间的对应关系，确定所述UE对应的S-CSCF网元。
将所述UE对应的S-CSCF网元的信息发送至所述I-CSCF网元，使得所述I-CSCF网元基于所述S-CSCF网元的信息，将所述呼叫请求转发至所述UE对应的S-CSCF网元进行处理。
本领域技术人员应明白，本说明书的实施例可提供为方法、系统或计算机程序产品。因此，本说明书可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本说明书可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
以上仅为本说明书的实施例而已，并不用于限制本说明书。对于本领域技术人员来说，本说明书可以有各种更改和变化。凡在本说明书的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本说明书的权利要求范围之内。此外，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本文件的保护范围。
Claims (10)
1.一种呼叫请求处理方法，应用于查询-呼叫会话控制功能I-CSCF网元，其特征在于，包括：
在接收到用户设备UE发起的呼叫请求后，确定是否触发核心-呼叫会话控制功能S-CSCF网元的辅助定位功能；
若触发所述辅助定位功能，则将所述呼叫请求转发至应用服务器AS网元；
接收所述AS网元基于所述呼叫请求反馈的所述UE对应的S-CSCF网元的信息，其中，所述AS网元预先存储有所述UE与S-CSCF网元之间的对应关系；
基于所述AS网元提供的所述S-CSCF网元的信息，将所述呼叫请求转发至所述UE对应的S-CSCF网元，以由所述UE对应的S-CSCF网元处理所述呼叫请求。
2.根据权利要求1所述的方法，其特征在于，
确定是否触发核心-呼叫会话控制功能S-CSCF网元的辅助定位功能，包括：
基于与归属用户服务器HSS网元之间的链路环境，判断是否向所述HSS网元获取所述UE对应的S-CSCF网元的信息；若判断不向所述HSS网元获取所述UE对应的S-CSCF网元的信息，则确定触发辅助定位功能。
3.根据权利要求2所述的方法，其特征在于，
所述I-CSCF网元通过订阅定位器功能SLF网元或Diameter代理路由DRA网元向所述HSS网元获取所述UE对应的S-CSCF网元的信息；
基于与归属用户服务器HSS网元之间的链路环境，判断是否向所述HSS网元获取所述UE对应的S-CSCF网元的信息，包括：
基于本地针对所述 SLF网元的负载均衡策略，以及与HSS网元之间的链路环境，判断是否通过所述SLF网元向所述HSS网元获取所述UE对应的S-CSCF网元的信息；
或者，
基于本地针对所述DRA网元的负载均衡策略，以及与HSS网元之间的链路环境，判断是否通过所述SLF网元向所述HSS网元获取所述UE对应的S-CSCF网元的信息。
4.根据权利要求2所述的方法，其特征在于，
所述AS网元预先存储的所述UE与S-CSCF网元之间的对应关系是所述AS网元在接收到第三方注册请求时，向所述HSS网元获取得到的, 所述第三方注册请求是所述UE在注册IMS域后所发起的。
5.根据权利要求4所述的方法，其特征在于，
将所述呼叫请求转发至应用服务器AS网元，包括：
基于一致性算法，对所述呼叫请求携带的UE标识进行一致性计算，确定与UE标识匹配的AS网元；
将所述呼叫请求转发至确定得到的AS网元。
6.一种呼叫请求处理方法，应用于AS网元，其特征在于，包括：
接收I-CSCF网元转发的呼叫请求，所述呼叫请求是用户设备UE所发起的；
基于本地预先存储的所述UE与核心-呼叫会话控制功能S-CSCF网元之间的对应关系，确定所述UE对应的S-CSCF网元；
将所述UE对应的S-CSCF网元的信息发送至所述I-CSCF网元，使得所述I-CSCF网元基于所述S-CSCF网元的信息，将所述呼叫请求转发至所述UE对应的S-CSCF网元进行处理。
7.根据权利要求6所述的方法，其特征在于，
在接收I-CSCF网元转发的呼叫请求前，所述方法还包括：
接收所述UE在注册IMS域后所发起的第三方注册请求；
向HSS网元获取所述UE对应的S-CSCF网元的信息；
基于所述UE对应的S-CSCF网元的信息，存储所述UE与S-CSCF网元之间的对应关系。
8.根据权利要求7所述的方法，其特征在于，
所述第三方注册请求是所述UE通过S-CSCF网元发送至所述AS网元的，所述S-CSCF网元基于一致性算法，对所述第三方注册携带的UE标识进行一致性计算，以确定接收所述第三方注册请求的所述AS网元。
9.一种网络节点，包括：处理器；以及被安排成存储计算机可执行指令的存储器，其特征在于，所述可执行指令在被执行时实现如权利要求1-8任一项所述的呼叫请求处理方法。
10.一种计算机可读存储介质，所述计算机可读存储介质存储一个或多条程序，其特征在于，所述一个或多条程序当被包括多条应用程序的网络节点执行如权利要求1-8任一项所述的呼叫请求处理方法。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211442260.5A CN115499415B (zh) | 2022-11-17 | 2022-11-17 | 一种呼叫请求处理方法、网络节点及存储介质 |
| PCT/CN2023/124439 WO2024104024A1 (zh) | 2022-11-17 | 2023-10-13 | 一种呼叫请求处理方法、网络节点及存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211442260.5A CN115499415B (zh) | 2022-11-17 | 2022-11-17 | 一种呼叫请求处理方法、网络节点及存储介质 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN115499415A true CN115499415A (zh) | 2022-12-20 |
| CN115499415B CN115499415B (zh) | 2023-03-28 |
Family
ID=85116085
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211442260.5A Active CN115499415B (zh) | 2022-11-17 | 2022-11-17 | 一种呼叫请求处理方法、网络节点及存储介质 |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN115499415B (zh) |
| WO (1) | WO2024104024A1 (zh) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2024104024A1 (zh) * | 2022-11-17 | 2024-05-23 | 中兴通讯股份有限公司 | 一种呼叫请求处理方法、网络节点及存储介质 |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101917696A (zh) * | 2010-07-30 | 2010-12-15 | 中国电信股份有限公司 | 归属用户服务器旁路方法及查询呼叫会话控制功能设备 |
| CN106454785A (zh) * | 2016-12-14 | 2017-02-22 | 中国联合网络通信集团有限公司 | 一种呼叫转移的方法及系统 |
| CN109417569A (zh) * | 2016-06-30 | 2019-03-01 | T移动美国公司 | 对服务呼叫会话控制和应用服务器功能的恢复 |
| CN111052775A (zh) * | 2017-08-31 | 2020-04-21 | T移动美国公司 | 基于sip选项的位置确定 |
| CN114501683A (zh) * | 2020-10-23 | 2022-05-13 | 华为技术有限公司 | 呼叫处理方法、装置及存储介质 |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20090103518A1 (en) * | 2007-10-18 | 2009-04-23 | Motorola, Inc. | Call origination by an application server in an internet protogol multimedia core network subsystem |
| CN105450621A (zh) * | 2014-09-30 | 2016-03-30 | 中兴通讯股份有限公司 | 终呼处理方法、装置及系统 |
| CN115499415B (zh) * | 2022-11-17 | 2023-03-28 | 中兴通讯股份有限公司 | 一种呼叫请求处理方法、网络节点及存储介质 |
-
2022
- 2022-11-17 CN CN202211442260.5A patent/CN115499415B/zh active Active
-
2023
- 2023-10-13 WO PCT/CN2023/124439 patent/WO2024104024A1/zh unknown
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101917696A (zh) * | 2010-07-30 | 2010-12-15 | 中国电信股份有限公司 | 归属用户服务器旁路方法及查询呼叫会话控制功能设备 |
| CN109417569A (zh) * | 2016-06-30 | 2019-03-01 | T移动美国公司 | 对服务呼叫会话控制和应用服务器功能的恢复 |
| CN106454785A (zh) * | 2016-12-14 | 2017-02-22 | 中国联合网络通信集团有限公司 | 一种呼叫转移的方法及系统 |
| CN111052775A (zh) * | 2017-08-31 | 2020-04-21 | T移动美国公司 | 基于sip选项的位置确定 |
| CN114501683A (zh) * | 2020-10-23 | 2022-05-13 | 华为技术有限公司 | 呼叫处理方法、装置及存储介质 |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2024104024A1 (zh) * | 2022-11-17 | 2024-05-23 | 中兴通讯股份有限公司 | 一种呼叫请求处理方法、网络节点及存储介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN115499415B (zh) | 2023-03-28 |
| WO2024104024A1 (zh) | 2024-05-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8560890B2 (en) | IMS recovery after HSS failure | |
| CN102035798B (zh) | 一种实现容灾的业务处理方法、系统及装置 | |
| EP1879337B1 (en) | A method for processing the register message in the ims network according to the initial filtering rules | |
| US20060136569A1 (en) | Transmission of service data | |
| US20100293261A1 (en) | Methods, apparatuses and computer program for ims recovery upon restart of a s-cscf | |
| EP1606921B1 (en) | Request redirection handling in imc | |
| US20100074100A1 (en) | Proxy server, communication system, communication method and program | |
| US20150282242A1 (en) | Methods and apparatus for processing an ims session | |
| WO2024104024A1 (zh) | 一种呼叫请求处理方法、网络节点及存储介质 | |
| US9288332B2 (en) | System and method for providing high reliability network | |
| WO2006072215A1 (fr) | Procede de realisation d'une connexion d'appel dans un systeme de reseau intelligent | |
| CN101459533A (zh) | 一种下一代网络中改进的应用服务器容灾的系统及方法 | |
| CN103841528A (zh) | Ims系统来电提醒业务实现方法和系统 | |
| US20100017527A1 (en) | Sip server and communication system | |
| US11522923B2 (en) | Method for enabling a calling User Equipment, UE, to retry a Session Initiation Protocol, SIP, call attempt to a called UE, over a Circuit Switched domain | |
| US10686849B2 (en) | Data processing | |
| CN109151221B (zh) | 呼叫提醒方法、提醒服务器和计算机可读存储介质 | |
| CN113595765A (zh) | 一种VoIP终端注册业务的故障转移方法及装置 | |
| CN104125591B (zh) | 一种基于ims的呼叫控制方法、装置及系统 | |
| CN102487495A (zh) | Hss异常时实现呼叫的方法及cscf | |
| CN107317786B (zh) | 一种转发会话初始协议消息的方法、装置及网元 | |
| CN102377658A (zh) | 一种实现高优先级业务的方法和系统 | |
| US20120250497A1 (en) | Methods for sending and processing an sip response | |
| CN115915036A (zh) | 基于被叫域选结果的呼叫处理方法、装置及计算设备 | |
| CN117459504A (zh) | Ims被叫接续方法、系统、设备及存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |