CN116319709A

CN116319709A - Method for predicting call quality and call quality prediction service device

Info

Publication number: CN116319709A
Application number: CN202310395329.1A
Authority: CN
Inventors: 文炳轸
Original assignee: Individual
Current assignee: Individual
Priority date: 2016-01-25
Filing date: 2017-01-24
Publication date: 2023-06-23
Also published as: KR20170088774A; KR101787348B1; CN108496346A; WO2017131418A1

Abstract

The invention provides a method for predicting call quality and a call quality prediction service device. A method of predicting call quality for predicting call quality between a first network communication device and a second network communication device, the method comprising: when at least one of a NAT transit performing device, a media transcoding performing device, and a Topology performing device exists between the first network communication device and the second network communication device, dividing an entire section between the first network communication device and the second network communication device into independent sections divided by the at least one device, and performing the call quality prediction in sequence for each independent section by performing independent execution of a transmission test, thereby completing the call quality prediction between the first network communication device and the second network communication device.

Description

Method for predicting call quality and call quality prediction service device

The present application is a divisional application of the invention patent application with the application number 201780008163.6 (international application number PCT/KR 2017/000839) of 24 days 1 in 2017, and the invention name of "method for predicting call quality and call quality prediction service device for realizing the method".

Technical Field

The present invention relates to a technology for predicting call quality, and more particularly, to a method for predicting call quality by using a transmission test of a SIP transaction request and a SIP transaction response without an actual call generation process between network communication apparatuses constituting a network telephone network including a network telephone terminal, and a call quality prediction service apparatus for implementing the method.

Background

Recently, old analog and circuit-switched (Circuit Switching) telephones based on digital systems such as SS7 (Signaling System 7) continue to decline, while Packet-switched (Packet Switching) telephones based on IP (Internet Protocol) networks including the SIP protocol have been expanded.

In the network telephone using the SIP protocol in the prior art, compared with the telephone of the circuit switching system in which the actual bandwidth is physically ensured, the communication quality may be reduced due to overload of the terminal or the congestion state of the system and network of intermediate nodes such as L2, L3, L4 switches in the packet switching network.

Korean registered patent No. 10-1011344 relates to a call quality measuring and introducing system for a telephone call service network, and discloses a technique for measuring call quality of a subscriber in a call center and performing voice introduction according to a request of the subscriber, thereby improving customer satisfaction by shortening call waiting time with a call center consultant, reducing consultation telephones of the consultant, thereby saving costs and improving operation efficiency of the consultant of the call center.

To overcome the above problems, an embodiment of the present invention provides a technique for providing a call quality prediction index regarding a plurality of network phone called terminals to a network phone call terminal in the case of being constituted by a plurality of network phone called terminals, so that a specific network phone called terminal having good call quality can be selected.

Disclosure of Invention

Technical problem

An embodiment of the present invention provides a method for predicting call quality in advance before an actual call is made, so that when the predicted call quality falls below a certain reference value, a method for predicting call quality for seeking opportunities for other schemes and a call quality prediction service device for implementing the method can be provided.

An embodiment of the present invention provides a method for predicting call quality by section and managing the predicted call quality by a cache memory within a predetermined end time on an expected path of a medium during a call, thereby avoiding unnecessary prediction operations for sections which are repeated almost simultaneously in a network telephone terminal call quality prediction, and a call quality prediction service device for implementing the method.

An embodiment of the present invention provides a method for predicting call quality by dividing an interval and storing a structure in a cache memory when there is an intermediate node performing media relay in the same environment as an actual call process, so as to prevent a transmission test for call quality prediction from being repeated when intervals overlap in other call quality prediction processes, thereby effectively operating a prediction operation of a network, and a call quality prediction service device implementing the method.

An embodiment of the present invention provides a method for predicting call quality in a network and a call quality prediction service device implementing the same, in which when there is an intermediate node performing media relay in the same environment as an actual call process, call quality is predicted between partitions and a structure is stored in a cache memory, so that when the partitions overlap in other call quality prediction processes, a transmission test for call quality prediction is prevented from being repeated, thereby effectively operating the predicted call quality of the network.

An embodiment of the present invention provides a method for predicting call quality by checking the integrity of original data in order to cope with the possibility of packet damage when a wireless section exists, and a call quality prediction service device for implementing the method, wherein after an RTP/RTCP media flow or a camouflage UDP flow, which is independent of whether the actual media for call is included, is generated according to the section of media transmission between a network telephone terminal and a network telephone server or between terminals connected to the actual call, the RTT (Round Trip Time) and packet loss rates of each packet are calculated.

An embodiment of the present invention provides a method for predicting call quality, which may be included in Presence information of a subscriber and utilize a SIP Event notification system, or may provide a call quality state through a SIP AS linked with an HTTP server or the like, and a call quality prediction service device for implementing the method.

Means for solving the problems

In an embodiment, a method for predicting call quality of a party performed at a party of first and second network communication devices, includes: (a) Optionally, the method includes a step of transmitting a SIP (Session Initiation Protocol) transaction request including a call quality prediction request to the other party, the address information (IP address, port number) of the one party being used for the call quality prediction of the one party; (b) A step of receiving a SIP transaction response including address information (IP address, port number) of the counterpart from the counterpart in response to the SIP transaction request; (c) Using 1) RTP packets which are independent of the inclusion of real media by the address information of one party and the address information of the other party; 2) RTCP packets; or 3) a step of performing a transmission test with the counterpart to predict a call quality for communication of a dummy UDP packet (hereinafter referred to as a "transmission test packet") in which the counterpart masquerades as RTP; and (d) or after the step (a), the pair Fang Li first performs the step (c) with the address of the party to obtain a call quality prediction result, and then includes the result in the SIP transaction response and transmits the result to the party.

In one embodiment, the step (c) may include a step of generating a NAT Pinhole (Pinhole) for the address information in advance by using the address information between the one and the other via communication between the two parties of the NAT device when the one and the other are connected by the NAT device.

In one embodiment, the step (c) may include the steps of sequentially transmitting N (N is a natural number greater than 2) of the transmission test packets to the one party or the other party, and confirming RTT (Round Trip Time) of each and loss of each to predict the call quality.

In one embodiment, the method for predicting call quality may further include (e) storing predicted call quality based on the packet loss rate and the transmission delay time predictions for the N transmission test packets to determine call selection for the counterpart.

In one embodiment, the step (e) may include a step of selecting a specific network phone terminal to perform a call based on a predicted call quality for each of the plurality of network phone terminals when the counterpart is composed of the plurality of network phone terminals.

In one embodiment, the step (e) may further include a step of selecting a network telephone terminal currently available and having a minimum transmission time delay as the network telephone terminal when the communication between the one party and the other party belongs to voice communication.

In an embodiment, the step (e) may further include a step of selecting a network telephone terminal currently available and having a minimum packet loss rate as the network telephone terminal when the communication between the one party and the other party belongs to data communication.

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

In one embodiment, the step (e) may include the step of saving a call quality prediction for the relay zone in a cache memory and updating the cache memory when a specific time is exceeded.

In one embodiment, the step (e) may further include a step of receiving a SIP transaction response including information about the call quality prediction means related to the cause of the failure when the call quality prediction for the specific relay zone fails.

In an embodiment, a method performed in a network telephony server or SBC without a call generation process to predict call quality to a plurality of network telephony terminals, comprises: (a) For the section between the IP phone server or SBC and the IP phone terminal, by using 1) RTP packets independent of the inclusion or non-inclusion of the actual media; 2) RTCP packets; or 3) a step of performing a transmission test with each of the plurality of network telephone terminals to predict a call quality for communication of a dummy UDP packet (hereinafter referred to as a "transmission test packet") in which the partner masquerades as RTP; and (b) providing the predicted result of the call quality to the call partner or performing information provision or connection attempt to the network telephone terminal available with the most excellent call quality based on the prediction of the respective call quality.

In an embodiment, a call quality prediction service device that performs a method of predicting call quality of a party, which is performed by a party of first and second network communication devices, includes: a SIP transaction request unit that may optionally include address information (IP address, port number) of the party for use in prediction of the call quality of the party, and that transmits a SIP (Session Initiation Protocol) transaction request including a call quality prediction request to the party; a SIP transaction response receiving unit that receives a SIP transaction response including address information (IP address, port number) of the counterpart from the counterpart in response to the SIP transaction request;

a call quality prediction unit that uses 1) an RTP packet that is independent of whether or not an actual medium is contained, based on the address information of the one party and the address information of the other party; 2) RTCP packets; or 3) performing a transmission test with the counterpart to predict call quality for communication of a disguised UDP packet (hereinafter referred to as a "transmission test packet") disguised as RTP by the counterpart; a SIP transaction response transmission unit configured to transmit the SIP transaction to the other party, wherein the pair Fang Li first predicts the call quality by using the address of the one party to obtain a call quality prediction result, and then includes the result in the SIP transaction response to the one party; and a call selection determination unit configured to store predicted call quality based on the packet loss rates and the transmission delay times of the N transmission test packets, and determine a call selection for the partner.

Effects of the invention

The technique disclosed above has the following effects. It is not intended that the particular embodiments include all or only the following effects and, as such, the scope of the claims of the disclosed technology is not so limited.

The method for predicting call quality and the call quality prediction service device for implementing the method according to an embodiment of the invention predict call quality in advance before actual call is performed, so that when the predicted call quality drops below a certain reference value, the predicted call quality of the opportunity of seeking other schemes can be provided

The method for predicting call quality and the call quality prediction service device for implementing the method according to an embodiment of the present invention predict call quality in intervals on an expected path of a medium and manage the predicted call quality in a predetermined end time through a cache memory during a call, thereby avoiding unnecessary prediction operations for almost simultaneously repeated intervals in the prediction of call quality of a network telephone terminal

The method for predicting call quality and the call quality prediction service device for implementing the method according to an embodiment of the present invention predict call quality between partitions and store a structure in a cache memory when there is an intermediate node performing media relay in the same environment as an actual call process, so as to prevent a transmission test for call quality prediction from being repeated when the partitions overlap in other call quality prediction processes, thereby effectively operating a prediction operation of a network.

The method for predicting call quality and the call quality prediction service device for implementing the method according to an embodiment of the present invention predict call quality between partitions and store a structure in a cache memory when there is an intermediate node performing media relay in the same environment as an actual call process, so as to prevent a transmission test for call quality prediction from being repeated when the partitions overlap in other call quality prediction processes, thereby effectively operating the predicted call quality of the network.

According to the method for predicting call quality and the call quality prediction service device for realizing the method, according to the interval of media transmission, RTP/RTCP media flow or disguised UDP flow which is irrelevant to the inclusion of the actual media for call is generated between a network telephone terminal and a network telephone server or between terminals connected with the actual call, then RTT (Round Trip Time) of each packet and packet loss rate are calculated, and when a wireless interval exists, the integrity of original data is checked for coping with the possibility of packet damage.

The method for predicting call quality and the call quality prediction service device for implementing the method according to an embodiment of the present invention may be included in Presence information of a subscriber to provide a call quality status by using a SIP Event notification system or by using a SIP AS linked with an HTTP server or the like.

Drawings

FIG. 1 is a diagram illustrating a call quality prediction system according to an embodiment of the present invention;

fig. 2 is a schematic diagram illustrating the construction of a call quality prediction service device;

fig. 3 is a schematic diagram illustrating a procedure of a transmission trial session for generating a request of a web telephony server and for prediction of call quality between a call quality prediction server and an arbitrary web telephony terminal;

FIG. 4 is a schematic diagram illustrating a process of generating a request by a web telephony server and a transmission trial session for prediction of call quality between the web telephony server and any web telephony terminal;

fig. 5 is a schematic diagram illustrating a procedure of a transmission trial session for generating a request of a network telephone terminal and for prediction of call quality between a call quality prediction server and an arbitrary network telephone terminal;

FIG. 6 is a schematic diagram illustrating a process of generating a request for a network telephony terminal and a transmission trial session for prediction of call quality between a network telephony server and any network telephony terminal;

