Patent Application
20080320132
The invention pertains to the field of telecommunications.
Telecommunications have tended to evolve towards all-IP, i.e. exchanging all multimedia data using Internet Protocol, commonly abbreviated IP. In IP, the digitized data, whether it is multimedia data (images, sound, video) or voice data (generally for telephone applications) are made up of IP packets placed in frames and then transmitted over the network, whether it is a local are network (LAN), metropolitan area network (MAN), or wide area network (WAN).
Communication between two communicating entities may be conducted using two types of dialogue: connectionless-oriented and connection-oriented.
In connectionless-oriented, the packets are transmitted by the sending entity without said entity having previously verified whether the receiving entity is present on the network.
In connection-oriented, the entities, prior to transmitting the data itself, conduct a negotiation phase during which the connection is established. After the connection has been established, the data is exchanged. Then, once the exchange of data has completed, the connection becomes free. At the time the connection is opened, the entities may additionally negotiate the quality of service, or QoS, for which parameters defining the permissible limits of the communication are exchanged between the entities.
One currently popular network architecture offers an adequate framework for multimedia communication between communicating entities in connection-oriented mode: IMS (IP Multimedia Subsystem), developed by the 3GPP consortium (Third Generation Partnership Project).
To establish, modify, and terminate the communication sessions, as well as to perform authentication, IMS uses the protocol known as SIP (Session Initiation Protocol).
In the session level of the protocol stack of datagrams exchanged between two network entities, the most commonly used communication protocol today is the one known as RTP (Realtime Transport Protocol), used in combination with the one known as UDP (User Datagram Protocol), which is used in message level of the stack.
These two protocols are associated with control protocols, used whenever the network encounters problems affecting communication between the entities: routing problems, disconnection problems for one or more entities, or a network breakdown.
In the session level, the control protocol associated with the RTP protocol is the RTCP protocol (Realtime Transport Control Protocol), one essential function of which is to inform the communicating entities of the quality of service. In the message level, the commonly used control protocol, associated with the UDP, is the ICMP protocol (Internet Control Message Protocol).
In practice, communication between two entities in connection-oriented mode involves:
In one conventional operating mode, whenever the network or an entity encounters problems (breakdowns or disruptions in the network, poorly handled handovers in mobile networks, etc.), the data packets exchanged may be incomplete or missing. In certain nodes of the network, the detecting of this fault generates control messages addressed to the recipient entity, intended to inform it of the degradation in the quality of service. As quality of service is considered a priority in current network policies, the acceptance of these control messages by the application generally leads to its immediate or delayed closing, correlated with the need, when the connection is restored or repaired, to reopen the application, going through all of the steps prior to reading the data: authentication, etc.
The result is a loss of time—and data—for the user.
The invention is meant to perfect existing networks, notably by remedying the abovementioned problems.
To that end, the invention discloses a communication method as defined in the claims.
Other characteristics and advantages of the invention shall become more apparent upon examining the description below, and the attached drawings, in which:
Each entity 2, 3 comprises a communication interface 5 capable of establishing a connection with the network 4 and handling the communication exchanged using IP, and a software application 6 that can play the data contained in the form of packets in the messages exchanged over the network 4.
The communication interface 5 and the application 6 are, within each entity 2, 3, configured to handle data exchange protocols in connection-oriented mode, particularly RTP.
When communication is established between two entities 2, 3 (naturally, communication between a number of entities greater than two may be provided for), a sending entity 2 sends a data flow in the form of packets to a receiving entity 3.
The receiving entity 3 is connected to a proxy server 7 integrated into a core network 8—particularly an IMS network—implemented within the network 4, and through which the messages transmitted to the receiving entity 3 travel.
The proxy server 7 includes two functional modules, to with:
Such control messages are included in the data flows traveling on the network 4 to the recipient entity 3, as soon as problems are detected within the network 4 (for example, in a gateway), affecting either the connection itself (breakdown or unavailability of the network), or the quality of the data transmitted (for example, packet loss). It should be noted that the notion of quality of service (QoS) is meant to qualify this type of problem.
The architecture 1 described above makes it possible to organize communication between at least two entities 2, 3, to with a sending entity 2 and a recipient entity 3, in the following manner.
A first step 100 consists of the sending entity 2 sending a data flow (images, sound, video, voice) in the form of packets included within an IP frame, intended for the recipient entity 3.
A second step 200 consists of the proxy server 7 receiving the data sent by the sending entity 2.
A third step 300 consists of the proxy server 7 examining the data using the filter module 9 in both the message and session levels of the frames in order to respectively detect ICMP or RTCP control messages, related to the quality of service.
A fourth step 400 consists of the proxy server 7, and more precisely the filter module 9, once control messages have been detected by said filter module, intercepting these messages and routing them to the capture module 10, where they are stored—or destroyed—without being transmitted to the recipient entity 3 whenever these messages are defined as potentially affecting the working order of the application.
It is possible to configure the filter module 9 to:
In practice, this configuration is performed by a network administrator.
For the data flow sent by the sending entity 2 a fifth step 500 consists of the proxy server 7, and more precisely its filter module 9, sending anything whatsoever to the recipient entity 3, regardless of the quality of service—i.e, from the viewpoint of the data, whether or not the packets transmitted are complete, and from the viewpoint of the proxy server 7, whether or not the control messages were intercepted.
In practice, because the RTP and RTCP flows are generally treated by different ports, the data flows (in RTP mode) do not necessarily travel through the filter module 9, which is preferentially linked only to the RTCP port.
In this manner, the application 6 is kept open no matter what the quality of service is, and in particular, no matter what the status of the network 4 or connection is. In particular, if the network 4 is disrupted (this is a common occurrence in cellular telephone networks whenever a telephone loses the network, such as due to an obstacle placed within the air interface, such as a tunnel), it is not necessary to reopen the application 6—by going through the preliminary phases comprising, for example, the authentication step—once the network 4 is restored. Though such a functionality goes against the current trend that favors quality of service above all else, it does make it possible for users to save precious time.
We have seen that the term “entity” may cover not only any communicating device, as described above, but also any software application that may receive data from the network. Furthermore, it should be noted that, as is depicted in
The fact that the proxy server 7 is, in the foregoing description, incorporated into an IMS network core is a particular, non-limiting example. Such a server 7 may be incorporated into another type of network, particularly within a local area network of an Internet service provider, and providing, for example, video services that are streamed, i.e. distributed live or with a short delay (as opposed to downloading).
| Number | Date | Country | Kind |
|---|---|---|---|
| 0704525 | Jun 2007 | FR | national |
