Method for predicting call quality and call quality prediction service apparatus

Abstract

This invention provides a method for predicting call quality and a call quality prediction service apparatus. The method predicts the call quality between a first network communication device and a second network communication device. The method includes: when at least one of the following devices exists between the first and second network communication devices: a device for performing NAT traversal, a device for performing media transcoding, and a device for performing topology hiding; dividing the overall interval between the first and second network communication devices into independent intervals defined by the at least one device; and sequentially performing the call quality prediction for each independent interval by independently executing a transmission test, thereby completing the call quality prediction step between the first and second network communication devices.

Description

[0001] This application is a divisional application of the invention patent application filed on January 24, 2017, with application number 201780008163.6 (international application number PCT / KR2017 / 000839) and entitled "Method for predicting call quality and call quality prediction service device for implementing the above method". Technical Field

[0002] This invention relates to a technique for predicting call quality, and more particularly to a method for predicting call quality between network communication devices constituting a VoIP network, including VoIP terminals, without requiring an actual call generation process, by utilizing transmission tests of SIP transaction requests and SIP transaction responses, and a call quality prediction service device for implementing the above method. Background Technology

[0003] Recently, old-fashioned analog and digital circuit-switching telephones based on SS7 (Signaling System 7) have continued to decline, while packet-switching telephones based on IP (Internet Protocol) networks, including SIP, have expanded.

[0004] Existing VoIP technology, which uses the SIP protocol, may experience reduced call quality compared to line-switched telephony, which has a physically guaranteed bandwidth. This is due to terminal overload or system and network congestion at intermediate nodes such as L2, L3, and L4 switches in the packet-switched network.

[0005] Korean Patent Registration No. 10-1011344 discloses a call quality measurement and introduction system for a telephone call service network. It discloses a technology that measures the call quality of new users at the call center and provides a voice introduction based on the request of the telephone caller. By shortening the call waiting time with the call center consultant, it can improve customer satisfaction, reduce the number of consultation calls for consultants, thereby saving costs and improving the operational efficiency of the call center consultants.

[0006] To overcome the above problems, one embodiment of the present invention provides a technique for providing a call quality prediction index of multiple VoIP called terminals to a VoIP calling terminal when the VoIP service consists of multiple VoIP called terminals, thereby enabling the selection of a specific VoIP called terminal with good call quality. Summary of the Invention

[0007] Technical issues

[0008] An embodiment of the present invention provides a method for predicting call quality before an actual call is made, thereby providing an opportunity to seek other solutions when the expected call quality drops below a certain benchmark value, and a call quality prediction service apparatus for implementing the above method.

[0009] An embodiment of the present invention provides a method for predicting call quality in VoIP terminal call quality prediction by interval along the expected path of the media during a call and managing it through a high-speed buffer memory within a specified end time, thereby avoiding unnecessary prediction work on almost simultaneously repeated intervals. The invention also provides a call quality prediction service device for implementing the above method.

[0010] An embodiment of the present invention provides a method for predicting call quality when there are intermediate nodes performing media relay in an environment identical to the actual call process, predicting call quality in intervals and storing the structure in a high-speed cache memory, so as to prevent the transmission test for call quality prediction from being repeated when intervals overlap in other call quality prediction processes, thereby enabling the effective operation of network prediction work, and a call quality prediction service device for implementing the above method.

[0011] An embodiment of the present invention provides a method for predicting call quality in a segmented manner when there are intermediate nodes performing media relay in an environment identical to the actual call process, and stores the structure in a high-speed cache memory to prevent the transmission test for call quality prediction from being repeated when segments overlap in other call quality prediction processes, thereby enabling the effective operation of the network. The present invention also provides a call quality prediction service device for implementing the above method.

[0012] An embodiment of the present invention provides a method for predicting call quality by generating RTP / RTCP media traffic or spoofed UDP traffic, regardless of whether the actual media used for the call is included, between a VoIP terminal and a VoIP server or between terminals with actual call connections, according to the media transmission interval, calculating the RTT (Round Trip Time) and packet loss rate of each packet, and checking the integrity of the original data to address the possibility of packet corruption when wireless intervals exist, as well as a call quality prediction service device that implements the above method.

[0013] An embodiment of the present invention provides a method for predicting call quality by utilizing the SIP Event notification system in the presence information of a network user, or by providing call quality status through a SIP AS linked with an HTTP server, and a call quality prediction service device for implementing the above method.

[0014] Problem-solving methods

[0015] In an embodiment, a method for predicting the call quality of the other party is performed by one of the first and second network communication devices, comprising: (a) optionally including address information (IP address, Port number) of the other party for predicting the call quality of the other party, and transmitting a SIP (Session Initiation Protocol) transaction request containing a call quality prediction request to the other party; (b) receiving a SIP transaction response containing the address information (IP address, Port number) of the other party from the other party in response to the SIP transaction request; (c) performing a transmission test with the other party to predict the call quality using the address information of the other party and the address information of the other party, by utilizing 1) RTP packets regardless of the inclusion of actual media; 2) RTCP packets; or 3) masquerading UDP packets disguised as RTP (hereinafter referred to as "transmission test packets") of the other party; and (d) or after step (a), the other party first performs step (c) using the address of the other party to obtain the call quality prediction result, and then transmits the result to the other party in the SIP transaction response.

[0016] In one embodiment, step (c) above may include, when one party and the other party are connected through a NAT device, pre-generating a NAT pinhole for the address information by utilizing the address information between the two parties via communication between the two parties through the NAT device.

[0017] In one embodiment, step (c) above may include sequentially sending N (N is a natural number greater than 2) of the transmission test packets to one or the other party, and confirming their respective RTT (Round Trip Time) and whether or not they are lost to predict the call quality.

[0018] In one embodiment, the method for predicting call quality may further include (e) storing the predicted call quality based on the packet loss rate and transmission delay time prediction of the above-mentioned N transmission test packets, in order to determine the call selection of the above-mentioned counterparty.

[0019] In one embodiment, step (e) above may include, when the other party consists of multiple VoIP terminals, selecting a specific VoIP terminal for the call based on the predicted call quality of each of the multiple VoIP terminals.

[0020] In one embodiment, step (e) above may further include selecting a VoIP terminal that is currently available and has the least transmission time delay as the VoIP terminal when the communication between the aforementioned party and the aforementioned other party is voice communication.

[0021] In one embodiment, step (e) above may further include selecting a VoIP terminal that is currently available and has the lowest packet loss rate when the communication between the aforementioned party and the aforementioned counterpart is data communication.

[0022] In one embodiment, the method may further include (e) when at least one media relay device performing media relay exists among the relay devices between the first and second network communication devices, the method shall sequentially complete the call quality prediction steps by performing steps (a) to (d) or performing step (c) alone for the relay interval formed between adjacent call quality prediction devices in the first and second network communication devices and the at least one media relay device (hereinafter referred to as "call quality prediction device").

[0023] In one embodiment, step (e) above may include storing a call quality prediction for the aforementioned relay interval in a cache memory and updating the cache memory after a certain period of time.

[0024] In one embodiment, step (e) above may further include receiving a SIP transaction response containing information about the call quality prediction device related to the cause of the failure when call quality prediction for a particular trunk interval fails.

[0025] In an embodiment, a method for predicting call quality for multiple VoIP terminals, executed in a VoIP server or SBC without a call generation process, includes: (a) performing a transmission test with each of the multiple VoIP terminals to predict call quality for the interval between the VoIP server or SBC and the VoIP terminals by utilizing 1) RTP packets independent of the inclusion of actual media; 2) RTCP packets; or 3) communication of spoofed UDP packets disguised as RTP (hereinafter referred to as "transmission test packets") between the other party; and (b) providing the predicted call quality to the other party based on the predicted call quality, or performing a step of providing information on the usable VoIP terminal with the best call quality or performing a connection attempt.

[0026] In an embodiment, a call quality prediction service apparatus that executes a method for predicting the call quality of the other party by executing one of the first and second network communication devices includes: a SIP transaction request unit that optionally includes address information (IP address, port number) of the other party for call quality prediction of the other party, and transmits a SIP (Session Initiation Protocol) transaction request containing a call quality prediction request to the other party; and a SIP transaction response receiving unit that receives a SIP transaction response containing the address information (IP address, port number) of the other party from the other party in response to the SIP transaction request.

[0027] The call quality prediction unit performs a transmission test with the other party using the address information of the aforementioned party and the address information of the other party, by using 1) RTP packets regardless of whether the actual media is included; 2) RTCP packets; or 3) dummy UDP packets disguised as RTP (hereinafter referred to as "transmission test packets") to predict the call quality; the SIP transaction response transmission unit, after transmitting the aforementioned SIP transaction to the other party, after the other party uses the address of the aforementioned party to first perform the call quality prediction to obtain the call quality prediction result, transmits the result in the aforementioned SIP transaction response to the aforementioned party; and the call selection decision unit stores the predicted call quality based on the packet loss rate and transmission delay time prediction of the aforementioned N transmission test packets, and decides the call selection for the aforementioned other party.

[0028] Invention Effects

[0029] The disclosed technology has the following effects. However, this does not mean that a particular embodiment needs to include all or only the following effects; therefore, the scope of the disclosed technology is not limited thereto.

[0030] An embodiment of the present invention provides a method for predicting call quality and a call quality prediction service apparatus for implementing the method. Before an actual call is made, the method predicts the call quality in advance, thereby providing an opportunity to seek alternative solutions when the expected call quality drops below a certain benchmark value.

[0031] An embodiment of the present invention provides a method for predicting call quality and a call quality prediction service device for implementing the above method. During a call, the method predicts call quality by interval along the expected path of the media and manages this prediction within a specified end time using a high-speed buffer memory. This avoids unnecessary prediction operations for almost simultaneously repeating intervals in VoIP terminal call quality prediction.

[0032] An embodiment of the present invention provides a method for predicting call quality and a call quality prediction service apparatus for implementing the above method. When there is an intermediate node for media relay in an environment identical to the actual call process, the method predicts call quality in intervals and stores the structure in a high-speed cache memory. This prevents the transmission test for call quality prediction from being repeated when intervals overlap in other call quality prediction processes, thereby effectively operating the prediction operation of the network.

[0033] An embodiment of the present invention provides a method for predicting call quality and a call quality prediction service apparatus for implementing the above method. When there is an intermediate node performing media relay in an environment identical to the actual call process, the method predicts call quality in intervals and stores the structure in a high-speed cache memory. This prevents the transmission test for call quality prediction from being repeated when intervals overlap in other call quality prediction processes, thereby effectively operating the network's predicted call quality.

[0034] An embodiment of the present invention provides a method for predicting call quality and a call quality prediction service device for implementing the above method. After generating RTP / RTCP media traffic or spoofed UDP traffic according to the media transmission interval between the VoIP terminal and the VoIP server or between the terminals of the actual call connection, regardless of whether the actual media used for the call is included, the RTT (Round Trip Time) and packet loss rate of each packet are calculated. In the presence of wireless intervals, the integrity of the original data is checked to deal with the possibility of packet corruption.

[0035] A method for predicting call quality and a call quality prediction service device for implementing the above method according to an embodiment of the present invention may be included in the presence information of the user using the SIP Event notification system, or the call quality status may be provided through a SIP AS linked with an HTTP server, etc. Attached Figure Description

[0036] Figure 1 A schematic diagram illustrating a call quality prediction system according to an embodiment of the present invention;

[0037] Figure 2 A schematic diagram illustrating the structure of the call quality prediction service device;

[0038] Figure 3 A schematic diagram illustrating the process of generating a VoIP server request and using it for a transmission test session to predict call quality between a call quality prediction server and any VoIP terminal.

[0039] Figure 4 A schematic diagram illustrating the process of generating a VoIP server request and using it for predicting call quality between the VoIP server and any VoIP terminal;

[0040] Figure 5 A schematic diagram illustrating the process of generating a VoIP terminal request and using it for a transmission test session for call quality prediction between the call quality prediction server and any VoIP terminal.

[0041] Figure 6 A schematic diagram illustrating the process of generating a transmission test session for predicting call quality between a VoIP server and any VoIP terminal.

[0042] Figures 7 to 12 A schematic diagram illustrating the process of predicting call quality between any VoIP terminals;

[0043] Figure 13 A schematic diagram of a UDP packet for comparison with an embodiment of the present invention;

[0044] Figure 14 A diagram illustrating the relationship between a VoIP terminal and a VoIP server or SBC;

[0045] Figure 15 A sequence diagram illustrating the process of predicting the other party's call quality according to an embodiment of the present invention;

[0046] Figure 16 This is a sequence diagram illustrating the process of predicting call quality for multiple VoIP terminals without a call generation process, according to another embodiment of the present invention. Detailed Implementation

[0047] The disclosed technical content is merely an illustration of structural or functional embodiments; therefore, the scope of the disclosed technology should not be limited to the embodiments described herein. That is, embodiments can be modified in various ways and have various forms; therefore, the scope of the disclosed technology should include equivalents that realize the technical concept. Specific embodiments of the present invention do not necessarily need to include all the aforementioned objective effects or only the following effects; therefore, the scope of the disclosed technology is not limited in this way.

[0048] In addition, the terminology used in this invention should be understood as follows.