fig. 7 to 12 are diagrams illustrating a process of predicting call quality between arbitrary network telephone terminals;

FIG. 13 is a diagram comparing UDP packets of an embodiment of the present invention;

Fig. 14 is a schematic diagram illustrating in detail the relationship between a network telephony terminal and a network telephony server or SBC;

fig. 15 is a sequence diagram illustrating a process of predicting call quality of a counterpart according to an embodiment of the present invention;

fig. 16 is a sequence diagram illustrating a process of predicting call quality to a plurality of network telephony terminals without a call generation process in accordance with another embodiment of the present invention.

Detailed Description

The disclosure is merely illustrative of structural or functional embodiments and, therefore, the scope of the claims directed to the disclosed technology should not be limited to the embodiments described herein. That is, the embodiments may be variously modified and have various forms, and thus the scope of the claims of the disclosed technology should include equivalents that can realize the technical idea. Specific embodiments of the invention need not include all or only the following active effects of the objects described above, and thus the scope of the claims of the disclosed technology is not so limited.

In addition, the terms used in the present invention should be understood as follows.

The terms "first," "second," and the like are used to distinguish one element from another element, but the scope of the claims is not limited by the terms. For example, the first component may be named as a second component, and similarly, the second component may be named as a first component.

One structure "connected" or "coupled" to another structure means directly connected or coupled to the other structure or connected or coupled through the other structure. In contrast, a structure that is "directly connected" to another structure means that there are no other structures in between. Other descriptions describing relationships between structures, such as "between … …" and "between … …" or "adjacent … …" and "meet … …" and the like, are also equally intended.

Where no clear distinction is made in the context, singular references include plural references, "comprise" or "have" and the like, meaning that the presence of a stated feature, number, step, action, structure, element, or combination thereof in the specification, does not preclude the presence or addition of one or more other features, numbers, steps, actions, structures, elements, or combinations thereof.

In each step, the identification symbols (e.g., a, b, c, etc.) are used for convenience of description, the identification symbols do not describe the order of each step, and each step may be performed in a different order from the order described unless a specific order is explicitly described in the text. That is, the steps may be performed in the order described, may be performed substantially simultaneously, or may be performed in the reverse order.

The present invention can be realized in computer-readable codes on a computer-readable recording medium including all kinds of recording apparatuses that hold data readable by a computer system. Examples of the computer readable recording medium include ROM, RAM, CD-ROM, magnetic disk, floppy disk, and optical data storage device.

Unless specifically defined otherwise, 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 belongs. Terms commonly used as terms defined in dictionaries have the same meaning as in the context of the relevant art and are not intended to have an ideal or excessive meaning in the present application unless explicitly defined.

Fig. 1 is a schematic diagram illustrating a call quality prediction system according to an embodiment of the present invention.

As shown in fig. 1, 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 network telephone terminal 100 and a network telephone server 200. These may be connected via a network.

The call quality prediction service device 20 is executed by one of the network telephone terminal 100 and the network telephone server 200, and can predict the call quality of the other party. More specifically, the call quality prediction service device 20 may predict the call quality between the network telephone terminal 100 and the network telephone server 200, the network telephone terminal 100 and the call quality prediction server 300, or the network telephone terminal 100.

The internet phone terminal 100 may be owned by a user, and may be a computing device connected to the internet phone server 200 and the call quality prediction server 300. For example, the network telephony terminal 100 may be implemented by a smart phone or the like, but is not limited thereto.

Any network telephone call terminal or call terminal 102, 106, 110, 114, 116, 120, network telephone called terminal or called terminal 104, 108, 112, 118, 122 belongs to a network telephone terminal.

The call quality prediction server 300 serves to reduce the burden of transmission trials from the internet phone server 200 that can perform SIP call processing. Here, call processing refers to a process of controlling and monitoring all states of call generation to end to ensure completion of a normal call. The call quality prediction server 300 may be a general server which is not directly related to the SIP network, and may be connected to the internet phone terminal 100 at IP (Internet Protocol) to exchange information by being linked to the internet phone server 200.

First, a transmission test for predicting call quality in different relay zones will be described.

The transmission test of the session quality prediction interval may also be performed using the actual RTP/RTC packets containing media playable as a real-time session. In a specific section, both parties can predict call quality by using a method of receiving and transmitting RTP/RCTP packets simultaneously and calculating RTT (Round Trip Time) and packet loss through RTCP packets, both parties share results to calculate a prediction result of bidirectional call quality, or a method of generating RTP packets by using a specific main body and transmitting the RTP packets to the counterpart in the section, then receiving and immediately retransmitting the RTP packets by the counterpart, and calculating RTT and packet loss of each RTP packet by the corresponding main body.

It is also possible to predict call quality by transmitting RTP packets containing no real media but transmission time information on the transmission side or even no header, UDP packets having the same IP packet size and transmission interval as those of RTP packets, containing transmission time information on the transmission side, and immediately obtaining retransmission from the counterpart in a way of calculated RTT and packet loss.

The method can be divided into a case where transmission test is performed simultaneously with one another and a case where the transmission test packet is transmitted first by one side master in a call quality prediction section, and when the transmission test packet is transmitted first by one side master, both sides do not need to know the address of the other side, and the transmission is performed first by one side, and then the receiving side performs reverse transmission with reference to the originating address of the IP packet.

Therefore, since the transmission test can be performed easily and simultaneously with each other by the case where the partner address is acquired by the one-side master, the following description will mainly be made mainly of the case where the one-side master.

Fig. 2 is a schematic diagram illustrating the structure of the call quality prediction service device.

As shown in fig. 2, 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 transmitting unit 24, a call selection determining unit 25, and a control unit 26.

The SIP transaction requesting unit 21 may optionally include address information (IP address, port number) of the party for use in the prediction of the call quality of the party, and may transmit SIP (Session Initiation Protocol) including the call quality prediction request to the party. For example, the SIP transaction requesting section 21 may transmit a SIP transaction request including the call quality prediction request information to the network telephone terminal 100. For another example, the SIP transaction requesting section 21 may transmit a SIP transaction request including the call quality prediction request information to the web telephony server 200.

In an embodiment, when there is a NAT device between the network telephone terminal 100 and a plurality of servers (the network telephone server 200 or the call quality prediction server 300), the SIP transaction request section 21 may transmit address information including the network telephone server 200 or the call quality prediction server 300 to the network telephone terminal 100 in a SIP transaction request for generating a transmission trial session, and the network telephone terminal 100 may transmit a NAP pinhole packet for generating a NAT pinhole to the network telephone server 200 or the call quality prediction server 300 through the received address information of the network telephone server 200 or the call quality prediction server 300.

The SIP transaction response receiving section 22 may receive the SIP transaction response. More specifically, the SIP transaction response receiving section 22 receives a SIP transaction response containing address information (IP address, port number) of the counterpart from the counterpart in response to the SIP transaction request. In an embodiment, the SIP transaction response receiving section 22 may receive a SIP transaction response from the network telephone terminal 100 as a response to the SIP transaction request. For example, as a response to the SIP transaction request, the SIP transaction response receiving section 22 may receive address information including Port information newly allocated for transmission trials.

The call quality prediction unit 23 uses 1) an RTP packet that is independent of whether or not the actual medium is included, by using address information of one party and address information of the other party; 2) RTCP packets; or 3) performing a transmission test with the counterpart to predict the call quality for communication of a disguised UDP packet (hereinafter referred to as a "transmission test packet") disguised as RTP by the counterpart.

When one party and the other party are connected by the NAT device, the call quality prediction unit 23 can generate a NAT Pinhole (Pinhole) for the address information in advance by using the address information between the two parties through communication between the two parties of the NAT device.

For example, the internet protocol phone server 200 or the call quality prediction server 300 may use the address of the internet protocol phone terminal 100 obtained by the SIP transaction response receiving unit 22 to perform a transmission test on the internet protocol phone terminal 100 and the call quality prediction target codec by generating an RTP or a UDP packet masquerading as an RTP that does not include an actual RTP/RTCP or an actual media, so as to predict the call quality.

For another example, the network telephone terminal 100 may use the address of the network telephone server 200 obtained by the SIP transaction response receiving unit 22 to perform a transmission test on the codec to be the target of the call quality prediction using RTP that does not include real RTP/RTCP or real media or UDP packets masquerading as RTP to predict the call quality.

That is, when NAT transit exists between the network telephone terminal 100 and each server (network telephone server 200 or call quality prediction server 300), address information of the network telephone server 200 or call quality prediction server 300 for generating a transmission test session is included in a SIP transaction request transmitted from the network telephone server 200 to the network telephone terminal 100, and after the network telephone terminal 100 transmits a packet for generating a NAT Pinhole (Pinhole) to an address of the network telephone server 200 or call quality prediction server 300 obtained from the SIP transaction request, the network telephone server 200 or call quality server 300 can perform a transmission test on the network telephone terminal 100 and a call quality prediction object codec by generating an RTP or a UDP packet disguised as RTP that does not include an actual RTP/RTCP, using the NAT Pinhole (Pinhole) to predict call quality.

At this time, before the execution between the network telephone terminal 100 and the network telephone server 200 or between the network telephone terminal 100 and the call quality prediction server 300, the SIP authentication of the network telephone terminal 100 may be executed, the call quality prediction may be abandoned when the authentication fails, and the transmission test may be executed when the authentication succeeds.

In an embodiment, the call quality prediction section 23 may generate a UDP packet masquerading as RTP based on the address information and the port information of the network telephone terminal 100, and perform a transmission test by the generated UDP packet to predict the call quality to the network telephone terminal 100. Here, the plurality of dummy UDP packets may include the same size, transmission interval, and transmission time data as RTP.

The call quality prediction unit 23 may transmit N (N is a natural number greater than 2) transmission test packets to one or the other, and may determine RTT (Round Trip Time) and loss of each to predict call quality.

The call quality prediction unit 23 can predict the call quality of the partner by confirming RTT (Round Trip Time) of each of the generated dummy UDP packets and whether or not each of the packets is lost to the corresponding packet. The call quality prediction unit 23 may calculate RTT values based on the reception time of each of the dummy UDP data and the transmission time recorded in the dummy UDP data, and predict the call quality of the partner by calculating the number of missing RTP data and the deviation (i.e., the degree of deviation) of RTTs of all RT packets from the average and RTT values.

In one embodiment, the call quality prediction unit 23 may generate N consecutive plural disguised UDP packets for transmission to the network telephone terminal 100, and the network telephone terminal 100 may receive the plural disguised UDP packets and simultaneously retransmit the plural disguised UDP packets to the call quality prediction unit 23. The call quality prediction unit 23 checks the RTT value and the reciprocation loss of each of the plurality of dummy UDP packets by the retransmission process to predict the call quality of the network telephone terminal 100 as the opposite party.

The call quality prediction unit 23 is executed in the network telephone server 200 or SBC, and when the call generation process is not required to predict the call quality to a plurality of network telephone terminals, can use 1) RTP packets which are independent of the inclusion or non-inclusion of the actual media for the section between the network telephone server or SBC and the network telephone terminals; 2) RTCP packets; or 3) performing a transmission test with each of the plurality of network telephone terminals for communication of a masquerading UDP packet (hereinafter referred to as a "transmission test packet") masquerading as RTP to the counterpart to predict the call quality.

The SIP transaction response transmitting unit 24 transmits the result to the party by first performing the call quality predicting unit (i.e., step (c)) using the address of the party to obtain the call quality predicting result, or by performing the SIP transaction requesting unit 21 (i.e., step (a)) and then including the result in the SIP transaction response.

The call selection determination unit may store predicted call quality based on the packet loss rate and the transmission delay time predictions for the N transmission test packets, and determine the call selection for the partner.

When the counterpart is constituted by a plurality of network telephone terminals 100, the call selection determination unit 25 selects a specific network telephone terminal to perform a call based on the predicted call quality for each of the plurality of network telephone terminals.

In one embodiment, the call selection decision section 25 selects, as the network telephone terminal, a network telephone terminal that can be currently used and has the smallest transmission time delay when communication between one party and the other party belongs to voice communication. In another embodiment, the call selection decision section 24 selects, as the network telephone terminal, a network telephone terminal that can be currently used and has the smallest packet loss rate when communication between one party and the other party belongs to data communication.

