KR102121556B1 - Apparatus and method for sending voice call between terminals - Google Patents

Abstract

It relates to a method and apparatus for a terminal supporting VoLTE to check VoLTE-capable information of a receiving terminal when a voice call is sent, and to send a VoLTE call or CS call according to the result of the confirmation. The verification unit of the terminal may check the VoLTE-capable information of the receiving terminal in a server that stores status information of the receiving terminal. As a result of the check, if the VoLTE call is not possible, the receiving terminal can send a CS call, and when the VoLTE call is possible, the receiving terminal can send the VoLTE call.

Description

Method and device for sending voice call between terminals{APPARATUS AND METHOD FOR SENDING VOICE CALL BETWEEN TERMINALS}

The present invention relates to a method of transmitting a VoLTE call or a CS call after confirming whether VoLTE is possible of a receiving terminal before calling from a VoLTE (Voice over Long term evolution) capable terminal.

In the terminal providing the existing LTE function, 3G network is used for voice and 3G network and LTE network are selectively used, whereas VoLTE is implemented in both LTE and voice networks.

VoLTE can send and receive video and text as well as high-quality HD (High Density) voice in packet units at the same time. VoLTE means a voice service, but since LTE technology is an ALL-IP based data only network, the VoLTE service actually provided is implemented in the form of data.

Although the LTE network is expanding and the number of VoLTE users is increasing, the LTE network is not 100% expanded for each carrier, and not all terminals support VoLTE calls. Therefore, a call between a terminal supporting VoLTE and a terminal not supporting VoLTE is made through a CS (Circuit Switched) method using a 3G network rather than the VoLTE method.

In addition, in a call between a terminal supporting VoLTE and a terminal not supporting VoLTE, although a VoLTE call is not possible, a relaying role between heterogeneous call communication and an HD voice decoding and encoding process and a CS voice decoding and encoding process are unnecessary. have.

According to one side, in a terminal supporting a Voice over Internet Protocol (VoIP) call, a confirmation unit for confirming VoIP capable information of a receiving terminal and a call for sending a CS (Circuit Switched) call when the receiving terminal is unable to make a VoIP call It provides a terminal including a generating unit.

According to one embodiment, the VoIP call may include a VoLTE call.

According to an embodiment, the verification unit may receive and confirm VoIP-enabled information of the receiving terminal from a server storing status information of the receiving terminal.

According to one embodiment, the verification unit may check the VoIP enable information of the receiving terminal before sending a VoIP call to the receiving terminal.

According to an embodiment, when the confirmation unit receives an input for requesting a call from the receiving terminal, it may check VoIP capable information of the receiving terminal.

According to an embodiment, the server storing status information of the receiving terminal may include at least one of an MCMS server, a presentation server, or a registration server.

According to an embodiment, the confirmation unit transmits a first message requesting VoIP-capable information of the receiving terminal to a server storing status information of the terminal, and from the server storing status information of the terminal It is possible to check the VoIP-capable information of the receiving terminal by receiving a second message including the VoIP-capable information of the receiving terminal.

According to an embodiment, the first message and the second message may be at least a part included in an IP Multimedia Subsystem (IMS) message.

According to one embodiment, the IMS message may correspond to the RCS-e standard.

According to one embodiment, it is possible to check the VoIP enable information of the receiving terminal through a result code corresponding to the result parameter of the second message.

According to one embodiment, the call generation unit may send a CS call even when the result code is a value indicating at least one of no required parameter, system error, database error, other error, or content storage error.

According to one embodiment, the call generator may send the CS call when the second message is not received.

According to the other side, in the call originating method of a terminal supporting a VoIP call, a step of confirming the VoIP enable information of the receiving terminal by the confirmation unit of the terminal and when the receiving terminal is unable to make a VoIP call, a CS call is called by the terminal. It provides a method comprising the step of sending the generator.

According to one embodiment, the VoIP call may include a VoLTE call.

According to an embodiment, the checking may be performed by receiving and confirming VoIP-capable information of the receiving terminal from a server storing status information of the receiving terminal.

According to an embodiment, the step of checking may confirm VoIP-capable information of the receiving terminal before sending a VoIP call to the receiving terminal.

According to an embodiment of the present disclosure, in the case of receiving an input for requesting a call to the receiving terminal, the checking step may check VoIP-capable information of the receiving terminal.

