CN118413517A

CN118413517A - Multiparty call method, device, terminal and storage medium

Info

Publication number: CN118413517A
Application number: CN202410456837.0A
Authority: CN
Inventors: 周哲; 黎明雪
Original assignee: China Telecom Technology Innovation Center; China Telecom Corp Ltd
Current assignee: China Telecom Technology Innovation Center; China Telecom Corp Ltd
Priority date: 2024-04-16
Filing date: 2024-04-16
Publication date: 2024-07-30

Abstract

The present application relates to the field of communications technologies, and in particular, to a method, an apparatus, a terminal, and a storage medium for multiparty call. The method comprises the following steps: before the multiparty call is initiated, a subscription request of the multiparty call MPTY service is sent to an access and mobility management function AMF network element corresponding to a calling party; the multi-party communication MPTY service comprises at least one of a voice transmission service, a video transmission service and a file transmission service; under the condition that a subscription success message returned by an AMF network element of a calling party is received, a session initiation protocol invite message SIP INVITE is sent to a proxy call session control function (P-CSCF) network element of the calling party, so that a multimedia telephony application server (MMTel AS) of the calling party is triggered by the P-CSCF network element of the calling party, and a called network is accessed through the multimedia telephony application server (MMTel AS) of the calling party.

Description

Multiparty call method, device, terminal and storage medium

Technical Field

The present application relates to the field of communications technologies, and in particular, to a method, an apparatus, a terminal, and a storage medium for multiparty call.

Background

The multiparty call service (Multi Party) is a voice call service initiated by a chairman user to realize real-time online communication of multiple users in different places.

The multiparty call breaks through the traditional one-to-one call mode, realizes the many-to-many simultaneous call mode, and is mainly applied to business meetings and typical implementation modes such as teleconferences.

However, the data types of the multi-party call include only voice data, so that the diversity is poor, and improvement is needed.

Disclosure of Invention

In view of the foregoing, it is desirable to provide a multiparty call method, apparatus, terminal, and storage medium capable of optimizing the diversity of multiparty calls.

In a first aspect, the present application provides a multiparty call method performed by a calling party, the method comprising:

before the multiparty call is initiated, a subscription request of the multiparty call MPTY service is sent to an access and mobility management function AMF network element corresponding to a calling party; the multi-party communication MPTY service comprises at least one of a voice transmission service, a video transmission service and a file transmission service;

Under the condition that a subscription success message returned by an AMF network element of a calling party is received, a session initiation protocol invite message SIP INVITE is sent to a proxy call session control function (P-CSCF) network element of the calling party, so that a multimedia telephony application server (MMTel AS) of the calling party is triggered by the P-CSCF network element of the calling party, and a called network is accessed through the multimedia telephony application server (MMTel AS) of the calling party.

In one embodiment, the session initiation protocol invite (sip invite) message SIP INVITE is used to instruct the proxy call session control function P-CSCF network element of the calling party to send a response authentication request AAR message to the policy control function PCF network element of the calling party; the response authentication request AAR message comprises user IP of a calling party, media component information and local application function AF application identification information;

The answer authentication request AAR message is used for indicating a policy control function PCF network element of the calling party to request voice service quality QoS flow resources to a next generation base station gNodeB and a user plane function UPF network element of the calling party respectively through a session management function SMF network element of the calling party, and reporting position reporting information of the policy control function PCF network element of the calling party to a proxy call session control function P-CSCF network element of the calling party;

The location report information is used to trigger the proxy call session control function P-CSCF network element of the calling party to forward the session initiation protocol invite message SIP INVITE to the service session control function S-CSCF network element of the calling party, so that the service session control function S-CSCF network element of the calling party triggers the multimedia telephony application server MMTel AS of the calling party.

In one embodiment, the Media component information includes a Media Type Media-Type parameter, a Flow Description Flow-Description parameter, and a Flow Status Flow-Status parameter.

In one embodiment, voice data corresponding to a voice transmission service is transmitted by a voice channel, video data corresponding to a video transmission service is transmitted by a video channel, and file data corresponding to a file transmission service is transmitted by a file channel.

In one embodiment, the method further comprises: in the process of maintaining the multiparty call, transmitting the IMS data of the Internet protocol multimedia subsystem to a MMTel AS of a calling party through a UPF network element of the user plane function of the calling party;

The internet protocol multimedia subsystem IMS data is used for triggering a user plane function UPF network element of the calling party and a multimedia telephony application server MMTel AS of the calling party to confirm a quality of service QoS parameter and a channel type in the internet protocol multimedia subsystem IMS data, and in case that the confirmation passes, the internet protocol multimedia subsystem IMS data is transmitted to the multimedia telephony application servers MMTel AS of other calling parties in the multi-party call in a multicast manner through the multimedia telephony application server MMETel AS of the calling party.

In a second aspect, the present application also provides a multiparty call device, which comprises:

The initiation module is used for sending a subscription request of the multi-party call MPTY service to an access and mobile management function AMF network element corresponding to the calling party before initiating the multi-party call; the multi-party communication MPTY service comprises at least one of a voice transmission service, a video transmission service and a file transmission service;

And the triggering module is used for sending a session initiation protocol invite message SIP INVITE to a proxy call session control function (P-CSCF) network element of the calling party under the condition that a subscription success message returned by the AMF network element of the calling party is received, so AS to trigger a multimedia telephone application server (MMTel AS) of the calling party through the P-CSCF network element of the calling party and access a called network through the multimedia telephone application server (MMTel AS) of the calling party.

In a third aspect, the present application provides a multiparty call method executed by a called party, the method comprising:

Under the condition of receiving the session initiation protocol invite (SIP) message SIP INVITE, subscribing the MPTY service of the multiparty call to an access and mobility management function (AMF) network element of a called party; the multi-party communication MPTY service comprises at least one of a voice transmission service, a video transmission service and a file transmission service;

under the condition that the subscription of the MPTY service of the multiparty call is completed, the SIP is sent: 183 message to the proxy call session control function P-CSCF network element of the called party to trigger the multimedia telephony application server MMTel AS of the called party by the P-CSCF network element of the called party and to send SIP via the S-CSCF network element of the called party: 183 message goes to the calling network to complete the called.

In a fourth aspect, the present application provides a multiparty call device, comprising:

The receiving module is used for subscribing the MPTY service of the multiparty call to the AMF network element of the access and mobile management function of the called party under the condition of receiving the session initiation protocol invite message SIP INVITE;

The access module is used for sending the SIP when the subscription of the MPTY service of the multiparty call is completed: 183 message to the proxy call session control function P-CSCF network element of the called party to trigger the multimedia telephony application server MMTel AS of the called party by the P-CSCF network element of the called party and to send SIP via the S-CSCF network element of the called party: 183 message goes to the calling network to complete the called.

In a fifth aspect, the present application also provides a computer device comprising a memory and a processor, the memory storing a computer program, the processor executing the computer program to perform the steps of:

In a sixth aspect, the present application also provides a computer readable storage medium having stored thereon a computer program which when executed by a processor performs the steps of:

In a seventh aspect, the present application also provides a computer program product comprising a computer program which, when executed by a processor, performs the steps of:

In an eighth aspect, the present application also provides a computer device comprising a memory and a processor, the memory storing a computer program, the processor executing the computer program to perform the steps of:

In a ninth aspect, the present application also provides a computer readable storage medium having stored thereon a computer program which when executed by a processor performs the steps of:

In a tenth aspect, the application also provides a computer program product comprising a computer program which, when executed by a processor, performs the steps of:

According to the multiparty call method, the device, the terminal and the storage medium, the transmission data are divided into different channels, so that various data types in multiparty calls can be managed and controlled more finely, subscription services corresponding to various types of data are added, different service functions can be selected and used by a user according to actual requirements, the service quality of multiparty calls is improved, and more diversified and personalized communication experience is provided for the user.

Drawings

FIG. 1 is a flow chart of a method of multi-party communication in one embodiment;

FIG. 2 is a flow chart of a method for multi-party communication according to another embodiment;

FIG. 3 is a flow chart of a method for multi-party communication according to another embodiment;

FIG. 4 is a block diagram of a multi-party communications device in one embodiment;

FIG. 5 is a block diagram of a multi-party communications device according to another embodiment;

FIG. 6 is an internal block diagram of a terminal in one embodiment;

Fig. 7 is an internal structural view of a terminal in another embodiment.

Detailed Description

The present application will be described in further detail with reference to the drawings and examples, in order to make the objects, technical solutions and advantages of the present application more apparent. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the application.

In one embodiment, as shown in fig. 1, a multiparty call method is provided, which is illustrated by taking the application of the method to a calling party terminal (calling UE), and includes the following steps:

S101, before the multiparty call is initiated, a subscription request of the multiparty call MPTY service is sent to an access and mobile management function AMF network element corresponding to a calling party.

It will be appreciated that the calling UE or related application/service will initiate a request for MPTY service. This request may contain specific parameters of the multiparty call, such as the number of parties expected, the call quality requirements, etc. And sending a subscription request of the MPTY service to an AMF network element corresponding to the calling party. The purpose of this subscription request is to inform the AMF network element that it is ready to support the multiparty call service, requiring some pre-processing or resource reservation by the AMF network element.

Further, after receiving the subscription request, the AMF network element performs necessary processing and returns a response. This response may include information as to whether the subscription was successful, whether additional configuration or adjustment is required, etc. Once the subscription is successful and the AMF network element is acknowledged, the establishment of the multiparty call can begin. The process of establishing a multiparty call may involve calling other parties, establishing a call connection, managing a call state, etc.

The multi-party communication MPTY service comprises at least one of a voice transmission service, a video transmission service and a file transmission service.

It can be appreciated that voice transmission service is the most basic and common function in multiparty call, which allows multiple users to communicate voice at the same time, and is suitable for conference, group discussion, and other scenarios. Through voice transmission, participants can hear the speech of other people in real time and interact.

The video transmission service is a more advanced function in the multiparty call, and supports the transmission of video pictures in addition to voice communication. The multi-party call is more visual and vivid, and can be applied to occasions needing visual communication such as teleconferences, online education and the like.