When at least one media relay device that performs media relay is present in the relay device between the first and second network communication devices, the call selection determination unit 25 sequentially completes the above-described call quality prediction steps by performing a SIP transaction request to a SIP transaction response or performing a call quality prediction alone in the relay section 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").

For example, the first and the first network communication devices (or call terminals) automatically set the last call quality prediction section boundary, and the SIP transaction request transmitted to the network telephony server 200 to which the first and the first network communication devices belong includes the second network communication device (or call quality prediction target called terminal) information to transmit call quality prediction request information.

Second, in the process of transferring the SIP transaction request to the second network communication device, if the SIP network component does not perform media relay by itself, the SIP transaction request is transferred to the next destination as it is, and if media relay is performed, the SIP transaction request including the information in which the address of the SIP transaction request is set as the last call quality prediction section boundary and the transmission trial for call quality prediction is performed while the last call quality prediction section boundary included in the SIP transaction request and the transmission trial for call quality prediction are performed, or after the transmission trial for call quality prediction is performed, the SIP transaction request including the call quality prediction result and the information in which the address of the SIP transaction request is set as the last call quality prediction section boundary is transferred to the next destination.

Third, if the SIP transaction request arrives at the called-side network telephony server, the called-side network telephony server performs media relay, and after performing the last call quality prediction section boundary included in the SIP transaction request and the transmission test for call quality prediction, and further performing the transmission test for prediction of call quality between the called-side network telephony server and the second network communication device, the SIP transaction request including the two prediction results transmits a SIP transaction response to the first network communication device, or the SIP transaction request including the information in which the address of the SIP transaction request is set to the last call quality prediction section boundary is transmitted to the second network communication device while performing the last call quality prediction section boundary included in the SIP transaction request and the transmission test for call quality prediction, or the SIP transaction request including the call quality prediction result and the information in which the address of the SIP transaction request is set to the last call quality prediction section boundary is transmitted to the second network communication device.

The fourth and second network communication devices are automatically set as a call quality prediction section boundary, and when the SIP transaction request reaches the second network communication device, after the last call quality prediction section boundary recorded in the SIP transaction request and a transmission test for predicting call quality are performed, the inclusion result transmits the SIP transaction response to the first network communication device, and when the SIP network component as the call quality prediction section boundary does not include the call quality prediction result in the SIP transaction request, the inclusion result may be included in the SIP transaction response.

The call selection determination unit 25 may store the call quality prediction for the relay zone in the cache memory and update the cache memory when a specific time is exceeded. For example, the SIP network component as the boundary of the session quality prediction section may refer to the session quality prediction result or the SIP transaction response performed by itself, and save the session quality prediction result of itself and other SIP network components as the boundary of the session quality prediction section in the cache memory to manage, so as to avoid repeated transmission tests when there is a repeated session quality prediction request within the end time of the cache memory.

When the call quality prediction for a specific relay zone fails, the call selection determination unit 25 receives a SIP transaction response including information about the call quality prediction device regarding the cause of the failure. For example, when the SIP network component cannot continue to predict the call quality due to policy or technical reasons during the transmission of the SIP transaction request to the second network communication device, the call selection determination unit 25 transmits the SIP transaction response to the first network communication device, if necessary, including the call quality prediction result for each section so far and including information or failure cause that sets itself as the failure point of the call quality prediction.

In addition, the call selection decision unit 25 provides the prediction result of the call quality to the call partner or performs information provision or connection attempt to the network telephone terminal available with the most excellent call quality based on the prediction of the respective call quality.

For example, with respect to the call quality between the network telephone terminal 100 and the network telephone server 200, the network telephone server 200 predicts the call quality by generating an RTP packet which does not contain an actual RTP/RTCP or an actual media or a UDP packet which is disguised as RTP, calculating a packet loss rate, a transmission delay value, and storing the information by directly using a registered address of the network telephone terminal 100 without a call generation process or generating another transmission test session for call quality prediction, and then transfers the call quality prediction information of the network telephone terminal 100 to the counterpart so that the counterpart refers to before the actual call connection or so that the counterpart selects a network telephone terminal having a good call quality when there are a plurality of network telephone terminals which can achieve the same purpose.

The control unit 26 controls the overall operation of the call quality prediction service device, and controls the control flow and 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 transmitting unit 24, and the call selection determining unit 25.

Fig. 3 is a schematic diagram illustrating a procedure of a transmission trial session for generating a request of a web telephony server and for prediction of call quality between a call quality prediction server and an arbitrary web telephony terminal.

More specifically, any of the network telephone terminals 100 in fig. 3 may perform SIP registration (or SIP REGISTER) with the network telephone server 200 to be in a state where a call can be made, and the network telephone server 200 may request generation of a transmission trial session prediction call quality for call quality prediction from the call quality prediction server 300 and the network telephone terminal 100.

In the process of (1) of fig. 3, the network telephony terminal 100 may request SIP registration from the network telephony server 200. More specifically, the network telephone terminal 100 may generate SIP REGISTER a message for requesting SIP registration and perform SIP registration through the generated SIP REGISTER message. At this time, SIP registration with the network telephone terminal 100 is performed by means such as a Shared Secret (Shared Secret) including an account (ID) and a Password (Password).

The network telephony terminal 100 may transmit an initial SIP REGISTER message, which does not include authentication information, to the network telephony server 200 requesting SIP registration, and the network telephony server 200 may transmit a 401Unauthorized answer, which includes authentication information, to the network telephony terminal 100. Here, the authentication information may include an authentication method, an authentication algorithm, an area defining an account (ID) and a Password (Password), a nonce value, and the like.

The internet phone terminal 100 can confirm the authentication information in the 401Unauthorized reply transmitted from the internet phone server 200 in accordance with the calculated Message Digest (Message Digest) required by the internet phone server 200. Here, a Message Digest (Message Digest) refers to repeatedly applying a one-way hash function to a Message of an arbitrary length, thereby reducing to a bit string of a fixed length.

The network telephony terminal 100 may transmit a second SIP REGISTER Message containing the calculated Message Digest to the network telephony server 200. Web telephony server 200 may calculate a message digest using the same method as that of web telephony terminal 100. After computing the message digest, web telephony server 200 may compare its own computed message digest result with the message digest result contained in the second SIP REGISTER message.

In one embodiment, the network telephony server 200 ends the SIP authentication of the network telephony terminal 100 when the result of the message digest calculated by itself is the same as the result of the message digest included in the second SIP REGISTER message. After finishing the SIP authentication of the network telephone terminal 100, the network telephone server 200 transmits a 200Ok message to the network telephone terminal 100, and successfully performs SIP registration of the network telephone terminal 100 using the REGISTER message.

In another embodiment, when the result of the message digest calculated by the web phone server 200 is not the same as the result of the message digest included in the second SIP REGISTER message, the SIP authentication of the web phone terminal 100 cannot be ended, and the SIP authentication of the web phone terminal 100 fails. At this time, the network phone server 200 may transmit an error response such as 403Forbidden (Bad auth) to the network phone terminal 100, prompting a SIP registration failure.

In the process (2) of fig. 3, the web telephony server 200 may request the web telephony terminal 100 to generate a transmission trial session for call quality prediction, and it is assumed hereinafter that SIP OPTIONS, which is a representative Dialog-Out message of SIP, is used, but not limited thereto.

Here, the SIP OPTIONS message belongs to a SIP message for requesting a query for the current Capability (Capability) of a component of the SIP network such as a User Agent (UA) or Proxy Server, registry, redirect Server, etc., and the component of the SIP network may provide information such as a type of SIP message which can be processed by itself or an interpretable language or a type of SIP message Body which can be processed in a response to the SIP OPTIONS message. However, in addition to the inquiry and response to the capabilities of the SIP network components, the SIP network component is currently used for applications such as Ping commands of the IP network for confirming whether the SIP network components are currently operating normally.

In addition to the standardized header in the basic protocol, SIP messages may use, as a method of adding new functions or properties, a non-standard header starting with X-with the meaning of (eXperimental) or (eXtension) of a trial.

The web phone server 200 transmits a SIP OPTIONS message to the web phone terminal 100 by adding a header (header) such as X-Quality-Test using the feature of using a non-standard header starting with X-, and requests generation of a transmission Test session for call Quality prediction.

The header of the X-Quality-Test may be configured as follows.

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

Here, request is a call quality prediction Request, aservadd is an address of the call quality prediction server 300 for voice, vservadd is an address of the call quality prediction server 300 for video, method set to digest means that an authentication method by a message digest method is used, nonce is a random value to be included in hash value calculation, algorithm is a hash algorithm, real is an area (conventionally multi-purpose server name) defining ID and Password, acode is a codec for voice using a ulaw codec and vcodec is a codec for video using a h263 codec.

In the above example (form of header of X-Quality-Test), only codec names are used for the sake of brevity. Taking the h.264 codec as an example, in order to accurately know the data transmission rate according to different codecs, detailed information such as Profile and Level is further included to be transmitted, so as to \calculate the number of frames per second (frames) or the size of the frames.

The address (aservaddr, vservaddr) of the call quality prediction server 300 for voice or video is an address for generating a transmission trial session for call quality prediction, and may be decided by the internet phone server 200 and the call quality prediction server 300 through additional process negotiations.

The internet phone server 200 may add a body to the SIP message to transmit request information for call quality prediction, in addition to the method of adding a new header to the SIP message.

For example, a header such as Content-Type application/call-quality-test may be added to the above SIP OPTIONS message, and the Content body may include the following SIP OPTIONS message.

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"

In the process of (2) of fig. 3, the header of the X-Quality-Test of the SIP 200Ok message is as follows:

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

the web telephony terminal 100 may transmit the message digest calculation result to the web telephony server, contained in the response field of the X-Quality-Test header. Message digest computation of the network telephony terminal 100 may calculate A1, nonce, and A2, respectively, and apply the hash algorithm again to A1, nonce, and A2 for cost effectiveness.

Here, A1 is a result of calculating a message digest by applying a hash algorithm to ID, password, realm recorded in the username field, and A2 is a result of calculating a message digest by applying a hash algorithm to "OPTIONS" of the SIP OPTIONS message and a request uri of the SIP OPTIONS message.

Web telephony server 200 may perform authentication of web telephony terminal 100 by comparing the message digest value calculated by itself with the message digest value transmitted from web telephony terminal 100.

In the process (3) of fig. 3, when authentication of the network telephony terminal 100 is successful, the network telephony server 200 may transmit 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 image for the call quality prediction server 300 transmitted to the internet protocol terminal 100, and the message digest value calculated by the internet protocol server 200 itself in the process of (2). If authentication of the network telephony terminal 100 fails in the process (2) of fig. 3, the call quality prediction may be immediately ended.

In the process (4) of fig. 3, the network telephony terminal 100 may generate a NAT Pinhole (Pinhole) for a transmission test between the network telephony terminal 100 and the call quality prediction server 300 by transmitting a packet containing authentication information to the call quality prediction server 300.

More specifically, the network telephone terminal 100 may allocate any own two ports other than ports for SIP message transmission and reception (for example, allocate 5060 when defaults are used in SIP messages), transmit a packet to the address of the call quality prediction server 300 obtained by the transmission in the process (2) of fig. 3, and transmit the message digest value calculated in the process (2) of fig. 3 to the call quality prediction server 300 as it is contained in the packet.

Call quality prediction server 300 may compare the message digest received from web telephony server 200 with the message digest received from web telephony terminal 100. In one embodiment, when the message digest comparison result is the same, the session quality prediction server 300 succeeds in the SIP authentication of the network telephony terminal 100, and then the process (5) may be continued. In another embodiment, when the message digest comparison results are different, the session quality prediction server 300 fails in SIP authentication of the network telephony terminal 100, and the entire session quality prediction process fails.

