On Sun, 29 Aug 2004, Kris Boutilier wrote:
Is timestamp information calculated purely from the relative timestamps of
each frame of the current incoming stream or is there some degree of RTC
synchronization expected between the two endpoints?
No sync is needed; its all relative.
On Sat, 28 Aug 2004, Michael George wrote:
So even with X11 eliminated the sound is still bad to Digium. I tried
another's 1700 number, and it sounded the same, so it's not something unique
to digium and me.
Would IAX/GSM be so sensitive to half-duplex that I cannot expect it to work
On Sat, 28 Aug 2004, Andrew Kohlsmith wrote:
Please note that it seems impossible to disable jitter buffer between 20040806
CVS HEAD endpoints. The jitterbuffer numbers in iax2 show channels look
live. The numbers look right (jitbuf 0ms) between 20040806 and RC1
(Nufone). I haven't
On Sunday 29 August 2004 02:06, [EMAIL PROTECTED] wrote:
On Sat, 28 Aug 2004, Andrew Kohlsmith wrote:
Please note that it seems impossible to disable jitter buffer between
20040806 CVS HEAD endpoints. The jitterbuffer numbers in iax2 show
channels look live. The numbers look right (jitbuf
On Sunday 29 August 2004 01:59, [EMAIL PROTECTED] wrote:
If you think that the jitter buffer isn't working right and should fix
this, then please capture debug from the buffer and send over to me.
To do that, in /etc/asterisk/logger.conf edit the debug line to be:
debug =
On Sunday 29 August 2004 01:59, [EMAIL PROTECTED] wrote:
If you think that the jitter buffer isn't working right and should fix
this, then please capture debug from the buffer and send over to me.
I notice that the timing measurements are still showing wild values at
times - here is a
Those wild times especially occur before any audio is sent. (e.g. while
ringing or pre ringing).
At 17:10 29/08/2004, you wrote:
On Sunday 29 August 2004 01:59, [EMAIL PROTECTED] wrote:
If you think that the jitter buffer isn't working right and should fix
this, then please capture debug
On Sat, Aug 28, 2004 at 11:31:48PM -0400, Andrew Kohlsmith wrote:
On Saturday 28 August 2004 23:01, Michael George wrote:
It's a PII 266 (okay, not the fatest system) with 192MB RAM. X is not
running and the Framebuffer has been turned off in /boot/grum/menu.lst. I
have disabled all the
At 17:10 29/08/2004, you wrote:
I notice that the timing measurements are still showing wild values at
times - here is a partial grab of an iax2 show channels:
Lag Jitter JitBuf Format
00020ms 6291456ms ms ALAW
00012ms 6291440ms ms ALAW
00017ms 0004ms ms ALAW
On Sun, Aug 29, 2004 at 07:59:20AM +0200, [EMAIL PROTECTED] wrote:
On Sat, 28 Aug 2004, Michael George wrote:
So even with X11 eliminated the sound is still bad to Digium. I tried
another's 1700 number, and it sounded the same, so it's not something unique
to digium and me.
Would
On Sun, 29 Aug 2004, Andrew Kohlsmith wrote:
Also, is are logs of problem conversations already in progress any use to you?
You nailed down the dead audio after 65535ms problem but every now and
again (very very rare) we will have a conversation where the incoming audio
goes totally
On Sun, 29 Aug 2004, joachim wrote:
Those wild times especially occur before any audio is sent. (e.g. while
ringing or pre ringing).
Yeah - because the sender does weird things to the timestamps it
generates. This is the problem that needs to be resolved; the jitter
buffer just shows
On Sunday 29 August 2004 15:52, [EMAIL PROTECTED] wrote:
The jitter buffer makes all its decisions about dejittering based on the
timestamps of incoming frames. There a fundamental expectation that the
sending side is correctly stamping each frame - 20msec, 40msec etc etc.
Right, this makes
On Sun, 29 Aug 2004, Andrew Kohlsmith wrote:
Hmm... I think next CVS update I'm gonna add a bit of code in chan_iax2 that
tries to verify that timestamps aren't getting sent incorrectly. Fun fun
fun. :-)
Its not that the generation is broken. Its that various optimisations and
things
On Sat, Aug 28, 2004 at 11:31:48PM -0400, Andrew Kohlsmith wrote:
On Saturday 28 August 2004 23:01, Michael George wrote:
It has nothing to do with IAX or GSM. Stop blaming them. My upstream is half
duplex as well (pretty much anyone on DSL or cable is on a half duplex
connection whether
: [Asterisk-Users] iaxtel and jitterbuffer
{clip}
The jitter buffer makes all its decisions about dejittering based on the
timestamps of incoming frames. There a fundamental expectation that the
sending side is correctly stamping each frame - 20msec, 40msec etc etc.
The problem is that the sending
Does this also effect 1.0-RC2? I am having a similar issue at a
customer site over a frame relay network that is having occasional
choppy sound over a fairly open line, with the jitter buffer enabled,
as well as trunk=yes enabled.
Thanks!
Brian
On Fri, 27 Aug 2004 12:47:05 -0700, Kris Boutilier
Had this problem earlier this week - ensure 'trunk=no' in iax.conf if you're
using fairly current CVS code. There is something not right w/the trunking
that causes choppy sound. See the wiki for more info.
I am using current CVS code and I have trunk=no. Still sounds crappy. I need
to
On Aug 28, 2004, at 7:39 AM, Rich Adamson wrote:
I do a lot of work with companies throughout the US on network
performance
and we _frequently_ run into routers, switches, servers, etc, that are
allowed to auto-negotiate their half vs full duplex nic interfaces.
About
50% of the time, systems
On Sat, Aug 28, 2004 at 08:39:50AM -0600, Rich Adamson wrote:
I do a lot of work with companies throughout the US on network performance
and we _frequently_ run into routers, switches, servers, etc, that are
allowed to auto-negotiate their half vs full duplex nic interfaces. About
50% of
On Sat, Aug 28, 2004 at 03:00:26PM -0400, Michael George wrote:
On Sat, Aug 28, 2004 at 08:39:50AM -0600, Rich Adamson wrote:
I do a lot of work with companies throughout the US on network performance
and we _frequently_ run into routers, switches, servers, etc, that are
allowed to
On Sat, 28 Aug 2004 15:24:01 -0400, Michael George wrote:
On Sat, Aug 28, 2004 at 03:00:26PM -0400, Michael George wrote:
On Sat, Aug 28, 2004 at 08:39:50AM -0600, Rich Adamson wrote:
I do a lot of work with companies throughout the US on network performance
and we _frequently_ run into
On Saturday 28 August 2004 15:00, Michael George wrote:
The difference between that and what I'm getting from IAX/GSM is profound,
with GSM being intolerably poor quality.
That's odd; every single voice call coming in and out of the company I work
for is using the GSM codec with asterisk and
On Saturday 28 August 2004 15:24, Michael George wrote:
I just saw a page on the wiki that mentions that running X11 or a VESA
frame buffer can cause jittery sound. I only have this problem with IAX2,
but that might be cause when I use Zap -- Zap or Zap -- SIP there is no
en/decoding
On Sat, Aug 28, 2004 at 05:08:30PM -0400, Andrew Kohlsmith wrote:
On Saturday 28 August 2004 15:24, Michael George wrote:
I just saw a page on the wiki that mentions that running X11 or a VESA
frame buffer can cause jittery sound. I only have this problem with IAX2,
but that might be cause
On Saturday 28 August 2004 23:01, Michael George wrote:
It's a PII 266 (okay, not the fatest system) with 192MB RAM. X is not
running and the Framebuffer has been turned off in /boot/grum/menu.lst. I
have disabled all the servers except for sshd. I have the latest source
from CVS HEAD as of
Had this problem earlier this week - ensure 'trunk=no' in iax.conf if you're
using fairly current CVS code. There is something not right w/the trunking
that causes choppy sound. See the wiki for more info.
Kris Boutilier
Information Systems Coordinator
Sunshine Coast Regional District
On Fri, Aug 27, 2004 at 12:47:05PM -0700, Kris Boutilier wrote:
Had this problem earlier this week - ensure 'trunk=no' in iax.conf if you're
using fairly current CVS code. There is something not right w/the trunking
that causes choppy sound. See the wiki for more info.
I am using current CVS
28 matches
Mail list logo
