FIELD OF INVENTION

This invention relates to a method for generating a real time connection between a first endpoint and a second endpoint as well as a corresponding telecommunications system.

BACKGROUND OF THE INVENTION

A typical telecommunication system for real-time communication, or RTC, is based on standardized multimedia technology designated as RTCWeb or WebRTC (the term “WebRTC” will be used herein in place of either designation) by the IETF (Internet Engineering Taskforce) and W3C (World Wide Web Consortium), or generally called RTC, in which a number of similarly standardized protocols are used. The ICE (Interactive Connectivity Establishment, RFC 5245) method used to determine the optimal RTC payload connection in turn uses the STUN (Session Traversal Utilities for NAT (Network Address Translation), RFC 5389) protocol to run so-called “connectivity checks.” These checks determine whether the route in question could in principle be used for the desired payload connection.

In VoIP (Voice-over-Internet-Protocol), the endpoints of a real-time connection (RTP/RTCP) are connected to each other as directly as possible, i.e., without interconnected servers. However, the shortage of IPv4 addresses has led to the fact that in many cases NAT or NAPT (Network Address & Port Translation) is used between Intranet and Internet. This makes it impossible to establish direct contact from the Internet to an Intranet endpoint without taking special measures. This involves ICE (Interactive Connectivity Establishment), which in the VoIP example works together with the SIP signaling protocol and the STUN and TURN (an extension of STUN) protocols. Because ICE does not require any presets for possible connections, as part of its operation all connection candidates are first determined by the endpoints and then simply tested (go/no go, the STUN-based “connectivity check”). These checks are done using a checklist. The list contains all candidates, sorted by priority (from the presumed best connection at the top to the presumed least suitable connection, e.g., via TURN server, at the bottom). The algorithm for establishing the priorities is described in the ICE RFC, but contains only fixed rules that do not account for the current network load or any network interferences.

Because it is important in this description to understand the various scenarios described in the standard, these scenarios are briefly outlined below. The connectivity checks are performed according to the standard in precisely this (priority) sequence (from top to bottom), as shown inFIGS. 1-3.

Next comes the question of why it should be possible for a direct host-host connection (seeFIG. 1) to be of poorer quality than one of the other two connections. The answer lies in the fact that the scenarios illustrated above show only the logical structures, without considering the physical characteristics.FIG. 5(logical network view on top and two physical expressions underneath) demonstrates this concept; although it is logically the same configuration, the quality of the connection established through the two VPN routers (R1, R2) differs significantly from the direct connection (via Ethernet) shown on the left. The connection through the two VPN routers generally has noticeably poorer quality-of-service values.

A VPN can similarly be used in all scenarios, without it being known to the ICE method. Thus, it is always a good idea to consider quality of service in the priority allocation.

However, at present only a few predefined criteria are used as described to decide which route is finally chosen for the payload (i.e., user data). The quality-of-service aspects that are important in the RTC (real-time communication) environment still are often not considered.

At present, with STUN only a “go/no go” test is performed (“connectivity check,” i.e., a test message either does or does not make a complete circuit from sender to STUN server and back again). In particular, QoS (quality of service) aspects that are important for real-time applications are not considered. Of course, in ICE the various alternatives (called candidates) are assigned priorities that should contribute to quality improvement (and, if applicable, cost reduction), but strictly speaking are based on assumptions or guidelines, as shown in the following examples of prioritizing criteria:IPv6 before IPv4, i.e. strategic guideline;Direct connection (with no address conversion) before NAT; this is OK with the IP technology, but does not allow any QoS statements;NAT before TURN (relay); TURN servers are potential bandwidth bottlenecks, and the assumption is therefore understandable, but reliable QoS statements are also not possible.

The aforementioned STUN connectivity checks are performed in the sequence established by the preceding prioritization. However, the prioritization itself is not influenced by either STUN or other QoS-related criteria.

In summary, the standard IETF ICE procedures, e.g., for WebRTC or SIP systems, test only the basic connectivity (“STUN connectivity checks”) of the offered RTC payload candidate address pairs for the (ICE) communication endpoints (clients, application servers). However, there is no function for considering the QoS characteristics of the various candidate payload paths.

SUMMARY OF THE INVENTION

The invention is intended to eliminate the aforementioned disadvantage when generating an RTC connection and to generate more efficient RTC connections in the future.

This objective is achieved with the method, the computer program product or computer program, the machine-readable data carrier with a computer program stored on it and the telecommunication system that are here described and claimed.

According to the invention, the (computer-implemented) method for generating an RTC connection between a first endpoint and a second endpoint in an IP network, in which the known STUN connectivity check procedures of an ICE method are used, is executed as follows: First, a list of possible connection paths-even all possible connection paths-between the first endpoint and the second endpoint is generated. Then, for each of the possible connection paths on the list (also called candidates), a respective priority is established that determines the sequence for the successive connectivity checks in the STUN process, to see whether a connection between the first endpoint and the second endpoint can be established using that particular connection path. Next, the RTC connection between the first endpoint and the second endpoint is established according to the determined priority, wherein the system first attempts to establish the RTC connection using the connection path with the highest priority. If this succeeds, no further steps are necessary. However, if it fails for any reason, then the system attempts to establish the RTC connection using the connection path with the next highest priority. These attempts continue, following the determined or established priority sequence, until an RTC connection is finally established.

The invention is characterized in that, for establishing the respective priority, not only are the criteria known to date applied, but also the respective quality-of-service value is determined for each possible connection path and is included in the list used to determine the priority of that connection path.