In the process (5) of fig. 3, the call quality prediction server 300 may perform a transmission test for call quality prediction by recording Source IP and Source Port numbers in the IP header of the packet received through the process (4) of fig. 3 as destinations. The transmission trial session generated in the above procedure can cope with NAT (Network Address Translation) of all four modes, here, full Cone, reserved Cone, port Restricted Cone, symmetry NAT.

In fig. 2, if there is no NAT transit between the network telephone terminal 100 and the network telephone server 200 and call quality prediction server 300, the network telephone server 200 may check whether the authentication of the network telephone terminal 100 is successful or not in the process (2) of fig. 3.

In one embodiment, when authentication is successful, the network telephony server 200 may additionally transmit address information (the client field of the X-Quality-Test header) of the network telephony terminal 100 obtained in the (2) process through the (3) process of fig. 3, and the call Quality prediction server 300 directly performs the (5) process to predict the call Quality without the process of generating the NAT Pinhole (Pinhole) of the (4) process of fig. 3.

For example, if there is no NAT transit between the network telephone terminal 100 and the call quality prediction server 300, a process of generating a NAT Pinhole (Pinhole) is not required, and therefore, in the process (2) of fig. 3, the address of the call quality prediction server 300 is not necessarily included in the SIP OPTIONS message.

For another example, if there is a NAT transit between the network telephone terminal 100 and the call quality prediction server 300, the call quality prediction server 300 performs a transmission test based on a NAT Pinhole (Pinhole), and in the process (2) of fig. 3, it is not necessary to include the address of the network telephone terminal 100 in the SIP 200Ok message.

That is, the network telephone terminal 100 becomes a state in which a call can be made after SIP registration with the network telephone server 200 is completed, and the network telephone server 200 can request generation of a transmission trial session prediction call quality for call quality prediction from the call quality prediction server 300 and the network telephone terminal 100.

Fig. 4 is a schematic diagram illustrating a process of generating a request for a web telephony server and a transmission trial session for prediction of call quality between the web telephony server and any web telephony terminal. More specifically, fig. 4 is a schematic diagram illustrating a process of directly performing call quality prediction by the web telephony server 200 without using the call quality server 300.

In the process of (1) of fig. 4, the network telephony terminal 100 may request SIP registration from the network telephony server 200. More specifically, the network telephone terminal 100 may generate SIP REGISTER a message for requesting SIP registration and perform SIP registration through the generated SIP REGISTER message. At this time, SIP registration with the network telephone terminal 100 is performed by a method such as Shared Secret key (Shared Secret).

In the process (2) of fig. 4, the network telephony server 200 may request the network telephony terminal 100 to generate a transmission trial session for call quality prediction. At this time, the process (2) of fig. 4 is the same except that in the process (2) of fig. 3, aservaddr, vservaddr of the X-Quality-Test header is set to the internet phone server 200 itself indicating the address of the non-call Quality prediction server 300.

Fig. 4 does not perform the process (3) of fig. 3 because the call quality prediction server 300 is not used. In the process (3) of fig. 4, as in the process (4) of fig. 3, the network telephony terminal 100 may perform authentication by transmitting a packet containing authentication information to the network telephony server 200 to generate a NAT Pinhole (Pinhole) for a transmission experiment.

In the process (4) of fig. 4, the web telephony server 200 may perform a transmission test for call quality prediction by including Source IP and Source Port numbers in the IP header of the packet received through the process (3) of fig. 4 as destinations. The transmission trial session generated in the above procedure can cope with NAT (Network Address Translation) of all four modes, here, full Cone, reserved Cone, port Restricted Cone, symmetry NAT.

If there is no NAT transit between the network telephone terminal 100 and the network telephone server 200, the network telephone server 200 may check whether the authentication of the network telephone terminal 100 is successful or not in the process (2) of fig. 4. In an embodiment, if authentication is null, the network telephony server 200 may directly perform the next process to predict call quality without generating a NAT Pinhole (Pinhole) in the network telephony terminal 100. For example, the network telephone terminal 100 included in the SIP 200Ok message may directly perform the transmission test without the process (3) of fig. 4 using Port information allocated for the call quality prediction transmission test.

That is, the network telephone terminal 100 becomes a state in which a call can be made after SIP registration with the network telephone server 200 is completed, and the network telephone server 200 can request the network telephone terminal 100 to generate a transmission trial session prediction call quality for call quality prediction.

Fig. 5 is a schematic diagram illustrating a procedure of a transmission trial session for generating a request of a network telephone terminal and for prediction of call quality between a call quality prediction server and an arbitrary network telephone terminal. More specifically, fig. 5 is a schematic diagram illustrating a process of requesting and directly performing call quality prediction by the network telephone terminal 100.

In the process of (1) of fig. 5, the network telephony terminal 100 may request SIP registration from the network telephony server 200. More specifically, the network telephone terminal 100 may generate SIP REGISTER a message for requesting SIP registration and perform SIP registration through the generated SIP REGISTER message. Here, the SIP registration procedure of the network telephone terminal 100 is the same as the (1) procedure of fig. 3 and 4.

In the process (2) of fig. 5, the network telephony terminal 100 may request the network telephony server 200 to generate a transmission trial session for call quality prediction. More specifically, as shown in fig. 3 and 4, the telephone terminal 100 may use SIP OPTIONS.

The header of the X-Quality-Test may be configured as follows.

X-Quality-Test:Request acodec＝"ulaw",vcodec＝"h263"

Here, the Request is a call quality prediction Request, and each of acodec and vcodec is a speech and video codec.

Other information for the transmission Test may be contained in the X-Quality-Test header of the SIP 200Ok response message transmitted by the web telephony server 200 as a response to the SIP OPTIONS in the following form.

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"

Here, the Request is a response to the call quality prediction Request, aservadd is an address of the call quality prediction server 300 for voice, vservadd is an address of the call quality prediction server 300 for video, the method set to digest means that an authentication method by the message digest method is used, nonce is a random value to be included in the hash value calculation, algorithm is a hash algorithm, real is an area defining an ID and a channel, acode is a codec for voice using a ulaw codec and vcodec is a codec for video using an h263 codec.

The internet phone server 200 may perform the SIP authentication of the internet phone terminal 100 after the completion of the SIP authentication including 401Unauthorized in the process (2) of fig. 5, as in the SIP registration request process using SIP REGISTER in the process (1). Only because the call quality prediction is performed by the call quality prediction server 300, it is omitted in fig. 5.

In the process (3) of fig. 5, the web telephony server 200 may be performed as in the process (3) of fig. 3, transmitting authentication information to the call quality prediction server 300. Here, the authentication information may include an IP address (20.20.20.20) and Port number (1000, 1001) of each voice and video for the call quality prediction server 300 transmitted to the internet protocol terminal 100. In one embodiment, web telephony server 200 may calculate a message digest and transmit authentication information to call quality prediction server 300, as in the method of calculating a message digest in the process of (2) of fig. 3.

In the process (4) of fig. 5, the network telephone terminal 100, after calculating the message digest, first transmits the calculated value to the call quality prediction server 300 by including it in the packet, in the same manner as the calculation in the process (2) of fig. 3.

The call quality prediction server 300 performs SIP authentication of the network telephony terminal 100 by comparing the message digest received from the network telephony terminal 100 with the message digest received from the network telephony server 200 through the (3) process of fig. 5.

In an embodiment, when the SIP authentication of the network telephony terminal 100 is successful, the test server 300 may receive a transmission test packet for call quality prediction transmitted by the network telephony terminal 100 and retransmit with Source IP and Source Port included in an IP header of the transmission test packet as a destination. The transmission trial session generated in the above procedure can cope with NAT (Network Address Translation) of all four modes, here, full Cone, reserved Cone, port Restricted Cone, symmetry NAT.

In another embodiment, when the SIP authentication to the network telephony terminal 100 fails, the call quality prediction server 300 refuses retransmission or otherwise notifies the network telephony terminal 100 of information about the SIP authentication failure to end the call quality prediction process.

That is, the network telephone terminal 100 performs SIP registration with the network telephone server 200 to become a state in which a call can be made, and the network telephone terminal 100 may request the network telephone server 200 to generate a transmission trial session for call quality prediction. The network telephony server 200 may transmit address information of the call quality prediction server 300 other than itself to the network telephony terminal 100, and the network telephony terminal 100 may generate a transmission test session to predict the call quality after performing the SIP authentication process using the call quality prediction server 300 of the address.

Fig. 6 is a schematic diagram illustrating a procedure of a transmission trial session for generating a request of a network telephony terminal and for prediction of call quality between a network telephony server and any network telephony terminal. More specifically, fig. 6 is a schematic diagram illustrating a process of requesting and directly performing call quality prediction by the network telephone terminal 100. Except that fig. 6 does not pass through the call quality prediction server 300, the network telephony server 200 performing SIP registration with the network telephony terminal 100 directly generates a transmission trial session to predict the call quality.

In the process of (1) of fig. 6, the network telephony terminal 100 may request SIP registration from the network telephony server 200. More specifically, the network telephone terminal 100 may generate SIP REGISTER a message for requesting SIP registration and perform SIP registration through the generated SIP REGISTER message. Here, the SIP registration process of the network telephone terminal 100 is the same as the (1) process of fig. 3, 4, and 5.

In the process of fig. 6 (2), as in fig. 3, 4 and 5, the network telephony terminal 100 may request generation of a transmission trial session for call quality prediction from the network telephony server 200 using the SIP OPTIONS. However, in the 200Ok response transmitted from the web telephony server 200, the aservaddr, vservaddr field of the X-Quality-Test header contains both the IP address of itself and the Port number newly allocated for the transmission Test.

In the process (3) of fig. 6, when SIP authentication is successful, the network telephony terminal 100 can generate a transmission test session, and can predict the call quality. As in the previous manner (fig. 3, 4, and 5), the web phone terminal 100 and the web phone server 200 can each calculate a message digest value. In one embodiment, the network telephone server 200 compares the message digest transmitted by the network telephone terminal 100 with the message digest calculated by itself, and when the values are the same, the authentication is successful, and the transmission test session generation request is accepted, and performs the call quality prediction with the network telephone terminal 100. Here, the procedure is the same as in (4) of fig. 5, except that the object to perform the call quality prediction is the web telephony server 200.

In addition, in the process (2) of fig. 6, the internet phone server 200 may perform call quality prediction after the SIP authentication of the internet phone terminal 100 is completed, including 401Unauthorized, as in the process SIP REGISTER of the process (1). At this time, in the process (3) of fig. 6, the network telephone terminal 100 immediately performs a transmission test using the address information of the network telephone server 200 obtained in the process (2) of fig. 6.

That is, the network telephone terminal 100 performs SIP registration with the network telephone server 200 to become a state in which a call can be made, and the network telephone terminal 100 may request the network telephone server 200 to generate a transmission trial session for call quality prediction. The internet phone server 200 may notify the internet phone terminal 100 of the address containing the own Port newly allocated for the transmission trial and the SIP authentication request information, and the internet phone terminal 100 may generate the transmission trial session prediction call quality after performing the SIP authentication process using the address of the internet phone server 200.

The call quality prediction process shown in fig. 3 to 6 is a process of measuring the predicted call quality such as the packet loss rate, the transmission delay, and the integrity of the original data by performing a transmission test between the network telephone terminal 100 and the network telephone server (SIP Proxy, IP-PBX, CSCF, etc.) 200 or between the network telephone terminal 100 and the call quality prediction server 300. In order to solve the NAT problem, when an SBC is provided between the network telephone terminal 100 and the network telephone server 200, the call quality prediction process shown in fig. 3 to 6 is applied as it is, and the SBC predicts the call quality between the network telephone terminals 100, and the SBC may only function as an intermediate call quality prediction process between the network telephone terminal 100 and the network telephone server 200.

The transmission test may be performed with the internet phone server 200 performing the SIP registration process or the external call quality prediction server 300 generating another transmission test session for predicting call quality. In addition, in the SIP registration process, the address of the network telephone terminal 100 identified by the network telephone server 200 is also stored in the network telephone server 200 by solving the NAT problem by the NAT transit solution of the SIP itself, and thus the transmission test can be simply performed using the address as it is.