According to an embodiment, the server storing status information of the receiving terminal may include at least one of an MCMS server, a presentation server, or a registration server.

According to an embodiment of the present invention, the checking comprises transmitting the first message requesting VoIP-capable information of the receiving terminal to a server storing status information of the terminal and transmitting status information of the terminal. And confirming the VoIP-enabled information of the receiving terminal by receiving the second message including the VoIP-enabled information of the receiving terminal from the stored server.

According to an embodiment, the first message and the second message may be at least a part included in the IMS message.

According to one embodiment, the IMS message may correspond to the RCS-e standard.

According to one embodiment, the sending step may send the CS call when the second message is not received.

1 is a block diagram showing the configuration of a terminal according to an embodiment.
2 is a flow diagram of a voice transmission when a conventional calling terminal can make a VoLTE call and a receiving terminal cannot make a VoLTE call.
3 is a flowchart of a calling method when a VoLTE call is possible by a receiving terminal according to an embodiment.
4 is a flowchart of an outgoing method when a VoLTE call is possible by a receiving terminal according to an embodiment.
5 is a flowchart illustrating a method for checking whether VoLTE is possible between a terminal and a server according to an embodiment.
6 is a flowchart illustrating an origination method according to an embodiment.

Hereinafter, some embodiments will be described in detail with reference to the accompanying drawings. However, it is not limited or limited by these embodiments. The same reference numerals in each drawing denote the same members.

1 is a block diagram showing the configuration of a terminal according to an embodiment.

According to an embodiment, the terminal 100 supporting the VoIP call includes a confirmation unit 110 for confirming whether the receiving terminal supports VoIP and a call generation unit 120 for sending a VoIP call or a CS call as a result of the verification. It can contain.

According to an embodiment, the VoIP-type call supported by the terminal 100 may be a VoLTE-type call. Hereinafter, in order to facilitate understanding, the VoIP-type call is described as an example in which the call is a VoLTE method, but is not limited thereto, and is applicable to other VoIP-type calls, which is obvious to a person skilled in the art. .

The confirming unit 110 may check VoLTE-capable information of the receiving terminal. According to an embodiment, the verification unit 110 may check VoLTE-capable information of the receiving terminal from a server storing status information of the receiving terminal.

In the LTE network structure, all networks are IP-based. In contrast, the existing 3G method has a CS (Circuit Switch) network for voice calls separately from an IP network for data communication. CS voice may be understood to refer to a general quality voice used in a voice call in a conventional 3G method using a CS network. However, it should not be interpreted as being limited to or limited to these terms, and should be understood to include all voices that can be used for voice calls in 3G method, which is obvious to those skilled in the art.

In this way, even if the terminal 100 can make a VoLTE call, if the receiving terminal does not make a VoLTE call, the VoLTE call cannot be made. Therefore, in this case, since the CS call using the CS network needs to be sent, the verification unit 110 can check the VoLTE-capable information of the receiving terminal before the call is sent.

In the case of a call between a terminal supporting the existing VoLTE and a terminal not supporting the VoLTE, a VoLTE call is sent without checking whether the receiving terminal is capable of VoLTE. Therefore, since the VoLTE call is sent even though the HD voice call through VoLTE cannot be connected, the relaying role between heterogeneous call communication and the HD voice data of the calling terminal are decoded, and this is encoded as CS voice data, and the receiving terminal's The process of decoding the CS voice data and encoding it into HD voice data is unnecessary.

In this case, even if the CS voice signal is decoded and the decoded data is encoded into HD voice data, it is not converted to HD quality, so the calling terminal always receives a call with CS quality voice. In addition, even if the HD voice signal is decoded and the decoded data is encoded into CS voice data, the receiving terminal does not support VoLTE calls, so the receiving terminal receives a call with CS quality voice.

As a result, when at least one of the calling terminal and the receiving terminal does not support VoLTE, as a result, an unnecessary data conversion process is performed even though a call is made with CS quality voice rather than HD quality voice.

Therefore, it is necessary to check the VoLTE-capable information of the receiving terminal in the confirmation unit 110 of the terminal 100 before sending the call. As a result of the verification, if the receiving terminal does not support VoLTE, a CS call can be sent to make a CS-type call without performing unnecessary data conversion process. In addition, if the reception terminal supports VoLTE as a result of the verification, a VoLTE call may be made by sending a VoLTE call.