File transfer services are also an important component in multiparty calls. The method allows the participants to transmit files, such as documents, pictures, videos and the like, in the conversation process, so that information and data can be shared more conveniently. Correspondingly, in the embodiment, a data channel of the multiparty call is added, and the transmission data in the multiparty call is divided into 3 channels: voice channels, video channels, and file channels.

Wherein each channel has a corresponding QoS parameter and channel type parameter.

Wherein, the QoS parameter prescribes the bandwidth, delay and transmission priority when the channel transmits data; the channel type parameter specifies the type of data transmitted by the channel, and data in the channel can be normally transmitted only when the data type is matched with the channel type.

In particular, the voice channel, the video channel, and the file channel are each responsible for transmitting corresponding types of data. The division of labor not only avoids mutual interference of different types of data in the transmission process, but also can carry out targeted optimization according to the characteristics of each data type. For example, voice data has high real-time requirements, so the QoS parameters of the voice channel can be set to a low delay and a high transmission priority; video data may be more bandwidth and stability intensive, and thus QoS parameters of the video channels may be adjusted accordingly.

At the same time, the setting of the channel type parameter ensures that only data matching the channel type can be transmitted in the channel. The mechanism effectively prevents the mistransmission and the misplacement of data and improves the accuracy and the reliability of communication. In addition, by defining the channel type, the management and maintenance of each channel can be conveniently carried out, such as monitoring the load condition of the channel, adjusting the resource allocation of the channel, and the like.

Optionally, the calling party terminal (calling party UE) sends a subscription request of the multi-party communication MPTY service to an access and mobility management function AMF network element corresponding to the calling party, which includes the following 1.1-1.4:

1.1, a calling UE sends a subscription request message to an access and mobility management function AMF network element of a calling party, wherein the message contains a UE ID and an MPTY service subscription request.

Wherein, the calling UE initiates a subscription flow first, and indicates that the calling UE wants to use MPTY service by sending a subscription request message to the AMF network element. The message contains an identifier (UE ID) of the UE, so that the AMF network element can identify the source of the request, and the MPTY service subscription request itself, which explicitly expresses the subscription intention of the calling UE.

1.2, The access and mobile management function AMF network element of the calling party replies the calling UE, and the MPTY service subscription of the calling party UE is successful.

After receiving the subscription request, the AMF network element performs authentication and processing. If the authentication is passed and the AMF network element is able to support the subscription request, it will send a reply message to the calling UE informing that the MPTY service subscription has been successful. This reply message is an acknowledgement to the calling UE that it can now initiate or participate in the multiparty call.

1.3, After successful service subscription, the calling party AMF network element sends a subscription report to the calling party localization unified data management UDM network element, and the message indicates that the calling party contains the UE ID and subscribed MPTY service.

After the subscription is successful, the AMF network element not only interacts with the calling UE, but also needs to inform other related components in the network, and the AMF network element can send a subscription report to the UDM network element. The report contains the UE ID and the subscribed MPTY service information, so that the UDM network element can update the record in the database, and the network side can accurately know the service subscription state of the calling UE.

1.4, The UMD network element of the calling party updates the business subscribed by the calling UE and sends a subscription information management reply to the AMF network element to indicate that the subscription information of the calling UE is updated.

After receiving the subscription report, the UDM network element updates the subscription record in its database according to the information in the report. After the update is completed, the UDM network element sends a subscription information management reply to the AMF network element, informing the AMF network element that the subscription information has been updated. The reply ensures the information synchronization between the AMF network element and the UDM network element, and provides data support for the subsequent multiparty call service.

S102, under the condition of receiving the subscription success message returned by the AMF network element of the calling party, a session initiation protocol invite message SIP INVITE is sent to the proxy call session control function P-CSCF network element of the calling party.

It is understood that SIP (Session Initiation Protocol) is a communication protocol for setting up, modifying and terminating multimedia sessions, such as voice and video calls, over IP networks. In the scenario of this embodiment, SIP INVITE messages are used to inform the P-CSCF network element that the calling party wishes to initiate a multiparty call session.

The P-CSCF network element is an important component in the SIP network, which acts as an interface between the User Equipment (UE) and the SIP core network, responsible for handling SIP messages and routing them to the correct destination when required. In the scenario of multiparty call services, the P-CSCF network element receives SIP INVITE the message and performs further processing according to the network configuration and policies. In particular, the P-CSCF network element may perform the following operations:

1. Verifying SIP INVITE the validity of the message, including checking the format, signature, authorization, etc. of the message.

2. Based on the network policy, the next routing or processing logic is determined. In particular may involve forwarding the message to other SIP network entities, such AS a serving call session control function S-CSCF or an application server AS, or performing some pre-processing operations.

3. The P-CSCF may also interact with other network functions, such as UDM or AMF, to obtain or update user information or status related to the session, if desired.

Once the P-CSCF has completed processing SIP INVITE the message, it will take appropriate action based on the processing results, which may include, in particular, forwarding the message to other network entities, setting up a session or returning a response to the calling party UE.

Optionally, the multimedia telephone application server MMTel AS of the calling party is triggered by the P-CSCF network element of the calling party, and the called network is accessed through the MMTel AS of the calling party.

It will be appreciated that when the calling party initiates a multiparty call request, a SIP INVITE message is sent first to the P-CSCF network element. The P-CSCF network element acts as an entry point for SIP signaling, is responsible for handling these SIP messages and decides the next operation according to network configuration and policies.

In this procedure, the P-CSCF network element recognizes that the SIP message is related to a multiparty call service and triggers the MMTel AS of the calling party. The MMTel AS is an application server that provides related functions of multimedia telephony services including call control, media processing, service logic execution, etc. By triggering the MMTel AS, the calling party can establish and manage the multiparty call using the service logic and functions on the server.

Once triggered, the MMTel AS may intervene in the SIP signaling procedure, interact with the P-CSCF network element, and may communicate with other network entities (e.g., the P-CSCF network element or application server of the called party). The MMTel AS performs corresponding operations, such AS determining routing information of the called party, establishing a media channel, handling call state, etc., according to the service requirements and policies. Finally, through the intervention of MMTel AS, the calling party can successfully access the called network and establish multiparty call connection with the called party. The access mode enables the multi-party call service to cross different network domains and realize communication among different users.

In the multiparty call method, the transmission data are divided into different channels, so that various data types in multiparty calls can be managed and controlled more finely, subscription services corresponding to various types of data are added, different service functions can be selected and used by a user according to actual requirements, the service quality of the multiparty calls is improved, and more diversified and personalized communication experience is provided for the user.

In one embodiment, the session initiation protocol invite (sip invite) message SIP INVITE is used to instruct the proxy call session control function (P-CSCF) network element of the calling party to send a reply authentication request (AAR) message to the Policy Control Function (PCF) network element of the calling party.

Specifically, when the calling party initiates a multiparty call, SIP INVITE messages are sent to the P-CSCF network element. After receiving SIP INVITE, the P-CSCF network element sends an AAR message to the PCF network element according to the specific logic in this embodiment, in addition to performing the conventional session establishment procedure.

The AAR message comprises user IP of the calling party, media component information and local application function AF application identification information.

It will be appreciated that AAR messages are a key message in Policy and Charging Control (PCC) architecture for exchanging policy control and charging related information between a Policy Enforcement Function (PEF) and a Policy Decision Function (PDF). In the scenario of this embodiment, the P-CSCF network element acts as PEF, requesting policy decisions from the PCF network element (as PDF) by sending AAR messages.

In this embodiment, the AAR message contains rich information, so that the PCF network element can make an accurate policy decision. Such information includes the caller's user IP address, which is used to identify the caller's location in the network; media component information describing specific parameters and configurations of voice, video, or file channels used in the multiparty call; and local Application Function (AF) application identification information identifying the specific application or service that triggered the multiparty call. By including these information, the AAR message helps the PCF network element to learn about the context and specific needs of the multiparty call, so that an appropriate policy can be formulated to control the session establishment, resource allocation, and billing. The method is beneficial to ensuring the quality and the safety of multiparty call service, and simultaneously provides more refined service management and charging means for operators.

The answer authentication request AAR message is used to instruct the policy control function PCF network element of the calling party to request the voice service quality QoS flow resource to the next generation base station gNodeB and the user plane function UPF network element of the calling party through the session management function SMF network element of the calling party, and report the position report information of the policy control function PCF network element of the calling party to the proxy call session control function P-CSCF network element of the calling party.

Specifically, after the P-CSCF element receives the SIP INVITE message and triggers the AAR message to be sent to a Policy Control Function (PCF) element of the calling party, the AAR message instructs the PCF element to perform a series of operations: firstly, the PCF network element requests voice quality of service (QoS) flow resources from a next generation base station (gNodeB) and a User Plane Function (UPF) network element, respectively, through a Session Management Function (SMF) network element of the calling party. QoS flow resources are key to ensuring voice transmission quality in multiparty calls. Through coordination of the SMF network elements, the PCF network elements can request gNodeB to provide sufficient radio resources for voice transmission, while requesting the UPF network elements to provide appropriate forwarding and processing capabilities for voice traffic. Thus, the voice data can be ensured to be processed preferentially in the transmission process, so that the conversation quality is improved.

In addition, the AAR message also indicates the PCF network element to report the position report information to the P-CSCF network element. The location reporting information is of great significance to network management and troubleshooting. By reporting the position information, the P-CSCF network element can know the specific position of the PCF network element in the network, thereby being convenient for network optimization and fault location.

The location report information is used for triggering the proxy call session control function P-CSCF network element of the calling party to forward the session initiation protocol invite message SIP INVITE to the service session control function S-CSCF network element of the calling party, so that the service session control function S-CSCF network element of the calling party triggers the multimedia telephony application server MMTel AS of the calling party.

Specifically, when a Policy Control Function (PCF) network element of a calling party reports its location information to a proxy call session control function (P-CSCF) network element through an AAR message, the P-CSCF network element performs a specific operation according to this information. Specifically, the location reporting information triggers the P-CSCF network element to forward the session initiation protocol invite message (SIP INVITE) to the serving session control function (S-CSCF) network element.