However, since the SIP message and the transmission test packet are possibly confused because of the address used for the transmission of the SIP message, the pattern of the RTP packet or the UDP packet which disguises (same bile and transmission interval) the RTP packet and records the transmission time is also fixed because of the fixed pattern of the SIP message, and it is possible to perform the call quality prediction transmission test using the SIP registration address as it is, without being impossible to distinguish.

If the network telephone operator solves the NAT translation problem of SIP by SBC (Session Border Controller) and executes the Topology routing on the network telephone server side, the SBC will generally execute the Media Relay, and at this time, the subscriber terminal and the SBC may generate NAT Pinhole in advance at ordinary times and use them in actual call generation. In this case, in order to maximize the performance of the call quality prediction in the same environment as that in the actual call generation, the SBC similarly performs Relay by using Media for predicting the call quality.

In fig. 3 and 4, when the network telephone server 200 records the address information of itself or the call quality prediction server 300 in the SIP OPTIONS message and transmits it to the network telephone terminal 100, the address is converted into its address by SBC (Session Border Controller) and transmitted to the network telephone terminal 100 to perform a transmission test session for call quality prediction.

In fig. 5 and 6, the SBC can address-convert the internet phone server 200 or the call quality prediction server 300 included in the response message to the SIP OPTIONS into its own address to predict the call quality. However, since the address used for generating the actual call is expected to be inconvenient due to collision with the actual call, the SBC and the network telephone terminal 100 may negotiate to generate a NAT Pinhole (Pinhole) for transmitting the test session in advance, and the address may be used.

In the call quality prediction process as in fig. 3 to 6, the transmission trial is performed after the SIP transaction is completed, but may be performed in the middle of the SIP transaction. For example, in the process (2) of fig. 3, the network telephone terminal 100 may receive the address of the call quality prediction server 300 and authentication information through 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 receiving the calculated message digest value from the network telephone terminal 100, the call quality prediction server 300 performs the process (3) of fig. 3 in the middle of the process (2) of fig. 3, and compares the authentication information transmitted from the network telephone server 200 with the message digest calculated by itself to complete SIP authentication. In an embodiment, when the SIP authentication is successful, the call quality prediction server 300 may perform a transmission test using a NAT Pinhole (Pinhole) generated in the process of receiving the message digest from the network telephony terminal 100, and transmit the call quality prediction result to the network telephony terminal 100 by including the SIP 200Ok message in the network telephony server 200 as necessary after performing the transmission test. In addition, the same method can be used in the case of fig. 4.

In the case of fig. 5, to receive the address of the call quality prediction server 300, the network telephony terminal 100 may first receive the SIP 200OK message. For example, the web telephony server 200 transmits the authentication information and the address of the call quality prediction server 300 originally while transmitting the 401Unauthorized reply to the web telephony terminal 100 first as a reply of the initial SIP OPTIONS message, at which time a transmission test may be performed in the middle of the second SIP OPTIONS transaction.

In addition, if the authentication process is omitted and there is no NAT device between the network telephone terminal 100 and the call quality prediction server 300, the network telephone server 200 transmits the address of the network telephone terminal 100 to the call quality prediction server 300 while performing the process (3) of fig. 5 in the process (2) of fig. 5 after obtaining the address of the network telephone terminal 100 through the SIP OPTIONS message in the process (2) of fig. 5, and the call quality prediction server 300 may perform a transmission test for call quality prediction with the network telephone terminal 100 and transmit the prediction result to the network telephone terminal 100 through the network telephone server 200 in the SIP 200Ok message included in the process (2) of fig. 5. The same can be done in the case of fig. 6.

In a mobile communication wireless network, when a network such as GPRS (General Packet Radio Service) exists between the network telephone terminal 100 and the CSCF (Call Session Control Function) of the network telephone server 200, a GPRS attach procedure is also required, and is constituted by PDP (Packet Data Protocol) Context active between the network telephone terminals 100 and SGSN (Serving GPRS Support Node), and by PDP Context Create procedure between the SGSN and GGSN (Gateway GPRS Support Node).

When the PDP Context is generated to be activated, the network telephone terminal 100 is given an IP address and Port number for a transmission trial and can generate a transmission trial session prediction call quality using the same. Such a procedure is required for predicting call quality in the same environment as that in the actual call generation to the maximum extent, and since the Private Ip can be obtained through the GGSN according to the policy of the mobile communication company, NAT Pinhole generation may be required as in the case of using the Private Ip in the wired network.

The (2) process of fig. 3 will send and receive codec information for transmission test, and QOS (Quality Of Service), which requests a required bandwidth in PDP generation and activation processes by different codecs, will be guaranteed by QOS related technologies such as RSVP (Resource Reservation Protocol) or DiffServ (Differentiated Service), so that the transmission test is performed in the same environment as the call between the actual network telephony terminals 100. Such QOS execution procedures may be applicable throughout the present disclosure.

Namely, when the actual call connection process is in, generating and activating through the first PDP Context; or second, resource reservation for a particular path session using RSVP; or third, differentiation using traffic classification by DiffServ; or fourth, MPLS (Multi-Protocol Label Switching), intServ (Integrated Service), etc., the transmission test for prediction of call quality for different sections between SIP network components including the network telephony terminal 100 is also implemented after the same QOS is provided.

Fig. 7 to 12 are diagrams illustrating a process of predicting call quality between arbitrary network telephone terminals. The network telephone terminal 100 in fig. 7 to 12 is described taking an example assuming that SIP messages are transmitted and received in an IMS network or a wireline network.

More specifically, fig. 7 is a message transmission and reception procedure for performing call quality prediction between an arbitrary calling terminal and a called terminal in an IMS network, when the calling terminal requests call quality prediction with the called terminal through a message such as SIP OPTIONS, the IMS component transmits the SIP OPTIONS message on the same path as the path of transmission of SIP INVITE message, and in the case of relaying an actual call between the calling terminal and the called terminal, when Media Relay is performed for various reasons such as a policy of a carrier, NAT, topology establishment, media Transcoding, etc., each component of the IMS network through which the SIP OPTIONS message passes is set as a boundary of a call quality transmission section (the terminal is set as a boundary of the transmission section by default), a transmission test is performed for each different section, and a method of averaging or simply taking the lowest value through each call quality prediction index is effective for the whole section. In the case of fig. 7, the procedure of performing Media Relay by the P-CSCF on both sides to which the calling terminal and the called terminal belong due to NAT or the like is shown.

Fig. 8 is largely the same as fig. 7, and belongs to a case where a public IP is directly set through GGSN (Gateway GPRS Support Node) or an SBC or the like exists between a terminal and a P-CSCF when a calling terminal and a called terminal are GPRS (General Packet Radio Service) networks, so that the public IP is indirectly acquired, since an IMS network component other than the terminal and the SBC does not execute a Media Relay at all (the SBC generally executes the Media Relay but will be omitted here, and supplementary explanation will be made in fig. 12), a transmission test is directly executed between the calling terminal and the called terminal.

Fig. 7 and 8 show a process of performing call quality prediction between any of the network

telephone call terminals

102, 106 and the particular network telephone called terminal 104, 108 using a SIP OPTIONS message. Here, any of the network

telephone call terminals

102, 106 may be at least two of the plurality of network telephone terminals 100 in fig. 1, and the specific network telephone called terminal 104, 108 may be at least two of the plurality of network telephone terminals 100 in fig. 1 that do not belong to any of the network

telephone call terminals

102, 106.

Hereinafter, for convenience of explanation, the network

telephone call terminals

102, 106 will be described as

call terminals

102, 106, and the specific network telephone called

terminals

104, 108 will be described as called

terminals

104, 108.

The SIP transaction requesting section 21 may record the information of the calling

terminals

102, 106 in a From header, and after recording the information of the called

terminals

104, 108 in a To header, request a call Quality prediction by adding a header such as an X-Quality-Test by a method similar To that of fig. 3 To 6.

As in the case of fig. 3 to 6, the header of the X-Quality-Test may also be recorded in the body of the SIP message, which means the same here, so that the process of adding the body to the SIP message for recording will be omitted in the following.

The header of the X-Quality-Test may be configured as follows.

X-Quality-Test:Request acodec＝ulaw,vcodec＝h263,addr1＝1.1.1.1:10,11

Here, the Request is a call quality prediction Request, and addr1 is an IP address, voice port information, and video port information of the user to be used for the call quality prediction Request. That is, addr1 includes its own IP address (1.1.1.1), voice Port (10) and video Port (11), acode is a voice using ula codec, vcodec is a video using h263 codec.

The own IP address may be a personal IP or a public IP, and an SBC (Session Border Controller) exists between the calling

terminals

102, 106 and the P-CSCF (Proxy CSCF) 400,400, 404, and when the calling

terminals

102, 106 possess the personal IP, the calling

terminals

102, 106 may record the personal IP as it is, and then be converted to the public IP by the SBC for transmission to the P-CSCF400, 404. At this time, the procedure of fig. 8 may be applied because the P-

CSCFs

400, 404 consider the calling

terminals

102, 106 to be used for public IP without performing Media Relay.

As in the case of fig. 3-6, the calling terminal 102 may first perform SIP authentication. In the process of (1) of fig. 7, the P-CSCF400 may request authentication by transmitting a 401Unauthorized answer to the calling terminal 102 as a response to the SIP OPTIONS message, and the calling terminal 102 may transmit the SIP OPTIONS message to the P-CSCF400 again for the SIP authentication request, which may contain authentication information.

The P-CSCF400 may continue the next process if authentication is successful by checking the value of the SIP OPTIONS message received from the calling terminal 102, and may transmit an error message such as 403, forbidden (Bad auth) to the calling terminal 102 if authentication fails, rejecting the call quality prediction request. In the following, the SIP authentication process after fig. 8 may also be completed through the same process, and thus a description of the SIP authentication will be omitted.

The P-CSCF400 can predict the call quality by a transmission test with the call terminal 102 when performing the Media Relay by performing telephone connection with the called terminal 104 recorded in the SIP transaction request by the procedure (1) of fig. 7, as long as the P-CSCF receives the SIP transaction request including the call quality prediction request. In this case, the transmission test was the same as the method described in fig. 3 and 4.

For example, if the P-CSCF or IP-PBX is assigned personal IP via GGSN (Gateway GPRS Support Node) to the call terminal 102 without the SBC executing NAT transit in between, the Media Relay may be executed for resolving NAT transit in the case of a SIP environment constituted by the IP-PBX or in the case of a call terminal existing behind a NAT device. In this case, if the call quality prediction method of fig. 4 is executed, a server that exclusively executes the Media Relay is managed by the P-CSCF or the IP-PBX, and the call quality prediction method of fig. 3 may be executed. In addition, in the procedure (1) of fig. 7, since the addr1 field of the X-Quality-Test header is not required at all, it is omitted here.

When the call Quality prediction with the calling terminal 102 is completed, the P-CSCF400 may store the result in its own cache memory (cache memory), and may store the IP address (30.30.30.30) of the P-CSCF400 performing the Media Relay and the ports (1000, 1001) of voice and video in the X-Quality-Test header as follows.

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

After storing the X-Quality-Test header, the P-CSCF400 may transmit the SIP OPTIONS message to the next destination on the same path as the transmission path of the SIP transaction request message. At this time, the P-CSCF400 removes CQTY (Call Quality) field for rapidity of call quality prediction, and inserts CQTY field for transmission in the process of transmitting 200Ok response after transmitting SIP OPTIONS message first. Here, CQTY fields each indicate a voice quality (8.9) and a video quality (8.2), and addr2 fields indicate an IP address (30.30.30.30), a voice port (1000), and a video port (1001) of the call-side P-CSCF 400.

The (1) procedure of fig. 8 belongs to the case where NAT transit is performed because the calling terminal 106 itself has a public IP or there is SBS between the calling terminal 106 and the P-CSCF404, and is regarded as the calling terminal 106 having a public IP without the Media Relay of the P-CSCF404. Accordingly, the P-CSCF404 of fig. 8 may not be set as a boundary of an interval for call quality prediction, and call quality prediction between the call terminal 106 and the P-CSCF404 may not be performed. Even though calling terminal 106 owns the personal IP, if configured in the same SUBNET environment, a Media Relay may not be required.

