CN115002695B

CN115002695B - IMS calling method, device, user equipment and computer storage medium

Info

Publication number: CN115002695B
Application number: CN202111652244.4A
Authority: CN
Inventors: 李海波; 孙敏; 薛超
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2021-12-30
Filing date: 2021-12-30
Publication date: 2023-04-07
Anticipated expiration: 2041-12-30
Also published as: CN115002695A

Abstract

The embodiment of the application provides an IMS calling method, an IMS calling device and user equipment. The method comprises the following steps: the UE sends a first update message to the NW. The first update message includes voice codec types proposed to be used by the UE and a PT value corresponding to each voice codec type. The UE receives a first update response message sent by the NW. The first update response message contains at least one of the voice codec types that the NW has chosen for its proposed use and the PT value for each voice codec type. And when the first update response message contains the voice coding and decoding type which is not supported by the UE and the first PT value corresponding to the voice coding and decoding type which is not supported by the UE is the PT value contained in the first update message, the UE sends a second request message to the NW to reinitiate the SDP negotiation. The second request message does not contain the first PT value. Therefore, the NW is prevented from insisting on using the voice coding and decoding type which is not supported by the UE, and the success rate of SDP negotiation is improved.

Description

IMS calling method, device, user equipment and computer storage medium

Technical Field

The embodiment of the application relates to the technical field of communication, in particular to an IMS calling method, an IMS calling device, user equipment and a computer storage medium.

Background

In an IP Multimedia Subsystem (IMS) voice service, when a User Equipment (UE) initiates a voice call, a Session Description Protocol (SDP) negotiation with a network side (NW) based on a Session Initiation Protocol (SIP) is required to determine a voice codec type. In this way, the user equipment transmits and codes the voice stream with the voice coding and decoding type determined based on the SDP negotiation, so as to implement the voice call function.

The internet engineering opinion group RFC 3551 specification promises technical parameters for the payload format of voice streams. The specification identifies the speech codec type by a Payload Type (PT) value, i.e. different PT values can be used to identify different speech codec types. The RFC 3551 specification specifically stipulates that PT values ranging from 96 to 127 can be used as dynamic PT values to identify voice codec types. Here, "dynamic" means that the correspondence between PT values and voice codec types is not uniquely fixed, but can be dynamically defined during an SDP session.

In the UE, the correspondence between the dynamic PT value and the supported voice codec type is usually preset at the time of factory shipment, and is not changed after factory shipment. Different IMS networks or servers may process the dynamic PT value in different ways due to different manufacturers, models, or configurations. For example: some IMS networks or servers will not preset the correspondence between dynamic PT values and voice codec types, while other IMS networks or servers will preset the correspondence between dynamic PT values and voice codec types, i.e. some dynamic PT values are reserved.

In the SDP negotiation process, if the PT value included in the INVITE message sent by the user equipment to the network side is the same as the PT value reserved by the network side, but the voice codec types corresponding to the same PT value are different, the user equipment and the network side will propose to use different voice codec types, thereby causing SDP negotiation failure and further failing to establish an IMS call.

Disclosure of Invention

The embodiment of the application provides an IMS calling method, an IMS calling device and user equipment, so that the success rate of IMS calling is improved.

In a first aspect, an embodiment of the present application provides an IMS call method. The method comprises the following steps: user Equipment (UE) sends a first request message to network equipment (NW); the first request message comprises at least one voice coding and decoding type supported by the UE and a payload type PT value corresponding to each voice coding and decoding type; the first request message is used to initiate session description protocol SDP negotiation to the NW. The UE receives a first response message sent by the NW; the first response message includes at least one own voice encoding and decoding type selected by the NW from the voice encoding and decoding types included in the first request message, and a PT value corresponding to each voice encoding and decoding type; the first response message also contains the voice codec types reserved by the NW for the PT values contained in the first request message, and a PT value corresponding to each reserved voice codec type. The UE selects at least one voice coding and decoding type supported by the UE from the voice coding and decoding types contained in the first response message as a voice coding and decoding type proposed by the UE, and sends a first updating message to the NW; the first update message includes voice codec types proposed to be used by the UE and a PT value corresponding to each voice codec type. The UE receives a first updating response message sent by the NW; the first update response message contains at least one proposed speech codec type selected by the NW from the speech codec types contained in the first update message, and a PT value corresponding to each speech codec type; the first update response message also contains the voice codec types reserved by the NW for the PT values contained in the first update message, and a PT value corresponding to each reserved voice codec type. If the first update response message contains a first voice codec type which is not supported by the UE and the first PT value corresponding to the first voice codec type is the PT value contained in the first update message, the UE sends a second request message to the NW; the second request message is used for UE to initiate SDP renegotiation to NW; the second request message includes at least one voice codec type supported by the UE and a PT value corresponding to each voice codec type, and the second request message does not include the first PT value.

According to the method, when the first update response message of the NW contains the voice codec type which is not supported by the UE, and the first PT value corresponding to the voice codec type which is not supported by the UE is the PT value contained in the first update message, the UE sends the second request message to the NW to reinitiate the SDP negotiation, and the second request message does not contain the first PT value, thereby preventing the NW from insisting on using the voice codec type which is not supported by the UE, and improving the success rate of the SDP negotiation.

In one implementation, the second request message includes a second PT value randomly selected by the UE from the preset dynamic PT values, and the second PT value is different from the first PT value. According to the method, the UE can use the randomly selected second PT value to replace the first PT value, so that the second request message does not contain the first PT value, thereby avoiding the NW from insisting on using the voice codec type which is not supported by the UE, and improving the success rate of SDP negotiation.

In one implementation, after the UE sends the second request message to the NW, the method further includes: the UE determines whether the renegotiation with the NW SDP is successful. If the SDP renegotiation is successful, the UE records the fault type of the call in a fault table as a PT value reserved by the NW, a solution is a replacement PT value, an invalid PT value is a first PT value, and an effective PT value is a second PT value. If the SDP renegotiation fails, the UE initiates a domain change redialing request to the NW, and records the fault type of the call in a fault table as the coding and decoding type cannot be negotiated, wherein the solution is domain change redialing, and the invalid PT value is the first PT value. According to the method, the UE records the solution when the SDP negotiation fails in the fault table, so that when the UE encounters the same fault again, the corresponding solution can be inquired from the fault table, and the fault self-healing is realized.

In one implementation, if the first update response message includes a first voice codec type that is not supported by the UE and the first PT value corresponding to the first voice codec type is the PT value included in the first update message, the UE sends the second request message to the NW, including: the UE queries whether a first target solution corresponding to the first voice codec type and the first PT value exists in the fault table. If the first target solution does not exist in the failure table, the UE sends a second request message to the NW. According to the method, when the UE encounters SDP negotiation failure, the target solution is inquired from the failure table to try failure self-healing, and if the target solution cannot be inquired, a second request message is sent to the NW.

In one implementation, the method further comprises: if the first target solution exists in the fault table, the UE sends a third request message to the NW; the third request message is used for UE to initiate SDP renegotiation to NW; the third request message comprises at least one voice coding and decoding type supported by the UE and a PT value corresponding to each voice coding and decoding type; the third request message does not contain the first PT value but contains the valid PT value in the first target solution. According to the method, when the UE encounters SDP negotiation failure, if the target solution is inquired from the failure table, the UE sends a third request message to the NW according to the target solution so as to realize failure self-healing.

In one implementation, before the UE sends the first request message to the NW, the method further includes: and when the UE initiates the IMS call, inquiring whether a second target solution corresponding to the called number exists in the fault table. If the second target solution exists in the fault table, the UE sends a fourth request message to the NW; the fourth request message is used for UE to initiate SDP negotiation to the NW; the fourth request message comprises at least one voice coding and decoding type supported by the UE and a PT value corresponding to each voice coding and decoding type; the fourth request message includes the valid PT value in the second target solution but does not include the invalid PT value in the second target solution. According to the method, when the UE inquires that the called number has the target solution in the fault table, the UE initiates SDP negotiation to the NW according to the effective PT value corresponding to the target solution. The NW is prevented from insisting on using codec modes not supported by the UE during SDP negotiation. Therefore, the possible call faults are pre-judged and eliminated, and the success rate of SDP negotiation is improved.

In one implementation, the UE sends a first request message to the NW, including: if the second target solution does not exist in the failure table, the UE sends a first request message to the NW.

In a second aspect, an embodiment of the present application provides an IMS call apparatus. The device includes: a sending unit configured to send a first request message to the network device NW; the first request message comprises at least one voice coding and decoding type supported by the network equipment UE and a payload type PT value corresponding to each voice coding and decoding type; the first request message is used to initiate session description protocol SDP negotiation to the NW. A receiving unit, configured to receive a first response message sent by the NW; the first response message includes at least one own voice encoding and decoding type selected by the NW from the voice encoding and decoding types included in the first request message, and a PT value corresponding to each voice encoding and decoding type; the first response message also contains the reserved voice codec types that the NW has reserved for the PT values contained in the first request message, and a PT value corresponding to each reserved voice codec type. The sending unit is further configured to select at least one of the voice codec types included in the first response message and supported by itself as a proposed voice codec type for use in the first response message, and send a first update message to the NW; the first update message includes voice codec types proposed to be used by the UE and a PT value corresponding to each voice codec type. The receiving unit is further configured to receive a first update response message sent by the NW; the first update response message contains at least one proposed speech codec type selected by the NW from the speech codec types contained in the first update message, and a PT value corresponding to each speech codec type; the first update response message also contains the voice codec types reserved by the NW for the PT values contained in the first update message, and a PT value corresponding to each reserved voice codec type. The sending unit is further configured to send a second request message to the NW if the first update response message includes a first voice codec type that is not supported by the UE and the first PT value corresponding to the first voice codec type is the PT value included in the first update message; the second request message is used for UE to initiate SDP renegotiation to the NW; the second request message includes at least one voice codec type supported by the UE and a PT value corresponding to each voice codec type, and the second request message does not include the first PT value.

According to the IMS call apparatus provided in this embodiment of the present application, when the first update response message of the NW includes the voice codec type that is not supported by the UE, and the first PT value corresponding to the voice codec type that is not supported by the UE is the PT value included in the first update message, the UE sends the second request message to the NW to reinitiate the SDP negotiation, and the second request message does not include the first PT value, thereby preventing the NW from insisting on using the voice codec type that is not supported by the UE, and improving the success rate of the SDP negotiation.

In one implementation, the second request message includes a second PT value randomly selected by the UE from preset dynamic PT values, and the second PT value is different from the first PT value. In this way, the UE can use the randomly selected second PT value to replace the first PT value, so that the second request message does not include the first PT value, thereby preventing the NW from insisting on using the voice codec type that the UE does not support, and improving the success rate of SDP negotiation.

In one implementation, the apparatus further comprises: and the judging unit is used for judging whether the UE successfully renegotiates with the NW SDP. And the recording unit is used for recording the fault type of the call in a fault table as a PT value reserved by the NW, a solution as a replacement PT value, an invalid PT value as a first PT value and an effective PT value as a second PT value if the SDP renegotiation is successful. The sending unit is further configured to initiate a domain change redial request to the NW if the SDP renegotiation fails. The recording unit is further configured to record, in the fault table, that the fault type of the call is a codec type that cannot be negotiated if the SDP renegotiation fails, and the solution is domain change redialing and the invalid PT value is the first PT value. According to the device, the UE records the solution when the SDP negotiation fails in the fault table, so that when the UE encounters the same fault again, the corresponding solution can be inquired from the fault table, and the fault self-healing is realized.

In one implementation, the apparatus further comprises: and a query unit, configured to query whether a first target solution corresponding to the first voice codec type and the first PT value exists in the fault table if the first update response message includes the first voice codec type that is not supported by the UE and the first PT value corresponding to the first voice codec type is the PT value included in the first update message. The sending unit is further configured to send a second request message to the NW if the first target solution does not exist in the failure table. According to the device, when the UE encounters failure of SDP negotiation, the target solution is inquired from the failure table to try failure self-healing, and if the target solution cannot be inquired, a second request message is sent to the NW.

In one implementation, the sending unit is further configured to send a third request message to the NW if the first target solution exists in the failure table; the third request message is used for UE to initiate SDP renegotiation to NW; the third request message comprises at least one voice coding and decoding type supported by the UE and a PT value corresponding to each voice coding and decoding type; the third request message does not contain the first PT value but contains a valid PT value in the first target solution. According to the device, when the UE encounters the failure of SDP negotiation failure, if the target solution is inquired from the failure table, the UE sends a third request message to the NW according to the target solution so as to realize the self-healing of the failure.

In one implementation, the querying unit is further configured to query, when the UE initiates the IMS call, whether a second target solution corresponding to the called number exists in the fault table. The sending unit is further configured to send a fourth request message to the NW if the second target solution exists in the fault table; the fourth request message is used for UE to initiate SDP negotiation to the NW; the fourth request message comprises at least one voice coding and decoding type supported by the UE and a PT value corresponding to each voice coding and decoding type; the fourth request message contains a valid PT value in the second target solution but does not contain an invalid PT value in the second target solution. According to the device, when the UE inquires that the called number has the target solution in the fault table, the UE initiates SDP negotiation to the NW according to the effective PT value corresponding to the target solution. The NW is prevented from insisting on using codec modes not supported by the UE during SDP negotiation. Therefore, the possible call faults are pre-judged and eliminated, and the success rate of SDP negotiation is improved.

In one implementation, the sending unit is further configured to send a first request message to the NW if the second target solution does not exist in the failure table.

In a third aspect, an embodiment of the present application provides a user equipment, including: a processor and a memory; the memory stores program instructions that, when executed by the processor, cause the user equipment to perform the above aspects and methods in its various implementations.

In a fourth aspect, embodiments of the present application further provide a chip system, where the chip system includes a processor and a memory, and the memory stores program instructions, and when the program instructions are executed by the processor, the chip system is caused to perform the methods in the foregoing aspects and their respective implementations. For example, information involved in the above-described methods is generated or processed.

In a fifth aspect, embodiments of the present application further provide a computer-readable storage medium, in which program instructions are stored, and when the program instructions are executed on a computer, the computer is caused to execute the methods in the foregoing aspects and their respective implementations.

In a sixth aspect, the present application also provides a computer program product, which when run on a computer, causes the computer to execute the methods in the above aspects and their respective implementations.

Drawings

Fig. 1 is a schematic diagram of a wireless communication system for implementing an IMS voice service according to an embodiment of the present application;

fig. 2 is a schematic structural diagram of a user equipment 101 provided in an embodiment of the present application;

fig. 3 is a flow chart of a user equipment failing in negotiation with a network side SDP;

fig. 4 is a flowchart of an IMS call method 400 provided in a first embodiment of the present application;

fig. 5 is a diagram of an example of an IMS call method 400 according to a first embodiment of the present application;

fig. 6 is a flow chart of an IMS call method 600 according to a second embodiment of the present application;

fig. 7 is a diagram of an example of an IMS call method 600 according to a second embodiment of the present application;

fig. 8 is a flowchart of an IMS call method 800 according to a third embodiment of the present application;

fig. 9 is a diagram of an example of an IMS call method 800 according to a third embodiment of the present application;

fig. 10 is a flowchart of an IMS call method 1000 according to a fourth embodiment of the present application;

fig. 11 is a diagram of an example of an IMS call method 1000 according to a fourth embodiment of the present application;

fig. 12 is a schematic structural diagram of an IMS call device according to an embodiment of the present application;

fig. 13 is a schematic structural diagram of another IMS call device according to an embodiment of the present application.

Detailed Description

The terms "first," "second," and "third," etc. in the description and claims of the present application and the description of the drawings are used for distinguishing between different objects and not for limiting a particular order.

In the embodiments of the present application, the words "exemplary" or "such as" are used herein to mean serving as an example, instance, or illustration. Any embodiment or design described herein as "exemplary" or "e.g.," is not necessarily to be construed as preferred or advantageous over other embodiments or designs. Rather, use of the word "exemplary" or "such as" is intended to present relevant concepts in a concrete fashion.

The terminology used in the description of the embodiments of the present application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application, which will be described in detail below with reference to the accompanying drawings.

The third generation partnership project (3 rd generation partnership project,3 gpp) defines that a fifth generation mobile communication network (5 th generation mobile network, 5 g) and a fourth generation mobile communication network (4 th generation mobile network, 5 g) can provide voice services based on IMS, so as to implement a voice call function between User Equipment (UE) such as a mobile phone.

First, a wireless communication system in which the embodiments of the present application can be applied is described with reference to fig. 1. Fig. 1 is a schematic diagram of a wireless communication system in which embodiments of the present application may be applied. The wireless communication system may be a Long Term Evolution (LTE) technology, a 5G wireless communication system, or a new communication system appearing in the future wireless communication development, and the like. As long as the wireless communication system adopts IMS as a voice implementation scheme, the wireless communication system may apply the embodiments of the present application.

As shown in fig. 1, the wireless communication system 100 includes a UE 101, an access network device 102 that provides an LTE network for the UE 101, an access network device 103 that provides a 5G network for the UE 101, a core network device 104, and an IP Multimedia Subsystem (IMS) 105.

The IMS 105 may include a Proxy-Call Session Control Function (P-CSCF) entity, an Interrogating-Call Session Control Function (I-CSCF), a Serving-Call Session Control Function (S-CSCF) entity, and a Home Subscriber Server (HSS).

The P-CSCF entity is the first point of attachment of the access network to the IMS, and all session messages originating from and terminating at IMS-capable UEs are forwarded through the P-CSCF entity. The P-CSCF entity is operable to forward an IMS registration request from the UE to the S-CSCF entity and to forward registration response information to the UE.

The I-CSCF entity may connect the S-CSCF entity and the P-CSCF entity for providing the UE with access to the home network. During the IMS registration, the P-CSCF entity may forward an IMS registration request from the UE to the I-CSCF entity, and the I-CSCF entity may query the HSS in the IMS to select an S-CSCF entity for the UE. In the calling process, a calling message destined for an IMS network is firstly routed to an I-CSCF, an I-CSCF entity can inquire the address information of an S-CSCF entity registered by a user for UE through an HSS in the IMS, and then the message is routed to the S-CSCF.

The S-CSCF entity is a control core of the IMS and provides functions of session control, registration and the like for the UE. And the S-CSCF entity is used for receiving the IMS registration request forwarded by the P-CSCF entity and carrying out authentication on the UE by matching with the HSS. And after the S-CSCF determines that the authentication is passed, the subscription information of the UE is acquired from the HSS. And the S-CSCF entity is also used for connecting with each application server based on the ISC interface, and triggering the application servers to execute operation, and routing the request of the UE to the corresponding application servers.

The HSS is used to store all user and service related data such as user identity, subscription information, access information, etc.

It should be understood that although the wireless communication system 100 shown in fig. 1 includes only one UE 101, one access network device 102, and one access network device 103, the wireless communication system 100 may include more UEs and/or more access network devices. In addition, the wireless communication system 100 may also include access network equipment that provides a 2G/3G network for the UE 101.

The access network device 102, the access network device 103 and the core network device 104 may be implemented in different network elements in different wireless communication systems 100. For example: in a 5G independent networking (SA) wireless communication system, the core network device 104 may be a 5G core network 5GC, and the access network device 103 may be a 5G access network NG-RAN (e.g., a gNB base station), or a NG-eNB base station upgraded from a 4G access network E-UTRAN (e.g., an eNB base station) to support access to the core network device 104. In a 5G non-independently Networked (NAS) wireless communication system, the core network device 104 may be a 4G core network EPC or a 5G core network 5GC, and the access network device 103 may be a ng-eNB base station. In an LTE wireless communication system, the core network device 104 may be a 4G core network EPC and the access network device 102 may be an eNB base station. It is understood that IMS voice traffic may be carried through different network elements in different wireless communication systems 100, in addition to the UE 101. For convenience of description, network devices for carrying IMS voice services other than the UE 101, such as the access network device 103, the core network device 104, and the IMS 105, may be referred to as a network side network, referred to as NW for short.

Fig. 2 is a schematic diagram of a hardware structure of the UE 101 according to an embodiment of the present application. As shown in fig. 2, the UE 101 may include a processor 110, an external memory interface 120, an internal memory 121, a Universal Serial Bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a key 190, a motor 191, an indicator 192, a camera 193, a display screen 194, a SIM card interface 195, and the like. The sensor module 180 may include a pressure sensor 180A, a gyro sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, and the like.

It is to be understood that the structure illustrated in FIG. 2 does not constitute a specific limitation on the UE 101. In another embodiment of the application, the UE 101 may include more or fewer components than illustrated, or combine certain components, or split certain components, or a different arrangement of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

Processor 110 may include one or more processing units. For example, the Processor 110 may include an Application Processor (AP), a Modem (Modem), a Graphics Processing Unit (GPU), an Image Signal Processor (ISP), a controller, a video codec, a Digital Signal Processor (DSP), a baseband Processor, and/or a Neural-Network Processing Unit (NPU), and the like. The different processing units may be separate devices or may be integrated in one or more processors.

The charging management module 140 is configured to receive a charging input from a charger. The charger can be a wireless charger or a wired charger.

The power management module 141 is used to connect the battery 142, the charging management module 140 and the processor 110. The power management module 141 receives input from the battery 142 and/or the charge management module 140, and supplies power to the processor 110, the internal memory 121, the display 194, the camera 193, the wireless communication module 160, and the like.

The wireless communication function of the UE 101 may be implemented by the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, a modem, a baseband processor, and the like.

The antennas 1 and 2 are used for transmitting and receiving electromagnetic wave signals. Each antenna in the UE 101 may be used to cover a single or multiple communication bands. Different antennas can also be multiplexed to improve the utilization of the antennas.

The mobile communication module 150 may provide a solution for wireless communication including 2G/3G/4G/5G, etc. applied on the UE 101.

The Wireless Communication module 160 may provide solutions for Wireless Communication applied to the UE 101, including Wireless Local Area Networks (WLANs) (e.g., wi-Fi Networks), bluetooth (bluetooth, BT), global Navigation Satellite System (GNSS), frequency Modulation (FM), near Field Communication (NFC), infrared, and the like. The wireless communication module 160 may be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2, performs frequency modulation and filtering processing on electromagnetic wave signals, and transmits the processed signals to the processor 110. The wireless communication module 160 may also receive a signal to be transmitted from the processor 110, perform frequency modulation and amplification on the signal, and convert the signal into electromagnetic waves via the antenna 2 to radiate the electromagnetic waves.

In some embodiments, in examples where the wireless communication module 160 provides bluetooth communication, the wireless communication module 160 may specifically be a bluetooth chip. The bluetooth chip may include one or more memories, one or more processors, and the like. The processor in the bluetooth chip can perform operations such as frequency modulation, filtering, operation, judgment and the like on the electromagnetic wave received by the antenna 2, and convert the processed signal into electromagnetic wave to be radiated out through the antenna 2, i.e. the processor 110 is not needed for processing.

The wireless communication module 160 or the processor 110 may perform the steps performed by the UE 101 in the method provided in the embodiment of the present application, which may specifically refer to the related descriptions of the UE 101 in fig. 3 to 11, and are not described herein again.

The UE 101 implements display functions via the GPU, display screen 194, application processor, and the like. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor.

The display screen 194 is used to display images or videos, etc. A series of Graphical User Interfaces (GUIs) may be displayed on a display screen 194 of the UE 101.

The UE 101 may implement the camera functions via an ISP, camera 193, video codec, GPU, display screen 194, and application processor, among others.

The camera 193 is used to capture still images or video.

The external memory interface 120 may be used to connect an external memory card, such as a Micro SD card, to extend the storage capabilities of the UE 101.

The internal memory 121 may be used to store computer-executable program code, which includes instructions. The processor 110 executes various functional applications of the UE 101 and data processing by executing instructions stored in the internal memory 121.

The UE 101 can implement audio functions such as music playing, sound recording, etc. through the audio module 170, the speaker 170A, the headphones 170B, the microphone 170C, the headset interface 170D, and the application processor, etc.

The SIM card interface 195 is used to connect a SIM card. The SIM card can be inserted into the SIM card interface 195 or extracted from the SIM card interface 195 to make contact with and separate from the UE 101. The UE 101 may support 1 or N SIM card interfaces, with N being a positive integer greater than 1. The SIM card interface 195 may support a Nano SIM card, a Micro SIM card, a SIM card, etc. The same SIM card interface 195 can be inserted with multiple cards at the same time. The SIM card interface 195 is also compatible with external memory cards. The UE 101 interacts with the network through the SIM card to realize functions such as conversation, data communication and the like.

On top of the above components, operating systems such as the hong meng operating system, the iOS operating system, the android operating system, the windows operating system, etc. run. Applications may be installed and run on the operating system. In other embodiments, there may be multiple operating systems running within the UE 101.

In IMS voice services, when a UE initiates a voice call, the UE needs to perform SDP negotiation with the NW based on the SIP protocol to determine the voice codec type. In this way, the UE and the NW may transmit and codec the voice stream based on the voice codec type determined by the SDP negotiation to implement the voice call function. Common types of speech codec are for example: enhanced Voice Services (EVS), adaptive multi-rate audio compression (AMR), adaptive multi-rate wideband audio compression (AMR-WB), adaptive multi-rate narrowband audio compression (AMR-NB), internet low bit rate codec (iLBC), and so on.

The internet engineering opinion group RFC 3551 specification promises technical parameters for the payload format of voice streams. The specification identifies the voice codec type by Payload Type (PT) value, i.e. different PT values can be used to identify different voice codec types. As shown in table 1, the RFC 3551 specification specifically stipulates that PT values ranging from 96 to 127 can be used as dynamic PT values to identify the voice codec type. By "dynamic" is meant that the correspondence between PT values and speech codec types is not uniquely fixed, but can be dynamically defined during the SDP session. For example: the AMR-WB format may correspond to PT values of 98, 99, etc.

TABLE 1

Wherein "a" in the media type represents audio, "V" represents video, "? "indicates that the media type is not fixed," N/a "indicates no media type, and the clock frequency refers to the clock frequency used in the media codec.

In the UE, the correspondence between the dynamic PT value and the supported voice codec type is usually preset at the time of factory shipment, and is not changed after factory shipment. For example, a UE performs the following table 2 settings on the correspondence between the dynamic PT values and the voice codec types before shipping:

TABLE 2

It should be noted that, the voice codec types supported by UEs of different brands, different models, or different network systems may be different, and the corresponding relationship between the dynamic PT value and the voice codec types supported by the dynamic PT value may also be different.

In addition, different IMS networks or servers may process the dynamic PT value in different ways due to different manufacturers, models, or configurations. For example: some IMS networks or servers do not preset the correspondence of dynamic PT values to voice codec types. Other IMS networks or servers preset the corresponding relationship between some dynamic PT values and the voice codec types, that is, reserve some dynamic PT values. For example, some IMS network makes the following table 3 reservations for PT values:

TABLE 3

In the SDP negotiation process, if the PT value included in the INVITE message sent by the UE to the NW is the same as the PT value reserved by the NW, but the voice codec types corresponding to the same PT value are different, the UE and the NW may propose to use different voice codec types, thereby causing SDP negotiation failure and failing to successfully establish an IMS call.

For example: the UE has set the PT value 97 to correspond to the AMR codec. The NW reserved PT value 97 corresponds to the iLBC codec. Then, when the UE sends the INVITE message to the NW containing the PT value 97, this indicates that the UE proposes to use AMR codec in IMS voice call, while the NW proposes to use iLBC codec. Failure of SDP negotiation results because the voice codec types proposed by both parties cannot agree.

Fig. 3 is a flow diagram illustrating SDP negotiation failure between the UE and the NW. The reason why the SDP negotiation between the UE and the NW fails is exemplarily described below with reference to fig. 3. Wherein: the UE presets the corresponding relationship between the dynamic PT value and the voice codec type as shown in table 1. The NW makes reservations for dynamic PT values as in table 3.

In step S301, when initiating an IMS voice call, the UE may send an INVITE message to the NW according to the voice codec type supported by the UE. The INVITE message is used to indicate to the NW the voice codec type supported by the UE itself. The INVITE message is one of Session Initiation Protocol (SIP) messages, and is used to indicate that the calling party is inviting the called party to participate in the session. The INVITE message may include a description of the session that the called party is invited to join, and may indicate the type of media that the calling party is able to receive, etc.

It should be added that, in the SDP negotiation process, the negotiation between the UE and the NW for the voice codec type is implemented based on the PT value. Therefore, the INVITE message sent by the UE includes both the voice codec types supported by the UE itself and PT values corresponding to the voice codec types set by the UE.

Illustratively, according to the settings of table 1, the INVITE message sent by the UE to the NW may include the following field 1 for indicating the voice codec type supported by itself:

it should be added that the UE may also indicate the number of channels supported by the UE for the voice codec types supported by the UE. For example, the tail 1 of AMR-WB/16000/1 indicates that the number of supported channels is 1 when AMR-WB codec is used. The number of channels supported by the NW is typically more than the number of channels supported by the UE, so the NW typically does not need to indicate to the UE the number of channels it supports.

Generally, if the NW does not reserve a dynamic PT value, the NW, upon receiving the INVITE message, selects the voice codec type that the NW itself supports from the voice codec type indicated by the INVITE message. The NW then sends the selected voice codec type to the UE via a 183 message of the SIP protocol.

The 183 message is also referred to as a session progress response message. 183 message is used to convey information that is not otherwise classified in the process of establishing an IMS call. For example: a reason phrase (reason phrase), a header field, a message body, and conveying more detailed information about the progress of the call.

Illustratively, when the INVITE message contains field 1, if the NW supports AMR codec and telephone-event/8000 codec therein, then the 183 message received by the UE may include the following field 2 indicating the type of speech codec supported by the NW:

if the NW makes a reservation for a dynamic PT value, the NW reserved PT value is the same as the PT value in the INVITE message. The NW may also add its reserved PT value and its indicated voice codec type to the 183 message.

Illustratively, if the NW reserves the PT value 98 for the iLBC codec when the INVITE message contains field 1, the NW will also add the reserved PT value 98 and its corresponding iLBC codec to the 183 message. Thus, the 183 message received by the UE may include the following field 3 to indicate the voice codec types supported by the NW:

it can be seen that, since the PT value reserved by the NW is the same as the PT value in the INVITE message, and the corresponding voice codec types of the same PT value in the NW and the INVITE message are different, the same PT value in the 183 message corresponds to two different voice codec types. For example, when the NW reserves PT value 98, the PT value 98 in the 183 message corresponds to both the iLBC codec and the telephone-event/8000 codec.

In step S302, the UE receives the 183 message transmitted by the NW.

After receiving the 183 message, the UE may select the voice codec type proposed to be used by itself from the 183 message according to the voice codec type supported by itself.

In step S303, the UE sends an UPDATE message to the NW. The UPDATE message includes the type of speech codec selected by the UE. The UPDATE message is one of SIP protocol message methods, and is used for a caller and a callee to UPDATE session information before a final response of an INVITE request.

Illustratively, when the 183 message contains field 3, the UE may select the voice codec AMR/8000/1 and telephone-event/8000 it proposes to use from the 183 message according to its own supported voice codec type. Thus, the UPDATE message sent by the UE to the NW may include the following field 4 to indicate the type of speech codec proposed by itself:

in general, if the NW does not reserve a dynamic PT value, the NW, upon receiving the UPDATE message, may select a voice codec type proposed to be used by the NW from the UPDATE message according to the voice codec type supported by the NW. The NW may then send the selected voice codec type to the UE via an UPDATE OK message.

Illustratively, if the NW proposes to use AMR codec and telephone-event/8000 codec when the UPDATE message contains field 4, then the UPDATE OK message that the NW sends to the UE may include the following field 5 indicating the type of speech codec that the NW proposes to use:

in this way, the UE and the NW propose the same voice codec type and the same PT value, the SDP negotiation is successful, and the UE and the NW can successfully establish the IMS voice call.

However, if the NW reserves a dynamic PT value, the NW may add the NW reserved PT value and the corresponding voice codec type as its proposed voice codec type to the UPDATE OK message.

Illustratively, if the NW reserves the PT value 98 for the iLBC codec when the UPDATE message contains field 4. Then, even if the UE does not propose to adopt the iLBC codec in the UPDATE message, the NW sends the iLBC codec to the UE as the type of speech codec it proposes to use. At this time, the UPDATE OK message sent by the NW to the UE may include the following field 6 for indicating the type of voice codec proposed to be used by itself:

in step S304, the UE receives the UPDATE OK message sent by the NW.

And the UE determines that the voice coding and decoding type proposed by the UE is not consistent with the voice coding and decoding type proposed by the NW according to the UPDATE OK message, so that the negotiation between the UE and the NWSDP fails.

In step S305, the UE sends a CANCEL message to the NW to proactively request termination of the IMS call.

The NW then sends 487 the message (i.e. request termination of RESPONSE identities) to the UE in RESPONSE to the CANCEL message.

In step S306, the UE receives the 487 message sent by the NW to terminate the IMS call.

As can be seen from the SDP negotiation procedure between the UE and the NW shown in fig. 3, if the PT value contained in the INVITE message sent by the UE to the NW is the same as the PT value reserved by the NW, but the voice codec types corresponding to the same PT value are different, the UE and the NW may propose to use different voice codec types, resulting in SDP negotiation failure and thus the IMS call cannot be successfully established.

In order to solve the foregoing technical problem, an IMS call method is provided in the embodiments of the present application. When the UE fails to negotiate with the SDP of the NW, the UE can initiate the SDP negotiation to the NW again, and the success rate of the IMS call is improved.

The following is a first embodiment of the present application.

A first embodiment of the present application provides an IMS call method. Fig. 4 is a flowchart of an IMS call method 400 according to a first embodiment of the present application. As shown in FIG. 4, the method 400 includes the following steps S401-S405:

in step S401, the UE transmits a first request message to the NW. The first request message includes at least one voice codec type supported by the UE and a PT value corresponding to each voice codec type. The first request message is used to initiate SDP negotiation to the NW.

The first request message may be, for example, an INVITE message in a session initiation protocol, SIP, message. In the first request message, different PT values indicate different types of voice codecs.

When the UE initiates an IMS call to the NW, at least one voice codec type and its corresponding PT value may be selected from among the voice codec types supported by the UE according to the settings at the time of shipment, and configured in the first request message. In this way, the NW can know the voice codec type supported by the UE from the first request message.

In step S402, the UE receives the first response message sent by the NW. The first response message is sent by the NW in response to the first request message. The first response message includes at least one NW-supported voice codec type selected by the NW from the voice codec types included in the first request message, and a PT value corresponding to each voice codec type. The first response message also contains the reserved voice codec types that the NW has reserved for the PT values contained in the first request message, and a PT value corresponding to each reserved voice codec type.

The first response message may be, for example, a 183 message in a SIP message.

Generally, after receiving the first request message, the NW selects at least one voice codec type supported by the NW from the voice codec types included in the first request message. Then, the NW configures the selected voice codec type and the PT value corresponding thereto in a first response message and transmits the first response message to the UE.

However, if the NW has previously reserved some PT values. When the PT value contained in the first request message is the same as the PT value reserved by the NW, the NW configures the reserved voice codec type for the same PT value in the first response message. In this case, the first request message and the first response message may contain the same PT value, but the voice codec types corresponding to the same PT value may be different.

For example: the PT value reserved by the NW is a first PT value corresponding to a first speech codec type. The first request message includes a first PT value corresponding to the second voice codec type. Then the NW, after receiving the first request message, will configure the first PT value and the first voice codec type in the first response message. At this time, the first response message and the first request message each include the first PT value. However, the first PT value corresponds to the first voice codec type in the first response message and corresponds to the second voice codec type in the first request message.

At step S403, the UE selects at least one of the voice codec types supported by itself from the voice codec types included in the first response message as the voice codec type it proposes to use, and sends a first update message to the NW. The first update message includes voice codec types proposed to be used by the UE and a PT value corresponding to each voice codec type.

The first UPDATE message may be, for example, an UPDATE message in a SIP message.

After receiving the first response message, the UE selects at least one of the voice codec types supported by the UE from the voice codec types included in the first response message as the voice codec type proposed by the UE. The UE configures the proposed codec type and its corresponding PT value in a first update message and sends it to the NW.

In step S404, the UE receives the first update response message sent by the NW. The first update response message is sent by the NW in response to the first update message. The first update response message contains at least one of the voice codec types that the NW has proposed to use, selected from the voice codec types contained in the first update message, and the PT value corresponding to each voice codec type. The first update response message also contains the type of speech codec that the NW has reserved for the PT value contained in the first update message, and a PT value corresponding to each reserved type of speech codec.

The first UPDATE response message may be, for example, an UPDATE OK message in a SIP message.

Generally, after receiving the first update message, the NW selects at least one speech codec type from the speech codec types included in the first update message as the speech codec type proposed by the NW. Then, the NW configures the proposed voice codec type and its corresponding PT value in a first update response message and sends it to the UE.

However, if the NW has reserved a certain speech codec type for a certain PT value contained in the first update message in advance, the NW will insist on this reserved speech codec type as the proposed speech codec type. At this time, the NW will configure the reserved voice codec type for the PT value included in the first update message and the PT value corresponding to the reserved voice codec type in the first update response message.

The voice codec type reserved by the NW for the PT value included in the first update message may be a voice codec type supported by the UE, or may be a voice codec type not supported by the UE. Since the UE cannot perform the IMS voice service using the voice codec type that is not supported by the UE, when the voice codec type reserved by the NW for the PT value included in the first update message is the voice codec type that is not supported by the UE, the SDP negotiation between the UE and the NW fails.

For example: if the NW reserves the first PT value contained in the first update message for the first speech codec type. Then the NW will configure the first speech codec type and the first PT value in the first update response message as well. When the first update response message contains the first voice codec type, the UE and the NW may fail the SDP negotiation if the first voice codec type is a voice codec type that is not supported by the UE.

In addition, if the PT value corresponding to the voice codec type not supported by the UE is the PT value included in the first update message, the UE may determine that the cause of the failure in SDP negotiation is that the NW has reserved the PT value included in the first update message.

For example: if the first update response message contains the first voice codec type, the first voice codec type corresponds to the first PT value, and the first PT value is the PT value contained in the first update message, the UE may determine that the cause of the failure in SDP negotiation is that the NW reserved the first PT value.

Step S405, if the first update response message includes the voice codec type that is not supported by the UE, and the PT value corresponding to the voice codec type that is not supported by the UE is the PT value included in the first update message, the UE sends a second request message to the NW. The second request message is used for the UE to initiate SDP renegotiation to the NW. The second request message includes at least one voice codec type supported by the UE and a PT value corresponding to each voice codec type. The second request message does not contain the PT value corresponding to the voice codec type not supported by the UE in the first update response message.

In one implementation, the second request message does not include the PT value corresponding to the voice codec type that is not supported by the UE in the first update response message. The second request message contains a PT value randomly selected by the UE from preset dynamic PT values, and the randomly selected PT value is different from the PT value corresponding to the voice coding and decoding type which is not supported by the UE in the first updating response message.

For example: the second request message may not contain the first PT value but contain the second PT value. In the second request message, the UE may replace the first PT value and the corresponding speech codec type in the first request message with the second PT value and the corresponding speech codec type. The UE may exclude the first PT value from the preset dynamic PT values and then randomly select one PT value as the second PT value.

The second request message may be, for example, a RE-INVITE message in a SIP message. The RE-INVITE message is one of SIP messages for indicating that the calling party is modifying the session on the basis of the original INVITE message, e.g. modifying the media type that the calling party can receive, etc.

The complete SDP renegotiation flow may comprise the following steps:

the UE sends a RE-INVITE message to the NW.

The UE receives the 183 message sent by the NW in response to the RE-INVITE message.

The UE sends an UPDATE message to the NW in response to the 183 message.

The UE receives the UPDATE OK message sent by the NW in response to the UPDATE message.

Since the RE-INVITE message does not contain the first PT value reserved by the NW, the NW will not insist on using the first voice codec type not supported by the UE during the SDP renegotiation process, and thus SDP negotiation failure will not be caused.

In this embodiment of the application, when the first update response message of the NW includes the voice codec type that is not supported by the UE, and the PT value corresponding to the voice codec type that is not supported by the UE is the PT value included in the first update message, the UE sends the second request message to the NW to reinitiate the SDP negotiation, where the second request message does not include the PT value corresponding to the voice codec type that is not supported by the UE in the first update response message, thereby preventing the NW from insisting on using the voice codec type that is not supported by the UE, and improving the success rate of the SDP negotiation.

The IMS call method provided in the first embodiment of the present application is further described below with reference to an example.

Fig. 5 is a diagram of an example of an IMS call method 400 according to the first embodiment of the present application. As shown in fig. 5, this example includes steps S501-S505, corresponding to steps S401-S405, respectively, in the method 400 shown in fig. 4.

When a user uses UE to dial a called number '139000000000000', the UE selects a voice coding and decoding type supported by the UE and a PT value corresponding to the voice coding and decoding type. The following field 1 is thus obtained:

a＝rtpmap:99AMR-WB/16000/1

a＝rtpmap:97AMR/8000/1

a＝rtpmap:96telephone-event/16000

a＝rtpmap:98telephone-event/8000

in S501, the UE transmits an INVITE message to the NW. The INVITE message includes field 1:

after receiving the INVITE message, the NW selects the codec AMR/8000 and the telephone-event/8000 and their corresponding PT values 97, 98 that it supports itself from the voice codec types contained in the INVITE message. In addition, since the INVITE message contains PT value 98, the NW reserves PT value 98 for codec iLBC/8000. Therefore, the NW will also choose PT value 98 and its corresponding codec iLBC/8000 as the self-supported speech codec type. The following field 3 is thus obtained:

a＝rtpmap:98iLBC/8000

a＝rtpmap:97AMR/8000

a＝rtpmap:98telephone-event/8000

in step S502, the UE receives a 183 message transmitted by the NWUE. 183 message includes field 3:

after the UE receives the 183 message, it selects the proposed codec AMR/8000/1, telephone-event/8000 and PT values 97, 98 from the voice codec types contained in the 183 message. The following field 4 is thus obtained:

a＝rtpmap:97AMR/8000/1

a＝rtpmap:98telephone-event/8000

in step S503, the UE sends an UPDATE message to the NW. The UPDATE message includes field 4:

after receiving the UPDATE message the NW selects the codec telephone-event/8000 and its corresponding PT value 98 that it proposes to use from the UPDATE message. In addition, since the NW reserves PT value 98 for codec iLBC/8000. Therefore, the NW will also choose the PT value 98 and its corresponding codec iLBC/8000 as the type of speech codec it proposes to use. The following field 6 is thus obtained:

a＝rtpmap:98iLBC/8000

a＝rtpmap:98telephone-event/8000

in step S504, the UE receives the UPDATE OK message sent by the NW. The UPDATE OK message includes a field 6:

the UE finds that the NW insists on using codec iLBC/8000 after receiving the UPDATE OK message, while the UE itself does not support iLBC/8000. And in the UPDATE OK message, the PT value 98 corresponding to the codec iLBC/8000 is the PT value contained in the INVITE message. So the UE determines that the NW made a reservation for PT value 98.

In step S505, the UE sends a RE-INVITE message to the NW. The RE-INVITE message is used to initiate SDP renegotiation with the network device. Wherein the RE-INVITE message does not include the PT value 98, but replaces the PT value 98 with another random PT value 100. The RE-INVITE message may illustratively include the following fields 7:

where EVS is a voice codec type preset by the UE for PT value 100.

In this way, the UE does not use the NW reserved PT value 98 in the RE-INVITE message. The NW is prevented from insisting on using the voice coding and decoding type iLBC which is not supported by the UE, so that the success rate of SDP negotiation is improved.

The following is a second embodiment of the present application.

A second embodiment of the present application provides an IMS call method. Fig. 6 is a flowchart of an IMS call method 600 according to a second embodiment of the present application. As shown in FIG. 6, method 600 includes steps S601-S6072. Steps S601 to S605 are similar to steps S401 to S405 in the method 400 shown in fig. 4, and are not described herein again. The following steps are also included after step S605:

in step S606, the UE determines whether renegotiation with NW SDP is successful. Wherein the SDP renegotiation is successful if the voice codec type proposed by the UE is the same as the voice codec type proposed by the NW. If the voice codec type proposed to be used by the UE is different from the voice codec type proposed to be used by the NW, then the SDP renegotiation fails.

For example: when the second request message does not contain the first PT value but contains the second PT value, the UE and the NW may successfully renegotiate in SDP as long as the second PT value is not a PT value reserved by the NW and the NW has no other compatibility problems. If the second PT value is also the NW reserved PT value, then the UE may fail SDP renegotiation with the NW.

If the SDP renegotiation is successful, step S6071 is performed. In step S6071, the UE records, in the failure table, the type of failure of the call as a PT value reserved by the NW, a solution as a replacement PT value, and an invalid PT value causing failure in SDP negotiation and a valid PT value causing success in SDP renegotiation.

For example: the invalid PT value is a first PT value, and the valid PT value is a second PT value.

If the SDP renegotiation fails, step S6072 is performed. In step S6072, the UE initiates a domain change redial request to the NW. In addition, the UE records the fault type of the call in a fault table as a codec type which cannot be negotiated, the solution is domain change redialing, and an invalid PT value which causes SDP negotiation failure. For example: the invalid PT value is the first PT value.

The domain change redial request may be, for example, a circuit switched domain fallback (CSFB) request initiated by the UE to the NW. The CSFB request is used to trigger the NW to drop the voice service back to the CS domain, where the voice call is made.

In specific implementation, the UE may perform failure learning when the SDP negotiation fails, and record failure information and solutions of each SDP negotiation failure to obtain a failure table. The fault table, as shown in table 4, may include some or all of the following elements: fault type, called number, invalid PT value, voice codec type corresponding to the invalid PT value in UE (UE side codec for short), voice codec type reserved in NW for the invalid PT value (NW codec for short), solution, valid PT value, etc.

TABLE 4

Wherein:

the failure type may include, for example, PT values being reserved by the NW and voice codec type being unable to be negotiated. If the UE renegotiation with NW SDP is successful, the failure type is "PT value reserved by NW". If the UE fails to renegotiate with the NW SDP, the failure type is "Voice codec type cannot be negotiated".

The invalid PT value refers to a PT value that causes SDP negotiation failure, i.e., a PT value reserved by the NW, e.g., a first PT value.

The corresponding voice codec type of the invalid PT value in the UE refers to a voice codec type, for example, the first voice codec type, set for the invalid PT value by the UE at factory shipment. The voice codec type reserved in the NW for the invalid PT value refers to a voice codec type set by the NW for the invalid PT value.

The solutions may include, for example, a change PT value and a change field redial. If the failure type is "PT value reserved by NW", the corresponding solution is "replace PT value". If the fault type is 'the voice coding and decoding type can not be negotiated', the corresponding type is domain change redial.

The valid PT value refers to a PT value, such as a second PT value, which can replace an invalid PT value to enable SDP renegotiation to be successful when the first request message includes the invalid PT value, resulting in SDP negotiation failure.

The IMS call method provided in the second embodiment of the present application is further described below with reference to an example.

Fig. 7 is a diagram of an example of an IMS call method 600 according to a second embodiment of the present application. As shown in fig. 7, this example includes steps S701-S7072, corresponding to steps S601-S6072, respectively, in the method 600 shown in fig. 6. Wherein steps S701 to S705 are similar to steps S501 to S505 in the example shown in fig. 5. The following steps may be included after step S705:

in step S706, the UE determines whether the negotiation with the NW SDP is successful again. If the voice codec type proposed by the UE is the same as the voice codec type proposed by the NW, then the SDP renegotiation is successful. If the NW still insists on using the voice codec type that the UE does not support, the SDP renegotiation fails.

If the SDP negotiation is successful, step S7071 is performed. In step S7071, the UE records in the fault table that the current fault type is "PT value reserved by NW", called number is "13900000000", invalid PT value is 98, UE side codec is AMR-WB, NW codec is iLBC, solution is "replace PT value", and valid PT value is 100.

If the SDP negotiation fails, step S7072 is performed. In step S7072, the UE initiates a domain change redial request to the NW. In addition, the UE records that the fault type at this time is ' voice coding and decoding type can not be negotiated ', the called number is ' 13900000000 ', the invalid PT value is 98 ', the UE side coding and decoding is AMR-WB, the NW coding and decoding is iLBC, and the solution is ' domain change redialing '.

In the embodiment of the application, after failing in SDP renegotiation, the UE initiates a domain change redialing request to the NW and drops the voice service back to the CS domain. Therefore, when the IMS voice call cannot be established, the UE cannot directly hang up the call, but continues to establish the voice call with the network equipment in the CS domain, and the success rate of the voice call is improved. In addition, when the SDP renegotiation fails, the UE also records the corresponding information such as the fault type, the solution and the like. Therefore, when the UE dials the same called number again in the follow-up process, the UE can take corresponding measures according to the recorded information so as to avoid the situation that the SDP negotiation fails to happen again.

The following is a third embodiment of the present application.

A third embodiment of the present application provides an IMS call method. Fig. 8 is a flowchart of an IMS call method 800 according to a third embodiment of the present application. As shown in fig. 8, method 800 includes steps S801-S8062. Wherein steps S801 to S804 are similar to steps S601 to S604 in the method 600 shown in fig. 6, and are not repeated herein. The following steps may be included after step S804:

step S805, if the first update response message includes the voice codec type that is not supported by the UE and the PT value corresponding to the voice codec type that is not supported by the UE is the PT value included in the first update message, the UE queries whether the target solution corresponding to the voice codec type that is not supported by the UE and the PT value corresponding to the voice codec type that is not supported by the UE exists in the fault table.

For example, when the first update response message contains a first voice codec type corresponding to a first PT value and the first PT value is also included in the first request message, the UE may determine that the failure type of SDP negotiation failure is "PT value reserved by NW". In this case, the UE may perform a query in the failure table according to the first PT value and the first voice codec type to determine whether a solution matching the current failure exists in the failure table. The first PT value is used to match an invalid PT value in the fault table. The first speech codec type is used to match the NW codecs in the failure table. If the first PT value and the first voice codec type are both successfully matched in the same fault record of the fault table, then the solution of the fault record is the target solution.

If the target solution exists in the fault table, step S8061 is executed. In step S8061, the UE transmits a third request message to the NW. The third request message is used for the UE to initiate SDP renegotiation to the NW. The third request message includes at least one voice codec type supported by the UE and a PT value corresponding to each voice codec type. The third request message does not contain the PT value corresponding to the voice codec type not supported by the UE in the first update response message but contains a valid PT value in the target solution.

The third request message may be, for example, a RE-INVITE message in a SIP message.

If the target solution does not exist in the fault table, step S8062 is executed. In step S8062, the UE sends a second request message to the NW.

As further shown in fig. 8, in one implementation, method 800 may further include steps S807-S8082 after step S8062. Steps S807-S8082 are similar to steps S606-S6072 in method 600, and are not described herein again.

In the embodiment of the application, when the SDP negotiation fails, the UE inquires whether a target solution exists in a fault table. And if the target solution is inquired, initiating SDP negotiation again to the NW according to the effective PT value in the target solution, and realizing self-healing of the fault.

The IMS call method provided in the third embodiment of the present application is further described below with reference to an example.

Fig. 9 is a diagram of an example of an IMS call method 800 according to a third embodiment of the present application. As shown in fig. 9, this example includes steps S901-S9082, corresponding to steps S801-S8082 in method 800 shown in fig. 8, respectively. Wherein steps S901-S904 are similar to steps S701-S704 in the example shown in fig. 7. Steps S907 to S9082 are similar to steps S706 to S7072 in the example shown in fig. 7. The following steps may be included between step S904 and step S907:

the UE finds that the NW insists on using codec iLBC/8000 after receiving the UPDATE OK message of the NW containing field 6, and PT value 98 corresponding to iLBC/8000 is contained in the INVITE message. The UE may determine that the NW reserved PT value 98. In this case, the UE performs step S905.

In step S905, the UE inquires of the failure table 4 whether a target solution exists according to the PT value 98 and the codec iLBC/8000.

After inquiry, the invalid PT value corresponding to the fault record with number 1 is 98, and the corresponding NW codec is iLBC. The UE thus determines that the target solution is a replacement PT value and the corresponding valid PT value is 100. The UE performs step S9061.

In step S9061, the UE sends an RE-INVITE message to the NW. The RE-INVITE message is used to trigger SDP renegotiation with the NW. The RE-INVITE message may use the valid PT value 100 instead of the PT value 98. The RE-INVITE message may illustratively include the following fields 7:

in this way, the UE initiates SDP negotiation using valid PT values 100 in the RE-INVITE message, while avoiding the use of invalid PT values 98. Therefore, the NW is prevented from insisting on using the voice coding and decoding types which are not supported by the UE, the self-healing of the fault is realized, and the success rate of SDP negotiation is improved.

In addition, if the UE does not inquire a solution from table 4, step S9062 is performed.

In step S9062, the UE sends an RE-INVITE message containing a random PT value to the NW.

After sending the RE-INVITE message, the UE may learn about a new call failure, and update the learned failure information and solution to table 4, so as to be used for subsequent query when encountering a call failure.

The following is a fourth embodiment of the present application.

A fourth embodiment of the present application provides an IMS call method. Fig. 10 is a flowchart of an IMS call method 1000 according to a fourth embodiment of the present application. As shown in FIG. 10, method 1000 includes steps S1001-S10102. Wherein steps S1004 to S10102 are similar to steps S802 to S8082 in the method 800 shown in fig. 8, and are not repeated herein. The following steps may be included before step S1004:

step S1001, when UE initiates an IMS call, UE inquires whether a target solution corresponding to a called number exists in a fault table.

If the SDP negotiation fails when the UE calls a certain called number before, the fault recovery is realized by replacing the PT value or the domain changing redialing scheme. Then the solution corresponding to the called number is recorded in the fault table of the UE. Therefore, when the user dials the called number again, the UE can look up the corresponding solution from the fault table. On the contrary, if the user dials a new called number or a called number for which SDP negotiation has not failed before, the UE cannot query the corresponding solution from the fault table.

If the target solution exists in the fault table, step S1002 is performed. In step S1002, the UE transmits a fourth request message to the NW according to the target solution. The fourth request message is used for the UE to initiate SDP negotiation to the NW. The fourth request message includes at least one voice codec type supported by the UE and a PT value corresponding to each voice codec type. The fourth request message includes a valid PT value corresponding to the target solution but does not include an invalid PT value.

The fourth request message may be, for example, an INVITE message in a SIP message.

In the embodiment of the present application, when querying that a called number has a target solution in a fault table, the UE initiates SDP negotiation to the NW according to an effective PT value corresponding to the target solution. The NW is prevented from insisting on using codec modes not supported by the UE during SDP negotiation. Therefore, the possible call faults are pre-judged and eliminated, and the success rate of SDP negotiation is improved.

If the target solution does not exist in the fault table, step S1003 is performed. In step S1003, the UE transmits a first request message to the NW. Step S1003 is similar to step S801 of method 800, and is not described herein again.

The IMS call method provided in the fourth embodiment of the present application is further described below with reference to an example.

Fig. 11 is a diagram of an example of an IMS call method 1000 according to a fourth embodiment of the present application. As shown in fig. 11, this example includes steps S1101-S11102, corresponding to steps S1001-S10102, respectively, in the method 1000 shown in fig. 10. Wherein steps S1104-S11102 are similar to steps S902-S9082 in the example shown in fig. 9. The following steps may be included before step S1104:

step S1101, when the UE initiates an IMS call, it queries whether a target solution corresponding to the called number exists in the fault table.

If the UE queries the target solution in the fault table, step S1102 is performed.

For example, when the called number is 13900000000, the UE can query the failure table 4 that the target solution is a replacement PT value, the corresponding valid PT value is 100, and the invalid PT value is 98.

In step S1102, the UE transmits an INVITE message to the NW. The INVITE message contains PT value 100 and does not contain an INVITE message for PT value 98. The INVITE message may illustratively include the following fields 7:

in this way, the UE initiates SDP negotiation using valid PT values 100 in the INVITE message, without using invalid PT values 98. The NW is prevented from insisting on using the voice coding and decoding types which are not supported by the UE, the prejudgment and elimination of the fault are realized, and the success rate of SDP negotiation is improved.

If the UE does not inquire the target solution in the failure table, step S1103 is performed.

In step S1103, the UE transmits an INVITE message to the NW. The NVITE message includes the supported voice codec types and the corresponding PT values.

In the embodiments provided in the present application, the aspects of the IMS call method provided in the present application are introduced from the perspective of the UE itself and from the perspective of the interaction between the UE and the NW. It is understood that the UE includes corresponding hardware structures and/or software modules for performing the respective functions in order to implement the above-mentioned functions. Those of skill in the art would readily appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as hardware or combinations of hardware and computer software. Whether a function is performed as hardware or computer software drives hardware depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

Fig. 12 is a schematic structural diagram of an IMS call device according to an embodiment of the present application.

In some embodiments, the UE may implement the corresponding functions by the hardware apparatus shown in fig. 12. As shown in fig. 12, the IMS call device may include: a transceiver 1201, a memory 1202, and a processor 1203.

In one implementation, the processor 1203 may include one or more processing units, such as: the processor 1203 may include an applications processor, a modem processor, a graphics processor, an image signal processor, a controller, a video codec, a digital signal processor, a baseband processor, and/or a neural network processor, among others. The different processing units may be separate devices or may be integrated into one or more processors. The memory 1202 is coupled to the processor 1203 for storing various software programs and/or sets of instructions. In some embodiments, memory 1202 may include volatile memory and/or non-volatile memory. The transceiver 1201 is, for example, a radio frequency circuit, a mobile communication module, a wireless communication module, and the like, which may be included to implement a wireless communication function of the UE.

In one embodiment, the software programs and/or sets of instructions in the memory 1202, when executed by the processor 1203, cause the UE to perform the method steps of: sending a first request message to the network device NW; the first request message comprises at least one voice coding and decoding type supported by the UE and a PT value corresponding to each voice coding and decoding type; the first request message is used to initiate session description protocol SDP negotiation to the NW. Receiving a first response message sent by the NW; the first response message includes at least one own voice encoding and decoding type selected by the NW from the voice encoding and decoding types included in the first request message, and a PT value corresponding to each voice encoding and decoding type; the first response message also contains the voice codec types reserved by the NW for the PT values contained in the first request message, and a PT value corresponding to each reserved voice codec type. At least one self-supported speech codec type selected from the speech codec types contained in the first response message as a proposed speech codec type to be used by the first response message, and sending a first update message to the NW; the first update message includes voice codec types proposed to be used by the UE and a PT value corresponding to each voice codec type. Receiving a first update response message sent by the NW; the first update response message contains at least one proposed speech codec type selected by the NW from the speech codec types contained in the first update message, and a PT value corresponding to each speech codec type; the first update response message also contains the voice codec types reserved by the NW for the PT values contained in the first update message, and a PT value corresponding to each reserved voice codec type. If the first update response message contains a first voice codec type which is not supported by the UE and the first PT value corresponding to the first voice codec type is the PT value contained in the first update message, sending a second request message to the NW; the second request message is used for UE to initiate SDP renegotiation to NW; the second request message includes at least one voice codec type supported by the UE and a PT value corresponding to each voice codec type, and the second request message does not include the first PT value.

In this way, when the first update response message of the NW contains the voice codec type that is not supported by the UE, and the first PT value corresponding to the voice codec type that is not supported by the UE is the PT value contained in the first update message, the UE sends the second request message to the NW to reinitiate the SDP negotiation, and the second request message does not contain the first PT value, thereby preventing the NW from insisting on using the voice codec type that is not supported by the UE, and improving the success rate of the SDP negotiation.

Optionally, the software program and/or sets of instructions in the memory 1202, when executed by the processor 1203, further cause the UE to perform the following method steps: it is determined whether the renegotiation with the NW SDP is successful. If the SDP is successfully renegotiated, the fault type of the call is recorded in a fault table as a PT value reserved by the NW, a solution is a replacement PT value, an invalid PT value is a first PT value, and an effective PT value is a second PT value. If the SDP renegotiation fails, a domain change redialing request is initiated to the NW, the fault type of the call is recorded in a fault table to be the codec type which can not be negotiated, the solution is domain change redialing, and the invalid PT value is the first PT value. Therefore, the UE records the solution when the SDP negotiation fails in the fault table, and when the UE encounters the same fault again, the corresponding solution can be inquired from the fault table, so that the fault self-healing is realized.

Optionally, the software program and/or sets of instructions in the memory 1202, when executed by the processor 1203, further cause the UE to perform the following method steps: if the first update response message contains a first voice codec type that is not supported by the UE and the first PT value corresponding to the first voice codec type is the PT value contained in the first update message, querying whether a first target solution corresponding to the first voice codec type and the first PT value exists in the failure table. If the first target solution does not exist in the failure table, a second request message is sent to the NW. Thus, when the UE encounters failure of SDP negotiation, the UE firstly queries the target solution from the failure table to try failure self-healing, and if the target solution cannot be queried, the UE sends a second request message to the NW.

Optionally, the software program and/or sets of instructions in the memory 1202, when executed by the processor 1203, further cause the UE to perform the following method steps: if the first target solution exists in the fault table, sending a third request message to the NW; the third request message is used for UE to initiate SDP renegotiation to NW; the third request message comprises at least one voice coding and decoding type supported by the UE and a PT value corresponding to each voice coding and decoding type; the third request message does not contain the first PT value but contains a valid PT value in the first target solution. In this way, when the UE encounters a failure of SDP negotiation failure, if the target solution is queried from the failure table, the UE sends a third request message to the NW according to the target solution, so as to implement failure self-healing.

Optionally, the software program and/or sets of instructions in the memory 1202, when executed by the processor 1203, further cause the UE to perform the following method steps: and when the IMS call is initiated, inquiring whether a second target solution corresponding to the called number exists in the fault table. If the second target solution exists in the fault table, sending a fourth request message to the NW; the fourth request message is used for UE to initiate SDP negotiation to the NW; the fourth request message comprises at least one voice coding and decoding type supported by the UE and a PT value corresponding to each voice coding and decoding type; the fourth request message contains a valid PT value in the second target solution but does not contain an invalid PT value in the second target solution. Thus, when the UE inquires that the called number has the target solution in the fault table, the UE initiates SDP negotiation to the NW according to the effective PT value corresponding to the target solution. The NW is prevented from insisting on using codec modes not supported by the UE during SDP negotiation. Therefore, the possible call faults are pre-judged and eliminated, and the success rate of SDP negotiation is improved.

Optionally, the software program and/or sets of instructions in the memory 1202, when executed by the processor 1203, further cause the UE to perform the following method steps: if the second target solution does not exist in the failure table, a first request message is sent to the NW.

In addition, in some embodiments, the UE may implement the corresponding functions through a software module. As shown in fig. 13, the IMS calling apparatus for implementing the function of the UE behavior includes: transmission section 1301 and reception section 1302.

Wherein: a sending unit 1301, configured to send a first request message to the network device NW; the first request message comprises at least one voice coding and decoding type supported by the network equipment UE and a PT value corresponding to each voice coding and decoding type; the first request message is used to initiate session description protocol SDP negotiation to the NW. A receiving unit 1302, configured to receive a first response message sent by the NW; the first response message includes at least one own voice encoding and decoding type selected by the NW from the voice encoding and decoding types included in the first request message, and a PT value corresponding to each voice encoding and decoding type; the first response message also contains the voice codec types reserved by the NW for the PT values contained in the first request message, and a PT value corresponding to each reserved voice codec type. The sending unit 1301 is further configured to select at least one self-supported speech codec type from the speech codec types included in the first response message as a proposed speech codec type for use by the sending unit, and send a first update message to the NW; the first update message includes voice codec types proposed to be used by the UE and a PT value corresponding to each voice codec type. The receiving unit 1302 is further configured to receive a first update response message sent by the NW; the first update response message contains at least one speech codec type that the NW proposes to use, selected from the speech codec types contained in the first update message, and a PT value corresponding to each speech codec type; the first update response message also contains the voice codec types reserved by the NW for the PT values contained in the first update message, and a PT value corresponding to each reserved voice codec type. The sending unit 1301 is further configured to send a second request message to the NW if the first update response message includes a first voice codec type that is not supported by the UE and a first PT value corresponding to the first voice codec type is a PT value included in the first update message; the second request message is used for UE to initiate SDP renegotiation to NW; the second request message includes at least one voice codec type supported by the UE and a PT value corresponding to each voice codec type, and the second request message does not include the first PT value.

Optionally, the apparatus further comprises: a determining unit 1303 is configured to determine whether the UE successfully renegotiates with the NW SDP. A recording unit 1304, configured to record, in the fault table, the fault type of the call as a PT value reserved by the NW, and the solution as a replacement PT value, where the invalid PT value is a first PT value, and the valid PT value is a second PT value, if the SDP renegotiation is successful. The sending unit 1301 is further configured to initiate a domain change redial request to the NW if the SDP renegotiation fails. The recording unit 1304 is further configured to record, in the fault table, that the fault type of the call is a codec type that cannot be negotiated if the SDP renegotiation fails, where the solution is domain change redial, and the invalid PT value is the first PT value. According to the device, the UE records the solution when the SDP negotiation fails in the fault table, so that when the UE encounters the same fault again, the corresponding solution can be inquired from the fault table, and the fault self-healing is realized.

Optionally, the apparatus further comprises: a query unit 1305, configured to query whether a first target solution corresponding to the first voice codec type and the first PT value exists in the fault table if the first update response message includes the first voice codec type that is not supported by the UE and the first PT value corresponding to the first voice codec type is the PT value included in the first update message. The sending unit 1301 is further configured to send a second request message to the NW if the first target solution does not exist in the failure table. According to the device, when the UE encounters failure of SDP negotiation, the target solution is inquired from the failure table to try failure self-healing, and if the target solution cannot be inquired, a second request message is sent to the NW.

Optionally, the sending unit 1301 is further configured to send a third request message to the NW if the first target solution exists in the fault table; the third request message is used for UE to initiate SDP renegotiation to NW; the third request message comprises at least one voice coding and decoding type supported by the UE and a PT value corresponding to each voice coding and decoding type; the third request message does not contain the first PT value but contains a valid PT value in the first target solution. According to the device, when the UE encounters the failure of SDP negotiation failure, if the target solution is inquired from the failure table, the UE sends a third request message to the NW according to the target solution so as to realize the self-healing of the failure.

Optionally, the querying unit 1305 is further configured to query, when the UE initiates the IMS call, whether a second target solution corresponding to the called number exists in the failure table. The sending unit 1301 is further configured to send a fourth request message to the NW if the second target solution exists in the fault table; the fourth request message is used for UE to initiate SDP negotiation to the NW; the fourth request message comprises at least one voice coding and decoding type supported by the UE and a PT value corresponding to each voice coding and decoding type; the fourth request message contains a valid PT value in the second target solution but does not contain an invalid PT value in the second target solution. According to the device, when the UE inquires that the called number has the target solution in the fault table, the UE initiates SDP negotiation to the NW according to the effective PT value corresponding to the target solution. The NW is prevented from insisting on using codec modes not supported by the UE during SDP negotiation. Therefore, the possible call faults are pre-judged and eliminated, and the success rate of SDP negotiation is improved.

Optionally, the sending unit 1301 is further configured to send a first request message to the NW if the second target solution does not exist in the failure table.

Embodiments of the present application also provide a computer storage medium, in which program instructions are stored, and when the program instructions are executed on a computer, the computer is enabled to execute the methods in the above aspects and the various implementation manners.

Embodiments of the present application also provide a computer program product, which when run on a computer, causes the computer to perform the methods in the above aspects and their various implementations.

The application also provides a chip system. The system on chip comprises a processor for enabling the above apparatus or device to perform the functions recited in the above aspects, for example, generating or processing information recited in the above methods. In one possible design, the system-on-chip further includes a memory for storing program instructions and data necessary for the above-described apparatus or device. The chip system may be formed by a chip, or may include a chip and other discrete devices.

The above embodiments are only for illustrating the embodiments of the present invention and are not to be construed as limiting the scope of the present invention, and any modifications, equivalent substitutions, improvements and the like made on the basis of the embodiments of the present invention shall be included in the scope of the present invention.

Claims

1. An IP multimedia subsystem, IMS, call method, comprising:

user Equipment (UE) sends a first request message to network equipment (NW); the first request message comprises at least one voice coding and decoding type supported by the UE and a payload type PT value corresponding to each voice coding and decoding type; the first request message is used for initiating Session Description Protocol (SDP) negotiation to the NW;

the UE receives a first response message sent by the NW; the first response message includes at least one self-supported voice coding and decoding type selected by the NW from the voice coding and decoding types included in the first request message, and a PT value corresponding to each voice coding and decoding type; the first response message further includes the voice codec type reserved by the NW for the PT value included in the first request message, and a PT value corresponding to each reserved voice codec type;

the UE selects at least one voice codec type supported by the UE from among the voice codec types included in the first response message as a voice codec type proposed to be used by the UE, and sends a first update message to the NW; the first update message comprises voice coding and decoding types proposed to be used by the UE and a PT value corresponding to each voice coding and decoding type;

the UE receives a first updating response message sent by the NW; the first update response message includes at least one proposed speech codec type selected by the NW from the speech codec types included in the first update message, and a PT value corresponding to each speech codec type; the first update response message further includes a voice codec type reserved by the NW for the PT value included in the first update message, and a PT value corresponding to each reserved voice codec type;

if the first update response message contains a first voice codec type that is not supported by the UE and the first PT value corresponding to the first voice codec type is the PT value contained in the first update message, the UE sends a second request message to the NW; the second request message is used for the UE to initiate SDP renegotiation to the NW; the second request message includes at least one voice codec type supported by the UE and a PT value corresponding to each voice codec type, and the second request message does not include the first PT value and its corresponding voice codec type.

2. The IMS call method according to claim 1, wherein the second request message includes a second PT value randomly selected by the UE from preset dynamic PT values, and the second PT value is different from the first PT value.

3. The IMS call method according to claim 2, wherein after the UE sends the second request message to the NW, the method further includes:

the UE judges whether renegotiation with the NW SDP is successful or not; wherein the SDP renegotiation success comprises that the UE proposed used voice codec type is the same as the NW proposed used voice codec type;

if the SDP is successfully renegotiated, the UE records the calling fault type in a fault table as a PT value reserved by the NW, a solution of the PT value is a replacement PT value, an invalid PT value is the first PT value, and an effective PT value is the second PT value;

if the SDP renegotiation fails, the UE initiates a domain change redialing request to the NW, and records the fault type of the call in a fault table as a coding and decoding type which cannot be negotiated, wherein the solution is domain change redialing, and the invalid PT value is the first PT value.

4. The IMS calling method according to claim 3, wherein if the first update response message includes a first voice codec type that is not supported by the UE, and the first PT value corresponding to the first voice codec type is the PT value included in the first update message, the UE sends a second request message to the NW, including:

the UE inquires whether a first target solution corresponding to the first voice coding and decoding type and the first PT value exists in the fault table or not;

if the first target solution does not exist in the failure table, the UE sends a second request message to the NW.

5. The IMS call method according to claim 4, further comprising:

if the first target solution exists in the failure table, the UE sends a third request message to the NW; the third request message is used for the UE to initiate SDP renegotiation to the NW; the third request message comprises at least one voice coding and decoding type supported by the UE and a PT value corresponding to each voice coding and decoding type; the third request message does not include the first PT value but includes a valid PT value in the first target solution.

6. The IMS call method according to any one of claims 3 to 5, wherein, before the UE sends the first request message to the NW, the method further comprises:

when the UE initiates an IMS call, inquiring whether a second target solution corresponding to the called number exists in the fault table;

if the second target solution exists in the failure table, the UE sends a fourth request message to the NW; the fourth request message is used for the UE to initiate SDP negotiation to the NW; the fourth request message comprises at least one voice coding and decoding type supported by the UE and a PT value corresponding to each voice coding and decoding type; the fourth request message includes a valid PT value in the second target solution but does not include an invalid PT value in the second target solution.

7. The IMS call method according to claim 6, wherein the UE sends a first request message to the NW, including: the UE sends the first request message to the NW if the second target solution does not exist in a failure table.

8. An IMS call device, comprising:

a sending unit configured to send a first request message to the network device NW; the first request message comprises at least one voice coding and decoding type supported by the network equipment UE and a payload type PT value corresponding to each voice coding and decoding type; the first request message is used for initiating Session Description Protocol (SDP) negotiation to the NW;

a receiving unit, configured to receive a first response message sent by the NW; the first response message includes at least one self-supported voice coding and decoding type selected by the NW from the voice coding and decoding types included in the first request message, and a PT value corresponding to each voice coding and decoding type; the first response message further includes the voice codec type reserved by the NW for the PT value included in the first request message, and a PT value corresponding to each reserved voice codec type;

the sending unit is further configured to select at least one self-supported speech codec type from the speech codec types included in the first response message as a proposed speech codec type, and send a first update message to the NW; the first update message comprises voice coding and decoding types proposed to be used by the UE and a PT value corresponding to each voice coding and decoding type;

the receiving unit is further configured to receive a first update response message sent by the NW; the first update response message contains at least one proposed speech codec type selected by the NW from the speech codec types contained in the first update message, and a PT value corresponding to each speech codec type; the first update response message further includes a voice codec type reserved by the NW for the PT value included in the first update message, and a PT value corresponding to each reserved voice codec type;

the sending unit is further configured to send a second request message to the NW if the first update response message includes a first voice codec type that is not supported by the UE and a first PT value corresponding to the first voice codec type is a PT value included in the first update message; the second request message is used for the UE to initiate SDP renegotiation to the NW; the second request message includes at least one voice codec type supported by the UE and a PT value corresponding to each voice codec type, and the second request message does not include the first PT value and its corresponding voice codec type.

9. A user device, comprising: a processor and a memory; the memory stores a computer program that, when executed by the processor, causes the user equipment to perform the method of any of claims 1-7.

10. A computer storage medium, in which a computer program is stored which, when run on a computer, causes the computer to perform the method of any one of claims 1 to 7.