| 00:10.02 | *** join/#asterisk-dev wdoekes2 (~walter@wjd.osso.nl) |
| 00:19.13 | *** join/#asterisk-dev wdoekes2 (~walter@wjd.osso.nl) |
| 04:46.44 | *** join/#asterisk-dev irroot (~gregory@41.51.230.133) |
| 04:47.16 | *** part/#asterisk-dev irroot (~gregory@41.51.230.133) |
| 04:58.17 | *** join/#asterisk-dev luckman212 (~do-not-re@pool-108-41-8-176.nycmny.fios.verizon.net) |
| 05:23.52 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-155-146.cablep.bezeqint.net) |
| 05:23.52 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 05:35.28 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.75.202) |
| 05:35.28 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 06:19.30 | *** join/#asterisk-dev Corydon76-home (gold@c-69-137-80-31.hsd1.tn.comcast.net) |
| 06:19.30 | *** mode/#asterisk-dev [+o Corydon76-home] by ChanServ |
| 06:30.31 | *** join/#asterisk-dev irroot (~gregory@197.105.111.71) |
| 06:31.10 | *** part/#asterisk-dev irroot (~gregory@197.105.111.71) |
| 06:49.52 | *** join/#asterisk-dev Corydon76-home (gold@c-69-137-80-31.hsd1.tn.comcast.net) |
| 06:49.52 | *** join/#asterisk-dev zh-home|away (~zerohalo@74.61.196.236) |
| 06:49.52 | *** mode/#asterisk-dev [+o Corydon76-home] by zelazny.freenode.net |
| 06:55.00 | *** join/#asterisk-dev irroot (~gregory@197.170.80.100) |
| 06:55.34 | *** part/#asterisk-dev irroot (~gregory@197.170.80.100) |
| 07:09.18 | *** join/#asterisk-dev irroot (~gregory@197.108.62.133) |
| 07:09.54 | *** part/#asterisk-dev irroot (~gregory@197.108.62.133) |
| 07:43.10 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 07:43.45 | schmidts | good morning |
| 07:46.13 | *** join/#asterisk-dev oej (~olle@2001:16d8:cc57:1000:c47:5108:d906:f43d) |
| 07:46.13 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:47.06 | oej | Good morning folks |
| 07:48.28 | schmidts | good morning oej |
| 08:02.35 | *** join/#asterisk-dev lftsy (~lftsy@194.38.160.113) |
| 08:08.12 | *** join/#asterisk-dev sgimeno (~sgimeno@163.117.206.10) |
| 08:10.20 | schmidts | wdoekes2 are you here allready? |
| 08:11.52 | *** join/#asterisk-dev oej (~olle@87.96.134.129) |
| 08:11.52 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:34.29 | *** join/#asterisk-dev oej (~olle@2001:16d8:cc57:1000:8583:75a:9a25:c44e) |
| 08:34.29 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:38.49 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 08:38.49 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:59.55 | wdoekes2 | morning schmidts, yes I am |
| 09:00.16 | wdoekes2 | back from warm Sweden |
| 09:00.21 | schmidts | good morning wdoekes2 ;) |
| 09:00.49 | schmidts | do you remember the problem i had with one of my machine and the seqfault in ast_rtp_write, you have taken a look at the gdb on this machine? |
| 09:01.10 | wdoekes2 | I remember |
| 09:03.15 | schmidts | it happend again just two hours ago, with exactly the same problem, gdb output looks quite the same |
| 09:03.36 | schmidts | uptime was 43 days this time, if i remeber correctly it was around 45 days the last time |
| 09:05.32 | wdoekes2 | you probably didn't add the debug code I suggested? |
| 09:06.07 | wdoekes2 | (which was something like: if (ptr == NULL) { ast_log(WTF); return; } ) |
| 09:08.06 | schmidts | let me check, i am not sure |
| 09:09.59 | wdoekes2 | could it be (unchecked) memory allocation failure? (I don't remember) do you have memory usage logs? |
| 09:10.03 | schmidts | damn no :( |
| 09:10.37 | schmidts | wdoekes2 no |
| 09:11.08 | schmidts | possibly it could be something like this but as we have checked the last time, it should never come to this point if the alloc failed |
| 09:11.21 | schmidts | something changes the pointer in between |
| 09:12.54 | wdoekes2 | if possible, add system logging (collectd?), it may aid in finding a problem (high cpu usage? many threads? mem usage?), especially if you suspect that it will happen again first after 40+ days |
| 09:14.01 | schmidts | i will check my nagios |
| 09:17.59 | schmidts | wdoekes2 everything looks normal for the given time, load was around 0.8, memory usage around 730 mb, threads very stabel arond 330, no major page faults, no peak in allocation, no udp or tcp peak |
| 09:19.12 | schmidts | what i dont understand about gdb is pending to this two rows: |
| 09:19.17 | schmidts | <PROTECTED> |
| 09:19.17 | schmidts | <PROTECTED> |
| 09:19.43 | schmidts | i can print out the value of rtpheader which is out of bounds and also the value of frame->data.ptr which looks like a very common pointer |
| 09:19.52 | schmidts | but i cant print out the value of hdrlen? |
| 09:20.13 | schmidts | ok forget it, i remeber its optimized out |
| 09:50.03 | *** join/#asterisk-dev merbanan (~benjamin@2a00:801:f5:10:221:70ff:fecb:d6f9) |
| 09:57.44 | *** join/#asterisk-dev irroot (~gregory@197.106.28.224) |
| 09:58.10 | *** part/#asterisk-dev irroot (~gregory@197.106.28.224) |
| 10:08.04 | *** join/#asterisk-dev oej (~olle@87.96.134.129) |
| 10:08.04 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 10:33.02 | *** join/#asterisk-dev irroot (~gregory@197.110.148.65) |
| 10:33.28 | *** part/#asterisk-dev irroot (~gregory@197.110.148.65) |
| 10:47.41 | *** join/#asterisk-dev tamiel (~tamiel@85-171-170-252.rev.numericable.fr) |
| 11:32.39 | *** join/#asterisk-dev luckman212 (~do-not-re@pool-108-41-8-176.nycmny.fios.verizon.net) |
| 11:42.21 | *** join/#asterisk-dev irroot (~gregory@197.175.72.96) |
| 11:42.58 | *** part/#asterisk-dev irroot (~gregory@197.175.72.96) |
| 11:46.14 | *** join/#asterisk-dev vpopov (~happylife@dyn-58-35.fttbee.kis.ru) |
| 11:46.51 | *** join/#asterisk-dev asterisk-Tester (~RAMYT@193.227.170.247) |
| 12:30.01 | WIMPy | I'm trying to debug missing dialling digits when using WaitExten. I notice that pbx_builtin_waitexten returns after the first digit is entered. In which place are additional digits collected? |
| 12:31.43 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:31.43 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 12:36.48 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:36.48 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:48.41 | *** join/#asterisk-dev ccesario (~ccesario@189.29.54.144) |
| 12:56.30 | tzafrir_laptop | WIMPy, collected? |
| 12:56.39 | tzafrir_laptop | Why would they be collected? |
| 12:56.59 | WIMPy | While I'm typing them on the phone. |
| 12:57.08 | WIMPy | But we are already a step further. |
| 12:57.18 | WIMPy | The issue seems to be due to dundi. |
| 12:57.49 | WIMPy | It only happens if I dial too fast. And disabling dundi cures it. |
| 12:58.11 | WIMPy | schmidts suggested a locking issue. |
| 12:58.32 | WIMPy | But I have nfi where to start searching. |
| 12:59.23 | schmidts | WIMPy its just a thought that i have ;) |
| 12:59.54 | WIMPy | You know a lot more about the internals than I do. |
| 13:10.15 | *** join/#asterisk-dev irroot (~gregory@41.52.229.163) |
| 13:10.49 | *** part/#asterisk-dev irroot (~gregory@41.52.229.163) |
| 13:16.06 | *** join/#asterisk-dev fobus912 (~fobus912@41.143.31.230) |
| 13:19.11 | WIMPy | Can you just send DTMF (start+end) with ast_queue_frame and assume this works or do you have to do any sort of (locking?) check before or after to make sure the frame will be/has been processed |
| 13:19.15 | WIMPy | correctly? |
| 13:21.19 | schmidts | WIMPy imho checking if the frame will be processed would break the queueing concept |
| 13:22.59 | WIMPy | Yes, the "queue" part may suggest that you don't have to care about anything. Just want to make sure. |
| 13:24.25 | *** join/#asterisk-dev luckman212 (~do-not-re@pool-108-41-8-176.nycmny.fios.verizon.net) |
| 13:29.08 | kpfleming | if you queue a frame, you no longer hold any reference to it.. you have passed ownership of it to the channel you queued it onto |
| 13:29.39 | WIMPy | Ok, so are no checks that you have to make? |
| 13:31.47 | WIMPy | I have just checked by creating another extension that does an Answer() and WaitExten(). Same problem. |
| 13:32.03 | WIMPy | So it does not seem to be realted to the channel. |
| 13:32.46 | WIMPy | related |
| 13:33.34 | WIMPy | Something on pbx core seems to discard digits while a dundi request is still active. |
| 13:35.02 | *** join/#asterisk-dev hrolf (~hrolf@unaffiliated/hrolf) |
| 13:38.22 | kpfleming | what does your dialplan on the incoming channel look like? |
| 13:39.06 | WIMPy | http://wimpy.yeti.dk/pastebin |
| 13:39.32 | WIMPy | There are some direct extensions following, but the switches should be the interesting part. |
| 13:39.40 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-fmnthxovnjtbvgkn) |
| 13:39.40 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:40.06 | WIMPy | I think the problem has existed for longer, I just blamed the keypad of one of my phones so far. |
| 13:40.37 | WIMPy | But after adding another dundi peer it has become apparent that it was not the keypads fault. |
| 13:41.57 | kpfleming | so i suspect that what is happening is that *all* inbound media while a 'switch' is being executed is being absorbed/dropped |
| 13:42.54 | WIMPy | In the normal situation the channel wouldn't have been answered. Just in the test case. |
| 13:44.18 | kpfleming | right |
| 13:45.49 | schmidts | i might have found something pending to DUNDI. pbx_extension_helper is called after a digit is read in waitexten and in this function it might do a dundi lookup (dont know anything about dundi at all). the text says it should store all frames which are received meanwhile but maybe thats the problem |
| 13:46.44 | *** join/#asterisk-dev irroot (~gregory@41.49.135.193) |
| 13:47.32 | *** part/#asterisk-dev irroot (~gregory@41.49.135.193) |
| 13:47.34 | WIMPy | A queue that doesn't queue? |
| 13:49.59 | schmidts | as its said there the auto-service code should queue it but maybe auto service doesnt run on this channel |
| 13:51.32 | WIMPy | I used SIP for the test case so it dies not seem to be related to the cahnnel. |
| 14:05.36 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-jpgmqyhvxouidofl) |
| 14:05.41 | kpfleming | no, i suspect that the 'switch' code was never written to expect the switch execution to take more than a couple of milliseconds, in which case this would not be an issue |
| 14:06.51 | WIMPy | So you think it is the combination of a loopback and a dundi switch? |
| 14:07.08 | kpfleming | no, i think it's probably just the time that a dundi switch takes |
| 14:07.21 | kpfleming | but the loopback and the call being answered is making it worse |
| 14:07.25 | WIMPy | But that must be expected to take time. |
| 14:07.42 | kpfleming | yes. but the 'switch' code existed years before dundi was created. |
| 14:08.54 | WIMPy | maybe I can try without the loopback. |
| 14:09.37 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:758d:9be3:921d:eb94) |
| 14:35.09 | *** join/#asterisk-dev hrolf (~hrolf@unaffiliated/hrolf) |
| 14:40.30 | WIMPy | It looks like the issue is indeed the loopback, not the dundi switch. |
| 14:41.18 | WIMPy | Or rather the combination of both. |
| 14:55.04 | *** join/#asterisk-dev fobus912 (~fobus912@41.143.31.230) |
| 14:55.26 | fobus912 | Hi All, |
| 14:55.43 | fobus912 | Is it possible to use the D option on the dial plan after the call is bridged |
| 14:55.53 | fobus912 | from the description it says D - Send the specified DTMF strings after the called party has answered, but before the call gets bridged. |
| 14:56.10 | fobus912 | Is there a way to send the DTMF after the call is bridged |
| 14:56.43 | pabelanger | fobus912: #asterisk |
| 14:57.00 | fobus912 | Thanks pabelanger |
| 15:03.01 | *** join/#asterisk-dev irroot (~gregory@197.170.58.6) |
| 15:04.10 | *** part/#asterisk-dev irroot (~gregory@197.170.58.6) |
| 15:11.04 | WIMPy | So does anyone have some further ideas, what to investigate to find out how the issue could be approaced? |
| 15:21.42 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 15:21.42 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:23.13 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 15:23.13 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 15:43.02 | *** join/#asterisk-dev zerohalo (~zerohalo@74-94-141-204-ma.hfc.comcastbusiness.net) |
| 15:46.03 | WIMPy | Ok, got it narrowed down to lswitch. If I use eswitch instead of lswitch, no more digits get lost. |
| 15:46.27 | WIMPy | But it takes a long time to match. Or to find there's no match. |
| 15:48.44 | WIMPy | Can someone explain the exact difference between lswitch and eswitch? |
| 15:50.01 | WIMPy | I can't find anything except for the extensions.conf.sample and that seems to suggest that lswitch passes variables by reference and eswitch by value, but I'm not sure what kind of difference that |
| 15:50.06 | WIMPy | makes. |
| 15:51.39 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 15:51.39 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 16:02.17 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 16:47.22 | *** join/#asterisk-dev irroot (~gregory@197.172.163.132) |
| 16:47.54 | *** part/#asterisk-dev irroot (~gregory@197.172.163.132) |
| 16:53.59 | *** join/#asterisk-dev Crowb4r (u1012@gateway/web/irccloud.com/x-lfwllqtmelnlhgkx) |
| 16:55.37 | *** part/#asterisk-dev asterisk-Tester (~RAMYT@193.227.170.247) |
| 16:57.51 | *** join/#asterisk-dev oej (~olle@87.96.134.129) |
| 16:57.51 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:16.49 | *** join/#asterisk-dev irroot (~gregory@197.110.16.34) |
| 17:17.32 | *** part/#asterisk-dev irroot (~gregory@197.110.16.34) |
| 17:26.48 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 17:36.57 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 17:36.57 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 18:28.11 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 18:28.11 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 18:43.56 | *** join/#asterisk-dev oej (~olle@87.96.134.129) |
| 18:43.56 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:18.09 | *** join/#asterisk-dev malcolmd_ (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 20:18.09 | *** mode/#asterisk-dev [+o malcolmd_] by ChanServ |
| 20:39.31 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-155-145.cablep.bezeqint.net) |
| 20:39.31 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 21:07.53 | *** join/#asterisk-dev otherwiseguy (~otherwise@rrcs-173-197-0-67.west.biz.rr.com) |
| 21:17.43 | tzafrir_laptop | http://lists.digium.com/pipermail/asterisk-users/2012-January/269273.html - Is this a bug? |
| 21:24.26 | mjordan | tzafrir_laptop: are you polling the mailboxes? |
| 21:25.26 | tzafrir_laptop | mjordan, is asterisk doing that? |
| 21:25.52 | mjordan | tzafrir_laptop: there is an option in voicemail.conf to have app_voicemail poll the mailboxes for changes from external sources for this exact purpose |
| 21:26.28 | mjordan | pollmailboxes = yes and pollfrequency = n (seconds) |
| 21:26.30 | tzafrir_laptop | ok. Though 'voicemail show users' does report it differently |
| 21:27.16 | mjordan | that is a little odd, but possible since the new message may not have been triggered through all of the proper notifications |
| 21:28.05 | mjordan | try it with the polling option and see if that gets things in synch |
| 21:28.49 | tzafrir_laptop | OK. That did the trick. Thanks |
| 21:28.53 | mjordan | np |
| 21:57.47 | *** join/#asterisk-dev tzafrir (~tzafrir@212.179.75.202) |
| 21:57.47 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 22:10.42 | *** join/#asterisk-dev Dovid (~Dovid@213.8.121.90) |
| 22:10.53 | Dovid | hi. found a mistake in the docs: http://pastebin.com/BTw20ta5 |
| 22:11.51 | Qwell | What's wrong with it? |
| 22:12.49 | mjordan | There's a '>' instead of a ')' |
| 22:13.01 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 22:13.01 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 22:32.36 | *** join/#asterisk-dev seraphie (~erin@75.76.38.159) |
| 22:52.48 | *** join/#asterisk-dev coreyf1513 (~cfarrell@75-130-93-234.dhcp.wlmn.ct.charter.com) |
| 23:19.49 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-fmnthxovnjtbvgkn) |
| 23:24.39 | *** join/#asterisk-dev luckman212 (~irc@pool-108-41-8-176.nycmny.fios.verizon.net) |
| 23:38.52 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 23:38.52 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 23:47.12 | *** join/#asterisk-dev tamiel (~tamiel@85-171-170-252.rev.numericable.fr) |