For example, when the SBC performs NAT transfer, a session generation and maintenance NAT pinhole for Media transfer may be preset between the call terminal 106 and the SBC, and at this time, the SBC may record its own Media Relay address in the addr1 field (e.g., may change the address of the existing call terminal to its own address) and transmit the same to the P-CSCF404. Simply because the SBC address is the address used to generate the actual call, when a flush is expected to occur, the SBC may negotiate with call terminal 106 to generate a NAT Pinhole (Pinhole) for the transfer Test session, and the address of the SBC may be set in the addr1 field of the X-Quality-Test header.

In the process of fig. 8 (1), if the X-Quality-Test header of the SIP OPTIONS message transmitted by the calling terminal 106 to the P-CSCF404 is as follows, it may be transmitted to the S-CSCF504 as it is.

X-Quality-Test:Request acodec＝ulaw,vcodec＝h263,addr1＝1.1.1.1:10,11

For example, in the case of an IMS Network, in the calling side P-

CSCFs

400, 404, the next destination of the SIP OPTIONS message is the S-

CSCH

500, 504 belonging to the Home Network (Home Network) of the calling

terminal

102, 106, and the next destination is the I-CSCH600, 602 of the domain to which the called

terminal

104, 108 belongs, may be transmitted by HSS querying the order of the S-

CSCFs

502, 506 to which the called

terminal

104, 108 belongs, the P-

CSCs

402, 406 to which the called

terminal

104, 108 belongs, and the called

terminal

104, 108.

If there is no intermediate node executing the Media Relay, the X-Quality-Test header is transferred as recorded by the P-CSCF400 to which the calling terminal 102 belongs until the called

sides

402 and 406, as in the case of fig. 7.

Here, addr1 is the address of the calling terminal 102, addr2 is the address of the P-CSCF400 of the calling terminal 102 to which it belongs, and CQTY is the call quality prediction result calculated in the process (1) of fig. 7.

In the case of fig. 8, the transmission may be performed as recorded by the P-CSCF400 to which the call terminal 102 belongs as follows.

X-Quality-Test:Request acodec＝ulaw,vcodec＝h263,addr1＝1.1.1.1:10,11

Addr1 is the address of the calling terminal 106.

In the process (3) of fig. 7, since the called terminal 104 has a personal IP, the called P-CSCF402 executes the Media Relay, and the call quality between the called terminal 104 and the P-CSCF402 can be predicted by the methods of fig. 3 and 4, and the result (voice is 8.1 and image is 8.2) can be stored in the cache memory.

In addition, in the process (2) of fig. 7, the called-side P-CSCF402 performs a transmission Test for call Quality prediction to the calling-side P-CSCF400 of addr2 recorded in the X-Quality-Test header of the SIP OPTIONS message, and saves the result (voice 8.1 and image 8.2) in the cache memory. In this case, since NAT transfer is generally not present, a NAT Pinhole (Pinhole) generation process is not required, and a transfer test may be performed using the address recorded in addr 2.

The call quality prediction can be performed by the called side P-CSCF402 and the calling side P-CSCF400 through the (2) procedure of fig. 7, or alternatively, the transmission test can be performed directly by the (3) procedure of fig. 7 and the called terminal 104, the P-CSCF402 performs only the (2) procedure of fig. 7, records the result and the own address in the SIP OPTIONS message, and then transmits the SIP OPTIONS message to the called terminal 104, and the called terminal 104 and the P-CSCF402 predict the call quality.

If SIP authentication is required in the process (2) of fig. 7, the method using Shared Secret as in fig. 3 to 6 is not suitable, but authentication can be performed by a method using certificates in a state where certificates issued by CAs derived from mutually trustable CA (Certificate Authority) are exchanged. For example, the receiving side may perform the partner authentication by generating a challenge and transmitting it, encrypting and retransmitting it with its own key, decrypting the challenge that confirms the original transmission for the public key of the certificate of the receiving side.

After completing the call Quality prediction in this way, the P-CSCF402 to which the called terminal 104 belongs (address=40.40.40.40:2000, 2001) can configure the X-Quality-Test header as follows.

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,1001CQTY＝8.4:8.5addr3＝40.40.40.40:2000,2001CQTY＝8.1:8.3addr4＝50.50.50.50:3000,3001

Here, addr1 is the address of the calling terminal 102, addr2 is the address of the calling side P-CSCF400, addr3 is the address of the called side P-CSCF402, and addr4 is the address of the called terminal 104. In addition, three CQTY fields each sequentially represent a call quality prediction result between the calling terminal 102 and the calling side P-CSCF400, between the calling side P-CSCF400 and the called side P-CSCF402, and between the called side P-CSCF402 and the called terminal 104.

The above-described X-Quality-Test header may be included in the 200Ok answer to the SIP OPTIONS message for transmission to the calling terminal 102. It can be confirmed that the prediction results between the calling terminal 102 and the called terminal 104 for different intervals are all included in the above-mentioned X-Quality-Test header.

The call quality prediction indexes for different sections are stored in the cache memory by the main body for performing call quality prediction, so that when a call quality prediction request for the same object is received within a certain period of time, the value stored in the cache memory is used without performing an actual transmission test, 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 as described above, only the call quality prediction may be performed between the calling side P-CSCF400 and the calling terminal 102, and both sides of the san xian may use the value stored in the cache memory as it is.

After passing the transmission test of the procedure (2) of fig. 7, the called-side P-CSCF402 saves the result (cqty=8.4:8.5) as a call quality prediction result with the calling-side P-CSCF400, and also saves the call quality prediction result with the called terminal 104, because it is the main body of predicting call quality. The caller-side P-CSCF400 refers to the call quality prediction result with the callee-side P-CSCF402 in the SIP 200Ok response message and saves it in the cache memory.

In addition, in the call side P-CSCF400, the call quality prediction result of the SIP 200Ok message passing through the (2) procedure and the (3) procedure of fig. 7 may be referred to as the call quality prediction result between the call side P-CSCF400 and the called terminal 104 and stored in the cache memory. At this time, when another calling terminal belonging to the calling side P-CSCF400 requests the call quality prediction for the same called terminal 104, only the procedure (1) of fig. 7 is executed, and the called side P-CSCF400 immediately transmits the SIP 200Ok response to the calling terminal 102 using the call quality prediction result stored in the cache memory, thereby ending the call quality prediction. Such a cache utilization structure may be applicable to the entire contents of the present invention.

In the case of fig. 8, since the called terminal 108 itself or through the SBC has a public IP, there is no node in the middle that performs Media Relay, and the following X-Quality-Test header can be transferred to the called terminal 108 as it is.

X-Quality-Test:Request acodec＝ulaw,vcodec＝h263,addr1＝1.1.1.1:10,11

The called terminal 108 may perform a transmission test for call quality prediction with reference to addr1 and the calling terminal 106 through the (2) procedure of fig. 8. If there is a called side SBC and the called side SBC negotiates with the called terminal 108 to generate a NAT pinhole for the transfer test session as also described in the procedure of (1) of fig. 8, a transfer test may be performed using this address. That is, when the called SBC transmits the address information of the addr1 field of the X-Quality-Test header to the called terminal 108 in order to participate in the transmission Test, the called terminal 108 performs the transmission Test by using the address of the SBC, and the SBC performs the Media Relay participation Test to the calling terminal as it is. The call Quality prediction result through the procedure of (3) of fig. 8 is voice 8.8, video 8.9, personal IP address for transmission Test of the called terminal 108 is 192.168.1.1, voice port information is 10, video port information is 11, public IP converted by the called side SBC is 50.50.50.50, voice port information is 20, video port information is 21, and a 200Ok message including the following X-Quality-Test header can be transmitted from the called terminal 108 to the called side SBC.

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

The called side SBC may modify the add1 field and addr2 field of the X-Quality-Test header as follows for transfer from the called side SBC to the called side P-CSCF406.

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

The 200Ok message is then passed to the calling terminal 106 as it is, ending the call quality prediction process.

Fig. 9 shows a process of performing call quality prediction between an arbitrary network phone call terminal and a specific network phone called terminal.

More specifically, as in the case of fig. 8, in fig. 9, the communication network is provided with a common IP for each terminal, and IBCF (Interconnection Border Control Function) functioning as Border Controller is provided between the communication companies for security, NAT transfer, and Topology routing, etc., the IBCF of each communication company generally executes a Media Relay, and in fig. 9, a transmission test section for call quality prediction is set as a calling terminal, i.e., a calling side IBGF1, a called side IBGF2, and a called terminal by the link between IBGF (Interconnection Border Gateway Function) and TrGW (Transition Gateway) is set as a transmission test section for call quality prediction, and the transmission test is executed in different sections.

Fig. 9 shows a process of performing call quality prediction between the paging terminal 110 and the terminating terminal 112 when there is no Media Relay between the paging terminal 110 and the first paging CSCF 700 or between the terminating terminal 112 and the second paging CSCF 702, for reasons such as direct or indirect use of the particular paging terminal 112 in public IP, for example, for the purpose of security between mobile communication operators, NAT transfer, and Topology routing, for example, in the middle, for the purpose of IBCF (Interconnection Border Control Function) for signal processing and IBGF (Interconnection Border Gateway Function) for Media processing.

In addition, fig. 9 generates Media Relay not only at the IBCF but also at the time of Media transcoding or the like required in the middle of the call transfer path, so that the call quality prediction process is performed similarly to the case of the IBCF. Here, IBGF generally performs Media Relay by interlocking with IBCF, and the X-Quality-Test header of the SIP OPTIONS message reaching the calling side IBCF-800 through the (1) procedure of fig. 9 is as follows.

X-Quality-Test:Request acodec＝ulaw,vcodec＝h263,addr1＝1.1.1.1:10,11

The calling side IBCF one 800 performs a transmission test by performing a Media Relay in association with the calling side IBGF one 900 (address=2.2.2.2) before transmitting the SIP OPTIONS message to the called side IBCF two 802 or for rapidity of call quality prediction, and simultaneously issues a command to the calling side IBGF one 900.

In the case before transmission, the result may be received from IBGF one 900 and the X-Quality-Test header may be configured to be transmitted to the called side IBCF two 802 as follows.

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

In the case where IBCF one 800 plays a role in the Topology ordering, to maintain consistency, addr1 information is deleted as follows and then transferred to IBCF two 802.

X-Quality-Test:Request acodec＝ulaw,vcodec＝h263,CQTY＝8.8:8.9,addr1＝2.2.2.2:20,21

Here, the existing addr2 may be addr1.

As described above, when the SIP OPTIONS message reaches IBCF two 802, IBCF two 802 issues a command to the called side IBGF two 902 (address=3.3.3.3) as well when Media Relay needs to be performed, performs a transmission Test between IBGF one 900 and IBGF two 902 through the (2) process of fig. 9, receives the result from IBGF two 902 as recorded in the X-Quality-Test header as follows, and transmits to the called side CSCF two 702.

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

If it is assumed that IBCF one 800 performs media transcoding (in the case of audio, ulaw is converted to iLBC, in the case of video, h.263 is converted to h.261), the acode and vcodec fields of the SIP OPTIONS message transmitted by IBCF one 800 to IBCF two 802 are replaced with iLBC and h261 for delivery, so that IBCF one 800 and IBCF two 802 can perform call quality prediction using iLBC and h261 as if it were a call. Such field changes must be kept in mind and delivered after reconstitution upon transmission of a 200Ok reply message.

In addition, although the audio codec and video codec are arbitrarily specified by the call terminal or AS (Application Server) requesting the call quality prediction, as in the case of an actual call, all codec lists supportable by the call terminal are recorded and transmitted by the other SIP OPTIONS Transaction before the SIP OPTIONS message for the call quality prediction is transmitted, and the call quality prediction is performed by the call terminal by transferring the response to the SIP OPTIONS message to the call terminal from the intersection with the codec list supportable by the called terminal.