CSCF network elements are core components in the IP Multimedia Subsystem (IMS) responsible for handling and controlling multimedia sessions. In the multiparty call scene, the S-CSCF network element is responsible for the routing and control of the session, so that the session can be correctly established and smoothly carried out. Therefore, forwarding SIP INVITE messages to the S-CSCF network element is a key step in setting up a multiparty call session.

Once the S-CSCF network element receives SIP INVITE the message, it triggers the calling party' S multimedia telephony application server (MMTel AS) based on the information in the message and the network policy. Therefore, the location reporting information in this embodiment acts AS a bridge, which connects the interaction between the PCF network element and the S-CSCF network element and indirectly triggers the intervention of the MMTel AS. The design not only enhances the flexibility and the expandability of the multiparty call service, but also improves the reliability and the efficiency of the service. By optimizing the network control and session management flows, operators can provide users with a better multiparty call experience.

Optionally, the calling procedure of the multiparty session provided in this embodiment includes 2.1-2.5:

2.1, the calling party UE initiates a call, sends SIP INVITE a message to the calling party P-CSCF, the message containing the proposed multi-party session type description.

The calling party UE (user equipment) first initiates a call by sending a session initiation protocol invite message (SIP INVITE) to the proxy call session control function (P-CSCF) of the calling party. This SIP INVITE message contains a proposed multiparty session type description, i.e. the specific type and parameters of the multiparty call that the calling party wishes to establish.

2.2, After the P-CSCF of the calling party receives SIP INVITE messages, the P-CSCF of the calling party sends AAR (Authorization Authentication Request) messages to the PCF network element of the calling party, and the AAR messages carry information such as user IP, media component information, AF application identifiers and the like and apply for conversation resources; after receiving the AAR message, the calling P-CSCF triggers an AAA (Authentication, authorization and Accounting) procedure from the calling P-CSCF to the calling PCF network element.

When the calling party's P-CSCF receives SIP INVITE the message, it sends a reply authentication request (AAR) message to the calling party's Policy Control Function (PCF) network element based on the message content. The AAR message carries key information such as user IP, media component information, application Function (AF) application identifier and the like, and is used for applying for resources required by communication. Meanwhile, after sending the AAR message, the P-CSCF triggers an authentication, authorization and accounting (AAA) process with the PCF network element to ensure that the identity and authority of the calling party are verified and corresponding resources are allocated to the calling party.

2.3, The PCF network element of the calling party indicates the SMF of the calling party to request voice QoS flow resources from gNB and UPF respectively.

After receiving the AAR message, the PCF network element of the calling party instructs, according to the information therein, the Session Management Function (SMF) network element to request voice quality of service (QoS) flow resources from the next generation base station (gNB) and the User Plane Function (UPF), respectively. This step is to ensure that the voice transmission in the multiparty call can get enough network resources and priority handling, thereby improving the call quality.

And 2.4, the P-CSCF network element of the calling party receives the position report information of the PCF network element of the calling party.

After the resource request is completed, the PCF network element of the calling party sends position report information to the P-CSCF network element. This location information may help the P-CSCF to know the specific location of the PCF in the network for better subsequent network control and session management.

And 2.5, the P-CSCF network element of the calling party processes the position information and forwards SIP INVITE information to the S-CSCF of the calling party, and the S-CSCF of the calling party triggers the responding MMTel AS of the calling party and is connected to the called network.

After receiving the position report information, the P-CSCF network element of the calling party processes the position report information and forwards the original SIP INVITE message to a service session control function (S-CSCF) network element. The S-CSCF is responsible for controlling and managing multimedia sessions as a core component in the IP Multimedia Subsystem (IMS). After receiving SIP INVITE the S-CSCF message, it can trigger the correspondent multimedia telephone application server (MMTel AS) to process the multiparty call service logic, and make it connect to the called network so AS to implement the establishment process of multiparty session.

Wherein the Media component information includes a Media Type Media-Type parameter, a Flow Description Flow-Description parameter, and a Flow Status Flow-Status parameter.

It is understood that the media type parameters are used to identify and describe the format and manner in which the media data is encoded. For example, it may be "audio/MPEG" representing MPEG encoded audio data, or "video/MP4" representing MP4 encoded video data. In CSS, the media type (MEDIA TYPE) belongs to the specification of CSS2 for setting different styles for different devices to optimize the export effect. In this way, the developer can provide different style rules for different devices (e.g., screen, printer, etc.), ensuring that the content is optimally presented on a variety of devices. In internet protocols such as HTTP, media types are also used as data formats to identify transmissions, ensuring that the recipient can properly parse and process the data.

The flow description parameters define packet filters of the IP data flow for identifying and managing data packets of the media flow. In multiparty calls, different media streams (e.g., audio streams, video streams, etc.) need to be handled and controlled separately, and the stream description parameters provide such capabilities. It typically contains a set of parameters for the packet header that identify the particular packet flow, ensuring that only satisfactory packets are allowed to pass through and into the corresponding process flow. In some network architectures, flow description parameters may also be associated with concepts such as a service data Flow Filter (SERVICE DATA Flow Filter) and a service data Flow Template (SERVICE DATA Flow Template), which together enable fine control and management of data packets.

The stream state parameters are used to describe the current state of the media stream, such as active, suspended, disconnected, etc. This helps the network entity to know the real-time status of the media stream for corresponding resource adjustment and control. For example, when a certain media stream is paused, the network may release part of the resources for use by other media streams; when the media stream is resumed, the network then needs to reallocate resources to ensure smooth transport of the stream. The flow state parameters may also be used to implement some advanced functions such as traffic shaping, congestion control, etc. to optimize network performance and user experience.

Further, voice data corresponding to the voice transmission service is transmitted by the voice channel, video data corresponding to the video transmission service is transmitted by the video channel, and file data corresponding to the file transmission service is transmitted by the file channel.

It will be appreciated that in a multiparty conversation scenario, different transport traffic types typically correspond to different data channels to ensure that the data for each service is processed efficiently, safely and reliably. The voice transmission service, the video transmission service and the file transmission service respectively use the respective special channels for data transmission, and the design greatly improves the network efficiency and the service quality.

For voice transmission services, voice data is transmitted over dedicated voice channels. Such channels are typically optimized to support real-time, low-latency voice communications. The characteristics of the voice channel enable the voice channel to process the encoding, decoding and transmission of voice signals, so that the voice quality is clear and the communication process is smooth.

Video transmission services rely on video channels to transmit video data. The design of the video channel takes into account the particularities of the video data such as a large amount of data, high sensitivity to delay, etc. Thus, video channels typically have higher bandwidth and more processing power to ensure smooth transmission and high quality presentation of video data.

And the file transmission service performs data transmission through the file channel. File channels typically have a large bandwidth and high stability to support fast, reliable transfer of large files. In addition, the file channel can also provide functions such as encryption and verification, etc. so as to ensure the security and the integrity of file transmission.

By distributing different transmission services to respective dedicated channels, the network can more efficiently manage resources, optimize performance, and meet the requirements of different service types. The design not only improves the overall efficiency of the network, but also improves the user experience, so that the voice, video and file transmission in the multiparty session can be well represented.

In this embodiment, the above-mentioned channelized design is also convenient for the operators to perform network management and troubleshooting. When a problem occurs, an operator can quickly locate a specific channel and take corresponding measures to repair and optimize.

In one embodiment, in the process of maintaining the multiparty call, the internet protocol multimedia subsystem IMS data is transmitted to the multimedia telephony application server MMTel AS of the calling party through the user plane function UPF network element of the calling party.

It will be appreciated that the UPF network element, as part of the user plane function, is primarily responsible for handling forwarding and routing of user data packets. In a multiparty call scenario, when a calling party communicates with other parties, a lot of IMS data is generated, including voice, video, signaling, etc. These data need to be efficiently and accurately transmitted through the UPF network element to ensure smooth progress of the call.

Specifically, in the process of maintaining the multiparty call, the UPF network element processes IMS data according to the network policy and the indication of the control function (PCF). It performs the necessary encapsulation and decapsulation operations on the data packets to ensure that the data is properly transferred between the different network domains. Meanwhile, the UPF network element also carries out flow shaping and congestion control on the data packet according to the network state and the load condition so as to optimize the network performance and the user experience.

Once the IMS data has been processed by the UPF network element, they will be forwarded to the MMTel AS of the calling party. The MMTel AS is used AS an application server of the multimedia telephone service and is responsible for processing service logic and control flow of the multiparty call. It receives IMS data from the UPF network element and performs corresponding processing, such as decoding voice data, rendering video streams, etc., according to service requirements. Meanwhile, the MMTel AS can interact with other network entities to coordinate and manage various aspects of the multiparty call.

Through the process of transmitting IMS data to MMTel AS by UPF network element, the high-efficiency transmission and service processing of data in multiparty call are realized. The design not only improves the network performance and reliability, but also ensures the continuity and stability of the multiparty call. The user can enjoy clear and smooth voice and video quality in the conversation process, and communication experience is improved.

Firstly, after receiving IMS data, a User Plane Function (UPF) network element of a calling party parses and confirms QoS parameters therein. The QoS parameters determine the quality and performance of the transmission of the multimedia data stream in the network, such as bandwidth requirements, delay requirements, etc. The UPF network element verifies and adjusts the parameters according to the network condition and the strategy configuration so as to ensure the smoothness and the stability of the call.

At the same time, the calling party's multimedia telephony application server (MMTel AS) also confirms the channel type in the IMS data. The channel type determines the transmission mode and characteristics of multimedia data, such as a voice channel, a video channel, or a data channel. The MMTel AS configures corresponding resources and processing logic according to the confirmed channel type to support the call.

In case both QoS parameters and channel type are confirmed, the MMTel AS of the calling party will start to process IMS data. For multiparty calls, the MMTel AS will transmit the data to MMTel AS of other calling parties by multicast. Multicasting is an efficient transmission scheme that allows data to be sent from a source node to multiple destination nodes simultaneously, thereby reducing network bandwidth occupation and delay.