[0049] Terms such as "first" and "second" are used to distinguish one constituent element from another, but the scope of the claims is not limited by these terms. For example, a first constituent element may be named a second constituent element, and similarly, a second constituent element may be named a first constituent element.

[0050] When one structure is "connected" or "accessed" to another structure, it means that it is directly connected to or accessed by the other structure or is connected to or accessed through other structures. Conversely, when one structure is "directly connected" to another structure, it means that there are no other structures in between. Other descriptions of the relationship between structures, such as "between" and "right between," or "adjacent to" and "connected to," have the same meaning.

[0051] In the absence of a clear distinction in the context, a singular description may contain the meaning of a plural. Terms such as "including" or "possessing" indicate the presence of the features, numbers, steps, actions, structures, components, or combinations thereof described in the specification, rather than pre-excluding the presence or additional possibility of one or more other features, numbers, steps, actions, structures, components, or combinations thereof.

[0052] In each step, the identification symbols (e.g., a, b, c, etc.) are used for ease of explanation and do not indicate the order of the steps. Unless a specific order is explicitly stated in the context, the steps may be performed in a different order than the one stated. That is, the steps may be performed in the order stated, simultaneously, or in the reverse order.

[0053] This invention can be implemented on a computer-readable recording medium with computer-readable encoding, and the computer-readable recording medium includes all kinds of recording devices that store data that can be read by a computer system. Examples of computer-readable recording media include ROM, RAM, CD-ROM, magnetic disk, floppy disk, optical data storage devices, etc.

[0054] Unless otherwise specified, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. Terms that are generally used identically to those defined in dictionaries have the same meaning as in the context of the relevant art, and unless explicitly defined, do not have an ideal or excessive meaning in this application.

[0055] Figure 1 This is a schematic diagram illustrating a call quality prediction system according to an embodiment of the present invention.

[0056] like Figure 1 As shown, the call quality prediction system 10 includes a call quality prediction service device 20 and a call quality prediction server 300, and the call quality prediction service device 20 includes a VoIP terminal 100 and a VoIP server 200. These can be connected via a network.

[0057] The call quality prediction service device 20 is executed on either the VoIP terminal 100 or the VoIP server 200, and can predict the call quality of the other party. More specifically, the call quality prediction service device 20 can predict the call quality between the VoIP terminal 100 and the VoIP server 200, between the VoIP terminal 100 and the call quality prediction server 300, or between the VoIP terminal 100 and the VoIP server 200.

[0058] The VoIP terminal 100 may be owned by the user and may be a computing device connected to the VoIP server 200 and the call quality prediction server 300. For example, the VoIP terminal 100 may be implemented by a smartphone or the like, but is not limited thereto.

[0059] Any VoIP calling terminal or calling terminal 102, 106, 110, 114, 116, 120, or VoIP called terminal or called terminal 104, 108, 112, 118, 122, are considered VoIP terminals.

[0060] The call quality prediction server 300 is used to reduce the transmission test load from the VoIP server 200, which is capable of performing SIP call processing. Here, call processing refers to the process of controlling and monitoring all states from the inception to the termination of a call to ensure a normal conversation. Furthermore, the call quality prediction server 300 can be a regular server that is not directly related to the SIP network, can establish an IP (Internet Protocol) connection with the VoIP terminal 100, and exchanges information with the VoIP server 200 in conjunction with it.

[0061] First, the transmission test for predicting call quality in different relay intervals is explained.

[0062] Transmission tests for the call quality prediction interval can also be conducted using actual RTP / RTC packets containing playable media similar to a real call. Within a specific interval, both parties can predict call quality by simultaneously sending and receiving RTP / RCTP packets and calculating RTT (Round Trip Time) and packet loss using RTCP packets. The results are shared to calculate the prediction results for bidirectional call quality. Alternatively, a specific entity can generate RTP packets and transmit them to the other party within the interval. The other party receives and immediately retransmits the packets, and the corresponding entity calculates the RTT and packet loss for each RTP packet.

[0063] Call quality can also be predicted by using RTP packets that do not contain actual media but contain transmission time information from the transmission side, or even UDP packets with the same IP packet size and transmission interval as RTP packets but containing transmission time information from the transmission side, and by immediately obtaining retransmissions from the other party to calculate RTT and packet loss.

[0064] This can be divided into two scenarios: one where transmission tests are conducted simultaneously during the call quality prediction interval, and the other where one side initiates the transmission test packets. In the case where one side initiates the transmission test packets, neither side needs to know the other's address. If one side initiates the transmission, the receiving side will refer to the originating address of the IP packet and transmit in the reverse direction.

[0065] Therefore, since it is easy for both sides to conduct transmission tests simultaneously after obtaining the other party's address by having one side take the lead, the following explanation will mainly focus on the case where one side takes the lead.

[0066] Figure 2 A schematic diagram illustrating the structure of the call quality prediction service device.

[0067] like Figure 2 As shown, the call quality prediction service device 20 includes a SIP transaction request unit 21, a SIP transaction response receiving unit 22, a call quality prediction unit 23, a SIP transaction response transmission unit 24, a call selection decision unit 25, and a control unit 26.

[0068] SIP transaction request unit 21 may optionally include the address information (IP address, port number) of the aforementioned party used for call quality prediction, and transmit a SIP (Session Initiation Protocol) containing a call quality prediction request to the other party. For example, SIP transaction request unit 21 may transmit a SIP transaction request containing call quality prediction request information to VoIP terminal 100. As another example, SIP transaction request unit 21 may transmit a SIP transaction request containing call quality prediction request information to VoIP server 200.

[0069] In one embodiment, when there is a NAT device between the VoIP terminal 100 and multiple servers (VoIP server 200 or call quality prediction server 300), the SIP transaction request unit 21 can include the address information of the VoIP server 200 or call quality prediction server 300 in the SIP transaction request used to generate the transmission test session and transmit it to the VoIP terminal 100. The VoIP terminal 100 can then transmit NAP pinhole packets used to generate NAT pinholes to the VoIP server 200 or call quality prediction server 300 using the received address information of the VoIP server 200 or call quality prediction server 300.

[0070] The SIP transaction response receiving unit 22 can receive SIP transaction responses. More specifically, in response to a SIP transaction request, the SIP transaction response receiving unit 22 receives a SIP transaction response containing the address information (IP address, Port number) of the other party. In one embodiment, as a response to a SIP transaction request, the SIP transaction response receiving unit 22 can receive a SIP transaction response from the VoIP terminal 100. For example, as a response to a SIP transaction request, the SIP transaction response receiving unit 22 can receive address information containing Port information newly allocated for the transmission test.

[0071] The call quality prediction unit 23 uses the address information of one party and the address information of the other party to perform a transmission test with the other party by using 1) RTP packets that are independent of the inclusion of the actual media; 2) RTCP packets; or 3) dummy UDP packets disguised as RTP packets (hereinafter referred to as "transmission test packets") to predict the call quality.

[0072] When one party and the other party are connected through a NAT device, the call quality prediction unit 23 can pre-generate NAT pinholes for address information by utilizing the address information between the two parties through communication between the two parties via the NAT device.

[0073] For example, the VoIP server 200 or the call quality prediction server 300 can use the address of the VoIP terminal 100 obtained through the SIP transaction response receiving unit 22 to perform transmission tests on the VoIP terminal 100 and the call quality prediction object codec by generating RTP packets that do not contain actual RTP / RTCP or actual media or UDP packets disguised as RTP to predict call quality.

[0074] For example, the VoIP terminal 100 can use the address of the VoIP server 200 obtained through the SIP transaction response receiving unit 22 to perform transmission tests on the call quality prediction object codec using RTP packets that do not contain actual RTP / RTCP or actual media, or UDP packets disguised as RTP, to predict call quality.

[0075] When NAT traversal exists between VoIP terminal 100 and each server (VoIP server 200 or call quality prediction server 300), the SIP transaction request transmitted by VoIP server 200 to VoIP terminal 100 includes the address information of VoIP server 200 or call quality prediction server 300 used to generate a transmission test session. After VoIP terminal 100 transmits a packet for generating a NAT pinhole to the address of VoIP server 200 or call quality prediction server 300 obtained from the SIP transaction request, VoIP server 200 or call quality prediction server 300 can use the NAT pinhole to perform a transmission test on VoIP terminal 100 and the call quality prediction object codec by generating RTP packets that do not contain actual RTP / RTCP or UDP packets disguised as RTP to predict call quality.

[0076] At this time, before execution between VoIP terminal 100 and VoIP server 200 or between VoIP terminal 100 and call quality prediction server 300, SIP authentication of VoIP terminal 100 can be performed. If authentication fails, call quality prediction is abandoned, and if authentication succeeds, a transmission test is performed.

[0077] In one embodiment, the call quality prediction unit 23 can generate UDP packets disguised as RTP based on the address and port information of the VoIP terminal 100, and perform transmission tests using the generated UDP packets to predict the call quality to the VoIP terminal 100. Here, the multiple disguised UDP packets may contain data of the same size, transmission interval, and transmission time as RTP packets.

[0078] The call quality prediction unit 23 can send N (N is a natural number greater than 2) of the above transmission test packets to one party or the other party, and confirm their respective RTT (Round Trip Time) and whether there is any loss to predict the call quality.

[0079] The call quality prediction unit 23 can predict the other party's call quality by confirming the RTT (Round Trip Time) of each generated spoofed UDP packet and whether there is any round-trip loss. The call quality prediction unit 23 can calculate the RTT value based on the reception time of each spoofed UDP data and the transmission time recorded in the spoofed UDP data, and predict the other party's call quality by calculating the number of missing RTP data and the deviation (i.e., the deviation) of the RTT to the average and RTT value of all RT packets.

[0080] In one embodiment, the call quality prediction unit 23 can generate N sequentially spoofed UDP packets and transmit them to the VoIP terminal 100. Simultaneously, the VoIP terminal 100 receives the spoofed UDP packets and then retransmits them to the call quality prediction unit 23. The call quality prediction unit 23 confirms the RTT value and round-trip loss of each of the spoofed UDP packets during the retransmission process to predict the call quality of the other party, i.e., the VoIP terminal 100.

[0081] In addition, when the call quality prediction unit 23 is executed in the VoIP server 200 or SBC and predicts the call quality for multiple VoIP terminals without the need for a call generation process, it can perform transmission tests with each of the VoIP server or SBC and the VoIP terminals on the interval between them by using 1) RTP packets that are independent of the inclusion of the actual media; 2) RTCP packets; or 3) dummy UDP packets disguised as RTP packets (hereinafter referred to as "transmission test packets") to predict the call quality.

[0082] After the execution of the SIP transaction response transmission unit 24 or the execution of the SIP transaction request unit 21 (i.e., step (a)), the other party first executes the call quality prediction unit (i.e., step (c)) using the address of one party to obtain the call quality prediction result, and then transmits the result to one party in the SIP transaction response.

[0083] The call selection decision unit can save the predicted call quality based on the packet loss rate and transmission delay time prediction of N transmission test packets, in order to decide on the call selection of the other party.

[0084] When the other party consists of multiple VoIP terminals 100, the call selection decision unit 25 selects a specific VoIP terminal to conduct the call based on the predicted call quality of each of the multiple VoIP terminals.

[0085] In one embodiment, when the communication between one party and the other party is voice communication, the call selection decision unit 25 selects a VoIP terminal that is currently available and has the least transmission time delay as the VoIP terminal. In another embodiment, when the communication between one party and the other party is data communication, the call selection decision unit 25 selects a VoIP terminal that is currently available and has the least packet loss rate as the VoIP terminal.

[0086] When at least one media relay device performing media relay exists in the relay device between the first and second network communication devices, the call selection decision unit 25 performs the above-mentioned call quality prediction steps sequentially by executing a SIP transaction request to a SIP transaction response or by performing call quality prediction alone in the relay interval formed between adjacent call quality prediction devices in the first and second network communication devices and the at least one media relay device (hereinafter referred to as "call quality prediction device").

[0087] For example, the first network communication device (or calling terminal) is automatically set as the boundary of the last call quality prediction interval, and the SIP transaction request transmitted to its own VoIP server 200 includes the call quality prediction request information of the second network communication device (or the called terminal of the call quality prediction object).

[0088] Second, during the process of transmitting the SIP transaction request to the second network communication device, if the SIP network component does not perform media relay, it will transmit the SIP transaction request to the next destination as is. If it performs media relay, it will transmit the SIP transaction request containing information that sets its own address as the last call quality prediction interval boundary to the next destination while performing the transmission test for call quality prediction contained in the SIP transaction request. Alternatively, after performing the transmission test for call quality prediction, it will transmit the SIP transaction request containing the call quality prediction result and information that sets its own address as the last call quality prediction interval boundary to the next destination.

[0089] Third, if the SIP transaction request reaches the called-side VoIP server, and the called-side VoIP server performs media relay, it may, after executing the final call quality prediction interval boundary and the transmission test for call quality prediction contained in the SIP transaction request, and after also executing the transmission test for call quality prediction between the called-side VoIP server and the second network communication device, transmit a SIP transaction response containing the two prediction results to the first network communication device; or, while executing the final call quality prediction interval boundary and the transmission test for call quality prediction contained in the SIP transaction request, transmit a SIP transaction request containing information that sets its own address as the final call quality prediction interval boundary to the second network communication device; or, after executing the final call quality prediction interval boundary and the transmission test for call quality prediction contained in the SIP transaction request, transmit a SIP transaction request containing the call quality prediction result and information that sets its own address as the final call quality prediction interval boundary to the second network communication device.