In the call quality prediction process, for rapidity, a transmission test and the transmission of the SIP OPTIONS message can be always performed simultaneously. At this time, even if the CQTY field is omitted, the address of the server that executes the Media Relay must be transferred while being included therein, and thus set as the boundary of the section for call quality prediction. Because the default timer f of the SIP Transaction is 32 seconds, the transmission test is preferably about 10 seconds, and only if the transmission tests in different intervals are executed simultaneously, the final 200Ok response can be transmitted to the calling terminal under the condition that the default timer f is not exceeded. The transmission test execution body remembers the result and inserts a CQTY field in a proper position of the 200Ok response message for delivery.

In the case of CSCF two 702, since Media Relay is not performed as assumed above, the above-described X-Quality-Test header is transferred to the called terminal 112 as it is, the called terminal 112 (address=4.4.4.4) performs call Quality prediction through addr2 (address=3.3.3, ibgf2) and (3) procedures of fig. 9 contained in the X-Quality-Test header as a boundary of an interval for final call Quality prediction, and transfers the result (voice 9.2, picture 9.3) to CSCF two 702 as recorded in the X-Quality-Test header as follows.

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

CSCF two 702 passes to IBCF two 802 as it is, in the case of IBCF two 802, if it functions as in the case of IBCF one 800 as a Topology upgrade, it passes to IBCF one 800 after addr3 is deleted to hide the intranet information as follows.

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

IBCF one 800 is a Topology routing, and the address of the deleted calling terminal 110 is restored and transferred to CSCF one 700 as follows, and CSCF one 700 may transfer to the calling terminal 110 as it is.

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

Calling terminal 110 may refer to the prediction of call quality for each of the different intervals and use the average or minimum value to predict call quality according to the policy.

Fig. 10 shows a process in which a called terminal of a network telephone performs call quality prediction when an analog circuit switched network such as PSTN exists.

More specifically, fig. 10 is a case where the called terminal belongs to CS (Circuit Switching) Domain, in which case the call is transferred to BGCF (Breatout Gateway Control Function) in the case of an IMS network, the SIP signal of the call is transferred from BGCF to CS Domain through SGW (Signaling Gateway) via MGCF (Media Gateway Control Function), and the media of the call is transferred to CS Domain through MGW (Media Gateway), at which point, since MGW is the last transit point of PS (Packet Switching) Domain, a section boundary for call quality prediction is set therein, and a transmission test for call quality prediction is performed between the call terminal and the call terminal.

When the destination is PSTN1400, the SIP OPTIONS message is delivered to BGCF (Breakout Gateway Control Function), which then selects MGCF (Media Gateway Control Function) for delivery. The transmission signal is responsible for SGW (Signaling Gateway) 1200 and the media is responsible for MGW (Media Gateway), connecting to the circuit switched network. In the case of a circuit-switched network, the use of channels whose bandwidth is physically guaranteed is beyond the scope of the present invention, and thus the call quality prediction operation is not required. I.e. to the MGW 1300.

Fig. 10 is a diagram of the case where there is no Media Relay between the calling terminal 114 and the calling-side P-CSCF one 408 due to the fact that the calling terminal 114 is directly or indirectly used for public IP or the like, and an OPTIONS message including the following X-Quality-Test header is transferred to the P-CSCF408 through the procedure (1) of fig. 10, and then transferred to the MGCF1100 as it is without modification.

X-Quality-Test:Request acodec＝ulaw,vcodec＝h263,addr1＝1.1.1.1:10,11

Since MGCF110 communicates with MGW1300 to perform Media Relay, a command to perform call quality prediction can be issued to MGW (address=2.2.2.2) 1300 through the process (2) of fig. 10. The MGCF803 obtains the voice 8.0 and the video 9.0 as a result of the structure for performing the call Quality prediction, and transmits a 200Ok message including the following X-Quality-Test header to the BGCF1000, and sequentially transmits the message to the calling terminal 114 as it is, thereby ending the process for performing the call Quality prediction.

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

At this time, since the call quality prediction is not completed until the final called terminal, the other SIP Error message is transmitted by including information such as the failure point (MGCF) and the failure cause (conversion to a circuit-switched network) instead of the 200Ok message. However, the content of the X-Quality-Test header is included as it is, and the call Quality prediction result is transmitted to the MGW 1300. For not only the technical reasons of switching to circuit switching or the like, but also the overload of the communication network due to the prediction of the call quality, the specific area is forbidden to predict the call quality due to the policy of the communication company.

Fig. 11 shows a process of performing call quality prediction by an external SIP AS. More specifically, fig. 11 shows a case where a call quality prediction between a calling terminal and a called terminal is requested by a non-calling terminal such as a SIP application server.

In addition to the direct request of the calling terminal 116 by transmitting a SIP OPTIONS message, prediction of call quality from a particular calling terminal 116 to a particular called terminal 118 may be requested by the SIP AS (Application Server) 1500 or the like via any communication protocol. At this time, taking IMS network 1600 as an example, information of P-CSCF410 to which calling terminal 116 belongs may be obtained first. This is only necessary to obtain the information of the P-CSCF410 after obtaining the address of HSS (Home Subscriber Server) through SLF (Subscriber Location Function) and querying the HSS for the address of the S-CSCF on the call side in the domain to which the call terminal 116 belongs. Also in the case of a wired network, the SIP Proxy to which the caller belongs may be obtained by a similar method, after which SIP AS1500 requests a prediction of the call quality between any of calling terminal 116 and called terminal 118 from SIP Proxy or P-CSCF410 on the calling side.

When a call quality prediction request containing information of the calling terminal 116 and information of the called terminal 118 arrives at the calling side P-CSCF410 through the procedure of (1) of fig. 11, a call quality prediction is requested from the P-CSCF410 to the calling terminal 116 through the procedure of (2) of fig. 11. Also using the SIP OPTIONS message, the To header and Request URI become the address of the calling terminal 116, and the X-Quality-Test header may be configured in the following form.

X-Quality-Test:Request acodec＝ulaw,vcodec＝h263,peer＝"sip:abc@def.com"

Here, the Request is a call quality prediction Request, acode is a voice codec, vcodec is an image codec, and peer is information of the called terminal.

When the call terminal 116 gets a call quality prediction request through the process (2) of fig. 11, a call quality prediction can be performed between the called terminal 118 and itself 116 through the process (3) of fig. 11.

The process (3) of fig. 11 may be replaced with the process of fig. 7, 8, 9, 10, 12, etc., according to the case. Through the (4) procedure of fig. 11, the call terminal 116 may transmit the result of the call quality prediction request, which is obtained through the (2) procedure of fig. 11, to the P-CSCF 410. The X-Quality-Test header of the 200Ok message may be configured as follows.

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

In the above example, it can be confirmed that only the final structure of the cost-effective different inter-zone call quality prediction results is transferred. The prediction results of the call quality for each section may be transmitted together with address information including the boundaries of the section.

When the call side P-CSCF410 receives a call quality prediction result between the calling terminal 116 and the called terminal 118, the call quality prediction result may be transferred to the SIP AS1500 through the (5) procedure of fig. 11.

Fig. 12 is a diagram showing a process of reducing predicted traffic of call quality, and fig. 13 is a diagram comparing UDP packets according to an embodiment of the present invention. More specifically, fig. 12 illustrates a process of performing call quality prediction by setting the SBC that executes the Media Relay as the boundary of the section for call quality prediction.

Conventionally, the SBC actually executes the Media Relay during the actual call connection and also executes the Media Relay in the transmission test for the call quality prediction, while the SBC is responsible for NAT transit of the terminal, but does not become the section boundary for the call quality prediction. If there are a plurality of SBCs and a plurality of terminals are linked with the SBC, the SBC is set as the boundary of the call quality prediction section, and the call quality prediction record between SBCs is managed by the cache memory, so that the call quality prediction traffic can be reduced.

In fig. 12, it is assumed that the personal IP address of the call terminal 120 is 192.168.1.10, and then the public IP address changed by the SBC is 20.20.20.20.

The call Quality prediction with the called terminal 1222 is requested by the calling terminal 120 in the process of (1) of fig. 12, the information of the called terminal 122 is set in the To header of the SIP OPTIONS message, and the header of the X-Quality-Test of the SIP OPTIONS message may be configured as follows.

X-Quality-Test:Request acodec＝ulaw,vcodec＝h263,addr1＝192.168.1.10:10,11

When the caller SBC one 1700 receives the SIP OPTIONS message including the X-Quality-Test, the addr1 field is ignored and the call Quality prediction (voice 8.9, image 8.2) between the call terminal 120 and the caller 1700 is performed by the method of fig. 3 and 4, and the X-Quality-Test header is transferred to the caller Proxy one 1800 as follows.

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

At this time, the X-Quality-Test header is transferred as it is until the called side SBC two (address= 30.30.30.30) 1702 because the calling side Proxy one 1800 and the called side Proxy two 1802 do not execute Media Relay. Since the second SBC 1702 on the called side executes the Media Relay and sets the boundary of the section for call quality prediction for the above-described reason, the call quality prediction is executed, and the result (voice 8.3, video 8.4) is recorded as follows and transferred to the called terminal (address= 192.168.2.10) 122.

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

The second SBC 1702 on the called side performs call quality prediction with the called terminal 122 and immediately passes the 200OK message to the second Proxy 1802. Called terminal 122 performs a transmission test with called side SBC two 1702 through the process (3) of fig. 11, records the results (voice 8.5, video 8.6) as follows and transmits a SIP 200Ok message to called side SBC two 1702.

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,11CQTY＝8.5:8.6addr4＝192.168.2.10:10,11

The 200Ok message is directly transmitted to the calling terminal 120, and the call quality prediction process is ended.

In the present invention, in the case of actual call connection, according to the policy of each carrier, techniques such as IPSEC (Internet Protocol Security) or SRTP (Secure Real-Time Transport Protocol) are used to improve security, and in the process of predicting call quality, in order to test in the same environment as the actual call connection process to the maximum extent in different sections, encryption and authentication of transmission test packets may be performed by means of ESP (Encapsulating Security Payload) or AH (Authentication Header) of IPSEC after negotiation of IPSEC SA (Security Association) is first performed between the boundaries of the sections.

In addition, when SRTP developed specifically for RTP is used, encryption and authentication of the corresponding packet can be performed in SRTP fashion after key exchange is performed between boundaries of sections for RTB packets that do not contain actual RTP packets or actual media.

In the case of a transmission trial using UDP packets, the process of generating UDP packets generates UDP packets having the same size and transmission interval as those of RTP packets of the object codec to be actually trial. As in the case of the ULAW, transmission is performed at intervals of 20ms (160 samples are 50 data transmission for 1 second) by dividing 8000 samples of data per second, and UDP packets including 160 samples (=160 bytes) and dummy data having a size of RTP header included in the RTP packet (default 12 bytes+header or extension data included in type according to codec) are generated and received, and a packet is generated and tested in a certain standard time.

In other words, if the ULAW is used and the call quality prediction test is performed within 10 seconds, the present invention generates 500 packets, and the dummy data included in each packet includes the transmission time information of the current transmission side. When the other party retransmits, the transmission side calculates an average RTT (Round Trip Time) by comparing the received time and the transmission time included in the dummy data of the packet for 500 packets, obtains the number of missing packets and the RTT value of each packet and the deviation (deviation degree) value of the average RTT value, and predicts the call quality using the above values. When a wireless network is included, checking the integrity of the original data may also be included in the call quality prediction process.

In a voice codec such as AMR (Adaptive Multi Rate), since a variable transmission rate is used according to the network condition, UDP packets are also similar to the actual case, and the variable transmission rate can be applied according to the network condition.

In the case of video, most of the video information uses the GOP (Group Of Pictures) concept consisting of I-frame (Intra Frame) including independent information of the entire video, P-frame (Predictive Frame) encoded with reference to the previous I or P-frame, and B-frame bi-directionally predictive Frame encoded with reference to the previous I or P-frame, and since frames are different in size, GOP structures themselves may be configured in other forms, statistical methods and the like may be used, and UDP packets may be transmitted in a state similar to the video frames at the time of actual call by adjusting the transmission interval and packet size to be similar to the actual state. The actual RTP packet and the UDP packet used in the present invention are relatively light with reference to fig. 13.

