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

[Klaus Darilion]

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.

regards
klaus

> 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
> it....
>
> So with HTTP-Tunneling on port 443 you can bypass almost any Firewall.
>
>
> Sebastian
>
>
>
> 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