In this way, the UPF network element and the MMTel AS of the calling party cooperate together, thereby ensuring the high efficiency and the accuracy of data transmission and processing in the multiparty call process. The method not only strictly confirms and configures QoS parameters and channel types, but also improves the efficiency of data transmission by utilizing a multicast technology, and provides high-quality communication experience for users.

The multiparty session call flow in this embodiment includes the following 3.1 to 3.3:

In the multiparty session, the calling party transmits IMS data (internet protocol multimedia subsystem (internet protocol multimedia subsystem, IMS) to the calling TAS through the UPF of the calling party, and the UPF of the calling party and the TAS of the calling party need to confirm QoS parameters and channel types in the IMS data so as to ensure the quality of multiparty call.

In the multiparty call, the User Plane Function (UPF) of the calling party is responsible for processing and forwarding IMS data. The data contains multimedia information such as voice, video and the like, and is the core content of the call. When the UPF receives these data, it will transmit them to the caller's Telephony Application Server (TAS). During the transmission, the calling UPF and TAS will acknowledge QoS parameters (such as bandwidth requirements, delay tolerance, etc.) and channel types (such as voice channels, video channels, etc.) in the IMS data.

3.2, The calling TAS transmits the IMS data to the corresponding TAS through the S-CSCF of the called UE-2 by multicast mode through the S-CSCF address of other UE stored by the calling TAS.

After receiving and processing the IMS data, the calling TAS determines how to send the data to other call participants according to the stored S-CSCF (serving call session control function) address information of other User Equipment (UE). In order to improve transmission efficiency, the calling TAS adopts a multicast technology to send data to a plurality of targets at the same time. This means that data is transferred to the S-CSCF of each called party before being forwarded by the S-CSCF to the corresponding TAS.

3.3, The TAS receiving the IMS data transmits the data to the corresponding called party UPF, the called party UPF transmits the received IMS data to the corresponding UE-2, and the called party TAS and the called party UPF corresponding to the UE-2 need to confirm the QoS parameters and the channel types in the IMS data so as to ensure the quality of the multiparty call.

When the called party' S-CSCF receives the multicast IMS data, it forwards these data to the corresponding TAS. The TAS of the called party then passes the received data to its corresponding UPF. The UPF is used as a core component of user plane processing and is responsible for accurately transmitting data to the UE (user equipment) of the called party. During the data transmission process, the TAS and UPF of the called party also need to confirm the QoS parameters and channel types in the received IMS data. This is to ensure that no change or loss of data occurs during the transmission process, thereby ensuring the quality of the multiparty call.

In this embodiment, each participant in the multiparty call can receive high-quality IMS data, thereby realizing smooth and high-quality call experience. The communication process is well supported and optimized in the IMS architecture, and reliable and efficient multimedia communication service is provided for users.

In one embodiment, as shown in fig. 2, a multiparty call method is provided, which is illustrated by taking a called party terminal of a calling party terminal call as an example, and includes the following steps:

S201, under the condition of receiving the session initiation protocol invite message SIP INVITE, subscription of the multi-party communication MPTY service is carried out to an access and mobility management function AMF network element of the called party.

The AMF plays a core role in the 5G network, and is responsible for registration, mobility management and overall business process monitoring of a terminal (UE) in the entire life cycle after power-on. When the multiparty call needs to be established, the AMF network element can perform corresponding service processing according to the request, so that the smooth establishment of the call is ensured.

It will be appreciated that the called party device or client needs to send a subscription request to the network, including the necessary authentication information and service request parameters. After receiving the request, the network side (including the AMF network element) performs authentication and processing, and if the request is valid and the user authority allows, the subscription of the MPTY service is completed and preparation is made for the subsequent multiparty call. After subscription is completed, the called party equipment or the client can participate in multi-party call, and perform real-time voice, video or data communication with other call participants. This typically requires support and coordination at the network side, including the delivery of signaling, forwarding of media streams, etc.

S202, under the condition that the subscription of the MPTY service of the multiparty call is completed, sending SIP:183 message to the proxy call session control function P-CSCF network element of the called party to trigger the multimedia telephony application server MMTel AS of the called party by the P-CSCF network element of the called party and to send SIP via the S-CSCF network element of the called party: 183 message goes to the calling network to complete the called.

Wherein, SIP: the 183 message, denoted "Session in Progress" in the SIP communication protocol (session in progress), is a temporary response message, typically indicating that the call is in progress.

Once the MPTY service subscription is completed, the called party sends a SIP:183 to its P-CSCF (proxy call session control function) network element. After the P-CSCF network element receives this message, it triggers the MMTel AS (multimedia telephony application server) of the called party. The MMTel AS is a core component for handling multimedia telephony services and is responsible for handling the logic and signaling associated with multiparty calls. The MMTel AS then interacts with the S-CSCF (serving call session control function) network element of the called party and finally sets the SIP:183 message is forwarded to the calling network to complete the called response procedure. When the calling party network receives SIP:183 it knows that the called party is handling the call invitation and that the session establishment procedure for the multiparty call is in progress. This typically results in the caller hearing a ringing tone or other corresponding alert tone until the session is eventually established.

Exemplary, the multiparty session called flow of the perfected UE provided in S021 and S202 is as follows 4.1 to 4.10:

and 4.1, after the query call session control function I-CSCF network element of the called side receives the MPTY service initial session INVITE request, routing the INVITE message to the S-CSCF registered by the called user.

Among them, in the IMS system, an INVITE message of SIP (session initiation protocol) is a code for establishing communication, particularly when a media session is established. When the calling party wants to initiate a multiparty call, it sends an INVITE message containing MPTY service type to the called party.

Among them, the query call session control function I-CSCF network element plays an important role in the IP Multimedia Subsystem (IMS). It is an entry point to the IMS home network and is mainly used to hide the topology of the IMS network to increase the security of the network. When there is no need to hide the IP address of the S-CSCF (serving CSCF), the I-CSCF may inform the P-CSCF (proxy CSCF) of the IP address of the S-CSCF so that the P-CSCF can send messages directly to the S-CSCF.

First, the I-CSCF will parse the information in the INVITE message, including the identity of the called user and the relevant parameters of the session. This information is critical in determining how to route the message. The I-CSCF then queries the subscriber subscription data in the network based on the identity of the called subscriber to determine the address of the serving call session control function (S-CSCF) to which the called subscriber is registered. This process is a critical step in ensuring that messages can be delivered accurately to the called subscriber. Once the address of the S-CSCF is determined, the I-CSCF will route the INVITE request to that address. This typically involves establishing connections and communicating messages between different nodes in the network.

And 4.2, after the S-CSCF of the called party receives the INVITE message, judging and triggering a corresponding application server TAS according to the MPTY service type in the INVITE message.

Among them, the application server TAS is a component responsible for executing a specific value added service, and for MPTY service, it may involve managing sessions between multiple participants, controlling mixing of media streams, etc.

In particular, the S-CSCF will parse the content of the INVITE message, with particular attention paid to the information about the MPTY traffic type therein. This information is critical for the S-CSCF to determine and trigger the corresponding Telephony Application Server (TAS).

The S-CSCF will determine which telephony application server TAS needs to be triggered to handle the multiparty call request based on MPTY traffic type information in the message. This may involve verifying the user's rights, checking the status of the network, and availability of resources, among other things. Once it is determined that MPTY services can be triggered, the S-CSCF will send instructions or requests to the corresponding TAS to initiate the required service logic. In this process, the interaction between the S-CSCF and TAS is critical. The S-CSCF is responsible for converting control information at the network level into traffic instructions that the TAS can understand and execute. The TAS executes specific service logic according to the instructions, such as establishing a session of the multiparty call, managing a session state, and the like. Through the cooperative work of the S-CSCF and the TAS, the correct realization and the efficient operation of the MPTY service on the network level can be ensured. The method provides a smooth and reliable multiparty call experience for the user, and meets various requirements of the user in the communication process.

4.3, The TAS of the called party routes the INVITE message to the UPF via the P-CSCF of the called party according to the P-CSCF address registered by the user.

Wherein the INVITE message carries an identification of the MPTY service type.

First, the TAS of the called party will parse the information in the INVITE message, in particular with respect to the part of the P-CSCF address where the user is registered. The P-CSCF is the representative of the user equipment in the network and is responsible for handling SIP (session initiation protocol) messages and routing them to the correct destination.

The TAS will then route the INVITE message to the User Plane Function (UPF) via the P-CSCF to which the called UE corresponds. In this process, the INVITE message will carry an identification of the MPTY traffic type so that the various components in the network can identify and properly handle this multiparty call request.

UPF is a key component in a network that is responsible for controlling the data flow of users according to policies. When the UPF receives the INVITE message with the MPTY service type identifier, the UPF makes a decision according to a pre-configured strategy, so that the message can reach the called UE smoothly.

And finally, the called UE receives the INVITE message and prompts the user to participate in the multiparty call. If the user accepts the invitation, a multiparty call session is established through which all participants can communicate.

4.4, The INVITE message is delivered to the called UE by UPF.

When the INVITE message arrives at the UPF, the UPF checks if the message carries an identification of the MPTY service type. This identification tells the UPF that the message is for setting up a multiparty call. Once the UPF confirms the traffic type of the message, it performs the necessary processing of the INVITE message according to pre-configured policies and rules.

After the processing is completed, the UPF forwards the INVITE message to the called UE. In this process, the UPF ensures the security and integrity of the message, preventing any possible malicious attacks or data leakage. Meanwhile, the UPF can also process the priority of the message according to the state and the load condition of the network, so as to ensure smooth operation of the multiparty call.

When the called UE receives the INVITE message, the called UE prompts the user to participate in the multiparty call according to the information in the message. If the user accepts the invitation, a multiparty call session is established through which all participants can communicate.

And 4.5, after receiving the INVITE message, the called UE subscribes MPTY service to the AMF.

When the called UE parses the INVITE message, it recognizes that the message is for setting up a multiparty call. The UE then decides whether to accept the multiparty call invitation according to its own configuration and network policy.

Once the UE decides to accept the invitation, it needs to indicate to the network side that it wants to participate in this MPTY service. At this time, the UE may send a subscription request to the AMF to inform the AMF that it needs to perform related mobility management and access control for the multiparty call.

The AMF is used as a key network element in the 5G core network and is responsible for the access and mobility management of users. After receiving the subscription request of the UE, the AMF processes the request of the UE according to the network policy and configuration. This may include verifying the identity of the UE, authorizing it to participate in MPTY services, allocating it with necessary network resources, etc.

Meanwhile, the AMF can also interact with other core network elements so as to ensure the smooth proceeding of the multiparty call service. For example, the AMF may communicate with a Session Management Function (SMF) and a User Plane Function (UPF) to coordinate session establishment, routing and forwarding of data flows, and the like.

Through subscribing MPTY business to AMF, the called UE can ensure that the UE can obtain necessary network support and resource guarantee when participating in multiparty call. This helps to improve reliability and user experience of the multiparty call service.

4.6, The called UE has performed the registration of MPTY service, and sends SIP to the P-CSCF of the called party: 183 message.

In the scenario of MPTY traffic, SIP: the 183 message is particularly used to inform the originating (calling) and called parties of the call, i.e. that a session establishment procedure of a multiparty call is in progress. This is an important feedback for both the calling party and the called party, as they both need to know the state of the establishment of the session.

When the called UE sends SIP to the P-CSCF: 183, it is actually telling the network that it is ready to participate in the multiparty call and is waiting for the joining of other participants or the further establishment of a session. The P-CSCF acts as an interface between the user equipment and the core network and is responsible for forwarding this message to the corresponding network component in order to further handle the establishment of the session.

SIP: the transmission of 183 message not only indicates the progress of the session establishment but may also contain other information related to the session, such as the configuration of the media stream, the status of the participants, etc. This information is critical to ensure smooth progress of the multiparty call.

4.7 After receiving 183 the message, the P-CSCF of the called party triggers the AAR/AAA process from the P-CSCF of the called party to the PCF of the called party.

AAR refers herein to a mechanism for collecting and analyzing data after a session or service is performed in order to optimize network performance and user experience. AAA is a key component in the network security domain, responsible for user authentication, authorization, and accounting management.

In MPTY services, when the P-CSCF receives SIP: after message 183, it may need to interact with the PCF of the called party to obtain policy information about the session establishment or to perform charging related processing. This procedure may involve AAR or AAA mechanisms.

In the case of an AAR procedure, the P-CSCF may send relevant session data or traffic execution results to the PCF for performance analysis and optimization by the PCF. Through AAR, a network operator can know the execution condition of MPTY service, find potential problems and improve, thereby improving user satisfaction and network quality.

In the case of an AAA procedure, the P-CSCF may need to cooperate with the PCF to complete authentication, authorization, and accounting operations for the user. This ensures that only legitimate users can participate in the multiparty call and that the network can accurately record the charging information for the session.

Both AAR and AAA processes are important links to ensure that MPTY traffic goes well. Through these processes, the network can realize the effective management and control of the multiparty call session, and provide high-quality and safe communication service for users.

4.8, The PCF of the called party instructs the SMF of the called party to request voice QoS flow resources from the gNB and UPF, respectively.

The gNB is a key component in the 5G network, is responsible for providing protocol terminals of an NR (new radio) user plane and a control plane, and is connected with the 5GC (5G core network). In the MPTY service, the gNB is responsible for management and allocation of radio resources, so as to ensure transmission quality and efficiency of voice data. Thus, when the SMF requests voice QoS flow resources from the gNB, the gNB allocates appropriate radio resources to the multiparty call session based on current network conditions and resource availability.

The UPF is a user plane functional entity in the 5G core network, responsible for routing and forwarding of user data. In MPTY services, UPF needs to ensure correct transmission of voice data and high quality of service. Therefore, when the SMF requests the voice QoS flow resource from the UPF, the UPF configures a corresponding data flow rule, so as to ensure that the voice data can be transmitted according to the required QoS standard.

Through the indication of PCF and the request of SMF, gNB and UPF can work cooperatively to provide the needed voice QoS flow resource for MPTY service. The voice quality and the service stability of the multiparty call session are ensured, and the communication experience of the user is improved.

4.9, The PCF of the called party reports the position of the called UE.

When a multiparty call session is established, the network needs to know the current location of the called UE in order to route voice and data flows correctly. The location information helps the network determine the best transmission path, reducing delay and packet loss, and thus improving communication quality.

In this process, the PCF may trigger a location report according to predefined policy rules as a policy decision point. These policy rules may be based on a variety of factors such as session type, user subscription information, network conditions, etc. Once the position report is triggered, the PCF sends a request to the relevant network function entity to obtain the position information of the called UE.

In particular, the PCF may interact with an access and mobility management function (AMF). The AMF is responsible for maintaining location information of the user and is able to provide up-to-date location data upon request. The PCF sends a position request to the AMF, and the AMF returns the position information of the called UE to the PCF after verifying the validity of the request.

In addition to AMF, PCF may interact with other network function entities (e.g., location management function LMF) to obtain more accurate or comprehensive location data. These interactive processes follow corresponding protocols and standards to ensure the accuracy and security of the information.

Once the PCF obtains the location information of the called UE, it may process it as needed and may report the location information to a higher level network management entity or for other purposes (e.g., billing, security auditing, etc.).

4.10, The P-CSCF of the called party forwards 183 the message to the TAS of the called party via the S-CSCF of the called party. The TAS of the called party recognizes the SIP message and forwards the message to the S-CSCF of the called party, and the S-CSCF of the called party forwards the message to the calling network to finish the called.

The P-CSCF passes the SIP through the S-CSCF (serving call session control function) of the called party: 183 message is forwarded to the TAS (terminal access server) of the called party. The S-CSCF serves as a core control point in an IMS (IP multimedia subsystem) network, responsible for handling call signaling and managing user sessions. Its role in this process is to pass the message from the P-CSCF to the next logical node.

When the TAS of the called party receives the SIP:183 it recognizes the SIP message and forwards it to the S-CSCF of the called party. This step ensures the correct routing and handling of messages in the IMS network.

Subsequently, the S-CSCF of the called party will SIP:183 message is forwarded to the calling network. This is a critical step in completing the called process because it establishes a communication connection between the calling subscriber and the called subscriber. Through the forwarding of the S-CSCF, the calling network can receive a confirmation message that the called user is ready to participate in the multiparty call.

This series of operations ensures that the multiparty call service proceeds smoothly at the network level. It involves the cooperative work of multiple network entities including P-CSCF, S-CSCF and TAS. Each entity processes SIP messages within its particular sphere of responsibility, thereby enabling call setup and management.

In the multiparty call method, before joining the multiparty call, the called party needs to complete the registration and subscription of the corresponding MPTY service, so that the voice data, the media data and the file data in the multiparty call can be transmitted.

In one embodiment, AS shown in fig. 3, the multimedia telephony application server MMTel AS of the calling party is further configured to perform the following steps, which may specifically include:

S301, storing the number of terminals joining the multiparty call.

It will be appreciated that when a new terminal joins a multiparty call, the network needs to record and update the number of participants. The number of terminals stored may be used for various purposes such as charging, session control and network performance optimization. By keeping track of the number of participants, the operator can learn the scale and complexity of the session, making necessary resource allocation and optimization.

S302, in the process of maintaining the multiparty call, broadcasting and transmitting the number of terminals accessed into the multiparty call and S-CSCF network elements corresponding to the terminals to S-CSCF network elements corresponding to the MMTel AS of the multimedia telephone application server of the called party.

Specifically, as the multiparty call proceeds, the network needs to update and maintain the state of the session in real time. To achieve this, the network may optionally broadcast and send the number of terminals that have been connected to the multiparty call and S-CSCF (serving call session control function) element information corresponding to each terminal to an S-CSCF (serving call session control function) element corresponding to a multimedia telephony application server (MMTel AS) of the called party. This allows the MMTel AS to know the real-time status of the current session, including the number and location of participants. This broadcast mechanism helps to ensure that MMTel AS can accurately handle multimedia sessions, including voice, video and data streams.

S303, receiving a reply confirmation message returned by the MMTel AS of the called party.

Optionally, after sending the number of terminals and the S-CSCF element information, the network needs to wait for an acknowledgement reply from the MMTel AS. This step ensures successful delivery and processing of the information. When the MMTel AS receives the information and processes it, it returns an acknowledgement message to the network. This acknowledgement message is part of the communication protocol for ensuring consistency and reliability of the communication between the two parties. By receiving this confirmation message, the network can confirm that the MMTel AS has already known the current state of the multiparty call and is ready for corresponding processing.

Illustratively, the above-mentioned multi-party session maintaining flow for multiple UE access and session is as follows:

And 5.1, after the calling party (UE-1) and the UE-2 realize voice call, the call between the calling party and the UE-2 is kept.

Optionally, a voice call connection is established between the calling party and the UE-2. The network needs to ensure that this connection is stable so that other UEs can be joined smoothly in the multiparty call later.

And 5.2, triggering the MMTel AS of the response by the S-CSCF corresponding to the calling party and connecting to the called network of the UE-3.

The S-CSCF (serving call session control function) where the calling party is located recognizes that a multiparty call needs to be initiated, thus triggering the corresponding MMTel AS (multimedia telephony application server). The MMTel AS then starts the logic to handle the multiparty call and attempts to connect the call to the called network where UE-3 is located.

And 5.3, the UE-3 subscribes to the MPTY service according to the called flow of the UE-2 and accesses the multiparty session.

UE-3 as a new participant needs to subscribe to MPTY (multi-party talk) service according to the called procedure. This typically involves a signaling interaction with the network to ensure that the UE-3 can successfully join the multiparty call. Once the subscription is successful, UE-3 will access the multiparty session.

And 5.4, the TAS corresponding to the calling party initiating the session records the number of the UE joining the multiparty session as MPTY_UE_COUNT, when the new UE joins the multiparty session, the MPTY_UE_COUNT stored in the TAS is increased by 1, and the S-CSCF address of the new UE is stored in the TAS.

When a new UE joins a multiparty session, the TAS where the calling party is located will perform the following operations:

And (5) counting and updating: the TAS maintains a counter named mpty_ue_count for keeping track of the number of UEs currently engaged in the multi-party call. This counter is incremented by 1 each time a new UE joins to reflect the change in the number of UEs in the session.

Address storage: in addition to updating the counter, the TAS stores the S-CSCF (serving call session control function) address of the newly joined UE locally. The S-CSCF address is a logical location identity of the UE in the network, which is critical for subsequent communication routing and session management.

By maintaining the mpty_ue_count counter and storing the S-CSCF address, the TAS of the calling party can grasp the participation of the multi-party call and the network location information of the UE in real time. Such information is critical to ensure successful progress of the session and to provide high quality communication services.

5.5, The TAS broadcasts MPTY UE information groupcast a message to the S-CSCF addresses corresponding to other TAS, the message contains the S-CSCF addresses and the number of the UE corresponding to the UE accessed into the multiparty session, and after the S-CSCF of the called UE receives the broadcast message, the broadcast message is transferred to the corresponding TAS to store the S-CSCF addresses and the number of the UE of other UE. The TAS of the called UE sends a reply acknowledge message to the TAS of the calling UE through the S-CSCF indicating that the broadcast message has been successfully received.

The above process may specifically include:

1) Broadcast MPTY UE information groupcast message: the TAS corresponding to the calling party is responsible for initiating the broadcast procedure. It constructs MPTY UE information groupcast a message containing the number of UEs that have accessed the multiparty session and the S-CSCF (serving call session control function) address corresponding to each UE. The TAS then broadcasts this message to the S-CSCF addresses corresponding to all other UEs participating in the multiparty call.

