Hi there 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? Many thanks Steven -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20051012/608315f3/attachment.htm
In article <E1EPcnp-0002ek-IH@piglet.barn.za.net>, Steven Langley <steven@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@softins.co.uk - http://www.softins.co.uk Play: tony@mountifield.org - http://tony.mountifield.org
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@softins.clara.co.uk (Tony Mountifield)> Subject: [Asterisk-Users] Re: delays with IAX2 and Meetme> To: asterisk-users@lists.digium.com> Message-ID: <diip8t$dq8$1@softins.clara.co.uk>>> In article <E1EPcnp-0002ek-IH@piglet.barn.za.net>,> Steven Langley <steven@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@softins.co.uk - http://www.softins.co.uk<http://www.softins.co.uk/>> Play: tony@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
Hi Thanks for the reply I do actually use the |q option to disable the enter/exit sounds. Steven> Message: 15> Date: Thu, 27 Oct 2005 10:25:32 -0500> From: "Eric \"ManxPower\" Wieling" <eric@fnords.org>> Subject: Re: [Asterisk-Users] Re: delays with IAX2 and Meetme> To: Asterisk Users Mailing List - Non-Commercial Discussion> <asterisk-users@lists.digium.com>> Message-ID: <4360F16C.4040800@fnords.org>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed> Steven Langley wrote:>> 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 notusing>> 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 clientsto>> narrow down the source of the delay?>>>I'm pretty sure this is a known issue with enabling meetme enter/exit>sounds. Turn them off (q option to MeetMe, I think)-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20051027/b1aff6d2/attachment.htm
Ryan
2005-Oct-28 22:20 UTC
[Asterisk-Users] DTMF recognition unreliable or absent, ringing lost on 2nd half of "3-way" call.
On Thu, Oct 27, 2005 at 02:10:51PM -0400, Dave Grey exclaimed:> >These appear to be a common problems, but after spending half a day >reading the wiki and list archives I have not gained much useful >knowledge beyond the fact that these are a common problems. I am >hoping for some suggestions or pointers to further info. > >I have an ivr in my incoming context that does a background() and... >well, it is an ivr, no need to explain that, I guess. > >So, testing locally, it works wonderfully. Testing through my DID, >provided by IPKall, it is decidedly hit-or-miss. The digits seem to >be either not recognized at all or recognized incorrectly better than >half the time. Most often, I get the "invalid extension" playback >that I have assigned to the i,1 exten. For a while, I had two test >extensions, one 2000 and one 2001. Dialing 2001 usually sent me to >2000 instead. What is making it hard for me to debug is that it >*sometimes* works, recognizing the extension I dialed correctly. > >My peer entry in sip.conf for IPKall contains dtmfmode=rfc2833 as per >their recommendation. I have tried setting relaxedtmf=yes in the >general section, with no noticeable change. I turned it off again, >since the problem seems to be too much relaxation in any case. >Looking at the console, I dial 7056 and it sees 7055, I dial 7056 >again and it sees 75, I dial 7056 a third time and it sees 7055556, >etc. Seems random and all over the place. Packet loss and/or >ordering? Aside from the dtmf issue, incoming calls on the DID work >fine and sound excellent. >This is a known issue that is fixed in CVS HEAD. Search for my prior emails to track down the bug numbers. Unfortunately this is going to require the upstream providers to upgrade to truly fix the issue. Basically the RTP packets are coming out of order and have the wrong sequence numbers. I started on a band-aid solution using ip_queue, but I have not had time to finish it up. I will post here if it ever materializes. -Ryan
trixter aka Bret McDanel
2005-Oct-30 21:57 UTC
[Asterisk-Users] DTMF recognition unreliable or absent, ringing lost on 2nd half of "3-way" call.
On Sun, 2005-10-30 at 23:42 -0500, Dave Grey wrote:> On Oct 30, 2005, at 11:21 PM, trixter aka Bret McDanel wrote: > > I am starting a provider that gives free service > > Nice! You went from listing free providers to becoming one. ;-) >I had been planning on offering free service for a while, started to get a little bit of time available and was able to put together what I had already :)> I would love an invite if you could use another tester. > > Either way, good luck with this and thanks for providing another free > option.It should be open to everyone soon. Right now the Sacramento Asterisk Users Group is the test ground, and I gotta move everything before I open it up anyway, I dont have the bandwidth on the sip/iax2 server right now to support hundreds of people. I also plan on adding more servers, right now I have one, a friend is donating some bandwidth and a server for a second, and I am in talks with a few people in different countries to donate some space for additional. -- Trixter http://www.0xdecafbad.com Bret McDanel UK +44 870 340 4605 Germany +49 801 777 555 3402 US +1 360 207 0479 or +1 516 687 5200 FreeWorldDialup: 635378 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20051030/c9e80147/attachment.pgp