[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 17:06:34 +0200

Hi Mitch,

you are right in theory.

But practically UDP and TCP was designed in 1960. Where people had big
problems because of their bad connection. They never thought about
viber-glass and sending GBytes around.

Today the situation is very different. Loss of packets is a problem
99% of people will never face (except they make the frame_size bigger
then the max_frame size of their network).

so ... yes every teacher in the university will tell you the story
just like you told it but practically the TCP VS UDP story is not
really a interesting thing from a today's point of view.
There are also quite a lot of Media-Stream protocols implemented in
TCP today. For example all Flash Video Streaming is over TCP.

And of course TCP has a lot of advantages from a programmer point of
view ... every package is in order and you do not have to deal with a
lot of problems compared with a lossy-orientated protocol.


2010/6/16 Mitch Davis <address@hidden>:
> 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.
> (Disclaimer: I know little in this area, this is just what I've read)
> Mitch.

Sebastian Wagner

reply via email to

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