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

[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,
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
>



-- 
Sebastian Wagner
http://www.webbase-design.de
http://openmeetings.googlecode.com
http://www.laszlo-forum.de
address@hidden