| 00:11.52 | lmadsen | o.O |
| 02:41.28 | lmadsen | Corydon76-dig: heh... 10540 gives a segfault |
| 02:49.19 | Corydon76-dig | Backtrace? |
| 02:50.55 | Corydon76-dig | lmadsen: p c->cdr |
| 02:51.23 | Corydon76-dig | and: p c->cdr->start |
| 02:51.26 | lmadsen | Corydon76-dig: $1 = (struct ast_cdr *) 0x2 |
| 02:51.36 | Corydon76-dig | Oooo, that's bad |
| 02:51.38 | lmadsen | Cannot access memory at address 0x282 |
| 02:51.56 | lmadsen | I think this is something in trunk in general... |
| 02:52.02 | lmadsen | because it did it while calling any extension :) |
| 02:52.04 | Corydon76-dig | Yeah, probably |
| 02:52.15 | lmadsen | although I haven't had a chance to try backing out the 10540 patch |
| 02:52.41 | Corydon76-dig | That's memory corruption again, most likely |
| 02:52.49 | Corydon76-dig | time for valgrind, perhaps? |
| 02:52.56 | lmadsen | perhaps |
| 02:52.59 | lmadsen | let me install it |
| 02:55.33 | lmadsen | running it now |
| 02:57.17 | lmadsen | Corydon76-dig: see valgrind.txt on the bug |
| 02:59.24 | *** join/#asterisk-bugs JunK-Y (n=junky@modemcable183.17-83-70.mc.videotron.ca) |
| 02:59.24 | *** mode/#asterisk-bugs [+o JunK-Y] by ChanServ |
| 03:05.52 | *** join/#asterisk-bugs russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 03:05.52 | *** mode/#asterisk-bugs [+o russellb] by ChanServ |
| 03:50.37 | *** join/#asterisk-bugs russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 03:50.37 | *** mode/#asterisk-bugs [+o russellb] by ChanServ |
| 03:53.21 | *** join/#asterisk-bugs russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 03:53.21 | *** mode/#asterisk-bugs [+o russellb] by ChanServ |
| 06:51.33 | *** join/#asterisk-bugs oej (n=olle@soll4-125.cust.blixtvik.net) |
| 07:46.17 | *** join/#asterisk-bugs oej (n=olle@soll4-125.cust.blixtvik.net) |
| 08:03.42 | *** join/#asterisk-bugs agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 09:26.27 | *** join/#asterisk-bugs sx|lappy (n=sxpert@lgit-1225.obs.ujf-grenoble.fr) |
| 09:51.07 | *** join/#asterisk-bugs sx|lappy (n=sxpert@lgit-1225.obs.ujf-grenoble.fr) |
| 10:01.49 | *** part/#asterisk-bugs jmls (n=jmls@81.138.42.77) |
| 10:14.30 | *** join/#asterisk-bugs jmls (n=jmls@81.138.42.77) |
| 12:08.43 | *** part/#asterisk-bugs jmls_home (n=jmls@81.138.42.77) |
| 12:09.59 | *** join/#asterisk-bugs jmls_work (n=jmls@81.138.42.77) |
| 12:30.33 | *** join/#asterisk-bugs flujan (n=flujan@200-160-115-020.static.spo.ctbc.com.br) |
| 13:27.42 | *** join/#asterisk-bugs lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:27.42 | *** mode/#asterisk-bugs [+o lmadsen] by ChanServ |
| 13:29.04 | lmadsen | morning all! |
| 14:17.54 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 14:48.23 | *** join/#asterisk-bugs miguel3239 (n=elguerom@ns1.nashuacs.com) |
| 15:30.18 | *** join/#asterisk-bugs d1mas (n=chatzill@ip195.117.adsl.wplus.ru) |
| 15:30.53 | d1mas | question: why Asterisk DSP code is designed to return DTMF_END only and never DTMF_BEGIN ? |
| 15:54.57 | lmadsen | hrmmm... maybe it's not VLDTMF and it only sent DTMF_ENDs ? |
| 15:57.22 | d1mas | lmadsen: do you know what VL in VLDTMF stands for ? |
| 15:57.30 | lmadsen | variable length |
| 15:58.03 | d1mas | aha... |
| 15:59.08 | d1mas | lmadsen: what does it mean "it is not VLDTMF" then? I suppose I can generate as long digit as I want just holding the key... |
| 15:59.29 | d1mas | ok, I will re-phrase my question |
| 15:59.39 | *** join/#asterisk-bugs putnopvut (n=putnopvu@216.207.245.1) |
| 15:59.40 | *** mode/#asterisk-bugs [+o putnopvut] by ChanServ |
| 16:00.32 | d1mas | dsp.c detects where digit started and where it ends. So it _could_ generate both DTMF_BEGIN and DTMF_END but it only generates END. Why? |
| 16:00.42 | lmadsen | good question |
| 16:01.32 | file | it was changed to generate both a begin and an end, but it may not have been changed the right way |
| 16:01.41 | lmadsen | oic |
| 16:01.53 | d1mas | oh |
| 16:02.15 | d1mas | So can I assume it will be good move to generate both? |
| 16:03.06 | file | if it doesn't already, sure |
| 16:03.06 | d1mas | file: it is not AFAIK |
| 16:03.59 | d1mas | file: there IS code which can generate DTMF_BEGIN but it works only when DSP_DIGITMODE_MUTECONF or DSP_DIGITMODE_MUTEMAX is set. Which is not often. |
| 16:04.14 | file | and like, barely any of us core developers know dsp.c |
| 16:04.34 | d1mas | (and that code is broken actually as I already explained Qwell. He agreed) |
| 16:05.03 | d1mas | ok. I just wanted to know if DTMF_BEGIN is desired thing |
| 16:05.31 | d1mas | file: I have another question to you anyway. And you know it :) |
| 16:08.45 | d1mas | eh :) |
| 16:08.47 | putnopvut | What is file doing today? |
| 16:08.53 | d1mas | Will find you tomorrow then :) |
| 16:09.04 | putnopvut | briding? netsock? something super secret? |
| 16:09.14 | d1mas | drilling oil :) |
| 16:09.19 | file | putnopvut: I don't have anything super secret :( |
| 16:09.24 | putnopvut | Aw... |
| 16:09.38 | putnopvut | You and I should work on a joint super-secret effort of some sort. |
| 16:09.48 | putnopvut | You do all the work, and I leak the secret. |
| 16:09.52 | file | pfft |
| 16:09.57 | file | I haven't done a joint project in awhile |
| 16:10.00 | codefreeze | How about global domination? |
| 16:10.07 | putnopvut | That could be fun. |
| 16:10.09 | file | there is something... |
| 16:12.26 | *** join/#asterisk-bugs russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 16:12.27 | *** mode/#asterisk-bugs [+o russellb] by ChanServ |
| 16:48.59 | flujan | putnopvut: hi... I will test the queue past tomorrow morning... :D |
| 16:49.13 | flujan | putnopvut: just in time, how are you doing? :) |
| 16:49.32 | flujan | putnopvut: here in Brazil we enter in a carnival periody... I just return work today. |
| 16:49.33 | putnopvut | I'm doing fine. |
| 16:49.45 | putnopvut | How long have you had the patch applied? |
| 16:50.40 | flujan | putnopvut: no days... I left last friday leaving the vanilla 1.4.17 on the machine... |
| 16:50.52 | flujan | I will put the patch on production tomorrow morning... |
| 16:51.03 | putnopvut | Oh, okay. |
| 16:52.59 | flujan | putnopvut: we really use the queue here. Just now, there are 56 agents and 20 guys waiting in the queue. If I stop asterisk now and try the patch, my boss will kill me... He is just amazed that the server stop crashing... ( queues.conf instead of the realtime ) that he does not want it to stop anymore... :P |
| 16:53.58 | putnopvut | I understand. There's no rush. I'd rather be certain that the patch works than to rush it into Asterisk and find out it is no good. |
| 16:55.12 | jmls_work | putnopvut: where's your spirit of adventure ? |
| 16:55.37 | putnopvut | jmls_work: it is strongly rooted in all things non-work-related. |
| 16:56.51 | jmls_work | heh |
| 16:57.08 | jmls_work | there is such a thing as non-work-related ? |
| 17:18.44 | d1mas | Anyone familar with Zaptel+Meetme at the same time? When Zap calls MeetMe conference and presses digits, DTMF tones get played to all participants. This does not happen when SIP callers press digits. I've checked that dsp.c actually squelches DTMF tones from signal. So who plays tones to the conference ? |
| 17:19.30 | jmls | M11943 |
| 17:19.31 | MuffinMan | [assigned] [Asterisk] Functions/func_logic 0011943: Feature to write variables to existing channels other than your own (func chanvar) reported by ramonpeek http://bugs.digium.com/view.php?id=11943 |
| 17:19.47 | jmls | anyone like the idea of read-only variables ? |
| 17:20.10 | Qwell | jmls: const? |
| 17:20.16 | lmadsen | ya... I was thinking const too |
| 17:20.31 | lmadsen | Set(CONST(foo)=bar) |
| 17:20.35 | jmls | potato / potatoe ;) |
| 17:20.36 | Qwell | read-only would make 0 sense, since...well...you wouldn't be able to write to it |
| 17:20.38 | lmadsen | Set(foo=blah) |
| 17:20.44 | Qwell | which means it would always be empty |
| 17:20.47 | lmadsen | [ERROR]: Variable is read only |
| 17:21.43 | lmadsen | I think it could make dialplans error prone to be honest... |
| 17:21.47 | jmls | if you had readonly, you could allow it to be created, but not modified, from another channel |
| 17:22.02 | jmls | so you couldn't overwrite an existing variable |
| 17:22.06 | lmadsen | but it already isn't modifiable from another channel.... |
| 17:22.10 | lmadsen | unless it's inherited |
| 17:22.15 | jmls | that's the problem |
| 17:22.22 | Qwell | 11943 adds that :D |
| 17:22.23 | lmadsen | so don't inherit it :) |
| 17:22.26 | lmadsen | M11943 |
| 17:22.27 | MuffinMan | [assigned] [Asterisk] Functions/func_logic 0011943: Feature to write variables to existing channels other than your own (func chanvar) reported by ramonpeek http://bugs.digium.com/view.php?id=11943 |
| 17:22.48 | lmadsen | heh, neat :) |
| 17:23.00 | Qwell | that's what I said. go test it! |
| 17:23.03 | jmls | if you are using originate, you can't inherit because the second leg is already created before you get to the dialplan of the first leg |
| 17:23.18 | jmls | (or vice-versa - can't remember which) |
| 17:23.29 | lmadsen | ah yes, atis_work saw that the other day |
| 17:23.44 | d1mas | Qwell: hello. regarding 11796 - is something else need to be done ? |
| 17:23.54 | lmadsen | M11796 |
| 17:23.55 | MuffinMan | [new] [Asterisk] PBX/General 0011796: [patch] refactoring of fax tone detection in DSP reported by dimas http://bugs.digium.com/view.php?id=11796 |
| 17:24.15 | Qwell | d1mas: I'd like to see more than just IgorG test it |
| 17:24.31 | jmls | Qwell: if you could prevent a variable from being overwritten in a channel from another channel, surely there is no harm in allowing a *new* variable to be created ? |
| 17:24.31 | Qwell | the code mostly looked okay the last time I looked at it though |
| 17:24.41 | d1mas | Qwell: I did :) I installed that dsp.c to my production 1.4 |
| 17:24.47 | d1mas | it runs there now |
| 17:24.48 | Qwell | d1mas: I mean besides you :p |
| 17:24.55 | d1mas | ok :) |
| 17:25.23 | Qwell | while I'm sure it works for your scenario, that was the scenario it was written for - so what I'd like to see is somebody with different usage of it |
| 17:26.07 | d1mas | Qwell: sure I understand. However I do not know how to encourage people to test it |
| 17:26.53 | putnopvut | If it gets put into a beta of the next 1.6 release, it would get tested... |
| 17:27.12 | putnopvut | But that's probably jumping the gun a bit. |
| 17:28.09 | d1mas | hehe. I have two more patches for dsp.c so by the moment they all be integrated, DSP will change A LOT from where it is now... |
| 17:36.25 | d1mas | Qwell: by any chance - do you know the idea behind AST_FLAG_END_DTMF_ONLY channel flag? If someone needs END frames only - why not simple ignore BEGINs ? |
| 17:36.39 | Qwell | d1mas: no idea |
| 17:37.48 | d1mas | oh. Russellb, maybe you? |
| 17:38.17 | russellb | what? |
| 17:38.27 | russellb | um |
| 17:38.53 | russellb | to avoid extra processing for emulation when it's not needed |
| 17:39.04 | russellb | and for some cases when no frames are coming through which allow proper processing for emulating the full digit |
| 17:39.17 | russellb | it has been a while since i have looked at it .. |
| 17:39.27 | d1mas | russellb: by "extra processing" you mean the code of ast_read only or something else? |
| 17:41.26 | d1mas | russelb: well my understanding is that DTMF frames are quite rare (compared to voice for example) so performance gain from not producing BEGIN frames is insignificant. Am I wrong? |
| 17:42.00 | russellb | in ast_read, yeah |
| 17:42.18 | russellb | but it's more for the case where there are no extra frames coming through to time the emulation off of |
| 17:42.21 | russellb | SIP INFO is a key example |
| 17:42.25 | russellb | media isn't coming through |
| 17:42.38 | russellb | so if you turn the END from an INFO message into a begin, then you have no way to later generate the END |
| 17:42.52 | d1mas | ah... |
| 17:42.56 | russellb | so, we just pass the END through, so it can go back out as INFO |
| 17:43.18 | russellb | i think that is what prompted the creation of that flag |
| 17:44.19 | d1mas | that is something I do not understand yet but that is definitely important stuff. I will think about it |
| 17:44.42 | d1mas | much more important than performance gain |
| 17:47.49 | russellb | yeah, that was the reason ... the performance part was just a side effect |
| 17:48.56 | d1mas | russellb: sorry, still need some explanation.Tried to understand it myself but it does not work :) I'm not familar with SIP INFO - are you saying that when DTMF mode is INFO, there are not begin and end messages, only the end ? |
| 17:49.43 | russellb | that is correct |
| 17:49.59 | russellb | the dtmf is sent as a single SIP signalling message |
| 17:50.14 | russellb | if both sides are SIP INFO, then the media may not be going through Asterisk, because it doesn't need to |
| 17:50.17 | russellb | since we can monitor DTMF without it |
| 17:50.38 | russellb | but in that case, if we turn the single DTMF frame into a begin, there are no other frames coming through ast_read we can use to make sure we generate the END at the right time |
| 17:50.56 | d1mas | russellb: ok. But what you mean seying "so if you turn the END from an INFO message into a begin, then you have no way to later generate the END" ? If standalone END is translated into BEGIN+END - there will be END anyway... |
| 17:51.26 | russellb | how would you know to send a BEGIN and END at the same time? |
| 17:51.28 | russellb | and what's the point? |
| 17:52.05 | d1mas | russellb: well, it won't be the same time - END translated to BEGIN and then later END is generated (emulation)... |
| 17:52.16 | russellb | right, but that's my point, emulation can't work in this case |
| 17:52.21 | d1mas | ahaaaa... there is no voice so no END will be generated "later" |
| 17:52.28 | russellb | right :) |
| 17:52.31 | d1mas | got it |
| 17:52.40 | russellb | cool |
| 17:52.45 | d1mas | thanks |
| 17:53.02 | russellb | no problem |
| 17:53.53 | russellb | i want you to understand, you're a good help :) |
| 17:54.17 | russellb | if i can't explain it to you, it's probably wrong, so it's a good exercise :) |
| 17:54.32 | d1mas | :) |
| 17:58.38 | d1mas | russellb: but who actually sets this flag in case of INFO DTMF mode? I see no such code in chan_sip.c ? ast_bridge sets this flag when channel driver does not provide send_digit_begin function but SIP driver provides it. |
| 18:01.53 | russellb | the SIP driver doesn't provide it if the channel uses INFO dtmf |
| 18:01.59 | russellb | it's sort of a hack :) |
| 18:02.43 | d1mas | omg |
| 18:03.20 | d1mas | oh now I see... |
| 18:05.32 | d1mas | russellb: one last thing. when application handles a call - the call is not considered "bridged" right? So the flag is not set and my understanding is that ast_read may emulate BEGINs . Correct? |
| 18:07.02 | russellb | correct |
| 18:07.11 | russellb | but if it's not bridged, then the media is coming into asterisk by definition |
| 18:08.04 | russellb | and we want emulation to happen then |
| 18:08.30 | d1mas | ok |
| 18:08.43 | d1mas | life isn't easy :) |
| 18:43.51 | d1mas | russellb: actually... ast_read can still activate emulation mode when AST_FLAG_END_DTMF_ONLY is on. This happens if it receives END frame with very short duration - in this case it reschedules END for later. This looked pretty much ok for me until your description of SIP+INFO |
| 18:44.55 | d1mas | russellb: now I would say that if too short DTMF END would be delivered with SIP INFO, it won't be processed properly (or it will be delayed considerably until next voice/null frame) |
| 18:45.08 | d1mas | considerably = significantly |
| 19:49.26 | russellb | d1mas: if it does that, then you are correct that it is wrong |
| 19:49.43 | russellb | if it is END_ONLY, and the duration is too short, then the duration should just be bumped up and passed along |
| 19:50.05 | Qwell | d1mas: I think you forgot to upload a patch on 11949 |
| 19:50.21 | d1mas | M11949 |
| 19:50.22 | MuffinMan | [new] [Asterisk] Resources/res_features 0011949: [patch] log what digits feature tries to match reported by dimas http://bugs.digium.com/view.php?id=11949 |
| 19:51.35 | d1mas | cool. I definitely attached it. Interesting - to which issue :) |
| 19:51.44 | Qwell | heh |
| 19:52.08 | d1mas | now attached. It is a one-liner actually :) |
| 19:52.18 | Qwell | yeah, I think that's good to go in 1.4 too |
| 19:54.10 | *** join/#asterisk-bugs agx (n=badpengu@81-174-45-198.dynamic.ngi.it) |
| 19:55.20 | d1mas | russellb: sorry, what "bumped up" means? :) |
| 19:55.27 | d1mas | (in respect to duration) |
| 19:56.59 | russellb | increased |
| 19:57.17 | russellb | if (duration < MIN_DURATION) duration = MIN_DURATION |
| 19:59.38 | d1mas | russellb: but is it valid action to change len on a frame and pass it further ? |
| 20:00.14 | russellb | sure, we make the rules :) |
| 20:00.24 | russellb | if we get a digit with a duration we find unacceptable, sure, why not modify it :) |
| 20:00.27 | russellb | we're not a proxy |
| 20:00.30 | d1mas | I recall something related on Mantis - there was problem with RTP timestamps or something... hold on |
| 20:00.39 | russellb | ah, that's different |
| 20:00.54 | russellb | if you regenerate timestamps, that screws up the jitterbuffer on the endpoint |
| 20:02.08 | d1mas | russellb: well because I (as a program at the remote end) would expect that lens of packets add up to a call length and not that sum(len) is greater than real time length |
| 20:02.37 | d1mas | well, it was bad explanation. Let me put it this way - receiving a RTP frame I would expect its timestamp is >= last_timestamp+last_len |
| 20:03.01 | d1mas | if len field can be adjusted for packets - this is not true anymore |
| 20:03.04 | russellb | right, well the only way that could happen is with INFO |
| 20:03.15 | d1mas | hmm... |
| 20:03.20 | russellb | if the length gets adjusted with DTMF associated with BEGIN and END, then they get queued up |
| 20:03.25 | russellb | and are generated in the time that we say it is |
| 20:04.18 | d1mas | "hmm..." = "yes you are right but there is something wrong with it" :) |
| 20:09.22 | d1mas | jfyi, why I'm digging in it - the emulation code as it is currently looks a bit complicated to me. I personally find it difficult to trace its logic and there are a lot of subtle situations where given status (combination of flags + incoming event) are not handled. There are already couple of related issues on Mantis - 11740 and 11911 |
| 20:10.26 | russellb | it is complicated ... it got complicated over time ... |
| 20:11.12 | d1mas | that is destiny of every piece of code - it gets complicated over time... |
| 20:12.34 | russellb | :) |
| 20:26.23 | *** join/#asterisk-bugs sx|lappy (n=sxpert@home.riquer.fr) |
| 20:31.55 | *** part/#asterisk-bugs agx (n=badpengu@81-174-45-198.dynamic.ngi.it) |
| 20:59.18 | *** join/#asterisk-bugs sx|lappy (n=sxpert@home.riquer.fr) |
| 21:11.40 | *** join/#asterisk-bugs sx|lappy (n=sxpert@home.riquer.fr) |
| 21:29.14 | *** join/#asterisk-bugs kpfleming (n=kpflemin@216.207.245.1) |
| 21:29.14 | *** mode/#asterisk-bugs [+o kpfleming] by ChanServ |
| 21:37.11 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |