The present invention is related to real-time data transmission through data communication networks. In particular the present invention discloses an arrangement and a method for high reliability two ways communication in real-time through one or more firewalls advantageously by way of using HTTP/HTTPS protocols and the use of such an arrangement and method.
To protect a PC or network against unauthorized intrusion (hackers), firewalls are used to control all communication. More and more companies and private users install firewalls in order to protect their network. Firewalls do not know all communication protocols on the Internet, so it is necessary with a proxy to let certain protocols through the firewalls. This is in particular the case when the networks are NATed (Network Address Translation, i.e. private addresses are used on the LAN segment). The firewalls today do not handle real-time data wells. With the increased usage of such as IP telephony and real-time online games there is a demand for applications that let such traffic through firewalls in a secure way.
There are many different proposals for solutions within this area, however, currently no good solutions exist and no one seems to be on the way: The big vendors are looking into firewall control protocols that let the applications open and close ports or gates on the firewall. Such solutions have two serious drawbacks. One is that certificates have to be distributed to all applications that are allowed to perform such operations; another drawback is that the security is strongly degraded according to the number of applications that are allowed to perform such operations.
Some of these solutions are mentioned in the following.
Arrangements showing a sender receiver arrangement for two-ways communication in real time through one or more firewalls wherein the arrangements includes at least a real tunnel client behind a firewall and a NAT is known from the following US publications: U.S. Pat. No. 6,687,245 B2 (Fangman et al.), US 2003/0093563 A1 (Young et al.) and US 2002/0150083 A1 (Fangman et al.), however all these publications make use of firewall control protocols for opening and closing ports. Hence the problem regarding opening and closing of ports or the use of dedicated hardware.
From the foregoing it should be evident that there is a need for a reliable and secure solution facilitating real time bidirectional communication without the need for opening of ports in firewalls or dedicated hardware.
It is an object of the present invention to provide an arrangement that eliminates the drawbacks described above. The features defined in the independent claim enclosed characterize this arrangement.
In particular, the present invention discloses a sender, receiver, arrangement for high reliability two ways data communication in real time, through one or more firewalls wherein that the arrangement comprises at least a real tunnel client behind a firewall and a RealTunnel server or a media engine on the outside of said firewall.
In order to make the invention more readily understandable, the discussion that follows will refer to the accompanying drawings.
In the following, the assumptions of the present invention will be described, followed by the specific aspects of the invention further, for readability, in the following the wording HTTP is to be understood as HTTP or HTTPS. Still further whenever the wording HTTP or HTTPS appears it is to be understood that HTTP/HTTPS protocols are encapsulated in TCP protocols hence TCP HTTP/HTTPS “packets” are by definition TCP packets.
The RealTunnel client can be deployed in many ways:
The key concept is in the first way. In this way no external personnel has to configure or deal with any configuration of any FW, network etc. Another interesting scenario is the second one. In this second case, still no configuration of any FW, network etc. has to be done.
The RealTunnel client will be designed in a modular way such that new applications and or protocols rapidly can be supported.
The present invention will advantageously work in two different scenarios: The main approach is to let a third party like MSN net or an external SIP registrar host the actual users and instant messaging services and the disclosed arrangement reside in the middle. I.e. the arrangement according to the present invention only does what is required in order to handle the media and NAT parts and not the “signaling” and the main instant messaging functionality parts. The first release supports XP Messenger used in combination with Passport. An alternative approach for consideration is that everything is hosted by the IP right owner according to the present invention, the instant messaging services, potentially a SIP client etc. Such an approach would however require much more development time.
UDP is nearly almost used for two-way real-time connections. HTTP is running over TCP. TCP's drawback is that it doesn't maintain the good real-time characteristics of UDP. We have identified a mechanism for simulating UDP behavior on TCP.
The users may pay for different bandwidth classes. The RealTunnel according to the present invention can perform policing and control the actual bandwidth used by the users by counting IP packets. A willingness to pay mechanism might be provided giving those with high willingness to pay better QoS than other. This product may also support billing, pre and post paid.
A provisioning system is included for operations like: Adding user accounts, modifying user accounts, deleting these, adding balance on user account, check current registrations, see current calls etc. etc.
The goal of the present invention is to let HTTP traffic pass through firewalls and then control all HTTP RealTunnel clients and servers, the present invention does not have to be fully HTTP compliant. This means that all that has to be done to be HTTP compliant in order to bypass firewalls. The HTTP server has many possibilities for being optimized.
High Level Description
The PC application is configured to send data to the RealTunnel client, and not the unavailable receiver on Internet. If the RealTunnel client is behind an HTTP proxy, the RealTunnel client automatically is configured with the HTTP proxy address and port. These data automatically are extracted from Internet Explorer settings, if IE is installed on the client computer. If not, the user must manually enter the data.
The RealTunnel clients will register at start-up towards the RealTunnel server according to the present invention.
Media and Signaling Paths
Several call scenarios exist:
In order to replace Messenger's SIP and RTP streams, one must have a SOCKS server to receive the TCP signaling, listen for messages with SIP IP RTP/UDP addresses in it, and replace these.
The SIP proxy must do the same, gain up the SDP in INVITEs, replacing the media (RTP) addresses with the local RTP proxies.
Protocol Architecture
See
RTP over TCP
When tunneling RTP in TCP, the RealTunnel adds a three byte header field (address) in the beginning of the TCP data field as shown in
The three byte RT header states the length of the RTP packet (two bytes) and whether the payload is RTP or RTCP (one byte). On good networks as well as when Nagle's algorithm is disabled, one TCP packet usually contains one RT header and one RTP packet as indicated in
HTTP Support
HTTP 1.0 Support
HTTP proxies such as squid only allow one outstanding request, i.e. one GET or POST from the client towards the server. The RESPONSE must be processed before a new GET or POST might be retransmitted. This is the reason why it is important to setup two unidirectional HTTP/TCP connections when handling real-time data, i.e. one connection for transmitting data and one connection for receiving data. It is important to keep the GET or POST outstanding as long time as possible to save bandwidth and processing power. I.e., to spawn a minimum of two TCP channels from each RealTunnel client towards a Media Engine. One is dedicated for data transmitted from the client towards the server, see
HTTP data as shown in
HTTPS Support
HTTPS currently is enabled. The advantage by HTTPS is that on many networks it is possible to use TCP directly after the normal setup procedure.
The setup procedure on networks where HTTPS proxies are required is that the HTTP client, the RealTunnel client, sends an HTTP connect message towards the HTTP proxy. The HTTP proxy then sends a response back. In some cases plain TCP can then be used directly between the RealTunnel client, the HTTP proxy, the RealTunnel server and the Media Engine. In other cases SSL have to be used. SSL adds however less overhead than HTTP, at least when encryption can be turned off on the SSL layer.
Authentication of Sessions
Before each new connection is setup from any TCP/HTTP client towards a RealTunnel server or an ME, an authentication procedure before accepting the connection on the application level is performed. According to the present invention one advantageously has to wait for the first portion of data that includes a user id and a hashed password before accepting the connection on the RealTunnel server and ME side. When the connection is setup, one may still check the user id and password on each datagram.
QoS Mechanisms
Improving TCP Real-Time Characteristics by Caching and Dropping Packets
The RealTunnel have implemented several mechanisms to make TCP get UDP behavior. One of the features is based on caching and dropping techniques. The RealTunnel system has two levels of cache and possibilities for dropping packets.
Cache level 1: Cache level 1 is the TCP sender buffer. Currently the RealTunnel components don't have direct access to this buffer, but this can be implemented. Currently RealTunnel only is able to detect when the TCP sender buffer is full, not to what degree it is partly full. The TCP socket write function always returns the number of bytes successfully written down to the socket. Since the application also always knows how many bytes it tried to transmit, it knows when cache level 1 is full. The optimal cache size can be dependent on such as throughput, network condition etc. The ME has currently configured this value fixed to be 8 Kbytes. The RealTunnel client has set this value fixed to 4 Kbytes. The ME drops packets when cache level 1 is reached.
Cache level 2: It is possible to add a cache level only contained within the application. Currently the RealTunnel client has implemented this cache level. This cache level makes it easier to manage RTP packets. Since RTP packets are dropped when cache level 1 is reached, cache level 2 is used for being able to delete whole RTP packets within the cache level 2 buffer. The RealTunnel client has full control of the fill level of cache 2.
Drop packets: Packets are dropped as described above when cache level 1 and 2 is exceeded.
Signaling information is cached with 64 Kbytes buffers since it is important that this information is forwarded.
Mechanisms for Increasing Bandwidth in Congested Networks
A problem when using TCP as a bearer of real-time data is that one TCP connection not always provides the necessary throughput. This is in particular a problem when transmitting voice codec data. A solution to this problem is to spawn several TCP connections when one TCP connection not is sufficient. It is here assumed that the new TCP connections are initiated and spawned by the RealTunnel client.
Different ways of identifying when to spawn new TCP connections:
Base it on the TCP window size: This feature or possibility is currently not implemented. It is possible to get direct access to the TCP window size when operating on the OS (Operating System) level. For RealTunnel clients on client computers that would typically imply making a driver. The TCP window size is the minimum of the sender's congestion window size and the receiver's window size. The TCP window size can be used to decide when to spawn new TCP connections. Typically new channels can be spawn when the TCP window size decreases in size since this might indicate packet loss and a degraded network link.
Base it on RTCP messages: RTCP reports many parameters that can be used to decide when to spawn new TCP connections. Such parameters are roundtrip time, total number of packets sent vs. received, total number of bytes sent vs. received, packets lost during the last time interval, total number of packets lost etc. New channels can be spawn when e.g. the roundtrip time increase and or when number of lost packets increase.
Base it on roundtrip time: When the roundtrip time between the RealTunnel client and server increase, new TCP connections can be spawn. Increased roundtrip time indicates degradation of the network link.
RTCP messages might be a good choice since the RTCP reports are comprehensive and accurate. Cache and drop level is a good alternative. The cache level can then be used for low threshold levels and the drop level for higher threshold levels.
The following protocol is implemented for the purpose of spawning new TCP connections:
The multi protocol between the RealTunnel client and RealTunnel server is defined with the following messages:
A similar protocol exists between the RealTunnel server and the Media Engine.
The RealTunnel server reads a configuration file with the parameters ranging from 1 to 2 in the list above. These parameters will be read by the RealTunnel server at start-up and directly passed on to the RealTunnel client and the ME, used by both the ME and the RealTunnel client. SetMaxNoOfConnections states how many TCP data connections that maximum are allowed to be used. This parameter is also used both in the RealTunnel client and the Media Engine. Epsilon states how sensitive the client shall be for spawning new TCP connections. An overall picture of the transmitting and receiving arrangement for three channels (TCP connections) is Application 1 and Application 2 is a RealTunnel client or a Media Engine. Note that number of channels on the originating (Application 1) is independent of the number on the terminating side (Application 2).
It is also possible to reduce the number of TCP connection if the network condition improves.
Different ways of identifying when to reduce new TCP connections:
Base it on the TCP window size: The TCP window size can be used to decide when to reduce the number of TCP connections. Typically channel(s) can be removed when the TCP window size increase in size since this might indicate a better TCP connection.
Base it on RTCP messages: Channels can be removed when e.g. the roundtrip time decrease and or when number of lost packets decrease.
Base it on roundtrip time: When the roundtrip time between the RealTunnel client and server decrease, TCP connections can be removed. Decreased roundtrip time indicates an improved network link.
RTCP messages might be a good choice since the RTCP reports are comprehensive and accurate. Cache and drop level is a good alternative. The cache level can then be used for low threshold levels and the drop level for higher threshold levels.
An additional ReduceEpsilon message in the the multi protocol between the RealTunnel client and RealTunnel server should be added. This number indicates threshold level for how easily the existing TCP connections should be removed when the network condition improves.
When HTTPS is used instead of HTTP is might be convenient to setup dedicated transmitter and receiver channels.
Cache
It is possible to spawn new TCP connections based on any of the following criteria:
It is possible to use the same scheme for reducing the number of TCP connections if the network condition improves.
Drop
It is possible to spawn new TCP connections based on the following criteria:
It is possible to use the same scheme for reducing the number of TCP connections if the network condition improves.
Measure Bandwidth
It is possible to spawn new TCP connections when the transmitting rate is higher than the receiving rate. This section describes a protocol to use for this purpose.
The multi protocol between the RealTunnel client and RealTunnel server is defined with the following messages:
The multi protocol between the RealTunnel client and the RealTunnel server is defined with the following additional messages:
The RealTunnel server reads a configuration file with parameter 1. This parameter is read by the RealTunnel server at start-up and directly passed on to the RealTunnel client and the ME. Parameter 5 (PassOnBw) is dynamic and passed on each time the ME has calculated received and transmitted bandwidth for a certain period, explained further below. SetPollInterval indicates how often the RealTunnel client and ME shall calculate transmitted bandwidth.
At certain intervals (the poll interval) the sender and receiver calculate both transmitted bandwidth and received bandwidth. At each poll interval the Media Engine sends the calculated received and transmitted bandwidth over to the RealTunnel client. The RealTunnel client accordingly has calculated transmitted and received bandwidth for the same period. The RealTunnel client side calculates the new number of channels based on the following algorithm:
if (totalTransmittingBw/totalReceivingBw>epsilon) spawn one new TCP connection
Where delta e.g. might be 1, 04. This means that the senders transmit approximately 4% more than the receivers get. This multi control protocol is designed stateless in order to save complexity and processing power.
It is possible to use the same scheme for reducing the number of TCP connections if the network condition improves.
Server Initiated Spawning of new TCP Connections
In some cases it might be helpful also to let the server side (ME), initiate new TCP connections. But since TCP connections always are initiated on the client side, this means that the RealTunnel client must get a message from the ME, telling the RealTunnel client to spawn a new TCP connection.
This mechanism is advantageous when the bandwidth from the RealTunnel client to the ME is sufficient, but the bandwidth from the ME to the RealTunnel suffers.
The ME must send a message to the RealTunnel client stating, spawn one or several new TCP connections. The message may alternatively be sent from the ME to the RealTunnel server and then to the RealTunnel client.
Server Initiated Reducing Number of TCP Connections
According to the scheme above, the server may also reduce the number of TCP connections.
Scheme for Maximizing Throughput on Steady State Connections
Assuming no packet loss, the following scheme is optimal for optimizing TCP throughput:
Send subsequent number of RTP packets on the same TCP connection at MAXIMUM according to:
RoundTrip Delay/[Number of TCP connections*ms between each RTP packet]
The sender must at certain intervals; it can be the poll interval previously mentioned, check the roundtrip delay and transmit according to this scheme.
Improving Throughput by Using the Best TCP Connections
When packet loss is detected it is important NOT to use congested TCP connections, typically that is TCP connections that have experienced packet loss. Therefore the sender always should rank the available TCP connections. The rank method can be any of the following:
RTCP messages might be a good choice since the RTCP reports are comprehensive and accurate.
The sender will always go through the available TCP connections in a round robin matter. When the first non-congested connection is found, the sender transmits the desired data on that particular TCP connection.
If only congested TCP connections are found, the least congested TCP connection will be used.
If all the TCP connections are congested according to the criteria chosen, the following RTP packets will be dropped until at least one TCP connection can pass on one whole RTP packet.
Theoretical Background
Suppose the capacity of a single bottleneck between a TCP client and TCP server is C, and the initial one TCP connection gets a throughput x. Then if (n−1) new connections are spawned, the n connections will each receive xC/(nx+C−x).
(Note that if n=1, then of course the answer is x.)
A simple example to illustrate:
Suppose a router comprise only TCP traffic, let's say 100 TCP connections are running through this router. The RealTunnel client has one single TCP connection through this router with a steady state throughput of 8 kbit/s. If the RealTunnel client sets up one additional TCP connection through this router, the new combined throughput for these two connections will be:
2*[8*1000/*(2*8+1000−8)]=15,87 kbit/s.
Other Considerations and Optimizations
When the roundtrip delay increases, and Nagle's algorithm is enabled (it is enabled on almost all TCP stacks by default), larger and larger TCP packets are sent to preserve the network condition. When only using one TCP connection between a RealTunnel client and a Media Engine, how many RTP packets are packed into one TCP packet is superfluous. The reason is that TCP when using Nagle's algorithm doesn't send ANY packet before the previous packet is acknowledged (or a full TCP packet is ready to be sent). In case of a packet loss, this means that there will be a full stop in the communication between the RealTunnel client and the ME until the lost TCP packet (and corresponding RTP packets) is resent and acknowledged.
When using several TCP connections the situation is different. Then one also must keep in mind which capabilities the actual applications like Messenger have for coping with lost RTP packets. When it comes to Messenger it can handle up to 3 consecutive lost RTP packets. This implies that at maximum three RTP packets should be packed into one TCP packet in case one TCP packet is lost. To be sure that this is the case, Nagle's algorithm should be turned off. Nagle's algorithm may be turned off both in the RealTunnel clients and in the ME.
Improving TCP Throughput and Characteristics by Modifying TCP Stack
Server Side TCP ACK Improvement
Since the server's side is controlled, i.e. the Media Engine, there is a possibility to improve the ME TCP stack.
When TCP packets are lost, the TCP sender will retransmit the lost packet(s) and won't send new packets before the lost packet(s) are acknowledged from the TCP server side. This is no good behavior for real-time sensitive traffic.
On the server side, i.e. the ME, an acknowledge will ALWAYS be given as though all packets are received. The TCP 32-bit acknowledge number of the TCP packet to be equal to the TCP bit sequence number of the last received TCP packet is modified when necessary.
There is no guarantee that a lost TCP segment will contain only whole RTP packets. There is a risk that a segment may contain a fraction of an RTP packet. In case such a segment is lost the problem of getting back into sync with the RTP packets is faced. This is solved by adding a fixed bit pattern (preamble) to every RTP packet. When a TCP segment with a fractional RTP packet is lost, the receiver (ME) will not find the preamble as expected. RealTunnel now enters hunt-mode. In hunt-mode a search in the byte stream for the first occurrence of the preamble will be performed. When it is found, RealTunnel is back in sync with the RTP packets. There is a risk that the preamble pattern occurs in the RTP data. If this is the case RealTunnel could mistakenly use wrong data as an RTP packet. In this case, the next RTP packet will most likely lack the preamble, and RealTunnel enters hunt-mode again.
This improvement is for traffic sent from the RT client towards the ME.
Server side RTP TCP Retransmission Improvement
When on the server side (ME) it is detected that a TCP packet (segment) is lost, the same segment is not retransmitted instead, and a new RTP packet is inserted into that segment before it is retransmitted. This means that one can drop packets that are lost while keeping the receiving TCP stack happy.
A packet loss is caused by congestion (CPU or bandwidth) somewhere along the path from the server to the client. A back off strategy involves dropping random RTP packets after such a packet loss to lower the probability of another packet loss occurring.
This improvement is for traffic sent from the ME towards the RT client.
Client Side Improvement
Potentially exactly the same improvements as described in the section Server side TCP ACK improvement and the section Server side RTP TCP retransmission improvement can be applied on the client side.
SSL
SSL/TLS is designed to operate on a reliable connection oriented transport-layer (TCP). SSL/TLS will fail when used on top of RealTunnel's enhanced TCP stack, see section Server side TCP ACK improvement. This is handled in one of two different ways:
All the use cases in this section are abstract use cases, i.e. the real signaling flows are somehow more complicated.
Registration
This use case shows the signaling at registration time, when a Messenger client registers to the system. This will lead to a local registration in the present database according to the present invention as well as registrations towards .net. and .net's database.
To be able to support third party SIP servers, it is important that the RealTunnel client adds its own address to the Via and Record-Route header fields. This way, calls to the user will be routed through the RealTunnel server.
Call Setup
The two users may be registered on different RealTunnel servers, but in order to conserve resources (RealTunnel server connections); the call should not be routed through more than one RealTunnel server. This is solved by letting the system inform the calling and called RealTunnel client about which RTP-proxy to use.
The session starts as the user presses “call” or similar in Messenger, which triggers an INVITE sent to the local RealTunnel client, which starts a local RTP proxy session. The listening local RTP/UDP port is reported back to the client in the forthcoming 200 OK.
The RealTunnel client asks to be connected to the called user, so that a virtual channel is opened to this one. The RealTunnel server locates the user. As the user is logged on the network, the INVITE is sent to the RealTunnel client of the called party in the HTTP session. This connects again to the calling user, opening another channel the opposite way. The calling party's RealTunnel client inserts the address of its local RTP proxy in the SDP before forwarding the INVITE to Messenger.
If the call is accepted, Messenger replies with a 200 OK (or any other response with SDP, which is notified to the RTP-proxy), which is sent back to the RealTunnel server, and passed on to the calling RealTunnel client. This now replaces the given media addresses (SDP) with those of its listening RTP proxy, and sends the modified 200 OK upstream.
Any further SIP message follows the same path.
Simple Voice and Video Conference
An enhancement of the service offering of RealTunnel is simple voice and video conference. The concept of simple voice and video conference is the same as other types of video conferencing service. Such conferences consist of a set of clients and one or more central mixing units. The task for the central mixing units is to receive media (voice and video) from all the participating clients and mix this together to a new voice and video stream that is sent back to the clients (see
The problem by adding conferencing capabilities is that video mixing require a lot of resource, and therefore becomes quite expensive. Because of the RealTunnel architecture, a simple conferencing service can be supported instead of the normal conferencing.
The only difference between a normal video conference and the simple voice video conference is that in the simple conferencing the central unit does not have mixing capabilities.
In the simple voice video conferencing the received video from the mixing unit is actually the same as the one sent from one participating clients (see
The advantage of the simple voice and video conferencing service is that it is cheep because no expensive video mixing hardware is in use.
The disadvantage is that it is not possible to see the picture of more that one of the participants at the time1.
1Because of the natural fast change of individuals speaking in a voice conference, a voice mixing unit has to be added to the service so that fast changes does not become to annoying for the participants.
For the central unit to choose the originator of the video picture sent to all the other participants, one of the following algorithms can be used.
Number | Date | Country | Kind |
---|---|---|---|
NO 20033938 | Sep 2003 | NO | national |