[Asterisk-Users] Re: delays with IAX2 and Meetme

[Steven Langley]

Hi Tony

 

Thanks for the reply and for posting the code. I added the code and
recompiled Asterisk, but unfortunately it did not resolve the issue. It
basically trapped all of the incoming audio and wrote to the error log
instead of outputting it. So basically it never seemed to go to the
careful_write statement.

 

To answer your questions: Firstly, I am using kernel 2.6, but am not using
Ztdummy. I am using a digium card for timing. I have run a test on it, and
it seems to be working properly.

 

I am using a client built using IaxClient, and am now looking at the
possibility that the delay might be a client issue instead of a server
issue. What is the best tool to use to run tests on my server and clients to
narrow down the source of the delay?

 

Many thanks

 

Steven

 

> Date: Wed, 12 Oct 2005 10:41:33 +0000 (UTC)

> From: tony at softins.clara.co.uk (Tony Mountifield)

> Subject: [Asterisk-Users] Re: delays with IAX2 and Meetme

> To: asterisk-users at lists.digium.com

> Message-ID: <diip8t$dq8$1 at softins.clara.co.uk>

> 

> In article <E1EPcnp-0002ek-IH at piglet.barn.za.net>,

> Steven Langley <steven at intellinc.co.za> wrote:

>> 

>> I am using IAX2 softphones dialing into meetme conferences. I also have

>> jitterbuffer=yes, with typical jitterbuffer settings. The problem I am

>> having is that as soon as there is a delay from a participant, then the

>> delay continues until the participant hangs up and dials in again. When

>> dialing in again the delay seems to go.

>> 

>> It seems to me as though as soon as the server registers a delay from a

>> participant, then it causes delay on all further packets from that

>> participant.

>> 

>> Does anyone have any ideas what the problem could be?

> 

> Yes, there are a few possibilities. Firstly, are you using ztdummy for

> timing? Which kernel version? If 2.6, have you ensured that USE_RTC is

> correctly defined in ztdummy.c?

> 

> Look in bugs.digium.com at bug IDs 3599 and 4252 - they might be relevant.

> 

> Yesterday I found another mechanism which could give rise to both a delay

> and broken audio - I found it with OH323 channels, but it might possibly

> arise on other channel types too. It concerns a backlog building up in

> the channel driver and never being drained by meetme because of blocking

> in the pseudo-device when trying to write the contents of a large frame.

> 

> In app_meetme.c, try replacing this:

> 

> careful_write(fd, f->data, f->datalen);

> 

> with this:

> 

> if (f->datalen <= CONF_SIZE) {

>   careful_write(fd, f->data, f->datalen);

> } else {

>   ast_log(LOG_WARNING, "Discarding large frame (%d bytes) from channel
%s\n", f->datalen, chan->name);

> }

> 

> and see if it helps.

> 

> I haven't yet submitted the above change to mantis.

> 

> Cheers

> Tony

> -- 

> Tony Mountifield

> Work: tony at softins.co.uk - http://www.softins.co.uk
<http://www.softins.co.uk/> 

> Play: tony at mountifield.org - http://tony.mountifield.org
<http://tony.mountifield.org/> 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20051027/d7789546/attachment.htm