[0090] Fourth, the second network communication device is automatically set as the call quality prediction interval boundary, and when a SIP transaction request arrives at the second network communication device, after executing the last call quality prediction interval boundary recorded in the SIP transaction request and the transmission test used to predict call quality, the SIP transaction response containing the result is transmitted to the first network communication device, and when the SIP network component serving as the call quality prediction interval boundary does not include the call quality prediction result in the SIP transaction request, it may include it in the SIP transaction response.

[0091] The call selection decision unit 25 can store call quality predictions for the trunk interval in a cache and update the cache after a certain time. For example, SIP network components that serve as the boundaries of the call quality prediction interval can refer to their own call quality prediction results or SIP transaction responses and store their own and other SIP network components that serve as the boundaries of the call quality prediction interval in the cache for management, so as to avoid repeated transmission tests when there are repeated call quality prediction requests within the cache's expiration time.

[0092] When call quality prediction for a specific trunk segment fails, the call selection decision unit 25 receives a SIP transaction response containing information about the call quality prediction device related to the cause of the failure. For example, if, during the transmission of a SIP transaction request to the second network communication device, the SIP network component is unable to continue call quality prediction due to policy or technical reasons, the call selection decision unit 25 may, if necessary, include the call quality prediction results for different segments to date in the SIP transaction response, along with information about the location where it was set as the failure point for call quality prediction, or the cause of the failure, and transmit this information to the first network communication device.

[0093] In addition, the call selection decision unit 25, based on the prediction of the call quality of each party, provides the predicted call quality to the other party or provides information on the available VoIP terminal with the best call quality or performs a connection attempt.

[0094] For example, regarding the call quality between VoIP terminal 100 and VoIP server 200, VoIP server 200 uses the registration address of VoIP terminal 100 directly without a call generation process, or generates another transmission test session for call quality prediction. It predicts call quality by generating RTP packets that do not contain actual RTP / RTCP or actual media, or UDP packets disguised as RTP, and calculates packet loss rate and transmission delay value. After saving the information, it transmits the call quality prediction information of VoIP terminal 100 to the other party, so that the other party can refer to it before the actual call connection, or choose the VoIP terminal with good call quality when there are multiple VoIP terminals that can achieve the same purpose.

[0095] The control unit 26 can control the overall operation of the call quality prediction service device and can control the control flow or data flow between the SIP transaction request unit 21, the SIP transaction response receiving unit 22, the call quality prediction unit 23, the SIP transaction response transmission unit 24, and the call selection decision unit 25.

[0096] Figure 3 This diagram illustrates the process of generating a VoIP server request and using it for a transmission test session to predict call quality between a call quality prediction server and any VoIP terminal.

[0097] More specifically, Figure 3 Any VoIP terminal 100 can perform SIP registration (or SIP REGISTER) with VoIP server 200 to become a callable state, while VoIP server 200 can request call quality prediction server 300 and VoIP terminal 100 to generate a transmission test session for call quality prediction.

[0098] exist Figure 3 During process ①, the VoIP terminal 100 may request SIP registration from the VoIP server 200. More specifically, the VoIP terminal 100 may generate a SIP REGISTER message to request SIP registration and perform SIP registration through the generated SIP REGISTER message. At this time, the SIP registration of the VoIP terminal 100 is performed through a method such as a shared secret, where the shared secret includes the account (ID) and password.

[0099] VoIP terminal 100 can transmit an initial SIPREGISTER message without authentication information to VoIP server 200 to request SIP registration, while VoIP server 200 can transmit a 401 Unauthorized response containing authentication information to VoIP terminal 100. Here, authentication information may include authentication method, authentication algorithm, areas defining account (ID) and password, nonce value, etc.

[0100] The VoIP terminal 100 can confirm the authentication information in the 401 Unauthorized response received from the VoIP server 200 and calculate the message digest as required by the VoIP server 200. Here, the message digest is a bit string of fixed length that is reduced by repeatedly applying a one-way hash function to a message of arbitrary length.

[0101] VoIP terminal 100 can transmit a second SIP REGISTER message containing a calculated message digest to VoIP server 200. VoIP server 200 can calculate the message digest using the same method as VoIP terminal 100. After calculating the message digest, VoIP server 200 can compare its calculated message digest result with the message digest result contained in the second SIP REGISTER message.

[0102] In one embodiment, the VoIP server 200 terminates the SIP authentication of the VoIP terminal 100 when its calculated message digest result is the same as the message digest result contained in the second SIP REGISTER message. After terminating the SIP authentication of the VoIP terminal 100, the VoIP server 200 transmits a 200OK message to the VoIP terminal 100, successfully performing the SIP registration of the VoIP terminal 100 using the REGISTER message.

[0103] In another embodiment, if the message digest result calculated by the VoIP server 200 is different from the message digest result contained in the second SIP REGISTER message, the VoIP server 200 cannot terminate the SIP authentication of the VoIP terminal 100, and the SIP authentication of the VoIP terminal 100 fails. At this time, the VoIP server 200 may transmit an error response such as 403 Forbidden (Bad auth) to the VoIP terminal 100, indicating that the SIP registration failed.

[0104] exist Figure 3In step ②, the VoIP server 200 may request the VoIP terminal 100 to generate a transmission test session for call quality prediction. Hereinafter, it is assumed that SIPOPTIONS, a representative Dialog-Out message of SIP, is used, but this is not a limitation.

[0105] Here, the SIP OPTIONS message is a SIP message used to query the current capabilities of SIP network components such as User Agents (UAs), Proxy Servers, Registrars, and Redirect Servers. SIP network components can provide information such as the types of SIP messages they can handle, the languages ​​they can interpret, or the types of SIP message bodies they can process in their responses to the SIP OPTIONS message. However, currently, in addition to querying and responding to the capabilities of SIP network components, it is also commonly used for purposes such as the Ping command in IP networks to confirm the current normal operation of components within a simple SIP network.

[0106] In addition to using the standardized headers in the basic protocol, SIP messages can use non-standard headers that begin with an X-, meaning experimental or extended, as a way to add new functions or features.

[0107] The VoIP server 200 utilizes the ability to use non-standard headers starting with X- to add headers such as X-Quality-Test to transmit SIP OPTIONS messages to the VoIP terminal 100, requesting the generation of a transmission test session for call quality prediction.

[0108] The header of X-Quality-Test can be configured as follows.

[0109] X-Quality-Test:Request aservaddr="20.20.20.20:1000",vservaddr="20.20.20.20:1001",method="digest,nonce="458e3bf6",algorithm="MD5,realm="lecture",acodec="ulaw,vcodec="h263

[0110] Here, Request is the call quality prediction request, aservaddr is the address of the call quality prediction server 300 for voice, vservaddr is the address of the call quality prediction server 300 for video, method is set to digest, which means that the authentication method is used via message digest, nonce is the random value to be included in the hash value calculation, algorithm is the hash algorithm, realm is the region that defines the ID and password (usually the server name), acodec is the ulaw codec used as the codec for voice, and vcodec is the h263 codec used as the codec for video.

[0111] In the example above (the header format of X-Quality-Test), only the codec name is used for brevity. Taking the h.264 codec as an example, to accurately understand the data transfer rate for different codecs, detailed information such as Profile and Level is also transmitted to calculate the number of frames per second or the size of the frames.

[0112] The addresses (aservaddr, vservaddr) of the call quality prediction server 300 used for voice or video are addresses used to generate transmission test sessions for call quality prediction, and can be negotiated and determined by the VoIP server 200 and the call quality prediction server 300 through a separate process.

[0113] In addition to adding new headers to SIP messages, the VoIP server 200 can also add a body to SIP messages to transmit request information for call quality prediction.

[0114] For example, you can add a header such as Content-Type:application / call-quality-test to the SIP OPTIONS message above, and include the following content in the content body to transmit the SIP OPTIONS message.

[0115] Request

[0116] aservaddr:20.20.20.20:1000

[0117] vservaddr:20.20.20.20:1001

[0118] method:digest

[0119] nonce:"458e3bf6"

[0120] Algorithm: MD5

[0121] realm:"lecture"

[0122] acodec:"ulaw"

[0123] vcodec:"h263"

[0124] exist Figure 3 During process ②, the X-Quality-Test header of the SIP 2000k message is as follows:

[0125] X-Quality-Test:Request aservaddr="20.20.20.20:1000",vservaddr="20.20.20.20:1001",method="digest,nonce="458e3bf6",algorithm="MD5,realm="l ecture",response="dfe56131d1958046689d83306477ecc",username="abc",uri="sip:abc@def.com",acodec=ulaw,vcodec=h263 clientaddr=1.1.1.1:10,11

[0126] The VoIP terminal 100 can include the message digest calculation result in the response field of the X-Quality-Test header and transmit it to the VoIP server. The message digest calculation of the VoIP terminal 100 can calculate A1, nonce, and A2 separately, and then apply a hash algorithm to A1, nonce, and A2 again for summation.

[0127] Here, A1 is the result of applying a hash algorithm to calculate the message digest for the ID, Password, and realm recorded in the username field, and A2 is the result of applying a hash algorithm to calculate the message digest for the method "OPTIONS" and the request URI of the SIP OPTIONS message.

[0128] The VoIP server 200 can authenticate the VoIP terminal 100 by comparing its own calculated message digest value with the message digest value transmitted from the VoIP terminal 100.

[0129] exist Figure 3In process ③, when authentication of the VoIP terminal 100 is successful, the VoIP server 200 can transmit authentication information to the call quality prediction server 300. Here, the authentication information may include the IP addresses (20.20.20.20) and port numbers (1000, 1001) of the voice and video transmitted to the VoIP terminal 100 for the call quality prediction server 300, and the message digest value calculated by the VoIP server 200 itself in process ②. If in Figure 3 If the authentication of the VoIP terminal 100 fails during process ②, the call quality prediction can be terminated immediately.

[0130] exist Figure 3 In process ④, the VoIP terminal 100 can generate a NAT pinhole for transmission testing between the VoIP terminal 100 and the call quality prediction server 300 by transmitting a packet containing authentication information to the call quality prediction server 300.

[0131] More specifically, the VoIP terminal 100 can assign any two of its own ports that are not used for SIP message transmission and reception (e.g., 50 or 60 when used by Default in SIP messages), to transmit and receive SIP messages. Figure 3 The address transmission packets of the call quality prediction server 300 obtained during process ② are transmitted, and the packets are transmitted... Figure 3 The message digest value calculated during process ② is included in the packet and transmitted to the call quality prediction server 300 as is.

[0132] The call quality prediction server 300 can compare the message digests received from the VoIP server 200 and the message digests received from the VoIP terminal 100. In one embodiment, if the message digest comparison results are the same, the call quality prediction server 300 successfully performs SIP authentication on the VoIP terminal 100, and then can continue to execute process ⑤. In another embodiment, if the message digest comparison results are different, the call quality prediction server 300 fails to perform SIP authentication on the VoIP terminal 100, and the entire call quality prediction process fails.

[0133] exist Figure 3 During process ⑤, the call quality prediction server 300 can record the call quality prediction data. Figure 3In process ④, the source IP and source port number in the IP header of the received packet are used as the destination to perform a transmission test for call quality prediction. The transmission test session generated in the above process can handle all four types of NAT (Network Address Translation): Full Cone, Restricted Cone, Port Restricted Cone, and Symmetric NAT.

[0134] exist Figure 2 If there is no NAT traversal between the VoIP terminal 100, the VoIP server 200, and the call quality prediction server 300, then the VoIP server 200 can... Figure 3 During step ②, check whether the authentication of the VoIP terminal 100 is successful.

[0135] In one embodiment, upon successful authentication, the VoIP server 200 can... Figure 3 In process ③, the address information of the VoIP terminal 100 obtained in process ② (the clientaddr field of the X-Quality-Test header) is added for transmission, while the call quality prediction server 300 does not need to. Figure 3 The process of generating NAT pinholes in process ④ directly executes process ⑤ to predict call quality.

[0136] For example, if there is no NAT traversal between the VoIP terminal 100 and the call quality prediction server 300, then there is no need for the process of generating a NAT pinhole; therefore, in Figure 3 During process ②, the address of the call quality prediction server 300 does not need to be included in the SIP OPTIONS message.

[0137] For example, if there is NAT traversal between the VoIP terminal 100 and the call quality prediction server 300, then because the call quality prediction server 300 performs transmission tests based on NAT pinholes, in... Figure 3 In step ②, the address of the VoIP terminal 100 does not need to be included in the SIP 2000k message.

[0138] That is, after completing SIP registration with the VoIP server 200, the VoIP terminal 100 becomes a call-ready state, and the VoIP server 200 can request the call quality prediction server 300 and the VoIP terminal 100 to generate a transmission test session for call quality prediction.

[0139] Figure 4 This is a schematic diagram illustrating the process of generating a transmission test session that generates a VoIP server request and is used to predict call quality between the VoIP server and any VoIP terminal. More specifically, Figure 4 This diagram illustrates the process of call quality prediction being performed directly by the VoIP server 200 without using the call quality server 300.

