>
> Thx for the response.  I've considered that but ruled it out.  Doing a
> packet capture on the HT end, I am sending about 30-36 pkts per second,
> totaling about 4500 bytes on the wire per second.  So I am only transmitting
> about 5 Kbs.  Even a low upload speed could handle that.
>

Maybe it's caused by something else. However, I believe that 5Kbs could
cause speed adjustment in TCP over some ADSL connection. It's enough to have
a very little more delay between 2 RTP packet in order to create an
increasing latency over the time.

>  This is more than an 'inconvenience' for using TCP for voice traffic.  It
> would make TCP unusable for voice traffic.  I have worked with other
> products that did SIP/RTP using TCP and we did not have this delay problem.
>
I myself had this problem from times to times but generally my communication
with http tunnel worked well.


>
>
> Jeff
>
> ----- Original Message -----
> From: "Minh Phan" <[email protected]>
> To: "Jeff Theinert" <[email protected]>
> Cc: [email protected]
> Sent: Tuesday, July 7, 2009 1:02:49 AM GMT -08:00 US/Canada Pacific
> Subject: Re: Http Tunnelling
>
> Hi Jeff,
>
> Is your local end using an ADSL connection? If it is the case, the
> increasing latency might be caused by the limited upload speed.
> If the connection speed from your phone to the HTTP server is low, the TCP
> protocol would naturally increase the delay between packets in order to
> avoid packet loss. Hence, increase the latency. This is the inconvenience of
> using TCP for voice traffic.
>
> Best regards,
>
> Minh
>
>
>
> 2009/7/7 Jeff Theinert <[email protected]>
>
>>  Hi,
>>
>>
>>
>> I have HTTP tunnelling working under Windows, but there is a problem I
>> cannot resolve.  During a call where the local end is using HTTP
>> tunnelling, the audio latency to the remote end degrades by about 1.6
>> seconds per minute the call lasts.  The audio latency from remote end to
>> local end is consistent.  I checked the server code and found that it was
>> compiled with debug messages, but even recompiling to eliminate the debug
>> messages did not change the degrading latency.
>>
>>
>>
>> I cannot find anything specifically causing a delay in the client.  If I
>> set a breakpoint in Visual Studio and let the program sit for 20-30 seconds,
>> when I resume, the latency is back to normal, but then begins to degrade
>> again.  Since all threads in VS are frozen at that point, that makes me
>> believe this is a server issue.  But since the server code has not changed
>> in 3 years, I would expect that some one would have reported this as a
>> problem.
>>
>>
>>
>> Any ideas to resolve this are greatly appreciated.
>>
>>
>>
>> Jeff Theinert
>>
>> _______________________________________________
>> QuteCom-dev mailing list
>> [email protected]
>> http://lists.qutecom.org/mailman/listinfo/qutecom-dev
>>
>>
>
_______________________________________________
QuteCom-dev mailing list
[email protected]
http://lists.qutecom.org/mailman/listinfo/qutecom-dev

Reply via email to