2) Message forwarding and storage: when the S-CSCF of the called UE receives this broadcast message, it forwards the message to the corresponding TAS (i.e. the TAS of the called UE). After receiving the message, the TAS of the called UE updates the locally stored UE information, including the S-CSCF address of the other UE and the number of UEs. Thus, the TAS of each UE participating in the multiparty call has complete session participant information.

3) Transmitting a reply acknowledge message: to ensure that the broadcast message has been successfully received and processed, the TAS of the called UE will send a reply acknowledge message to the TAS of the calling UE via its corresponding S-CSCF. This reply acknowledge message is part of the communication protocol and is used to indicate the successful status of the message delivery.

4) Processing of acknowledgement messages: the TAS of the calling UE may confirm that the broadcast message has been successfully delivered to all participants after receiving the reply confirm messages of all called UEs. This helps to ensure that the session state of the multiparty call remains consistent among all participants.

Through this process, the network can ensure synchronization and consistency of information between participants of the multiparty call. This helps to maintain the stability of the session, preventing problems due to inconsistent information. Meanwhile, the reply confirmation mechanism also improves the reliability and accuracy of communication. 5.6, maintaining a multiparty session between calling party (UE-1), UE-2, UE-3.

Specifically, to maintain a multiparty session, the network needs to perform the following operations:

And (3) signaling processing: the network needs to continuously process signaling messages from the UE, including transmission requests for voice or video data, session control instructions, etc. The entities such AS S-CSCF and MMTel AS are responsible for analyzing and processing the messages and carrying out corresponding operation according to the conversation logic.

Session state management: the network needs to track and manage the session state of the multiparty call in real time. This includes information on the number of participants, the status of each participant (e.g., whether it is online, whether it is in a mute state, etc.), the media type of the session (e.g., voice or video), etc. This information is critical to ensure session continuity and consistency.

Media stream forwarding: in multiparty calls, media streams (e.g., voice or video data) need to be forwarded in real-time between different UEs. The network needs to ensure that the media stream can be accurately transmitted from one UE to another while maintaining low latency and high quality. This typically involves the use of a media gateway and a media stream processing server.

Error handling and recovery: the network needs to be able to handle various errors and anomalies that may occur, such as network failures, UE dropped lines, etc. When these situations occur, the network needs to take corresponding measures to restore the session or maintain the stability of the session. This may include reestablishing the connection, switching to a standby network, or making other necessary adjustments.

And (3) resource release: when the multiparty session ends, the network needs to release the resources allocated for the session, including signaling connections, media stream channels, etc. This helps to ensure efficient use of network resources and avoid unnecessary wastage.

When the multiparty call is ended, the multiparty call method further comprises a flow of releasing the session by the called UE, and the specific flow is as follows:

And 6.1, when the called UE-2 releases the session, sending a BYE message to the P-CSCF corresponding to the UE-2.

The BYE message contains the ID of the UE-2 and the identification of the multiparty session.

It will be appreciated that when the UE-2 decides to end the multiparty call, it will send a BYE message to the proxy call session control function (P-CSCF) to which it is connected. This BYE message contains the identity of UE-2 (e.g., IMSI or MSISDN) and the identity of the multiparty session so that the network can accurately identify which session needs to be released.

And 6.2, after receiving the BYE message, the P-CSCF releases QoS resources and forwards the BYE message to the S-CSCF.

The P-CSCF, upon receiving the BYE message, will first release QoS (quality of service) resources allocated for this session, such as bandwidth reservations, etc. The P-CSCF will then forward the BYE message to the serving call session control function (S-CSCF) to further handle the logic of session release.

6.3, S-CSCF forwards BYE message to the calling party ' S TAS through the UE-2 ' S TAS and the calling party ' S S-CSCF. After receiving the BYE message, the S-CSCF forwards the message to the calling party via the relevant entity in the network. In this process, the S-CSCF may need to interact with the Terminal Access Server (TAS) of UE-2 and the S-CSCF of the calling party to ensure that the BYE message can be accurately delivered to the TAS of the calling party.

And 6.4, the TAS stores and updates the number of the UE and the S-CSCF information.

After receiving the BYE message, the TAS of the calling party updates the multiparty call information stored in the TAS. This includes reducing the UE COUNT (i.e., mpty_ue_count minus 1) and may update or delete S-CSCF address information associated with UE-2. Thus, the network can know the current participants and states of the multiparty call in real time.

6.5, The TAS of the calling party sends 200 (BYE) information to the UE-2 through the S-CSCF and the P-CSCF of the UE-2, and confirms the release of the multiparty session of the UE-2.

To confirm that the session of UE-2 has been successfully released, the TAS of the calling party sends a 200 (BYE) response message to UE-2. This response message is forwarded through the S-CSCF and P-CSCF of UE-2 and eventually reaches UE-2. Upon receipt of this response, UE-2 may determine that it has successfully exited the multiparty call.

In this embodiment, the network can ensure that when a UE decides to release the multiparty call, the session can be ended normally, related resources are released, and all participants can be notified and confirmed accordingly. This helps to maintain efficient use of network resources and provide high quality communication services.

In the multiparty call process, the multiparty call method further comprises an implementation flow of multiparty session, and the specific flow is as follows:

7.1, in the multiparty session, the calling party transmits the IMS data to the TAS through the UPF, and the UPF and the TAS need to confirm the QoS parameters and the channel types in the IMS data so as to ensure the quality of multiparty call.

It can be appreciated that QoS parameters are key factors for measuring quality of service, which directly affect call fluency, delay, packet loss rate, etc. By confirming the QoS parameters, the UPF and the TAS can ensure reasonable distribution of network resources during data transmission, and bandwidth and delay requirements required by multiparty calls are preferentially ensured, so that high-quality call experience is provided. Confirmation of the channel type is also an important step in ensuring call quality. Different channel types have different transmission characteristics and capacities and are suitable for different application scenes. By confirming the channel types, the UPF and the TAS can select the channel most suitable for multi-party call, and accurate and efficient transmission of data is ensured.

In this process, the cooperation of the UPF and TAS plays a key role. The UPF is used as a core component of a user plane and is responsible for forwarding and processing data; the TAS, in turn, serves as an access server that manages the connection with the UE. Through the close fit between the IMS data and the IMS data, the IMS data can be accurately controlled and processed, so that the high-quality performance of the multiparty call is ensured.

And 7.2, the TAS transmits the IMS data to the corresponding TAS through the S-CSCF of the receiving UE-2 in a multicast mode through the S-CSCF address of other UE stored in the TAS.

Specifically, the TAS of the calling party may find the S-CSCF address corresponding to the receiving party UE-2 according to the participant information of the session. It will then send these IMS data out in a multicast manner. Multicasting is a network transmission scheme that allows data to be simultaneously transmitted to multiple receivers, and is particularly effective in multiparty call scenarios because it can significantly reduce network bandwidth consumption and improve data transmission efficiency.

In this process, the data is forwarded to the corresponding TAS via the S-CSCF of the receiving UE-2. The S-CSCF serves as a core control entity in the IMS network, responsible for handling signaling and control logic related to session management. After receiving the data, the data is accurately sent to the TAS corresponding to the receiving party UE-2 according to the routing logic therein.

By the way, the TAS of the calling party can ensure that IMS data can be efficiently and accurately transmitted to all session participants, thereby ensuring the smooth proceeding of the multiparty call. The implementation of this step relies on the cooperation and accurate routing control between the entities in the network, which together ensure the reliability and stability of the multiparty call.

And 7.3, the TAS receiving the IMS data transmits the data to the corresponding UPF, the UPF transmits the received IMS data to the corresponding UE-2, and the TAS and the UPF corresponding to the UE-2 need to confirm the QoS parameters and the channel types in the IMS data so as to ensure the quality of the multiparty call.

The UPF is used as a core component of a user plane and is responsible for forwarding and processing data. Upon receiving the IMS data from the TAS, the UPF performs the necessary processing, such as encapsulation, decapsulation, and forwarding of data packets, to ensure that the data accurately reaches the target UE-2.

In the data transmission process, the TAS and UPF corresponding to the UE-2 can confirm the QoS parameters and the channel types in the IMS data. The QoS parameter is a key factor for ensuring the call quality, and relates to the aspects of data transmission speed, delay, packet loss rate and the like. Through confirming the QoS parameters, TAS and UPF can ensure that data is properly prioritized and processed in the transmission process, so as to meet the real-time performance and quality requirements of multi-party calls.

