CN115914176A - 一种呼叫处理方法、装置及系统 - Google Patents

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

Info

Publication number
CN115914176A
CN115914176A CN202110929156.8A CN202110929156A CN115914176A CN 115914176 A CN115914176 A CN 115914176A CN 202110929156 A CN202110929156 A CN 202110929156A CN 115914176 A CN115914176 A CN 115914176A
Authority
CN
China
Prior art keywords
media
party call
network element
terminal devices
call
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.)
Pending
Application number
CN202110929156.8A
Other languages
English (en)
Inventor
林宏达
黄锴
李拓
欧文军
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN202110929156.8A priority Critical patent/CN115914176A/zh
Priority to PCT/CN2022/105366 priority patent/WO2023016172A1/zh
Priority to EP22855155.2A priority patent/EP4351102A1/en
Publication of CN115914176A publication Critical patent/CN115914176A/zh
Pending legal-status Critical Current

Links

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
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
    • H04L12/1818—Conference organisation arrangements, e.g. handling schedules, setting up parameters needed by nodes to attend a conference, booking network resources, notifying involved parties
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
    • H04L12/1822—Conducting the conference, e.g. admission, detection, selection or grouping of participants, correlating users to one or more conference sessions, prioritising transmission
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/56—Unified messaging, e.g. interactions between e-mail, instant messaging or converged IP messaging [CPM]
    • 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/102—Gateways
    • H04L65/1023—Media gateways
    • H04L65/1026—Media gateways at the edge
    • 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/102—Gateways
    • H04L65/1023—Media gateways
    • H04L65/103—Media gateways in the network
    • 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
    • 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/1063—Application servers providing network services
    • 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/1069—Session establishment or de-establishment
    • 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/40—Support for services or applications
    • H04L65/403—Arrangements for multi-party communication, e.g. for conferences
    • 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/40—Support for services or applications
    • H04L65/403—Arrangements for multi-party communication, e.g. for conferences
    • H04L65/4038—Arrangements for multi-party communication, e.g. for conferences with floor control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/56—Arrangements for connecting several subscribers to a common circuit, i.e. affording conference facilities
    • H04M3/567—Multimedia conference systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/14—Systems for two-way working
    • H04N7/15—Conference systems
    • H04N7/152—Multipoint control units therefor

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Telephonic Communication Services (AREA)

Abstract

本申请实施例提供一种呼叫处理方法、装置及系统，该方法通过IMS网络中新引入的统一媒体功能网元代替原有的多方会议媒体功能网元，在接入侧提供多方通话媒体业务，减少媒体迂回，降低时延，支持扩展现实XR等时延敏感业务对IMS架构的诉求。并且，统一媒体功能网元直接转发多方通话的音视频流，不对音视频流进行混音处理，有利于降低对统一媒体功能网元的性能消耗。

Description

一种呼叫处理方法、装置及系统
技术领域
本申请涉及通信技术领域，尤其涉及一种呼叫处理方法、装置及系统。
背景技术
IIP多媒体子系统(IP multimedia subsystem，IMS)为一种基于IP的网络的提供多媒体业务的通用网络架构。IMS网络采用会话发起协议(session initiation protocol，SIP)作为主要的信令协议，使得运营商可以为用户提供端到端的全IP的多媒体业务。其中，IMS网络支持丰富的业务，同时又支持多种接入方式，为不同接入方式的用户提供一致、融合的业务体验。例如，基于IMS的多方通话为用户提供多连接呼叫的能力，即可以同时有三个或三个以上的用户(与会者)参与同一次会话，方便了多用户间交流，节约了多用户间的信息沟通和传递成本。
目前，现网的组网方式来实现多方通信时，由于在IMS半呼叫模型下，无论主叫和各个与会者是否通过同一个物理IMS接入媒体网关(IMS access media gateway，IMS-AGW)接入IMS网络，每个与会者在逻辑上都需要一个独立的IMS-AGW，实时传输协议(real-timetransport protocol，RTP)媒体都需要经过主叫IMS-AGW、中心侧多媒体资源功能处理器(multimedia resource function processor，MRFP)、被叫IMS-AGW各转发一次，导致媒体多跳转发，造成资源浪费。并且，采用多点控制单元(multipoint control unit，MCU)架构的多方通信需要由中心侧的MRFP提供混音功能，导致资源消耗大；并且中心侧的MRFP只能提供多方语音通话，无法支撑多方视频及未来涉及多方的媒体业务。
发明内容
本申请实施例提供一种呼叫处理方法、装置及系统，该方法通过IMS网络中新引入的统一媒体功能网元代替原有的多方会议媒体功能网元，在接入侧提供多方通话媒体业务，减少媒体迂回，降低时延，支持XR等时延敏感业务对IMS架构的诉求。
第一方面，本申请实施例提供一种呼叫处理方法，该呼叫处理方法由统一媒体功能网元所执行。统一媒体功能网元接收来自应用服务器的多方通话连接请求消息，多方通话连接请求消息包括请求参与多方通话的终端设备的标识或者标识列表。统一媒体功能网元接收来自参与多方通话的终端设备各自的媒体数据，并将参与多方通话的终端设备中的任意一个终端设备的媒体数据，转发给参与多方通话的终端设备中除该终端设备之外的其他一个或多个终端设备。其中，参与多方通话的终端设备至少为三个终端设备。通过该方法，统一媒体功能网元替代IMS网络中原有的多媒体资源处理功能，能够在接入侧提供多方通话媒体业务，有利于减少媒体迂回，降低业务时延。并且，统一媒体功能网元直接转发多方通话的音视频流，不对音视频流进行混音处理，有利于降低对统一媒体功能网元的性能消耗。
在一种可能的设计中，统一媒体功能网元根据多方通话连接请求消息创建针对参与多方通话的终端设备各自的媒体端点。统一媒体功能网元接收来自应用服务器的关联指示信息，并根据关联指示信息关联参与多方通话的终端设备中的任意一个终端设备的媒体端点，与参与多方通话的终端设备中除任意一个终端设备之外的其他一个或多个终端设备各自的媒体端点。通过该方法，统一媒体功能网元根据应用服务器的指示，关联参与多方通话的终端设备各自的媒体端点，从而实现直接转发多方通话的音视频流，有利于降低对统一媒体功能网元的性能消耗。
在一种可能的设计中，统一媒体功能网元根据多方通话连接请求消息创建会话媒体处理上下文，会话媒体处理上下文包括参与多方通话的终端设备各自的媒体端点。
在一种可能的设计中，统一媒体功能网元根据多方通话连接请求消息创建针对参与多方通话的终端设备各自的媒体流。会话媒体处理上下文还包括针对参与多方通话的终端设备各自的媒体流。
在一种可能的设计中，统一媒体功能网元通过参与多方通话的终端设备中的任意一个终端设备的媒体端点，与参与多方通话的终端设备中除任意一个终端设备之外的其他一个或多个终端设备各自的媒体端点，之间的关联进行多流转发。通过该方法，媒体处理逻辑上只需要一个统一媒体功能网元，减少了多方通话过程中的媒体转发跳数，节省了媒体资源。
在一种可能的设计中，统一媒体功能网元向应用服务器发送参与多方通话的终端设备各自的资源标识。通过该方法，统一媒体功能网元能够向IMS信任域中的控制网元发送统一媒体资源标识URL，实现UMF媒体资源共享。
在一种可能的设计中，统一媒体功能网元根据多方通话连接请求消息创建针对参与多方通话的终端设备的选择性转发单元，选择性转发单元用于进行多流转发。通过该方法，统一媒体功能网元还可以创建针对多方通话的选择性转发单元SFU，例如，SFU用于接收来自参与多方通话的任意一个终端设备的音视频流，并向其他参与多方通话的终端设备直接转发音视频流，有利于降低对统一媒体功能网元的性能消耗。
在一种可能的设计中，统一媒体功能网元关联选择性转发单元与参与多方通话的终端设备各自的媒体端点，并通过参与多方通话的终端设备中的任意一个终端设备的媒体端点与选择性转发单元之间的关联，以及选择性转发单元与参与多方通话的终端设备中除任意一个终端设备之外的其他一个或多个终端设备各自的媒体端点之间的关联，进行多流转发。通过该方法，媒体处理逻辑上只需要一个统一媒体功能网元，减少了多方通话过程中的媒体转发跳数，节省了媒体资源。
第二方面，本申请实施例提供另一种呼叫处理方法，该呼叫处理方法由应用服务器所执行。其中，应用服务器接收第一会话请求消息，第一会话请求消息用于指示应用服务器创建多方通话。应用服务器向统一媒体功能网元发送多方通话连接请求消息，多方通话连接请求消息包括参与多方通话的终端设备的标识或者标识列表，多方通话连接请求消息用于请求统一媒体功能网元将参与多方通话的终端设备中的任意一个终端设备的媒体数据，转发给参与多方通话的终端设备中除任意一个终端设备之外的其他一个或多个终端设备。通过该方法，应用服务器可以指示统一媒体功能网元对参与多方通话的终端设备之间的音视频流进行多流转发，统一媒体功能网元替代了IMS网络中MRFP的功能。
在一种可能的设计中，应用服务器向统一媒体功能网元发送关联指示信息，关联指示信息用于指示统一媒体功能网元关联参与多方通话的终端设备中的任意一个终端设备的媒体端点，与参与多方通话的终端设备中除任意一个终端设备之外的其他一个或多个终端设备各自的媒体端点。
在一种可能的设计中，多方通话连接请求消息还用于指示统一媒体功能网元创建针对参与多方通话的终端设备的选择性转发单元，选择性转发单元与参与多方通话的终端设备各自的媒体端点相关联。其中，选择性转发单元与参与多方通话的终端设备各自的媒体端点之间的关联关系用于进行多流转发。
在一种可能的设计中，应用服务器接收来自统一媒体功能网元的参与多方通话的终端设备的资源标识。
在一种可能的设计中，第一会话请求消息为会话发起协议SIP中的INVITE消息，INVITE消息包括请求参与多方通话的任意一个终端设备的标识和多方通话创建指示信息。可选的，INVITE消息还包括请求参与多方通话的终端设备的标识列表。
在一种可能的设计中，应用服务器接收第二会话请求消息，第二会话请求消息用于指示应用服务器将参与多方通话的终端设备中除任意一个终端设备之外的其他一个或多个终端设备加入多方通话，第二会话请求消息为会话发起协议SIP中的REFER消息。
第三方面，本申请实施例提供另一种呼叫处理方法，该呼叫处理方法由第一接入媒体控制网元所执行。其中，第一接入媒体控制网元向应用服务器发送第一会话请求消息，第一会话请求消息用于指示应用服务器创建多方通话。第一接入媒体控制网元接收来自应用服务器的会话请求响应消息，会话请求响应消息包括第一终端设备的资源标识，第一终端设备为发起多方通话的终端设备。通过该方法，第一接入媒体控制网元作为多方通话的发起方，通过向应用服务器发送会话请求消息，以使应用服务器指示统一媒体功能网元创建多方通话，从而通过统一媒体功能网元即可对参与多方通话的终端设备的音视频流进行多流转发。
关于第一会话请求消息的具体描述可参考第二方面，此处不再赘述。
在一种可能的设计中，第一接入媒体控制网元向应用服务器发送第二会话请求消息，第二会话请求消息用于指示应用服务器将参与多方通话的终端设备中除第一终端设备之外的其他一个或多个终端设备加入多方通话。
第四方面，本申请实施例提供另一种呼叫处理方法，该呼叫处理方法由第二接入媒体控制网元所执行。其中，第二接入媒体控制网元接收来自应用服务器的第三会话请求消息。第二接入媒体控制网元向应用服务器发送第三会话响应消息，第三会话响应消息包括第二终端设备的媒体信息和第二媒体端点的资源标识，第二终端设备为参与多方通话的终端设备，第二媒体端点为统一媒体功能网元针对第二终端设备创建的媒体端点。通过该方法，应用服务器可以指示统一媒体功能网元为第二终端设备创建参与多方通话的媒体端点，以实现多方通话。
在一种可能的设计中，第二接入媒体控制网元向统一媒体功能网元发送媒体更新指示消息，媒体更新指示消息用于指示统一媒体功能网元将第二媒体端点的远端媒体信息更新为第二终端设备的媒体信息。
第五方面，本申请实施例提供一种呼叫处理装置，该呼叫处理装置包括通信模块。其中，通信模块用于接收来自应用服务器的多方通话连接请求消息，多方通话连接请求消息包括请求参与多方通话的终端设备的标识或者标识列表。通信模块还用于接收来自参与多方通话的终端设备各自的媒体数据，其中，参与多方通话的终端设备至少为三个终端设备。通信模块还用于将参与多方通话的终端设备中的任意一个终端设备的媒体数据，转发给参与多方通话的终端设备中除任意一个终端设备之外的其他一个或多个终端设备。
一种可能的设计中，呼叫处理装置还包括处理模块。处理模块用于根据多方通话连接请求消息创建针对参与多方通话的终端设备各自的媒体端点。处理模块还用于根据多方通话连接请求消息关联参与多方通话的终端设备中的任意一个终端设备的媒体端点，与参与多方通话的终端设备中除任意一个终端设备之外的其他一个或多个终端设备各自的媒体端点。
关于通信模块和处理模块实现的其他功能请参见第一方面，此处不再赘述。
第六方面，本申请实施例提供另一种呼叫处理装置，该呼叫处理装置包括通信模块。其中，通信模块用于接收第一会话请求消息，第一会话请求消息用于指示应用服务器创建多方通话。通信模块还用于向统一媒体功能网元发送多方通话连接请求消息，多方通话连接请求消息包括参与多方通话的终端设备的标识或者标识列表，多方通话连接请求消息用于请求统一媒体功能网元将参与多方通话的终端设备中的任意一个终端设备的媒体数据，转发给参与多方通话的终端设备中除任意一个终端设备之外的其他一个或多个终端设备。
关于通信模块实现的其他功能请参见第二方面，此处不再赘述。
第七方面，本申请实施例提供另一种呼叫处理装置，该呼叫处理装置包括通信模块。通信模块用于向应用服务器发送第一会话请求消息，第一会话请求消息用于指示应用服务器创建多方通话。通信模块还用于接收来自应用服务器的会话请求响应消息，会话请求响应消息包括第一终端设备的资源标识，第一终端设备为发起多方通话的终端设备。
关于通信模块实现的其他功能请参见第三方面，此处不再赘述。
第八方面，本申请实施例提供另一种呼叫处理装置，该呼叫处理装置包括通信模块。通信模块用于接收来自应用服务器的第三会话请求消息。通信模块还用于向应用服务器发送第三会话响应消息，第三会话响应消息包括第二终端设备的媒体信息和第二媒体端点的资源标识，第二终端设备为参与多方通话的终端设备，第二媒体端点为统一媒体功能网元针对第二终端设备创建的媒体端点。
关于通信模块实现的其他功能请参见第四方面，此处不再赘述。
第九方面，本申请实施例提供一种呼叫处理装置，该呼叫处理装置可以为设备或设置于设备中的芯片或电路。该呼叫处理装置包括用于执行上述第一方面至第四方面及其任意一种可能的设计中所提供的呼叫处理方法的单元和/或模块，因此也能实现第一方面至第四方面提供的呼叫处理方法所具备的有益效果。
第十方面，本申请实施例提供一种计算机可读存储介质，该可读存储介质包括程序或指令，当所述程序或指令在计算机上运行时，使得计算机执行第一方面至第四方面及其任一种可能实现方式中的方法。
第十一方面，本申请实施例提供一种计算机程序或计算机程序产品，包括代码或指令，当代码或指令在计算机上运行时，使得计算机执行第一方面至第四方面及其任一种可能实现方式中的方法。
第十二方面，本申请实施例提供一种芯片或者芯片系统，该芯片或者芯片系统包括至少一个处理器和接口，接口和至少一个处理器通过线路互联，至少一个处理器用于运行计算机程序或指令，以进行第一方面至第四方面及其任一种可能的实现方式中任一项所描述的方法。
其中，芯片中的接口可以为输入/输出接口、管脚或电路等。
上述方面中的芯片系统可以是片上系统(system on chip，SOC)，也可以是基带芯片等，其中基带芯片可以包括处理器、信道编码器、数字信号处理器、调制解调器和接口模块等。
在一种可能的实现中，本申请中上述描述的芯片或者芯片系统还包括至少一个存储器，该至少一个存储器中存储有指令。该存储器可以为芯片内部的存储单元，例如，寄存器、缓存等，也可以是该芯片的存储单元(例如，只读存储器、随机存取存储器等)。
第十三方面，本实施例还提供一种通信系统，该系统包括如上所述的统一媒体功能网元、应用服务器、第一接入媒体控制网元和第二接入媒体控制网元。
在一种可能的实现中，上述方面中的会话媒体处理上下文称为Context，上述方面中的媒体端点称为Endpoint，上述方面中的媒体流称为Stream。
在一种可能的实现中，上述方面中的媒体端点也可以称为Connector。
附图说明
图1为一种IMS网络架构的示意图；
图2为本申请实施例提供的一种网络架构的示意图；
图3a为一种多方通信采用Mesh架构的示意图；
图3b为一种多方通信采用MCU架构的示意图；
图3c为一种多方通信采用SFU架构的示意图；
图4为一种IMS基本呼叫与媒体协商的流程示意图；
图5为一种IMS网络中基于MCU架构的多方通话流程的示意图；
图6为一种IMS网络中基于MCU架构的多方通话流程完成后的媒体连接拓扑的示意图；
图7为一种H.248协议定义的媒体资源模型的示意图；
图8为本申请实施例提供的一种呼叫处理方法的流程示意图；
图9本申请实施例提供的一种UMF创建的针对多方通话的会话媒体处理上下文；
图10为本申请实施例提供的另一种UMF创建的针对多方通话的会话媒体处理上下文；
图11为本申请实施例提供的另一种呼叫处理方法的流程示意图；
图12为本申请实施例提供的呼叫处理方法应用于多方通话建立场景中的流程示意图；
图13为本申请实施例提供的一种呼叫处理装置的示意图；
图14为本申请实施例提供的另一种呼叫处理装置的示意图；
图15为本申请实施例提供的另一种呼叫处理装置的示意图；
图16为本申请实施例提供的另一种呼叫处理装置的示意图；
图17为本申请实施例提供的另一种呼叫处理装置的示意图；
图18为本申请实施例提供的另一种呼叫处理装置的示意图。
具体实施方式
在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。
在本申请的实施例中，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第二”、“第一”的特征可以明示或者隐含地包括一个或者更多个该特征。
应理解，在本文中对各种所述示例的描述中所使用的术语只是为了描述特定示例，而并非旨在进行限制。如在对各种所述示例的描述和所附权利要求书中所使用的那样，单数形式“一个(“a”，“an”)”和“该”旨在也包括复数形式，除非上下文另外明确地指示。
还应理解，在本申请的各个实施例中，各个过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
还应理解，根据A确定B并不意味着仅仅根据A确定B，还可以根据A和/或其它信息确定B。
还应理解，术语“包括”(也称“includes”、“including”、“comprises”和/或“comprising”)当在本说明书中使用时指定存在所陈述的特征、整数、步骤、操作、元素、和/或部件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元素、部件、和/或其分组。
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。
IP多媒体子系统(IP multimedia subsystem，IMS)为一种基于IP的网络的提供多媒体业务的通用网络架构。IMS网络采用会话发起协议(session initiation protocol，SIP)作为主要的信令协议，使得运营商可以为用户提供端到端的全IP的多媒体业务。其中，SIP采用会话描述协议(session description protocol，SDP)与发起/应答(offer/answer，简称OA)机制完成会话各参与方的媒体协商，例如音视频编解码，主机地址，网络传输协议等协商。
图1为一种IMS网络架构的示意图。IMS网络架构可以分为接入侧、中心侧和互通侧。为了便于描述，图1仅示出了IMS网络中与媒体处理相关的网元。在IMS网络架构下，媒体处理网元只能由特定的媒体控制网元直接控制。例如，媒体控制网元通过SIP信令和SDP协议与其它网元或终端设备完成媒体协商，然后控制媒体处理网元完成实际的媒体处理与媒体数据传输。其中，媒体控制网元与媒体处理网元之间通常采用H.248网关控制协议，完成媒体处理节点及其连接关系的管理。
接入侧包括IMS接入媒体网关(IMS access media gateway，IMS-AGW)、代理呼叫会话控制功能(proxy call session control function，P-CSCF)网元等。其中，IMS-AGW为接入侧媒体处理网元，用于实现终端设备的媒体接入代理与转发，网络地址转换(networkaddress translation，NAT)穿越，音频编解码转换等功能。P-CSCF用于控制IMS-AGW，完成接入侧的媒体处理。
中心侧包括多媒体资源功能处理器(multimedia resource functionprocessor，MRFP)、多媒体资源功能控制器(multimedia resource function controller，MRFC)、归属服务器(home subscriber server，HSS)、应用服务器(application server，AS)、查询呼叫会话控制功能(interrogating CSCF，I-CSCF)网元、服务呼叫会话控制功能(serving CSCF，S-CSCF)网元等。其中，MRFP是中心侧的媒体处理网元，用于提供放音收号、语音会议等功能。MRFC用于控制MRFP完成放音收号、语音会议等功能。
互通侧包括互通边界控制功能(interconnection border control function，IBCF)网元、转换网关(transition gateway，TrGW)、IP多媒体网关(IP multimedia mediagateway，IM-MGW)、媒体网关控制功能(media gateway control function，MGCF)网元等。其中，TrGW与IM-MGW是互通侧的媒体处理网元，用于实现IMS网络与其它网络的媒体互通。例如，TrGW用于实现IMS网络与其他IP网络媒体面的互通，包括媒体NAT、服务质量(qualityof service，QoS)控制和编解码转换等。IM-MGW用于实现IMS网络和其他非IP网络(例如公共交换电话网络(public switched telephone network，PSTN)、公用陆地移动通信网(public land mobile network，PLMN))媒体面的互通。IBCF用于控制TrGW，完成与其它IP域的媒体互通控制。MGCF用于控制IM-MGW，完成与非IP域的媒体互通控制。
其中，IMS网络支持丰富的业务，同时又支持多种接入方式。IMS网络为不同接入方式的用户提供一致、融合的业务体验。例如，基于IMS网络的多方通话可以为用户提供多连接呼叫的能力，即可以同时有三个或三个以上的用户(与会者)参与同一次会话，方便了多用户间交流，节约了多用户间的信息沟通和传递成本。现有标准协议3GPP TS 24.147描述了IMS网络架构下的多方通话业务流程。其中，IMS网络采用多点控制单元(multipointcontrol unit，MCU)架构模型，AS提供多方通话的业务逻辑控制，实现业务触发、控制MRFC/MRFP实现会议资源分配、接续呼叫、参数方人数控制等功能。MRFP为媒体服务器，为多方通话提供混流和媒体转发。
但是，在IMS半呼叫模型下，无论多方通话的参与方是否通过同一个物理IMS-AGW接入IMS网络，各个多方通话的参与方在逻辑上都需要一个独立的IMS-AGW，实时传输协议(real-time transport protocol，RTP)媒体需要经过主叫侧的IMS-AGW、中心侧的MRFP、被叫侧的IMS-AGW各转发一次。也就是说，在IMS半呼叫模型下，多方通话的参与方在进行多方通话时，将通过多跳转发才能实现端到端的媒体数据的传输，导致媒体迂回。增加业务传输时延。并且，采用MCU架构的多方通话需要由中心侧的MRFP提供混音功能，使得MRFP的资源消耗大。目前中心侧的MRFP只能提供多方语音通话，无法支撑多方视频通话及未来涉及多方的媒体业务。
因此，在IMS半呼叫模型下，如何避免媒体多跳转发，降低业务处理时延，以及如何降低媒体处理开销，支持多方视频及未来涉及多方的媒体业务成为待解决的问题。
为了解决上述问题，本申请实施例提供一种呼叫处理方法，该呼叫处理方法基于IMS网络架构，由新增的统一媒体功能(unified media function，UMF)网元所执行。UMF可以通过接入侧提供媒体能力，减少媒体迂回，有利于支持扩展现实等时延敏感业务对IMS网络架构的需求。并且，UMF直接转发参与多方通话的终端设备各自的媒体流，不需要对多个媒体流进行混音处理，有利于减少对媒体服务器的性能消耗。
本申请实施例提供的呼叫处理方法应用于如图2所示的一种网络架构中。图2所示的网络架构包括本申请实施例新增的UMF。UMF在功能上除了融合当前IMS网络架构中的媒体处理网元，例如IMS-AGW、MRFP、TrGW等之外，还可以提供未来新业务需要的媒体处理功能，如数据通道服务(data channel server)。UMF可以同时部署在接入侧、中心侧或互通侧，IMS信任域的所有网元均可控制UMF。UMF用于提供丰富的媒体处理能力，减少媒体迂回，满足未来XR等低时延敏感业务的诉求。
其中，图2所示的网络架构还包括AS、MGCF、IBCF、I-CSCF、S-CSCF、P-CSCF、HSS和终端设备，各个网元或设备的功能与现有的IMS网络中对应的网元或设备的功能类似，并且还支持未来媒体能力演进。例如，本申请实施例中的媒体功能控制(例如P-CSCF控制UMF执行基本呼叫建立时)采用非OA机制，通过如媒体网关控制协议(例如H.248协议)接口或服务化接口等控制UMF，从而在执行媒体业务时避免信令重协商和媒体重定向，实现IMS信令面(包括OA协商)与媒体能力解耦，有利于支持未来媒体能力演进。应注意，图2所示的网络架构重点体现媒体业务，未示出非媒体业务相关的网元。CSCF一般不参与媒体业务，因此图2中不体现CSCF与UMF的控制关系，但是本申请实施例不作限定。
图2所涉及到的终端设备还可以称为终端，可以是一种具有无线收发功能的设备，其可以部署在陆地上，包括室内或室外、手持或车载；也可以部署在水面上(如轮船等)；还可以部署在空中(例如飞机、气球和卫星上等)。终端设备可以是用户设备(userequipment，UE)，其中，UE包括具有无线通信功能的手持式设备、车载设备、可穿戴设备或计算设备。示例性地，UE可以是手机(mobile phone)、平板电脑或带无线收发功能的电脑。终端设备还可以是虚拟现实(virtual reality，VR)终端设备、增强现实(augmentedreality，AR)终端设备、工业控制中的无线终端、无人驾驶中的无线终端、远程医疗中的无线终端、智能电网中的无线终端、智慧城市(smart city)中的无线终端、智慧家庭(smarthome)中的无线终端等等。本申请实施例中，用于实现终端的功能的装置可以是终端；也可以是能够支持终端实现该功能的装置，例如芯片系统，该装置可以被安装在终端中。本申请实施例中，芯片系统可以由芯片构成，也可以包括芯片和其他分立器件。本申请实施例提供的技术方案中，以用于实现终端的功能的装置是终端为例，描述申请实施例提供的技术方案。
下面对本申请实施例涉及的相关概念进行描述。
1、多方通信的网络架构方案：目前针对多方通信，主要有以下三种网络架构方案。
方案一：Mesh架构。图3a为一种多方通信采用Mesh架构的示意图。Mesh架构下，多个终端之间两两进行连接，形成一个网状结构。例如，图3a中的终端A～终端D一共4个终端进行多对多通信，当终端A想要共享媒体数据(比如音频、视频)时，终端A需要分别向终端B、终端C和终端D发送媒体数据。类似的，当终端B想要共享媒体数据时，就需要分别向终端A、终端C和终端D发送媒体数据，依次类推。可见，采用Mesh架构进行多方通话时对各个终端的带宽要求比较高。
方案二：MCU架构。图3b为一种多方通信采用MCU架构的示意图。该MCU架构为由一个MCU服务器和多个终端组成的星形结构。其中，终端A～终端D将待共享的音视频流发送给MCU服务器，MCU服务器将在同一个会话中的所有终端的音视频流进行混合，生成一个混合后的音视频流。MCU服务器再将混合后的音视频流分别发送给终端A～终端D，则各个终端就可以看到/听到其他终端的音视频了。其中，该MCU服务器端就是一个音视频混合器，采用MCU架构进行多方通信时，对MCU服务器的处理性能要求较高，MCU服务器的业务处理压力会非常大。
方案三：选择性转发单元(selective forwarding unit，SFU)架构。图3c为一种多方通信采用SFU架构的示意图。该MCU架构为由一个SFU服务器和多个终端组成的星形结构。但与MCU媒体服务器不同的是，SFU媒体服务器不对音视频进行混流。当SFU媒体服务器接收某个终端共享的音视频流后，就直接将该音视频流转发给多方通话中的其他终端。也就是说，该SFU服务器实际上就是一个音视频路由转发器。其中，目前业界基于WebRTC的多方通信媒体服务器都是采用SFU架构，如Kurento，Licode，MediaSoup，Janus等。相比MCU模式，SFU媒体服务器性能消耗更低，但带宽占用比MCU大。
2、IMS半呼叫模型：无论主叫终端设备与被叫终端设备是否通过一个物理上的IMS-AGW接入IMS网络，在逻辑上主叫侧与被叫侧为两个IMS-AGW，需要建立两个媒体上下文。
3、IMS基本呼叫与媒体协商：图4为一种IMS基本呼叫与媒体协商的流程示意图。该基本呼叫与媒体协商流程是由终端设备、IMS-AGW、P-CSCF、CSCF/AS之间的交互实现。应注意，由于IMS为半呼叫模型，无论主叫与被叫是否通过同一个物理IMS网络接入，其呼叫处理分别由两个不同的逻辑实体完成。也就是说，即图4中逻辑上的上行(mobile original，MO)包括主叫终端设备、主叫IMS-AGW、主叫P-CSCF和主叫CSCF/AS，下行(mobile terminated，MT)包括被叫终端设备、被叫IMS-AGW、被叫P-CSCF和被叫CSCF/AS。图4所示的基本呼叫与媒体协商流程包括：
A、主叫终端设备通过初始INVITE消息携带自身媒体信息(SDP)，该媒体信息为SDPOffer。
B、主叫P-CSCF接收INVITE消息，记录并储存主叫终端设备的媒体信息。并且，主叫P-CSCF指示主叫IMS-AGW分配输出媒体端点O2，对应的本地媒体信息为SDP(O2)。主叫P-CSCF将主叫媒体信息替换为SDP(O2)，然后通过SIP信令传递给后续网元。例如，该SIP信令由主叫P-CSCF发送给主叫CSCF/AS，再由主叫CSCF/AS发送给被叫CSCF/AS，再由被叫CSCF/AS发送给被叫P-CSCF。
C、被叫P-CSCF接收INVITE消息，记录并储存主叫侧媒体信息。并且，被叫P-CSCF指示被叫IMS-AGW分配输出媒体端点T2，对应本地媒体信息为SDP(T2)。被叫P-CSCF再将SDP(T2)发送给被叫终端设备。
D、被叫终端设备通过首个可靠1XX(183或180)响应消息携带媒体信息，该媒体信息为SDP Answer。
E、被叫P-CSCF接收1XX响应消息，将T2的远端媒体信息更新为被叫终端设备的媒体信息。并且，被叫P-CSCF指示被叫IMS-AGW分配输入媒体端点T1，对应的本地媒体信息为SDP(T1)，对应的远端媒体信息为之前保存的主叫媒体信息SDP(O2)。
F、被叫P-CSCF指示被叫IMS-AGW关联T1和T2，并将被叫SDP替换为SDP(T1)，然后通过SIP信令传递给后续网元。例如，该SIP信令由被叫P-CSCF发送给被叫CSCF/AS，再由被叫CSCF/AS发送给主叫CSCF/AS，再由主叫CSCF/AS发送给主叫P-CSCF。其中，若被叫终端设备不支持标准协议RFC3262定义的1XX响应可靠传输机制，则被叫终端设备可以通过200(INVITE)响应携带SDP Answer。
G、主叫P-CSCF接收被叫的SDP Answer(T1)，将O2的远端媒体信息更新为SDP(T1)。主叫P-CSCF指示主叫IMS-AGW分配输入媒体端点O1，对应的本地媒体信息为SDP(O1)，对应的远端媒体信息为之前保存的主叫终端设备的媒体信息。
H、主叫P-CSCF指示主叫IMS-AGW关联O1和O2，并将主叫SDP替换为SDP(O1)，然后通过SIP信令传递给主叫终端设备。
综上所述，媒体协商过程完成，主叫终端设备和被叫终端设备可以传输RTP媒体。
可选的，若主叫侧在初始INVITE消息中不携带媒体信息(慢启流程)，则可通过以下2种流程完成媒体协商：
1)被叫侧在首个可靠18X(183或180)响应消息中携带SDP Offer，主叫通过PRACK消息回复SDP Answer，完成媒体协商。
2)被叫在200(INVITE)响应消息中携带SDP Offer，主叫通过ACK消息回复SDPAnswer，完成媒体协商。
可选的，主叫终端设备和被叫终端设备之间的通话结束后，主叫侧和被叫侧将执行呼叫释放，具体实现方式参考现有协议标准中的描述，在此不再赘述。
4、基于MCU架构的多方通话：图5为一种IMS网络中基于MCU架构的多方通话流程的示意图。该多方通话流程是由终端设备(包括第一终端设备、第二终端设备和第三终端设备)、P-CSCF、S-CSCF、AS、MRF(将MRFC与MRFP合并，统称为MRF)之间的交互实现。应注意，由于IMS为半呼叫模型，无论主叫与被叫是否通过同一个物理IMS网络接入，其呼叫处理分别由两个不同的逻辑实体完成。也就是说，即图5中逻辑上的上行(mobile original，MO)包括第一终端设备、P-CSCF、S-CSCF、AS和MRF，下行(mobile terminated，MT)包括第二终端设备、P-CSCF和S-CSCF。为了描述简便，图5中未示完整示出MT侧的P-CSCF和S-CSCF，其作用和MO侧的P-CSCF和S-CSCF是相同的，处理流程也与MO侧相同。图5所示的多方通话流程包括：
A、UE-A与UE-B通话中，UE-A将UE-B保持，然后发起多方通话。
B、UE-A发送INVITE消息，该INVITE消息中的参数request-uri为conferencefactory uri，表示该INVITE消息用于请求创建多方通话。AS收到该INVITE消息，到MRF上申请会议资源，并将UE-A加入多方通话。
C、UE-A发送REFER消息，该REFER消息中的refer-to头域为B，表示该REFER消息用于指示AS将UE-B加入多方通话。并且该REFER消息还携带replace参数，该参数用于指示AS新建多方通话代替UE-A和UE-B原有的会话。
D、AS接收REFER消息，向UE-B发送INVITE消息。该INVITE消息中携带replace头域，并携带UE-A和UE-B原有的会话信息。
E、AS接收UE-B的200响应消息，到MRF上申请多方通话资源，并将UE-B加入多方通话。并且，AS释放之前为UE-B申请的放音资源(通话保持)，向UE-A和UE-B发送BYE消息释放UE-A和UE-B原有的会话。
F、UE-A请求将UE-C加入多方通话，具体实现流程与UE-A请求将UE-B加入多方通话的流程类似。不同之处在于UE-A和UE-C原本未建立会话，则UE-A发送的REFER消息中refer-to头域为C，且不携带replace参数。AS向UE-C发送INVITE消息时也不携带replace头域。
应注意，图5中仅示出了三个终端设备参与多方通话，还可以有更多的终端设备参与多方通话(例如第四终端设备、第五终端设备等)，具体实现方式与图5中的三个终端设备类似，本实施例不作限定。
其中，图6为一种IMS网络中基于MCU架构的多方通话流程完成后的媒体连接拓扑的示意图。其中，在IMS半呼叫模型下，无论多方通话的参与方是否通过同一个物理IMS-AGW接入IMS网络，各个多方通话的参与方在逻辑上都需要一个独立的IMS-AGW。例如，对于第一终端设备的RTP媒体，需要经过第一终端设备对应的IMS-AGW、中心侧的MRFP、第二终端设备对应的IMS-AGW各转发一次(至少三跳)，才能传输至第二终端设备，如图6所示。
5、基于媒体网关控制协议的媒体资源模型：现网中对媒体资源的控制，除了基于SDP协议的OA机制，还有基于媒体网关控制协议(如H.248)的媒体资源模型。图7为H.248协议定义的媒体资源模型，该媒体资源模型包括终端(terminal)和上下文(context)。其中，终端是逻辑实体，用于发送和接收一种或多种媒体，媒体类型可以是窄带的时隙、模拟线，也可以是基于IP的RTP流等。例如，终端可以发送视频流(video stream)、音频流(audiostream)和信息流(message stream)等，如图7所示。应注意，一个终端属于且只能属于一个上下文。上下文表示终端间的连接关系，它描述了终端之间的拓扑关系及媒体混合/交换的参数。基于图7所示的媒体资源模型，H.248协议还定义了对应的协议接口，控制网元通过协议接口管理内部的媒体资源及连接关系。其中，协议接口包括但不限于：Add命令(用于在上下文中新增终端)、Modify命令(用于修改一个终端的属性、事件等)、Subtract命令(用于从上下文中删除终端，并且返回终端的统计状态)、Move命令(用于将一个终端从一个上下文移到另一个上下文中)、Notify命令(用于将检测到的事件通知控制网元)。
6、基于服务化接口的媒体资源模型：业界开源媒体服务器大多提供了服务化接口，如REST API或RPC，用于控制媒体处理网元，典型的如Kurento。其中，Kurento的逻辑架构包括Kurento媒体服务器(KurentoMedia Server，KMS)、应用服务器(applicationserver，AS)等模块。其中，KMS相当于IMS中的媒体处理网元，AS相当于IMS网络中的媒体控制网元，AS通过Kurento protocol控制KMS。Kurento protocol采用基于websocket的JSON-RPC接口。与H.248协议类似，KMS内部也提供了对应的媒体资源模型，通过Kurentoprotocol来描述媒体资源的管理及其连接关系。KMS媒体资源模型采用了面向对象的思想，将媒体资源抽象为各种对象，最主要的媒体资源对象是Media Pipeline和MediaElements。KMS采用流水线架构描述媒体业务，Media Pipeline对象表示媒体处理流水线，用于描述媒体处理对象之间的连接拓扑关系，相当于H.248协议中的context。MediaElements表示媒体处理组件对象，根据其提供的功能，媒体处理组件又分为Endpoints，Filters，Hubs等。Endpoints主要提供媒体流的收发，相当于H.248中的终端。Filters主要提供一些媒体处理能力，如音视频编解码。KMS可通过Filters提供丰富的媒体处理能力，具备很好的扩展性。与H.248协议类似，Kurento protocol描述了媒体资源的管理(包括创建，修改，删除)、事件订阅以及媒体资源的连接拓扑关系，其格式为JSON(或者也可以采用其他格式)。
下面对本申请实施例的方法进行详细的描述。
图8为本申请实施例提供的一种呼叫处理方法的流程示意图。该呼叫处理方法由统一媒体功能网元UMF所执行，包括以下步骤：
801，统一媒体功能网元接收来自应用服务器的多方通话连接请求消息，多方通话连接请求消息包括请求参与多方通话的终端设备的标识或者标识列表。
其中，当IMS网络中存在终端设备请求发起多方通话时，应用服务器可以指示统一媒体功能网元UMF创建多方通话。其中，本申请实施例中的UMF作为媒体服务器，可以取代现有MRFP，实现多方通话(包括语音通话、视频通话等)。其中，应用服务器向统一媒体功能网元发送多方通话连接请求消息，该多方通话连接请求消息用于指示统一媒体功能网元创建多方通话。
一种实现方式中，多方通话连接请求消息中包括请求参与多方通话的终端设备的标识。例如，IMS网络中的第一终端设备请求创建多方通话，第一终端设备首先向P-CSCF发送INVITE消息，该INVITE消息中的request-uri为conference factory uri，表示业务类型为会议呼叫(多方通话)。P-CSCF向AS发送INVITE消息，INVITE消息中还包括第一终端设备的标识(例如为第一终端设备的SIP信息)。AS根据该INVITE消息确定多方通话连接请求消息，并向UMF发送多方通话连接请求消息，以指示UMF将第一终端设备加入多方通话。
一种实现方式中，多方通话连接请求消息中包括请求参与多方通话的终端设备的标识列表。例如，IMS网络中的第一终端设备请求创建多方通话，并且请求将第二终端设备和第三终端设备都加入多方通话。第一终端设备向P-CSCF发送的INVITE消息中的request-uri为conference factory uri，并且该INVITE消息中还包括请求参与多方通话的终端设备的标识列表，该标识列表包括第一终端设备、第二终端设备和第三终端设备各自的标识(例如为各自的SIP信息)。应注意，本申请实施例中参与多方通话的终端设备至少为三个终端设备。
一种实现方式中，统一媒体功能网元接收多方通话连接请求消息后，可以根据该多方通话连接请求消息创建针对参与多方通话的终端设备各自的媒体端点。其中，本申请实施例中的媒体端点类似于图7所示的媒体资源模型中的终端，为一种逻辑实体，用于发送和接收一种或多种媒体。一个媒体端点(endpoint)用于标识一个IP连接的五元组，包括本端和远端分别的IP地址、端口地址及传输类型。其中，endpoint的本端IP地址和端口地址是指已连接的设备的IP地址和端口地址。例如，第一媒体端点为针对第一终端设备创建的媒体端点，则第一媒体端点的本端IP地址和端口地址为第一终端设备的IP地址和端口地址。endpoint的远端IP地址和端口地址是指待连接的资源或设备对应的IP地址和端口地址。传输类型可以包括但不限于RTP over用户数据报协议(user datagram protocol，UDP)或数据通道(data channel)over UDP/数据包传输层安全性协议(datagram transport layersecurity，DTLS)/流控制传输协议(stream control transmission protocol，SCTP)等。
其中，不同的媒体端点通过媒体端点的资源标识来区分，例如，通过统一资源定位符(uniform resource locator，URL)来区分。媒体端点的资源标识为EndpointURL，EndpointURL的格式为：endpoints/{endpoint_id}。其中，endpoints表示该URL为EndpointURL，{endpoint_id}为endpoint的编号，在运行时动态分配。可以理解，UMF创建第一媒体端点时，也创建第一媒体端点的资源标识。其中，第一媒体端点的资源标识例如为Endpoint1URL。
可选的，统一媒体功能网元还根据第一媒体连接请求消息创建针对第一终端设备的第一媒体流。其中，本申请实施例中的媒体流类似于图7所示的媒体资源模型中的音频流等，包括了媒体流的详细信息，例如媒体流包括音视频的编解码信息等。其中，一个endpoint上可以有多个媒体流，例如，多方通话中一个endpoint上的视频多流，datachannel上的多个通道等。其中，不同的媒体流通过媒体流的资源标识来区分。例如，媒体流的资源标识为StreamURL，StreamURL的格式为：streams/{stream_id}。其中，streams表示该URL为StreamURL，{stream_id}为Stream的编号，在运行时动态分配。可以理解，UMF创建第一媒体流时，也创建第一媒体流的资源标识。例如，第一媒体流的资源标识为Stream1URL。
可选的，统一媒体功能网元还根据第一媒体连接请求消息创建会话媒体处理上下文(Context)。其中，会话媒体处理上下文可以视为逻辑上的一种容器，用于记录媒体端点和媒体流。例如，会话媒体处理上下文为一个RTP处理实体或一个datachannel处理实体。一个Context可以有多个Endpoint，一个Endpoint可以有多条Stream。其中，不同的会话媒体处理上下文通过会话媒体处理上下文的资源标识来区分。例如，会话媒体处理上下文的资源标识为ContextURL，ContextURL的格式为：{umf_domain}/contexts/{context_id}。其中，{umf_domain}为UMF的域名，contexts表示该URL为ContextURL，{context_id}为Context的编号，在运行时动态分配。
802，统一媒体功能网元接收来自参与多方通话的终端设备各自的媒体数据。
803，统一媒体功能网元将参与多方通话的终端设备中的任意一个终端设备的媒体数据，转发给参与多方通话的终端设备中除任意一个终端设备之外的其他一个或多个终端设备。
一种实现方式中，根据步骤801中的描述，统一媒体功能网元根据多方通话连接请求消息创建了针对参与多方通话的终端设备各自的媒体端点和媒体流，用于传输参与多方通话的终端设备之间的媒体数据。例如，参与多方通话的终端设备包括第一终端设备、第二终端设备和第三终端设备，UMF创建针对第一终端设备的第一媒体端点和多个第一媒体流、针对第二终端设备的第二媒体端点和多个第二媒体流，以及针对第三终端设备的第三媒体端点和多个第三媒体流。可以理解，针对一个媒体端点可以有多个媒体流，用于传输不同的终端设备之间的媒体数据，从而可以实现多方通话。例如，统一媒体功能网元可以通过第一媒体端点接收来自第一终端设备的媒体数据，并通过多个第一媒体流，分别向第二终端设备和第三终端设备发送第一终端设备的媒体数据。又例如，统一媒体功能网元可以通过第多个第一媒体流接收来自第二终端设备和第三终端设备的媒体数据，并通过第一媒体端点向第一终端设备发送第二终端设备和第三终端设备的媒体数据。
一种实现方式中，统一媒体功能网元接收来自应用服务器的关联指示信息，并根据关联指示信息，关联参与多方通话的终端设备中的任意一个终端设备的媒体端点，与参与多方通话的终端设备中除该终端设备之外的其他一个或多个终端设备各自的媒体端点。
例如，图9为本申请实施例提供的一种UMF创建的针对多方通话的会话媒体处理上下文。该会话媒体处理上下文包括第一媒体端点、第二媒体端点和第三媒体端点，以及多个第一媒体流、多个第二媒体流和多个第三媒体流。其中，会话媒体处理上下文的资源标识为ContextURL，ContextURL的格式为：{umf_domain}/contexts/{context_id}。假设{umf_domain}为umf.huawei.com，Context的编号为1000，则ContextURL为umf.huawei.com/contexts/1000。假设第一媒体端点的编号为5000，则Endpoint1URL为umf.huawei.com/contexts/1000/endpoints/5000。假设第二媒体端点的编号为6000，则Endpoint2URL为umf.huawei.com/contexts/1000/endpoints/6000。假设第三媒体端点的编号为7000，则Endpoint3URL为umf.huawei.com/contexts/1000/endpoints/7000。并且，统一媒体功能网元将第一媒体端点、第二媒体端点和第三媒体端点分别通过association关联。例如，第一媒体端点分别与第二媒体端点和第三媒体端点关联，第二媒体端点分别与第一媒体端点和第三媒体端点关联，第三媒体端点分别与第一媒体端点和第二媒体端点关联，如图9所示。其中，对于媒体端点传输的媒体流，一个入流可以关联多个出流，多个入流可以关联一个出流。其中，若入流和出流的编解码属性不同，则需要添加编解码转换组件。
一种实现方式中，统一媒体功能网元通过参与多方通话的终端设备中的任意一个终端设备的媒体端点，与参与多方通话的终端设备中除任意一个终端设备之外的其他一个或多个终端设备各自的媒体端点，之间的关联进行多流转发。例如，当第一终端设备需要向第二终端设备和第三终端设备发送媒体数据时，统一媒体功能网元通过第一媒体端点与第二媒体端点之间的关联，以及第一媒体端点和第三媒体端点之间的关联，向第二终端设备和第三终端设备进行多流转发，如图9所示。
一种实现方式中，统一媒体功能网元向应用服务器发送参与多方通话的终端设备各自的资源标识。也就是说，UMF可以向IMS信任域中的控制网元发送EndpointURL(或StreamURL、ContextURL)，以使IMS信任域中所有网元能够直接控制UMF。从而使得在IMS半呼叫模型下共享媒体资源成为可能，在逻辑上只需要一个UMF，媒体转发只需要一次即可，同时也节省了媒体资源。其中，UMF传递媒体资源URL。例如，UMF向AS发送Endpoint1URL、Endpoint2URL和Endpoint3URL，并且UMF还可以向P-CSCF发送上述URL，从而有利于实现IMS网络中共享媒体资源，减少媒体转发跳数，避免多AS串接时的媒体业务冲突和媒体碰撞，减少媒体资源浪费。其中，UMF对IMS网元提供的接口，可以采用各种控制协议，包括但不限于H.248媒体网关控制协议、RESTful API、RPC等。
一种实现方式中，统一媒体功能网元根据多方通话连接请求消息创建针对参与多方通话的终端设备的选择性转发单元，选择性转发单元用于进行多流转发。也就是说，UMF内部还可以创建一个逻辑实体作为选择性转发单元(SFU)，该选择性转发单元可以将参与多方通话的终端设备中的任意一个终端设备的媒体数据，转发给参与多方通话的终端设备中除该终端设备之外的其他一个或多个终端设备。具体实现方式，包括以下步骤：
1.统一媒体功能网元关联选择性转发单元与参与多方通话的终端设备各自的媒体端点。
2.统一媒体功能网元通过参与多方通话的终端设备中的任意一个终端设备的媒体端点与选择性转发单元之间的关联，以及选择性转发单元与参与多方通话的终端设备中该终端设备之外的其他一个或多个终端设备各自的媒体端点之间的关联，进行多流转发。
例如，图10为本申请实施例提供的另一种UMF创建的针对多方通话的会话媒体处理上下文。该会话媒体处理上下文还包括选择性单元SFU。其中，UMF关联SFU和第一媒体端点，并关联SFU和第二媒体端点，并关联第三媒体端点，如图10所示。当第一终端设备向第二终端设备和第三终端设备发送媒体数据时，UMF通过第一媒体端点与SFU之间的关联，以及SFU与第二终端设备之间的关联、SFU与第三终端设备之间的关联进行多流转发。
可选的，统一媒体功能网元还可以针对每一个媒体端点，都创建一个SFU。也就是说，一个媒体端点对应一个专用的SFU。UMF通过各个媒体端点对应的SFU之间的关联，对参与多方通话的终端设备之间的媒体数据进行多流转发。
本申请实施例提供一种呼叫处理方法，该方法中UMF可以通过接入侧提供媒体能力，减少媒体迂回，有利于支持扩展现实等时延敏感业务对IMS网络架构的需求。并且，UMF直接转发参与多方通话的终端设备各自的媒体流，不需要对多个媒体流进行混音处理，有利于减少对媒体服务器的性能消耗。
图11为本申请实施例提供的另一种呼叫处理方法的流程示意图。本实施例中以三方通话为例进行描述。该呼叫处理方法由第一终端设备、第二终端设备、第三终端设备、第一接入媒体控制网元、第二接入媒体控制网元、第三接入媒体控制网元、应用服务器、统一媒体功能网元之间的交互实现。其中，本实施例中假设第一终端设备、第二终端设备和第三终端设备之间均未建立媒体连接，该呼叫处理方法包括以下步骤：
1101，第一终端设备向第一接入媒体控制网元发送第一会话请求消息，第一会话请求消息用于指示应用服务器创建多方通话。
例如，第一终端设备向第一P-CSCF发送INVITE消息，该INVITE消息中的参数request-uri为conference factory uri，表示该INVITE消息用于请求创建多方通话。其中，该INVITE消息中包括第一终端设备的标识。可选的，该INVITE消息包括参与多方通话的终端设备各自的标识。
1102，第一接入媒体控制网元根据第一会话请求消息，向统一媒体功能网元发送第一媒体连接请求消息，第一媒体连接请求消息用于指示统一媒体功能网元创建针对第一终端设备的第一媒体端点。具体实现方式，参考图8实施例中对UMF创建媒体端点的具体实现方式的描述，在此不再赘述。
1103，统一媒体功能网元创建针对第一终端设备的第一媒体端点。
1104，统一媒体功能网元向第一接入媒体控制网元发送第一媒体端点的统一媒体资源标识。
1105，第一接入媒体控制网元更新第一会话请求消息，并向应用服务器发送更新后的第一会话请求消息。
其中，第一接入媒体控制网元将第一媒体端点的统一媒体资源标识Endpoint1URL加入第一会话请求消息中，更新第一会话请求消息。
1106，应用服务器根据更新后的第一会话请求消息，向统一媒体功能网元发送多方通话连接请求消息。
1107，统一媒体功能网元确定第一媒体端点为参与多方通话的终端设备的媒体端点。
1108，统一媒体功能网元向第一接入媒体控制网元发送第一会话响应消息，第一会话响应消息包括第一终端设备(第一媒体端点)的资源标识和多方通话的资源标识。其中，多方通话的资源标识也可以是统一资源标识URL。
1109，第二终端设备获取多方通话的资源标识。其中，第二终端设备获取多方通话的资源标识可以包括但不限于以下两种情况：
情况一：第二终端设备接收来自第一终端设备的REFER消息，该REFER消息包括多方通话的资源标识。
情况二：第二终端设备通过邮件、短信等方式获取多方通话的资源标识。
上述两种情况下，第二终端设备在收到REFER消息后，直接向P-CSCF发送INVITE消息请求加入多方通话。
1110，第二终端设备向第二接入媒体控制网元发送第二会话请求消息，第二会话请求消息用于请求将第二终端设备加入多方通话。
1111，第二接入媒体控制网元根据第二会话请求消息，向统一媒体功能网元发送第二媒体连接请求消息，第二媒体连接请求消息用于指示统一媒体功能网元创建针对第二终端设备的第二媒体端点。
1112，统一媒体功能网元创建针对第二终端设备的第二媒体端点。
1113，统一媒体功能网元向第二接入媒体控制网元发送第二媒体端点的统一媒体资源标识。
1114，第二接入媒体控制网元更新第二会话请求消息，并向应用服务器发送更新后的第二会话请求消息。
其中，第二接入媒体控制网元将第二媒体端点的统一媒体资源标识Endpoint2URL加入第二会话请求消息中，更新第二会话请求消息。
1115，应用服务器根据更新后的第二会话请求消息，向统一媒体功能网元发送关联指示信息。
1116，统一媒体功能网元根据关联指示信息，关联第一媒体端点和第二媒体端点。
1117，统一媒体功能网元向应用服务器发送确认消息；
1118，应用服务器向第二接入媒体控制网元发送确认消息和第二会话响应消息，第二会话响应消息包括第二终端设备(第二媒体端点)的资源标识。
1119，第三终端设备获取多方通话的资源标识，并向第三接入媒体控制网元发送第三会话请求消息，第三会话请求消息用于请求将第三终端设备加入多方通话。具体实现方式与第二终端设备对应的步骤类似，在此不再赘述。
1120，第三接入媒体控制网元根据第三会话请求消息，向统一媒体功能网元发送第三媒体连接请求消息，第三媒体连接请求消息用于指示统一媒体功能网元创建针对第三终端设备的第二媒体端点。
1121，统一媒体功能网元创建针对第三终端设备的第三媒体端点。
1122，统一媒体功能网元向第三接入媒体控制网元发送第三媒体端点的统一媒体资源标识。
1123，第三接入媒体控制网元更新第三会话请求消息，并向应用服务器发送更新后的第三会话请求消息。
其中，第三接入媒体控制网元将第三媒体端点的统一媒体资源标识Endpoint3URL加入第三会话请求消息中，更新第三会话请求消息。
1124，应用服务器根据更新后的第三会话请求消息，向统一媒体功能网元发送关联指示信息。
1125，统一媒体功能网元根据关联指示信息，关联第一媒体端点和第三媒体端点，并且关联第二媒体端点和第三媒体端点。
1126，统一媒体功能网元向应用服务器发送确认消息。
1127，应用服务器向第三接入媒体控制网元发送确认消息和第三会话响应消息，第三会话响应消息包括第三终端设备(第三媒体端点)的资源标识。
下面对图8至图11所示的呼叫处理方法应用于具体场景中的应用实施例进行详细的描述。图12为本申请实施例提供的呼叫处理方法应用于多方通话建立场景中的流程示意图。该多方通话建立场景包括第一终端设备UE-A、第二终端设备UE-B、第三终端设备UE-C、代理呼叫会话控制功能P-CSCF1、服务呼叫会话控制功能S-CSCF1、代理呼叫会话控制功能P-CSCF2、服务呼叫会话控制功能S-CSCF2、代理呼叫会话控制功能P-CSCF3、服务呼叫会话控制功能S-CSCF3、应用服务器AS和统一媒体功能网元UMF。应注意，为了描述简便，图12中未示完整示出UE-B与代理呼叫会话控制功能P-CSCF2、服务呼叫会话控制功能S-CSCF2之间的交互流程(与基本呼叫流程相同，不再赘述)，UE-C与代理呼叫会话控制功能P-CSCF3、服务呼叫会话控制功能S-CSCF3之间的交互流程(与基本呼叫流程相同，不再赘述)。其中，该多方通话建立场景假设UE-A和UE-B已建立会话，UE-A将UE-B保持，然后发起多方通话。图12所示的多方通话建立流程包括以下步骤：
1.UE-A发送INVITE消息，request-uri为conference factory uri，该uri用于指示AS创建会议。
2.P-CSCF1接收INVITE消息，指示UMF创建媒体端点endpoint1，处理过程参考基本通话流程中创建媒体端点的描述。
3.P-CSCF1向AS发送INVITE消息，消息中增加local-media头域，携带endpoint1的URL。
4.AS接收INVITE消息，request-uri为conference factory uri，记录业务类型是会议呼叫(多方通话)，同时向主叫侧发送200(INVITE)响应消息，携带endpoint1的SDP信息。
5.P-CSCF1向UE-A发送200(INVITE)响应消息，该响应消息中不包括local-media头域(local-media头域只在IMS域内传递)，携带endpoint1的SDP信息。通过上述流程，UE-A加入多方通话。
6～7.UE-A发送REFER消息，refer-to头域为B，携带replace参数(该参数用于指示AS用新建多方通话代替UE-A和UE-B原有会话)，指示AS将UE-B加入多方通话。
8～9.AS接收REFER消息，向P-CSCF1发送202(REFER)响应消息，用于指示接受该REFER请求。
10～11.REFER有一个隐含订阅，隐含订阅用于订阅REFER请求的进展状态，即AS将UE-B加入多方通话的进展状态。例如，AS向P-CSCF1发送NOTIFY消息，消息体内容携带SIP/2.0 100Trying，用于通知主叫REFER的订阅状态为active，该状态表示AS已接收并验证通过REFER创建的订阅，消息体中的内容“SIP/2.0 100Trying”表示进展状态为100Trying，即AS正在尝试将UE-B加入多方通话。
12～13.AS向UE-B发送INVITE消息，该INVITE消息中增加local-media头域，携带endpoint1对应的Context URL且不携带endpoint1的URL。其目的是防止P-CSCF2创建与endpoint1的关联关系，多方通话场景下的媒体端点之间的关联关系需要由AS创建。
14.UE-B对应的P-CSCF2接收INVITE消息，指示UMF创建第二媒体端点endpoint2。
15～16.UE-B向S-CSCF1发送200(INVITE)响应消息，该响应消息携带UE-B的媒体信息，包括UE-B的IP地址、端口号，编解码信息等。其中，P-CSCF1收到200(INVITE)响应消息后，补齐endpoint2的远端媒体信息为UE-B的媒体信息，同时增加local-media头域，携带endpoint2的URL。
17.AS接收200(INVITE)响应，并向UMF发送关联指示消息，指示UMF创建多方通话中所有媒体端点(当前只有UE-A加入多方通话，所以多方通话中的媒体端点只有endpoint1)与endpoint2的关联关系。
18～19.AS向P-CSCF1发送ACK消息，携带endpoint2的媒体信息，包括endpoint2的IP地址、端口号，编解码信息等。应注意，P-CSCF1收到ACK消息后不创建endpoint1与endpoint2的关联关系。
20.AS指示UMF停止向UE-B播放呼叫保持音。
21～22.AS向P-CSCF1发送NOTIFY消息，通知主叫REFER的订阅状态为terminated，消息体中携带SIP状态码：SIP/2.0 200OK，表示REFER关联的隐含订阅终结(即AS后续不再发送NOTIFY消息)。其中，SIP状态码“SIP/2.0 200OK”表示AS已经成功的将B加入多方通话。
23.AS向S-CSCF1发送BYE消息，释放UE-A和UE-B原有会话。
24.UE-A的P-CSCF1接收BYE消息，指示UMF释放UE-A和UE-B原有会话中申请的媒体端点。
25.P-CSCF1向UE-A发送BYE消息。
26～27.AS向UE-B发送BYE消息，释放UE-A和UE-B原有会话。
28.UE-B的P-CSCF2收到BYE消息，指示UMF释放UE-A和UE-B原有会话中申请的媒体端点，同时删除媒体关联关系。
应注意，后续流程还包括UE-A将新用户UE-C加入多方通话的步骤，具体实现方式与UE-A将UE-B加入多方通话的过程类似，区别点在于：
(1)UE-A发送的REFER消息中refer-to头域为C的号码，不携带replace参数。
(2)AS向UE-C发送INVITE消息时不携带replace头域。
(3)UE-A与UE-C之前建立会话，不需要向UE-A和UE-C发送BYE消息释放原会话。
假设UE-C在UMF上对应的媒体端点为endpoint3，则AS收到UE-C的200(INVITE)响应消息时，由于此时会议中已经存在endpoint1和endpoint2两个媒体端点，所以UMF需要同时创建endpoint1、endpoint2分别与endpoint3的关联关系。
为了实现上述本申请实施例提供的方法中的各功能，统一媒体处理网元、应用服务器、和接入媒体控制网元可以包括硬件结构和/或软件模块，以硬件结构、软件模块、或硬件结构加软件模块的形式来实现上述各功能。上述各功能中的某个功能以硬件结构、软件模块、还是硬件结构加软件模块的方式来执行，取决于技术方案的特定应用和设计约束条件。
本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，另外，在本申请各个实施例中的各功能模块可以集成在一个处理器中，也可以是单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。
如图13所示为本申请实施例提供的一种呼叫处理装置1300，用于实现上述方法实施例中统一媒体功能网元的功能。该装置可以是设备，也可以是设备中的装置，或者能够和设备匹配使用的装置。其中，该装置可以为芯片系统。本申请实施例中，芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。呼叫处理装置1300包括至少一个处理器1320，用于实现本申请实施例提供的呼叫处理方法中统一媒体功能网元的功能。示例性地，处理器1320可以将参与多方通话的终端设备中的任意一个终端设备的媒体数据，转发给参与多方通话的终端设备中除任意一个终端设备之外的其他一个或多个终端设备，以及执行其他的操作，具体参见方法示例中的详细描述，此处不做赘述。
装置1300还可以包括至少一个存储器1330，用于存储程序指令和/或数据。存储器1330和处理器1320耦合。本申请实施例中的耦合是装置、单元或模块之间的间接耦合或通信连接，可以是电性，机械或其它的形式，用于装置、单元或模块之间的信息交互。处理器1320可能和存储器1330协同操作。处理器1320可能执行存储器1330中存储的程序指令。所述至少一个存储器中的至少一个可以包括于处理器中。
装置1300还可以包括通信接口1310，该通信接口例如可以是收发器、接口、总线、电路或者能够实现收发功能的装置。其中，通信接口1310用于通过传输介质和其它设备进行通信，从而用于装置1300中的装置可以和其它设备进行通信。处理器1320利用通信接口1310收发数据，并用于实现图8至图12对应的实施例中所述的统一媒体功能网元所执行的方法，具体参见方法示例中的详细描述，此处不做赘述。
本申请实施例中不限定上述通信接口1310、处理器1320以及存储器1330之间的具体连接介质。本申请实施例在图13中以存储器1330、处理器1320以及通信接口1310之间通过总线1340连接，总线在图13中以粗线表示，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图13中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
如图14所示为本申请实施例提供的另一种呼叫处理装置1400，用于实现上述方法实施例中应用服务器的功能。该装置可以是设备，也可以是设备中的装置，或者能够和设备匹配使用的装置。其中，该装置可以为芯片系统。呼叫处理装置1400包括至少一个处理器1420，用于实现本申请实施例提供的方法中应用服务器的功能。示例性地，处理器1420可以向统一媒体功能网元发送多方通话连接请求消息，具体参见方法示例中的详细描述，此处不做赘述。
装置1400还可以包括至少一个存储器1430，用于存储程序指令和/或数据。存储器1430和处理器1420耦合。本申请实施例中的耦合是装置、单元或模块之间的间接耦合或通信连接，可以是电性，机械或其它的形式，用于装置、单元或模块之间的信息交互。处理器1420可能和存储器1430协同操作。处理器1420可能执行存储器1430中存储的程序指令。所述至少一个存储器中的至少一个可以包括于处理器中。
装置1400还可以包括通信接口1410，该通信接口例如可以是收发器、接口、总线、电路或者能够实现收发功能的装置。其中，通信接口1410用于通过传输介质和其它设备进行通信，从而用于装置1400中的装置可以和其它设备进行通信。处理器1420利用通信接口1410收发数据，并用于实现图8至图12对应的实施例中所述的应用服务器所执行的方法。
本申请实施例中不限定上述通信接口1410、处理器1420以及存储器1430之间的具体连接介质。本申请实施例在图14中以存储器1430、处理器1420以及通信接口1410之间通过总线1440连接，总线在图14中以粗线表示，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图14中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
如图15所示为本申请实施例提供的另一种呼叫处理装置1500，用于实现上述方法实施例中第一接入媒体控制网元/第二接入媒体控制网元的功能。该装置可以是设备，也可以是设备中的装置，或者能够和设备匹配使用的装置。其中，该装置可以为芯片系统。呼叫处理装置1500包括至少一个处理器1520，用于实现本申请实施例提供的方法中第一接入媒体控制网元/第二接入媒体控制网元的功能。示例性地，处理器1520可以向统一媒体功能网元发送第一媒体连接请求消息，具体参见方法示例中的详细描述，此处不做赘述。
装置1500还可以包括至少一个存储器1530，用于存储程序指令和/或数据。存储器1530和处理器1520耦合。本申请实施例中的耦合是装置、单元或模块之间的间接耦合或通信连接，可以是电性，机械或其它的形式，用于装置、单元或模块之间的信息交互。处理器1520可能和存储器1530协同操作。处理器1520可能执行存储器1530中存储的程序指令。所述至少一个存储器中的至少一个可以包括于处理器中。
装置1500还可以包括通信接口1510，该通信接口例如可以是收发器、接口、总线、电路或者能够实现收发功能的装置。其中，通信接口1510用于通过传输介质和其它设备进行通信，从而用于装置1500中的装置可以和其它设备进行通信。处理器1520利用通信接口1510收发数据，并用于实现图8至图12对应的实施例中所述的第一接入媒体控制网元/第二接入媒体控制网元所执行的方法。
本申请实施例中不限定上述通信接口1510、处理器1520以及存储器1530之间的具体连接介质。本申请实施例在图15中以存储器1530、处理器1520以及通信接口1510之间通过总线1540连接，总线在图15中以粗线表示，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图15中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
在本申请实施例中，处理器可以是通用处理器、数字信号处理器、专用集成电路、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。
在本申请实施例中，存储器可以是非易失性存储器，比如HDD或SSD等，还可以是volatile memory，例如RAM。存储器是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。本申请实施例中的存储器还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。
如图16所示为本申请实施例提供的另一种呼叫处理装置1600。该呼叫处理装置可以是统一媒体处理网元，也可以是统一媒体处理网元中的装置，或者是能够和统一媒体处理网元匹配使用的装置。一种设计中，该呼叫处理装置可以包括执行图8至图12对应的示例中所描述的方法/操作/步骤/动作所一一对应的模块，该模块可以是硬件电路，也可是软件，也可以是硬件电路结合软件实现。一种设计中，该装置可以包括通信模块1601和处理模块1602。示例性地，通信模块1601用于接收来自应用服务器的关联指示信息。处理模块1602用于根据关联指示信息，关联参与多方通话的终端设备中的任意一个终端设备的媒体端点，与参与多方通话的终端设备中除任意一个终端设备之外的其他一个或多个终端设备各自的媒体端点。具体参见图8至图12示例中的详细描述，此处不做赘述。
如图17所示为本申请实施例提供的另一种呼叫处理装置1700，该呼叫处理装置可以是应用服务器，也可以是应用服务器中的装置，或者是能够和应用服务器匹配使用的装置。一种设计中，该呼叫处理装置可以包括执行图8至图12对应的示例中所描述的方法/操作/步骤/动作所一一对应的模块，该模块可以是硬件电路，也可是软件，也可以是硬件电路结合软件实现。一种设计中，该装置可以包括通信模块1701和处理模块1702。示例性地，通信模块1701用于接收第一会话请求消息。处理模块1702用于指示统一媒体功能网元创建针对参与多方通话的终端设备的选择性转发单元。具体参见图8至图12示例中的详细描述，此处不做赘述。
如图18所示为本申请实施例提供的另一种呼叫处理装置1800，该呼叫处理装置可以是第一接入媒体控制网元/第二接入媒体控制网元，也可以是第一接入媒体控制网元/第二接入媒体控制网元中的装置，或者是能够和第一接入媒体控制网元/第二接入媒体控制网元匹配使用的装置。一种设计中，该呼叫处理装置可以包括执行图8至图12对应的示例中所描述的方法/操作/步骤/动作所一一对应的模块，该模块可以是硬件电路，也可是软件，也可以是硬件电路结合软件实现。一种设计中，该装置可以包括通信模块1801和处理模块1802。示例性地，通信模块1801用于向应用服务器发送第一会话请求消息。处理模块1802用于指示统一媒体功能网元创建第一媒体端点/第二媒体端点。具体参见图8至图12示例中的详细描述，此处不做赘述。
本申请实施例提供的技术方案可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、网络设备、终端设备或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机可以存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如，数字视频光盘(digital video disc，DVD))、或者半导体介质等。
在本申请实施例中，在无逻辑矛盾的前提下，各实施例之间可以相互引用，例如方法实施例之间的方法和/或术语可以相互引用，例如装置实施例之间的功能和/或术语可以相互引用，例如装置实施例和方法实施例之间的功能和/或术语可以相互引用。
显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (17)