According to one embodiment, as described above, the process of checking the VoLTE capable information of the receiving terminal in the confirmation unit 110 of the terminal 100 receives the VoLTE capable information of the receiving terminal from the server storing the state information of the terminal. Can be confirmed.

Since the terminal 100 can serve as both a receiving terminal and a calling terminal, a server storing status information of the terminal may be storing both status information of the calling terminal as well as the receiving terminal. In the following, it may be understood in this form even if there is no specific mention.

In addition, the verification unit 110 may check the VoLTE-capable information of the receiving terminal when the terminal receives an input for requesting a call from the user from the user. For example, since the receiving terminal is specified only after the user inputs the number of the receiving terminal and presses the call button, in this case, the confirmation unit can check the VoLTE-capable information of the receiving terminal.

As described above, when an input for requesting a call to the receiving terminal is received from the user, a more efficient voice call can be performed by confirming the VoLTE-capable information of the receiving terminal before the terminal makes a call.

According to an embodiment, a server that stores status information of a terminal confirming VoLTE-capable information of a receiving terminal may include at least one of an MCMS server, a presentation server, or a registration server.

According to an embodiment, the MCMS server is a multimedia call message server that is currently being serviced, and may be an IMS (IP Multimedia Subsystem) service server for displaying videos, photos, and text on the reception screen of the opposite terminal. . When a request to transmit a multimedia call message is received, it is possible to obtain subscription information by confirming whether the opposite terminal is a VoLTE subscriber to the presentation server.

The presentation server may be a server that stores subscriber information. It may be a server that delivers the confirmation result when checking whether the user is a VoLTE subscriber.

The registration server may be a server that registers whether a VoLTE-type call is possible when a user is a VoLTE subscriber and is actually connected to an LTE or IMS network. When LTE network sharing is performed between communication providers, it is possible to check whether a VoLTE-type call is possible.

The server may store the state information of the calling terminal and the receiving terminal, and upon receiving a message confirming whether VoLTE of the receiving terminal is possible from the terminal 100, the server may transmit the information to the terminal 100.

According to an embodiment, the terminal 100 may receive VoLTE-capable information of the receiving terminal from the server in real time through an IP Multimedia Subsystem (IMS) message. The detailed process of confirming VoLTE-capable information of the receiving terminal will be described later in FIG. 5.

According to an embodiment, the call generation unit 120 may check whether the receiving terminal VoLTE is available from the server storing the status information of the terminal, and then may transmit a VoLTE call or CS call according to the result. have.

If the receiving terminal supports VoLTE, a VoLTE call can be sent to connect a VoLTE call, and if the receiving terminal does not support VoLTE, a CS call can be sent to prevent unnecessary data conversion by sending a VoLTE call.

Hereinafter, a method for transmitting a call according to an existing VoLTE-capable terminal and a method for transmitting a call according to whether a VoLTE is possible for a receiving terminal according to an embodiment will be described below.

FIG. 2 is a flow diagram 200 of a voice transmission when a conventional calling terminal can make a VoLTE call and a receiving terminal cannot make a VoLTE call.

Conventionally, when the originating terminal 210 is a terminal supporting VoLTE, the receiving terminal 220 always transmits a VoLTE call regardless of whether it supports VoLTE. In this case, since the receiving terminal 220 cannot receive an HD voice packet, it is necessary to convert the voice data into CS packets so that the receiving terminal 220 can receive it.

The calling terminal 210 transmits the HD voice packet used in the VoLTE call to the IMS server 230 serving as a relay during the VoLTE call. Thereafter, as described above, since the receiving terminal 220 cannot receive the HD voice packet, the receiving terminal 220 undergoes a process of converting voice data into a CS packet that can be received.

This process is performed by a data conversion server 240, and the data conversion server 240 decodes HD voice and relays voice data encoded with CS voice as a relay in CS call (250) ).

The CS server 250 transmits the voice data encoded in the CS voice received from the data conversion server 240 to the receiving terminal 220. As described above, the originating terminal 210 has transmitted the HD voice packet, but the receiving terminal 220 receives the CS voice through the decoding and encoding process of the voice data.