Meanwhile, the confirmation of the channel type is also an important link for ensuring the call quality. Different channel types have different transmission characteristics and capacities and are suitable for different application scenes. By confirming the channel type, TAS and UPF can select the channel most suitable for multiparty call, and ensure accurate and efficient data transmission.

In this embodiment, based on the above steps, the multiparty call is realized, and the quality of the call is effectively ensured. In this process, the cooperation between the various network entities plays a critical role in the accurate processing of data.

When the multiparty call is ended, the multiparty call method further comprises a process of deleting multiparty session members by the calling party, wherein the specific process is as follows:

8.1, the calling party sends MPTY member deletion request message to the TAS through the P-CSCF and the S-CSCF.

The deletion request message contains configuration information of the UE-2 which is a member to be deleted, including the UE-2 ID and an S-CSCF address corresponding to the UE-2.

It will be appreciated that when the calling party decides to delete a member (e.g. UE-2), it will first send an MPTY member deletion request message to the Terminal Access Server (TAS) via its proxy call session control function (P-CSCF) and serving call session control function (S-CSCF). The message contains configuration information of members to be deleted, and specifically includes an Identification (ID) of the UE-2 and an S-CSCF address corresponding to the UE-2. This information is critical to accurately identifying and locating members that need to be deleted.

8.2, The TAS of the calling party forwards the MPTY member deletion request message to the S-CSCF of the UE-2.

Specifically, after receiving the MPTY member deletion request message, the TAS of the calling party forwards the message to the S-CSCF corresponding to the UE-2 according to the S-CSCF address information of the UE-2 provided in the message. This step ensures that the delete request can be accurately delivered to the control node of the target UE-2.

8.3, UE-2 and corresponding TAS execute the called UE to release the multiparty session flow.

Specifically, once the S-CSCF of UE-2 receives the MPTY member deletion request message, it triggers a corresponding procedure to release the multiparty session of UE-2. This process may include the steps of releasing session resources associated with UE-2, updating session state, and notifying other session members. Meanwhile, the TAS corresponding to the UE-2 also participates in the process, so that the synchronization of the session state and the correct release of the resources are ensured.

In this embodiment, based on the above steps, the network can effectively delete a specific member in the multiparty session, while ensuring that sessions of other members are not affected. This helps to maintain the stability and reliability of the session and provides more flexible multiparty call management functions. In practical application, the flow can be customized and optimized according to specific network architecture and service requirements so as to meet the multi-party call requirements in different scenes.

When the multiparty call is ended, the multiparty call method further comprises a process of releasing the session by the calling UE, wherein the concrete process is as follows:

9.1, the caller sends a BYE (MPTY) message to the caller's P-CSCF indicating the release of the current MPTY session.

When the calling party decides to end the multiparty session, it sends a BYE (MPTY) message to its proxy call session control function (P-CSCF). This message is a session end notification instructing the P-CSCF to start releasing session related resources.

And 9.2, the P-CSCF of the calling party releases QoS resources.

Upon receiving the BYE (MPTY) message, the P-CSCF of the calling party will start releasing the QoS (quality of service) resources previously allocated for the multiparty session. This includes freeing up bandwidth, lowering priority, etc. to ensure efficient use of network resources.

9.3, The P-CSCF of the calling party routes BYE (MPTY) to the TAS of the calling party according to a fixed path, and indicates the release of the multiparty session, wherein the path is as follows: (P-CSCF of the calling party) - > (S-CSCF of the calling party) - > (TAS of the calling party).

The P-CSCF forwards a BYE (MPTY) message to a serving call session control function (S-CSCF) of the calling party according to a fixed routing path, and the BYE (MPTY) message is forwarded to a Terminal Access Server (TAS) by the S-CSCF. This path ensures that messages can accurately arrive at the TAS responsible for handling multiparty sessions.

9.4, The TAS of the calling party forwards BYE (MPTY) to the S-CSCF of the called UE-2 in a multicast mode according to the S-CSCF addresses of all the called UE-2 stored by the TAS of the calling party, and the S-CSCF of the UE-2 forwards BYE (MPTY) information to the P-CSCF of the UE-2, wherein the UE-2 can be 1 or more called UEs.

After receiving BYE (MPTY) information, the TAS of the calling party forwards the information to S-CSCF of the called UE (e.g. UE-2) in a multicast mode according to the S-CSCF address information of the called UE stored in the TAS. In this way, all called UEs participating in the multiparty session can receive notification of the end of the session.

And 9.5, the P-CSCF of the UE-2 releases QoS resources.

The P-CSCF of each called UE receiving the BYE (MPTY) message releases the QoS resources previously allocated for the session to ensure timely reclamation of network resources.

9.6, The P-CSCF of UE-2 forwards a BYE (MPTY) message to UE-2.

After releasing the resources, the P-CSCF of the called UE forwards a BYE (MPTY) message to the corresponding UE informing them that the multiparty session has ended.

9.7, UE-2 routes a 200 (BYE) message to the calling party on a fixed path, indicating that the multiparty session has been released, the path being (UE-2) - > (P-CSCF of UE-2) > (S-CSCF of UE-2) > (TAS of UE-2) > (S-CSCF of calling party) > (P-CSCF of calling party) > (calling party). Each called UE, after receiving the BYE (MPTY) message, sends a 200 (BYE) message to the calling party according to a fixed path as confirmation of session release. This path ensures that the message is properly returned to the calling party, thereby completing the entire session release procedure.

In this embodiment, based on the above steps, the multiparty call method can ensure that the calling UE can gracefully release related resources when deciding to end the session, and notify all the called UEs participating in the session. This helps to maintain efficient utilization of network resources and stability of sessions.

Compared with the traditional technology, the video and file data channels of multiparty conversations are increased; under the 5G architecture, the subscription flow of the UE to the multiparty session is perfected; the multicast, maintaining and modifying flow of multiparty session is perfected; the multi-party call service is expanded and enhanced based on the 5G new call, and the multi-media multi-party call service is realized.

It should be understood that, although the steps in the flowcharts related to the above embodiments are sequentially shown as indicated by arrows, these steps are not necessarily sequentially performed in the order indicated by the arrows. The steps are not strictly limited to the order of execution unless explicitly recited herein, and the steps may be executed in other orders. Moreover, at least some of the steps in the flowcharts described in the above embodiments may include a plurality of steps or a plurality of stages, which are not necessarily performed at the same time, but may be performed at different times, and the order of the steps or stages is not necessarily performed sequentially, but may be performed alternately or alternately with at least some of the other steps or stages.

Based on the same inventive concept, the embodiment of the application also provides a multiparty call device for realizing the multiparty call method. The implementation of the solution provided by the device is similar to the implementation described in the above method, so the specific limitation in the embodiments of the multi-party call device provided below may be referred to the limitation of the multi-party call method hereinabove, and will not be repeated here.

In one embodiment, as shown in fig. 3, there is provided a multiparty call device 1, comprising: an initiation module 11 and a trigger module 12, wherein:

The initiating module 11 is configured to send a subscription request of an MPTY service for the multiparty call to an AMF network element corresponding to the calling party before initiating the multiparty call; the multi-party communication MPTY service comprises at least one of a voice transmission service, a video transmission service and a file transmission service;

And the triggering module 12 is configured to send a session initiation protocol invite message SIP INVITE to a proxy call session control function P-CSCF network element of the calling party, so AS to trigger a multimedia telephony application server MMTel AS of the calling party through the P-CSCF network element of the calling party, and access the called network through the multimedia telephony application server MMTel AS of the calling party, when receiving a subscription success message returned by the AMF network element of the calling party.

In one embodiment, the apparatus further comprises a holding module for: in the process of maintaining the multiparty call, transmitting the IMS data of the Internet protocol multimedia subsystem to a MMTel AS of a calling party through a UPF network element of the user plane function of the calling party;

In one embodiment, as shown in fig. 4, there is provided a multiparty call device 2, comprising: a receiving module 21 and an access module 22, wherein:

A receiving module 21, configured to subscribe the multi-party call MPTY service to an AMF network element of the called party under the condition that the session initiation protocol invite message SIP INVITE is received;

The access module 22 is configured to send SIP when subscription of the multi-party MPTY service is completed: 183 message to the proxy call session control function P-CSCF network element of the called party to trigger the multimedia telephony application server MMTel AS of the called party by the P-CSCF network element of the called party and to send SIP via the S-CSCF network element of the called party: 183 message goes to the calling network to complete the called.

The modules in the multiparty call device can be realized in whole or in part by software, hardware and a combination thereof. The above modules may be embedded in hardware or may be independent of a processor in the computer device, or may be stored in software in a memory in the computer device, so that the processor may call and execute operations corresponding to the above modules.

In one embodiment, a computer device is provided, which may be the terminal of the calling party, the internal structure of which may be as shown in fig. 5. The computer device includes a processor, a memory, a communication interface, a display screen, and an input device connected by a system bus. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The communication interface of the computer device is used for carrying out wired or wireless communication with an external terminal, and the wireless mode can be realized through WIFI, a mobile cellular network, NFC (near field communication) or other technologies. The computer program is executed by a processor to implement a multiparty call method. The display screen of the computer equipment can be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer equipment can be a touch layer covered on the display screen, can also be keys, a track ball or a touch pad arranged on the shell of the computer equipment, and can also be an external keyboard, a touch pad or a mouse and the like.

It will be appreciated by those skilled in the art that the structure shown in FIG. 5 is merely a block diagram of some of the structures associated with the present inventive arrangements and is not limiting of the computer device to which the present inventive arrangements may be applied, and that a particular computer device may include more or fewer components than shown, or may combine some of the components, or have a different arrangement of components.

In one embodiment, a computer device is provided, which may be a terminal of a called party, and the internal structure diagram of which may be as shown in fig. 6. The computer device includes a processor, a memory, a communication interface, a display screen, and an input device connected by a system bus. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The communication interface of the computer device is used for carrying out wired or wireless communication with an external terminal, and the wireless mode can be realized through WIFI, a mobile cellular network, NFC (near field communication) or other technologies. The computer program is executed by a processor to implement a multiparty call method. The display screen of the computer equipment can be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer equipment can be a touch layer covered on the display screen, can also be keys, a track ball or a touch pad arranged on the shell of the computer equipment, and can also be an external keyboard, a touch pad or a mouse and the like.