Using this process means that, by using available statistics on the respective quality of service (also designated as QoS), the quality-of-service or QoS values, which are sometimes critical for real-time applications, are considered, making it possible to establish corresponding real-time connections, or RTC connections, more efficiently.

Considering QoS in ICE procedures (STUN connectivity checks) according to the invention allows the likely best ICE address pair from a QoS standpoint to be tested first. Unnecessary and time-consuming STUN connectivity checks can thus be avoided, which leads to shorter real-time connection establishment times, less network load, and the selection of the ICE candidate pair (connection path) with the best QoS characteristics (compared to the alternatives).

According to one advantageous version of the invented method, the first endpoint also transmits the quality-of-service values for the possible connection paths between the first endpoint and the second endpoint to other endpoints by using STUN messages. Because here the term “first endpoint” is not intended to indicate a limitation to any particular endpoint, all endpoints therefore transfer knowledge about quality-of-service values to the remaining endpoints. In other words, the QoS data for each possible connection path (also called ICE candidate pairs) are exchanged back and forth in STUN messages. In this way, each endpoint adds the corresponding information from its partners to its own QoS statistics. Not only the QoS data for previous “real” connections, but also the results of the connectivity checks performed for the present call to be placed (which can also be called an RTC connection), will be included in the current ICE candidate selection. The QoS data exchanged via STUN connectivity checks are also integrated in QoS statistical data for the ICE endpoint and can be considered for future RTC connections or calls. This is especially advantageous when no past QoS data for the ICE candidate pair are available yet at that terminal.

According to one embodiment of the invented method, quality-of-service values known only to network infrastructure elements (such as routers) but not to the endpoints are inserted into STUN connectivity check messages (typically “request” and “response”) in order to send information to the endpoints that otherwise (i.e., without the invented method) would not be available to them. In this case, preferably the network infrastructure elements themselves perform this insertion, providing their own QoS knowledge. In this way, for example, a router can insert its available information—that the router queue currently has a packet loss rate of 15% for a “video” type of payload or user data connection in that direction, which requires so-called Traffic Shaping—into the STUN response message. This can be taken into account at the endpoint acting as the so-called controlling ICE client endpoint, which receives the STUN response message, and also considered for the ICE candidate pair selection, for the video connection to be established (also called a video call), and for updating the QoS statistics at the affected endpoint for subsequent calls or RTC connection. This can further improve the efficiency of establishing ICE connections.

It is advantageous to define groups of endpoints whose connections can be expected to have the same quality of service value, so that preferably each group corresponds to at least one or part of one subnet for the affected endpoint. In other words, this means that preferably all members of a group would be located in the same subnet. This permits the advantages of reducing data volume and making assumptions about the connection's quality of service on endpoints with which no connection has existed until now, as long as they are members in a group with a connection whose quality of service is known. If the determined quality-of-service values for connection paths to various endpoints within a group are different, these quality-of-service values preferably are averaged, wherein the current values are considered or weighted more heavily.

According to one embodiment, a central point of the IP network is used to send its available quality-of-service values to the controlling endpoint (also called an ICE controlling endpoint). Because such a central point has a higher traffic volume, “better” QoS data are received for use in the predictions. This type of central point can be, for example, a gateway, a session-border controller, or a media server (such as a server-based real-time application).

It is advantageous if the determined quality-of-service values for the possible connection paths or candidate pairs can be stored in a central unit (such as a Call Admission Control or CAC) from which all endpoints can request them. The use of such centralized services or pieces of knowledge (such as QoS, performance) offers the advantage that the performance requirements for the client or endpoint can be kept low. It is obvious, however, that an interface is required here between the ICE client and such a central QoS application.

In addition, a computer program or computer program product for executing the aforementioned method, and a machine-readable data carrier on which such a computer program is stored, are considered part of this invention.

The objective of the invention is also achieved with a telecommunication system having a first endpoint, a second endpoint (as well as multiple additional endpoints, normally), and an IP network through which the endpoints are connected to each other, wherein the endpoints are configured such that they are suitable for executing the described invented method.

The various aspects of the invention can be summarized as follows:

1. Expansion of the “STUN check” ICE procedure:

In addition to the parameters defined in RFC5389 (STUN), QoS-related data are inserted and later considered when prioritizing connection candidates.

2. Expansion of both endpoints so that they can determine QoS statistical data from earlier (or currently existing) connections and assign them to certain targets (target groups) and, if applicable, paths through the IP network. In addition, they are capable of “learning” statistical data from other endpoints.
3. Expansion of the first endpoint, such thata. its STUN client can insert QoS statistical data into the STUN request message,b. the STUN client can acquire QoS data from the STUN response message, in order to update or add to its own statistical data, andc. prioritization of the connection candidates, and with it the candidate selection, can be influenced based on self-determined data and on data received in b. above (from earlier checks).
4. Expansion of the second endpoint, such thata. its STUN client can acquire QoS data from the STUN request message, in order to update or add to its own statistical data, andb. its STUN server can insert its QoS statistical data into the STUN response message.
5. Optional expansion of network infrastructure elements (e.g., routers) so that they can insert their “QoS knowledge” (regarding current packet loss and packet drop for video traffic (video router queue), for example), into STUN messages.

Obviously, for this invention the invented method and the invented telecommunication system are closely interrelated. This means that features described with respect to the method can also be provided or required as part of the telecommunication system, and also, conversely, features and characteristics described with respect to the telecommunication system also apply to the method, even when this is not expressly stated.

Additional advantages, features, and characteristics of the present invention are presented in the following description of advantageous embodiments with reference to the drawing.