Fig. 14 is a schematic diagram illustrating in detail the relationship between a network telephony terminal and a network telephony server or SBC. More specifically, fig. 14 is a schematic diagram showing in detail the relationship between the

network telephone terminals

124, 126 and the network telephone server 200.

The first network telephone terminal 124 is a network telephone terminal connected via a wireless network, such as a smart phone. Network telephony terminal one 124 is wirelessly connected to BTS (Base Transceiver Station) or Node B1900 via BSC (Base Station Controller) 2000 that manages the wireless network through BTS1900 or RNC (Radio Network Controller) 2000 that manages the wireless network through Node B1900.

Then, the first network telephone terminal 124 is connected to a circuit switching network, may be connected to an MSC (Mobile Switching Center (omitted in fig. 14), or is connected to a packet switching network such as the internet, is given an IP address via the SGSN2100 and the GGSN2200, and is connected to the network telephone server 200 directly or as the case may be via the SBC1704 via the internet composed of the L3 Switch, the L2 Switch, the L4 Switch, and the like, which are the router 2600.

The network telephone server 200 functions as a P-CSCF of an IMS network, a SIP Proxy of a wired network, an IP-PBX for personal enterprises, and the like, and is a first SIP object of a session with the network telephone terminal one 120 through SIP in the SIP network from the viewpoint of the SIP protocol.

The first internet protocol terminal 124 may be given a personal IP by the GGSN2200 due to a policy of a communication company or the like, and then be converted into a public IP by the NAT device to be connected to the internet protocol server 200 via the internet, and in this case, to solve the NAT transit problem, may be connected to the internet protocol server 200 via the SBC 1704. In addition, when a call is generated between a calling terminal and a called terminal, media is generally routed through the SBC, and when the SBC1704 is not used even if there is a NAT transit problem, media can be relayed by the web telephony server 200 when the call is generated.

The second Network telephone terminal 126 is connected to a wired Network via an Access Network (Access Network) such as xDSL via a wireless router 2300 and a DSL modem 2400. DSLAM (Digital Subscriber Line Access Multiplexer) 2500 is provided at the carrier and is connected to the DSL modem2400 to provide internet access services to the network subscriber. Thereafter, as in the case of the network telephone terminal one 124, the network telephone server 200 is connected directly or as the case may be via the SBC1704 through the internet composed of the L3 Switch, the L2 Switch, the L4 Switch, and the like, which are the routers 2600.

Depending on the carrier's policy, the carrier may provide personal or public IP to the subscriber via DSL modem2400, even if public IP is available, if a wireless router is used, network telephony terminal two 126 will be given personal IP. At this time, as in the case of the network telephone terminal one 124, in order to solve the NAT transit problem, the network telephone server 200 is connected via the SBC1704 or the network telephone server 200 relays media.

In the present invention, in order to predict the call quality state of any of the

network telephone terminals

124 and 126 before call generation in response to the above-described situation, the call quality is predicted by a transmission test for the section between the network telephone server 200 and the

network telephone terminals

124 and 126 or between the SBC1704 and the

network telephone terminals

124 and 126 as a reference for the call quality state of the

network telephone terminals

124 and 126 in the Idle state. That is, in a state before a call destination is determined, even if the communication destination is connected to any other party, the call quality is predicted for the medium transmission path having the longest distance in common. In case that the public IP is obtained from the network telephone terminal one 124 through the GGSN2200 in the case of a wireless network or from the network telephone terminal two 126 through the DSL Modem2400 in the case of a wired network due to, for example, the IPv6 environment, the problem of overlapping with the session quality prediction interval of the present invention occurs because media is directly transferred to the counterpart terminal without via the SBC1704 or the network telephone server 200 in the actual session, and there is an advantage in that the state of the network telephone server 200 can be better reflected when compared to the case that measurement is performed through another session quality measurement device other than the network telephone server 200.

Fig. 15 is a sequence diagram illustrating a process of predicting call quality of a counterpart according to an embodiment of the present invention.

In fig. 15, a method of predicting call quality may be performed at one of the first and second network communication devices to predict call quality at the opposite party.

The SIP transaction requesting unit 21 may optionally include address information (IP address, port number) of the party for use in the call quality prediction of the party, and may transmit SIP (Session Initiation Protocol) including the call quality prediction request to the party (step S1501).

The SIP transaction response receiving section 22 receives a SIP transaction response containing address information (IP address, port number) of the counterpart from the counterpart in response to the SIP transaction request (step S1502).

The call quality prediction unit 23 uses 1) an RTP packet that is independent of whether or not the actual medium is included, by using address information of one party and address information of the other party; 2) RTCP packets; or 3) performing a transmission test with the counterpart to predict the call quality for communication of a disguised UDP packet (hereinafter referred to as "transmission test packet") disguised as RTP by the counterpart (step S1503).

After the step (a), the SIP transaction response transmitting unit 24 first performs the step (c) using the address of the party to obtain the call quality prediction result, and then transmits the result to the party by including the result in the SIP transaction response (step S1504).

The call selection decision unit may store predicted call quality based on the packet loss rate and the transmission delay time predictions for the N transmission test packets to decide the call selection for the counterpart (step S1505).

In fig. 16, the method of predicting call quality may be performed in a network telephony server or SBC without the call generation process predicting call quality to a plurality of network telephony terminals.

The call quality prediction unit 23 uses 1) RTP packets that are independent of the inclusion or non-inclusion of the actual media in the section between the IP telephone server or the SBC and the IP telephone terminal; 2) RTCP packets; or 3) performing a transmission test with each of the plurality of network telephone terminals for communication of a masquerade UDP packet (hereinafter referred to as a "transmission test packet") masquerading as RTP to the partner so as to predict a call quality (S1601 step).

The call selection decision unit 25 provides the prediction result of the call quality to the call partner or performs information provision or connection attempt to the available network telephone terminal having the most excellent call quality based on the prediction of the respective call quality (step S1602).

The above-described embodiments are provided for illustrating the present invention and not for limiting it, and it should be understood by those skilled in the art that the present invention may be modified, changed or substituted for equivalents thereof without departing from the spirit and scope of the present invention, which is intended to be covered by the scope of the appended claims.

Description of the reference numerals

10: call quality prediction system 20: communication quality prediction service device

21: SIP transaction requesting unit 22: SIP transaction response receiving unit

23: the call quality prediction unit 24: SIP transaction response transmission unit

25: the call selection determination unit 26: control unit

30、40：IP Header 32、42：UDP Header

34：RTP Header 36：RTP Data

44: the transmission time 46 contained in the UDP packet: dummy Data

100. 102, 104, 106, 108, 110, 112, 114, 116, 118, 120, 122, 124, 126: network telephone terminal

200: network telephony server 300: communication quality prediction server

400、402、404、406、408、410：P-CSCF(Proxy CSCF)

500、502、504、506、508：S-CSCF(Serving CSCF)

600、602：I-CSCF(Interrogating CSCF)

700、702：CSCF(Call Session Control Function)

800、802：IBCF(Interconnection Border Control Function)

900、902：IBGF(Interconnection Border Gateway Function)

1000：BGCF(Border Gateway Control Function)

1100：MGCF(Media Gateway Control Function)

1200：SGW(Signaling Gateway) 1300：MGW(Media Gateway)

1400：PSTN(Public Switched Telephone Network)

1500：SIP AS(Application Server)

1600: IMS (IP Multimedia Subsystem) net

1700、1702、1704：SBC(Session Border Controller)

1800、1802：SIP Proxy

1900: BTS (Base Transceiver Station) or Node B

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

2100：SGSN(Serving GPRS Support Node)

2200：GGSN(Gateway GPRS Support Node)

2300: wireless Router (with Wireless Router)

2400：DSL(Digital Subscriber Line)Modem

2500：DSLAM(Digital Subscriber Line Access Multiplexer)

2600: router 2700: backbone network

Claims

1. A method of predicting call quality between a first network communication device and a second network communication device, the method comprising:

When at least one of a NAT transit performing device, a media transcoding performing device, and a Topology performing device exists between the first network communication device and the second network communication device, dividing an entire section between the first network communication device and the second network communication device into independent sections divided by the at least one device, and performing the call quality prediction in sequence for each independent section by performing independent execution of a transmission test, thereby completing the call quality prediction between the first network communication device and the second network communication device.

2. The method for predicting call quality of claim 1, wherein,

in the above-mentioned transmission test, the transmission data,

when a NAT device is present in the independent section, NAT pinholes for the address information are generated in advance by using the address information of both ends of the independent section through communication of the independent section of the NAT device.

3. The method for predicting call quality of claim 1, wherein,

in the above-mentioned transmission test, the transmission data,

and receiving and transmitting N transmission test packets at two ends of the independent interval in sequence, and confirming RTT of each transmission test packet and loss of each transmission test packet to predict the call quality, wherein N is a natural number more than 2, and RTT is round trip time.

4. The method for predicting call quality according to claim 3, wherein,

and storing predicted call quality predicted based on the packet loss rates and the transmission delay times for the N transmission test packets to determine a call selection for the first network communication device or the second network communication device.

5. The method for predicting call quality of claim 4, wherein,

when the first network communication device or the second network communication device is constituted by a plurality of network telephone terminals, a specific network telephone terminal is selected to perform a call based on the predicted call quality for each of the plurality of network telephone terminals.

6. The method for predicting call quality of claim 5, wherein,

when the communication between the first network communication device and the second network communication device belongs to voice communication, a network telephone terminal which can be currently used and has the least transmission time delay is selected as the specific network telephone terminal.

7. The method for predicting call quality of claim 5, wherein,

when the communication between the first network communication device and the second network communication device belongs to data communication, a network telephone terminal which can be currently used and has the least packet loss rate is selected as the specific network telephone terminal.

8. The method for predicting call quality of claim 1, wherein,

and storing the call quality prediction for the independent section in a cache memory, and updating the cache memory when a specific time is exceeded.

9. The method for predicting call quality of claim 1, wherein,

when the prediction of the call quality for a specific independent section fails, the first network communication device or the second network communication device receives information on the independent section regarding the cause of the failure.

10. The method for predicting call quality of claim 1, wherein,

the following information is transferred: the device for performing NAT translation, the device for performing media transcoding, and the device for performing Topology sharing record and transfer the own address information in the call quality prediction message or the call quality prediction response message, and identify devices adjacent to each other among the device for performing NAT translation, the device for performing media transcoding, and the device for performing Topology sharing to form the independent section, thereby predicting call quality.

11. A method of predicting call quality predicts call quality to a network telephone terminal in Idle state,

when there are a device for performing NAT transfer, a device for performing media transcoding, and a device for performing Topology sharing between the network telephone terminal and the counterpart telephone terminal, a transmission test is performed on a section between the network telephone terminal and the device to predict call quality, wherein the section is the following section: even if the network telephone terminal is connected to any other party by telephone, the network telephone terminal can be the longest distance section of the common media transmission path.

12. The method for predicting call quality of claim 11, wherein,

in the above-mentioned transmission test, the transmission data,

when a NAT device is present in a section between the network telephone terminal and the apparatus, NAT pinholes for the address information are generated in advance by using address information at both ends of the section between the network telephone terminal and the apparatus through communication between the network telephone terminal and the apparatus of the NAT device.

13. The method for predicting call quality of claim 11, wherein,

In the above-mentioned transmission test, the transmission data,

n transmission test packets are sequentially transmitted and received to and from both ends of a section between the network telephone terminal and the device, and RTT of each transmission test packet and loss of each transmission test packet are confirmed to predict the call quality, wherein N is a natural number of 2 or more, and RTT is round trip time.

14. The method for predicting call quality of claim 11, wherein,

a prediction of call quality for a section between the network telephone terminal and the device is stored in a cache memory, and the cache memory is updated when a specific time is exceeded.

15. A call quality prediction service device that performs a method of predicting call quality to a network telephone terminal in an Idle state includes a call quality prediction unit that performs: