Calling method and apparatus

Abstract

A calling method and apparatus, relating to the field of wireless communications, and capable of reducing call delay and improving user experience. The method comprises: a first network element receiving a first message; determining a second message on the basis of the first message; and sending the second message, wherein both the first message and the second message comprise a media negotiation request, the first message does not comprise capability information of a first terminal device, and the second message further comprises the capability information of the first terminal device; or both the first message and the second message comprise media response information, the first message comprises capability information of a second terminal device, and the second message does not comprise the capability information of the second terminal device; the first terminal device is used for calling the second terminal device; and the first network element is a network element in an Internet protocol multimedia subsystem (IMS) network accessed by the first terminal device.

Description

Calling methods and devices

[0001] This application claims priority to Chinese Patent Application No. 202510389586.3, filed on March 27, 2025, entitled "Calling Method and Apparatus", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of wireless communication, and more specifically, to a calling method and apparatus. Background Technology

[0003] The 3rd Generation Partnership Project (3GPP) standard defines a call setup mechanism that enables communication between the calling and called parties.

[0004] Specifically, the call setup mechanism mainly includes four processes: call initiation media negotiation, temporary message confirmation, resource reservation confirmation, and ringing connection. Each of these four processes requires signaling interaction between the calling and called parties, resulting in significant call delays.

[0005] Therefore, how to reduce call latency is an urgent problem to be solved. Summary of the Invention

[0006] The calling method and apparatus provided in this application can reduce call latency and improve user experience.

[0007] In a first aspect, embodiments of this application provide a calling method, which can be executed by a first network element. Unless otherwise specified, the "first network element" in this application can be the first network element itself, a component applicable to the first network element (e.g., a communication module, processor, circuit, chip, or chip system), or a logic module or software capable of implementing all or part of the functions of the first network element. The method includes: receiving a first message; determining a second message based on the first message, and sending the second message; wherein both the first message and the second message contain a media negotiation request, the first message does not contain capability information of a first terminal device, and the second message also contains capability information of the first terminal device; or, both the first message and the second message contain media response information, the first message contains capability information of a second terminal device, and the second message does not contain capability information of the second terminal device, the first terminal device is used to call the second terminal device, and the first network element is a network element in the Protocol Multimedia Subsystem (IMS) network accessed by the first terminal device.

[0008] Based on the first aspect, considering that the media negotiation information (such as media negotiation request or media response information) during the call process carries information such as the media types and encodings supported by the terminal device, and that the media types and encodings supported by the terminal device constitute the terminal device's capability information; and that the media negotiation information exchanged between the calling and called terminal devices actually requires the IMS network elements of both parties to know in order to align the media types and encodings used by both parties during communication, the calling and called terminal devices can consider reporting this capability information in advance (i.e., reporting this capability information to their IMS network elements). Therefore, during the call process, the media negotiation information does not need to carry the terminal device's capability information (such as supported media types and encodings), and only requires the exchange of complete SIP signaling between the IMS network elements of both parties.

[0009] Specifically, for the calling IMS network element, if it receives a media negotiation request (i.e., the first message) from the calling terminal device, the first message does not contain the capability information of the calling terminal device (i.e., the first terminal device). Then, it needs to send the media negotiation request to the called IMS network element, so that the capability information of the calling terminal device can be added to the first message to obtain the second message, so that the IMS network elements of both parties can exchange complete SIP signaling.

[0010] If it receives media response information (i.e., the first message) from the IMS network element on the called side, since the IMS network elements of both parties exchange complete SIP signaling, the first message contains the capability information of the terminal device on the called side (i.e., the second terminal device). Then, it needs to send the media response information to the terminal device on the calling side, so that the capability information of the terminal device on the called side in the first message can be deleted to obtain the second message, thereby reducing the load of SIP signaling exchanged between the terminal device and the IMS network element.

[0011] In other words, the media negotiation information does not need to carry the terminal device's capability information during the interaction between the terminal device and its IMS network element. However, the media negotiation information carries the terminal device's capability information during the interaction between the two IMS network elements. This reduces the signaling load between the terminal device and the IMS network element, increases the signaling transmission rate, reduces transmission latency, and consequently reduces call latency and improves user experience.

[0012] In one possible design, the capability information of the terminal device includes the call coding formats supported by the terminal device, and the terminal device is either a first terminal device or a second terminal device.

[0013] Based on this possible design, it is understandable that the call encoding format in media negotiation information (such as media negotiation requests and media response information) consumes a significant amount of resources. However, since the call encoding format is a capability information of the terminal device, it can be reported in advance. Therefore, the call encoding format can be stored in the IMS network in advance. During the interaction between the terminal device and its IMS network element, the media negotiation information does not need to carry the call encoding format supported by the terminal device. When the IMS network elements of both parties interact, the media negotiation information carries the call encoding format, thereby reducing the signaling load of the interaction between the terminal device and the IMS network element, increasing the signaling transmission rate, reducing transmission latency, and thus reducing call latency and improving user experience.

[0014] In one possible design, the terminal device's capability information may also include one or more of the following: the terminal device's preferred information, SIP-related information supported by the terminal device, call characteristics supported by the terminal device, and Quality of Service (QoS) parameters in the Session Description Protocol (SDP) supported by the terminal device.

[0015] Based on this possible design, considering that terminal devices can report their capability information at any time, the capability information can be stored in the IMS network in advance. During the interaction between the terminal device and its IMS network element, the media negotiation information does not need to carry the terminal device's capability information. However, when the IMS network elements of both parties interact, the media negotiation information carries the capability information, thereby reducing the signaling load of the interaction between the terminal device and the IMS network element, increasing the signaling transmission rate, reducing transmission latency, and thus reducing call latency and improving user experience.

[0016] In one possible design, before determining the second message based on the first message, the method further includes: obtaining capability information of the terminal device.

[0017] Based on this possible design, since the signaling conversion performed by the first network element (i.e., determining the second message based on the first message) is actually adding or deleting the terminal device's capability information in the first message, the terminal device's capability information needs to be obtained in advance before performing the signaling conversion; thus, an implementation method is provided for its signaling conversion.

[0018] In one possible design, the terminal device is a first terminal device, and obtaining the capability information of the terminal device includes: receiving its capability information from the first terminal device.

[0019] In one possible design, the capability information of the first terminal device is included in the first request message, which is an IMS registration request for the first terminal device; or, before receiving the capability information from the first terminal device, the method further includes: receiving the first request message from the first terminal device.

[0020] In one possible design, the terminal device is a first terminal device, and the acquisition of terminal device capability information includes: receiving capability information of the first terminal device from a first core network device, wherein the first core network device is the core network device accessed by the first terminal device.

[0021] In one possible design, before receiving capability information from the first terminal device of the first core network device, the method further includes:

[0022] Receive a first request message from a first terminal device, the first request message being an IMS registration request from the first terminal device; send first instruction information to a first core network device, the first instruction information being used to instruct the first core network device to send capability information of the first terminal device.

[0023] Based on the above four possible designs, the first terminal device can report its capability information in different ways, providing different implementation methods for the first network element to obtain the capability information of the first terminal device.

[0024] In one possible design, the terminal device is a first terminal device, and the acquisition of the terminal device's capability information includes: receiving capability information of the second terminal device from a second network element, where the second network element is a network element in the IMS network accessed by the second terminal device.

[0025] Based on this possible design, the first network element can obtain the capability information of the second terminal device from the second network element, providing an optional implementation method for implementing signaling conversion based on the capability information of the terminal device.

[0026] In one possible design, the first message and the second message also include session static information. The method further includes: obtaining session static information from the first message; and storing the session static information, which includes one or more of the source address, destination address, or routing information of the message.

[0027] In one possible design, the method further includes: receiving a third message; determining a fourth message based on the session static information and the third message; and sending the fourth message; wherein the third message contains session static information and the fourth message does not contain session static information; or, the third message does not contain session static information and the fourth message contains session static information.

[0028] Based on the two possible designs mentioned above, it is understandable that during a call, the calling and called terminal devices will interact multiple times. During these interactions, the source address, destination address, or routing information (i.e., session static information) contained in the signaling in the same transmission direction will be the same. Therefore, even if the session static information is simplified, the session static information of the current transmission signaling can still be obtained from the session static information of the earlier transmitted signaling. Thus, the session static information in the signaling can be simplified (e.g., deleted). The simplified signaling can be used in the interaction between the terminal device and its IMS network element, further reducing the signaling load, increasing the signaling transmission rate, reducing transmission latency, and thus reducing call latency and improving user experience.

[0029] In one possible design, if the third message does not contain session static information and the fourth message does contain session static information, then the third and fourth messages are included in the temporary response acknowledgment PRACK message or the update UPDATA message; if the third message contains session static information and the fourth message does not contain session static information, then the third and fourth messages are included in the response message of the PRACK message or the response message of the UPDATA message.

[0030] In one possible design, before receiving the first message, the method further includes receiving second indication information, the second indication information being used to indicate that the signaling transmitted during the call does not contain capability information of the terminal device.

[0031] In one possible design, receiving the second instruction information includes: receiving second instruction information from the first terminal device; wherein the second instruction information is contained in a first request message, and the first request message is a registration request from the first terminal device; or, before receiving the second instruction information from the first terminal device, the method further includes: receiving first request information from the first terminal device.

[0032] In one possible design, both the first and second messages contain second indication information, which is used to indicate that the signaling transmitted during the call does not contain UE capability information.

[0033] Secondly, embodiments of this application provide a calling method, which can be executed by a first terminal device. Unless otherwise specified, the "first terminal device" in this application can be the first terminal device itself, a component applicable to the first terminal device (e.g., a communication module, processor, circuit, chip, or chip system), or a logic module or software capable of implementing all or part of the functions of the first terminal device. The method includes: obtaining a first message, the first message containing a media negotiation request or media response information, the first message not containing terminal device capability information, the terminal device being either a first terminal device or a second terminal device, the first terminal device being used to call the second terminal device; and executing a calling process according to the first message.

[0034] Based on the second aspect, considering that the media negotiation information (such as media negotiation request or media response information) during the call process carries information such as the media types and encodings supported by the terminal device, and that the media types and encodings supported by the terminal device constitute the terminal device's capability information; and that the media negotiation information exchanged between the calling and called terminal devices actually needs to be known by both parties' IMS network elements to align the media types and encodings used by both parties during communication, the calling and called terminal devices can consider reporting this capability information in advance (i.e., reporting this capability information to their IMS network elements). Therefore, during the call process, the media negotiation information does not need to carry the terminal device's capability information (such as supported media types and encodings), and only requires the exchange of complete SIP signaling between the IMS network elements of both parties.

[0035] Specifically, for the calling terminal device, the first message it can send does not contain the capability information of the calling terminal device (i.e., the first terminal device). Compared with the current signaling that carries media negotiation information, the first message has a smaller load, which can improve the signaling transmission rate, reduce transmission latency, and thus reduce call latency and improve user experience.

[0036] In one possible design, the terminal device's capability information includes the call coding formats supported by the terminal device.

[0037] In one possible design, the terminal device's capability information may also include one or more of the following: the terminal device's preferred information, SIP-related information supported by the terminal device, call characteristics supported by the terminal device, and Quality of Service (QoS) parameters in the SDP supported by the terminal device.

[0038] In one possible design, before obtaining the first message, the method further includes sending capability information of the first terminal device.

[0039] In one possible design, the capability information of the first terminal device is included in the first request message, which is an IMS registration request for the first terminal device; or, before sending the capability information of the first terminal device, the method further includes sending the first request message.

[0040] In one possible design, the first message contains a media negotiation request. Obtaining the first message includes generating the first message. Accordingly, the call process is executed based on the first message, including sending the first message.

[0041] In one possible design, before sending the first message, the method further includes: obtaining the address information of a first network element, wherein the first network element is a network element in the IMS network accessed by the first terminal device; and sending the first message, including: sending the first message to the first network element.

[0042] In one possible design, obtaining the address information of the first network element includes: sending a second request message, the second request message being a packet data network (PDN) connection request for the first terminal device; and receiving a second response message, the second response message being used to indicate the establishment of a PDN connection for the first terminal device, the second response message containing the address information of the first network element.

[0043] In one possible design, the first message contains media response information, and obtaining the first message includes receiving the first message.

[0044] In one possible design, the method further includes: obtaining a third message, which does not contain session static information, and the session static information contains one or more of the message's source address, destination address, or routing information.

[0045] In one possible design, obtaining a third message includes: generating a third message.

[0046] In one possible design, the third message is included in the temporary response acknowledgment PRACK message or the update UPDATA message.

[0047] In one possible design, obtaining a third message includes receiving a third message contained in the response message of a PRACK message or the response message of an UPDATA message.

[0048] In one possible design, before receiving the first message, the method further includes sending a second indication message, the second indication message being used to indicate that the signaling transmitted during the call does not contain capability information of the terminal device.

[0049] In one possible design, the second instruction information is included in the first request message, which is a registration request for the first terminal device; or, before sending the second instruction information, the method further includes sending the first request message.

[0050] In one possible design, the first message contains a second indication information, which indicates that the signaling transmitted during the call does not contain terminal device capability information.

[0051] The technical effects of any design in the second aspect can be referenced from the technical effects of the corresponding design in the first aspect, and will not be elaborated here.

[0052] Thirdly, embodiments of this application provide a communication method, which can be executed by a first terminal device. Unless otherwise specified, the "first terminal device" in this application can be the first terminal device itself, a component applicable to the first terminal device (e.g., a communication module, processor, circuit, chip, or chip system), or a logic module or software capable of implementing all or part of the functions of the first terminal device. The method includes: determining the address information of a first network element based on the network access method of the first terminal device. The network access method of the first terminal device includes the first terminal device accessing a narrowband high-speed rail network. The first network element is a network element in the Protocol Multimedia Subsystem (IMS) network accessed by the first terminal device. The first network element supports the mutual conversion between signaling containing terminal device capability information and signaling not containing terminal device capability information during a call. The terminal device can be either the first terminal device or a second terminal device, with the first terminal device used to call the second terminal device; and sending the address information of the first network element.

[0053] Based on the third aspect, it is understandable that narrowband high-speed rail has a lower transmission rate, resulting in a larger transmission delay. Therefore, to reduce transmission delay, it is advisable to select an IMS network element that supports the mutual conversion between signaling containing terminal device capability information and signaling without such information. This allows the IMS network element to transmit signaling without terminal device capability information during the interaction between the terminal device and its IMS network element, while using signaling containing terminal device capability information during the interaction between the two IMS network elements. This reduces the signaling load between the terminal device and the IMS network element, increases the signaling transmission rate, reduces transmission delay, and ultimately reduces call delay, improving the user experience.

[0054] In one possible design, before determining the address information of the first network element based on the access network method of the first terminal device, the method further includes: receiving a second request message, the second request message being a packet data network (PDN) connection request for the first terminal device; and sending the address information of the first network element, including: sending a second response message, the second response message being used to indicate the establishment of a PDN connection for the first terminal device, the second response message containing the address information of the first network element.

[0055] In one possible design, the method further includes: sending capability information of the first terminal device.

[0056] In one possible design, before sending the capability information of the first terminal device, the method further includes: receiving first indication information, the first indication information being used to instruct the first core network device to send the capability information of the first terminal device.

[0057] In one possible design, the capability information of the first terminal device includes the call coding formats supported by the first terminal device.

[0058] The technical effects of any design in the third aspect can be referenced from the technical effects of the corresponding design in the first aspect, and will not be elaborated here.

[0059] Fourthly, a communication device is provided for implementing various methods. This communication device can be a first network element in the first aspect, a first terminal device in the second aspect, or a first core network device in the third aspect, such as a device, chip, or chip system. The communication device includes modules, units, or means corresponding to the implementation of the methods. These modules, units, or means can be implemented in hardware, software, or by hardware executing corresponding software. The hardware or software includes one or more modules or units corresponding to the functions.

[0060] In some possible designs, the communication device may include a processing module and a transceiver module. The processing module can be used to implement the processing functions in any of the above aspects and any possible implementations thereof. The transceiver module may include a receiving module and a transmitting module, respectively used to implement the receiving function and the transmitting function in any of the above aspects and any possible implementations thereof.

[0061] In some possible designs, the transceiver module can consist of transceiver circuits, transceivers, transceivers, or communication interfaces.

[0062] Fifthly, a communication device is provided, comprising: a processor and a memory; the memory is used to store computer instructions, which, when executed by the processor, cause the communication device to perform the method described in any aspect. The communication device may be a first network element in the first aspect, a first terminal device in the second aspect, or a first core network device in the third aspect, such as a device, chip, or chip system. The communication device includes modules, units, or means corresponding to the implementation of the method, which may be implemented in hardware, software, or by hardware executing corresponding software. The hardware or software includes one or more modules or units corresponding to the function.

[0063] A sixth aspect provides a communication device, comprising: a processor and a communication interface; the communication interface being used to communicate with a module outside the communication device; the processor being used to execute computer programs or instructions to cause the communication device to perform the method described in any aspect. The communication device may be a first network element in the first aspect, a first terminal device in the second aspect, or a first core network device in the third aspect, such as a device, chip, or chip system. The communication device includes modules, units, or means corresponding to the implementation method, which may be implemented in hardware, software, or by hardware executing corresponding software. The hardware or software includes one or more modules or units corresponding to the function.

[0064] A seventh aspect provides a communication device, comprising: at least one processor; the processor being configured to execute a computer program or instructions to cause the communication device to perform the method described in any aspect. The communication device may be a first network element in the first aspect, a first terminal device in the second aspect, or a first core network device in the third aspect, such as a device, chip, or chip system. The communication device includes modules, units, or means corresponding to the implementation of the method, which may be implemented in hardware, software, or by hardware executing corresponding software. The hardware or software includes one or more modules or units corresponding to the functions.

[0065] In some possible designs, the communication device includes a memory for storing at least one of necessary programs, instructions, or data. The memory may be coupled to the processor, or it may be independent of the processor.

[0066] In some possible designs, when the device is a chip system, it can be composed of chips or contain chips and other discrete components.

[0067] It is understandable that when the communication device provided in any of the fourth to seventh aspects is a chip, the sending action / function of the communication device can be understood as outputting information, and the receiving action / function of the communication device can be understood as inputting information.

[0068] The aforementioned first terminal device may be a terminal device, or a communication module in a terminal device, or a chip in a terminal device that is responsible for communication functions, such as a modem chip (also known as a baseband chip), or a system-on-chip (SoC) chip or system-in-a-package (SIP) chip that includes a modem module.

[0069] And / or, the aforementioned first network element may be an IMS network element, or a communication module in an IMS network element, or a circuit or chip in an IMS network element responsible for communication functions, or a functional module in a network device capable of calling and executing programs.

