[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Linphone-users] HT-Proxy and Linphone (HTTP-Tunneling)

From: Klaus Darilion
Subject: Re: [Linphone-users] HT-Proxy and Linphone (HTTP-Tunneling)
Date: Wed, 16 Jun 2010 20:21:37 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv: Gecko/20100317 Thunderbird/3.0.4

Am 16.06.2010 19:22, schrieb Sebastian Wagner:
Yes and as it seems to be the easiest way to bypass firewall Issues
from a Client point of view I ask myself why hardly any Softphone
implements it :-/

As STUN seems to be only working with a single client behind a NAT,

Only with broken NAT implementations. A well implemented NAT will use a different public port if the port is already in use to the same destination.

I know there are some broken NATs, but I haven't meet one yet.


otherwise you will again have a Port Issue.... and also Firewalls
often block content in general except:
Port 80 (but they can filter on Packets that port)
and Port 443 (https) =>  and they _cannot_ filter the Packets as they
expect https packets .. which are encrypted, so they can just allow

So with HTTP-Tunneling on port 443 you can bypass almost any Firewall.


2010/6/16 Klaus Darilion<address@hidden>:

Am 16.06.2010 15:51, schrieb Mitch Davis:

On Wed, Jun 16, 2010 at 5:41 PM, Sebastian Wagner<address@hidden>

I would like to know if there are plans or started implementation for
HTTP-Tunneling in Linphone.

Anyway: HTTP-Tunneling is a quite common (and comfortable) way of
bypassing the firewall

One problem with doing this is that HTTP uses TCP, which is a
"reliable" protocol.  That is, the protocol doesn't pay special
attention to getting packets delivered on time, rather, it focuses on
getting *all* packets delivered, in order.  This isn't a great idea
when one is carrying live voice, because for time-critical
applications like voice, it's better to drop a few packets than to
hold everything up and be 100% reliable.  Most voice and video codecs
are designed with this in mind, and can somewhat conceal some missed

It may be easy to tunnel HTTP, and it may be possible to do live voice
over HTTP, but in general, HTTP is the wrong tool for the job.

In theory you are correct. But enough bandwidth and some application logic
can solve the problem - see Skype which can tunnel everything over HTTP(S).

SIP over HTTP tunnel should be rather easy to implement. the client only has
to use SIP over TCP/TLS and connect to the http proxy instead of the real
target, and then send a CONNECT request before starting with the SIP
signaling. Of course there might be issues with SRV/NATPR lookups as those
are of course not implemented by normal HTTP proxies.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]