[0140] exist Figure 4 During process ①, the VoIP terminal 100 may request SIP registration from the VoIP server 200. More specifically, the VoIP terminal 100 may generate a SIP REGISTER message to request SIP registration and perform SIP registration through the generated SIP REGISTER message. At this time, the SIP registration of the VoIP terminal 100 is performed through methods such as a shared secret.

[0141] VoIP terminal 100 can transmit an initial SIPREGISTER message without authentication information to VoIP server 200 to request SIP registration, while VoIP server 200 can transmit a 401 Unauthorized response containing authentication information to VoIP terminal 100. Here, authentication information may include authentication method, authentication algorithm, areas defining account (ID) and password, nonce value, etc.

[0142] The VoIP terminal 100 can confirm the authentication information in the 401 Unauthorized response received from the VoIP server 200 and calculate the message digest as required by the VoIP server 200. Here, the message digest is a bit string of fixed length that is reduced by repeatedly applying a one-way hash function to a message of arbitrary length.

[0143] VoIP terminal 100 can transmit a second SIP REGISTER message containing a calculated message digest to VoIP server 200. VoIP server 200 can calculate the message digest using the same method as VoIP terminal 100. After calculating the message digest, VoIP server 200 can compare its calculated message digest result with the message digest result contained in the second SIP REGISTER message.

[0144] In one embodiment, the VoIP server 200 terminates the SIP authentication of the VoIP terminal 100 when its calculated message digest result is the same as the message digest result contained in the second SIP REGISTER message. After terminating the SIP authentication of the VoIP terminal 100, the VoIP server 200 transmits a 200OK message to the VoIP terminal 100, successfully performing the SIP registration of the VoIP terminal 100 using the REGISTER message.

[0145] In another embodiment, if the message digest result calculated by the VoIP server 200 is different from the message digest result contained in the second SIP REGISTER message, the VoIP server 200 cannot terminate the SIP authentication of the VoIP terminal 100, and the SIP authentication of the VoIP terminal 100 fails. At this time, the VoIP server 200 may transmit an error response such as 403 Forbidden (Bad auth) to the VoIP terminal 100, indicating that the SIP registration failed.

[0146] exist Figure 4 During process ②, the VoIP server 200 may request the VoIP terminal 100 to generate a transmission test session for call quality prediction. At this time, Figure 4 The second process, except in Figure 3 In step ②, the aservaddr and vservaddr of the X-Quality-Test header are set to the same values ​​as those of the VoIP server 200, which is not the address of the call quality prediction server 300.

[0147] Figure 4 Because the call quality prediction server 300 is not used, it is not executed. Figure 3 The third process. In Figure 4 In the process of ③, with Figure 3 Similar to process ④, the VoIP terminal 100 can perform authentication by generating a NAT pinhole for transmission testing by transmitting a packet containing authentication information to the VoIP server 200.

[0148] exist Figure 4 In process ④, the VoIP server 200 may be included in the process of... Figure 4In process ③, the source IP and source port number in the IP header of the received packet are used as the destination to perform a transmission test for call quality prediction. The transmission test session generated in the above process can handle all four types of NAT (Network Address Translation): Full Cone, Restricted Cone, Port Restricted Cone, and Symmetric NAT.

[0149] If there is no NAT traversal between VoIP terminal 100 and VoIP server 200, then VoIP server 200 can... Figure 4 In step ②, the authentication success of the VoIP terminal 100 is checked. In one embodiment, if authentication fails, the VoIP server 200 can skip the process of generating a NAT pinhole in the VoIP terminal 100 and directly execute the next step to predict call quality. For example, the VoIP terminal 100 included in the SIP 2000k message can use the port information allocated for the call quality prediction transmission test, without needing to... Figure 4 The ③ process directly executes the transmission test.

[0150] That is, after completing SIP registration with the VoIP server 200, the VoIP terminal 100 becomes a call-ready state, and the VoIP server 200 can request the VoIP terminal 100 to generate a transmission test session for call quality prediction.

[0151] Figure 5 This is a schematic diagram illustrating the process of generating a transmission test session for call quality prediction between a VoIP terminal request and an arbitrary VoIP terminal. More specifically, Figure 5 This is a schematic diagram illustrating the process by which a VoIP terminal 100 requests and directly performs call quality prediction.

[0152] exist Figure 5 During process ①, the VoIP terminal 100 may request SIP registration from the VoIP server 200. More specifically, the VoIP terminal 100 may generate a SIP REGISTER message to request SIP registration and perform SIP registration through the generated SIP REGISTER message. Here, the SIP registration process of the VoIP terminal 100 is similar to... Figure 3 and Figure 4 The process is the same as ①.

[0153] exist Figure 5During process ②, the VoIP terminal 100 may request the VoIP server 200 to generate a transmission test session for call quality prediction. More specifically, such as... Figure 3 and Figure 4 As shown, telephone terminal 100 can use SIPOPTIONS.

[0154] The header of X-Quality-Test can be configured as follows.

[0155] X-Quality-Test:Request acodec="ulaw",vcodec="h263"

[0156] Here, Request is a call quality prediction request, and acodec and vcodec are the voice and video codecs, respectively.

[0157] Other information used for transmitting the test can be included in the X-Quality-Test header of the SIP 200 OK response message transmitted by the VoIP server 200 as a response to SIP OPTIONS, in the following form.

[0158] X-Quality-Test:Response aservaddr="20.20.20.20:1000",vservaddr="20.20.20.20:1001",method="digest,nonce="458e3bf6",algorithm="MD5,realm="lecture",acodec="ulaw",vcodec="h263"

[0159] Here, Request is the response to the call quality prediction request, aservaddr is the address of the call quality prediction server 300 for voice, vservaddr is the address of the call quality prediction server 300 for video, method is set to digest, which means that the authentication method is used via message digest, nonce is the random value to be included in the hash value calculation, algorithm is the hash algorithm, realm is the region that defines the ID and password, acodec is the ulaw codec used as the codec for voice, and vcodec is the h263 codec used as the codec for video.

[0160] VoIP server 200 Figure 5In process ②, it can be performed similarly to the SIP registration request process using SIP REGISTER in process ①, including a 401 Unauthorized error after completing SIP authentication of the VoIP terminal 100. However, because call quality prediction is performed by the call quality prediction server 300, therefore... Figure 5 The middle part is omitted.

[0161] exist Figure 5 During process ③, the VoIP server 200 can communicate with... Figure 3 The same process as step ③ is performed, transmitting authentication information to the call quality prediction server 300. Here, the authentication information may include the IP address (20.20.20.20) and port number (1000, 1001) of each voice and video transmitted to the VoIP terminal 100 for the call quality prediction server 300. In one embodiment, similar to... Figure 3 The method for calculating the message digest is the same in process ②. The VoIP server 200 can calculate the message digest and transmit the authentication information to the call quality prediction server 300.

[0162] exist Figure 5 In the process of ④, with Figure 3 The calculation method is the same in process ②. After calculating the message digest, the VoIP terminal 100 includes the calculated value in the packet and first transmits it to the call quality prediction server 300.

[0163] Call quality prediction server 300 compares the message digest received from VoIP terminal 100 with the message digest received from VoIP terminal 100. Figure 5 The third process receives a message digest from the VoIP server 200 and performs SIP authentication on the VoIP terminal 100.

[0164] In one embodiment, when SIP authentication of the VoIP terminal 100 is successful, the test server 300 can receive the transmission test packets for call quality prediction transmitted by the VoIP terminal 100, and retransmit them with the Source IP and Source Port contained in the IP header of the transmission test packets as the destination. The transmission test session generated in the above process can handle all four types of NAT (Network Address Translation): FullCone, Restricted Cone, Port Restricted Cone, and Symmetric NAT.

[0165] In another embodiment, when SIP authentication of VoIP terminal 100 fails, call quality prediction server 300 refuses to transmit or separately notifies VoIP terminal 100 of the SIP authentication failure to terminate the call quality prediction process.

[0166] Specifically, VoIP terminal 100 performs SIP registration with VoIP server 200 to become capable of making calls. VoIP terminal 100 can then request VoIP server 200 to generate a transmission test session for call quality prediction. VoIP server 200 can transmit the address information of a call quality prediction server 300 that is not its own to VoIP terminal 100. VoIP terminal 100 then uses the call quality prediction server 300 at that address to perform the SIP authentication process and generates a transmission test session to predict call quality.

[0167] Figure 6 This is a schematic diagram illustrating the process of generating a transmission test session for predicting call quality between a VoIP server and any VoIP terminal, using a VoIP terminal request. More specifically, Figure 6 This is a schematic diagram illustrating the process by which a VoIP terminal 100 requests and directly performs call quality prediction. (Just...) Figure 6 Without going through the call quality prediction server 300, the VoIP server 200, which performs SIP registration with the VoIP terminal 100, directly generates a transmission test session to predict call quality.

[0168] exist Figure 6 During process ①, the VoIP terminal 100 may request SIP registration from the VoIP server 200. More specifically, the VoIP terminal 100 may generate a SIP REGISTER message to request SIP registration and perform SIP registration through the generated SIP REGISTER message. Here, the SIP registration process of the VoIP terminal 100 is similar to... Figure 3 , Figure 4 and Figure 5 The process is the same as ①.

[0169] exist Figure 6 In the process of ②, such as Figure 3 , Figure 4 and Figure 5 Similarly, VoIP terminal 100 can use SIP OPTIONS to request VoIP server 200 to generate a transmission test session for call quality prediction. However, in this case, the 200OK response transmitted by VoIP server 200 will contain its own IP address and a newly assigned port number for the transmission test in the aservaddr and vservaddr fields of the X-Quality-Test header.