Even when the receiving terminal 220 transmits a voice, a data conversion process is performed as described above. However, in this case, even if the CS voice is decoded through the data conversion server 240 and encoded as an HD voice, the CS voice data is not converted to an HD quality voice, but the calling terminal 210 is still used as the CS voice. Will receive.

In conclusion, although the calling terminal 210 is capable of VoLTE calls and is transmitting HD voice, when the receiving terminal 220 does not support VoLTE calls, it results in CS-quality calls and performs unnecessary data conversion process. There is a problem to be done.

Therefore, hereinafter, in order not to perform the unnecessary data conversion process as described above, a method for transmitting a call according to an embodiment will be described later.

3 is a flowchart 300 of a calling method when a VoLTE call is possible by a receiving terminal according to an embodiment.

In order not to perform unnecessary data conversion process that occurs during the existing VoLTE call, it is necessary to check whether the receiving terminal supports VoLTE when the VoLTE-capable terminal makes a voice call.

According to an embodiment, when the calling terminal 310 supporting VoLTE inputs the number of the counterpart receiving terminal 330 and presses the call button, the receiving terminal 330 from the server 340 storing the status information of the terminal. You can check whether VoLTE is supported.

According to an embodiment, the originating terminal 310 may check whether the VoLTE is supported by the receiving terminal through an IMS message to the server 340 storing the status information of the terminal. As a result of the check, if the receiving terminal 330 is identified as a VoLTE capable terminal, the calling terminal 310 can send a VoLTE call, and the calling display screen 320 of the calling terminal 310 is displayed as shown in FIG. 3. Can be.

Since the receiving terminal 330 has confirmed that the VoLTE call is possible through the above confirmation process, the calling terminal 310 can transmit a VoTLE call to transmit the HD voice packet to the IMS server 350 serving as a relay during the VoLTE call. have.

In addition, since the receiving terminal 330 is capable of VoLTE calls, the IMS server 350 can directly transmit HD voice packets to the receiving terminal 330 without going through a separate data conversion process.

The process of the receiving terminal 330 transmitting the HD voice packet to the calling terminal 310 may also transmit the voice data as the HD voice packet to the calling terminal even though the same data conversion process is not performed.

The process illustrated in FIG. 3 may be applied in the same manner when the receiving terminal supports VoLTE calls even in the conventional method. Accordingly, although a separate process for checking whether the receiving terminal supports VoLTE may be considered to be added, when the receiving terminal does not support VoLTE, an unnecessary data conversion process may not be performed unlike the conventional method.

Hereinafter, a method of transmitting a call by a terminal supporting VoLTE when the receiving terminal does not support VoLTE will be described later.

4 is a flowchart 400 of a calling method when a VoLTE call is possible by a receiving terminal according to an embodiment.

According to an embodiment, when the calling terminal 410 supporting VoLTE transmits a voice call, it is possible to check whether the receiving terminal 430 supports VoLTE from the server 440 storing the state information of the terminal.

According to an embodiment, the calling terminal 410 may check whether the receiving terminal supports VoLTE through an IMS message to the server 440 storing the terminal status information. As a result of the check, if the receiving terminal 430 is identified as a terminal that is not capable of VoLTE calls, the calling terminal can make a CS call, and the calling display screen 420 of the calling terminal 410 is displayed as shown in FIG. 4. Can be.

Since the receiving terminal 430 has confirmed that the VoLTE call is not possible through the verification process, the calling terminal 410 sends a CS call to the CS server 450 that serves as a relay for CS voice packets during CS calls. Can transmit.

Although the receiving terminal 430 does not support the VoLTE call, since the calling terminal 410 supporting the VoLTE call sends a CS call to the receiving terminal, the CS server 450 receives it even if it does not perform a separate data conversion process. The terminal 430 may receive voice data.

As described above, when the receiving terminal 430 does not support the VoLTE call, the calling terminal 410 may make the CS call, not the VoLTE call, to perform a call connection between terminals without performing unnecessary data conversion process.

The process in which the receiving terminal 430 transmits the CS voice packet to the calling terminal may also be performed in the same manner. The calling terminal can receive the HD voice packet, but even if the CS voice packet is converted to the HD voice packet, the CS quality voice is not converted to the HD quality voice. Therefore, a process of converting a CS voice packet to an HD voice packet through a separate data conversion process may be unnecessary.

As described above, unlike the conventional call originating method, it is unnecessary for the calling terminal 410 to check whether the receiving terminal 430 supports the VoLTE call through the server 440 that stores the state information of the terminal when the call is made. It may be effective in that it may not perform the data conversion process.

As described in FIG. 3, when the receiving terminal 330 supports VoLTE calls, it may be considered that a process of checking whether the receiving terminal supports VoLTE calls is unnecessary. However, in the case that the receiving terminal 430 does not support VoLTE calls, a process of checking whether the receiving terminal supports VoLTE calls from the server is necessary when the calling terminal makes a call, since unnecessary data conversion process may not be performed. Do.

3 and 4 have been described with respect to a method for transmitting a call according to whether a VoLTE call is supported by a receiving terminal of a terminal supporting VoLTE call according to an embodiment. Hereinafter, a specific method of confirming whether or not the receiving terminal supports VoLTE call through a message from a server storing status information of the terminal through a message will be described later.

5 is a flowchart 500 illustrating a method for checking whether VoLTE is possible between a terminal and a server according to an embodiment.

According to an embodiment, the terminal 510 supporting the VoLTE call may check whether the VoLTE call is supported by the receiving terminal from the server 520 storing the state information of the terminal. In addition, the terminal 510 may check whether the VoLTE call of the receiving terminal is supported from the server 520 through a message.

According to an embodiment, the first message requesting VoLTE capable information of the receiving terminal and the second message including VoLTE capable information of the receiving terminal may be at least part of the IMS message. In addition, the first message and the second message may follow the RCS-e standard of the IMS standard specification. Table 1 shows the RCS service specifications.

Support service name Parameter version SVLTE video phone LTE_VT1.0 Supported versions of each service specification SVLTE video chat support LTE_VT1.1 VoLTE Video Phone LTE_VT2.0 VoLTE video chat support LTE_VT2.1 LTE AT (VoIP) LTE_AT1.0 LTE MSG LTE_MSG1.0 Pure text message with no file attached LTE MMS LTE_MMS1.0 MMS with file attached RCS-e RCS-e1.2 RCS-e service specification support

According to an embodiment, the terminal 510 may request 530 call message information including VoLTE-capable information of the receiving terminal from the server 520 that stores the terminal's status information. For example, the terminal 510 may transmit a first message requesting VoLTE capable information of the receiving terminal to the server 520.

According to one embodiment, the first message may use the call message information request to check VoLTE-capable information of the receiving terminal. The request URL may be in the form of "https://[MCMS server domain]/CallMessage/getCallMessage.call", and the request method may be a POST method. In addition, the first message can be requested by including the information shown in Table 2.

number Parameter name division Explanation Remarks (example) One user_ctn M User (outgoing) CTN 01044445555 2 user_device_id M Device ID of the terminal ffffffff-d7d2-454a-0000-00002xxxx 3 user_device_type M Terminal OS Type A: Android 4 receive_user_ctn M Other party (incoming) CTN 01055554444

According to an embodiment, an example of the first message may be as follows.

"POST http://[MCMS server domain]/CallMessage/getCallMessage.call HTTP/1.1

Host: xxx.xxx.xxx.xxx:8080

Content-Length: 112

Connection: Keep-Alive

user_ctn=01044445555&user_device_type=A&user_device_id=ffffffff-d7d2-454a-0000-000026c3c239&receive_user_ctn=01055554444"

The first message message as described above is only an example, and may vary depending on a manufacturer of a terminal, a terminal type, a communication method, a communication standard, or a machine language used, but is not limited thereto.

According to an embodiment, when the server 520 storing the state information of the terminal receives the request 530 of the call message information, the result of the call message information 540 may be transmitted to the terminal 510 in response. . For example, when a first message confirming whether a receiving terminal is capable of VoLTE is received, a second message including VoLTE capable information of the receiving terminal may be transmitted to the terminal.

According to one embodiment, the second message may include basic information and call message content information. The content information may include multimedia content information and message content information. The second message may be delivered to the terminal including information shown in Table 3.