1.一种呼叫处理方法，其特征在于，包括：
统一媒体功能网元接收来自应用服务器的多方通话连接请求消息，所述多方通话连接请求消息包括请求参与多方通话的终端设备的标识或者标识列表；
统一媒体功能网元接收来自参与多方通话的终端设备各自的媒体数据；所述参与多方通话的终端设备至少为三个终端设备；
所述统一媒体功能网元将所述参与多方通话的终端设备中的任意一个终端设备的媒体数据，转发给所述参与多方通话的终端设备中除所述任意一个终端设备之外的其他一个或多个终端设备。
2.根据权利要求1所述的方法，其特征在于，所述方法还包括：
所述统一媒体功能网元根据所述多方通话连接请求消息创建针对所述参与多方通话的终端设备各自的媒体端点；
所述统一媒体功能网元接收来自应用服务器的关联指示信息，并根据所述关联指示信息，关联所述参与多方通话的终端设备中的任意一个终端设备的媒体端点，与所述参与多方通话的终端设备中除所述任意一个终端设备之外的其他一个或多个终端设备各自的媒体端点。
3.根据权利要求1或2所述的方法，其特征在于，所述统一媒体功能网元将所述参与多方通话的终端设备中的任意一个终端设备的媒体数据，转发给所述参与多方通话的终端设备中除所述任意一个终端设备之外的其他一个或多个终端设备，包括：
所述统一媒体功能网元通过所述参与多方通话的终端设备中的任意一个终端设备的媒体端点，与所述参与多方通话的终端设备中除所述任意一个终端设备之外的其他一个或多个终端设备各自的媒体端点，之间的关联进行多流转发。
4.根据权利要求1至3任一项所述的方法，其特征在于，所述方法还包括：
所述统一媒体功能网元向所述应用服务器发送所述参与多方通话的终端设备各自的资源标识。
5.根据权利要求1至4任一项所述的方法，其特征在于，所述统一媒体功能网元接收来自应用服务器的多方通话连接请求消息之后，所述方法还包括：
所述统一媒体功能网元根据所述多方通话连接请求消息创建针对所述参与多方通话的终端设备的选择性转发单元，所述选择性转发单元用于进行多流转发。
6.根据权利要求5所述的方法，其特征在于，所述统一媒体功能网元将所述参与多方通话的终端设备中的任意一个终端设备的媒体数据，转发给所述参与多方通话的终端设备中除所述任意一个终端设备之外的其他一个或多个终端设备，包括：
所述统一媒体功能网元关联所述选择性转发单元与所述参与多方通话的终端设备各自的媒体端点；
所述统一媒体功能网元通过所述参与多方通话的终端设备中的任意一个终端设备的媒体端点与所述选择性转发单元之间的关联，以及所述选择性转发单元与所述参与多方通话的终端设备中除所述任意一个终端设备之外的其他一个或多个终端设备各自的媒体端点之间的关联，进行多流转发。
7.一种呼叫处理方法，其特征在于，包括：
应用服务器接收第一会话请求消息，所述第一会话请求消息用于指示所述应用服务器创建多方通话；
所述应用服务器向统一媒体功能网元发送多方通话连接请求消息，所述多方通话连接请求消息包括参与多方通话的终端设备的标识或者标识列表，所述多方通话连接请求消息用于请求所述统一媒体功能网元将所述参与多方通话的终端设备中的任意一个终端设备的媒体数据，转发给所述参与多方通话的终端设备中除所述任意一个终端设备之外的其他一个或多个终端设备。
8.根据权利要求7所述的方法，其特征在于，所述方法还包括：
所述应用服务器向所述统一媒体功能网元发送关联指示信息，所述关联指示信息用于指示所述统一媒体功能网元关联所述参与多方通话的终端设备中的任意一个终端设备的媒体端点，与所述参与多方通话的终端设备中除所述任意一个终端设备之外的其他一个或多个终端设备各自的媒体端点。
9.根据权利要求7或8所述的方法，其特征在于，所述多方通话连接请求消息还用于指示所述统一媒体功能网元创建针对所述参与多方通话的终端设备的选择性转发单元，所述选择性转发单元与所述参与多方通话的终端设备各自的媒体端点相关联，所述选择性转发单元与所述参与多方通话的终端设备各自的媒体端点之间的关联关系用于进行多流转发。
10.根据权利要求7至9任一项所述的方法，其特征在于，所述方法还包括：
所述应用服务器接收来自所述统一媒体功能网元的所述参与多方通话的终端设备的资源标识。
11.一种呼叫处理方法，其特征在于，包括：
第一接入媒体控制网元向应用服务器发送第一会话请求消息，所述第一会话请求消息用于指示所述应用服务器创建多方通话；
所述第一接入媒体控制网元接收来自应用服务器的第一会话响应消息，所述第一会话响应消息包括所述第一终端设备的资源标识和多方通话的资源标识，所述第一终端设备为发起多方通话的终端设备。
12.根据权利要求11所述的方法，其特征在于，所述方法还包括：
所述第一接入媒体控制网元向所述应用服务器发送第二会话请求消息，所述第二会话请求消息用于指示所述应用服务器将所述参与多方通话的终端设备中除所述第一终端设备之外的其他一个或多个终端设备加入多方通话。
13.一种呼叫处理方法，其特征在于，包括：
第二接入媒体控制网元接收第二会话请求消息；
所述第二接入媒体控制网元接收发送第二会话响应消息，所述第二会话响应消息包括第二终端设备的媒体信息和第二媒体端点的资源标识，所述第二终端设备为参与多方通话的终端设备，所述第二媒体端点为统一媒体功能网元针对所述第二终端设备创建的媒体端点。
14.根据权利要求13所述的方法，其特征在于，所述方法还包括：
所述第二接入媒体控制网元向所述统一媒体功能网元发送媒体更新指示消息，所述媒体更新指示消息用于指示所述统一媒体功能网元将所述第二媒体端点的远端媒体信息更新为所述第二终端设备的媒体信息。
15.一种呼叫处理装置，其特征在于，用于实现如权利要求1至14中任一项所述的方法。
16.一种呼叫处理装置，包括处理器和存储器，所述存储器和所述处理器耦合，所述处理器用于执行权利要求1至14中任一项所述的方法。
17.一种计算机可读存储介质，包括指令，当其在计算机上运行时，使得计算机执行权利要求1至14中任一项所述的方法。
CN202110929156.8A 2021-08-13 2021-08-13 一种呼叫处理方法、装置及系统 Pending CN115914176A (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN202110929156.8A CN115914176A (zh) 2021-08-13 2021-08-13 一种呼叫处理方法、装置及系统
PCT/CN2022/105366 WO2023016172A1 (zh) 2021-08-13 2022-07-13 一种呼叫处理方法、装置及系统
EP22855155.2A EP4351102A1 (en) 2021-08-13 2022-07-13 Call processing method, apparatus and system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110929156.8A CN115914176A (zh) 2021-08-13 2021-08-13 一种呼叫处理方法、装置及系统

Publications (1)

Publication Number Publication Date
CN115914176A true CN115914176A (zh) 2023-04-04

Family

ID=85200538

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110929156.8A Pending CN115914176A (zh) 2021-08-13 2021-08-13 一种呼叫处理方法、装置及系统

Country Status (3)

Country Link
EP (1) EP4351102A1 (zh)
CN (1) CN115914176A (zh)
WO (1) WO2023016172A1 (zh)

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101990267B (zh) * 2009-08-04 2013-06-05 中兴通讯股份有限公司 一种多方通话业务连续性的实现方法
CN101998568B (zh) * 2009-08-14 2013-08-07 中兴通讯股份有限公司 一种多会话业务连续性的实现方法
US9641557B2 (en) * 2009-12-08 2017-05-02 Alcatel Lucent Method for joining SIP communication devices into an existing call
CN102348291B (zh) * 2010-07-28 2016-02-10 中兴通讯股份有限公司 基于对话关联标识的会话建立方法及系统
CN106161357B (zh) * 2015-04-02 2019-12-13 中兴通讯股份有限公司 Ims网络中实现合法监听的方法、装置及应用服务器
US20180084100A1 (en) * 2016-09-19 2018-03-22 T-Mobile Usa, Inc. Multi-party emergency calls
CN108616496A (zh) * 2017-01-24 2018-10-02 展讯通信（上海）有限公司 多方通话的实现方法、装置、多通终端及网络侧设备

Also Published As

Publication number Publication date
EP4351102A1 (en) 2024-04-10
WO2023016172A1 (zh) 2023-02-16

Similar Documents

Publication Publication Date Title
US9106716B2 (en) Method, apparatus, and system for cross-platform conference convergence
US7898990B2 (en) Method, system and gateway device for enabling interworking between IP and CS networks
KR101185669B1 (ko) 인터넷 프로토콜 멀티미디어 서브시스템 기반 3자간 통화를 위한 방법 및 장치
JP4865803B2 (ja) ＰｏＣシステムにおけるアドホックＰｏＣセッション開設のための方法、端末装置、及びそのシステム
JP5529129B2 (ja) 電気通信ネットワーク内の媒体属性に基づく選択的な呼転送のための方法およびシステム
US20060116150A1 (en) Push-to-talk apparatus and method for communication between an application server and media resource function processor
US20060256748A1 (en) System and method for interworking between IMS network and H.323 network
CN101884205B (zh) Ims集中式服务中i1-ps信令的动态发起
US20080285487A1 (en) Method and system for providing full duplex services over multiple simplex media paths and sessions
CN101674305B (zh) 一种多媒体会议的实现方法及系统
JP2012010416A (ja) 事前設定セッションを管理する方法及びそれを実現するためのＰｏＣシステム及びＰｏＣ端末装置
US20110116495A1 (en) Method and apparatus for inter-device session transfer between internet protocol (ip) multimedia subsystem (ims) and h.323 based clients
US20150295974A1 (en) Method, User Equipment and Application Server for Adding Media Stream of Multimedia Session
WO2015127793A1 (zh) 录音方法、语音交换设备、录音服务器及录音系统
US20090047938A1 (en) Media Handling for Multimedia Conferencing in Multihop Cellular Networks
WO2007095855A1 (fr) Procédé et entité réseau de négociation d'un paramètre de type média
US8495225B2 (en) Methods and arrangements for a telecommunications system
WO2023016172A1 (zh) 一种呼叫处理方法、装置及系统
WO2009121310A1 (zh) 一种网关选择的方法、系统及设备
CN102111386B (zh) 一种早期媒体的实现方法和装置
WO2023016177A1 (zh) 一种呼叫处理方法、装置及系统
CN101330640B (zh) 一种ip多媒体子系统集中业务呼叫保持业务的实现方法
CN118158200A (zh) 通信方法、装置和系统
KR101451111B1 (ko) 영상 회의 서비스를 제공하는 방법 및 장치
WO2013057547A1 (en) Communication methods providing media content stream selection and related system

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