[0170] exist Figure 6 During process ③, when SIP authentication is successful, the VoIP terminal 100 can generate a transmission test session to predict call quality. This differs from the previous method ( Figure 3 , Figure 4 and Figure 5 Similar to the above, both the VoIP terminal 100 and the VoIP server 200 can calculate message digest values. In one embodiment, the VoIP server 200 compares the message digest transmitted by the VoIP terminal 100 with its own calculated message digest. If the values ​​are the same, authentication is successful, and a transmission test session generation request can be accepted to perform call quality prediction with the VoIP terminal 100. Here, besides the fact that the object performing call quality prediction is the VoIP server 200, the VoIP server 200 can also perform call quality prediction with the VoIP terminal 100. Figure 5 The process is the same as step ④.

[0171] Additionally, the VoIP server 200 is in Figure 6 In process ②, similar to the SIP REGISTER process in process ①, after completing SIP authentication of the VoIP terminal 100 (using the 401 Unauthorized error), call quality prediction can be performed. At this point, Figure 6 During process ③, the VoIP terminal 100 is used in Figure 6 The address information of the VoIP server 200 obtained during process ② is immediately used to perform a transmission test.

[0172] Specifically, VoIP terminal 100 performs SIP registration with VoIP server 200 to become capable of making calls. VoIP terminal 100 can then request VoIP server 200 to generate a transmission test session for call quality prediction. VoIP server 200 can inform VoIP terminal 100 of its address, which includes a newly allocated port for the transmission test, and SIP authentication request information. VoIP terminal 100 can then use the address of VoIP server 200 to perform the SIP authentication process and generate the transmission test session to predict call quality.

[0173] Figures 3 to 6 The call quality prediction process described above illustrates how transmission tests are performed between the VoIP terminal 100 and the VoIP server (SIP Proxy, IP-PBX, CSCF, etc.) 200, or between the VoIP terminal 100 and the call quality prediction server 300, to measure packet loss rate, transmission delay, and raw data integrity, thus predicting call quality. To address the NAT issue, when an SBC is present between the VoIP terminal 100 and the VoIP server 200, the existing method is applied as is. Figures 3 to 6The call quality prediction process up to this point is performed by the SBC, which predicts the call quality between VoIP terminals 100. Moreover, the SBC can also simply act as an intermediary in the call quality prediction process between VoIP terminals 100 and VoIP server 200.

[0174] The system can generate additional transmission test sessions for predicting call quality with the VoIP server 200 that performs the SIP registration process or an external call quality prediction server 300 to perform transmission tests. Furthermore, the address of the VoIP terminal 100 identified by the VoIP server 200 during the SIP registration process, having resolved NAT issues through SIP's own NAT Traversal solution and stored in the VoIP server 200, can be used directly to perform transmission tests.

[0175] However, since it is an address used for SIP message transmission, although SIP messages and transmission test packets may be confused, the format of SIP messages is fixed, and the format of RTP packets or masquerading (with the same size and transmission interval) RTP packets and UDP packets that record transmission time is also fixed, so it is not impossible to distinguish them. The call quality prediction transmission test can be performed using the SIP registered address as is.

[0176] When VoIP operators use SBC (Session Border Controller) to resolve SIP NAT Traversal issues and perform Topology Hiding on the VoIP server side, the SBC typically performs Media Relay. In this case, the subscriber's terminal and the SBC can pre-generate NAT pinholes for use during actual call generation. To ensure that call quality prediction is performed in the same environment as the actual call generation, the media used by the SBC for call quality prediction also performs relay.

[0177] exist Figure 3 and Figure 4 In the process, when the VoIP server 200 records its own or the call quality prediction server 300's address information in the SIP OPTIONS message and transmits it to the VoIP terminal 100, the SBC (Session Border Controller) transforms the address into its own address and transmits it to the VoIP terminal 100 to execute a transmission test session for call quality prediction.

[0178] exist Figure 5 and Figure 6In this process, the SBC can transform the address of the VoIP server 200 or the call quality prediction server 300 contained in the response message to SIP OPTIONS into its own address to predict call quality. However, since this is an address used to generate actual calls, and in case of anticipated inconvenience due to conflicts with actual calls, the SBC can negotiate with the VoIP terminal 100 to pre-generate a NAT pinhole for transmitting test sessions, and this address can also be used.

[0179] In such Figures 3 to 6 In the call quality prediction process up to this point, transmission tests are performed after a SIP transaction is completed, but they can also be performed in the middle of a SIP transaction. For example, in Figure 3 During process ②, the VoIP terminal 100 can receive the address and authentication information of the call quality prediction server 300 via a SIP OPTIONS message, calculate a message digest based on the authentication information, and transmit the calculated value to the call quality prediction server 300. When the call quality prediction server 300 receives the calculated message digest value from the VoIP terminal 100, it will... Figure 3 process ③ in Figure 3 During process ②, SIP authentication is completed by comparing the authentication information received from the VoIP server 200 with the message digest calculated by the server itself. In one embodiment, when SIP authentication is successful, the call quality prediction server 300 can use a NAT pinhole generated during the process of receiving the message digest from the VoIP terminal 100 to perform a transmission test. After performing the transmission test, if necessary, the call quality prediction result is included in a SIP 200OK message and transmitted to the VoIP terminal 100 via the VoIP server 200. Additionally, in Figure 4 The same method can be used to achieve the same result in other cases.

[0180] exist Figure 5 In this case, to receive the address of the call quality prediction server 300, the VoIP terminal 100 may first receive a SIP 200 OK message. For example, while the VoIP server 200 first transmits a 401 Unauthorized response to the VoIP terminal 100 as an initial SIP OPTIONS message, it may also transmit authentication information and the address of the call quality prediction server 300. In this case, the transmission test can be performed in the middle of the second SIP OPTIONS transaction.

[0181] Furthermore, if the authentication process is omitted and there is no NAT device between the VoIP terminal 100 and the call quality prediction server 300, then the VoIP server 200... Figure 5 In process ②, after obtaining the address of the VoIP terminal 100 through the SIP OPTIONS message, then... Figure 5 process ③ in Figure 5 During process ②, the address of the VoIP terminal 100 is transmitted to the call quality prediction server 300. The call quality prediction server 300 can then perform a transmission test for call quality prediction with the VoIP terminal 100 and include the prediction results in the VoIP server 200. Figure 5 The SIP 2000k message in process ② is transmitted to the VoIP terminal 100. Figure 6 The same method can be used to achieve the same result in other cases.

[0182] In mobile communication wireless networks, when there is a network such as GPRS (General Packet Radio Service) between the CSCF (Call Session Control Function) belonging to the VoIP terminal 100 and the VoIP server 200, a GPRS attach process is also required. The process between the VoIP terminal 100 and the SGSN (Serving GPRS Support Node) is constituted by the PDP (Packet Data Protocol) Context Activate process, and the process between the SGSN and the GGSN (Gateway GPRS Support Node) is constituted by the PDP Context Create process.

[0183] When the PDP Context is generated and activated, the VoIP terminal 100 is assigned an IP address and port number for transmission testing and can use it to generate transmission test sessions to predict call quality. This process is necessary to predict call quality in an environment that is as similar as possible to when an actual call is generated, and since the Private IP can be obtained through the GGSN according to the mobile communication company's policy, the same situation as using Private IP in a wired network may be required.

[0184] Figure 3 The second process involves sending and receiving codec information for the transmission test. Using this information, the required bandwidth for QoS (Quality of Service) is requested during PDP generation and activation according to different codecs. QoS-related technologies such as RSVP (Resource Reservation Protocol) or DiffServ (Differentiated Service) are used to ensure QoS, thereby enabling the transmission test to be performed in the same environment as a call between actual VoIP terminals 100. This QoS execution process is applicable to the entire scope of this invention.

[0185] That is, when in the actual call connection process, QoS is provided through various methods such as first, PDP Context generation and activation; or second, resource reservation for a specific path session using RSVP; or third, traffic classification differentiation using DiffServ; or fourth, MPLS (Multi-Protocol Label Switching), IntServ (Integrated Service), etc. Then, the transmission test for predicting call quality between different intervals of SIP network components, including VoIP terminal 100, is also implemented after providing the same QoS.

[0186] Figures 7 to 12 This is a schematic diagram illustrating the process of predicting call quality between any VoIP terminals. Figures 7 to 12 The VoIP terminal 100 in the example is described using the assumption that it sends and receives SIP messages in an IMS network or a wired network.

[0187] More specifically, Figure 7 In an IMS network, this process involves sending and receiving messages to perform call quality prediction between any calling terminal and called terminal. When a calling terminal requests call quality prediction from a called terminal via a message such as SIP OPTIONS, the IMS component transmits the SIP OPTIONS message along the same path as the SIP INVITE message. In the case of an actual call between a trunk terminal and a called terminal, when Media Relay is executed due to various reasons such as telecommunications company policies, NAT, Topology Hiding, and Media Transcoding, the components of the IMS network through which the SIP OPTIONS message passes are set as the boundaries of the call quality transmission interval (the terminal is set to the boundary of the transmission interval by default). Transmission tests are performed for each interval, and the call quality prediction index for the entire interval is calculated by averaging or simply taking the lowest value among the various call quality prediction indices. Figure 7 This situation indicates that the P-CSCFs on both sides of the calling terminal and the called terminal are performing Media Relay due to reasons such as NAT.

[0188] Figure 8 Most of the Figure 7Similarly, when both the calling and called terminals are on a GPRS (General Packet Radio Service) network, the public IP is either directly set via the GGSN (Gateway GPRS Support Node) or indirectly obtained through an SBC (System-Based Communication Center) between the terminal and the P-CSCF. This is because IMS network components other than the terminal and SBC do not perform Media Relay (the SBC generally performs Media Relay, but it is ignored here). Figure 12 (As supplemented in the text), the transmission test is performed directly between the calling terminal and the called terminal.

[0189] Figure 7 and Figure 8 This describes the process of using SIP OPTIONS messages to predict call quality between any VoIP calling terminals 102 and 106 and specific VoIP called terminals 104 and 108. Here, any VoIP calling terminals 102 and 106 can be... Figure 1 At least two of the multiple VoIP terminals 100, wherein the specific VoIP called terminals 104 and 108 can be those not belonging to any VoIP calling terminals 102 and 106. Figure 1 At least two of the multiple VoIP terminals 100 in the system.

[0190] For ease of explanation, VoIP calling terminals 102 and 106 will be referred to as calling terminals 102 and 106, while specific VoIP called terminals 104 and 108 will be referred to as called terminals 104 and 108.

[0191] SIP Transaction Request Unit 21 can record information of calling terminals 102 and 106 in the From header and information of called terminals 104 and 108 in the To header, and then utilize the... Figures 3 to 6 A similar approach could be used to add headers such as X-Quality-Test to request call quality prediction.

[0192] and Figures 3 to 6 Similarly, the X-Quality-Test header can also be recorded in the body of the SIP message. The meaning is the same here, so the process of adding a body to the SIP message for recording will be omitted in the following content.

[0193] The header of X-Quality-Test can be configured as follows.

[0194] X-Quality-Test:Request acodec=ulaw,vcodec=h263,addr1=1.1.1.1:10,11

[0195] Here, Request is the call quality prediction request, and addr1 is the user's own IP address, voice port information, and video port information that will be used in the call quality prediction request. That is, addr1 includes its own IP address (1.1.1.1), voice port (10), and video port (11), acodec is the ulaw codec used for voice, and vcodec is the h263 codec used for video.

[0196] The user's IP address can be either a personal IP or a public IP. The SBC (Session Border Controller) exists between calling terminals 102 and 106 and P-CSCF (Proxy CSCF) 400 and 404. When calling terminals 102 and 106 have personal IPs, they can record the personal IP as is, and then the SBC converts it to a public IP before transmitting it to P-CSCF 400 and 404. At this time, because P-CSCF 400 and 404 consider calling terminals 102 and 106 to be using public IPs, they do not execute Media Relay, thus enabling [the application of...]. Figure 8 The process.

[0197] and Figures 3 to 6 In the same situation, the calling terminal 102 can first perform SIP authentication. Figure 7 During process ①, P-CSCF400 can transmit a 401Unauthorized response to the calling terminal 102 in response to the SIP OPTIONS message to request authentication. The calling terminal 102 can then transmit the SIP OPTIONS message to P-CSCF400 again, including authentication information, in response to the SIP authentication request.

[0198] The P-CSCF400 checks the value of the SIP OPTIONS message received from the calling terminal 102. If authentication is successful, it can continue to the next step; if authentication fails, it can transmit error messages such as 403 Forbidden (Bad auth) to the calling terminal 102, rejecting the call quality prediction request. In the following content... Figure 8 The subsequent SIP authentication process can also be completed through the same process, so the explanation of SIP authentication will be omitted.

[0199] The P-CSCF400, upon receiving a SIP transaction request containing a call quality prediction request, manages the call terminal 102 through... Figure 7The process ① involves the called terminal 104, which executes a telephone connection and records the SIP transaction request. During MediaRelay execution, call quality can be predicted through a transmission test with the calling terminal 102. At this time, the transmission test and the record... Figure 3 and Figure 4 The method is the same as in [the previous section].

[0200] For example, when a P-CSCF or IP-PBX is assigned a personal IP address via a GGSN (Gateway GPRS Support Node) to a calling terminal 102, and there is no SBC performing NAT traversal in between, in a SIP environment comprised of an IP-PBX or in the case of a calling terminal behind a NAT device, Media Relay can be executed to resolve NAT traversal. In this case, if... Figure 4 The call quality prediction method, managed by P-CSCF or IP-PBX, is implemented by servers dedicated solely to Media Relay. Figure 3 Call quality prediction methods are sufficient. Additionally, in Figure 7 In step ①, the addr1 field of the X-Quality-Test header is ignored here because it is not needed at all.

[0201] Once the call quality prediction with the calling terminal 102 is completed, the P-CSCF400 can save the result in its own cache memory. The IP address (30.30.30.30) of the P-CSCF400 executing MediaRelay and the voice and video ports (1000, 1001) can be saved in the X-Quality-Test header in the following form.

[0202] X-Quality-Test:Request acodec=ulaw,vcodec=h263,addr1=1.1.1.1:10,11,CQTY=8.9:8.2,addr2=30.30.30.30:1000,1001

[0203] After saving the X-Quality-Test header, the P-CSCF400 can transmit the SIP OPTIONS message to the next destination via the same transmission path as the SIP Transaction Request message. At this point, to ensure rapid call quality prediction, the P-CSCF400 removes the CQTY (Call Quality) field, first transmitting the SIP OPTIONS message, and then inserting the CQTY field during the transmission of the 2000k response. Here, the CQTY field represents both voice quality (8.9) and video quality (8.2), and the addr2 field represents the IP address (30.30.30.30), voice port (1000), and video port (1001) of the calling P-CSCF400.

[0204] Figure 8 Process ① falls under the category of NAT traversal execution due to the calling terminal 106 itself having a public IP or an SBS existing between the calling terminal 106 and P-CSCF404. This is considered a case where the calling terminal 106 has a public IP and does not require a Media Relay from P-CSCF404. Therefore, Figure 8 The P-CSCF404 may not be set as the boundary of the interval used for call quality prediction, and call quality prediction between the calling terminal 106 and the P-CSCF404 may not be performed. Even if the calling terminal 106 has a personal IP, a Media Relay may not be required if configured in the same SUBNET environment.

[0205] For example, when the SBC performs NAT traversal, a session for media transmission can be pre-configured between the calling terminal 106 and the SBC, and a NAT pinhole can be maintained. In this case, the SBC can record its own Media Relay address in the addr1 field (e.g., it can change the address of an existing calling terminal to its own address) and transmit it to the P-CSCF404. However, since the SBC address is used to generate the actual call, if an conflict is anticipated, the SBC and the calling terminal 106 can negotiate to generate a NAT pinhole for transmitting the test session. The SBC address can be set in the addr1 field of the X-Quality-Test header.

[0206] exist Figure 8 During process ①, if the X-Quality-Test header of the SIP OPTIONS message sent by the calling terminal 106 to P-CSCF404 is as follows, it can be sent to S-CSCF504 as is.

[0207] X-Quality-Test:Request acodec=ulaw,vcodec=h263,addr1=1.1.1.1:10,11

[0208] For example, in the case of an IMS network, in the P-CSCF400 and 404 on the calling side, the next destination of the SIP OPTIONS message is the S-CSCF500 and 504 of the home network of the calling terminals 102 and 106, while the next destination is the I-CSCH600 and 602 of the domain to which the called terminals 104 and 108 belong. This can be achieved by querying the HSS and transmitting the messages in the order of the S-CSCF502 and 506 to which the called terminals 104 and 108 belong, the P-CSCF402 and 406 to which the called terminals 104 and 108 belong, and the called terminals 104 and 108.

[0209] If there is no intermediate node executing Media Relay, then... Figure 7 As in the case of the X-Quality-Test header, the X-Quality-Test header is transmitted up to the called side 402, 406 as recorded in the P-CSCF400 to which the calling terminal 102 belongs.

[0210] X-Quality-Test:Request acodec=ulaw,vcodec=h263,addr1=1.1.1.1:10,11,CQTY=8.9:8.2,addr2=30.30.30.30:1000,1001

[0211] Here, addr1 is the address of calling terminal 102, addr2 is the address of the P-CSCF400 of the calling terminal 102, and CQTY is the address of the P-CSCF400 of the calling terminal 102. Figure 7 The call quality prediction results calculated during process ①.

[0212] exist Figure 8 In such cases, the transmission can be performed as recorded in the P-CSCF400 to which the call terminal 102 belongs.

[0213] X-Quality-Test:Request acodec=ulaw,vcodec=h263,addr1=1.1.1.1:10,11

[0214] Here, addr1 is the address of the calling terminal 106.

[0215] exist Figure 7 During process ③, due to reasons such as the called terminal 104 having a personal IP address, the Media Relay is executed by the called side P-CSCF402, which can then be achieved through... Figure 3 and Figure 4 The method predicts the call quality between the called terminal 104 and P-CSCF402, and saves the results (voice as 8.1, video as 8.2) in a high-speed cache.

[0216] In addition, Figure 7 In process ②, the called-side P-CSCF402 performs a transmission test for call quality prediction to the calling-side P-CSCF400 at addr2 in the X-Quality-Test header of the SIP OPTIONS message, and saves the results (8.1 for voice and 8.2 for video) in a cache. Since NAT traversal is generally not present at this time, there is no need for a NAT pinhole generation process; the transmission test can be performed using the address recorded in addr2.

[0217] It can be accessed via the called party's P-CSCF402. Figure 7 The second process involves the P-CSCF400 on the call side performing call quality prediction, which can also replace the method of... Figure 7 The ③ process involves the called terminal 104 directly performing the transmission test, while the P-CSCF402 only performs the test. Figure 7 In step ②, the result and its own address are recorded in the SIP OPTIONS message and then transmitted to the called terminal 104, which then predicts the call quality with P-CSCF402.

[0218] If in Figure 7 SIP authentication is required in process ②, then... Figures 3 to 6 The shared secret method is unsuitable. Instead, authentication can be performed by using certificates, which are issued by mutually trusted CAs (Certificate Authorities). For example, a challenge can be generated and transmitted. The receiving side encrypts the challenge with its own key and then transmits it again. Decryption to the public key of the receiving side's certificate confirms the original transmitted challenge, thus performing authentication.

[0219] After completing the call quality prediction, the P-CSCF402 (address = 40.40.40.40:2000, 2001) to which the called terminal 104 belongs can be configured with the X-Quality-Test header as follows.

[0220] X-Quality-Test:Request acodec=ulaw,vcodec=h263,addr1=1.1.1.1:10,11,CQTY=8.9:8.2,addr2=30.30.30.30:1000,1 001CQTY=8.4:8.5addr3=40.40.40.40:2000,2001CQTY=8.1:8.3addr4=50.50.50.50:3000,3001

[0221] Here, addr1 is the address of calling terminal 102, addr2 is the address of the calling P-CSCF400, addr3 is the address of the called P-CSCF402, and addr4 is the address of the called terminal 104. Additionally, the three CQTY fields, in sequence, represent the call quality prediction results between calling terminal 102 and calling P-CSCF400, between calling P-CSCF400 and called P-CSCF402, and between called P-CSCF402 and called terminal 104.

[0222] The X-Quality-Test header mentioned above can be included in the 200OK response to the SIP OPTIONS message and transmitted to the calling terminal 102. It can be confirmed that the prediction results between the calling terminal 102 and the called terminal 104 in different intervals are all included in the X-Quality-Test header mentioned above.

[0223] Each call quality prediction index, categorized by different intervals, is stored in a cache memory by the entity performing the call quality prediction. This allows for the avoidance of actual transmission tests when a call quality prediction request for the same target is received within a certain timeframe; instead, the stored values ​​are utilized, thereby reducing unnecessary traffic. For example, when another calling terminal 102 belonging to the same calling side P-CSCF400 requests a call quality prediction for the same called terminal 104, only the call quality prediction can be performed between the calling side P-CSCF400 and the calling terminal 102, while the values ​​stored in the cache memory can be used as is on both sides.

[0224] pass Figure 7 After the transmission test in process ②, the called side P-CSCF402, being the main body for predicting call quality, saves the result (CQTY = 8.4:8.5) as the call quality prediction result with the calling side P-CSCF400, and also saves the call quality prediction result with the called terminal 104. The calling side P-CSCF400, in its SIP 2000k response message, references the call quality prediction result with the called side P-CSCF402 and saves it in a cache memory.

[0225] Additionally, in the P-CSCF400 on the calling side, the SIP 2000k message calculation can also be referenced. Figure 7 The call quality prediction results of processes ② and ③ are stored in a cache memory as the call quality prediction results between the calling side P-CSCF400 and the called terminal 104. At this time, if another calling terminal belonging to the calling side P-CSCF400 requests call quality prediction for the same called terminal 104, only the following steps are performed: Figure 7 In process ①, the called party P-CSCF400 uses the call quality prediction results stored in the high-speed cache memory to immediately transmit a SIP 200OK response to the calling terminal 102, thereby ending the call quality prediction. This high-speed cache memory utilization structure is applicable throughout the entire scope of this invention.

[0226] Figure 8 In this case, since the called terminal 108 has a public IP address either on its own or through the SBC, there is no intermediate node that executes Media Relay, and the X-Quality-Test header below can be transmitted to the called terminal 108 as is.

[0227] X-Quality-Test:Request acodec=ulaw,vcodec=h263,addr1=1.1.1.1:10,11

[0228] It is possible Figure 8 In process ②, the called terminal 108 can refer to addr1 and perform a transmission test for call quality prediction with the calling terminal 106. If a called-side SBC exists and the called-side SBC is similar to... Figure 8 As described in step ①, the NAT pinhole for the transmission test session is negotiated with the called terminal 108, and this address can be used to perform the transmission test. That is, when the called-side SBC changes the addr1 field of the X-Quality-Test header to its own address information and transmits it to the called terminal 108 to participate in the transmission test, the called terminal 108 uses this SBC address to perform the transmission test. Then, the SBC performs the Media Relay transmission test as is for the calling terminal. Figure 8 The call quality prediction results for process ③ are 8.8 for voice and 8.9 for video. The personal IP address of the called terminal 108 used for transmission test is 192.168.1.1, the voice port information is 10, the video port information is 11, the public IP address of the called side SBC transformation is 50.50.50.50, the voice port information is 20, and the video port information is 21. A 200 OK message containing the following X-Quality-Test header can be transmitted from the called terminal 108 to the called side SBC.

[0229] X-Quality-Test:Request acodec=ulaw,vcodec=h263,addr1=50.50.50.50:20,21,CQTY=8.8:8.9,addr2=192.168.1.1:10,11

[0230] The called SBC can modify the add1 and addr2 fields of the X-Quality-Test header as follows, and transmit them from the called SBC to the called P-CSCF406.

[0231] X-Quality-Test:Request acodec=ulaw,vcodec=h263,addr1=1.1.1.1:10,11,CQTY=8.8:8.9,addr2=50.50.50.50:20,21

[0232] The 2000k message is then transmitted to the calling terminal 106 as is, ending the call quality prediction process.

[0233] Figure 9 This refers to the process of predicting call quality between any VoIP calling terminal and a specific VoIP called terminal.

[0234] More specifically, with Figure 8 The situation is the same. Figure 9 In situations where each terminal has a public IP address, and due to security, NAT traversal, and topology hiding reasons, there is an IBCF (Interconnection Border Control Function) acting as a border controller between telecommunications companies within the IMS network. The IBCF of each telecommunications company typically performs media relay. Figure 9 This indicates that because both sides of the IBCF execute Media Relay through linkage with IBCF (Interconnection Border Gateway Function) or TrGW (Transition Gateway), the transmission test interval for call quality prediction is set as calling terminal - calling side IBCF1 - called side IBCF2 - called terminal, and the transmission test is performed according to different intervals.

[0235] in addition, Figure 9This refers to a situation where, due to reasons such as both any VoIP calling terminal 110 and a specific VoIP called terminal 112 being directly or indirectly used for public IP, there is no Media Relay between the calling terminal 110 and the calling-side CSCF-700 or between the called terminal 112 and the called-side CSCF-702. This indicates that, for security purposes between mobile communication operators or for NAT traversal, topology hiding, etc., there exists an IBCF (Interconnection Border Control Function) for signal processing and an IBCG (Interconnection Border Gateway Function) for media processing. In this case, a call quality prediction process is performed between the calling terminal 110 and the called terminal 112.

[0236] in addition, Figure 9 Media Relay is generated not only in IBCF but also during media transcoding in the call delivery path, similar to the IBCF process, to perform call quality prediction. Here, IBGF typically executes Media Relay in conjunction with IBCF, and through... Figure 9 The X-Quality-Test header of the SIP OPTIONS message that arrives at the calling side IBCF-800 during process ① is as follows.

[0237] X-Quality-Test:Request acodec=ulaw,vcodec=h263,addr1=1.1.1.1:10,11

[0238] The calling side IBCF-800, in conjunction with the calling side IBCF-900 (address = 2.2.2.2), performs MediaRelay. Before transmitting the SIP OPTIONS message to the called side IBCF-802, or for the sake of call quality prediction, it sends a command to the calling side IBCF-900 to perform a transmission test.

[0239] Before transmission, the result can be received from IBGF-900 and the X-Quality-Test header can be transmitted to the called side IBCF-802 as follows.

[0240] X-Quality-Test:Request acodec=ulaw,vcodec=h263,addr1=1.1.1.1:10,11CQTY=8.8:8.9,addr2=2.2.2.2:20,21

[0241] When IBCF-800 acts as a Topology Hiding device, to maintain consistency, the addr1 information is deleted and then transmitted to IBCF-802.

[0242] X-Quality-Test:Request acodec=ulaw,vcodec=h263,CQTY=8.8:8.9,addr1=2.2.2.2:20,21

[0243] Here, the existing addr2 can become addr1.

[0244] As described above, when Topology Hiding is executed and the SIP OPTIONS message reaches IBCF 2802, IBCF 2802, when Media Relay needs to be executed, also sends a command to the called party IBCF 2902 (address = 3.3.3.3), through... Figure 9 The second process involves performing a transmission test between IBGF-900 and IBGF-902. After receiving the result from IBGF-902 and recording it in the X-Quality-Test header, it is transmitted to the called side CSCF-702.

[0245] X-Quality-Test:Request acodec=ulaw,vcodec=h263,CQTY=8.8:8.9,addr1=2.2.2.2:20,21,CQTY=9.0:9.1,addr2=3.3.3.3:30,31

[0246] Assuming the IBCF-800 performs media transcoding (converting uLBC to iLBC for audio and h.263 to h.261 for video), replacing the acodec and vcodec fields of the SIP OPTIONS message transmitted from the IBCF-800 to the IBCF-802 with iLBC and h.261 will allow the IBCF-800 and IBCF-802 to perform call quality prediction using iLBC and h.261, just like in a regular call. This field change must be remembered and restored before transmitting the 2000k acknowledgment message.

[0247] In addition, the audio and video codecs are arbitrarily specified by the calling terminal requesting call quality prediction or the AS (Application Server). However, as in the case of an actual call, before transmitting the SIP OPTIONS message for call quality prediction, a separate SIP OPTIONS Transaction is used to record and transmit a list of all codecs supported by the calling terminal. The called terminal then takes the intersection of this list with its own supported codec list and passes it to the calling terminal in response to the SIP OPTIONS message. The calling terminal can then select any codec from this list to perform call quality prediction.

[0248] For speed, the call quality prediction process can always involve simultaneous transmission tests and SIP OPTIONS message delivery. Even if the CQTY field is omitted, the address of the server executing the Media Relay will always be included in the transmission, thus setting the boundary for the interval used for call quality prediction. Since the default timer f for a SIP transaction is 32 seconds, a transmission test of approximately 10 seconds is preferable. Only by executing transmission tests in different intervals simultaneously can the final 200OK response be delivered to the calling terminal without exceeding timer f. The entity executing the transmission test remembers the result and inserts the CQTY field at the appropriate position in the 200OK response message for transmission.

[0249] In the case of CSCF 2.702, since Media Relay is not executed as assumed above, the X-Quality-Test header is transmitted to the called terminal 112 as is. The called terminal 112 (address = 4.4.4.4) uses addr2 (address = 3.3.3.3, IBGF2) contained in the X-Quality-Test header as the boundary of the interval used for the final call quality prediction. Figure 9 The ③ process performs call quality prediction and records the results (voice 9.2, video 9.3) in the X-Quality-Test header as follows, and transmits them to CSCF 702.

[0250] X-Quality-Test:Request acodec=ulaw,vcodec=h263,CQTY=8.8:8.9,addr1=2.2.2.2:20,21,CQTY=9.0:9.1,addr2=3.3.3.3:30,31CQTY=9.2:9.3,addr3=4.4.4.4:40,41

[0251] CSCF 2702 is passed to IBCF 2802 as is. In the case of IBCF 2802, if it serves the same purpose as IBCF 1800 in terms of Topology Hiding, then the following is how to hide the intranet information and pass it to IBCF 1802 after deleting addr3.

[0252] X-Quality-Test:Request acodec=ulaw,vcodec=h263,CQTY=8.8:8.9,addr1=2.2.2.2:20,21,CQTY=9.0:9.1,addr2=3.3.3.3:30,31CQTY=9.2:9.3

[0253] IBCF-800 is for Topology Hiding. The address of the deleted calling terminal 110 is restored and transmitted to CSCF-700 as follows, and CSCF-700 can transmit it to calling terminal 110 as is.

[0254] X-Quality-Test:Request acodec=ulaw,vcodec=h263,addr1=1.1.1.1:10,11,CQTY=8.8:8.9,addr2=2.2.2.2:20,21,CQTY=9.0:9.1,addr3=3.3.3.3:30,31CQTY=9.2:9.3

[0255] Call terminal 110 can refer to the call quality prediction of different intervals and use the average or minimum value to predict the call quality according to the strategy.

[0256] Figure 10 This refers to the process by which the VoIP recipient terminal performs call quality prediction when an analog line-switched network such as PSTN is in existence.

[0257] More specifically, Figure 10In the case where the called terminal belongs to the CS (Circuit Switching) domain, under the IMS network, the call is passed to the BGCF (Breakout Gateway Control Function). The SIP signal of the call is transmitted from the BGCF through the MGCF (Media Gateway Control Function) and then through the SGW (Signaling Gateway) to the CS domain, while the media of the call is transmitted through the MGW (Media Gateway) to the CS domain. At this time, since the MGW is the last traversal point of the PS (Packet Switching) domain, the interval boundary for call quality prediction is set here, and a transmission test for call quality prediction is performed between the MGW and the calling terminal.

[0258] When the destination is PSTN1400, a SIP OPTIONS message is sent to BGCF (Breakout Gateway Control Function) 1000, followed by transmission via MGCF (Media Gateway Control Function) 1100. Signal transmission is handled by SGW (Signaling Gateway) 1200, while media transmission is handled by MGW (Media Gateway), thus connecting to the circuit-switched network. In the case of a circuit-switched network, since the channel with physically guaranteed bandwidth is used, it is beyond the scope of this invention, and call quality prediction is not required. That is, call quality is predicted up to MGW 1300.

[0259] Figure 10 In cases where there is no Media Relay between the calling terminal 114 and the calling side P-CSCF-408 due to the calling terminal 114 being used directly or indirectly for public IP, an OPTIONS message containing the following X-Quality-Test header is sent. Figure 10 The process ① is passed to P-CSCF408, and then passed to MGCF1100 without any changes.

[0260] X-Quality-Test:Request acodec=ulaw,vcodec=h263,addr1=1.1.1.1:10,11

[0261] Because the MGCF110 and MGW1300 are connected to perform Media Relay, it can be used to... Figure 10In step ②, a command is sent to MGW (address = 2.2.2.2) 1300 to perform call quality prediction. MGCF803, having obtained the results of voice 8.0 and image 9.0 as the structure performing call quality prediction, then transmits a 200OK message containing the following X-Quality-Test header to BGCF1000, which is then sequentially transmitted to the calling terminal 114, thus ending the call quality prediction process.

[0262] X-Quality-Test:Request acodec=ulaw,vcodec=h263,addr1=1.1.1.1:10,11CQTY=8.0:9.0,addr2=2.2.2.2:20,21

[0263] At this point, since call quality prediction is not completed until the final called terminal, instead of the 200OK message, other SIP Error messages are transmitted containing information such as the failure location (MGCF) and the reason for failure (switching to a line-switched network). However, the X-Quality-Test header content is included as is, and the call quality prediction result is transmitted up to the MGW1300. This is not only due to technical reasons such as switching to line switching, but also because of the excessive load on the communication network caused by call quality prediction; in certain areas, call quality prediction may be prohibited due to the policy reasons of the communication company.

[0264] Figure 11 This refers to the process of performing call quality prediction via an external SIP AS. More specifically, Figure 11 This indicates a request from a non-calling terminal, such as a SIP application server, to predict the call quality between the calling terminal and the called terminal.

[0265] Besides the calling terminal 116 directly requesting via SIP OPTIONS messages, the SIP AS (Application Server) 1500 can also request call quality predictions between a specific calling terminal 116 and a specific called terminal 118 via any communication protocol. Taking the IMS network 1600 as an example, the information of the P-CSCF 410 to which the calling terminal 116 belongs can be obtained first. This is done by obtaining the address of the HSS (Home Subscriber Server) through the SLF (Subscriber Location Function) within the domain to which the calling terminal 116 belongs, querying the HSS to obtain the address of the S-CSCF on the calling side, and then obtaining the information of the P-CSCF 410. Similarly, in the case of a wired network, the information of the SIP Proxy to which the caller belongs can be obtained in a similar way. Then, the SIP AS 1500 requests call quality predictions between any calling terminal 116 and the called terminal 118 from the SIP Proxy or P-CSCF 410 on the calling side.

[0266] When passing Figure 11 In process ①, a call quality prediction request, including information from the calling terminal 116 and the called terminal 118, arrives at the calling side P-CSCF410, and then... Figure 11 In step ②, the P-CSCF410 requests a call quality prediction from the calling terminal 116. The SIP OPTIONS message is used again, with the To header and Request URI becoming the address of the calling terminal 116, and the X-Quality-Test header configured as follows.

[0267] X-Quality-Test:Request acodec=ulaw,vcodec=h263,peer="sip:abc@def.com"

[0268] Here, Request is a call quality prediction request, acodec is a voice codec, vcodec is a video codec, and peer is the called terminal's information.

[0269] When the calling terminal 116 passes Figure 11 If the call quality prediction request is obtained through process ②, then it can be obtained through... Figure 11 In process ③, call quality prediction is performed between the called terminal 118 and itself 116.

[0270] Depending on the situation Figure 11 The process of ③ is replaced by Figure 7 , Figure 8 , Figure 9 , Figure 10 , Figure 12 The process of waiting. Through Figure 11 In process ④, the calling terminal 116 can transmit data to the P-CSCF410 via... Figure 11 The result of the call quality prediction request obtained from process ② is transmitted to P-CSCF410. The X-Quality-Test header of the 200OK message can be configured as follows.

[0271] X-Quality-Test:Request acodec=ulaw,vcodec=h263,peer="sip:abc@def.com",CQTY=8.0:9.0

[0272] In the example above, it can be confirmed that only the final structure of the call quality prediction results for different intervals is transmitted. Additionally, the call quality prediction results for each interval may include the address information of the interval boundaries, which is also transmitted.

[0273] When the calling side P-CSCF410 receives the call quality prediction result between the calling terminal 116 and the called terminal 118, it can then... Figure 11 The fifth process transmits the call quality prediction results to the SIP AS1500.

[0274] Figure 12 This is a schematic diagram illustrating the process of predicting traffic to reduce call quality. Figure 13 This is a schematic diagram of a UDP packet for comparison with an embodiment of the present invention. More specifically, Figure 12 This describes the process of setting the SBC of the Media Relay to the boundaries of the interval used for call quality prediction.

[0275] Currently, while the SBC handles NAT traversal for the terminal and actually executes Media Relay during the actual call connection process, it also executes Media Relay in the transmission experiments used for call quality prediction, but it does not serve as the boundary of the call quality prediction interval. If multiple SBCs exist and multiple terminals are linked with the SBCs, setting the SBC as the boundary of the call quality prediction interval and managing the call quality prediction records between SBCs through a high-speed cache can reduce call quality prediction traffic.

[0276] exist Figure 12 In this example, assume that the personal IP address of the calling terminal 120 is 192.168.1.10, and its public IP address is changed to 20.20.20.20 via SBC.

[0277] Figure 12During process ①, the calling terminal 120 requests a call quality prediction from the called terminal 1222. The information of the called terminal 122 is set in the To header of the SIP OPTIONS message, and the X-Quality-Test header of the SIP OPTIONS message can be configured in the following form.

[0278] X-Quality-Test:Request acodec=ulaw,vcodec=h263,addr1=192.168.1.10:10,11

[0279] When the calling SBC-1700 receives a SIP OPTIONS message containing the aforementioned X-Quality-Test, it ignores the addr1 field and proceeds through... Figure 3 and Figure 4 The method performs call quality prediction (voice 8.9, image 8.2) between the calling terminal 120 and itself 1700, and transmits the X-Quality-Test header to the calling Proxy 1800 with the following configuration.

[0280] X-Quality-Test:Request acodec=ulaw,vcodec=h263,addr1=192.168.1.10:10,11,CQTY=8.9:8.2,addr2=20.20.20.20:10,11

[0281] At this time, since the calling side Proxy 1800 and the called side Proxy 2 1802 do not execute Media Relay, the X-Quality-Test header mentioned above is transmitted as is up to the called side SBC 2 (address = 30.30.30.30) 1702. Because the called side SBC 2 1702 executes Media Relay and is set as the boundary of the interval used for call quality prediction for the above reasons, call quality prediction is performed, and the results (voice 8.3, video 8.4) are recorded as follows and transmitted to the called terminal (address = 192.168.2.10) 122.

[0282] X-Quality-Test:Request acodec=ulaw,vcodec=h263,addr1=192.168.1.10:10,11,CQTY=8.9:8.2,addr2=20.20.20.20:10,11CQTY=8.3:8.4addr3=30.30.30.30:10,11

[0283] The called party's SBC 1702 performs call quality prediction with the called terminal 122 and immediately sends a 200 OK message to Proxy 1802. Figure 11 The ③ process is executed and the transmission test is performed on the called side SBC 1702. The results (voice 8.5, video 8.6) are recorded as follows and the SIP 2000k message is sent to the called side SBC 1702.

[0284] X-Quality-Test:Request acodec=ulaw,vcodec=h263,addr1=192.168.1.10:10,11,CQTY=8.9:8.2,addr2=20.20.20.2 0:10,11CQTY=8.3:8.4addr3=30.30.30.30:10,11CQTY=8.5:8.6addr4=192.168.2.10:10,11

[0285] The 2000k message is transmitted as is to the calling terminal 120, ending the call quality prediction process.

[0286] In actual call connection scenarios, this invention utilizes technologies such as IPSEC (Internet Protocol Security) or SRTP (Secure Real-Time Transport Protocol) to enhance security, based on the strategies of various telecommunications companies. During call quality prediction, and to conduct experiments in different intervals within an environment that is as similar as possible to the actual call connection process, IPSEC SA (Security Association) negotiation can be performed first between the boundaries of the intervals. Then, IPSEC's ESP (Encapsulating Security Payload) or AH (Authentication Header) methods can be used to encrypt and authenticate the transmitted test packets.

[0287] Additionally, when using SRTP, which was specifically developed for RTP, encryption and authentication of RTB packets that do not contain actual RTP packets or actual media can be performed via SRTP after key exchange is performed between interval boundaries.

[0288] In the case of transmission experiments using UDP packets, the process of generating UDP packets involves generating UDP packets with the same size and transmission interval as the RTP packets of the codec being tested. For example, in the case of ULAW, since 8000 samples of data per second are transmitted in 20ms intervals (160 samples * 50 data transmissions per second), UDP packets containing 160 samples (160 bytes) of arbitrary data and dummy data (the size of the RTP header in the RTP packet, defaulting to 12 bytes + header or extended data depending on the codec type) are generated and sent / received within a certain standard time frame for testing.

[0289] If ULAW is used and a call quality prediction test is performed within 10 seconds, this invention generates 500 packets, and the dummy data contained in each packet includes the current transmission time information of the transmitting side. When the other party transmits again, the transmitting side calculates the average RTT (Round Trip Time) by comparing the reception time of each of the 500 packets with the transmission time contained in the dummy data of the packets. After determining the number of missed packets and the deviation (deviation degree) between the RTT value of each packet and the average RTT value, the above values ​​are used to predict the call quality. When a wireless network is involved, checking the integrity of the original data can also be included in the call quality prediction process.

[0290] In voice codecs such as AMR (Adaptive Multi Rate), variable transmission rates are used based on network conditions. Similarly, UDP packets can also be configured to use variable transmission rates based on network conditions.

[0291] In the case of video, to improve compression ratio, video information uses the GOP (Group of Pictures) concept, which consists of an I-frame (Intra Frame) containing independent information about the entire image, a P-frame (Predictive Frame) encoded with reference to the previous I or P-frame, and a B-frame (Bi-directionally predictive Frame) encoded with both the preceding and following I or P-frames. Because frame sizes vary, and the GOP structure itself can be configured in other ways, statistical methods can be used, allowing UDP packets to adjust transmission intervals and packet sizes to resemble actual conditions, maximizing transmission in a state similar to video frames during a real-world call. A comparison of actual RTP packets and UDP packets used in this invention is provided for reference. Figure 13 .

[0292] Figure 14This diagram illustrates the relationship between a VoIP terminal and a VoIP server or SBC. More specifically, Figure 14 This is a schematic diagram illustrating in detail the relationship between VoIP terminals 124 and 126 and VoIP server 200.

[0293] VoIP terminal 124 is a type of VoIP terminal that connects via a wireless network, such as a smartphone. VoIP terminal 124 is wirelessly connected to a BTS (Base Transceiver Station) 1900 or a Node B 1900, and then connected to a wired network via a BSC (Base Station Controller) 2000 that manages the wireless network through the BTS 1900 or an RNC (Radio Network Controller) 2000 that manages the wireless network through the Node B 1900.

[0294] Afterwards, the VoIP terminal 124 connects to the line-switched network and can connect to the MSC (Mobile Switching Center). Figure 14 (omitted), or for connecting to the Internet or other packet-switched networks, it is assigned an IP address through SGSN2100 and GGSN2200, and is connected directly to the Internet, or as appropriate, via SBC1704, through the Internet consisting of L3 Switch, L2 Switch, L4 Switch, etc., which are routers 2600.

[0295] The VoIP server 200 acts as a P-CSCF for IMS networks, a SIP proxy for wired networks, and an IP-PBX for personal and business use. From the perspective of the SIP protocol, it is the first SIP object that communicates with the VoIP terminal 120 via SIP in the SIP network.

[0296] VoIP terminal 124 may be assigned a personal IP address via GGSN2200 due to telecommunications company policies, etc. This IP address is then converted to a public IP address via NAT and connected to VoIP server 200 via the Internet. To resolve NAT traversal issues, it can connect to VoIP server 200 via SBC1704. Furthermore, when a call is generated between the calling and called terminals, the media generally passes through the SBC. Even if NAT traversal issues exist, the SBC1704 is not used; instead, the VoIP server 200 can relay the media during call generation.

[0297] VoIP terminal 2 126 connects to the wired network via a wireless router 2300 and a DSL modem 2400 through an access network such as xDSL. A DSLAM (Digital Subscriber Line Access Multiplexer) 2500, installed by the telecommunications company and connected to the DSL modem 2400, provides internet access services to subscribers. Subsequently, similar to VoIP terminal 1 124, it connects directly to the VoIP server 200 via the internet formed by the L3 switch, L2 switch, and L4 switch (which act as routers) or, depending on the situation, via SBC 1704.

[0298] According to the telecommunications company's strategy, the company can provide personal or public IP addresses to subscribers via DSL modem 2400. Even when a public IP address is obtained, if a wireless router is used, VoIP terminal 2 126 will be assigned a personal IP address. In this case, similar to VoIP terminal 1 124, to resolve the NAT traversal issue, it connects to VoIP server 200 via SBC 1704 or the VoIP server 200 relays the media.

[0299] In this invention, to predict the call quality status of any VoIP terminal 124, 126 before call generation in response to the above-mentioned situation, the call quality is predicted through transmission tests in the interval between VoIP server 200 and VoIP terminals 124, 126 or between SBC1704 and VoIP terminals 124, 126, as a benchmark for the call quality status of VoIP terminals 124, 126 in an idle state. That is, in the state before determining the call target, even if connected to any other party, the call quality is predicted for the longest common media transmission path. In situations such as IPv6 environments, where a public IP address is obtained via GGSN2200 from VoIP terminal 124 in a wireless network environment, or via DSLModem2400 from VoIP terminal 226 in a wired network environment, the media is directly transmitted to the other party's terminal without passing through SBC1704 or VoIP server 200 during actual calls. This results in an overlap with the call quality prediction range of this invention. Compared to measuring call quality using other call quality measurement devices other than VoIP server 200, this method has the advantage of better reflecting the status of VoIP server 200.

[0300] Figure 15 A sequence diagram illustrating the process of predicting the call quality of the other party according to an embodiment of the present invention.

[0301] exist Figure 15In this process, the method for predicting call quality can be executed on one of the first and second network communication devices to predict the call quality of the other party.

[0302] SIP Transaction Request Unit 21 may optionally include the address information (IP address, Port number) of the aforementioned party for call quality prediction of one party, and transmit the SIP (Session Initiation Protocol) containing the call quality prediction request to the other party (step S1501).

[0303] SIP Transaction Response Receiving Unit 22 receives a SIP transaction response containing the address information (IP address, Port number) of the other party in response to the SIP transaction request (step S1502).

[0304] The call quality prediction unit 23 uses the address information of one party and the address information of the other party to perform a transmission test with the other party by using 1) RTP packets that are independent of the inclusion of actual media; 2) RTCP packets; or 3) dummy UDP packets disguised as RTP (hereinafter referred to as "transmission test packets") to predict the call quality (step S1503).

[0305] After step (a), the SIP transaction response transmission unit 24 first performs step (c) using the address of one party to obtain the call quality prediction result, and then transmits the result to one party in the SIP transaction response (step S1504).

[0306] The call selection decision unit can save the predicted call quality based on the packet loss rate and transmission delay time prediction of N transmission test packets, and decide on the call selection of the other party (step S1505).

[0307] Figure 16 This is a sequence diagram illustrating the process of predicting call quality for multiple VoIP terminals without a call generation process, according to another embodiment of the present invention.

[0308] exist Figure 16 In this context, the method for predicting call quality can be executed in the VoIP server or SBC without requiring the call generation process to predict call quality for multiple VoIP terminals.

[0309] The call quality prediction unit 23 performs transmission tests with each of the multiple VoIP terminals on the interval between the VoIP server or SBC and the VoIP terminal by using 1) RTP packets that are independent of the inclusion of actual media; 2) RTCP packets; or 3) dummy UDP packets disguised as RTP packets (hereinafter referred to as "transmission test packets") to predict the call quality (step S1601).

[0310] Based on the prediction of the call quality of each party, the call selection decision unit 25 provides the predicted call quality to the other party or provides information on the available VoIP terminal with the best call quality or performs a connection attempt (step S1602).

[0311] The above embodiments are only used to illustrate the present invention and not to limit it. Those skilled in the art should understand that modifications, variations or equivalent substitutions can be made to the present invention without departing from the spirit and scope of the present invention, and all such modifications and substitutions should be covered within the scope of the claims of the present invention.

[0312] Explanation of reference numerals in the attached figures

[0313] 10: Call quality prediction system; 20: Call quality prediction service device

[0314] 21: SIP Transaction Request Section 22: SIP Transaction Response Receiving Section

[0315] 23: Call Quality Prediction Department; 24: SIP Transaction Response Transmission Department

[0316] 25: Call Selection Decision Department 26: Control Department

[0317] 30, 40: IP Header 32, 42: UDP Header

[0318] 34: RTP Header 36: RTP Data

[0319] 44: Transmission time included in UDP packets 46: Dummy Data

[0320] 100, 102, 104, 106, 108, 110, 112, 114, 116, 118, 120, 122, 124, 126: VoIP terminals

[0321] 200: VoIP server; 300: Call quality prediction server

[0322] 400, 402, 404, 406, 408, 410: P-CSCF (Proxy CSCF)

[0323] 500, 502, 504, 506, 508: S-CSCF (Serving CSCF)

[0324] 600, 602: I-CSCF (Interrogating CSCF)

[0325] 700, 702: CSCF (Call Session Control Function)

[0326] 800, 802: IBCF (Interconnection Border Control Function)

[0327] 900, 902: IBGF (Interconnection Border Gateway Function)

[0328] 1000: BGCF (Border Gateway Control Function)

