[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: Sebastian Wagner
Subject: Re: [Linphone-users] HT-Proxy and Linphone (HTTP-Tunneling)
Date: Wed, 16 Jun 2010 19:22:54 +0200

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,
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>
>>  wrote:
>>> 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
>> packets.
>> 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.
> regards
> Klaus

Sebastian Wagner

reply via email to

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