number Parameter name division Description Remarks (example) One result M -Result Code 0000: normal processing
0006: VoLTE (IMS not supported) 2 service_type M Service classification
-Preset type: CNAP3
-Real-time type: CNAP4 CNAP3 3 service_seq M -Service setting seq 100000000011 (12 digit number) 4 content_type O -Multimedia content type Image (P), Movie (M) 5 content_url O -URL of multimedia content http://[Cache server domain]/CallMessage/contents/1000000001.mp4 6 content_msg O -Contents of message content Be happy. 7 ErrMsg M -Provides detailed error information when it is not processed normally Message
-"" during normal processing

According to an embodiment, the terminal 510 may check whether the VoLTE of the receiving terminal is possible by viewing a result code of the “result” parameter of the second message. If the result code is "0000", the receiving terminal can be determined to be a VoLTE capable terminal, and if the result code is "0006", the receiving terminal can be determined to be a terminal that is not VoLTE capable.

According to an embodiment, an example of the full text of the second message may be as follows.

"HTTP/1.1 200 OK

Server: Apache-Coyote/1.1

Content-Type: text/html;charset=UTF-8

Content-Length: 330

Date: Tue, 15 Jan 2013 05:49:08 GMT

{"result":"0000","service_type":"R", "content_type":"M", "content_url":" http://[Cache server domain]/CallMessage/contents/1000000001.mp4", " content_msg":"Happy", "service_seq":"100000000001", "ErrMsg":""}"

The second message message as described above is only an example, and may vary according to a manufacturer of a terminal, a terminal type, a communication method, a communication standard, or a machine language used, but is not limited thereto.

According to an embodiment, the result code may be shown in Table 4. The terminal may determine that the receiving terminal is a VoLTE capable terminal only when the result code is "0000". When the values of the remaining result codes are "0001" to "0006", the receiving terminal may determine that the terminal is not capable of VoLTE. This is because when the terminal 510 transmits the VoLTE call when the receiving terminal cannot reliably determine whether VoLTE is possible, it is possible to perform an unnecessary data conversion process as in the conventional transmission method.

number value Explanation One 0000 Normal treatment 2 0001 No required parameters 3 0002 System error 4 0003 DB error 5 0004 Other errors 6 0005 Content storage error (NAS error) 7 0006 VoLTE (IMS) not supported

As described above, even if the content of the result code indicates at least one of no required parameters, system error, DB error, other error, and content storage error, the terminal 510 determines that the receiving terminal is not capable of VoLTE and calls CS to the receiving terminal. Can send

In addition, the terminal 510 transmits a first message to the server 520 storing the state storage information of the terminal to determine whether the receiving terminal is VoLTE capable, and then receives the VoLTE capable information of the receiving terminal from the server 520. A CS call can be sent even if the containing second message is not received. This is because, even in this case, since the receiving terminal cannot determine whether VoLTE is possible, when the terminal 510 transmits a VoLTE call, unnecessary data conversion process may be performed as in the conventional transmission method.

The method of checking the VoLTE-capable information of the receiving terminal through the message of the IMS standard is only one embodiment, and another method of checking the VoLTE-capable information of the receiving terminal through a server storing status information of the terminal may also be applied. Is obvious to a person skilled in the art and is not limited thereto.

6 is a flowchart illustrating an origination method according to an embodiment.

When the terminal transmits, it is possible to check VoLTE-capable information of the receiving terminal. According to an embodiment of the present invention, when a user makes a call, VoLTE-capable information of a receiving terminal may be checked in a server storing state information of the terminal (S610 ). In this step, the terminal and the server can confirm VoLTE-capable information of the receiving terminal through a message. A specific process of confirming VoLTE-capable information of the receiving terminal is described in detail in FIG. 5.

As a result of checking the information, the receiving terminal may determine whether VoLTE is possible (S620). This is because it is necessary to determine whether to send a VoLTE call or a CS call to the receiving terminal in order not to perform unnecessary data conversion process depending on whether the receiving terminal is capable of VoLTE.

If the receiving terminal is capable of VoLTE, the terminal may send a VoLTE call (S630). In this case, the terminal sends a VoTLE call and transmits the HD voice packet to the IMS server serving as a relay in the VoLTE call, and the IMS server can transmit the HD voice packet to the receiving terminal. The detailed process for this is described in detail in FIG. 3.

If the receiving terminal is not VoLTE capable, the terminal may send a CS call (S640). In this case, the terminal sends a CS call to transmit the CS voice packet to the CS server acting as a relay in the CS call, and the CS server can transmit the CS voice packet to the receiving terminal. The detailed process for this is described in detail in FIG. 4.

As described above, by checking whether VoLTE of the receiving terminal is possible through the server storing the state information of the terminal in advance at the time of outgoing before the call connection, unlike the existing calling method, unnecessary data conversion process may not be performed. .

The device described above may be implemented with hardware components, software components, and/or combinations of hardware components and software components. For example, the devices and components described in the embodiments include, for example, processors, controllers, arithmetic logic units (ALUs), digital signal processors (micro signal processors), microcomputers, field programmable arrays (FPAs), It may be implemented using one or more general purpose computers or special purpose computers, such as a programmable logic unit (PLU), microprocessor, or any other device capable of executing and responding to instructions. The processing device may run an operating system (OS) and one or more software applications running on the operating system. In addition, the processing device may access, store, manipulate, process, and generate data in response to the execution of the software. For convenience of understanding, a processing device may be described as one being used, but a person having ordinary skill in the art, the processing device may include a plurality of processing elements and/or a plurality of types of processing elements. It can be seen that may include. For example, the processing device may include a plurality of processors or a processor and a controller. In addition, other processing configurations, such as parallel processors, are possible.

The software may include a computer program, code, instruction, or a combination of one or more of these, and configure the processing device to operate as desired, or process independently or collectively You can command the device. Software and/or data may be interpreted by a processing device, or to provide instructions or data to a processing device, of any type of machine, component, physical device, virtual equipment, computer storage medium or device. , Or may be permanently or temporarily embodied in the transmitted signal wave. The software may be distributed over networked computer systems, and stored or executed in a distributed manner. Software and data may be stored in one or more computer-readable recording media.

The method according to the embodiment may be implemented in the form of program instructions that can be executed through various computer means and recorded on a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, or the like alone or in combination. The program instructions recorded on the medium may be specially designed and configured for the embodiments or may be known and usable by those skilled in computer software. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes, optical media such as CD-ROMs, DVDs, and magnetic media such as floptical disks. Includes hardware devices specifically configured to store and execute program instructions such as magneto-optical media, and ROM, RAM, flash memory, and the like. Examples of program instructions include high-level language code that can be executed by a computer using an interpreter, etc., as well as machine language codes produced by a compiler. The hardware device described above may be configured to operate as one or more software modules to perform the operations of the embodiments, and vice versa.

As described above, although the embodiments have been described by a limited embodiment and drawings, those skilled in the art can make various modifications and variations from the above description. For example, the described techniques are performed in a different order than the described method, and/or the components of the described system, structure, device, circuit, etc. are combined or combined in a different form from the described method, or other components Alternatively, even if substituted or substituted by equivalents, appropriate results can be achieved.

Therefore, other implementations, other embodiments, and equivalents to the claims are also within the scope of the following claims.

Claims (22)

In the terminal supporting VoLTE call,
A confirmation unit for confirming VoLTE-capable information of the receiving terminal; And
When the receiving terminal VoLTE call is impossible, including a call generation unit for sending a CS call,
The confirmation part
A server that stores status information of the receiving terminal, including any one of an MCMS server, a presentation server, or a registration server, transmits a first message requesting VoLTE capable information of the receiving terminal, and receives the message from the server A terminal that receives a second message including VoLTE capable information of the terminal and checks VoLTE capable information of the receiving terminal. delete delete According to claim 1,
The checking unit checks VoLTE-capable information of the receiving terminal before sending a VoLTE call to the receiving terminal. delete delete delete delete delete delete delete delete In the method of making a call of a terminal supporting VoLTE call,
Confirming the voLTE-capable information of the receiving terminal by the checking unit of the terminal; And
When the VoLTE call is not possible for the receiving terminal, a step of transmitting a CS call to the call generation unit of the terminal,
The step of confirming the VoLTE-capable information of the receiving terminal by the confirmation unit of the terminal,
A server that stores status information of the receiving terminal, including any one of an MCMS server, a presentation server, or a registration server, transmits a first message requesting VoLTE capable information of the receiving terminal, and receives the message from the server A method of receiving a second message including VoLTE capable information of a terminal and checking VoLTE capable information of the receiving terminal. delete delete delete delete delete delete delete delete delete

Images