[0329] 1100: MGCF (Media Gateway Control Function)

[0330] 1200: SGW (Signaling Gateway) 1300: MGW (Media Gateway)

[0331] 1400: PSTN (Public Switched Telephone Network)

[0332] 1500: SIP AS (Application Server)

[0333] 1600: IMS (IP Multimedia Subsystem) network

[0334] 1700, 1702, 1704: SBC (Session Border Controller)

[0335] 1800, 1802: SIP Proxy

[0336] 1900: BTS (Base Transceiver Station) or Node B

[0337] 2000: BSC (Base Station Controller) or RNC (Radio Network Controller)

[0338] 2100: SGSN (Serving GPRS Support Node)

[0339] 2200: GGSN (Gateway GPRS Support Node)

[0340] 2300: Wireless Router

[0341] 2400: DSL (Digital Subscriber Line) Modem

[0342] 2500: DSLAM (Digital Subscriber Line Access Multiplexer)

[0343] 2600: Router; 2700: Backbone Network

Claims

1. A method for predicting call quality, the method predicting the call quality between a first network communication device and a second network communication device, the method comprising: When at least one of the following devices exists in the path through which the communication medium is transmitted between the first network communication device and the second network communication device: a device performing NAT Traversal, a device performing media transcoding, or a device performing Topology Hiding, the overall interval between the first network communication device and the second network communication device is divided into independent intervals defined by the at least one device. For each independent interval, the call quality prediction is performed sequentially by independently executing transmission tests, thereby completing the call quality prediction step between the first network communication device and the second network communication device. In order to predict the call quality between the first network communication device and the second network communication device, no other transmission tests are performed except for the independent execution of transmission tests for the independent intervals.

2. The method for predicting call quality according to claim 1, characterized in that, In the above transmission test, When a NAT device exists within the aforementioned independent interval, a NAT pinhole for the aforementioned address information is pre-generated by utilizing the address information at the two ends of the aforementioned independent interval through communication between the aforementioned independent intervals of the NAT device.

3. The method for predicting call quality according to claim 1, characterized in that, In the above transmission test, N transmission test packets are sent and received sequentially at the two ends of the aforementioned independent interval, and the RTT of each transmission test packet and whether there is any loss in each transmission test packet are confirmed in order to predict the call quality, wherein N is a natural number greater than 2, and RTT is the round-trip time.

4. The method for predicting call quality according to claim 3, characterized in that, Save the predicted call quality based on the packet loss rate and transmission delay time of the above N transmission test packets, so as to determine the call selection for the above first network communication device or the second network communication device.

5. The method for predicting call quality according to claim 4, characterized in that, When the first or second network communication device is composed of multiple VoIP terminals, a specific VoIP terminal is selected for a call based on the predicted call quality of each of the multiple VoIP terminals.

6. The method for predicting call quality according to claim 5, characterized in that, When the communication between the first network communication device and the second network communication device is voice communication, the network telephone terminal that is currently available and has the least transmission time delay is selected as the specific network telephone terminal.

7. The method for predicting call quality according to claim 5, characterized in that, When the communication between the first network communication device and the second network communication device is data communication, the network telephone terminal that is currently available and has the lowest packet loss rate is selected as the specific network telephone terminal.

8. The method for predicting call quality according to claim 1, characterized in that, The call quality predictions for the aforementioned independent intervals are stored in a cache memory and updated after a certain period of time.

9. The method for predicting call quality according to claim 1, characterized in that, When the call quality prediction for a specific independent interval fails, the first network communication device or the second network communication device receives information about the independent interval related to the cause of the failure.

10. The method for predicting call quality according to claim 1, characterized in that, The following information is transmitted: a call quality prediction message transmitted from the first network communication device toward the second network communication device and a call quality prediction response message transmitted from the second network communication device toward the first network communication device. The aforementioned devices performing NAT traversal, media transcoding, and topology hiding record their own address information in the aforementioned call quality prediction message or the aforementioned call quality prediction response message and transmit it. The devices performing NAT traversal, media transcoding, and topology hiding are identified as adjacent to each other to form the aforementioned independent intervals, and call quality is predicted.

11. A method for predicting call quality, the method predicting call quality for a VoIP terminal in an idle state, When a device exists between the aforementioned VoIP terminal and the other party's telephone terminal to perform NAT Traversal for the VoIP terminal, a transmission test is performed on the interval between the VoIP terminal and the device performing NAT Traversal for the VoIP terminal to predict call quality, wherein... The aforementioned interval is the longest distance interval that may become a common media transmission path even if the aforementioned VoIP terminal is connected to any other party. In order to predict the call quality for the aforementioned VoIP terminal, no other transmission tests will be conducted besides the aforementioned transmission tests.

12. The method for predicting call quality according to claim 11, characterized in that, In the above transmission test, When a NAT device exists in the interval between the aforementioned VoIP terminal and the aforementioned device, a NAT pinhole for the aforementioned address information is pre-generated by utilizing the address information at both ends of the interval between the VoIP terminal and the aforementioned device via communication between the VoIP terminal and the aforementioned device through the NAT device.

13. The method for predicting call quality according to claim 11, characterized in that, In the above transmission test, At the two ends of the interval between the aforementioned VoIP terminal and the aforementioned device, N transmission test packets are sequentially sent and received, and the RTT of each transmission test packet and whether there is any loss of each transmission test packet are confirmed in order to predict the aforementioned call quality, wherein the aforementioned N is a natural number greater than 2, and the aforementioned RTT is the round-trip time.

14. The method for predicting call quality according to claim 11, characterized in that, The call quality prediction for the interval between the aforementioned VoIP terminal and the aforementioned device is stored in a cache memory and updated after a certain period of time.

15. A call quality prediction service apparatus that performs a method for predicting the call quality of a VoIP terminal in an idle state, the call quality prediction service apparatus comprising a call quality prediction unit that performs the following processing: When a device exists between the aforementioned VoIP terminal and the other party's telephone terminal to perform NAT Traversal for the VoIP terminal, a transmission test is performed on the interval between the VoIP terminal and the device performing NAT Traversal for the VoIP terminal to predict call quality, wherein... The aforementioned interval is the longest distance interval that may become a common media transmission path even if the aforementioned VoIP terminal is connected to any other party. In order to predict the call quality for the aforementioned VoIP terminal, no other transmission tests will be conducted besides the aforementioned transmission tests.

Images