[0070] Eighthly, a computer-readable storage medium is provided that stores a computer program or instructions that, when executed on a communication device, enable the communication device to perform the method described in either aspect.

[0071] In a ninth aspect, a computer program product containing instructions is provided that, when run on a communication device, enables the communication device to perform the method described in either aspect.

[0072] In a tenth aspect, a communication system is provided, comprising a first network element (e.g., an IMS network element, a chip or chip system applied to the IMS network element) in the first aspect, a first terminal device (e.g., a terminal device, a chip or chip system applied to the terminal device) in the second aspect, and a first core network device (e.g., a core network device, a chip or chip system applied to the core network device) in the third aspect.

[0073] The technical effects of any of the design methods in aspects four through ten can be found in the technical effects of the different design methods in aspects one through three above, and will not be repeated here. Attached Figure Description

[0074] Figures 1 and 2 are schematic diagrams of the network architecture provided in the embodiments of this application;

[0075] Figure 3 is a schematic diagram of a call flow provided in an embodiment of this application;

[0076] Figure 4 is a schematic diagram of a call setup process provided in an embodiment of this application;

[0077] Figure 5 is a schematic diagram of the architecture of a communication system applied in an embodiment of this application;

[0078] Figures 6 to 17 are schematic flowcharts of the calling method provided in the embodiments of this application;

[0079] Figure 18 is a schematic diagram of the structure of a communication device provided in an embodiment of this application;

[0080] Figure 19 is a schematic diagram of another communication device provided in an embodiment of this application;

[0081] Figure 20 is a schematic diagram of another communication device provided in an embodiment of this application. Detailed Implementation

[0082] Before describing the embodiments of this application, the technical terms involved in the embodiments of this application will be described.

[0083] 1. Mobile network architecture:

[0084] The mobile network architecture defined in the 3rd Generation Partnership Project (3GPP) standard is mainly divided into two parts: the access network (AN) and the core network. The access network is used to implement functions related to radio access.

[0085] The fourth-generation (4G) network architecture includes: the access network, which may include the evolved UMTS terrestrial radio access network (E-UTRAN); and the core network, which mainly includes the following key logical network elements: mobility management entity (MME), serving gateway (S-GW), packet data network (PDN) gateway (P-GW), home subscriber server (HSS), policy and charging control function (PCRF), and serving GPRS support node (SGSN).

[0086] Referring to Figure 1, this is a schematic diagram of a 4G non-roaming network architecture. The terminal device can be user equipment (UE), such as a mobile phone or an IoT terminal. The UE can access the network through E-UTRAN.

[0087] The MME (Mobile Equipment Manager) primarily handles complex signaling and user identity management, including functions such as user mobility management, session management, and security control. The S-GW (Service Gateway) is mainly responsible for user data forwarding and session management, such as handling packet routing and forwarding to ensure efficient data transmission. The P-GW (Public Network Gateway) is primarily responsible for user network protocol (IP) address allocation, session management, policy enforcement, and billing. The HSS (Hospital Service Controller) is a central database storing user subscription information, including user authentication information and service profiles. The PCRF (Programmable Request for Radio Functions) is primarily responsible for formulating and implementing policy refinement and billing rules to ensure quality of service (QoS) and reasonable billing. The SGSN (Service Grid Service Controller) is primarily responsible for forwarding IP packets between mobile stations (MS) and external networks within its service area.

[0088] In addition, the 4G network architecture can also include the UMTS terrestrial radio access network (UTRAN) and the Global System for Mobile Communications (GMS) edge radio access network (GERAN). UTRAN is a 3rd generation (3G) access network, while GERAN is a 2nd generation (2G) GMS network access network. UTRAN and GERAN can be deployed as backup networks within the 4G network for 2G or 3G devices with insufficient coverage or those that do not support 4G network access.

[0089] Furthermore, referring to Figure 1, S1-MME is the control plane protocol interface between E-UTRAN and MME; S1-U is the user plane interface between E-UTRAN and S-GW, used for user data transmission; S3 is the interface between MME and SGSN, used for interoperability between 4G long term evolution (LTE) and 3G UMTS networks (such as handover and user context transfer); S4 is the interface between S-GW and SGSN, used for 4G... User plane data transmission between LTE and 3G UMTS networks; S5 is the interface between S-GW and P-GW, used for user plane data transmission and management; S6a is the interface between MME and HSS, used for user authentication and authorization; S10 is the interface between MMEs, used for user context transmission between MMEs; S11 is the interface between MME and S-GW, used for control plane signaling transmission (such as session management, bearer establishment, etc.); S12 is the interface between S-GW and UTRAN, used for user plane data transmission; Gx is the interface between PCRF and P-GW, used for policy and charging control; Rx is the interface between PCRF and external application function (AF), used for dynamic policy control; where AF can be an IP multimedia subsystem (IMS).

[0090] The 5th generation (5G) network architecture consists of: an access network (AN) which may include a radio access network (RAN); and a core network (CN) which mainly includes the following key logical network elements: user plane function (UPF), authentication server function (AUSF), access and mobility management function (AMF), session management function (SMF), network slice selection function (NSSF), network exposure function (NEF), network repository function (NRF), policy control function (PCF), unified data management (UDM), unified data repository (UDR), and application function (AF).

[0091] Referring to Figure 2, this is a schematic diagram of a 5G non-roaming network architecture. The terminal device can be a UE, such as a mobile phone or an IoT terminal. The UE can access the network through the RAN.

[0092] The AMF (Agency Mobile Provider) network element is primarily responsible for mobility management in the mobile network, such as user location updates, user registration with the network, and user handover. The SMF (Segment Management Provider) network element is primarily responsible for session management in the mobile network, such as session establishment, modification, and release. Specific functions include allocating IP addresses to users and selecting the UPF (User Platform Provider) to provide packet forwarding. The PCF (Physical PC Provider) network element is primarily responsible for providing policies to the AMF and SMF, such as QoS policies and slice selection policies. The UDM (User DM) network element is primarily responsible for storing user data, such as subscription information and authentication / authorization information. The AF (Agency Provider) network element is primarily responsible for providing service requirements to the 3GPP network, such as influencing service routing and interacting with the PCF network element for policy control. The UPF (User Platform Provider) network element is primarily responsible for processing user packets, such as forwarding and billing. Terminal devices access the data network (DN) by establishing Protocol Data Unit (PDU) sessions between the terminal device and the RAN (Radio Access Network), UPF, and DN (Digital Network Provider). The DN is mainly used to provide data transmission services to users; for example, the DN can be IMS (Integrated Mobile Service). The AUSF (User USF) network element is primarily responsible for providing terminal authentication services to the AMF network element. The NSSF network element is primarily responsible for network slicing selected as the terminal service.

[0093] Furthermore, referring to Figure 2, Nx represents the logical interface or service interface between two network elements, used for communication between network elements. For example, N1 is the interface between the terminal and the AMF network element; N2 is the interface between the access network device and the AMF network element; N3 is the interface between the access network device and the UPF network element; N9 is the interface between different UPF network elements; N6 is the interface between the UPF network element and the DN; and N4 is the interface between the UPF network element and the SMF network element.

[0094] Furthermore, the control plane functions shown in Figure 2, such as AUSF, AMF, SMF, NSSF, NEF, NRF, PCF, UDM, UDR, or AF, interact using service-oriented interfaces. For example, the service-oriented interface provided by AUSF is Nausf; AMF is Namf; SMF is Nsmf; NSSF is Nnssf; NEF is Nnef; NRF is Nnrf; PCF is Npcf; UDM is Nudm; UDR is Nudr; and AF is Naf.

[0095] 2. Non-terrestrial networks (NTN):

[0096] Fifth-generation (5G) new radio (NR) technology is evolving from release 18 (Rle18 / R18) to R19. Simultaneously, NR technology has moved from the standardization phase to commercial deployment. The initial research on the NR standard protocol was for wireless communication technologies designed for terrestrial cellular network scenarios, capable of providing users with low latency, ultra-reliability, ultra-high speed, and massive connectivity wireless communication services. However, cellular networks cannot achieve seamless global coverage. For example, in areas without terrestrial base stations, such as ocean areas, polar regions, and rainforests, voice and data services cannot be provided to areas covered by cellular networks.

[0097] Compared to terrestrial communications, NTN communications offer significant advantages such as global coverage, long-distance transmission, flexible networking, convenient deployment, and freedom from geographical limitations. It has been widely applied in various fields including maritime communications, positioning and navigation, disaster relief, scientific experiments, video broadcasting, and Earth observation. NTN networks can be integrated with terrestrial networks, leveraging their respective strengths to create a seamless, globally integrated sea, land, air, space, and ground communications network, meeting the diverse and ubiquitous service needs of users.

[0098] Depending on the altitude of the flight platform above the ground, the NTN can include a low altitude platform (LAP) subnetwork, a high altitude platform (HAP) subnetwork, and a satellite communication subnetwork.

[0099] For example, in a LAP subnetwork, base stations or base station functions are deployed on low-altitude flight platforms (e.g., drones) at an altitude of 0.1km to 1km above the ground to provide coverage for terminals; in a HAP subnetwork, base stations or base station functions are deployed on high-altitude flight platforms (e.g., aircraft) at an altitude of 8km to 50km above the ground to provide coverage for terminals; and in a SATCOM subnetwork, base stations or base station functions are deployed on satellites at an altitude of more than 50km above the ground to provide coverage for terminals. Satellite communication has significant advantages such as global coverage, long-distance transmission, flexible networking, convenient deployment, and no geographical limitations, and has been widely used in various fields such as maritime communication, positioning and navigation, disaster relief, scientific experiments, video broadcasting, and Earth observation. Furthermore, satellites in satellite communication systems typically transmit information via inter-satellite links (ISL) or satellite-to-ground links.

[0100] Furthermore, based on the satellite's orbital altitude, satellite communication systems can be divided into geostationary earth orbit (GEO) satellite communication systems, medium earth orbit (MEO) satellite communication systems, and low-earth orbit (LEO) satellite communication systems.

[0101] GEO satellite communication systems, also known as geostationary orbit satellite systems or high Earth orbit satellite communication systems (abbreviated as GEO satellite communication systems), operate at an altitude of 35,786 km. Their orbital speed is the same as the Earth's rotation speed, meaning GEO satellites can remain stationary relative to the ground. GEO satellite communication systems can provide large cell coverage, typically with a cell diameter of 500 km. MEO satellites operate at altitudes between 2,000 and 35,786 km, achieving global coverage with a relatively small number of satellites. LEO satellites operate at altitudes between 300 and 2,000 km, lower than MEO satellites. They offer advantages such as low transmission latency, low transmission loss, and relatively low launch costs.

[0102] 3. IMS:

[0103] IMS is the collective term for the logical functional entities of the network core layer that control IP multimedia services. The IMS network is built on the operator's network using IP technology and can provide a wealth of telecom-grade multimedia services such as high-definition audio / video calls, video ringback tones, and teleconferencing.

[0104] The core functional entity of the IMS network is the Call Session Control Function (CSCF). It is primarily responsible for handling signaling control during multimedia call sessions and forming the Session Initialization Protocol (SIP) routing system. The CSCF includes the Proxy-Call Session Control Function (P-CSCF) and the Service-Call Session Control Function (S-CSCF) network elements. The P-CSCF is the first network element encountered by the user in the IMS system; all SIP signaling traffic from the user must be sent to the P-CSCF. Correspondingly, all terminating SIP signaling traffic from the network must be sent from the P-CSCF to the user equipment (UE). The S-CSCF is the core of the IMS system, providing session control services to the UE and maintaining session state according to the operator's needs to support services.

[0105] Therefore, as shown in Figure 3(a), for two UEs (i.e., UE#1 and UE#2) with a call requirement (such as a voice call or a video call), the transmission path of SIP signaling (such as signaling #1) from UE#1 to UE#2 is: UE#1 → Access Network Device #1 → Core Network Device #1 → P-CSCF Network Element #1 → S-CSCF Network Element #1 → S-CSCF Network Element #2 → P-CSCF Network Element #2 → Core Network Device #2 → Access Network Device #2 → UE#2. Correspondingly, the transmission path of SIP signaling (such as signaling #2) from UE#2 to UE#1 is: UE#2 → Access Network Device #2 → Core Network Device #2 → P-CSCF Network Element #2 → S-CSCF Network Element #2 → S-CSCF Network Element #1 → P-CSCF Network Element #1 → Core Network Device #1 → Access Network Device #1 → UE#1. Among them, UE#1, access network equipment #1, core network equipment #1, P-CSCF network element #1, and S-CSCF network element #1 are all calling side equipment; UE#2, access network equipment #2, core network equipment #2, P-CSCF network element #2, and S-CSCF network element #2 are all called side equipment.

[0106] Optionally, the P-CSCF network element and the S-CSCF network element can also be collectively referred to as the IMS network element; thus, as shown in Figure 3(b), the transmission path of SIP signaling (such as signaling #1) from UE#1 to UE#2 is: UE#1 → Access Network Equipment #1 → Core Network Equipment #1 → IMS Network Element #1 → IMS Network Element #2 → Core Network Equipment #2 → Access Network Equipment #2 → UE#2. Correspondingly, the transmission path of SIP signaling (such as signaling #2) from UE#2 to UE#1 is: UE#2 → Access Network Equipment #2 → Core Network Equipment #2 → IMS Network Element #2 → IMS Network Element #1 → Core Network Equipment #1 → Access Network Equipment #1 → UE#1. Among them, UE#1, Access Network Equipment #1, Core Network Equipment #1, and IMS Network Element #1 are all calling side devices; UE#2, Access Network Equipment #2, Core Network Equipment #2, and IMS Network Element #2 are all called side devices.

[0107] The calling party establishment process defined in the 3GPP standard can include four stages: call initiation-media negotiation, provisional message confirmation, resource reservation confirmation, and ringing connection. Specifically, as shown in Figure 4, during the call initiation-media negotiation process, the calling UE (i.e., UE#1) can initiate a call request (such as an INVITE message) to the called UE. Furthermore, this call request is also used to initiate a media negotiation request (i.e., a Session Description Protocol (SDP) offer) to the called UE. For example, the INVITE message contains the called UE's (i.e., UE#2) number, the media types and encodings supported by the calling UE, etc., where the media negotiation request contains the media types and encodings supported by the calling UE. Correspondingly, after receiving the call request, the called UE can send a media response message (such as a 183 message, i.e., a 183 session progress message) to the calling UE. This media response message is used to indicate the called UE's media response (i.e., an SDP answer). For example, the 183 message (or SDP answer) contains information such as the media types and encodings supported by the called UE.

[0108] Furthermore, during the call initiation-media negotiation process, after the calling party's Internet Protocol (IP) Multimedia Subsystem (IMS) network element (i.e., IMS network element #1) receives the call request, it can send a response message (such as a 100 Trying message) to the calling party's UE to indicate that the calling party's IMS network element has received the call request and is processing it (e.g., sending it to the called party's IMS network element (i.e., IMS network element #2)).

[0109] Furthermore, after the calling side's IMS network element receives the media response message from the called side, it can send a message to the calling side's core network equipment (i.e., core network equipment #1) to trigger the core network equipment to establish the calling side UE's call bearer (or, the bearer used for the call). After the calling side UE's call bearer is established, the calling side's core network equipment can inform the calling side's IMS network element. In addition, the core network equipment can also inform the calling side UE that the calling side UE's call bearer has been established.

[0110] During the provisional message acknowledgment process, after receiving the media response message, the calling UE can send a provisional response acknowledgement (PRACK) message to the called UE to indicate that the calling UE has received the media response message. Correspondingly, after receiving the PRACK message, the called UE sends a PRACK response message (such as a PRACK200OK message) to the calling UE to indicate that the called UE has received the PRACK message.

[0111] During the resource reservation confirmation process, after the calling UE learns that its call bearer establishment is complete (e.g., from the core network equipment on the calling side), it sends an update message (e.g., an UPDATA message) to the called UE to indicate that the calling UE's call resource reservation has been successful. Correspondingly, after receiving this update message and learning that its call bearer establishment is complete, the called UE can send a response message (e.g., an UPDATA 200OK message) to the calling UE to indicate that the called UE's call bearer establishment is complete.

[0112] In this context, "call bearer establishment completed" signifies "call resource reservation successful"; that is, in this application, "call bearer establishment completed" and "call resource reservation successful" have the same meaning and can be used interchangeably.

[0113] During the ringing and connection process, after the called UE sends a response message to the calling UE in response to an update message, the called UE rings and notifies the calling UE (i.e., sends a 180 message (e.g., a 180ring message) to the calling UE to indicate that the called UE has rung). Further, the called UE answers and notifies the calling UE (i.e., sends a response message corresponding to the call request (e.g., an INVITE 200OK message) to the calling UE to indicate that the called UE has answered). Upon receiving the INVITE 200OK message, the calling UE can send an acknowledgment (ACK) message to the called UE. Thus, the calling UE can then communicate with the called UE.

[0114] In the call setup process shown in Figure 4 above, the time delay between the moment the calling UE sends the call request and the moment it receives the 180 message is called the call delay. For example, the implementation of the signaling interaction between the calling UE and the called UE in Figure 4 above can be found in the relevant description in Figure 3(b) above, and will not be repeated here.

[0115] In addition, during a call, devices typically interact using Session Initialization Protocol (SIP) signaling. That is, the INVITE message, 183 message, PRACK message, PRACK 200OK message, UPDATA message, UPDATA200OK message, 180ring message, INVITE 200OK message, and ACK message mentioned above are all SIP signaling.

[0116] With the widespread application of machine-type communication (MTC) and Internet of Things (IoT) communication in 5G NR, the number of IoT devices connected to the network is increasing, necessitating consideration of cost and power consumption requirements for IoT devices. Based on these cost and power consumption needs, narrowband IoT (NB-IoT) devices can be considered. NB-IoT devices can achieve power consumption down to the milliwatt (mW) level.

[0117] Especially in NTN scenarios, narrow-band (NB) high-orbit satellites (or NB-IoT high-orbit satellites) supporting voice services have become an industry trend. However, compared to terrestrial networks (TN), narrow-band high-orbit satellites have lower transmission rates, resulting in greater transmission latency. In particular, signaling carrying SDP offers (such as INVITE and 183 messages) and SDP answers (such as 183 messages) carries UE-supported media types and encoding information, leading to a heavy SIP signaling load and consequently, significant call latency (e.g., greater than or equal to 80 seconds), thus degrading the user experience. Therefore, reducing call latency and improving user experience is an urgent problem to be solved.

[0118] Based on this, this application provides a calling method that considers the media negotiation information (such as media negotiation request or media response information) during the call process carrying information such as the media types and encodings supported by the terminal device. This information constitutes the terminal device's capability information. Furthermore, the media negotiation information exchanged between the calling and called terminal devices actually requires the IMS network elements of both parties to be aware of it in order to align the media types and encodings used by both parties during communication. Therefore, the calling and called terminal devices can consider reporting this capability information in advance (i.e., reporting this capability information to their IMS network elements). Consequently, during the call process, the media negotiation information does not need to carry the terminal device's capability information (such as supported media types and encodings); only complete SIP signaling needs to be exchanged between the IMS network elements of both parties.

[0119] Specifically, for the calling IMS network element, if it receives a media negotiation request (i.e., the first message) from the calling terminal device, the first message does not contain the capability information of the calling terminal device (i.e., the first terminal device). Then, it needs to send the media negotiation request to the called IMS network element, so that the capability information of the calling terminal device can be added to the first message to obtain the second message, so that the IMS network elements of both parties can exchange complete SIP signaling.

[0120] If it receives media response information (i.e., the first message) from the IMS network element on the called side, since the IMS network elements of both parties exchange complete SIP signaling, the first message contains the capability information of the terminal device on the called side (i.e., the second terminal device). Then, it needs to send the media response information to the terminal device on the calling side, so that the capability information of the terminal device on the called side in the first message can be deleted to obtain the second message, thereby reducing the load of SIP signaling exchanged between the terminal device and the IMS network element.

[0121] In other words, the media negotiation information does not need to carry the terminal device's capability information during the interaction between the terminal device and its IMS network element. However, the media negotiation information carries the terminal device's capability information during the interaction between the two IMS network elements. This reduces the signaling load between the terminal device and the IMS network element, increases the signaling transmission rate, reduces transmission latency, and consequently reduces call latency and improves user experience.

[0122] The technical solution provided in this application can be used in various communication systems, including high altitude platform station (HAPS) satellite communication systems, unmanned aerial vehicle (UAV) and other NTN systems, such as integrated communication and navigation (ICAN) systems, global navigation satellite systems (GNSS), and ultra-dense low-Earth orbit (LEO) satellite communication systems. Satellite communication systems can be integrated with traditional mobile communication systems. For example, the mobile communication system can be a 3GPP-related cellular system, such as the 4th generation (4G) long term evolution (LTE) system, the worldwide interoperability for microwave access (WiMAX) communication system, the evolved LTE system (LTE-Advanced, LTE-A) system, the 5G NR system, the vehicle to everything (V2X) system, the LTE and NR hybrid networking system, or the device-to-device (D2D) system, the machine-to-machine (M2M) communication system, the Internet of Things (IoT), and other future communication systems.

[0123] Alternatively, the communication system may be a non-3GPP communication system, such as an open radio access network (O-RAN or ORAN), a cloud radio access network (CRAN), or a communication system that integrates multiple of the above communication systems. This application does not impose any restrictions.

[0124] The communication systems and scenarios applicable to this application mentioned above are merely illustrative examples. The communication systems and scenarios applicable to this application are not limited thereto. The communication systems and scenarios provided in this application do not impose any limitations on the solutions of this application. This is hereby stated uniformly and will not be repeated below.

[0125] This application provides an exemplary communication system. As shown in FIG5(a), the communication system may include at least one calling-side terminal device, at least one calling-side IMS network element, at least one called-side IMS network element, and at least one called-side terminal device.

[0126] During the signaling interaction between the calling and called terminal devices, the signaling can be sent from the calling terminal device to the calling IMS network element, then from the calling IMS network element to the called IMS network element, and finally from the called IMS network element to the called terminal device (i.e., the signaling transmission path is: calling terminal device → calling IMS network element → called IMS network element → called terminal device).

[0127] And / or, the signaling can be sent from the terminal equipment on the called side to the IMS network element on the called side, and then from the IMS network element on the called side to the IMS network element on the calling side, and then from the IMS network element on the calling side to the terminal equipment on the calling side (that is, the transmission path of the signaling is: terminal equipment on the called side → IMS network element on the called side → IMS network element on the calling side → terminal equipment on the calling side).

[0128] Furthermore, during signaling interaction between the terminal device and the IMS network element (such as signaling interaction between the calling terminal device and the calling IMS network element, and / or signaling interaction between the called terminal device and the called IMS network element), the signaling sent by the terminal device can be transmitted to the IMS network element sequentially through the access network device and the core network device (i.e., the signaling transmission path is: terminal device → access network device → core network device → IMS network element); correspondingly, the signaling sent by the IMS network element can be transmitted to the terminal device sequentially through the access network device and the core network device (i.e., the signaling transmission path is: IMS network element → core network device → access network device → terminal device).

[0129] Therefore, this communication system also includes access network equipment on the calling side, core network equipment on the calling side, access network equipment on the called side, and core network equipment on the called side. In the NTN scenario, this communication system also includes non-terrestrial platforms (such as low-altitude platforms (e.g., drones), high-altitude platforms (e.g., aircraft), or satellites; for ease of description, satellites will be used as an example below, and will not be elaborated further) and NTN gateways. Typically, NTN gateways are deployed on the ground. NTN gateways can communicate with satellites; the link between the satellite and the NTN gateway can be called a feeder link.

[0130] Specifically, as shown in Figure 5(b), when the satellite acts as a wireless relay node, or in other words, when the satellite has relay forwarding capabilities, the NTN gateway has the functions of a base station or part of a base station. In this case, the NTN gateway can function as an access network device. Alternatively, the NTN gateway can be deployed separately from the access network device. Figure 5(b) illustrates this using the example of deploying the NTN gateway and access network device separately. In this case, the signaling sent by the terminal device can be transmitted sequentially through the satellite and the NTN gateway to the access network device (i.e., the signaling transmission path is: terminal device → satellite → NTN gateway → access network device); correspondingly, the signaling sent by the access network device can be transmitted sequentially through the NTN gateway and the satellite to the terminal device (i.e., the signaling transmission path is: access network device → NTN gateway → satellite → terminal device).

[0131] Furthermore, IMS network elements include P-CSCF network elements and S-CSCF network elements (e.g., the calling side's IMS network elements include both the calling side's P-CSCF network elements and the calling side's S-CSCF network elements; the called side's IMS network elements include both the called side's P-CSCF network elements and the called side's S-CSCF network elements). Therefore, the signaling transmission from the access network device to the IMS network element includes: the access network device sending the signaling to the P-CSCF network element, which then forwards the signaling to the S-CSCF network element; correspondingly, the signaling transmission from the IMS network element to the access network device includes: the S-CSCF network element sending the signaling to the P-CSCF network element, which then forwards the signaling to the access network device.

[0132] The signaling interaction between the calling side's IMS network element and the called side's IMS network element includes: the calling side's S-CSCF network element sending signaling to the called side's S-CSCF network element; and / or, the called side's S-CSCF network element sending signaling to the calling side's S-CSCF network element.

[0133] Furthermore, in the architecture shown in Figure 5(b), NG refers to the interface between the access network device and the core network device. Uu refers to the interface between the access network device and the terminal device. It is understood that as the communication system evolves, the interface names between the access network device and the core network device, and between the access network device and the terminal device, may also change, and this application does not specifically limit them.

[0134] It should be noted that in this application, during the transmission of a signaling message from the source address (i.e., the IP address of the first device to send the signaling message) to the destination address (i.e., the IP address of the last device to receive the signaling message), when the signaling message passes through an intermediate device, the intermediate device may forward the signaling message directly to the next node without making any modifications to it (i.e., pass-through forwarding); or, the intermediate device may modify or adjust the signaling message and transmit the modified or adjusted new signaling message to the next node.

[0135] For example, the terminal equipment shown in (a) or (b) of Figure 5 above can be a device or module that is connected to the aforementioned communication system and has corresponding communication functions. Terminal equipment can also be called user equipment (UE), mobile station, mobile terminal, etc. Terminal equipment can be widely used in various scenarios, such as device-to-device (D2D), vehicle-to-everything (V2X) communication, machine-type communication (MTC), Internet of Things (IoT), virtual reality, augmented reality, industrial control, autonomous driving, telemedicine, smart grid, smart furniture, smart office, smart wearables, smart transportation, smart cities, etc. Terminal equipment can be mobile phones, tablets, computers with wireless transceiver capabilities, wearable devices, vehicles, drones, helicopters, airplanes, ships, robots, robotic arms, smart home devices, transportation vehicles with wireless communication capabilities, communication modules, etc. The embodiments of this application do not limit the form of the terminal equipment. Terminal equipment typically contains communication modules, circuits, or chips that perform corresponding communication functions. The terminal device is also configured with program instructions for performing corresponding communication functions.

[0136] The access network device shown in Figure 3(b) above, sometimes also called a RAN entity or access node, is part of a communication system used to help terminal devices achieve wireless access. In one possible scenario, the access network device can be a base station, an evolved NodeB (eNodeB), an access point (AP), a transmission reception point (TRP), a next-generation NodeB (gNB), a base station in a future mobile communication system, or an access node in a WiFi system. The access network device can be a macro base station, a micro base station or an indoor station, a relay node or a donor node, or a radio controller in a CRAN scenario. Optionally, the access network device can also be a server, a wearable device, a vehicle, or an in-vehicle device. For example, the RAN node in vehicle-to-everything (V2X) technology can be a roadside unit (RSU). All or part of the functions of the access network device in this application can also be implemented through software functions running on hardware, or through virtualization functions instantiated on a platform (e.g., a cloud platform). The access network device may also include communication modules, circuits, or chips that perform corresponding communication functions. The access network device may also be configured with program instructions for performing corresponding communication functions, as well as corresponding program instructions. The access network device in this application may also be a logical node, logical module, or software capable of implementing all or part of the functions of an access network device.

[0137] In another possible scenario, multiple access network devices collaborate to assist terminal devices in achieving wireless access, with each access network device performing a portion of the base station's functions. For example, the access network devices can be a central unit (CU), a distributed unit (DU), a CU-control plane (CP), a CU-user plane (UP), or a radio unit (RU), etc. The CU and DU can be configured separately or included in the same network element, such as a baseband unit (BBU). The RU can be included in radio frequency equipment or radio frequency units, such as a remote radio unit (RRU), an active antenna unit (AAU), or a remote radio head (RRH).

[0138] In different systems, CU (or CU-CP and CU-UP), DU, or RU may have different names, but those skilled in the art will understand their meaning. For example, in an ORAN system, CU can also be called O-CU (open CU), DU can also be called O-DU, CU-CP can also be called O-CU-CP, CU-UP can also be called O-CU-UP, and RU can also be called O-RU. For ease of description, this application uses CU, CU-CP, CU-UP, DU, and RU as examples. Any of the units among CU (or CU-CP, CU-UP), DU, and RU in this application can be implemented through software modules, hardware modules, or a combination of software and hardware modules.

[0139] In some embodiments, the CU and DU can be divided according to the protocol layer of the wireless network: for example, the functions of the Packet Data Convergence Protocol (PDCP) layer and above (such as the Radio Resource Control (RRC) layer and the Service Data Adaptation Protocol (SDAP) layer) are set in the CU, and the functions of the protocol layers below the PDCP layer (such as the Radio Link Control (RLC) layer, the Media Access Control (MAC) layer, or the Physical (PHY) layer) are set in the DU; or, for example, the functions of the protocol layers above the PDCP layer are set in the CU, and the functions of the protocol layers below the PDCP layer are set in the DU, without restriction.

[0140] The above division of CU and DU processing functions according to protocol layers is merely an example; other methods can also be used. For instance, CUs or DUs can be divided into those with more protocol layer functions, or they can be divided into those with partial protocol layer processing functions. For example, some functions of the RLC layer and the protocol layer functions above the RLC layer can be placed in the CU, while the remaining functions of the RLC layer and the protocol layer functions below the RLC layer can be placed in the DU. Furthermore, the functions of CUs or DUs can be divided according to service type or other system requirements, such as by latency. Functions that need to meet latency requirements can be placed in the DU, while functions that do not need to meet this latency requirement can be placed in the CU.

[0141] In some embodiments, the RU may be included in a radio frequency device or radio frequency unit, such as a remote radio unit (RRU), an active antenna unit (AAU), or a remote radio head (RRH).

[0142] In some embodiments, when the RAN node is an access network device or a module of an access network device in an open ORAN system, in the ORAN system, CU can also be called open (O)-CU, DU can also be called O-DU, CU-CP can also be called O-CU-CP, CU-UP can also be called O-CU-UP, and RU can also be called O-RU. Any of the units among CU (or CU-CP, CU-UP), DU, and RU in this application can be implemented by a software module, a hardware module, or a combination of a software module and a hardware module.

[0143] In different systems, CU (or CU-CP and CU-UP), DU, or RU may have different names, but those skilled in the art will understand their meaning. For example, in an ORAN system, CU may also be called O-CU (open CU), DU may also be called O-DU, CU-CP may also be called O-CU-CP, CU-UP may also be called O-CU-UP, and RU may also be called O-RU.

[0144] The following description, in conjunction with the communication system shown in Figure 5 and Figure 6 in the following embodiments, takes the interaction between the calling terminal device, the called terminal device, the calling IMS network element, and the called IMS network element as an example to further illustrate the calling method provided in this application.

[0145] Figure 6 is a flowchart illustrating a calling method provided in an embodiment of this application; as shown in Figure 6, the method may include the following steps:

[0146] S601, network element #1 sends a first message to network element #2; correspondingly, network element #2 receives the first message from network element #1.

[0147] S602 and network element #2 determine the second message based on the first message.

[0148] S603, network element #2 sends a second message to network element #3; correspondingly, network element #3 receives the second message from network element #2.

[0149] Among them, network element #2 is a network element in the IMS network accessed by the terminal equipment on the calling side, and both the first message and the second message contain media negotiation information.

[0150] For example, since network element #2 is a network element in the IMS network accessed by the terminal equipment on the calling side, network element #2 can also be called the IMS network element on the calling side.

[0151] Optionally, the first message can be a simplified second message; in this case, network element #2 determining the second message based on the first message can also be considered as restoring the first message to the complete message (i.e., the second message). Alternatively, the second message can be a simplified first message; in this case, network element #2 determining the second message based on the first message can also be considered as simplifying the complete message (i.e., the first message) to obtain the second message.

[0152] For example, "simplifying the complete message" can be understood as deleting certain information from the complete message. In other words, the difference between a simplified message and a complete message is that the simplified message includes this information. For ease of description, the implementation of the first and second messages will be described below using the example of this information including media negotiation information.

[0153] For example, based on different implementations of media negotiation information, the first message and the second message can be implemented in the following two scenarios:

[0154] Scenario 1: The media negotiation information is a media negotiation request (such as an SDP offer). That is, both the first and second messages contain a media negotiation request.

[0155] For example, the signaling that typically carries a media negotiation request is an INVITE message; therefore, both the first message and the second message are INVITE messages; or, both the first message and the second message are contained within an INVITE message.

[0156] It is understandable that INVITE messages are usually sent from the calling side's terminal equipment to the calling side's IMS network element, and then the calling side's IMS network element sends them to the called side's IMS network element; therefore, network element #1 in Figure 6 above is the calling side's terminal equipment, and network element #3 is the called side's IMS network element.

[0157] Therefore, step S601 can be replaced by step S601A as shown in Figure 7: the calling terminal device sends a first message to the calling IMS network element; correspondingly, the calling IMS network element receives the first message from the calling terminal device.

[0158] The first message does not contain capability information of the calling terminal device, while the second message contains capability information of the calling terminal device used to call the called terminal device. Therefore, in this scenario, the first message is a simplified version of the second message. For example, the calling terminal device can send the first message to the calling IMS network element via the IP-connectivity access network (IP-CAN). Here, IP-CAN is a collection of network entities and interfaces connecting the UE and the IMS network element.

[0159] Specifically, IP-CAN can include access network equipment and core network equipment. That is, the calling terminal device can sequentially send the first message to the calling IMS network element through the calling access network equipment and the calling core network equipment. The transmission path of the first message is: calling terminal device → calling access network equipment → calling core network equipment → calling IMS network element. In this case, the communication system also includes the calling access network equipment and the calling core network equipment.

[0160] Wherein, after receiving the first message from its previous node (such as the previous node of the access network device on the calling side being the terminal device on the calling side, and the previous node of the core network device on the calling side being the access network device on the calling side), either the calling side access network device or the calling side core network device can choose not to process the first message and directly forward it to the next node; or, it can modify or adjust the first message and send the modified or adjusted first message to the next node.

[0161] It is understandable that the access network equipment on the calling side can also be referred to as the first access network equipment, and the core network equipment on the calling side can also be referred to as the first core network equipment.

[0162] Optionally, the IMS network element on the calling side may include the P-CSCF network element and the S-CSCF network element on the calling side. In this case, step S601A can also be replaced by: the terminal device on the calling side sending a first message to the P-CSCF network element on the calling side; correspondingly, the P-CSCF network element on the calling side receives the first message from the terminal device on the calling side.

[0163] It is understandable that the calling side's terminal equipment can also be referred to as the first terminal equipment, and the calling side's IMS network element can also be referred to as the first network element; similarly, the called side's terminal equipment can also be referred to as the second terminal equipment, and the called side's IMS network element can also be referred to as the second network element. That is, the called side's IMS network element is the network element in the IMS network that the calling side's terminal equipment accesses.

[0164] In one example, the first message may be directly generated by the calling party's terminal device. That is, before step S601A, the call method further includes the step of: the calling party's terminal device generating the first message.

[0165] Specifically, when generating the first message, the calling terminal device may consider not including the calling terminal device's capability information in the first message.

[0166] In another example, the first message may be determined by the calling terminal device based on message #1. Message #1 contains capability information of the calling terminal device.

[0167] Specifically, the calling terminal device can generate message #1 during the call, and then determine the first message based on message #1. That is, before step S601A, the call method further includes the steps of: the calling terminal device generating message #1; and determining the first message based on message #1.

[0168] For example, after the calling terminal device generates message #1, it can delete the capability information of the calling terminal device contained in message #1 to obtain the first message.

[0169] For example, the method of generating message #1 is similar to the method of generating the call request described in Figure 4 above. For details, please refer to the implementation of the call request above, which will not be repeated here.

[0170] Combining the two examples above, and exemplarily based on the aforementioned related technologies, it is known that in scenarios where terminal devices use narrowband high-speed rail access, significant call delays can occur during the call process. Therefore, the solution proposed in this application reduces call delays. Thus, before determining the first message, the calling terminal device can determine whether it is in a narrowband high-speed rail access scenario. If so, it determines the first message and executes step S601A as described above. If not, it does not need to determine the first message; it can directly determine message #2 and send it to the calling IMS network element. Consequently, the calling IMS network element does not need to perform signaling conversion (as in step S602) and can directly send message #2 to the called IMS network element.

[0171] For example, a media negotiation request includes a session-level description field, a media-level description field, and other optional fields.

[0172] (a) The session-level description field includes the SDP protocol version number, session source information, session name, connection information, and session time.

[0173] The version number field of the SDP protocol can be represented by the field: v =; the version number of the SDP protocol is usually 0, that is, v = 0.

[0174] Session source information can be represented by the field: o=. Session source information includes the username, session ID, session version number, network type, address type, and address. For example, o=rue 4103 4103 IN IP6 2409:8131:615:ffa9::1. Here, rue is the username, the first 4103 is the session ID, the second 4103 is the session version number, IN (i.e., Internet) is the network type, IP6 (i.e., IPv6) is the address type, and 2409:8131:615:ffa9::1 is the IP address.

[0175] The session name can be represented by the field s=; if the session name is unknown, "-" can be used, i.e., s=-.

[0176] Connection information can be represented by the field: c=; the connection information includes the network type, address type, and connection address. For example, c=IN IP62409:8131:615:ffa9::1. Here, IN (i.e., Internet) is the network type, IP6 (i.e., IPv6) is the address type, and 2409:8131:615:ffa9::1 is the IP address (i.e., the connection address).

[0177] Session duration can be represented by the field: t=; session duration includes start and end times. For example, t=0 0. Here, 0 0 indicates that there is no limit to the session duration.

[0178] (ii) The media-level description field contains media information and attribute rows.

[0179] Media information can be represented by the field: m=. Media information includes media type, port, transport protocol, and media format. For example, m=audio 31006 RTP / AVP 110 107 106 105 104 101 102. Here, audio is the media type (e.g., audio, video, etc.), 31006 is the port number of the media stream, real-time transport protocol (RTP) / audio video profile (AVP) is the transport protocol (e.g., RTP / AVP, RTP, session announcement protocol (SAVP), etc.), and 110 107 106 105 104 101 102 are the media formats (e.g., the RTP payload type of the codec).

[0180] The attribute row describes additional attributes of the media stream and can be represented by the field: a=. The attribute row contains the mapping between the RTP payload type and the codec, the codec format parameters, and the transmission direction of the media stream. The mapping between the RTP payload type and the codec can be defined using rtpmap, and the codec format parameters can be defined using fmtp.

[0181] For example, a = rtpmap:110EVS / 16000 / 1. Here, 110 is the RTP payload type, Enhance Voice Services (EVS) is the codec (such as Pulse Code Modulation with μ-law Companding (PCMU), Pulse Code Modulation A-law (PCMA), H.264, EVA, etc.), and 16000 is the sampling rate (Hz). Another example is a = fmtp:110br = 5.9-24.4; bw = nb-swb; max-red = 220. Here, br = 5.9-24.4; bw = nb-swb:max-red = 220 are the encoder format parameters corresponding to RTP payload type 110.

[0182] The transmission direction of a media stream can include one or more of the following: bidirectional (sendrecv), sendonly, recvnoly, and inactive.

[0183] (iii) Other optional fields include bandwidth information.

[0184] Bandwidth information can be represented by the field: b=, which indicates the bandwidth requirements of the media stream. For example, b=AS:50. Here, AS represents the application layer bandwidth, and 50 is the bandwidth value (kbps).

[0185] Based on the above description of media negotiation requests, the media format (such as the RTP payload type of the codec) in the media-level description field, as well as the mapping between the RTP payload type and the codec, and the codec format parameters in the attribute row, all represent the capability information of the calling party's terminal equipment, i.e., the call encoding formats supported by the calling party's terminal equipment. Therefore, the first message does not contain the call encoding formats supported by the calling party's terminal equipment, while the second message does.

[0186] For example, the call encoding formats supported by the calling terminal equipment may include low-rate encoding formats for narrowband high-orbit voice, such as 2.4kbps, 1.2kbps, 0.8kbps, and 0.5kbps, as well as other voice encoding and decoding formats, such as AMR-NB (4.75-12.2kbps) and AMR-WB (up to 23.85kbps).

[0187] For example, the call encoding format supported by the calling party's terminal device can also be understood as: the call encoding format supported by the calling party. For instance, the call encoding format supported by the calling party as described in this application can be a call encoding format that the calling party's terminal device actually supports; or it can be a call encoding format that the calling party's terminal device does not actually support, but which the calling party's IMS network element can transcode. For example, in a narrowband high-speed rail access scenario, the calling party's terminal device only supports low bit rate formats, but considering that the called party may not support low bit rate formats, the calling party's IMS network element will add other encoding formats. In this case, the call encoding format supported by the calling party as described in this application can include these other encoding formats.

[0188] For example, a media negotiation request may include the fields shown in Table 1, meaning the second message may include the fields shown in Table 1:

[0189] Table 1

[0190] Based on the above description of media negotiation requests, the bolded fields mentioned above contain the codec information supported by the calling terminal device for the call. Therefore, the first message may not contain the bolded fields; the second message may contain all of the above fields.

[0191] Optionally, in scenario one, step S602 can be replaced with step S602A as shown in Figure 7: the calling side IMS network element determines the second message based on the first message.

[0192] For example, after receiving the first message, the calling side's IMS network element can add the calling side's terminal device capability information to the first message to obtain the second message. This allows the second message to contain the calling side's terminal device capability information. Specifically, the calling side's terminal device capability information can include the call encoding formats supported by the calling side's terminal device.

[0193] Specifically, the capability information of the terminal device can be pre-stored in the IMS network of the calling and called parties. Thus, in step S602A, the IMS network element on the calling side determines the second message based on the first message and the capability information of the terminal device. The implementation of pre-storing the capability information of the terminal device can be found in the relevant description in the following embodiments, and will not be repeated here.

[0194] Optionally, if the IMS network element on the calling side may include the P-CSCF network element and the S-CSCF network element on the calling side, then step S602A can also be replaced by: the P-CSCF network element on the calling side determines the second message based on the first message.

[0195] Optionally, in one scenario, step S603 can be replaced by step S603A as shown in Figure 7: the calling side IMS network element sends a second message to the called side IMS network element; correspondingly, the called side IMS network element receives the second message from the calling side IMS network element.

[0196] For example, the calling side's IMS network elements may include the calling side's P-CSCF network element and the calling side's S-CSCF network element; the called side's IMS network elements may include the called side's P-CSCF network element and the called side's S-CSCF network element. In this case, the calling side's IMS network element sending a second message to the called side's IMS network element may include: the calling side's P-CSCF network element sending the second message to the called side's P-CSCF network element through the calling side's S-CSCF network element and the called side's S-CSCF network element. That is, the transmission path of the second message is: calling side's P-CSCF network element → calling side's S-CSCF network element → called side's S-CSCF network element → called side's P-CSCF network element.

[0197] Optionally, after step S603A, as shown in Figure 7, the calling method further includes steps S604A to S605A:

[0198] S604A, the called party's IMS network element determines message #2 according to the second message.

[0199] For example, after receiving the second message, the IMS network element on the called side can delete the capability information of the calling side's terminal equipment from the second message, resulting in message #2. This ensures that message #2 does not contain the capability information of the calling side's terminal equipment.

[0200] Optionally, if the IMS network element on the called side may include the P-CSCF network element and the S-CSCF network element on the called side, then step S604A can also be replaced by: the P-CSCF network element on the called side determines message #2 according to the second message.

[0201] Specifically, based on the aforementioned related technologies, it is known that in scenarios where terminal devices are accessed via narrowband high-speed rail, significant call delays may occur during the call process. Therefore, the proposed solution reduces call delays. Thus, before the called party's IMS network element converts the signaling (such as executing step S604), it can be determined whether the called party's terminal device is in a scenario where it is accessed via narrowband high-speed rail. If so, step S604A is executed. If not, there is no need to perform signaling conversion, and the second message can be directly sent to the called party's terminal device.

[0202] Specifically, the capability information of the calling terminal device may include the call encoding formats supported by the calling terminal device. The implementation type of message #2 is the same as that of the first message mentioned above; please refer to the relevant description of the first message for details, which will not be repeated here.

[0203] S605A, the IMS network element on the called side sends message #2 to the terminal device on the called side; correspondingly, the terminal device on the called side receives message #2 from the IMS network element on the called side.

[0204] For example, the IMS network element on the called side can send message #2 to the terminal device on the called side via IP-CAN. Here, IP-CAN is a collection of network entities and interfaces that connect the UE and the IMS network element.

[0205] Specifically, IP-CAN can include access network equipment and core network equipment. That is, the IMS network element on the called side can sequentially send the first message to the called side terminal equipment through the called side core network equipment and the called side access network equipment. In other words, the transmission path of message #2 is: called side IMS network element → called side core network equipment → called side access network equipment → called side terminal equipment. At this time, the communication system also includes the called side access network equipment and the called side core network equipment.

[0206] Wherein, after receiving the first message from its previous node (e.g., the previous node of the called-side access network device and / or the called-side core network device is the called-side access network device, and the previous node of the called-side access network device is the called-side IMS network element), the calling-side device may not process the first message and directly forward it to the next node; or, it may modify or adjust the first message and send the modified or adjusted first message to the next node.

[0207] Optionally, if the IMS network element on the called side may include the P-CSCF network element and the S-CSCF network element on the called side, then step S605A can also be replaced by: the P-CSCF network element on the called side sending a first message to the terminal device on the called side; correspondingly, the terminal device on the called side receives the first message from the P-CSCF network element on the called side.

[0208] It is understandable that the access network equipment on the called side can also be referred to as the second access network equipment, and the core network equipment on the called side can also be referred to as the second core network equipment.

[0209] In conjunction with the method described in Scenario 1 above, when the calling terminal device sends signaling (such as an INVITE message) to the called terminal device, it can determine whether simplified signaling is used for interaction between the calling terminal device and the calling IMS network element based on whether the calling terminal device is based on a narrowband high-orbit access network.

[0210] Using this signaling as an INVITE message, if the calling terminal device is based on a narrowband high-speed access network, it transmits a simplified INVITE message with the calling IMS network element (i.e., the calling terminal device generates a simplified INVITE message and sends it to the calling IMS network element). If the calling terminal device is based on a non-narrowband high-speed access network, it can generate a complete INVITE message (such as the standard-defined INVITE message), and then transmit the complete INVITE message with its IMS network element.

[0211] Furthermore, if the calling IMS network element receives a complete INVITE message, it directly forwards the INVITE message to the called IMS network element. If the calling IMS network element receives a simplified INVITE message, it restores the simplified INVITE message to a complete INVITE message and sends the complete INVITE message to the called IMS network. In other words, regardless of whether the calling terminal equipment is based on a narrowband high-speed access network, the calling IMS network element and the called IMS network element always transmit complete signaling (i.e., a complete INVITE message).

[0212] Furthermore, after receiving the complete INVITE message, the IMS network element on the called side can determine whether to transmit a complete INVITE message or a simplified INVITE message between the called side's terminal device and its IMS network element, based on whether the called side's terminal device is accessed via a narrowband high-speed network. Specifically, if the called side's terminal device is accessed via a non-narrowband high-speed network, the called side's terminal device and its IMS network element will transmit a complete INVITE message; that is, after receiving the complete INVITE message, the called side's IMS network element can send the complete INVITE message to the called side's terminal device. If the called side's terminal device is accessed via a narrowband high-speed network, the called side's terminal device and its IMS network element will transmit a simplified INVITE message; that is, after receiving the complete INVITE message, the called side's IMS network element can convert the complete INVITE message into a simplified INVITE message and send the simplified INVITE message to the called side's terminal device. Based on Scenario 1, consider that the media negotiation request during a call carries the call coding format supported by the terminal device, and the call coding format supported by the terminal device is the terminal device's capability information. Furthermore, the media negotiation request transmitted between the calling and called terminal devices actually requires the IMS network elements of both parties to know and align the call coding formats used by both parties during communication. Therefore, the calling and called terminal devices can consider reporting this capability information in advance (i.e., reporting this capability information to their IMS network elements). Consequently, during the call, the media negotiation request does not need to carry the terminal device's capability information (such as supported call coding formats); only complete SIP signaling needs to be exchanged between the IMS network elements of both parties.

[0213] For example, the calling side's IMS network element receives a media negotiation request (i.e., the first message) from the calling side's terminal device. At this time, the first message does not contain the capability information of the calling side's terminal device (i.e., the first terminal device). Then, it needs to send the media negotiation request to the called side's IMS network element, so that the capability information of the calling side's terminal device can be added to the first message to obtain the second message, so that the IMS network elements of both parties can exchange complete SIP signaling.

[0214] In other words, the media negotiation request does not need to carry the terminal device's capability information during transmission between the terminal device and its IMS network element. However, the media negotiation request carries the terminal device's capability information during interaction between the two IMS network elements. This reduces the signaling load between the terminal device and the IMS network element, increases the signaling transmission rate, reduces transmission latency, and consequently reduces call latency and improves user experience.

[0215] Scenario 2: Media negotiation information is media response information (such as SDP answer). That is, both the first and second messages contain media response information.

[0216] For example, during a call, the signaling carrying the media response can be any one of the following: 183 message, PRACK 200 OK message, UPDATA 200 OK message, 180 message, or INVITE 200 OK message.

[0217] For ease of description, the implementation of the first and second messages is described below using the 183 message carrying media response as an example. The implementation of the first and second messages is similar to that of the first and second messages in the case where the signaling carrying media response is any one of the PRACK 200 OK message, UPDATA 200 OK message, 180 message, or INVITE 200 OK message. For details, please refer to the relevant descriptions in the following embodiments, which will not be repeated here.

[0218] Optionally, both the first and second messages can be 183 messages; or, both the first and second messages can be included in a 183 message.

[0219] It is understandable that the 183 message is usually sent by the terminal device on the called side to the IMS network element on the called side, and then the IMS network element on the called side sends it to the IMS network element on the calling side, and finally the IMS network element on the calling side sends it to the terminal device on the calling side. Therefore, network element #1 in Figure 6 above is the IMS network element on the called side, and network element #3 is the terminal device on the calling side.

[0220] Therefore, step S601 can be replaced by step S601B as shown in Figure 8: the called side IMS network element sends a first message to the calling side IMS network element; correspondingly, the calling side IMS network element receives the first message from the called side IMS network element.

[0221] In this scenario, the first message contains the capability information of the called party's terminal device, while the second message does not. The calling party's terminal device is used to call the called party's terminal device. Therefore, in scenario two, the second message is a simplified version of the first message.

[0222] For example, the calling side's IMS network elements may include the calling side's P-CSCF network element and the calling side's S-CSCF network element; the called side's IMS network elements may include the called side's P-CSCF network element and the called side's S-CSCF network element. In this case, the called side's IMS network element sending a first message to the calling side's IMS network element may include: the called side's P-CSCF network element sending the first message to the calling side's P-CSCF network element through the called side's S-CSCF network element and the calling side's S-CSCF network element. That is, the transmission path of the first message is: called side's P-CSCF network element → called side's S-CSCF network element → calling side's S-CSCF network element → calling side's P-CSCF network element.

[0223] Optionally, before step S601B, as shown in FIG8, the calling method further includes steps S600B#1 to S600B#2:

[0224] S600B#1: The called-side terminal device sends message #3 to the called-side IMS network element; correspondingly, the called-side IMS network element receives message #3 from the calling-side terminal device. Message #3 does not contain capability information of the called-side terminal device.

[0225] Optionally, the IMS network element on the called side may include the P-CSCF network element and the S-CSCF network element on the called side. Then, step S600B#1 can also be replaced by: the terminal device on the called side sending message #3 to the P-CSCF network element on the called side; correspondingly, the P-CSCF network element on the called side receives message #3 from the terminal device on the called side.

[0226] For example, the interaction between the called-side terminal device and the called-side IMS network element in step S600B#1 is similar to the interaction between the calling-side terminal device and the calling-side IMS network element in step S601A above. For details, please refer to the relevant description of step S601A above, which will not be repeated here.

[0227] It is understandable that the calling side's terminal equipment can also be referred to as the first terminal equipment, and the calling side's IMS network element can also be referred to as the first network element; similarly, the called side's terminal equipment can also be referred to as the second terminal equipment, and the called side's IMS network element can also be referred to as the second network element. That is, the called side's IMS network element is the network element in the IMS network that the calling side's terminal equipment accesses.

[0228] In one example, message #3 can be directly generated by the called party's terminal device. That is, before step S600B#1, the call method further includes the step of: the called party's terminal device generating message #3.

[0229] Specifically, when generating message #3, the called party's terminal device may consider not including the called party's terminal device's capability information in message #3.

[0230] In another example, message #3 may be determined by the called party's terminal device based on message #4, where message #4 contains capability information of the called party's terminal device.

[0231] Specifically, the called party's terminal device can generate message #4 during the call, and then determine message #3 based on message #4. That is, before step S600B#1, the call method further includes the steps of: the called party's terminal device generating message #4; and determining message #3 based on message #4.

[0232] For example, after the called-side terminal device generates message #4, it can delete the capability information of the called-side terminal device contained in message #4 to obtain message #3.

[0233] The generation method of the exemplary message #4 is similar to that of message 183 described in Figure 4 above. For details, please refer to the implementation of message 183 above, which will not be repeated here.

[0234] Combining the two examples above, and exemplarily based on the aforementioned related technologies, it is known that in scenarios where terminal devices use narrowband high-speed rail access, significant call delays can occur during the call process. Therefore, the proposed solution reduces call delays. Thus, before the called-side terminal device determines message #3, it can determine whether it is in a narrowband high-speed rail access scenario. If so, it determines message #3 and executes the aforementioned step S600B#1; if not, it does not need to determine message #3, and can directly determine message #4 and send it to the calling-side IMS network element. Consequently, the calling-side IMS network element also does not need to perform signaling conversion (as shown in step S600B#2 below), and can directly send message #4 to the calling-side IMS network element.

[0235] For example, the media response information includes a session-level description field, a media-level description field, and other optional fields. Specifically, the session-level description field, media-level description field, and other optional fields can be found in the relevant descriptions in Scenario 1 above, and will not be repeated here.

[0236] For example, media response information can include the fields shown in Table 2, meaning the first message can include the fields shown in Table 2:

[0237] Table 2

[0238] Based on the above description of media response information, the bolded content in the aforementioned fields includes the call encoding formats supported by the called party's terminal equipment. Therefore, the second message may not contain the bolded fields; the first message may contain all of the aforementioned fields.

[0239] It should be noted that the call coding formats supported by the called-side terminal equipment as described in this application can be understood as the call coding formats supported by the called side among the call coding formats supported by the calling side. In other words, the call coding formats supported by the called-side terminal equipment are actually the intersection of the call coding formats supported by the calling side and the call coding formats supported by the called side, or, in other words, a subset of the call coding formats supported by the calling side.

[0240] The call encoding format supported by the calling side can be either a format that the calling side's terminal equipment actually supports, or a format that the calling side's terminal equipment does not actually support, but which the calling side's IMS network element can transcode. Similarly, the call encoding format supported by the called side can be either a format that the called side's terminal equipment actually supports, or a format that the called side's terminal equipment does not actually support, but which the called side's IMS network element can transcode.

[0241] S600B#2, the called party's IMS network element determines the first message based on message #3.

[0242] For example, after receiving message #3, the IMS network element on the called side can add the capability information of the called side's terminal device to the first message to obtain the first message. This allows the first message to contain the capability information of the called side's terminal device. Specifically, the capability information of the called side's terminal device can include the call encoding formats supported by the called side's terminal device.

[0243] Optionally, if the IMS network element on the called side may include the P-CSCF network element and the S-CSCF network element on the called side, then step S600B#2 can also be replaced by: the P-CSCF network element on the called side determines the first message according to message #3.

[0244] Optionally, in scenario two, step S602 can be replaced by step S602B as shown in Figure 8: the calling side IMS network element determines the second message based on the first message.

[0245] For example, after receiving the first message, the calling side's IMS network element can remove the called side's terminal device capability information from the first message to obtain the second message. This ensures that the second message does not contain the called side's terminal device capability information. Specifically, the called side's terminal device capability information may include the call encoding formats supported by the called side's terminal device.

[0246] Specifically, the capability information of the terminal device can be pre-stored in the IMS network of the calling and called parties. Thus, in step S602B, the IMS network element on the calling side determines the second message based on the first message and the capability information of the terminal device. The implementation of pre-storing the capability information of the terminal device can be found in the relevant description in the following embodiments, and will not be repeated here.

[0247] Optionally, if the IMS network element on the calling side may include the P-CSCF network element and the S-CSCF network element on the calling side, then step S602B can also be replaced by: the P-CSCF network element on the calling side determines the second message based on the first message.

[0248] Specifically, based on the aforementioned related technologies, it is known that in scenarios where terminal devices are accessed via narrowband high-speed rail, significant call delays may occur during the call process. Therefore, the proposed solution reduces call delays. Thus, before the IMS network element on the calling side converts the signaling (such as executing step S602B), it can be determined whether the terminal device on the calling side is in a scenario where it is accessed via narrowband high-speed rail. If so, step S602B is executed; if not, there is no need to perform signaling conversion, and the first message can be directly sent to the terminal device on the calling side.

[0249] Optionally, in scenario two, step S603 can be replaced by step S603B as shown in Figure 8: the calling side's IMS network element sends a second message to the calling side's terminal device; correspondingly, the calling side's terminal device receives the second message from the calling side's IMS network element.

[0250] Optionally, if the IMS network element on the calling side may include the P-CSCF network element and the S-CSCF network element on the calling side, then step S602B can also be replaced by: the P-CSCF network element on the calling side sending a second message to the terminal device on the calling side; correspondingly, the terminal device on the calling side receives the second message from the P-CSCF network element on the calling side.

[0251] For example, the interaction between the calling terminal device and the calling IMS network element in step S603B is similar to the interaction between the called terminal device and the called IMS network element in step S605A above. For details, please refer to the relevant description of step S605A above, which will not be repeated here.

[0252] In conjunction with the method described in Scenario 2 above, when the called terminal device sends signaling (such as a 183 message) to the calling terminal device, it can determine whether simplified signaling is used for interaction between the called terminal device and the called IMS network element based on whether the called terminal device is based on a narrowband high-orbit access network.

[0253] Taking the 183 message as an example, if the called party's terminal equipment is based on a narrowband high-speed access network, a simplified 183 message will be transmitted between it and the called party's IMS network element (i.e., the called party's terminal equipment generates a simplified 183 message and sends it to the called party's IMS network element). If the called party's terminal equipment is based on a non-narrowband high-speed access network, a complete 183 message can be generated (such as the standard 183 message), and then the complete 183 message will be transmitted between the called party's terminal equipment and its IMS network element.

[0254] Furthermore, if the called party's IMS network element receives a complete 183 message, it directly forwards the 183 message to the calling party's IMS network element. If the called party's IMS network element receives a simplified 183 message, it reconstructs the simplified 183 message into a complete 183 message and sends the complete 183 message to the calling party's IMS network. In other words, regardless of whether the called party's terminal equipment is based on a narrowband high-speed access network, the calling party's IMS network element and the called party's IMS network element always transmit complete signaling (i.e., a complete 183 message).

[0255] Furthermore, after receiving the complete 183 message, the IMS network element on the calling side can determine whether the terminal device on the calling side is transmitting a complete 183 message or a simplified 183 message between itself and the IMS network element, based on whether the terminal device on the calling side is accessed via a narrowband high-speed network. Specifically, if the terminal device on the calling side is accessed via a non-narrowband high-speed network, the terminal device on the calling side will transmit a complete 183 message; that is, after receiving the complete 183 message, the IMS network element on the calling side can send the complete 183 message to the terminal device on the calling side. If the terminal device on the calling side is accessed via a narrowband high-speed network, the terminal device on the calling side will transmit a simplified 183 message; that is, after receiving the complete 183 message, the IMS network element on the calling side can convert the complete 183 message into a simplified 183 message and send the simplified 183 message to the terminal device on the calling side.

[0256] Based on Scenario 2, consider that the media response information during a call carries the call encoding formats supported by the terminal device, and the call encoding formats supported by the terminal device are the terminal device's capability information. Furthermore, the media response information transmitted between the calling and called terminal devices actually needs to be known by both parties' IMS network elements to align the call encoding formats used during communication. Therefore, the calling and called terminal devices can consider reporting this capability information in advance (i.e., reporting this capability information to their IMS network elements). Consequently, during the call, the media response information does not need to carry the terminal device's capability information (such as supported media types and encoding information), and only requires the exchange of complete SIP signaling between the two parties' IMS network elements.

[0257] For example, if the calling IMS network element receives media response information (i.e., the first message) from the called IMS network element, since the IMS network elements of both sides exchange complete SIP signaling, the first message contains the capability information of the called terminal device (i.e., the second terminal device). Then, it needs to send the media response information to the calling terminal device, so that the capability information of the called terminal device in the first message can be deleted to obtain the second message, thereby reducing the load of SIP signaling exchanged between the terminal device and the IMS network element.

[0258] In other words, the media negotiation request does not need to carry the terminal device's capability information during transmission between the terminal device and its IMS network element. However, the media negotiation request carries the terminal device's capability information during interaction between the two IMS network elements. This reduces the signaling load between the terminal device and the IMS network element, increases the signaling transmission rate, reduces transmission latency, and consequently reduces call latency and improves user experience.

[0259] The above examples illustrate the implementation process of the calling method described in this application under different scenarios, using different implementations of media negotiation information as examples. The following section provides a detailed description of the "terminal device capability information" involved in the above embodiments. Here, the terminal device refers to either the calling side's terminal device or the called side's terminal device.

[0260] Optionally, the capability information of the terminal device includes, but is not limited to, one or more of the following: the terminal device's preferred information, SIP-related information supported by the terminal device, call characteristics supported by the terminal device, QoS parameters in the SDP supported by the terminal device, and transmission behavior of early-media supported by the terminal device.

[0261] For example, the QoS parameters in the SDP supported by the terminal device are usually located in the media negotiation information; such as the fields a=curr:qos local none, a=curr:qos remote none, a=des:qos mandatory local sendrecv, a=des:qos option remote sendrecv mentioned in Table 1 or Table 2 above.

[0262] For example, the preferred information of a terminal device is used to indicate the type of service or service identifier (for the operator or manufacturer) that the terminal device wishes to use. Specifically, the preferred information of the terminal device may be located in the P-Preferred-service field and / or the P-Preferred-identity field.

[0263] For example, the transmission line of early media supported by the terminal device can be located in the P-early-Media field.

[0264] For example, the SIP-related information supported by the terminal device may be located in one or more of the following fields: supported (option tags for supported SIP signaling extensions), allow (indicating the SIP methods allowed by the terminal device), user-agent, accept, accept-contact (indicating the contact information of the user initiating the request that the terminal device can accept), and contact.

[0265] For example, the call features supported by the terminal device can be located in the contact field (used to indicate the contact information of the user initiating the request). The extended information in the contact field contains the call features supported by the terminal device. For example, the extended information could include: +g.3gpp.mid-call; +g.3gpp.srvcc-alerting; +g.3gpp.ps2cs-srvcc-orig-pre-alerting.

[0266] As an example, in addition to the media negotiation request, the INVITE message typically includes the fields shown in Table 3; that is, the INVITE message typically includes the fields shown in Tables 1 and 3:

[0267] Table 3

[0268] Combining Tables 1 and 3 above, it can be seen that the bolded fields in Tables 1 and 3, as well as the fields a=curr:qos local none, a=curr:qos remote none, a=des:qos mandatory local sendrecv, and a=des:qos option remote sendrecv, are all used for terminal device capability information. Therefore, the first message does not include the bolded fields in Tables 1 and 3, nor the fields a=curr:qos local none, a=curr:qos remote none, a=des:qos mandatory local sendrecv, and a=des:qos option remote sendrecv; the second message can include all fields from Tables 1 and 3.

[0269] For example, if both the first and second messages are INVITE messages, it means that the INVITE messages transmitted between the terminal device and its IMS network element do not contain the bolded fields in Tables 1 and 3, nor the fields a=curr:qos local none, a=curr:qos remote none, a=des:qos mandatory local sendrecv, and a=des:qos option remote sendrecv; the INVITE messages transmitted between the calling and called IMS network elements contain all the fields in Tables 1 and 3.

[0270] In addition, the INVITE message typically contains some general and duplicate information. For example, general information may include the information indicated by the Min-SE field and the information indicated by the Max-Forwards field in Table 1. Duplicate information includes IP addresses (e.g., IN IP62409:8131:615:ffa9::1) and bandwidth information (e.g., fields such as b=AS:50, b=RR:1875, b=RS:625, etc.). General information can also be pre-stored in the calling and called party IMS network elements along with the terminal device's capability information, and duplicate information can be considered for deletion; therefore, the first message may not contain general and duplicate information; correspondingly, the second message contains general and duplicate information.

[0271] As another example, 183 messages typically include the fields shown in Table 4 in addition to media response information; that is, 183 messages typically include the fields shown in Tables 2 and 4:

[0272] Table 4

[0273] Combining Tables 2 and 4 above, it can be seen that the bolded fields in Tables 2 and 4, as well as the fields a=curr:qos local none, a=curr:qos remote none, a=des:qos mandatory local sendrecv, and a=des:qos option remote sendrecv, are all used for terminal device capability information. Therefore, the first message can include all the fields in Tables 2 and 4 above; the second message does not include the bolded fields in Tables 1 and 3, as well as the fields a=curr:qos local none, a=curr:qos remote none, a=des:qos mandatory local sendrecv, and a=des:qos option remote sendrecv.

[0274] For example, if both the first and second messages are 183 messages, it means that the 183 messages transmitted between the terminal device and its IMS network element do not contain the bolded fields in Tables 2 and 4, nor the fields a=curr:qos local none, a=curr:qos remote none, a=des:qos mandatory local sendrecv, and a=des:qos option remote sendrecv; the 183 messages transmitted between the calling and called IMS network elements contain all the fields in Tables 2 and 4.

[0275] Furthermore, 183 messages typically contain duplicate information. For example, duplicate information may include IP addresses (e.g., IN IP62409:8030:5002:0127:0001:0000:0000:000F) and bandwidth information (e.g., b=AS:49, b=RR:1837, b=RS:612, etc.). Therefore, it's also possible to consider removing duplicate information, meaning the first message could be free of duplicates; correspondingly, the second message could contain duplicate information.

[0276] The above describes the implementation of the first and second messages. The following is a detailed description of the implementation of "the calling and called IMS network elements obtaining the capability information of the terminal device (furthermore, conventional information can also be stored in advance)" involved in the above embodiments.

[0277] For ease of description, the following description uses the IMS network element on the calling side obtaining the capability information of the terminal device as an example. The implementation of the IMS network element on the called side obtaining the capability information of the terminal device is similar to that of the IMS network element on the calling side obtaining the capability information of the terminal device described below. For details, please refer to the relevant descriptions in the following embodiments, which will not be repeated here.

[0278] Optionally, prior to step S602 (or step S602A or step S602B), as shown in (a) or (b) of FIG9, the calling method may further include step S606:

[0279] S606, The calling side's IMS network element obtains the terminal device's capability information.

[0280] For example, the IMS network element on the calling side can obtain the terminal device's capability information based on the following two scenarios:

[0281] Scenario 1: Both the first and second messages contain a media negotiation request (e.g., both the first and second messages are INVITE messages). That is, the first message does not contain capability information of the calling party's terminal equipment, while the second message does. In other words, in Scenario 1, the calling party's IMS network element needs to obtain the capability information of the calling party's terminal equipment.

[0282] In one possible implementation, the calling side terminal equipment and the calling side IMS network element can be pre-configured with the calling side terminal equipment's capability information, so that both the calling side IMS network element and the calling side terminal equipment can know and store the calling side terminal equipment's capability information.

[0283] In another possible implementation, the IMS network element on the calling side can obtain the capability information of the terminal device on the calling side from the terminal device on the calling side.

[0284] Optionally, in a possible implementation, as shown in Figure 10, step S606 can be replaced by step S606A:

[0285] S606A: The calling terminal device sends its capability information to the calling IMS network element; correspondingly, the calling IMS network element receives the capability information from the calling terminal device.

[0286] In one example, the capability information of the calling terminal device can be reported separately by the calling terminal device to the calling IMS network element.

[0287] For example, the calling terminal device can report its capability information at any time, as long as the reporting is completed before step S602A.

[0288] Optionally, the calling terminal device can access the calling terminal device's capability information during the IMS registration process.

[0289] Understandably, during the IMS registration process, the calling terminal device needs to send an IMS registration request (i.e., a registration message) to the calling IMS network element. Then, after IMS registration is complete, the calling IMS network element will send an IMS registration response (such as a 200 OK message corresponding to the registration message) back to the calling terminal device. In other words, as shown in Figure 11, before step S606A, this call method also includes step S606B:

[0290] S606B: The calling terminal device sends an IMS registration request to the calling IMS network element; correspondingly, the calling IMS network element receives the IMS registration request from the calling terminal device.

[0291] For example, an IMS registration request (such as a registration message) may also be referred to simply as a first request message, and this application does not limit this.

[0292] Optionally, after step S606A, as shown in FIG11, the calling method further includes:

[0293] S606C: The calling side's IMS network element stores the capabilities information of the calling side's terminal equipment.

[0294] For example, after receiving the IMS registration request, the IMS network element on the calling side also needs to register the terminal device on the calling side in the IMS network according to the IMS registration request.

[0295] S606D: The calling side's IMS network element sends an IMS registration response to the calling side's terminal equipment; correspondingly, the calling side's terminal equipment receives the IMS registration response from the calling side's terminal equipment.

[0296] For example, after the calling party's IMS network element registers the calling party's terminal device in the IMS network, it can send back the IMS registration result (i.e., the IMS registration response) to the calling party's terminal device.

[0297] It is understandable that the IMS registration process is usually completed between call processes, therefore the above steps S606B to S606D need to be performed before step S602.

[0298] In another example, the capability information of the calling terminal device can be carried in the signaling exchanged between the calling terminal device and the calling IMS network element.

[0299] As described above regarding the IMS registration process, the signaling exchange between the calling terminal device and the calling IMS network element includes an IMS registration request and an IMS registration response. Therefore, the calling terminal device's capability information can be carried in the IMS registration request; in other words, the calling terminal device's capability information is contained within the IMS registration request.

[0300] In other words, steps S606B and S606A in Figure 11 can be combined into step S606E as shown in Figure 12:

[0301] In S606E, the calling terminal device sends an IMS registration request to the calling IMS network element; correspondingly, the calling IMS network element receives the IMS registration request from the calling terminal device. The IMS registration request also includes capability information of the calling terminal device.

[0302] For example, an IMS registration request (such as a registration message) may also be referred to simply as a first request message, and this application does not limit this.

[0303] Furthermore, after step S606E, steps S606C to S606D can be executed.

[0304] In another possible implementation, the IMS network element on the calling side can obtain the capability information of the terminal device on the calling side from the core network equipment on the calling side.

[0305] Optionally, the calling terminal device can send its capability information to the calling core network device, wherein the HSS in the calling core network device can store the capability information of the calling terminal device; thus, the calling IMS network element can obtain the capability information of the calling terminal device from the HSS network element in the calling core network device.

[0306] For example, the calling terminal device can send its capability information to the calling core device at any time, as long as this is done before the calling IMS network element obtains the capability information of the calling terminal device from the calling core network device (HSS). Alternatively, the capability information of the calling terminal device can be carried in the signaling exchanged between the calling terminal device and the calling core network device.

[0307] Understandably, during the core network registration process, the calling terminal device needs to interact with the calling core network equipment via signaling. Specifically, the calling terminal device sends a registration request (such as an attach request; for simplicity, we'll use the MME as an example below) to the calling core network equipment (e.g., an MME in a 4G network architecture or an SMF in a 5G network architecture). The MME then authenticates the calling terminal device. Next, the MME and the calling terminal device activate a security mode. For example, the MME sends a security model command (SMC) to the calling terminal device, and the calling terminal device responds to the MME that the security mode is activated (e.g., SMC complete). The MME can then send a local update request to the HHS to obtain the user's subscription data. Finally, the MME establishes a default bearer, thus confirming that core network registration is complete.

[0308] Since the capability information of the calling terminal device needs to be sent from the calling terminal device to the HSS, it is possible to consider carrying the capability information of the calling terminal device in the registration request or the security mode activation instruction for transmission to the MME; furthermore, the capability information of the calling terminal device can also be carried in the local update request for transmission to the HSS. In one example, the calling core network device actively informs the calling IMS network element of the calling terminal device's capability information. That is, as shown in Figure 13, step S606 can be replaced by step S606F:

[0309] S606F: The core network equipment on the calling side sends the capability information of the terminal equipment on the calling side to the IMS network element on the calling side; correspondingly, the IMS network element on the calling side receives the capability information of the terminal equipment on the calling side from the core network equipment on the calling side.

[0310] For example, step S606F can be replaced by: the HSS sending the capability information of the terminal equipment on the calling side to the IMS network element on the calling side; correspondingly, the IMS network element on the calling side receives the capability information of the terminal equipment on the calling side from the HSS.

[0311] Optionally, the IMS network element on the calling side may include the calling side's P-CSCF network element and the calling side's S-CSCF network element. As mentioned above, the calling side's P-CSCF network element determines the second message based on the first message. Therefore, the HSS needs to send the capability information of the calling side's terminal equipment to the calling side's P-CSCF network element; however, the user-related information is usually obtained from the HSS by the S-CSCF network element in the IMS network. Therefore, step S606F can be replaced by: the HSS sending the calling side's terminal equipment capability information to the calling side's S-CSCF network element; thus, when the calling side's P-CSCF network element needs to determine the second message based on the first message, it can obtain the calling side's terminal equipment capability information from the calling side's S-CSCF network element, and then the first message and the calling side's terminal equipment capability information determine the second message.

[0312] Optionally, in this example, after receiving the capability information of the terminal equipment on the calling side, the S-CSCF network element on the calling side can provide feedback to the HSS network element (such as providing the negotiated capability information of the terminal equipment on the calling side); furthermore, the HSS can send this feedback to the terminal equipment on the calling side.

[0313] For example, during the process of HSS sending the capability information of the calling party's terminal equipment to the calling party's S-CSCF network element, the capability information of the calling party's terminal equipment can be carried in Cx-Put signaling or Cx-Pull signaling.

[0314] In another example, during the IMS network registration process, the IMS network element on the calling side obtains the capability information of the terminal device on the calling side from the core network equipment on the calling side. That is, as shown in Figure 14, before step S606, the call method further includes:

[0315] In the S606G, the calling terminal device sends an IMS registration request to the calling IMS network element; correspondingly, the calling IMS network element receives the IMS registration request from the calling terminal device.

[0316] The implementation of step S606G is the same as that of step S606B. For details, please refer to the relevant description of step S606B, which will not be repeated here.

[0317] S606H: The IMS network element on the calling side sends first indication information to the core network equipment on the calling side; correspondingly, the core network equipment on the calling side receives the first indication information from the IMS network element on the calling side. The first indication information is used to indicate to the core network equipment on the calling side the capability information of the terminal equipment on the calling side.

[0318] For example, step S606H can be replaced by: the calling side's IMS network element sending first indication information to the HSS; and the corresponding HSS receiving the first indication information from the calling side's IMS network element. Further, the first indication information can be carried in Cx-Put signaling or Cx-Pull signaling.

[0319] Optionally, the IMS network element on the calling side may include the P-CSCF network element and the S-CSCF network element on the calling side; step S606H can be replaced by: the P-CSCF network element on the calling side sending first indication information to the HSS; correspondingly, the HSS receives the first indication information from the P-CSCF network element on the calling side.

[0320] For example, since user-related information is usually obtained from the HSS by the S-CSCF network element in the IMS network, the transmission path of the first indication information is: P-CSCF network element on the calling side → S-CSCF network element on the calling side → HSS.

[0321] Therefore, in this example, as shown in Figure 14, step S606 can be replaced by step S606I:

[0322] S606I: The core network equipment on the calling side sends the capability information of the terminal equipment on the calling side to the IMS network element on the calling side; correspondingly, the IMS network element on the calling side receives the capability information of the terminal equipment on the calling side from the core network equipment on the calling side.

[0323] For example, in step S606I, the HSS sends the capability information of the terminal device on the calling side to the IMS network element on the calling side; correspondingly, the IMS network element on the calling side receives the capability information of the terminal device on the calling side from the HSS.

[0324] For example, after receiving the first indication information, the core network device on the calling side can send the capability information of the terminal device on the calling side to the IMS network element on the calling side.

[0325] Optionally, the IMS network element on the calling side may include the P-CSCF network element and the S-CSCF network element on the calling side. Step S606I can be replaced by: the HSS sending the capability information of the terminal equipment on the calling side to the P-CSCF network element on the calling side; correspondingly, the P-CSCF network element on the calling side receives the capability information of the terminal equipment on the calling side from the HSS.

[0326] For example, the transmission path of the capability information of the calling party's terminal equipment is: HSS → S-CSCF network element of the calling party → P-CSCF network element of the calling party. Therefore, the P-CSCF network element of the calling party can store the capability information of the calling party's terminal equipment. Thus, when it needs to determine the second message based on the first message, it can retrieve the capability information of the calling party's terminal equipment from its storage area, and then determine the second message based on the first message and the capability information of the calling party's terminal equipment.

[0327] Optionally, in this example, after receiving the capability information of the calling terminal device, the calling P-CSCF network element can send back response information corresponding to the calling terminal device's capability information (such as the negotiated capability information of the calling terminal device). Since the calling terminal device's capability information is sent from the calling terminal device to the HSS, and then to the calling P-CSCF network element, the response information sent back by the calling P-CSCF network element will also be sent back to the calling terminal device. Since the calling P-CSCF network element and the calling terminal device can communicate directly, the calling P-CSCF network element can directly send the response information to the calling terminal device. In other words, the response information does not need to go through the HSS.

[0328] For example, during the process of HSS sending the capability information of the calling party's terminal equipment to the calling party's S-CSCF network element, the capability information of the calling party's terminal equipment can be carried in Cx-Put signaling or Cx-Pull signaling.

[0329] Scenario 2: Both the first and second messages contain media response information (e.g., both the first and second messages are 183 messages). That is, the first message contains the capability information of the called party's terminal equipment, while the second message does not. In other words, in Scenario 2, the calling party's IMS network element needs to obtain the capability information of the called party's terminal equipment.

[0330] For example, based on the aforementioned Scenario 1, the IMS network element accessed by the terminal device can obtain the capability information of the terminal device; that is, the IMS network element on the called side can obtain the capability information of the terminal device on the called side. Specifically, the implementation of the IMS network element on the called side obtaining the capability information of the terminal device on the called side is similar to the implementation of the IMS network element on the calling side obtaining the capability information of the terminal device on the calling side in Scenario 1 above. For details, please refer to the relevant description in Scenario 1 above, which will not be repeated here.

[0331] Therefore, the calling side's IMS network element can obtain the capability information of the called side's terminal equipment from the called side's IMS network element. In other words, step S606 can be replaced by: the called side's IMS network element sending the called side's terminal equipment capability information to the calling side's IMS network element; correspondingly, the calling side's IMS network element receiving the called side's terminal equipment capability information from the called side's IMS network element.

[0332] Specifically, the called party's IMS network element can proactively inform the calling party's IMS network element of the capabilities of the called party's terminal equipment; or, the called party's IMS network element can also send the called party's terminal equipment capabilities to the calling party's IMS network element based on the instruction sent to it by the calling party's IMS network element.

[0333] In summary, in the calling method described in this application, if the calling terminal device sends an INVITE message to the called terminal device during the call process, the corresponding INVITE message can be generated based on the method shown in Scenario 1 above, and transmitted to the called terminal device based on the transmission process shown in Scenario 1 above.

[0334] If the called party's terminal device sends a 183 message to the calling party's terminal device, the corresponding 183 message can be generated based on the method shown in Scenario 2 above, and transmitted to the calling party's terminal device according to the transmission process shown in Scenario 2 above.

[0335] In some implementations, the first and second messages further include session static information. This session static information includes one or more of the following: the source address, the destination address, and the identifier or routing information of the called party's terminal device. For example, consider that during a call, the session static information in the signaling sent by the calling party's terminal device to the called party's terminal device is identical. For instance, the session static information in INVITE, PRACK, and UPDATA messages is the same. Similarly, the session static information in the signaling sent by the called party's terminal device to the calling party's terminal device is identical. For instance, the session static information in 183, PRACK 200 OK, UPDATA 200 OK, and 180 messages is the same.

[0336] Therefore, it is possible to consider storing session static information in the IMS network element, so that the session static information is only included in the signaling transmitted between the calling and called IMS network elements, while the session static information can be simplified in the signaling transmitted between the terminal device and the IMS network element (i.e., the signaling does not contain session static information). However, since the session static information is generated during the call process, that is, in the signaling of the first interaction between the calling and called terminal devices during the call process (i.e., the first and second messages mentioned above, such as INVITE and 183 messages), the signaling of the first interaction between the calling and called terminal devices needs to carry session static information. Thus, after the calling side IMS network element receives the first message, it can obtain and store the session static information from the first message, providing a basic guarantee for simplifying the session static information in the signaling transmitted between the terminal device and the IMS network element for other signaling during the call process (such as PRACK message, UPDATA message, PRACK 200 OK message, UPDATA 200 OK message, and 180 message).

[0337] For example, as shown in FIG15, after step S601 (or step S601A or step S601B), the calling method further includes:

[0338] S607 and network element #2 obtain session static information from the first message.

[0339] For example, the embodiments of this application do not limit the order of steps S607-S608 and step S602 (or, in other words, step S602A or step S602B).

[0340] For example, the source address of the message can be indicated by the From field, the destination address by the To field, routing information by the Route field and / or the Record-Route field, and the identifier of the called party's terminal device by the Call-ID field. Thus, the calling party's IMS network element can obtain the information indicated by the From field, To field, Route field and / or Record-Route field, and Call-ID field from the first message.

[0341] In one example, when both the first and second messages contain a media negotiation request (e.g., both the first and second messages are INVITE messages), the session static information includes the information indicated by the From, To, Route, and / or Record-Route fields in Table 3, as well as the Call-ID field.

[0342] In another example, when both the first and second messages contain media response information (e.g., both the first and second messages are 183 messages), the session static information includes the information indicated by the From, To, Route, and / or Record-Route fields in Table 4, as well as the Call-ID field.

[0343] Combining the two examples above, routing information can sometimes be indicated by the Via field; therefore, session static information can also contain information indicated by the Via field.

[0344] S608 and network element #2 store static session information.

[0345] It is understood that this application does not limit the order of steps S602 (or S602A or S602B) with steps S607 to S608. For example, step S602 may be performed before steps S607 to S608, or step S602 may be performed after steps S607 to S608, or step S602 may be performed simultaneously with steps S607 to S608.

[0346] Optionally, after the second message transmission is completed (e.g., transmitted to the calling terminal device or the called terminal device), as shown in Figure 16, the calling method further includes the following steps:

[0347] S609, Network element #1 sends a third message to Network element #2; correspondingly, Network element #2 receives the third message from Network element #1.

[0348] S610 and network element #2 determine the fourth message based on the third message.

[0349] S611, Network element #2 sends a fourth message to network element #3; correspondingly, network element #3 receives the fourth message from network element #2.

[0350] Exemplary third and fourth messages can be implemented based on the following two scenarios:

[0351] Scenario 1: Network element #1 is the calling side terminal device, network element #2 is the calling side IMS network element, and network element #3 is the called side IMS network element. In this case, both the first and second messages contain a media negotiation request (e.g., both the first and second messages are INVITE messages).

[0352] For example, in scenario one, the third message does not contain session static information, while the fourth message does. Specifically, network element #2 can add session static information to the third message to obtain the fourth message.

[0353] For example, in one scenario, the third and fourth messages are either PRACK messages (or contained within PRACK messages), UPDATA messages (or contained within UPDATA messages), or ACK messages (or contained within ACK messages).

[0354] Taking the PRACK message as an example, a typical PRACK message may contain the fields shown in Table 5:

[0355] Table 5

[0356] Comparing Table 5 with Tables 3 and 4 reveals that the bolded fields in Table 5 (i.e., the From, To, and Call-ID fields) indicate the same information as the corresponding fields in Table 3. Furthermore, the Route field in Table 5 indicates the same information as the Record-Route field in Table 4. These fields are all used to indicate the aforementioned session static information. Therefore, the third message does not contain session static information (i.e., it does not contain the bolded fields in Table 5), while the fourth message may contain session static information (such as all fields in Table 5).

[0357] For example, if both the third and fourth messages are PRACK messages, it means that the PRACK message transmitted between the terminal device and its IMS network element does not contain the bolded fields in Table 5; the PRACK message transmitted between the calling and called IMS network elements contains all the fields in Table 5.

[0358] In addition, PRACK messages typically contain terminal device capability information, general information, and duplicate information. For example, terminal device capability information includes the P-Preferred-Service field, Supported field, and User-Agent field in Table 5. General information includes the P-Access-Network-Info field and Max-Forwards field in Table 5; duplicate information includes SIP / 2.0 / UDP[2409:8131:615:ffa9::1]:31856 in the Via field of Table 5; sip:[2409:8030:5002:127:1::d]:9900; Hpt=8eb2_16; Cxtld=3; TRC=ffffffff-ffffffff, etc. in the rport and aucSipMsg fields. Therefore, it is possible to pre-store the terminal device's capability information together with the regular information in the IMS network element. This would allow for the deletion of the terminal device's capability information, regular information, and duplicate information. In other words, the third message would not contain the terminal device's capability information, regular information, and duplicate information. Correspondingly, the fourth message would contain the terminal device's capability information, regular information, and duplicate information.

[0359] It should be noted that the implementation of the third and fourth messages in Scenario 1 above is based on the PRACK message. If the third and fourth messages are UPDATA or ACK messages, their implementation is similar to that of the PRACK message in Scenario 1 above; please refer to the relevant descriptions above for details, which will not be repeated here.

[0360] Scenario 2: Network element #1 is the IMS network element on the called side, network element #2 is the IMS network element on the calling side, and network element #3 is the terminal equipment on the calling side. In this case, both the first message and the second message contain relevant media information (e.g., both the first message and the second message are 183 messages).

[0361] For example, in scenario two, the third message contains static session information, while the fourth message does not. Specifically, network element #2 can delete the static session information from the third message to obtain the fourth message.

[0362] For example, in scenario two, the third and fourth messages are either PRACK 200 OK messages (or contained in PRACK 200 OK messages), UPDATA 200 OK messages (or contained in UPDATA 200 OK messages), 180 messages (or contained in 180 messages), or INVITE 200 OK messages (or contained in INVITE 200 OK messages).

[0363] The following sections use PRACK 200 OK messages and PRACK 180 messages as examples to illustrate the different implementations of the third and fourth messages.

[0364] In one example, a PRACK 200 OK message may typically include the fields shown in Table 6:

[0365] Table 6

[0366] Comparing Table 6 with Table 4, we can see that the bolded fields in Table 6 (i.e., the From, To, and Call-ID fields) indicate the same information as the corresponding fields in Table 4; furthermore, the Route field in Table 6 indicates the same information as the Record-Route field in Table 4. These fields are all used to indicate the aforementioned session static information. Therefore, the third message can contain session static information (such as all fields in Table 5), while the fourth message does not contain session static information (i.e., it does not contain the bolded fields in Table 5).

[0367] For example, if both the third and fourth messages are PRACK 200 OK messages, it means that the PRACK 200 OK messages transmitted between the terminal device and its IMS network element do not contain the bolded fields in Table 5; the PRACK 200 OK messages transmitted between the calling and called IMS network elements contain all the fields in Table 5.

[0368] In addition, the PRACK 200 OK message typically includes the terminal device's capability information. For example, the terminal device's capability information includes the Supported and User-Agent fields from Table 5. Therefore, it is possible to pre-store the terminal device's capability information in the IMS network element, thereby allowing for the deletion of the terminal device's capability information, i.e., the third message includes the terminal device's capability information; correspondingly, the fourth message does not include the terminal device's capability information.

[0369] In another example, a 180 message may typically include the fields shown in Table 7:

[0370] Table 7

[0371] Comparing Table 7 with Table 4 reveals that the bolded fields in Table 7 (i.e., From, To, Via, Record-Route, and Call-ID fields) indicate the same information as the corresponding fields in Table 4. These fields are all used to indicate the aforementioned session static information. Therefore, the third message does not contain session static information (i.e., it does not contain the bolded fields in Table 7), while the fourth message may contain session static information (such as including all fields from Table 7).

[0372] For example, if both the third and fourth messages are 180 messages, it means that the 180 messages transmitted between the terminal device and its IMS network element do not contain the bolded fields in Table 7; the 180 messages transmitted between the calling and called IMS network elements contain all the fields in Table 7.

[0373] In addition, 180 messages typically contain terminal device capability information and duplicate information. For example, terminal device capability information includes the Allow, User-Agent, and P-early-Media fields from Table 7. Duplicate information includes the Contact and Feature-Caps fields from Table 7. Therefore, it is possible to pre-store the terminal device capability information in the IMS network element, thereby allowing for the removal of terminal device capability information and duplicate information. That is, the third message would contain terminal device capability information and duplicate information; correspondingly, the fourth message would not contain terminal device capability information and duplicate information.

[0374] It should be noted that the implementation of the third and fourth messages in Scenario 1 above uses PRACK 200 OK and 180 messages as examples. If the third and fourth messages are UPDATA 200 OK or INVITE 200 OK messages, the implementation of the third and fourth messages is similar to that of PRACK 200 OK and / or 180 messages in Scenario 2 above. For example, static session information, identical or repeated information can be simplified. For details, please refer to the relevant description in Scenario 2 above, which will not be repeated here.

[0375] In summary, in the calling method described in this application, if the calling terminal device sends a PRACK message, UPDATA message, or ACK message to the called terminal device during the call process, the corresponding message can be generated based on the method shown in Scenario 1 above, and transmitted to the called terminal device based on the transmission process shown in Scenario 1 above.

[0376] If the called party's terminal device sends a PRACK 200 OK message, 180 message, UPDATA 200 OK message, or INVITE 200 OK message to the calling party's terminal device, the corresponding message can be generated based on the method shown in Scenario 2 above, and transmitted to the calling party's terminal device according to the transmission process shown in Scenario 2 above.

[0377] It is understood that the above embodiments use the example of the default IMS network elements of the calling and called parties supporting the signaling conversion described in this application to introduce the calling method described in the embodiments of this application. In reality, there may be IMS network elements in the IMS network that support the above signaling conversion, and there may also be IMS network elements that do not support the above signaling conversion. Therefore, before the calling method described in this application, the terminal device also needs to determine whether the IMS network element it accesses supports the above signaling conversion.

[0378] For example, the IMS network element supports the call method described in this application, which can be understood as follows: the IMS network element can convert signaling that does not contain certain information (such as terminal device capability information, session static information, repetitive information, regular information, etc.) into signaling that contains such information (such as adding such signaling to the original signaling to achieve signaling conversion); and / or, the IMS network element can convert signaling that contains certain information into signaling that does not contain such information (such as deleting such signaling from the original signaling to achieve signaling conversion).

[0379] Furthermore, since signaling during a call (such as SIP signaling) includes this information, IMS network elements by default support the transmission of signaling containing this information. Therefore, to implement the call method described in this application, when determining the IMS network element, it is also necessary to consider whether the IMS network element supports the transmission of signaling that does not contain this information. In other words, the IMS network element described in this application supports both signaling transmitted during a call containing the aforementioned information and signaling transmitted during a call that does not contain the aforementioned information. For example, the IMS network element supports signaling transmitted during a call that does not contain the terminal device's capability information.

[0380] For ease of description, the following embodiments will use the IMS network element on the calling side as an example for introduction, and will be described uniformly here without further details.

[0381] As an example, during a typical PDN connection process, the terminal device initiates a PDN connectivity request to the core network. The core network device then processes the PDN connectivity request accordingly. After the connection is established, it can send a PDN connectivity response to the terminal device to inform it that the PDN connection has been established. In addition, it will also carry the address information of the IMS network elements configured for the terminal device.

[0382] In other words, during the PDN connection process, the core network equipment will select an IMS network element (such as a P-CSCF network element) for the terminal equipment. Therefore, when the terminal equipment on the calling side initiates a PDN connection to the core network equipment on the calling side, the core network equipment on the calling side may consider configuring the IMS network element for signaling conversion as described in this application for the terminal equipment on the calling side.

[0383] Specifically, in scenarios where terminal devices use narrowband high-speed rail access, significant call latency occurs during calls. Therefore, the solution proposed in this application reduces call latency. Consequently, the core network equipment on the calling side can determine the IMS network element based on the terminal device's access scenario. For example, if the core network equipment on the calling side determines that the terminal device uses narrowband high-speed rail access, it will select an IMS network element that supports the signaling conversion described in this application as the calling side's IMS network element.

[0384] For example, as shown in Figure 17, before step S601A, the calling method further includes:

[0385] S612, The calling terminal device sends a PDN connection request to the calling core network device; correspondingly, the calling core network device receives the PDN connection request from the calling terminal device.

[0386] S613. The core network equipment on the calling side determines the address information of the IMS network element on the calling side based on the way the terminal equipment on the calling side accesses the network.

[0387] For example, if the core network equipment on the calling side determines that the terminal equipment on the calling side is based on narrowband high-speed access, it selects an IMS network element that supports the signaling conversion described in this application as the IMS network element on the calling side. If the core network equipment on the calling side determines that the terminal equipment on the calling side is based on non-narrowband high-speed access, it can continue to use the current method of selecting IMS network elements to select a suitable IMS network element as the IMS network element on the calling side.

[0388] Optionally, the access method of the calling terminal device can be reported by the calling terminal device to the calling core network device. For example, it can be carried in the PDN connection request, or it can be reported separately. Alternatively, the calling core network device can be assumed to know the access method of the calling terminal device; this application does not limit this.

[0389] S614. The core network equipment on the calling side sends a PDN connection response to the terminal equipment on the calling side; correspondingly, the terminal equipment on the calling side receives the PDN connection response from the core network equipment on the calling side. The PDN connection response is used to indicate the address information of the IMS network element on the calling side.

[0390] It is understandable that the PDN connection establishment process can be executed during the core network registration process, or it can be executed after the core network registration process is completed. If the PDN connection establishment process can be executed during the core network registration process, then the PDN connection request can be included in the registration request (such as an attach request).

[0391] For example, a PDN connection establishment request may be referred to as a second request message; correspondingly, a PDN connection response may also be referred to as a second response message; or other names may exist, which are not limited in this application.

[0392] In another example, the calling terminal device can obtain the address information of the calling IMS network element through dynamic host configuration protocol (DHCP) or by querying the domain name system (DNS).

[0393] Specifically, when obtaining the address information of the IMS network element on the calling side, the terminal device can determine it based on its network access method. For example, in a scenario where the calling side terminal device is based on narrowband high-speed rail access, it selects an IMS network element that supports the signaling conversion described in this application as the calling side IMS network element. In a scenario where the calling side terminal device is based on non-narrowband high-speed rail access, it can continue to use the current method of selecting IMS network elements to select a suitable IMS network element as the calling side IMS network element.

[0394] Optionally, after selecting an IMS network element that supports the signaling conversion described in this application as the calling side's IMS network element, the calling side's IMS network element can be instructed to activate the signaling conversion function during the call. Thus, during the call, a call to the called side's terminal equipment can be made according to the calling method described in this application. That is, before step S602A, the calling side's terminal equipment can also send a second instruction message to the calling side's IMS network element; correspondingly, the calling side's IMS network element receives the second instruction message from the calling side's terminal equipment. The second instruction message is used to instruct the activation of the signaling conversion function during the call.

[0395] For example, the second instruction information can be reported separately. The second instruction information can be carried in certain signaling sent by the calling terminal equipment to the calling IMS network element.

[0396] For example, a second instruction message can be sent during the IMS network element registration process, thus carrying the second instruction message in the IMS registration request; alternatively, the second instruction message can be sent separately during the IMS network element registration process.

[0397] Taking the inclusion of the second instruction information in the IMS registration request as an example, the second instruction information can be located in the header fields of the IMS registration request; for example, it can be located in the Contact field and / or Via field. The second instruction information can include +g.3gpp.simplifiedSIP; thus, the IMS registration request can include Contact:UAC; +g.3gpp.simplifiedSIP; and Via:UAC; +g.3gpp.simplified. Furthermore, the PDN connection response can also carry the second instruction information; for example, the second instruction information can be located in the Feature Caps field, thus, the PDN connection response can include Feature Caps: +g.3gpp.simplifiedSIP.

[0398] Alternatively, after selecting an IMS network element that supports the signaling conversion described in this application as the calling side's IMS network element, the signaling conversion function can be activated by default during the call. Therefore, during the call, the calling method described in this application can be used directly to call the called party's terminal equipment.

[0399] Furthermore, during a call, a second instruction can be carried in the signaling to enable the use of signaling switching functions during the call.

[0400] Taking the second indication information carried in all signaling during the call process as an example, for uplink signaling (such as INVITE message, PRACK message, UPDATA message, ACK message), the second indication information can be located in fields such as Contact field, Via field, Route field, etc. For uplink signaling (such as 183 message, PRACK 200OK message, UPDATA 200OK message, 180 message, UPDATA 200OK message), the second indication information can be located in fields such as Contact field, Via field, Record-Route field, etc.

[0401] Taking the second instruction information containing +g.3gpp.simplifiedSIP as an example, the uplink signaling may contain one or more of the following:

[0402] (1), Via: UAC:+g.3gpp.simplifiedSIP;

[0403] (2), Route:Proxy;+g.3gpp.simplifiedSIP;

[0404] (3), Contact: UAC; +g.3gpp.simplifiedSIP.

[0405] Similarly, downlink signaling may include one or more of the following:

[0406] (1), Record-route:proxy;+g.3gpp.simplifiedSIP;

[0407] (2), Via:UAC;+g.3gpp.simplifiedSIP;

[0408] (3), Contact: UAC; +g.3gpp.simplifiedSIP.

[0409] For example, the second indication information is used to indicate support for signaling conversion during a call, which can be understood as: the IMS network element can convert signaling that does not contain certain information (such as terminal device capability information, session static information, repetitive information, general information, etc.) into signaling that contains such information (such as adding such signaling to the original signaling to achieve signaling conversion); and / or, the IMS network element can convert signaling that contains certain information into signaling that does not contain such information (such as deleting such signaling from the original signaling to achieve signaling conversion).

[0410] Furthermore, since signaling during a call (such as SIP signaling) includes this information, IMS network elements by default support the transmission of signaling containing this information. Therefore, to implement the call method described in this application, when determining the IMS network element, it is also necessary to consider whether the IMS network element supports the transmission of signaling that does not contain this information. In other words, the IMS network element described in this application supports both signaling transmitted during a call containing the aforementioned information and signaling transmitted during a call that does not contain the aforementioned information. For example, the IMS network element supports signaling transmitted during a call that does not contain the terminal device's capability information.

[0411] It should be noted that the above embodiments describe the implementation of the second instruction information by taking the inclusion of +g.3gpp.simplifiedSIP as an example. This does not mean that the second instruction information described in this application can only be represented by "+g.3gpp.simplifiedSIP". In fact, it can also be represented in other ways, as long as the above purpose can be achieved. This application does not limit it.

[0412] It is understood that the above embodiments all use the deletion of certain information in the original signaling as a simplification method to describe the calling method described in this application. In fact, in addition to deleting information in the original signaling, compression methods (such as Sigcomp compression) can also be used to simplify the signaling to reduce the signaling load. That is to say, both deleting the original signaling and compression are aimed at reducing the signaling load. Therefore, the simplification described in this application can also include any other methods that can reduce the signaling load, and this application does not limit them.

[0413] Therefore, when selecting an IMS network element (such as a P-CSCF network element) for a terminal device, in addition to considering whether the terminal device is based on narrowband high-speed rail access, specific simplification methods can also be considered to select a suitable IMS network element for the terminal device to implement the calling method described in this application.

[0414] Furthermore, when activating or enabling simplified operation between the terminal device and the IMS network element (such as activating or enabling simplified operation through the aforementioned second indication information), it can further indicate which specific simplification method is activated or enabled, so that the terminal device and the IMS network element can implement the call method described in this application based on the simplification method.

[0415] Furthermore, the complete message corresponding to the simplified message (hereinafter referred to as the simplified message) described in this application can be considered as a message defined in the standard. Therefore, when the IMS network element restores the simplified message to the complete message, it is actually restoring the simplified message to the message specified in the standard, enabling the message to be transmitted within the IMS network element. It should be noted that the various embodiments of this application can be implemented independently or in combination, without limitation. Unless otherwise specified or in case of logical conflict, at least one of the terms or descriptions in the different embodiments provided in this application is consistent and can be referenced mutually. Technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships.

[0416] The foregoing primarily describes the solutions provided in this application from the perspective of device-to-device interaction. It is understood that each device, in order to achieve the aforementioned functions, includes at least one of the hardware structures or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, in conjunction with the algorithm steps of the examples described in the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0417] It is understood that, in order to achieve the above-mentioned functions, the communication device includes at least one of the hardware structures or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0418] This application embodiment can divide each device into functional modules according to the above method example. For example, each function can be divided into a separate functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0419] Figure 18 shows a schematic diagram of a communication device 1800. The communication device 1800 includes a processing module 1801 and a transceiver module 1802. This communication device can be used to implement the functions of the first network element (i.e., the IMS network element on the calling side), the first terminal device (i.e., the terminal device on the calling side), or the first core network device (i.e., the core network device on the calling side).

[0420] In some embodiments, the communication device 1800 may further include a storage module (not shown in FIG18) for storing at least one of a program, instructions, or data.

[0421] In some embodiments, the transceiver module 1802, also referred to as a transceiver unit, is used to implement at least one of the functions of sending or receiving. The transceiver module 1802 may consist of a transceiver circuit, a transceiver, a transceiver unit, or a communication interface.

[0422] In some embodiments, the transceiver module 1802 may include a receiving module and a sending module, respectively configured to perform receiving and sending steps performed by the first network element or the first terminal device in the above method embodiments, or to support at least one of other processes in which the technology described herein is performed; the processing module 1801 may be configured to perform processing steps (e.g., determination) performed by the first network element, the first terminal device, or the first core network device in the above method embodiments, or to support at least one of other processes in which the technology described herein is performed.

[0423] When the communication device 1800 is used to implement the function of the first network element mentioned above:

[0424] In some embodiments, the transceiver module 1802 is configured to receive a first message. The processing module 1801 is configured to determine a second message based on the first message. The transceiver module 1802 is also configured to send the second message.

[0425] In this context, both the first message and the second message contain a media negotiation request, the first message does not contain capability information of the first terminal device, and the second message does contain capability information of the first terminal device; or, both the first message and the second message contain media response information, the first message contains capability information of the second terminal device, and the second message does not contain capability information of the second terminal device, the first terminal device is used to call the second terminal device, and the first network element is a network element in the IMS network accessed by the first terminal device.

[0426] Optionally, the capability information of the terminal device includes the call encoding formats supported by the terminal device, wherein the terminal device is a first terminal device or a second terminal device.

[0427] Optionally, the terminal device's capability information may also include one or more of the following: the terminal device's preferred information, SIP-related information supported by the terminal device, call characteristics supported by the terminal device, and Quality of Service (QoS) parameters in the Session Description Protocol (SDP) supported by the terminal device.

[0428] Optionally, the processing module 1801 is also used to obtain capability information of the terminal device.

[0429] Optionally, the transceiver module 1802 is also used to receive capability information from the first terminal device.

[0430] Optionally, the capability information of the first terminal device is included in the first request message, which is an IMS registration request for the first terminal device; or, the transceiver module 1802 is further configured to receive the first request message from the first terminal device.

[0431] Optionally, the transceiver module 1802 is also used to receive capability information of the first terminal device from the first core network device, wherein the first core network device is the core network device accessed by the first terminal device.

[0432] Optionally, the transceiver module 1802 is further configured to receive a first request message from the first terminal device, the first request message being an IMS registration request from the first terminal device; and to send first indication information to the first core network device, the first indication information being used to instruct the first core network device to send capability information of the first terminal device.

[0433] Optionally, the transceiver module 1802 is also used to receive capability information of the second terminal device from the second network element, where the second network element is a network element in the IMS network accessed by the second terminal device.

[0434] Optionally, the processing module 1801 is further configured to obtain session static information from the first message and store the session static information, which includes one or more of the source address, destination address, or routing information of the message.

[0435] Optionally, the transceiver module 1802 is further configured to receive a third message; the processing module 1801 is further configured to determine a fourth message based on the session static information and the third message; and the transceiver module 1802 is further configured to send the fourth message. The third message contains session static information, while the fourth message does not; or, the third message does not contain session static information, while the fourth message contains session static information.

[0436] Optionally, if the third message does not contain session static information and the fourth message does contain session static information, then the third and fourth messages are included in the temporary response acknowledgment PRACK message or the update UPDATA message; if the third message contains session static information and the fourth message does not contain session static information, then the third and fourth messages are included in the response message of the PRACK message or the response message of the UPDATA message.

[0437] Optionally, the transceiver module 1802 is also configured to receive second indication information, which indicates that the signaling transmitted during the call does not contain terminal device capability information.

[0438] Optionally, the transceiver module 1802 is further configured to receive second indication information from the first terminal device; wherein the second indication information is included in the first request message, and the first request message is a registration request from the first terminal device; or, the transceiver module 1802 is further configured to receive first request information from the first terminal device.

[0439] Optionally, both the first message and the second message contain second indication information, which is used to indicate that the signaling transmitted during the call does not contain UE capability information.

[0440] When the communication device 1800 is used to implement the functions of the first terminal device described above:

[0441] In some embodiments, the processing module 1801 is used to obtain a first message and execute a call process according to the first message; wherein the first message includes a media negotiation request or media response information, the first message does not include the capability information of the terminal device, the terminal device is a first terminal device or a second terminal device, and the first terminal device is used to call the second terminal device.

[0442] Optionally, the terminal device's capability information includes the call encoding formats supported by the terminal device.

[0443] Optionally, the capability information of the terminal device may also include one or more of the following: the terminal device's preferred information, SIP-related information supported by the terminal device, call characteristics supported by the terminal device, and Quality of Service (QoS) parameters in the Session Description Protocol (SDP) supported by the terminal device.

[0444] Optionally, the transceiver module 1802 is used to send capability information of the first terminal device.

[0445] Optionally, the capability information of the first terminal device is included in the first request message, which is an IMS registration request for the first terminal device; or, the transceiver module 1802 is also used to send the first request message.

[0446] Optionally, the first message includes a media negotiation request, and the processing module 1801 is also used to generate the first message; correspondingly, the sending and receiving module 1802 is also used to send the first message.

[0447] Optionally, the processing module 1801 is also used to obtain the address information of the first network element, the first network element being a network element in the IMS network accessed by the first terminal device; and to send a first message to the first network element.

[0448] Optionally, the transceiver module 1802 is further configured to send a second request message, which is a packet data network (PDN) connection request for the first terminal device; the transceiver module 1802 is further configured to receive a second response message, which is used to indicate the establishment of a PDN connection for the first terminal device, and the second response message contains the address information of the first network element.

[0449] Optionally, the transceiver module 1802 is also used to receive the first message.

[0450] Optionally, the processing module 1801 is also used to obtain a third message, which does not contain session static information. The session static information contains one or more of the message's source address, destination address, or routing information.

[0451] Optionally, the processing module 1801 is also used to generate a third message.

[0452] Optionally, the third message may be included in a temporary response acknowledgment PRACK message or an update UPDATA message.

[0453] Optionally, the transceiver module 1802 is also used to receive a third message, which is contained in the response message of the PRACK message or the response message of the UPDATA message.

[0454] Optionally, the transceiver module 1802 is also used to send a second indication message, which indicates that the signaling transmitted during the call does not contain terminal device capability information.

[0455] Optionally, the second indication information is included in the first request message, which is a registration request for the first terminal device; or, the transceiver module 1802 is further used to send the first request message.

[0456] Optionally, the first message includes second indication information, which indicates that the signaling transmitted during the call does not include terminal device capability information.

[0457] When the communication device 1800 is used to implement the functions of the aforementioned first core network equipment:

[0458] In some embodiments, the processing module 1801 is used to determine the address information of the first network element based on the access network access method of the first terminal device. The access network access method of the first terminal device includes the first terminal device accessing the narrowband high-speed rail network. The first network element refers to the network element in the Multimedia Subsystem (IMS) network accessed by the first terminal device. The first network element supports the mutual conversion between signaling containing terminal device capability information and signaling not containing terminal device capability information during the call process. The terminal device is either the first terminal device or the second terminal device. The first terminal device is used to call the second terminal device. The transceiver module 1802 is used to send the address information of the first network element.

[0459] Optionally, the transceiver module 1802 is further configured to receive a second request message, which is a packet data network (PDN) connection request for the first terminal device; the transceiver module 1802 is further configured to send a second response message, which is used to indicate the establishment of a PDN connection for the first terminal device, and the second response message contains the address information of the first network element.

[0460] Optionally, the transceiver module 1802 is also used to send capability information of the first terminal device.

[0461] Optionally, the transceiver module 1802 is also used to receive first indication information, which is used to instruct the first core network device to send capability information of the first terminal device.

[0462] Optionally, the capability information of the first terminal device includes the call encoding formats supported by the first terminal device.

[0463] Optionally, the capability information of the first terminal device may also include one or more of the following: preferred information of the terminal device, SIP-related information supported by the terminal device, call characteristics supported by the terminal device, and Quality of Service (QoS) parameters in the Session Description Protocol (SDP) supported by the terminal device.

[0464] All relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0465] In this application, the communication device (i.e., the first network element or the first terminal device) 1800 is presented in an integrated manner, divided into various functional modules. Here, "module" may refer to at least one of the following: ASIC, circuit, processor and memory executing one or more software or firmware programs, integrated logic circuit, or other device that can provide the above-mentioned functions.

[0466] In some embodiments, when the communication device 1800 in FIG18 is a chip or chip system, the function / implementation process of the transceiver module 1802 can be implemented through the input / output interface (or communication interface) of the chip or chip system, and the function / implementation process of the processing module 1801 can be implemented through the processor (or processing circuit) of the chip or chip system.

[0467] Since the communication device 1800 provided in this embodiment can execute the above method, the technical effects it can achieve can be referred to the above method embodiment, and will not be repeated here.

[0468] As another possible product form, the first network element, first terminal device, or first core network device described in the embodiments of this application can all adopt the composition structure shown in FIG19, or include the components shown in FIG19. FIG19 is a schematic diagram of the composition of a communication device 1900 provided in an embodiment of this application. The communication device 1900 can be a first network element or a chip or system-on-a-chip in the first network element; it can also be a first terminal device or a chip or system-on-a-chip in the first terminal device; or it can be a first core network device or a chip or system-on-a-chip in the first core network device. As shown in FIG19, the communication device 1900 includes a processor 1901, a communication interface 1902, and a communication line 1903.

[0469] Furthermore, the communication device 1900 may also include a memory 1904. The processor 1901, the memory 1904, and the communication interface 1902 can be connected via a communication line 1903.

[0470] The processor 1901 can be a CPU, a network processor (NP), a digital signal processor (DSP), a microprocessor, a microcontroller, a programmable logic device (PLD), or any combination thereof. The processor 1901 can also be other devices with processing capabilities, such as circuits, devices, or software modules, without limitation.

[0471] Communication interface 1902 is used for communication with other devices or other communication networks. These other communication networks can be Ethernet, radio access network (RAN), wireless local area network (WLAN), etc. Communication interface 1902 can be a module, circuit, transceiver, or any device capable of enabling communication.

[0472] Communication line 1903 is used to connect different components in communication device 1900, enabling communication between them. Communication line 1903 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used in Figure 19, but this does not indicate that there is only one bus or one type of bus.

[0473] The memory 1904 may be a device with storage function, used to store at least one of instructions or data. The instructions may be computer programs.

[0474] For example, memory 1904 may be at least one of read-only memory (ROM) or other types of static storage devices capable of storing static information or instructions; it may also be at least one of random access memory (RAM) or other types of dynamic storage devices capable of storing information or instructions; it may also be electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, etc., without limitation.

[0475] It should be noted that the memory 1904 can exist independently of the processor 1901, or it can be integrated with the processor 1901. The memory 1904 can be used to store instructions, program code, or some data, etc. The memory 1904 can be located inside or outside the communication device 1900, without limitation. The processor 1901 is used to execute the instructions stored in the memory 1904 to implement the communication method provided in the following embodiments of this application.

[0476] In one example, processor 1901 may include one or more CPUs, such as CPU0 and CPU1 in Figure 19.

[0477] In some embodiments, those skilled in the art will recognize that the communication device 1800 may take the form of the communication device 1900 shown in FIG19 in terms of hardware implementation.

[0478] As an example, the function / implementation of the processing module 1801 in Figure 18 can be achieved by the processor 1901 in the communication device 1900 shown in Figure 19 calling computer execution instructions stored in the memory 1904. The function / implementation of the transceiver module 1802 in Figure 18 can be achieved by the communication interface 1902 in the communication device 1900 shown in Figure 19.

[0479] As an optional implementation, the communication device 1900 may include multiple processors, for example, in addition to processor 1901 in FIG19, it may also include processor 1907.

[0480] As an optional implementation, the communication device 1900 also includes an output device 1905 and an input device 1906. Exemplarily, the input device 1906 is a liquid crystal display (LCD), a light-emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector, etc. For example, the input device 1906 can be a keyboard, mouse, microphone, joystick, touchscreen device, or sensing device, etc. The output device 1905 is a display screen, a speaker, etc.

[0481] It should be noted that the communication device 1900 may be a desktop computer, a portable computer, a web server, a mobile phone, a tablet computer, a wireless terminal, an embedded device, a chip system, or a device with a similar structure to that shown in Figure 19. Furthermore, the composition shown in Figure 19 does not constitute a limitation on the communication device. In addition to the components shown in Figure 19, the communication device may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0482] In this embodiment of the application, the chip system may be composed of chips or may include chips and other discrete devices.

[0483] As another possible product form, the first network element, first terminal device, or first core network device described in this application embodiment can be implemented using a general bus architecture. For ease of explanation, refer to FIG20, which is a schematic diagram of the structure of a communication device 2000 provided in this application embodiment. The communication device 2000 includes a processor 2001 and a transceiver 2002. The communication device 2000 can be a first network element, or a chip or chip system therein; or, the communication device 2000 can be a first terminal device, or a chip or module therein; or, the communication device 2000 can be a first core network device, or a chip or module therein. The function / implementation process of the transceiver module 1802 in FIG18 can be implemented by the transceiver 2002 in the communication device 2000 shown in FIG20; similarly, the function / implementation process of the processing module 1801 in FIG18 can be implemented by the processor 2001 in the communication device 2000 shown in FIG20.

[0484] Figure 20 shows only the main components of the communication device 2000. In addition to the processor 2001 and transceiver 2002, the communication device may further include a memory 2003.

[0485] Optionally, the processor 2001 is mainly used to process communication protocols and communication data, control the entire communication device, execute software programs, and process the data of the software programs. The memory 2003 is mainly used to store software programs and data. The transceiver 2002 may include radio frequency (RF) circuitry and an antenna. The RF circuitry is mainly used for converting baseband signals to RF signals and processing RF signals. The antenna is mainly used for transmitting and receiving RF signals in the form of electromagnetic waves.

[0486] Optionally, the processor 2001, transceiver 2002, and memory 2003 can be connected via a communication bus.

[0487] When the communication device is powered on, the processor 2001 can read the software program in the memory 2003, interpret and execute the instructions of the software program, and process the data of the software program. When data needs to be transmitted wirelessly, the processor 2001 performs baseband processing on the data to be transmitted and outputs the baseband signal to the radio frequency (RF) circuit. The RF circuit processes the baseband signal and transmits the RF signal outward in the form of electromagnetic waves through the antenna. When data is sent to the communication device, the RF circuit receives the RF signal through the antenna, converts the RF signal into a baseband signal, and outputs the baseband signal to the processor 2001. The processor 2001 converts the baseband signal into data and processes the data.

[0488] In some embodiments, transceiver 2002 may include a transmitter and a receiver, wherein the transmitter is used to implement the transmission operation in the above method embodiments; and the receiver is used to implement the reception operation in the above method embodiments.

[0489] For example, when the communication device is a chip, the chip may not include the memory 2003; that is, the communication device includes a processor 2001 and a transceiver 2002. In this case, the transceiver 2002 is the input / output interface of the chip, wherein the transmitter in the transceiver corresponds to the output interface of the chip, and the receiver in the transceiver corresponds to the input interface of the chip.

[0490] In some embodiments, this application also provides a communication device, which includes a processor for implementing the methods in any of the above method embodiments.

[0491] As one possible implementation, the communication device also includes a memory. This memory stores necessary computer programs or instructions. The processor can invoke the computer programs or instructions in the memory to cause the communication device to execute the methods in any of the above method embodiments. Alternatively, the memory may be external and not located within the communication device.

[0492] As another possible implementation, the communication device also includes an interface circuit, which is a code / data read / write interface circuit, used to receive computer execution instructions (which are stored in memory and may be read directly from memory or may be transmitted through other devices) and transmit them to the processor.

[0493] As another possible implementation, the communication device also includes a communication interface for communicating with modules outside the communication device.

[0494] It is understood that the communication device can be a chip or a chip system. When the communication device is a chip system, it can be composed of chips or may include chips and other discrete devices. This application does not specifically limit this.

[0495] This application also provides a computer-readable storage medium having a computer program or instructions stored thereon, which, when executed by a computer, implements the functions of any of the above-described method embodiments.

[0496] This application also provides a computer program product that, when executed by a computer, implements the functions of any of the above method embodiments.

[0497] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0498] It is understood that the systems, apparatuses, and methods described in this application can also be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0499] The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. The components shown as units may or may not be physical units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0500] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0501] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software programs, implementation can be, in whole or in part, in the form of a computer program product. This computer program product includes one or more computer instructions. When the computer program or instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device containing one or more servers, data centers, etc., that can be integrated with the medium. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive (SSD)). In this embodiment, the computer may include the aforementioned apparatus.

[0502] Although this application has been described herein in conjunction with various embodiments, those skilled in the art, by reviewing the accompanying drawings, disclosure, and appended claims, will understand and implement other variations of the disclosed embodiments in carrying out the claimed application. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude a plurality. A single processor or other unit can implement several functions listed in the claims. While different dependent claims may recite certain measures, this does not mean that these measures cannot be combined to produce good results.

Claims

1. A calling method, characterized in that, The method is applied to a first network element, and the method includes: Receive the first message; Based on the first message, determine the second message. Send the second message; wherein, Both the first message and the second message contain a media negotiation request. The first message does not contain capability information of the first terminal device, while the second message does contain capability information of the first terminal device; or... Both the first message and the second message contain media response information. The first message contains capability information of the second terminal device, while the second message does not contain capability information of the second terminal device. The first terminal device is used to call the second terminal device. The first network element is a network element in the IMS network accessed by the first terminal device.

2. The method according to claim 1, characterized in that, The capability information of the terminal device includes the call encoding formats supported by the terminal device, wherein the terminal device is either the first terminal device or the second terminal device.

3. The method according to claim 2, characterized in that, The capability information of the terminal device also includes one or more of the following: the preferred information of the terminal device, SIP-related information supported by the terminal device, call characteristics supported by the terminal device, and Quality of Service (QoS) parameters in the Session Description Protocol (SDP) supported by the terminal device.

4. The method according to claim 2 or 3, characterized in that, Before determining the second message based on the first message, the method further includes: Obtain the capability information of the terminal device.

5. The method according to claim 4, characterized in that, The terminal device is the first terminal device, and obtaining the capability information of the terminal device includes: Receive capability information of the first terminal device from the first terminal device.

6. The method according to claim 5, characterized in that, The capability information of the first terminal device is included in the first request message, which is the IMS registration request of the first terminal device. or, Before receiving the capability information of the first terminal device from the first terminal device, the method further includes: Receive a first request message from the first terminal device.

7. The method according to claim 4, characterized in that, The terminal device is the first terminal device, and obtaining the capability information of the terminal device includes: The first terminal device receives capability information from a first core network device, where the first core network device is the core network device to which the first terminal device is connected.

8. The method according to claim 7, characterized in that, Before receiving the capability information of the first terminal device from the first core network device, the method further includes: Receive a first request message from the first terminal device, wherein the first request message is an IMS registration request from the first terminal device; Send a first indication message to the first core network device, the first indication message being used to instruct the first core network device to send the capability information of the first terminal device.

9. The method according to claim 4, characterized in that, The terminal device is the first terminal device, and obtaining the capability information of the terminal device includes: The second terminal device receives capability information from a second network element, where the second network element is a network element in the IMS network accessed by the second terminal device.

10. The method according to any one of claims 1-9, characterized in that, The first message and the second message also include session static information, and the method further includes: Obtain session static information from the first message; The session static information is stored, which includes one or more of the following: the source address, the destination address, or the routing information of the message.

11. The method according to claim 10, characterized in that, The method further includes: Receive third message; Based on the static session information and the third message, a fourth message is determined; Send the fourth message; Wherein, the third message contains the session static information, and the fourth message does not contain the session static information; or, The third message does not contain the session static information, while the fourth message does contain the session static information.

12. The method according to claim 11, characterized in that, If the third message does not contain the session static information, and the fourth message contains the session static information, then the third message and the fourth message are included in the temporary response acknowledgment PRACK message or the update UPDATA message; If the third message contains the session static information and the fourth message does not contain the session static information, then the third message and the fourth message are included in the response message of the PRACK message or the response message of the UPDATA message.

13. The method according to any one of claims 1-12, characterized in that, Before receiving the first message, the method further includes: Receive a second indication message, which indicates that the signaling transmitted during the call does not contain terminal device capability information.

14. The method according to claim 13, characterized in that, The receiving of the second indication information includes: receiving second indication information from the first terminal device; wherein... The second indication information is included in the first request message, which is a registration request for the first terminal device; or, Before receiving the second indication information from the first terminal device, the method further includes: Receive a first request message from the first terminal device.

15. The method according to any one of claims 1-12, characterized in that, Both the first message and the second message contain second indication information, which is used to indicate that the signaling transmitted during the call does not contain UE capability information.

16. A calling method, characterized in that, The method is applied to a first terminal device, and the method includes: Obtain a first message, which includes a media negotiation request or media response information. The first message does not contain terminal device capability information. The terminal device is either a first terminal device or a second terminal device. The first terminal device is used to call the second terminal device. The call process is executed based on the first message.

17. The method according to claim 16, characterized in that, The capability information of the terminal device includes the call encoding formats supported by the terminal device.

18. The method according to claim 17, characterized in that, The capability information of the terminal device also includes one or more of the following: the preferred information of the terminal device, the Session Initiation Protocol (SIP) related information supported by the terminal device, the call characteristics supported by the terminal device, and the Quality of Service (QoS) parameters in the Session Description Protocol (SDP) supported by the terminal device.

19. The method according to claim 17 or 18, characterized in that, Before obtaining the first message, the method further includes: Send the capability information of the first terminal device.

20. The method according to claim 19, characterized in that, The capability information of the first terminal device is included in the first request message, which is the IMS registration request of the first terminal device. or, Before sending the capability information of the first terminal device, the method further includes: sending the first request message.

21. The method according to any one of claims 16-20, characterized in that, The first message contains the media negotiation request, and obtaining the first message includes: Generate the first message; accordingly, The step of executing the call process according to the first message includes: sending the first message.

22. The method according to claim 21, characterized in that, Before sending the first message, the method further includes: Obtain the address information of the first network element, where the first network element is a network element in the IMS network accessed by the first terminal device; Sending the first message includes: sending the first message to the first network element.

23. The method according to claim 22, characterized in that, The step of obtaining the address information of the first network element includes: Send a second request message, the second request message being a packet data network (PDN) connection request from the first terminal device; A second response message is received, which is used to indicate that the PDN connection of the first terminal device is established, and the second response message contains the address information of the first network element.

24. The method according to any one of claims 16-20, characterized in that, The first message contains the media response information, and obtaining the first message includes: Receive the first message.

25. The method according to any one of claims 16-24, characterized in that, The method further includes: Obtain a third message, which does not contain session static information, and the session static information contains one or more of the following: the source address, the destination address, or the routing information of the message.

26. The method according to claim 25, characterized in that, The acquisition of the third message includes: The third message is generated.

27. The method according to claim 26, characterized in that, The third message is included in the temporary response PRACK message or the update UPDATA message.

28. The method according to claim 25, characterized in that, The acquisition of the third message includes: The third message is received, which is included in the response message of the PRACK message or the response message of the UPDATA message.

29. The method according to any one of claims 16-28, characterized in that, Before receiving the first message, the method further includes: Send a second indication message, which indicates that the signaling transmitted during the call does not contain the capability information of the terminal device.

30. The method according to claim 29, characterized in that, The second indication information is included in the first request message, which is a registration request for the first terminal device; or, Before sending the second instruction information, the method further includes sending the first request message.

31. The method according to any one of claims 16-28, characterized in that, The first message includes second indication information, which indicates that the signaling transmitted during the call does not contain terminal device capability information.

32. A communication method, characterized in that, The method is applied to a first core network device, and the method includes: Based on the network access method of the first terminal device, the address information of the first network element is determined. The network access method of the first terminal device includes the first terminal device accessing the narrowband high-speed rail network. The first network element is a network element in the network protocol multimedia subsystem (IMS) network accessed by the first terminal device. The first network element supports the mutual conversion between signaling containing the capability information of the terminal device and signaling not containing the capability information of the terminal device during the call process. The terminal device is either the first terminal device or the second terminal device. The first terminal device is used to call the second terminal device. Send the address information of the first network element.

33. The method according to claim 32, characterized in that, Before determining the address information of the first network element based on the network access method of the first terminal device, the method further includes: Receive a second request message, the second request message being a packet data network (PDN) connection request from the first terminal device; Sending the address information of the first network element includes: sending a second response message, the second response message being used to indicate the establishment of a PDN connection for the first terminal device, the second response message containing the address information of the first network element.

34. The method according to claim 32 or 33, characterized in that, The method further includes: Send the capability information of the first terminal device.

35. The method according to claim 34, characterized in that, Before sending the capability information of the first terminal device, the method further includes: Receive first indication information, which is used to instruct the first core network device to send the capability information of the first terminal device.

36. The method according to claim 34 or 35, characterized in that, The capability information of the first terminal device includes the call encoding formats supported by the first terminal device.

37. The method according to claim 36, characterized in that, The capability information of the first terminal device also includes one or more of the following: the preferred information of the terminal device, the Session Initiation Protocol (SIP) related information supported by the terminal device, the call characteristics supported by the terminal device, and the Quality of Service (QoS) parameters in the Session Description Protocol (SDP) supported by the terminal device.

38. A communication device, characterized in that, The communication device includes a processor; the processor is configured to run a computer program or instructions to cause the communication device to perform the method as claimed in any one of claims 1-15; or to cause the communication device to perform the method as claimed in any one of claims 16-31; or to cause the communication device to perform the method as claimed in any one of claims 32-37.

39. A computer-readable storage medium, characterized in that, A computer-readable storage medium stores computer instructions or programs that, when executed on a computer, cause the method of any one of claims 1-15 to be performed; or cause the method of any one of claims 16-31 to be performed; or cause the method of any one of claims 32-37 to be performed.

40. A computer program product, characterized in that, The computer program product includes a computer program or instructions; when some or all of the computer instructions are executed on a computer, they cause the method of any one of claims 1-15 to be performed; or cause the method of any one of claims 16-31 to be performed; or cause the method of any one of claims 32-37 to be performed.

41. A chip, characterized in that, include: Memory is used to store computer program instructions; A processor is configured to execute the computer program instructions, causing a communication device including the chip to perform the method as described in any one of claims 1-15; or, causing the communication device including the chip to perform the method as described in any one of claims 16-31; or, causing the communication device including the chip to perform the method as described in any one of claims 32-37.

Images