| 00:19.05 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.pa.comcast.net) |
| 00:19.29 | ZaVoid | burp |
| 00:34.18 | *** join/#asterisk-dev outtolunc (n=me@c-67-170-211-86.hsd1.ca.comcast.net) |
| 00:34.48 | gitguy | is 1.6.0-beta8 more stable than latest 1.4 now? |
| 00:35.38 | gitguy | i'm considering using 1.6.0-beta8, 1.4 works great for me but i'm feeling adventurous |
| 00:39.53 | *** join/#asterisk-dev uluatu (n=deg@189.58.9.17.adsl.gvt.net.br) |
| 00:40.30 | jpeeler | codefreeze: i think i need help with explaining all these NOTNOW defines in pbx.c |
| 00:40.36 | jpeeler | or at least one in particular |
| 00:41.02 | jpeeler | perhaps i'll catch you tomorrow though |
| 00:46.42 | Corydon76-dig | jpeeler: which one? |
| 00:47.11 | *** part/#asterisk-dev sruffell (n=sruffell@216.207.245.1) |
| 00:47.15 | jpeeler | Corydon76-dig: the second one in pbx_find_extension |
| 00:48.05 | Corydon76-dig | jpeeler: it's a define in case murf's hashtabs aren't working |
| 00:48.20 | jpeeler | well the code doesn't execute right? |
| 00:48.37 | Corydon76-dig | So if hashtabs don't work, then use the linked lists |
| 00:48.58 | jpeeler | how do i switch? i'm not following |
| 00:49.37 | Corydon76-dig | If you define the value, then it will use the linked lists, although it's not exactly fair, given that it executes both sections of code |
| 00:50.14 | jpeeler | oh so manually just define it, ok let me check |
| 00:50.34 | Corydon76-dig | It's not meant to be used by anybody other than developers |
| 00:50.49 | Corydon76-dig | And really, not by anybody but murf |
| 00:51.50 | jpeeler | i can't even make a call with it defined |
| 00:52.23 | Corydon76-dig | I think the intent is to show the difference |
| 00:52.54 | Corydon76-dig | in terms of code path |
| 00:52.55 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.137) |
| 00:54.25 | jpeeler | one day i will see the bigger picture... but until then i just see what parameters are passed into a function |
| 00:54.40 | jpeeler | if exten is a zero length string, the function returns NULL in 1.4 |
| 00:54.48 | jpeeler | not so in trunk, and that's causing problems |
| 00:54.54 | Corydon76-dig | Ah... |
| 00:55.15 | Corydon76-dig | Then there's bitrot |
| 00:55.40 | jpeeler | so the function should return NULL then correct? |
| 00:55.44 | Corydon76-dig | Could probably be removed, then |
| 00:56.28 | jpeeler | what could be removed? |
| 00:57.46 | Corydon76-dig | the code within those ifdefs |
| 00:57.59 | Corydon76-dig | If you can't turn on the define, then there's bitrot |
| 00:58.17 | jpeeler | oh i thought you referring to the return behavior changing |
| 00:58.21 | Corydon76-dig | You know that terminology, right? |
| 00:58.24 | jpeeler | yes |
| 00:58.50 | Corydon76-dig | Right, the function behavior change means bitrot in the old code |
| 00:58.55 | jpeeler | how valid would it be to modify the check below that NOTNOW block |
| 00:59.03 | jpeeler | if (e && strcmp(e->exten,"")) { /* found a valid match */ |
| 00:59.22 | jpeeler | that seems to solve the problem for me |
| 00:59.48 | Corydon76-dig | Are you trying to make it so that you can select the older code? |
| 00:59.49 | jpeeler | i guess that's how you check for zero length strings |
| 00:59.53 | jpeeler | it's not null |
| 01:00.13 | Corydon76-dig | Checking for zero length strings should be done with ast_strlen_zero |
| 01:00.16 | jpeeler | nope, the NOTNOW is undefined as it originally was |
| 01:00.18 | jpeeler | ah right |
| 01:00.24 | jpeeler | i forgot about that function |
| 01:00.40 | Corydon76-dig | No problem; we all forget sometimes |
| 01:01.04 | Qwell | it's been beaten into most of us :D |
| 01:01.08 | jpeeler | at a high level, i'm fixing the multiparking stuff. when # is pressed and nothing is pressed, the code is currently trying to match on the extension '' and is falling through |
| 01:01.35 | Corydon76-dig | Ah... |
| 01:01.40 | jpeeler | i suck at explaining stuff, but that's the general idea |
| 01:01.51 | Corydon76-dig | You're doing fine |
| 01:02.09 | jpeeler | and i'm using 1.4 behavior as the golden standard which makes sense since it works there |
| 01:02.11 | Corydon76-dig | As a recent college graduate, you're probably better than some of the rest of us |
| 01:02.32 | jpeeler | that's flattering, but just not the case, but maybe soon :) |
| 01:02.42 | Corydon76-dig | You're much closer to paper writing. ;-) |
| 01:03.35 | Corydon76-dig | I sometimes have to resist the urge to say "because I'm a crabby old man, and I said so!" |
| 01:04.04 | Corydon76-dig | Well, not really. |
| 01:04.32 | jpeeler | heh, well i don't consider you old |
| 01:04.39 | Corydon76-dig | I do. |
| 01:04.56 | jpeeler | fine, you win |
| 01:05.03 | Corydon76-dig | My hair is turning gray already |
| 01:05.12 | jpeeler | sometimes i consider myself old as well |
| 01:05.16 | jpeeler | i have a few gray hairs :( |
| 01:05.24 | Corydon76-dig | Heh |
| 01:05.41 | jsmith | Yeah... you guys are *so* old |
| 01:05.48 | Corydon76-dig | Unlike my brother at 32, though, I am not balding. |
| 01:05.49 | jsmith | ducks and hides |
| 01:06.05 | jsmith | Corydon76-dig: That's nothing... my little brother started going bald in high school |
| 01:06.17 | Corydon76-dig | jsmith: heh |
| 01:06.24 | jpeeler | Corydon76-dig: if it were not for ast_strlen_zero though, what is the proper method for checking a zero length string? |
| 01:06.37 | jsmith | Corydon76-dig: In fact... I have ninety first cousins, and out of *all* the male cousins, I'm the only one with anything resembling a full head of hair |
| 01:06.38 | Corydon76-dig | jsmith: my brother had a friend in HS who was completely bald by his senior year |
| 01:07.02 | jpeeler | jsmith: name them, now |
| 01:07.10 | jsmith | jpeeler: Which side of the family? |
| 01:07.15 | Qwell | ninety-first cousins? |
| 01:07.20 | jpeeler | lol, the bigger half |
| 01:07.23 | Corydon76-dig | jpeeler: if (foo && foo) { / not blank */ } |
| 01:07.34 | Corydon76-dig | Err |
| 01:07.41 | Corydon76-dig | I hate it when it does that |
| 01:07.44 | Qwell | if (foo || !foo) |
| 01:08.03 | Corydon76-dig | imagine *'s around the part that went bold |
| 01:08.16 | jsmith | jpeeler: Clark, Allison, Diana, Kelley, Kyle, Jonathon, Terry, Mandi (one family) |
| 01:08.23 | jpeeler | oh wow, he's doing it |
| 01:08.45 | jsmith | jpeeler: Lizette, Lane, Lyle, Laramie, Lauren, Lynelle, Lucinda, Leandra |
| 01:09.01 | jpeeler | Qwell: wouldn't that match non zero length strings? |
| 01:09.02 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.pa.comcast.net) |
| 01:09.12 | Qwell | oh, I didn't see the question |
| 01:09.24 | Corydon76-dig | if (!foo || !*foo) { ... } |
| 01:09.27 | Qwell | jsmith: they all have L names? |
| 01:09.53 | Corydon76-dig | Qwell: some parents are sick in the head |
| 01:09.54 | jsmith | Qwell: Yes, in that family they do.... my aunt's name is Laurel, and my uncle's name is Leon, so all the kids have L names |
| 01:10.09 | jsmith | OK... next! |
| 01:10.26 | jsmith | Rod, Dan, Deon, Julie, and Sunny |
| 01:10.31 | Corydon76-dig | I had a teacher in HS whose family was like that (with J, though) |
| 01:11.08 | jsmith | Cameron, Dave, Michelle |
| 01:11.17 | jsmith | Cody, Kami |
| 01:11.54 | jsmith | Ty, Taya, Mindy, Joni, Meagan, Sage, Tennison (I'm missing another sister in there somewhere) |
| 01:12.11 | jsmith | Kayla, Amy, Kendell, Betsy, Zane |
| 01:12.28 | jpeeler | that's 37 i think, i'm impressed enough |
| 01:12.33 | jsmith | Landon, Ben, Ariel, Aubrey |
| 01:13.02 | jsmith | jpeeler: You have to understand... my mom had 11 brothers and sisters |
| 01:13.19 | jsmith | jpeeler: My grandmother had grandkids (from her older children) before she was done having children herself. |
| 01:13.25 | jpeeler | amazing |
| 01:14.00 | tzanger | jsmith: holy shit |
| 01:14.31 | jsmith | Gives a whole new meaning to the term "family reunion" |
| 01:14.47 | jsmith | When we got together for Thanksgiving, we'd literally rent out a church just to be able to hold everyone |
| 01:14.48 | *** join/#asterisk-dev uluatu (n=deg@189.58.9.17.adsl.gvt.net.br) |
| 01:15.36 | jpeeler | jsmith: so what did you guys do? |
| 01:16.03 | jsmith | We'd rent a church, get fat on turkey, and then play basketball |
| 01:16.24 | jsmith | There were always enough people to sport two or three teams |
| 01:17.07 | jpeeler | wow, that's impressive |
| 01:20.49 | jpeeler | Corydon76-dig: thanks for looking over the API documentation by the way |
| 01:22.18 | jpeeler | i should go home now, bye everybody |
| 01:22.37 | jsmith | Go home! |
| 01:40.42 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23) |
| 02:05.30 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.pa.comcast.net) |
| 02:18.25 | ZaVoid | jsmith? |
| 02:22.03 | *** join/#asterisk-dev moy (n=moyhu@189.169.83.74) |
| 03:05.49 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 03:05.49 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 03:10.03 | *** join/#asterisk-dev outtolunc (n=me@c-67-170-211-86.hsd1.ca.comcast.net) |
| 03:21.41 | *** join/#asterisk-dev obnauticus (n=obnautic@c-67-160-187-7.hsd1.wa.comcast.net) |
| 03:50.12 | Corydon76-dig | Qwell: ping |
| 03:50.33 | Corydon76-dig | any other database guys around? |
| 03:55.59 | *** part/#asterisk-dev mog (n=mog@c-68-62-219-86.hsd1.al.comcast.net) |
| 04:02.13 | *** join/#asterisk-dev jeffspeff (n=jeff@c-68-53-81-73.hsd1.ky.comcast.net) |
| 04:03.51 | snuff-home | mm i know some db.. |
| 04:11.30 | Corydon76-dig | snuff-home: can you have a SELECT statement that has uncommitted changes? |
| 04:11.48 | Corydon76-dig | Most of the time, no... I'm wondering about some of the weird stuff |
| 04:12.04 | Corydon76-dig | like "select next(id) from dual" on Oracle |
| 04:13.01 | *** join/#asterisk-dev gitguy (n=diego@adsl-134-171.click.com.py) |
| 04:13.06 | gitguy | hello guys |
| 04:14.11 | gitguy | i compiled libogg 1.1.3, speex 1.2beta3, asterisk 1.4.19.2 and everything is fine, but with disallow=all;allow=speex i get weird noises |
| 04:14.13 | snuff-home | mm sorry no idea.. only used oracle once or twice at uni.. forgotten most |
| 04:14.19 | gitguy | using xlite/zoiper |
| 04:14.40 | gitguy | same weird noises with older version of speex/libogg too |
| 04:15.10 | gitguy | but with older version i had a WARNING message that got fixed with newer versions of speex |
| 04:15.20 | gitguy | although the bad noise is still there |
| 04:17.23 | snuff-home | file it on mantis (bugs.digium.com) |
| 04:18.24 | gitguy | how do i describe the "weird noise", just as "weird noise" ? :P |
| 04:18.49 | snuff-home | attach wav/ogg sample? |
| 04:19.41 | gitguy | how can i record it |
| 04:19.44 | gitguy | from softphone |
| 04:20.40 | snuff-home | mm.. should be option.. or try record via 'mixmonitor' |
| 04:21.13 | gitguy | ok |
| 04:21.13 | snuff-home | on the asterisk side |
| 04:21.15 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177582051.dsl.bell.ca) |
| 04:21.18 | gitguy | ok |
| 04:21.20 | gitguy | thanks |
| 04:21.23 | snuff-home | :) |
| 04:21.49 | gitguy | i'll do that tomorrow at morning, been awake since 07:00 am and is 12:20 am now :S |
| 04:22.02 | gitguy | see ya laterz guys xD |
| 04:30.24 | *** join/#asterisk-dev CunningPike (n=arodgers@S010600095b33697f.vc.shawcable.net) |
| 06:10.14 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 06:29.28 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 06:44.34 | *** join/#asterisk-dev Laureano (n=Laureano@OL93-199.fibertel.com.ar) |
| 06:44.40 | Laureano | Hello guys |
| 06:46.24 | snuff-home | ello |
| 06:47.15 | Laureano | Was my user (Laureano) logged here a few minutes ago? |
| 06:47.29 | snuff-home | nope |
| 06:48.04 | Laureano | Thank you snuff-home. |
| 06:55.08 | jmls_home | hey. what does "WARNING[31180]: pbx.c:6081 pbx_builtin_saynumber: We were unable to say the number 08, is it too large?" mean ? |
| 06:55.19 | jmls_home | apart from the bleeding obvious |
| 06:55.46 | jmls_home | doing some stress tests (30 sip channels -> zap out -> zap in with mixminitor) |
| 06:55.56 | jmls_home | and occasionally I get this on the console |
| 07:07.32 | snuff-home | mm.. interesting problem |
| 07:18.11 | snuff-home | because its 'atoi'ed.. so it should always be a number.. rather than '08' |
| 07:21.29 | *** join/#asterisk-dev fenlander (n=fenlande@82.152.81.57) |
| 08:06.04 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 08:37.01 | *** join/#asterisk-dev tzafrir (n=tzafrir@local.xorcom.com) |
| 08:37.01 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:40.13 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 08:53.18 | *** join/#asterisk-dev steliosk (n=Stelios@athedsl-170653.home.otenet.gr) |
| 08:56.04 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 09:01.40 | *** join/#asterisk-dev floppp (n=flopp@nat-staff.b3g-telecom.com) |
| 09:02.28 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 09:12.16 | *** join/#asterisk-dev _ys (n=yuri@236-069.nat.mns.ru) |
| 09:15.32 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 09:20.04 | jmls_home | snuff-home: it works 9 times out of 10. |
| 09:20.11 | jmls_home | gotta get to work; |
| 09:20.14 | jmls_home | be back soon |
| 09:38.24 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 09:57.26 | *** join/#asterisk-dev RoyK (n=roy@fw.fortel.no) |
| 10:46.04 | *** join/#asterisk-dev _ys (i=yuri@91.151.196.254) |
| 10:53.27 | *** join/#asterisk-dev DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 11:03.58 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 11:03.58 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 11:05.01 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.135) |
| 11:17.42 | *** part/#asterisk-dev jmls_work (n=jmls_wor@mail.tessera.co.uk) |
| 11:20.30 | _ys | hi. astobj2 is ok in trunk? |
| 11:20.45 | _ys | on my box "astobj2 test 1" failed |
| 11:23.08 | *** join/#asterisk-dev juanjoc (n=juanjoc@host197.190-31-170.telecom.net.ar) |
| 11:35.10 | *** join/#asterisk-dev jmls_work (n=jmls_wor@mail.tessera.co.uk) |
| 12:01.00 | *** join/#asterisk-dev uluatu (n=deg@189.58.9.17.adsl.gvt.net.br) |
| 12:06.48 | *** join/#asterisk-dev uluatu (n=deg@189.58.9.17.adsl.gvt.net.br) |
| 12:10.28 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:13.12 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.pa.comcast.net) |
| 12:20.34 | *** join/#asterisk-dev jeffg (i=6PlM2mpO@pdpc/supporter/active/jeffg) |
| 12:25.48 | jmls_work | if I have a Dial(Zap/G1/123456,50) this _should_ dial for 50s, yes ? |
| 12:26.35 | jmls_work | is there anything that could shorten the ring time ? I have a log which shows that the ring time is consistently 17s |
| 12:29.19 | *** join/#asterisk-dev kickserver (n=picachu@host-static-89-41-72-225.moldtelecom.md) |
| 12:30.00 | *** join/#asterisk-dev shido6 (n=shido6@209.114.208.192) |
| 12:30.02 | kickserver | hey guys. I want to create small billing system. where should I collect cdr ? |
| 12:30.12 | *** join/#asterisk-dev rolek (n=rolek@87.215.195.98) |
| 12:30.23 | shido6 | what do you want it to do? |
| 12:30.32 | shido6 | just billing? no provisioning? |
| 12:30.40 | kickserver | just billing |
| 12:31.02 | kickserver | create a wrapper around dial , or better write another cdr_ module ? |
| 12:31.19 | kickserver | btw, what happens if a block cdr for a long time ? like 3-5 secs |
| 12:31.29 | kickserver | what if for 30 secs |
| 12:31.41 | shido6 | so ""block" ? |
| 12:31.45 | shido6 | block? |
| 12:31.55 | shido6 | explain what you mean by blocking cdr |
| 12:33.47 | *** join/#asterisk-dev uluatu (n=deg@189.58.9.17.adsl.gvt.net.br) |
| 12:43.30 | *** join/#asterisk-dev sruffell (n=sruffell@adsl-074-185-078-025.sip.bhm.bellsouth.net) |
| 12:43.30 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 12:45.17 | rolek | Could someone please have a look at the patch that was filed for bug 12322? |
| 12:48.48 | *** join/#asterisk-dev sorcs (n=sorcs@195.204.248.62) |
| 12:48.57 | sorcs | I am setting up my asterisknow server and i got one error [May 14 14:12:12] NOTICE[3281] chan_iax2.c: Asked to authenticate to 88.151.165.10 with an RSA key, but they don't allow RSA authentication | .the VOIP provider use md5. how to change |
| 13:00.06 | *** join/#asterisk-dev pgarcia (n=pedgarci@yoda.kanatek.com) |
| 13:17.48 | *** join/#asterisk-dev codefreeze-lap (n=murf@216.166.159.235) |
| 13:19.05 | *** join/#asterisk-dev uluatu (n=deg@200.195.161.164) |
| 13:19.52 | *** join/#asterisk-dev uluatu (n=deg@200.195.161.164) |
| 13:21.39 | rolek | Are there by chance any chan_sip developers around? |
| 13:24.24 | jsmith | rolek: Just ask your question, and if someone knows the answer, they'll answer |
| 13:24.33 | jsmith | rolek: Otherwise, they won't |
| 13:25.28 | *** join/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 13:26.08 | rolek | jsmith: well, I have some specific questions about the patch I wrote to fix a bug. I had some discussion with oej about it some time ago, but we were interrupted and never saw a chance to continue.. |
| 13:27.20 | rolek | jsmith: I would like to know if the solution I used is a proper one.. |
| 13:28.05 | jsmith | Is it on the bug tracker? |
| 13:28.19 | rolek | jsmith: yes. Bug 12322 |
| 13:30.38 | rolek | jsmith: I'm using a flag to mark a reinvited call that is being hung up, but it might be more correct to just use a flag for a reinvited call (at the moment the reinvite happens) |
| 13:31.08 | rolek | jsmith: However, oej said the way that chan_sip currently checks for a reinvite is not correct. |
| 13:31.37 | rolek | jsmith: And it hardly seems prudent to file a bug for that ("bug: oej said that...") |
| 13:34.44 | jsmith | The only thing I can suggest is to have some patience... the developers are working very hard to address all the issues raised in the bug tracker, but they're plenty busy |
| 13:35.54 | rolek | jsmith: True, but one is allowed to ask, right? |
| 13:38.07 | *** part/#asterisk-dev jsmith (n=jsmith@72.21.36.138) |
| 13:38.11 | *** join/#asterisk-dev jsmith (n=jsmith@72.21.36.138) |
| 13:38.11 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 13:38.21 | jsmith | rolek: Absolutely! You're always allowed to ask. |
| 13:38.32 | ctooley | rolek, let me go look at the bug, if I can help, I'll try. |
| 13:39.12 | rolek | ctooley: well, the patch I filed fixes it. I'm just not sure it's a solution the developers are happy with.. |
| 13:39.38 | rolek | ctooley: could you shed any light on that? |
| 13:39.47 | ctooley | rolek, maybe |
| 13:40.19 | ctooley | I'm certainly not a maintainer or committer, but I've had plenty of my own patches thrown away. :) |
| 13:44.29 | rolek | ctooley: well, if you have any tips for me, that'd be useful.. |
| 13:44.35 | ctooley | In my experience using a broken method of solving a problem in multiple places just because it seems to work leads to a bigger headache in the long run. If the patch is working for you, I'd suggest keeping it as a patch set for yourself. Most likely the bug and providing a patch will either get someone to clean up your patch or more likely inspire them to fix the solution in a better way. |
| 13:45.27 | ctooley | I'm not sure how exactly to solve the problem the "right" way, but I do have a multi-thousand line patchset I apply to Asterisk for our builds because they're things that I've had to hack together and aren't fit for public consumption. |
| 13:45.55 | rolek | ctooley: that's my experience as well.. that's why I was asking for inspiration. |
| 13:46.32 | ctooley | If that fix is working for you, keep it. I'm pretty sure though that Olle will want to fix it a different way if he already knows that handle_response_invite() is broken. |
| 13:47.01 | rolek | ctooley: That would probably be best then, wouldn't it.. |
| 13:48.14 | rolek | ctooley: Well, thanks for your explanations.. |
| 13:48.50 | ctooley | Yeah, I just don't know enough about the reinvite status |
| 13:52.18 | jmls_work | takes a small liberty |
| 13:52.35 | jmls_work | could someone look at http://pastebin.com/m121718c8 and tell me just what the hell I am doing wrong |
| 13:52.55 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 13:56.26 | mvanbaak | jmls_work: you are working with asterisk, that's what you are doing wrong ;) |
| 13:56.29 | mvanbaak | hides |
| 13:56.38 | jmls_work | ha ha bloody ha. |
| 13:56.40 | jmls_work | ;) |
| 13:56.53 | jmls_work | this stupid thing is making me tear my hair out. |
| 13:57.19 | jmls_work | it will be such a noob problem |
| 13:58.04 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 13:58.04 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 13:58.05 | mvanbaak | ah |
| 13:58.19 | mvanbaak | dont you have to feed strftime some data ? |
| 13:58.27 | mvanbaak | I know I used EPOCH for that |
| 13:58.47 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 13:59.25 | mvanbaak | jmls_work: this is from my setup and it's working: |
| 13:59.28 | mvanbaak | Verbose(1,${STRFTIME(${EPOCH},,%d-%m-%Y %H:%M:%S)} Routing call from ${CALLERID(num)} (${CALLERID(name)}) to ${EXTEN} on channel ${CHANNEL}); |
| 13:59.53 | mvanbaak | gives me this: |
| 14:00.38 | mvanbaak | 13-05-2008 13:20:59 Routing call from 0XXXX (Terrazur) to 313XXXX on channel IAX2/vanbaak-4760 |
| 14:00.52 | mvanbaak | sorry, had to get rid of the phone numbers |
| 14:01.05 | jsmith | No worries |
| 14:01.25 | mvanbaak | as you can see, the date and time are there as I specified in the STRFTIME |
| 14:02.23 | mvanbaak | hey russellb |
| 14:02.51 | russellb | greetings |
| 14:04.02 | jmls_work | mvanbaak: it's the times that are the problem |
| 14:04.18 | jmls_work | if you look at the output, I have 14:43:34 and 14:43:50 |
| 14:04.35 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 14:04.35 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:04.39 | jmls_work | iow 16s between dialling and hangup, though I asked for 120s ... |
| 14:05.25 | file | if you don't put /n on the end of a Local channel it will go away once the channel gets to an answered state, perhaps that is what is happening |
| 14:05.57 | jmls_work | I do use /n |
| 14:06.18 | file | then perhaps the complete console output would yield the answer |
| 14:07.58 | Corydon76-dig | jmls_work: are you sure you want group 1 and not group 0, for instance? |
| 14:09.01 | Corydon76-dig | and do you perhaps have any channel bank users in that group? |
| 14:09.23 | Corydon76-dig | If you change to lowercase g, does it change the result? |
| 14:11.18 | jmls_work | Corydon76-dig: yup G1 is my 10 channel, G2+G3 is span 2 and 3, G4 is span 4 G5 is spans 2+3 |
| 14:11.28 | jmls_work | all SIP users |
| 14:12.14 | jmls_work | tries g1 .. |
| 14:12.55 | jmls_work | nope. this time it was 17s |
| 14:14.16 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 14:16.41 | Corydon76-dig | jmls_work: How is the Local channel getting created? |
| 14:16.50 | jmls_work | file: http://pastebin.com/m5828bc2d |
| 14:16.59 | jmls_work | Corydon76-dig: from AMI originate |
| 14:17.48 | Corydon76-dig | Ah... Did you specify a timeout for that channel in AMI? |
| 14:18.15 | Corydon76-dig | Because if the Local channel is hungup, it will cancel whatever is running in that Local channel |
| 14:19.18 | russellb | I propose 1.4.20-rc3, thoughts? |
| 14:27.17 | file | I have no qualms with doing such a thing |
| 14:28.04 | russellb | the response is overwhelming |
| 14:30.00 | jmls_work | Corydon76-dig: nope |
| 14:30.02 | *** join/#asterisk-dev km- (n=pgrace@aeneas.fierymoon.com) |
| 14:30.30 | km- | morning! |
| 14:30.42 | Corydon76-dig | jmls_work: I'm showing that Timeout is a mandatory parameter in AMI Originate |
| 14:30.51 | jmls_work | hmm. |
| 14:30.54 | Corydon76-dig | Mr0nin, km |
| 14:31.29 | jmls_work | ffs |
| 14:31.30 | km- | surfing dsp.c, I'm amused by the "if (sofarsogood)" |
| 14:31.57 | jmls_work | timeout is milliseconds, isn't it ? |
| 14:33.54 | jmls_work | is embarrassed. |
| 14:34.04 | jmls_work | found it. |
| 14:34.05 | jmls_work | sorry. |
| 14:34.50 | km- | Corydon76-dig: Are you particularly skilled in the dsp side of asterisk? FFT's always seem like black magic to me. |
| 14:35.06 | Corydon76-dig | No, I am not |
| 14:35.07 | km- | Corydon76-dig: you're an amateur radio operator, right? |
| 14:35.13 | Corydon76-dig | Yes |
| 14:35.23 | km- | I'm batting around an idea for app_rpt |
| 14:35.28 | Corydon76-dig | KI4KUA |
| 14:35.28 | km- | have you played with it? |
| 14:35.35 | Corydon76-dig | No, have not |
| 14:35.45 | Corydon76-dig | Mostly lack of fundage |
| 14:35.49 | km- | I have a 70cm repeater at home that's gathering dust that I'm going to fire up app_rpt on |
| 14:36.00 | Corydon76-dig | I have an HT and a mobile, but no home rig |
| 14:36.34 | Corydon76-dig | Honestly, I'd need a tower in my backyard, as I live in a gully |
| 14:37.09 | Corydon76-dig | and serious height... I'd need at least a 30' tower to get above the hill behind my house |
| 14:37.10 | km- | but this is what I was thinking. Local hams here use minitor pagers (like firemen) to activate races, remind people of the nets, do siren tests for the nuke plant, etc. Asterisk has some pretty good software dsp magic. I'm thinking of making a new channel module that will listen to remote base output and spawn <something> when it hears the two-tone page |
| 14:37.16 | km- | ah, sucks |
| 14:37.49 | Corydon76-dig | Sure, that could be done |
| 14:38.11 | km- | the <something> so far in my head would be dumping the audio into the meetme and using the spooler to dump people's cellphones into the meetme to listen to the remote base audio |
| 14:38.34 | km- | that way people who cant afford the pagers (and who dont rely on them for mission critical things) can still be informed as to what's going on |
| 14:39.05 | km- | My first step was to figure out whether dsp.c's routines were generic enough to do any FFT or if they're keyed specifically for dtmf, unfortunately they are. |
| 14:39.08 | mvanbaak | Corydon76-dig: put the tower on top of the hill |
| 14:39.14 | km- | so I could do DSQ |
| 14:39.16 | Corydon76-dig | mvanbaak: not my land |
| 14:39.17 | russellb | km-: what version are you looking at? |
| 14:39.18 | km- | but not dual-tone |
| 14:39.26 | km- | russellb: 1.4 something. |
| 14:39.32 | km- | russellb: has dsp been rewritten since? |
| 14:39.39 | russellb | km-: look at asterisk trunk, dsp.c is a lot cleaner there ... |
| 14:39.43 | km- | oh nice |
| 14:39.44 | russellb | and i believe the tone detection was made generic |
| 14:39.56 | km- | I wonder if app_rpt has been ported to trunk as well |
| 14:40.02 | russellb | yeah, it's in trunk |
| 14:40.14 | awk | does anyone have a solution for patch 10815-4.patch, I just get the following... http://www.pastebin.ca/1017989 |
| 14:40.15 | Corydon76-dig | I don't think the dsp routines are actually using FFT for tone detection |
| 14:40.21 | russellb | i can't even compile it, though ... it has never compiled for 64-bit (without warnings, and i treat warnings as errors) |
| 14:40.27 | km- | Corydon76-dig: it talks about geortzel transforms, which I think are FFT's |
| 14:40.28 | awk | Any idea when app_fax.c will be intergrated into asterisk-addons? |
| 14:40.38 | Corydon76-dig | I heard something to the effect that FFT is a massive drain on CPU resources |
| 14:40.39 | russellb | awk: it already is |
| 14:40.51 | km- | http://en.wikipedia.org/wiki/Goertzel_algorithm |
| 14:40.57 | *** join/#asterisk-dev joetester2 (n=joeteste@216.191.34.13) |
| 14:40.59 | km- | it's a fft-like dsp thing |
| 14:41.12 | km- | hmmm |
| 14:41.44 | km- | goertzel is quite different than fft, yeah. But it actually works in my favor I think |
| 14:41.47 | Corydon76-dig | Right, not an FFT, just a detector for specific tones |
| 14:41.55 | km- | if dsp.c is cleaner now, it might be even easier to implement this. |
| 14:42.29 | km- | This project is moving swiftly from napkin to proof-of-concept |
| 14:43.23 | russellb | maybe ... you'll have to look |
| 14:43.33 | awk | russellb so app_fax.so is part of addons 1.4.6? |
| 14:43.34 | russellb | I know the code was made more generic |
| 14:43.39 | russellb | addons 1.6.X |
| 14:43.54 | awk | ;/ thats the issue and the patch doesn't compile on 1.4.6 |
| 14:44.04 | russellb | ok |
| 14:52.45 | russellb | signage time |
| 15:05.11 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.135) |
| 15:15.51 | caio1982 | if i enter in this code from chan_sip (like 50 people dialing 50 different invalid extens): pbx_builtin_setvar_helper(c, "INVALID_EXTEN", c->exten);... does it mean i'll have just one global variable with its value changing in seconds or less or i'd be able to get this variable for each channel separately? |
| 15:16.16 | caio1982 | i know 'c' is the channel, but i dont get how only one global variable will work in such case |
| 15:17.02 | caio1982 | and by 'get this variable' i mean reading and manipulating it inside the dialplan of course :) |
| 15:19.02 | *** part/#asterisk-dev codefreeze-lap (n=murf@216.166.159.235) |
| 15:20.53 | *** join/#asterisk-dev codefreeze-lap (n=murf@216.166.159.235) |
| 15:20.58 | *** join/#asterisk-dev Cresl1n (n=matt@216.207.245.1) |
| 15:20.58 | *** mode/#asterisk-dev [+o Cresl1n] by ChanServ |
| 15:22.38 | *** join/#asterisk-dev jpeeler (n=jpeeler@216.207.245.1) |
| 15:24.28 | codefreeze-lap | jpeeler: still want to know what's going on with pbx.c? |
| 15:24.59 | codefreeze-lap | a NOTNOW vs. RIGHTNOW thing.... |
| 15:25.24 | jpeeler | codefreeze-lap: sure, although i just have a simple modification that i wanted to see would be alright |
| 15:25.33 | *** join/#asterisk-dev mog (n=mog@216.207.245.1) |
| 15:25.33 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 15:27.04 | codefreeze-lap | The NOTNOW stuff there is the OLD way-- a linear search for the priority. The new way is just above, a hashtab_lookup. I kept the NOTNOW stuff for reference, until the code is solid. Why do you need the mod? |
| 15:29.23 | jpeeler | i need pbx_find_extension to return null when a extension string of zero length is searched for, which is the 1.4 behavior |
| 15:29.29 | jpeeler | currently it does not return null |
| 15:30.04 | jpeeler | after the second NOTNOW block in that function, i simply check to see if it is zero length |
| 15:30.08 | jpeeler | if (e && !ast_strlen_zero(e->exten)) { /* found a valid match */ |
| 15:30.22 | jpeeler | and that has solved the problem, but i wanted to check and make sure that didn't break anything |
| 15:31.36 | codefreeze-lap | uh, I'm confused; the exten field in the struct is empty? |
| 15:32.34 | jpeeler | not sure what struct you are referring to, but yes the exten is empty |
| 15:33.17 | jpeeler | it happens in the case of pressing # and then just waiting for it to timeout |
| 15:41.02 | shido6 | does this make sense? |
| 15:41.03 | shido6 | http://pastebin.ca/1018075 |
| 15:41.37 | shido6 | Data source name not found yet it registers odbc class Voicemail |
| 15:42.38 | codefreeze-lap | jpeeler: I'm still puzzled. What kind of dialplan code would yield that? your test is for e->exten not being empty/NULL string. the e-> structs are pointing to the dialplan. Seems to me, that the exten field shouldn't be empty anywhere. |
| 15:44.01 | jpeeler | codefreeze-lap: well then perhaps there is a bug somewhere else then, but as i said above it occurs when during a call pressing the # key and not entering any digits |
| 15:44.17 | file | transfer? |
| 15:44.24 | jpeeler | yes |
| 15:44.55 | codefreeze-lap | jpeeler: well, then wouldn't the func's 'exten' arg be null instead |
| 15:46.05 | jpeeler | codefreeze-lap: appeared to be a zero length string, but i'll check again |
| 15:47.01 | jpeeler | well actually i have it sitting right here |
| 15:47.08 | jpeeler | <PROTECTED> |
| 15:48.10 | codefreeze-lap | jpeeler: so, wouldn't the test be !ast_strlen_zero(exten) instead? |
| 15:49.05 | jpeeler | oops, that was a very stupid mistake |
| 15:50.03 | codefreeze-lap | jpeeler: and... you could move it up to near the beginning of the func... no use doing a lot of work if we are just going to return... |
| 15:54.00 | jpeeler | codefreeze-lap: i guess that would be best |
| 15:54.09 | jpeeler | thanks for taking a look at it, all appears to be well now |
| 15:54.40 | codefreeze-lap | jpeeler: whew. you had me worried. *** life flashes before murf's eyes *** |
| 15:57.05 | jpeeler | codefreeze-lap: heh, nothing to worry about |
| 15:58.15 | file | pokes Corydon76-dig |
| 16:00.44 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 16:00.58 | *** part/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 16:02.56 | *** join/#asterisk-dev RoyK (n=roy@195.139.216.234) |
| 16:06.41 | Corydon76-dig | file: yes? |
| 16:07.09 | russellb | steals file's keyboard |
| 16:08.31 | file | I forgot what I wanted :\ |
| 16:08.59 | Qwell | pizza, no doubt |
| 16:09.14 | Corydon76-dig | Qwell: You is the Oracle |
| 16:09.48 | Corydon76-dig | Qwell: can you have a SELECT statement be part of a transaction? |
| 16:09.54 | Qwell | sure? |
| 16:10.09 | Corydon76-dig | I'm specifically thinking of things like SELECT next(id) FROM dual |
| 16:10.09 | kpfleming | umm... select can occur during a transaction, sure |
| 16:10.39 | Corydon76-dig | I'm wondering if that next(id) can get rolled back or not |
| 16:11.03 | kpfleming | no |
| 16:11.10 | kpfleming | sequences never roll back |
| 16:11.19 | Corydon76-dig | Specifically, I'm looking at tracking whether a transaction is active when a dbh is released, so I know whether I need to do an explicit rollback |
| 16:11.30 | russellb | requests a download of kpfleming's SQL foo |
| 16:11.49 | Corydon76-dig | since handles are recycled, it would be rather bad if a transaction commit did more than it was supposed to |
| 16:12.38 | Corydon76-dig | So a SELECT would not count for the purpose of determining whether or not a transaction was started, correct? |
| 16:14.25 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.12.183) |
| 16:17.24 | jpeeler | russellb: would you like to see/review what i changed of your code in features.c before i commit? |
| 16:17.48 | Corydon76-dig | ctooley: ping |
| 16:18.14 | ctooley | Corydon76-dig, pong |
| 16:18.26 | Corydon76-dig | I'm looking at your patch on 12618 |
| 16:18.34 | ctooley | M12618 |
| 16:18.35 | MuffinMan | [assigned] [Asterisk] Applications/app_externalivr 0012618: [patch] ExternalIVR will hang a channel attempting to read from a file descriptor that has somehow gone away reported by ctooley (Karma: neutral) http://bugs.digium.com/view.php?id=12618 |
| 16:18.40 | Corydon76-dig | Why do you open /dev/null in that patch? |
| 16:19.22 | Corydon76-dig | Oh, wait, nevermind |
| 16:19.22 | kpfleming | Corydon76-dig: that is correct |
| 16:19.24 | Corydon76-dig | I know why |
| 16:19.38 | kpfleming | i don't know that there is any SQL you can reliably issue to find out whether a transaction is in process or not |
| 16:19.45 | kpfleming | if there is, it would be very db-specific, not generic |
| 16:20.00 | ctooley | Corydon76-dig, yeah, just some file to open to get a file handle.... /dev/null seemed safe |
| 16:20.06 | ctooley | or at least safe enough. |
| 16:20.18 | Corydon76-dig | Right |
| 16:20.58 | putnopvut | I just tried applying that patch and I get a warning when compiling because 'test_available_fd' may be used uninitialized. |
| 16:21.22 | Corydon76-dig | Yeah, I'm fixing that, as well as a scoping issue |
| 16:21.23 | ctooley | Corydon76-dig, I do consider that a 1.4 bug BTW. It's not likely that anyone would ever run into it, but it's possible. |
| 16:22.05 | ctooley | putnopvut, on trunk or 1.4? |
| 16:22.29 | Corydon76-dig | The scoping issue is that you're declaring it at one level and checking it outside of that level |
| 16:22.33 | putnopvut | ctooley: trunk. |
| 16:22.45 | putnopvut | trunk doesn't have the scoping problem, I believe. |
| 16:23.06 | putnopvut | Yeah, only the 1.4 version has the scoping issue. |
| 16:23.16 | ctooley | Corydon76-dig, I "cleaned it up" before submitting the patch, I probably screwed it up in clean up process. |
| 16:23.52 | ctooley | The variable name I my copy is slightly more colorful. |
| 16:24.09 | ctooley | s/I my/in my/ |
| 16:25.51 | Corydon76-dig | ctooley: eivr_commands_fd is not a declared variable in 1.4 |
| 16:26.19 | Corydon76-dig | Did you mean to type ready_fd perhaps? |
| 16:26.29 | ctooley | Corydon76-dig, hehe, it is in mine. |
| 16:26.33 | ctooley | Corydon76-dig, probably |
| 16:26.44 | Corydon76-dig | ctooley: there are several other candidates |
| 16:26.58 | Corydon76-dig | child_commands_fd, child_events_fd |
| 16:27.05 | ctooley | gimme a sec |
| 16:27.30 | ctooley | I'll take a look at the one from the digium tree |
| 16:29.15 | ctooley | line 441 from the 1.4 branch says child_commands |
| 16:30.03 | ctooley | let me look at that patch, I must have submitted something horribly screwed up. |
| 16:30.48 | ctooley | child_commands_fd |
| 16:33.33 | ctooley | I see what I did... ugh, sorry guys. |
| 16:34.06 | russellb | you are forgiven! |
| 16:34.22 | ctooley | russellb has spoken! |
| 16:34.23 | ctooley | :) |
| 16:34.24 | *** part/#asterisk-dev jmls_work (n=jmls_wor@mail.tessera.co.uk) |
| 16:34.30 | russellb | runs in circles |
| 16:34.38 | Qwell | cowers in fear |
| 16:41.43 | ctooley | goes back to writing CDRs. :( |
| 16:45.34 | file | so before I commit this... if a field isn't in realtime when it does an update, will it still be fine? |
| 16:45.49 | Qwell | nope, don't think so |
| 16:45.58 | file | frowns |
| 16:46.13 | Qwell | I think that's why Tilghman created his branch for adaptiveness |
| 16:46.32 | file | well this is quite unhappy |
| 16:46.44 | file | pokes Corydon76-dig |
| 16:46.50 | russellb | file: same thing occurred to me |
| 16:46.54 | russellb | file: UPGRADE.txt it ... |
| 16:46.56 | Qwell | realtime odbc basically just does an UPDATE table SET field1=value1 field2=value2 |
| 16:47.02 | russellb | i think that it's a useful enough feature to merge |
| 16:47.02 | Qwell | erm, with a comma in there somewhere |
| 16:47.07 | russellb | right |
| 16:47.18 | Qwell | so, if field2 doesn't exist, the query will just bomb |
| 16:47.47 | russellb | hopefully that would result in an ERROR message |
| 16:47.53 | russellb | and people would be clued in to figure out what's wrong ... |
| 16:47.56 | Corydon76-dig | russellb: it does not, actually |
| 16:47.57 | russellb | if they didn't read upgrade info |
| 16:48.01 | russellb | sad. :( |
| 16:48.06 | file | :\ |
| 16:48.11 | file | Corydon76-dig: AST-38 |
| 16:48.14 | Corydon76-dig | And yes, this is the reason for my branch |
| 16:48.27 | Qwell | in the past (ODBC_STORAGE with context/exten), we had to support both |
| 16:48.36 | Qwell | I think it was a second #define...yuck |
| 16:52.39 | file | Corydon76-dig: how long do you expect? |
| 16:53.42 | Corydon76-dig | file: you realize that branch is trunk-only, right? |
| 16:53.53 | file | yes |
| 16:54.14 | Corydon76-dig | Well, the odbc part is done, but I need to implement for pgsql, at least |
| 16:54.19 | Corydon76-dig | Not sure about TDS, though |
| 16:54.28 | Corydon76-dig | and the mysql one in -addons |
| 16:54.30 | file | ah yes... it's at that level |
| 16:54.33 | file | bollocks! |
| 16:54.35 | Corydon76-dig | and then I need a lot of testing |
| 16:55.16 | Corydon76-dig | and the apps all implement the warnings, so... if you use odbc, it's at the level where testing could begin |
| 16:56.36 | *** join/#asterisk-dev jaytee (n=jforde@unaffiliated/jaytee) |
| 16:56.44 | Corydon76-dig | Oh, and one completely irrelevant implementation detail... it only checks the first 64 fields in an update |
| 16:57.01 | Qwell | why 64? |
| 16:57.03 | Corydon76-dig | I don't think we have even 10 in an update yet |
| 16:57.11 | Corydon76-dig | Qwell: sizeof(long long) |
| 16:57.18 | Qwell | ahh |
| 16:57.41 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 16:57.51 | Corydon76-dig | It's done because the query is done in two parts... a rendering of the SQL with ? placeholders, and in another place, too |
| 16:57.58 | *** join/#asterisk-dev moy (n=moyhu@nat/ibm/x-7819d7674b64d200) |
| 16:58.16 | Corydon76-dig | so I needed a way to keep track of which parameters should be ignored (because the fields aren't in the table) |
| 16:59.33 | *** join/#asterisk-dev RoyK (n=roy@ti211310a080-7765.bb.online.no) |
| 17:03.15 | *** join/#asterisk-dev jmls_work (n=jmls_wor@mail.tessera.co.uk) |
| 17:11.33 | *** part/#asterisk-dev jmls_work (n=jmls_wor@mail.tessera.co.uk) |
| 17:32.17 | *** join/#asterisk-dev jpeeler (n=jpeeler@216.207.245.1) |
| 17:43.33 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.80.140) |
| 17:43.50 | anonymouz666 | jpeeler |
| 17:44.03 | Qwell | tzafrir: ping? |
| 17:44.09 | anonymouz666 | I finish the patch, it seems dnsmgr is working with chan_sip (1.4) |
| 17:44.33 | tzafrir | Qwell, here |
| 17:44.48 | Qwell | tzafrir: I think r4006 wasn't quite complete. basechan is no longer being incremented |
| 17:44.53 | jpeeler | anonymouz666: so you decided to upgrade? |
| 17:44.55 | Qwell | M12635 |
| 17:44.56 | MuffinMan | [feedback] [Asterisk-GUI] Card Detection 0012635: Card detection not working when analog and digital both present reported by msales (Karma: neutral) http://bugs.digium.com/view.php?id=12635 |
| 17:45.04 | anonymouz666 | jpeeler yes |
| 17:45.15 | Qwell | if I set basechan to static, it works for me. not sure that's the correct fix though |
| 17:45.37 | jpeeler | anonymouz666: well then i'm glad it's working for you |
| 17:47.29 | bkruse | Qwell: <3 |
| 17:47.46 | Qwell | bkruse: heh, I was going to ping you, but didn't see you in the user list. you were gray :) |
| 17:48.11 | bkruse | Qwell: I have been in a VM :X |
| 17:48.30 | Qwell | bkruse: I was able to reproduce that pretty trivially here. I just so happen to have a te11xp and tdm400 in here |
| 17:48.42 | bkruse | Qwell: Nice, and you it does the same thing? |
| 17:48.46 | Qwell | yep |
| 17:48.55 | bkruse | Qwell: I have not kept up with ztscan after the initial commit, in which it used to work? (I tested on both) |
| 17:52.23 | tzafrir | Right. But anyway, it is not the right way to remember it |
| 17:52.43 | Qwell | right, I didn't think it would be correct |
| 17:52.49 | tzafrir | Conside what hapepned if you had two spans and now you unregister the first one |
| 17:53.03 | Qwell | ztscan would be run again. |
| 17:53.19 | tzafrir | but what should be basechan for the second span? |
| 17:53.30 | Qwell | 1? |
| 17:53.54 | tzafrir | (even without that bug I inflicted) |
| 17:54.43 | Qwell | if you have 2 spans, and unregister 1 of them, there would only be 1 span |
| 17:54.55 | Qwell | (if unregister means remove the module) |
| 17:56.01 | Qwell | if you ztscan 2, that's also broken. with or without making it static/global. hmm |
| 17:59.27 | tzafrir | Qwell, http://pastebin.ca/1018190 |
| 18:00.11 | tzafrir | But you can also cause that by modprobing a second module after Asterisk has started and then stoping Asterisk |
| 18:01.00 | Qwell | so...where does that channel number come from? if it's different than how ztscan does it, perhaps that is what should change |
| 18:02.18 | tzafrir | Actually, in the worst case you can't really assume that the first number and the number of channels are good enough |
| 18:06.51 | tzafrir | like in here: |
| 18:06.54 | tzafrir | http://pastebin.ca/1018196 |
| 18:09.23 | Qwell | well, how is procfs getting the channel numbers? |
| 18:10.55 | Qwell | if (chans[x]->span && (chans[x]->span->spanno == span)) { |
| 18:11.38 | Qwell | so it's iterating through every channel |
| 18:14.26 | tzafrir | Right. It look wrong locking-wise . Accessing a channel not through its span |
| 18:14.41 | tzafrir | Not to mention we start with the span |
| 18:18.49 | Qwell | without iterating the channels like that, is there a way to get the list of channels on a span? |
| 18:19.20 | Qwell | there doesn't appear to be, after a quick look |
| 18:19.45 | Corydon76-dig | M12650 |
| 18:19.51 | Corydon76-dig | Anybody care to comment? |
| 18:20.39 | MuffinMan | [new] [Asterisk] Core/BuildSystem 0012650: [patch] Warn when a string of "(null)" is passed to ast_strlen_zero reported by Corydon76 (Karma: +418.25) http://bugs.digium.com/view.php?id=12650 |
| 18:21.23 | putnopvut | When has that problem occurred? |
| 18:21.51 | putnopvut | And you need to close the parentheses inside the quotes, I'm guessing. |
| 18:22.34 | putnopvut | i.e. "(null)" instead of "(null" |
| 18:23.16 | Corydon76-dig | Ah |
| 18:24.39 | Corydon76-dig | It occurred in voicemail |
| 18:25.53 | putnopvut | Did you retrieve "(null)" from a DB? |
| 18:26.42 | Corydon76-dig | A103197 |
| 18:27.00 | Corydon76-dig | asterisk commit 103197 |
| 18:27.13 | file | commit asterisk 103197 |
| 18:27.21 | MuffinMan | [103197] Committed by tilghman on 2008-02-09T06:23:49.556021Z: Commit fix for being unable to send voicemail from VoiceMailMain |
| 18:27.21 | MuffinMan | .. Reported by: William F Acker (via the -users mailing list) |
| 18:27.21 | MuffinMan | .. Patch by: Corydon76 (license 14) |
| 18:27.55 | Corydon76-dig | http://svn.digium.com/view/asterisk/branches/1.4/apps/app_voicemail.c?r1=102576&r2=103197 |
| 18:28.55 | putnopvut | is "(null)" always what is set? No chance of it being "nil" or some other variation? |
| 18:29.09 | Corydon76-dig | In gcc, it's always "(null)" |
| 18:29.17 | Corydon76-dig | or glibc, maybe |
| 18:29.28 | Corydon76-dig | glibc is probably where it's set |
| 18:30.59 | jpeeler | any known issues with wct4xxp module, dmesg output is reporting unknown symbols |
| 18:39.14 | Qwell | tzafrir: would you be okay with reverting 4006 for now, until a proper fix can be made? |
| 18:39.26 | tzafrir | yeah |
| 18:40.08 | Qwell | I guess 4009 also |
| 18:44.10 | anonymouz666 | jpeeler: I broke the transmit_register somehow |
| 18:44.13 | anonymouz666 | :/ |
| 18:44.41 | anonymouz666 | DNS Manager: enabled Number of entries: 4 |
| 18:46.56 | tzafrir | it turned out to be useless anyway |
| 18:46.57 | jpeeler | anonymouz666: the modifications to that function were pretty small, notice the newly added parameter to create_addr |
| 18:53.02 | anonymouz666 | the sin pointer to the sockaddr_in struct |
| 18:56.03 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:05.57 | *** join/#asterisk-dev Mw3 (n=mw3@ip59934bd1.rubicom.hu) |
| 19:16.14 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.134) |
| 19:26.43 | jmls_home | heh. |
| 19:26.49 | jmls_home | anyone know what this means : |
| 19:26.51 | jmls_home | <PROTECTED> |
| 19:27.15 | jmls_home | the number is variable - I have 08, 03, 16, 23 .. |
| 19:28.06 | Qwell | jmls_home: 18 is pretty big.. |
| 19:28.12 | jsmith | jmls_home: Definitely sounds like a bug... that warning got added very recently |
| 19:28.28 | jsmith | can't remember who to blame though |
| 19:28.43 | Qwell | jmls_home: how are you calling it exactly? |
| 19:32.13 | jmls_home | Qwell: exten => _A.,n,SayNumber(${AGENTNUM}) |
| 19:32.33 | Qwell | and I suppose AGENTNUM is just 18/ |
| 19:32.47 | jmls_home | where ${AGENTNUM} is an integer from 01 to 50 |
| 19:33.05 | jmls_home | but I only have 25 agents active at the moment |
| 19:38.24 | jmls_home | Qwell: what if the channel gets a hangup just as it's about to say the number ? |
| 19:39.08 | Qwell | umm, that would probably do it |
| 19:39.30 | Qwell | or as it's playing it |
| 19:39.42 | jmls_home | is trying to break it right now |
| 19:40.25 | Qwell | though, I'm not sure why that warning was added. ast_say_number_full_en has: ast_log(LOG_DEBUG, "Number '%d' is too big for me\n", num); |
| 19:40.58 | *** join/#asterisk-dev RoyK (n=roy@35.84-48-13.nextgentel.com) |
| 19:43.17 | jsmith | Qwell: Because people were doing something like exten => 123,1,SayNumber(12345678901234567) |
| 19:43.45 | Qwell | that's already handled though |
| 19:44.52 | Qwell | it was stopping dialplan execution though. hmm |
| 19:45.41 | jsmith | I thought the goal was to throw the warning and *not* stop dialplan execution |
| 19:47.01 | RoyK | Qwell: minor detail - all the use has to do is dial back :P |
| 19:47.08 | RoyK | hides under his desk |
| 19:47.18 | Qwell | I think that function could just always return 0, and not have to check the result of ast_say_number |
| 19:47.45 | Qwell | no need for the added warning, I don't think. maybe change the DEBUG messages in ast_say_number_full_* to WARNING |
| 19:48.06 | RoyK | seems quite hard to change that... might take 5-10 minutes for an untrained developer |
| 19:48.50 | Corydon76-dig | Qwell: isn't the point that we report in the log in what app the error occurred, not in the core? |
| 19:49.43 | Qwell | Corydon76-dig: huh? |
| 19:50.00 | Qwell | oh |
| 19:50.03 | Corydon76-dig | If you return an error code from the core API and let the app report the error... |
| 19:50.18 | RoyK | Qwell: he's got a point - the core should return an error, but the function might want to ignore it |
| 19:50.20 | Qwell | dunno, maybe, but should it give a warning if the channel hung up? |
| 19:50.55 | Qwell | that's an "error" condition that could report that |
| 19:50.57 | RoyK | Qwell: imho the channel shouldn't be hung up - at least there should be an argument to allow it to go on after certain errors |
| 19:51.20 | RoyK | Qwell: why does it crash, anyway? number too large? |
| 19:51.21 | Corydon76-dig | Qwell: probably not... hangup is its own condition |
| 19:51.46 | RoyK | Corydon76-dig: app returns -1, dialplan logic hangs up |
| 19:51.48 | Qwell | Corydon76-dig: ast_waitstream |
| 19:52.48 | Corydon76-dig | Qwell: still your call |
| 19:52.52 | Qwell | well, hmm |
| 19:52.58 | jmls_sleeps | goddam, I *hate* BT |
| 19:53.09 | jmls_sleeps | no backlog :( |
| 19:53.14 | jmls_sleeps | what did I miss ? |
| 19:53.15 | Corydon76-dig | I'm just trying to provide a reasoning why some things are the way they are |
| 19:53.32 | Qwell | what does ast_waitstream return if the channel gets hungup while it's in there? |
| 19:53.58 | Corydon76-dig | -1, I think |
| 19:54.10 | Corydon76-dig | Last part of waitstream_core |
| 19:54.24 | Qwell | right, so... |
| 19:54.44 | Qwell | should ast_say_number_full_* also return -1 if the number is too large? |
| 19:55.14 | Corydon76-dig | Why not/ |
| 19:55.14 | Cresl1n | -ETOOBIG |
| 19:55.47 | Corydon76-dig | The way we distinguish in the app is ast_check_hangup() |
| 19:56.40 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:58.41 | Qwell | shrugs |
| 20:15.15 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 20:15.15 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 20:24.43 | caio1982 | what does "TBD" from iax2 magic stands for? |
| 20:24.53 | Qwell | to be determined |
| 20:25.01 | russellb | it means, I would like to initiate a call, but I don't know who I'm calling yet |
| 20:25.01 | Qwell | ie; we don't know what number we're dialing yet |
| 20:25.09 | russellb | please let me authenticate now, so I can send you digits one at a time ... |
| 20:25.16 | russellb | and you can match it against the server side dialplan |
| 20:25.18 | russellb | kthx |
| 20:25.31 | anonymouz666 | jpeeler: care to take a look on this http://pastebin.ca/1018333? is there a way to fix that or just totally lost? |
| 20:25.35 | caio1982 | thank you two :) |
| 20:25.56 | russellb | np |
| 20:26.06 | *** join/#asterisk-dev Deeewayne (n=Deeewayn@216.207.245.1) |
| 20:26.06 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 20:27.03 | russellb | M12650 |
| 20:27.05 | MuffinMan | [new] [Asterisk] Core/BuildSystem 0012650: [patch] Warn when a string of "(null)" is passed to ast_strlen_zero reported by Corydon76 (Karma: +418.25) http://bugs.digium.com/view.php?id=12650 |
| 20:27.23 | russellb | Corydon76-dig: what would you think of starting to make use of assert(), and to only enable assertions in dev mode? |
| 20:27.50 | putnopvut | I know that wasn't directed at me, but +1 from me. |
| 20:28.05 | russellb | it was inspired by Tilghman's patch on that issue |
| 20:28.09 | russellb | but yeah, the question is to everyone |
| 20:28.14 | russellb | or proposal, rather |
| 20:29.26 | putnopvut | I think we shouldn't use the assert macro defined in assert.h though |
| 20:29.42 | putnopvut | I think it would be better to define one that would print the value of whatever variable we were testing. |
| 20:29.54 | russellb | fair enough |
| 20:30.10 | russellb | Create our own ast_assert() wrapper. |
| 20:30.30 | jpeeler | anonymouz666: looks like you ported everything over, but since you missed that change i suggest you look elsewhere for changes as well |
| 20:30.43 | putnopvut | russellb: yes. |
| 20:31.31 | file | russellb: I like that idea |
| 20:32.31 | putnopvut | It could also print a backtrace. |
| 20:32.51 | putnopvut | er, I guess if it core dumped that would be good enough. |
| 20:32.54 | putnopvut | just call abort(). |
| 20:33.20 | russellb | right |
| 20:33.44 | russellb | because if we had ast_assert, it would be useful in quite a few places |
| 20:34.08 | russellb | next question, is that ok for 1.4? |
| 20:34.31 | russellb | I can't see anyone having a problem with that. |
| 20:34.41 | russellb | if it helps make Asterisk better ... |
| 20:36.34 | anonymouz666 | jpeeler: I checked every place for create_addr() the third parameter looks like correct to me. |
| 20:36.49 | jpeeler | anonymouz666: i mean more dnsmgr changes... like in build_peer |
| 20:36.59 | putnopvut | russellb: yeah, if it's only a dev-mode thing I guess it could go in 1.4... |
| 20:37.07 | russellb | right |
| 20:43.08 | anonymouz666 | jpeeler: I changed the build_peer function too, unless I miss something in that function |
| 20:49.13 | Corydon76-dig | russellb: as long as ast_assert doesn't call assert(3) or abort(3), I'm okay with it |
| 20:49.32 | putnopvut | Why don't you want it calling abort? |
| 20:50.05 | russellb | I would treat ast_assert() as a fatal error that needs to be debugged ... |
| 20:50.09 | jpeeler | anonymouz666: something with the address is messed up, <sip:3030@...>, there's no IP address there |
| 20:50.13 | Corydon76-dig | putnopvut: I don't like server daemons going kablooie |
| 20:50.22 | russellb | dev mode, though :) |
| 20:50.32 | Corydon76-dig | I run dev mode everywhere |
| 20:50.42 | russellb | well then you wouldn't anymore :) |
| 20:50.48 | putnopvut | Corydon76-dig: isn't that the point of the assertion, though? |
| 20:51.00 | anonymouz666 | jpeeler: that makes me look at create_addr again |
| 20:51.02 | russellb | new menuselect option, CRASH_ON_ASSERT, available only in dev mode? |
| 20:51.03 | russellb | how's that |
| 20:51.06 | Corydon76-dig | putnopvut: point of the assertion is to be loud about a problem |
| 20:51.14 | putnopvut | Crashing is pretty loud. |
| 20:51.14 | Qwell | russellb: nobody would ever turn it on |
| 20:51.25 | Qwell | besides, wouldn't it be the same as DO_CRUSH? |
| 20:51.26 | russellb | you would if you were trying to figure out how an assertion happens. |
| 20:51.43 | Qwell | (yes, I intentionally misspelled that :p) |
| 20:51.45 | russellb | sort of, but that gets used in a lot of places where it shouldn't be |
| 20:51.54 | Corydon76-dig | What if --enable-dev-mode were additive, like verbose? |
| 20:51.59 | Corydon76-dig | or bitwise? |
| 20:52.24 | russellb | perhaps ... |
| 20:52.24 | Qwell | russellb: so, why not remove the bad DO_CRASH places? |
| 20:52.28 | Corydon76-dig | --enable-dev-mode=511 |
| 20:53.09 | Corydon76-dig | I think DO_CRASH provides us with the opportunity to do the abort(3) |
| 20:53.34 | russellb | k, let me work on this patch for a sec |
| 20:56.20 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 21:00.46 | *** join/#asterisk-dev mvanbaak_ (n=michiel@vanbaak.xs4all.nl) |
| 21:02.00 | anonymouz666 | jpeeler: maybe I am missing (as compiler says) casts so a dereference is needed to get the data, in this case the IP number |
| 21:04.43 | *** join/#asterisk-dev jmls_net (n=asterisk@host217-36-208-155.in-addr.btopenworld.com) |
| 21:04.56 | jmls_net | holy cow, I'm back |
| 21:05.11 | russellb | Corydon76-dig: ping |
| 21:05.13 | russellb | M12650 |
| 21:05.15 | MuffinMan | [new] [Asterisk] Core/BuildSystem 0012650: [patch] Warn when a string of "(null)" is passed to ast_strlen_zero reported by Corydon76 (Karma: +418.25) http://bugs.digium.com/view.php?id=12650 |
| 21:05.23 | russellb | and others .... ast_assert() patch uploaded for consideration |
| 21:05.59 | Qwell | yay |
| 21:06.27 | russellb | 1) only enabled in dev mode |
| 21:06.32 | russellb | 2) only crashes with DO_CRASH |
| 21:06.40 | russellb | without DO_CRASH, it just issues a LOG_ERROR message |
| 21:06.49 | putnopvut | Any reason why you use __builtin_expect() instead of likely()? Is likely() a linux-specific thing? |
| 21:06.57 | russellb | likely is a linux kernel thing |
| 21:07.07 | Qwell | err, only with DO_CRASH? |
| 21:07.24 | russellb | Qwell: at your suggestion, wasn't it? |
| 21:07.42 | russellb | and I removed it from sched.c, which is where it was crashing quite often before |
| 21:07.45 | Qwell | I must be misread this, but I don't see it checking that anywhere |
| 21:07.47 | russellb | so that people could turn it on |
| 21:07.55 | Qwell | misreading* |
| 21:07.59 | russellb | oh, i screwed it up |
| 21:08.01 | russellb | one sec |
| 21:09.14 | russellb | plz to be waiting for rev2 |
| 21:09.57 | putnopvut | russellb: I have a suggestion for consideration. |
| 21:10.34 | putnopvut | er, nevermind, what I was suggesting just complicates things unnecessarily. |
| 21:10.42 | putnopvut | s/suggesting/going to suggest/ |
| 21:11.04 | russellb | ok, rev2 up |
| 21:11.26 | Qwell | that makes more sense |
| 21:11.42 | putnopvut | I think the usleep should be outside the #ifdef DO_CRASH |
| 21:12.01 | Qwell | it's there so that if the abort is called, the message is shown |
| 21:12.02 | Qwell | buffer stuffage |
| 21:12.12 | *** join/#asterisk-dev mort___ (n=mort@user-5446487b.lns3-c12.dsl.pol.co.uk) |
| 21:12.15 | Qwell | if there's no abort, the message will show just fine |
| 21:12.43 | putnopvut | I get that, but I guess I was thinking that exiting the function could cause the same problems. |
| 21:12.44 | Qwell | I think :D |
| 21:12.59 | Qwell | oh, like a crash immediately after the assert, for whatever reason? |
| 21:13.10 | Qwell | that could be fairly likely |
| 21:13.11 | russellb | I suppose that's fair ... |
| 21:14.45 | Qwell | russellb: yeah, I like that - no more CRUSH bugs either...hopefully? |
| 21:15.17 | Qwell | oh, and should it be an ast_log? |
| 21:15.41 | russellb | ok, rev3 uploaded |
| 21:15.43 | Qwell | it's highly possible that logger hasn't been initialized yet, or logger itself caused the assert |
| 21:15.45 | russellb | what else should it be? |
| 21:15.53 | Qwell | which is why CRUSH used a printf, I assume |
| 21:15.55 | russellb | shrugs, it's possible ... |
| 21:16.01 | Qwell | fprintf, rather |
| 21:16.14 | russellb | ok, i'll fprintf it, as well, just to be extra safe, or something |
| 21:17.16 | Qwell | +1 |
| 21:17.43 | russellb | rev4 uploaded .... |
| 21:18.26 | jpeeler | what an interesting previous crash method |
| 21:18.48 | russellb | heh |
| 21:23.58 | Qwell | russellb: you should do that old method after the abort - just in case the abort returns. |
| 21:24.05 | Qwell | (it never returns) |
| 21:24.13 | Qwell | ((but that code is pretty cool)) |
| 21:26.46 | russellb | (((but it never returns, so you weren't serious, right?))) |
| 21:27.17 | Qwell | I actually was serious, but that code is really cool, and should be kept around in some form :p |
| 21:27.43 | russellb | oh, the *((int*)0)=0; ? |
| 21:27.47 | Qwell | yeah |
| 21:29.53 | russellb | oh, and i'm also including "FRACK!" |
| 21:37.02 | jpeeler | russellb: you need to catch up, that is all |
| 21:37.11 | russellb | jpeeler: i'm trying |
| 21:37.17 | russellb | i'm up to disc 6 of 6 on season 3 ... |
| 21:37.41 | Qwell | season 3 is 6 discs? |
| 21:37.45 | jpeeler | woot |
| 21:37.53 | russellb | Qwell: yes |
| 21:38.06 | Qwell | what show are we talking about? O.o |
| 21:38.09 | russellb | lol |
| 21:38.14 | russellb | Battlestar Gallactica |
| 21:48.03 | anonymouz666 | what I am doing wrong to produce this warning: chan_sip.c:16909: warning: implicit declaration of function `unref_peer' |
| 21:48.46 | bbryant | you're using a function that hasn't been declared yet |
| 21:51.26 | anonymouz666 | that's because I probably need to use another function |
| 21:52.21 | anonymouz666 | like ASTOBJ_UNREF(peer, sip_destroy_peer); |
| 22:03.54 | anonymouz666 | jpeeler fixed the IP |
| 22:03.58 | anonymouz666 | but |
| 22:05.31 | anonymouz666 | Registration from '<sip:3030@201.25.182.23>' failed for '127.0.0.1' |
| 22:05.34 | anonymouz666 | 127.0.0.1? |
| 22:05.39 | anonymouz666 | this is wrong |
| 22:07.15 | jpeeler | so fix it :) |
| 22:08.30 | anonymouz666 | trying :) |
| 22:09.52 | anonymouz666 | == Refreshing DNS lookups. |
| 22:09.55 | anonymouz666 | CLI output :D |
| 22:09.58 | anonymouz666 | this is nice |
| 22:20.28 | snuff-home | mm 1.6 changelog looks better without all the blocked revisions ;) |
| 22:21.26 | russellb | heh, someone noticed |
| 22:21.47 | russellb | :) |
| 22:21.56 | russellb | that was a PITA ... |
| 22:22.10 | russellb | though i'm sure if i wanted to, i could modify the script that generates the ChangeLog to filter it for me in the future |
| 22:23.01 | snuff-home | mm sounds reasonable |
| 22:36.01 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 23:27.13 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 23:29.43 | puzzled | hi |
| 23:30.01 | *** join/#asterisk-dev RoyK (n=roy@ip-15-27-149-91.dialup.ice.no) |
| 23:52.38 | *** part/#asterisk-dev Deeewayne (n=Deeewayn@216.207.245.1) |
| 23:57.50 | *** join/#asterisk-dev CrashHD (n=CrashHD@65.74.161.225) |