It will be appreciated by those skilled in the art that the structure shown in FIG. 6 is merely a block diagram of some of the structures associated with the present inventive arrangements and is not limiting of the computer device to which the present inventive arrangements may be applied, and that a particular computer device may include more or fewer components than shown, or may combine some of the components, or have a different arrangement of components.

In one embodiment, there is provided a terminal of a calling party, comprising a memory and a processor, the memory storing a computer program, the processor implementing the following steps when executing the computer program:

In one embodiment, the session initiation protocol invite (sip invite) message SIP INVITE is used to instruct the proxy call session control function (P-CSCF) network element of the calling party to send a response authentication request (AAR) message to the Policy Control Function (PCF) network element of the calling party; the response authentication request AAR message comprises user IP of a calling party, media component information and local application function AF application identification information;

In one embodiment, the processor when executing the computer program further performs the steps of: in the process of maintaining the multiparty call, transmitting the IMS data of the Internet protocol multimedia subsystem to a MMTel AS of a calling party through a UPF network element of the user plane function of the calling party; the internet protocol multimedia subsystem IMS data is used for triggering a user plane function UPF network element of the calling party and a multimedia telephony application server MMTel AS of the calling party to confirm a quality of service QoS parameter and a channel type in the internet protocol multimedia subsystem IMS data, and in case that the confirmation passes, the internet protocol multimedia subsystem IMS data is transmitted to the multimedia telephony application servers MMTel AS of other calling parties in the multi-party call in a multicast manner through the multimedia telephony application server MMETel AS of the calling party.

In one embodiment, a computer readable storage medium is provided having a computer program stored thereon, which when executed by a processor, performs the steps of:

In one embodiment, the computer program when executed by the processor further performs the steps of: in the process of maintaining the multiparty call, transmitting the IMS data of the Internet protocol multimedia subsystem to a MMTel AS of a calling party through a UPF network element of the user plane function of the calling party; the internet protocol multimedia subsystem IMS data is used for triggering a user plane function UPF network element of the calling party and a multimedia telephony application server MMTel AS of the calling party to confirm a quality of service QoS parameter and a channel type in the internet protocol multimedia subsystem IMS data, and in case that the confirmation passes, the internet protocol multimedia subsystem IMS data is transmitted to the multimedia telephony application servers MMTel AS of other calling parties in the multi-party call in a multicast manner through the multimedia telephony application server MMETel AS of the calling party.

In one embodiment, a computer program product is provided comprising a computer program which, when executed by a processor, performs the steps of:

In one embodiment, the computer program when executed by the processor further performs the steps of: in the process of maintaining the multiparty call, transmitting the IMS data of the Internet protocol multimedia subsystem to a MMTel AS of a calling party through a UPF network element of the user plane function of the calling party;

In one embodiment, there is provided a terminal of a called party, comprising a memory and a processor, the memory storing a computer program, the processor implementing the following steps when executing the computer program:

The user information (including but not limited to user equipment information, user personal information, etc.) and the data (including but not limited to data for analysis, stored data, presented data, etc.) related to the present application are information and data authorized by the user or sufficiently authorized by each party.

Those skilled in the art will appreciate that implementing all or part of the above described methods may be accomplished by way of a computer program stored on a non-transitory computer readable storage medium, which when executed, may comprise the steps of the embodiments of the methods described above. Any reference to memory, database, or other medium used in embodiments provided herein may include at least one of non-volatile and volatile memory. The nonvolatile Memory may include Read-Only Memory (ROM), magnetic tape, floppy disk, flash Memory, optical Memory, high density embedded nonvolatile Memory, resistive random access Memory (ReRAM), magneto-resistive random access Memory (Magnetoresistive Random Access Memory, MRAM), ferroelectric Memory (Ferroelectric Random Access Memory, FRAM), phase change Memory (PHASE CHANGE Memory, PCM), graphene Memory, and the like. Volatile memory can include random access memory (Random Access Memory, RAM) or external cache memory, and the like. By way of illustration, and not limitation, RAM can be in various forms such as static random access memory (Static Random Access Memory, SRAM) or dynamic random access memory (Dynamic Random Access Memory, DRAM), etc. The databases referred to in the embodiments provided herein may include at least one of a relational database and a non-relational database. The non-relational database may include, but is not limited to, a blockchain-based distributed database, and the like. The processor referred to in the embodiments provided in the present application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic unit, a data processing logic unit based on quantum computing, or the like, but is not limited thereto.

The technical features of the above embodiments may be arbitrarily combined, and all possible combinations of the technical features in the above embodiments are not described for brevity of description, however, as long as there is no contradiction between the combinations of the technical features, they should be considered as the scope of the description.

The foregoing examples illustrate only a few embodiments of the application and are described in detail herein without thereby limiting the scope of the application. It should be noted that it will be apparent to those skilled in the art that several variations and modifications can be made without departing from the spirit of the application, which are all within the scope of the application. Accordingly, the scope of the application should be assessed as that of the appended claims.

Claims

1. A method of multiparty calling, performed by a calling party, the method comprising:

Before the multiparty call is initiated, a subscription request of the multiparty call MPTY service is sent to an access and mobility management function AMF network element corresponding to a calling party; wherein the multi-party call MPTY service comprises at least one of a voice transmission service, a video transmission service and a file transmission service;

And under the condition that a subscription success message returned by the access and mobile management function AMF network element of the calling party is received, sending a session initiation protocol invite message SIP INVITE to a proxy call session control function P-CSCF network element of the calling party so AS to trigger a multimedia telephone application server MMTel AS of the calling party through the proxy call session control function P-CSCF network element of the calling party, and accessing a called network through the multimedia telephone application server MMTel AS of the calling party.

2. The method according to claim 1, wherein the session initiation protocol invite (sip invite) message SIP INVITE is used to instruct a proxy call session control function (P-CSCF) network element of the calling party to send a reply authentication request (AAR) message to a Policy Control Function (PCF) network element of the calling party; the response authentication request AAR message comprises user IP of the calling party, media component information and local application function AF application identification information;

The answer authentication request AAR message is configured to instruct the PCF network element of the calling party to request, through the SMF network element of the calling party, a voice quality of service QoS flow resource to the next generation base station gNodeB and the UPF network element of the calling party, and report, to the P-CSCF network element of the proxy call session control function of the calling party, location report information of the PCF network element of the calling party;

3. The method of claim 2, wherein the Media component information includes a Media Type Media-Type parameter, a Flow Description Flow-Description parameter, and a Flow Status Flow-Status parameter.

4. The method of claim 1, wherein the voice data corresponding to the voice transmission service is transmitted by a voice channel, the video data corresponding to the video transmission service is transmitted by a video channel, and the file data corresponding to the file transmission service is transmitted by a file channel.

5. The method according to claim 4, wherein the method further comprises:

In the process of maintaining the multiparty call, transmitting the IMS data to a MMTel AS of the calling party through a UPF network element of the calling party;

The internet protocol multimedia subsystem IMS data is used for triggering the user plane function UPF network element of the calling party and the multimedia telephony application server MMTel AS of the calling party to confirm the QoS parameters and channel types in the internet protocol multimedia subsystem IMS data, and in case that the confirmation passes, the internet protocol multimedia subsystem IMS data is transmitted to the multimedia telephony application servers MMTel AS of other calling parties in the multi-party call in a multicast manner through the multimedia telephony application server MMETel AS of the calling party.

6. A method of multiparty calling, performed by a called party, the method comprising:

Under the condition of receiving the session initiation protocol invite (SIP) message SIP INVITE, subscribing the MPTY service of the multiparty call to an access and mobility management function (AMF) network element of a called party; wherein the multi-party call MPTY service comprises at least one of a voice transmission service, a video transmission service and a file transmission service;

And under the condition that the subscription of the MPTY service of the multiparty call is completed, sending the SIP:183 to the proxy call session control function P-CSCF network element of the called party to trigger the multimedia telephony application server MMTel AS of the called party by the P-CSCF network element of the called party and to send the SIP via the S-CSCF network element of the called party: 183 message goes to the calling network to complete the called.

7. A multi-party call device, the device comprising:

The initiation module is used for sending a subscription request of the multi-party call MPTY service to an access and mobile management function AMF network element corresponding to the calling party before initiating the multi-party call; wherein the multi-party call MPTY service comprises at least one of a voice transmission service, a video transmission service and a file transmission service;

And the triggering module is used for sending a session initiation protocol invite message SIP INVITE to a proxy call session control function (P-CSCF) network element of the calling party under the condition of receiving a subscription success message returned by the AMF network element of the calling party so AS to trigger a multimedia telephony application server (MMTel AS) of the calling party through the P-CSCF network element of the calling party and access a called network through the multimedia telephony application server (MMTel AS) of the calling party.

8. A multi-party call device, the device comprising:

The receiving module is used for subscribing the MPTY service of the multiparty call to the AMF network element of the access and mobile management function of the called party under the condition of receiving the session initiation protocol invite message SIP INVITE; wherein the multi-party call MPTY service comprises at least one of a voice transmission service, a video transmission service and a file transmission service;

The access module is used for sending the SIP when the subscription of the MPTY service of the multiparty call is completed: 183 to the proxy call session control function P-CSCF network element of the called party to trigger the multimedia telephony application server MMTel AS of the called party by the P-CSCF network element of the called party and to send the SIP via the S-CSCF network element of the called party: 183 message goes to the calling network to complete the called.

9. A terminal comprising a memory and a processor, the memory storing a computer program, characterized in that the processor implements the steps of the method of any of claims 1 to 6 when the computer program is executed.

10. A computer readable storage medium, on which a computer program is stored, characterized in that the computer program, when being executed by a processor, implements the steps of the method of any of claims 1 to 6.

11. A computer program product comprising a computer program, characterized in that the computer program, when being executed by a processor, implements the steps of the method of any of claims 1 to 6.