| 00:15.36 | *** part/#asterisk-dev corramor (n=corramor@216.207.245.1) |
| 00:19.23 | *** join/#asterisk-dev corramor (n=corramor@216.207.245.1) |
| 00:21.26 | *** join/#asterisk-dev kpfleming (n=kpflemin@216.207.245.1) |
| 00:21.26 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 00:30.25 | Qwell | kpfleming: wow, that ended up being quite silly indeed |
| 00:37.45 | lmadsen | Qwell: hi! |
| 00:40.43 | jsmith | Qwell: Just how silly was it? |
| 00:40.50 | Qwell | quite silly |
| 00:41.03 | lmadsen | that's what she said |
| 01:11.50 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip68-103-153-140.ks.ok.cox.net) |
| 01:21.37 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-9-100.dsl.telesp.net.br) |
| 01:59.15 | *** join/#asterisk-dev monkeytype (n=Bill@216.207.245.1) |
| 02:01.53 | *** join/#asterisk-dev AdamWest (n=Leif@CPE001d7e2f9574-CM0012c9db3d2e.cpe.net.cable.rogers.com) |
| 02:17.51 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip68-103-153-140.ks.ok.cox.net) |
| 02:27.20 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 02:27.26 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.32.126) |
| 02:29.16 | IgorG | hi all |
| 02:33.37 | snuff-work | hello IgorG |
| 02:41.07 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip68-103-153-140.ks.ok.cox.net) |
| 02:51.37 | *** join/#asterisk-dev putnopvut (n=putnopvu@user-24-214-112-81.knology.net) |
| 02:51.37 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 02:54.43 | *** join/#asterisk-dev sruffell (n=sruffell@216.207.245.1) |
| 02:54.43 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 02:58.14 | *** part/#asterisk-dev RoyK (n=roy@91.149.9.91) |
| 04:12.16 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 04:29.28 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 04:45.38 | IgorG | beeeep... qwell, next time if delete some module check depends in menuselect... |
| 04:45.50 | IgorG | where my shotgun? |
| 04:46.14 | IgorG | :) |
| 04:46.39 | Qwell | d'oh |
| 04:46.48 | Qwell | what happens? |
| 04:46.52 | Qwell | it totally worked on my box |
| 04:47.40 | IgorG | you delete res_features |
| 04:47.53 | IgorG | but not deleted depends in menuselect |
| 04:48.14 | IgorG | chan_sip, chan_iax2 now not compiled... |
| 04:49.43 | Corydon76-dig | IgorG: are you ever going to add a patch to 11291? |
| 04:50.15 | IgorG | yes, yes... But it is hard for me to make it properly... |
| 04:50.28 | IgorG | May be you can help? |
| 04:50.39 | Corydon76-dig | Well, make it improperly, and maybe we can clean it up for you |
| 04:51.06 | IgorG | Ok, then I post it it few hors, just check that all works for me |
| 04:57.23 | *** join/#asterisk-dev CunningPike (n=CunningP@S010600095b33697f.vc.shawcable.net) |
| 05:39.27 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 05:39.27 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 05:44.59 | IgorG | Corydon76-dig: done |
| 06:11.01 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-159.bredband.comhem.se) |
| 06:15.56 | citats | i think theres something funny going on with res_features. just tried a fresh checkout and a lot of stuff that depends on res_features didnt get compiled |
| 06:17.38 | Qwell | yeah, gonna have to fix that tomorrow |
| 06:17.39 | citats | oh looks like res_features was removed in favor of main/features |
| 06:17.50 | citats | cool |
| 06:18.28 | Qwell | not sure why it worked for me |
| 06:19.14 | JunK-Y | ldap in trunk, great! |
| 06:19.56 | JunK-Y | qwell: im working on reinvite with mgcp, do you know where that part is clearly define for native and partial in the rfc? |
| 06:19.58 | citats | didnt it get changed so the dependancy checking stuff doesnt happen all the time? maybe thats why it didnt hit you |
| 06:20.10 | Qwell | citats: probably |
| 06:25.10 | JunK-Y | i just svn co 100095, compile like a charm here |
| 06:26.56 | IgorG | chan_sip.so also compiled? |
| 06:27.14 | citats | JunK-Y: did anything that depends on res_features compile? |
| 06:27.20 | citats | chan_iax, chan_sip, prolly others |
| 06:28.36 | russellb | Qwell: yeah, there are more things that need to be fixed ... just do a grep -r res_features and you'll see |
| 06:29.36 | russellb | citats: to make the other stuff build, you have to remove the <depend>res_features</depend> tags from the MODULEINFO comment blocks in each module that depended on it |
| 06:31.02 | citats | russellb: yeah i figured that out. i just needed to test copy_request in chan_sip so i only did that module |
| 06:31.15 | russellb | oh, ok, cool |
| 06:32.10 | JunK-Y | citats: ya, just remove the depend |
| 06:32.14 | russellb | citats: sounds like you might be working on SIP message length :) |
| 06:32.15 | JunK-Y | dah |
| 06:32.21 | citats | russellb: yep :) |
| 06:32.24 | russellb | awesome |
| 06:32.55 | russellb | citats: thanks for all of your help ... it is much appreciated |
| 06:33.15 | JunK-Y | is that the stuff for mikey? |
| 06:33.44 | russellb | nope |
| 06:34.13 | russellb | i was talking about updating chan_sip so it is not limited to 4096 byte SIP messages |
| 06:34.40 | JunK-Y | okay, isnt the same bug that the guy was using mikey ? |
| 06:35.00 | russellb | oh, you might be right |
| 06:35.04 | russellb | if the key was huge or something |
| 06:35.06 | citats | russellb: no problem, its nice to be working on interesting things again rather than working on bs work for a clueless customer |
| 06:35.19 | JunK-Y | http://bugs.digium.com/view.php?id=8556 ? |
| 06:35.23 | russellb | citats: heh, yes, sounds like a good thing. |
| 06:35.25 | russellb | M8556 |
| 06:35.26 | MuffinMan | [new] [Asterisk] Channels/chan_sip/Interoperability 0008556: Large SIP messages are truncated to 4096 bytes reported by mikma http://bugs.digium.com/view.php?id=8556 |
| 06:35.33 | russellb | JunK-Y: yep, that one |
| 06:35.37 | JunK-Y | sounds like that :) |
| 06:36.03 | russellb | and then after that, SRTP is probably next on my chan_sip wish-list |
| 06:36.31 | JunK-Y | for 1.6beta2? |
| 06:36.56 | russellb | doubt that soon |
| 06:37.24 | JunK-Y | if its for the final 1.6.0, sounds really great. |
| 06:37.42 | Corydon76-dig | For all the screaming about having release candidate, there sure is a dearth of reports about beta1 |
| 06:37.44 | russellb | JunK-Y: keep in mind that even if some feature isn't in 1.6.0, we may merge it in for a future 1.6 release |
| 06:37.59 | russellb | Corydon76-dig: heh ... yep |
| 06:38.07 | russellb | everyone wants release candidates ... but wants someone else to test them |
| 06:38.15 | russellb | we do have 1 bug report against 1.6-beta1 |
| 06:38.21 | JunK-Y | russellb: so that will not be a "real stable" like 1.2 or 1.4, correct? |
| 06:38.32 | russellb | JunK-Y: it will be different. |
| 06:38.44 | JunK-Y | russellb: i will have one other to report for app_queue |
| 06:39.03 | JunK-Y | i can easily get segfault for current trunk |
| 06:39.10 | russellb | ah, well that's no good. |
| 06:39.47 | JunK-Y | let me see if i can fix it in 10 minutes |
| 06:42.12 | russellb | sleepy time for me. |
| 06:42.14 | russellb | g'night ... |
| 06:49.23 | JunK-Y | APPLICATION ERROR #1303 |
| 06:49.24 | JunK-Y | Invalid value for field |
| 06:49.25 | JunK-Y | wtf! |
| 06:50.35 | JunK-Y | i cant report bug, im always getting that error. |
| 06:51.38 | JunK-Y | take a look at: http://junky.homelinux.com/state.diff |
| 06:51.53 | JunK-Y | (gdb) bt |
| 06:51.53 | JunK-Y | #0 add_to_interfaces (interface=0x0) at /usr/src/asterisk-trunk/include/asterisk/strings.h:180 |
| 06:51.56 | JunK-Y | #1 0xb6e14a30 in add_to_queue (queuename=<value optimized out>, interface=0xb6e5e92c "SIP/10", membername=0xb6e5e937 "SIP/10", penalty=0, paused=0, dump=0, state_interface=0x0) at app_queue.c:3711 |
| 06:52.00 | JunK-Y | #2 0xb6e16083 in load_module () at app_queue.c:3974 |
| 06:52.03 | JunK-Y | and im off to bed too. |
| 06:57.43 | *** join/#asterisk-dev steliosk (n=Stelios@85.72.75.139) |
| 07:02.45 | *** join/#asterisk-dev oej (n=olle@cust-IP-10.data.tre.se) |
| 07:02.45 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:03.27 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 07:21.27 | oej | morning |
| 07:22.13 | mvanbaak | hello |
| 07:33.20 | IgorG | good day |
| 07:36.52 | *** join/#asterisk-dev oej_ (n=olle@80.251.192.3) |
| 07:45.09 | *** join/#asterisk-dev magumbade (n=magumbad@p5798BC34.dip.t-dialin.net) |
| 07:54.57 | *** join/#asterisk-dev nicox (n=nicox@83-64-42-210.prater.xdsl-line.inode.at) |
| 07:55.02 | nicox | good morning |
| 08:08.13 | *** join/#asterisk-dev sergee (n=serg@195.94.224.197) |
| 08:19.23 | snuff-work | mm.. has res_config_ldap been added to configure/menuselect checking |
| 08:19.38 | snuff-work | aka if ldap library != exist ;) |
| 08:24.30 | *** join/#asterisk-dev steliosk (n=Stelios@athedsl-277626.home.otenet.gr) |
| 08:26.20 | snuff-work | mm think its just my issue.. |
| 08:51.35 | tzafrir | hmmm... I wonder if LatencyTOP would be a useful tool for Asterisk: |
| 08:51.38 | tzafrir | http://www.latencytop.org/ |
| 09:06.19 | *** join/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 09:09.49 | snuff-work | mm might work for test load systems but i dont think many ppl would add a patch to their kernel in prod |
| 09:11.23 | agx | Hi, is there a way to monitor a non SIP phone extension? i mean i wanna monitor: exten=>98,1,Milliwat ... i tried to monitor it using exten=>98,hint,Local/98 .... but didn't worked out; is there a way to do this? |
| 09:11.33 | *** join/#asterisk-dev _ys (n=yuri@80.70.236.69) |
| 09:30.52 | snuff-work | uhmm anyone have issue reporting a bug |
| 09:31.04 | snuff-work | APPLICATION ERROR #1303 |
| 09:31.18 | snuff-work | says inv value for field and doesn't tell u which |
| 09:31.39 | snuff-work | ah HA |
| 09:32.16 | snuff-work | note to anyone tryin to log a fault with an svn version number.. > 99999 = error 1303 |
| 09:32.17 | *** join/#asterisk-dev steliosk (n=Stelios@athedsl-25685.home.otenet.gr) |
| 09:33.07 | _ys | snuff-work time to upgreade svn client ? :) |
| 09:34.47 | *** join/#asterisk-dev tzafrir_home (n=tzafrir@bzq-179-75-202.static.bezeqint.net) [NETSPLIT VICTIM] |
| 09:34.47 | *** join/#asterisk-dev hmmhesays (n=Neg@24-119-176-74.cpe.cableone.net) |
| 09:34.47 | *** join/#asterisk-dev ctooley (n=ctooley@doc-72-47-33-80.maryville.mo.cebridge.net) |
| 09:34.47 | *** join/#asterisk-dev atisss (n=atisss@193.238.212.171) [NETSPLIT VICTIM] |
| 09:34.47 | *** join/#asterisk-dev egypcio (n=vinicius@unaffiliated/egypcio) [NETSPLIT VICTIM] |
| 09:34.47 | *** join/#asterisk-dev mbranca (i=daemon@mi-gw1.voismart.net) |
| 09:34.47 | *** join/#asterisk-dev lvl- (n=lvl@101.248.dhcp.lht.hhs.nl) [NETSPLIT VICTIM] |
| 09:34.47 | *** join/#asterisk-dev codefreeze (n=steve_mu@216.166.159.235) |
| 09:34.47 | *** join/#asterisk-dev srt (n=ceiyah6U@eins-ext.reucon.net) [NETSPLIT VICTIM] |
| 09:34.47 | *** join/#asterisk-dev brookshire (n=mbrooks@hijacked.us) [NETSPLIT VICTIM] |
| 09:34.47 | *** join/#asterisk-dev festr_ (n=festr@ns.regnet.cz) [NETSPLIT VICTIM] |
| 09:34.48 | *** join/#asterisk-dev MuffinMan (n=muffins@neutrino.joshua-colp.com) |
| 09:34.48 | *** mode/#asterisk-dev [+oo tzafrir_home codefreeze] by irc.freenode.net |
| 09:35.18 | snuff-work | _ys: no mantis problem :) |
| 09:44.00 | *** join/#asterisk-dev _ys (n=yuri@80.70.236.69) |
| 09:50.12 | IgorG | snuff-work: http://bugs.digium.com/view.php?id=11828 |
| 09:50.48 | IgorG | sorry |
| 09:50.59 | IgorG | :) 100000 is not 10000 |
| 09:52.14 | snuff-work | ack |
| 09:52.33 | snuff-work | IgorG: ..but look at bug 11829 |
| 09:52.46 | snuff-work | reason why it is 10000 |
| 09:52.48 | snuff-work | :) |
| 09:53.26 | IgorG | get it |
| 09:54.09 | snuff-work | mm wtf.. my solaris has the resource modules missing in menuselect.. time to re-gen it again |
| 09:56.16 | snuff-work | i think my 'awk' idea was flawed :( |
| 10:01.50 | IgorG | res_features gone, revove depend on that in menuselect-tree... |
| 10:02.10 | agx | anyone has a clue why asterisk 1.4.latest rejects "SNOM M3" Voicemail subscriptions? http://www.pastebin.ca/870717 |
| 10:05.48 | snuff-work | mm m3 is the new dect/wifi one? |
| 10:21.47 | *** join/#asterisk-dev jmls (n=jmls@81.138.42.77) |
| 10:24.30 | agx | snuff-work: no its a Dect / VoIP ... it works very nice if compared to the Siemens C450 IP but i was unable to make it have voicemail notification work (provisioning works nice too) |
| 10:24.57 | agx | snuff-work: asterisk keep answering unautorhized like in the above pastebin |
| 10:25.46 | agx | snuff-work: ... and honestly... comparing how it works it looks the exact same firmware as the new incoming Polycom :-P :-P :-P |
| 10:28.14 | *** join/#asterisk-dev steliosk (n=Stelios@athedsl-313828.home.otenet.gr) |
| 10:29.30 | snuff-work | ah.. i've been wanting to get my hands on a M3 for work testing.. |
| 10:31.29 | snuff-work | mm unsure about your problem.. since it does submit subscribe with auth.. |
| 10:40.35 | *** join/#asterisk-dev andrelg (n=andrelg@server01.outcenter.com.br) |
| 10:43.54 | *** join/#asterisk-dev kpfleming (n=kpflemin@216.207.245.1) [NETSPLIT VICTIM] |
| 10:43.54 | *** join/#asterisk-dev nicox (n=nicox@83-64-42-210.prater.xdsl-line.inode.at) [NETSPLIT VICTIM] |
| 10:43.54 | *** join/#asterisk-dev monkeytype (n=Bill@216.207.245.1) |
| 10:43.54 | *** join/#asterisk-dev ZX81 (n=ZX81@202.49.106.158) [NETSPLIT VICTIM] |
| 10:43.55 | *** join/#asterisk-dev jsmith (n=jsmith@72.21.36.138) |
| 10:43.55 | *** join/#asterisk-dev bkruse (n=bkruse@216.207.245.1) [NETSPLIT VICTIM] |
| 10:43.55 | *** join/#asterisk-dev d3wayne (n=deeewayn@76.29.245.9) [NETSPLIT VICTIM] |
| 10:43.55 | *** mode/#asterisk-dev [+oooo kpfleming jsmith bkruse d3wayne] by irc.freenode.net |
| 10:43.55 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) [NETSPLIT VICTIM] |
| 10:43.55 | *** join/#asterisk-dev JerJer (n=PhatJ@pdpc/supporter/bronze/jerjer) [NETSPLIT VICTIM] |
| 10:43.55 | *** join/#asterisk-dev Damin (n=damin@nucleus.nacs.net) [NETSPLIT VICTIM] |
| 10:43.55 | *** join/#asterisk-dev davevg-btwtech (n=davevg-b@nj-67-76-177-147.sta.embarqhsd.net) [NETSPLIT VICTIM] |
| 10:43.55 | *** mode/#asterisk-dev [+o JerJer] by irc.freenode.net |
| 10:44.15 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-159.bredband.comhem.se) [NETSPLIT VICTIM] |
| 10:44.15 | *** join/#asterisk-dev wedhorn (n=wedhorn@dsl-58-6-89-11.act.westnet.com.au) [NETSPLIT VICTIM] |
| 10:44.15 | *** join/#asterisk-dev tzanger (n=tzanger@gromit.mixdown.ca) [NETSPLIT VICTIM] |
| 10:44.15 | *** join/#asterisk-dev JT (n=j@unaffiliated/jt) |
| 10:48.36 | *** join/#asterisk-dev pnlarsson-work (n=pnlarsso@h3n1fls34o831.telia.com) |
| 10:51.57 | *** join/#asterisk-dev JerJer (n=PhatJ@pdpc/supporter/bronze/jerjer) |
| 10:51.57 | *** mode/#asterisk-dev [+o JerJer] by ChanServ |
| 10:55.39 | mvanbaak | snuff-work: you should run svn update |
| 10:55.52 | mvanbaak | rev 10095 is really old ;) |
| 10:58.23 | mvanbaak | oh wait |
| 10:58.27 | mvanbaak | that's the mantis bug |
| 10:58.30 | mvanbaak | nm |
| 10:59.17 | *** join/#asterisk-dev d3wayne (n=deeewayn@76.29.245.9) |
| 10:59.17 | *** mode/#asterisk-dev [+o d3wayne] by ChanServ |
| 11:03.02 | *** join/#asterisk-dev _ys (i=yuri@91.151.196.254) |
| 11:04.27 | *** join/#asterisk-dev steliosk (n=Stelios@athedsl-144806.home.otenet.gr) |
| 11:06.44 | *** join/#asterisk-dev HeXeD (n=hex@87-194-8-43.bethere.co.uk) |
| 11:07.19 | *** join/#asterisk-dev myiagy (n=Jose@200.215.59.133) |
| 11:57.18 | *** join/#asterisk-dev nebojsajsimic (n=nebojsaj@cable-89-216-16-106.static.sbb.co.yu) |
| 11:59.18 | *** part/#asterisk-dev nebojsajsimic (n=nebojsaj@cable-89-216-16-106.static.sbb.co.yu) |
| 12:03.52 | *** join/#asterisk-dev nebojsajsimic (n=nebojsaj@cable-89-216-16-106.static.sbb.co.yu) |
| 12:12.35 | *** part/#asterisk-dev nebojsajsimic (n=nebojsaj@cable-89-216-16-106.static.sbb.co.yu) |
| 12:27.14 | *** join/#asterisk-dev eliel (n=chatzill@200.59.172.38) |
| 12:34.27 | *** join/#asterisk-dev eferro (n=eferro@212.230.49.164) |
| 12:38.13 | eferro | I have a core when using a Macro and other process execute a reload.... |
| 12:38.31 | eferro | I am not sure if it is a conf problem or a bug |
| 12:38.46 | eferro | But i can reproduce in our labs |
| 12:39.46 | eferro | Whe a reload is in progress is the any var, funcion o similar that i shuldn't use in a dialplan macro?? |
| 12:41.37 | eferro | the cores are like this: |
| 12:41.39 | eferro | #0 0xb7d2f159 in strcasecmp () from /lib/tls/i686/cmov/libc.so.6 |
| 12:41.39 | eferro | #1 0xb720b278 in _macro_exec (chan=0x8484468, data=<value optimized out>, exclusive=0) at app_macro.c:322 |
| 12:41.39 | eferro | #2 0x080c97aa in pbx_extension_helper (c=0x8484468, con=0x0, context=0x84845e8 "macro-dial-trunk", exten=0x8484638 "s", priority=1, label=0x0, |
| 12:41.39 | eferro | <PROTECTED> |
| 12:42.17 | eferro | is a asterisk 1.4.4 version, but whe detect the same problem in the 1.4.11 and 1.4.16 version... |
| 12:43.16 | eferro | I supose that the problem is to use some Variable or funcion when the reload is reloading the dialplan, but i don't know how avoid the problem... |
| 12:43.31 | eferro | any tip? |
| 12:49.15 | eliel | eferro: You should submit a bug report on bugs.digium.com uploading the backtrace |
| 12:50.11 | eliel | eferro: Also explain how to reproduce the bug |
| 12:50.15 | eliel | eferro: Thanks! |
| 12:51.43 | eferro | This is the problem i can't reproduce in the lab.... only on production sites.... and versions 1.4.4 or 1.4.11 but not with the svn version |
| 12:52.03 | eferro | I don't want to send a bad bug report :) |
| 12:53.00 | eferro | I don't want to waste a lot of time of official developers.... |
| 12:53.30 | eferro | eliel, you think that it can be a submitable bug, even if the problem is in configuration? |
| 12:54.36 | eliel | eferro: If you have a core dump it doesn't look like a configuration issue... |
| 12:55.51 | *** join/#asterisk-dev anonymouz666 (n=anonymou@200.218.193.6) |
| 13:02.12 | eferro | eliel, ok |
| 13:02.28 | eferro | eferro, I go to check two issues an submit a bug |
| 13:02.42 | eferro | eliel, thanks |
| 13:03.02 | eliel | eferro: Thanks you for contributing! |
| 13:07.51 | *** join/#asterisk-dev uluatu (n=deg@200.195.161.164) |
| 13:38.51 | *** join/#asterisk-dev jeffg (i=uFi9kNrV@pdpc/supporter/active/jeffg) |
| 13:43.06 | *** join/#asterisk-dev slayer192 (i=chrisc@208.188.175.153.duracom.net) |
| 13:44.06 | lmadsen | morning! |
| 13:44.28 | *** join/#asterisk-dev bweschke (n=bweschke@204.13.233.213) |
| 13:44.28 | *** mode/#asterisk-dev [+o bweschke] by ChanServ |
| 13:48.15 | jmls | morning |
| 14:00.39 | *** part/#asterisk-dev jmls (n=jmls@81.138.42.77) |
| 14:05.08 | Qwell | M11830 |
| 14:05.09 | MuffinMan | [new] [Asterisk] General 0011830: Mantis issue with SVN revision no > 100000 reported by snuffy http://bugs.digium.com/view.php?id=11830 |
| 14:05.10 | Qwell | yikes |
| 14:07.36 | ctooley | nice |
| 14:10.38 | *** join/#asterisk-dev Juggie (i=Juggie@CPE001601df17fb-CM001a6682d7b6.cpe.net.cable.rogers.com) |
| 14:13.02 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 14:14.23 | sergee | A100000 |
| 14:14.24 | MuffinMan | [100000] Committed by root on 2008-01-23 17:16:20: automerge commit |
| 14:14.29 | jeffg | 100000 revisions ought to be enough for anybody |
| 14:14.46 | jeffg | just means asterisk is finished |
| 14:15.06 | sergee | automerge took the jackpot |
| 14:16.00 | *** join/#asterisk-dev jmls (n=jmls@81.138.42.77) |
| 14:23.49 | *** join/#asterisk-dev RoyK (n=roy@91.149.9.91) |
| 14:24.53 | ctooley | Since DeadAGI has been removed there's a feeling that DeadExternalIVR() wouldn't be an acceptable application either (even if it's part of ExternalIVR and just modifies the way ExternalIVR() handles audio functions. |
| 14:25.39 | ctooley | However, this leads to some problems. Namely EIVR communications on an unanswered channel that we don't want to have answered. |
| 14:25.49 | ctooley | ExternalIVR() auto-answers |
| 14:26.16 | kpfleming | DeadAGI isn't gone... it's just another mode for AGI now |
| 14:27.29 | ctooley | Well, that's what we were going to do for DeadExternalIVR(). |
| 14:27.39 | Juggie | DeadAGI() as an app is gone. |
| 14:27.48 | Juggie | its just aliased to AGI and outputs a warning when using. |
| 14:28.04 | ctooley | The question is, can you put DeadAGI(/path/app) in the dialplan? |
| 14:28.08 | ctooley | And is that going away/ |
| 14:28.15 | Juggie | you can, but it will yell at you. |
| 14:28.46 | kpfleming | there isn't any need for DeadExternalIVR |
| 14:28.56 | kpfleming | just make ExternalIVR do the 'right thing' on a channel that is hungup |
| 14:29.17 | kpfleming | and add an option to make it not answer the channel if you don't want it to, although that's not the same thing as a dead channel |
| 14:29.21 | ctooley | kpfleming, it's not channels that have been answered and hungup, it's channels that have never been answered and we don't want them to answer. |
| 14:29.28 | kpfleming | because even an unanswered channel has audio |
| 14:29.32 | ctooley | kpfleming, yeah, name is bad. |
| 14:29.53 | jsmith | kpfleming: Like the "noanswer" option to Playback, in a way? |
| 14:29.59 | kpfleming | yep |
| 14:30.27 | jsmith | ctooley: That's the point I was trying to make yesterday ;-) |
| 14:30.29 | ctooley | options to ExternalIVR() won't work though, the arguments are all passed to the child application. So a dialplan variable was suggested. |
| 14:30.36 | Juggie | you could tell ExternalIVR() not to answer, but the most logical way would be as a parm, but of course that would require changing how you call ExternalIVR() to pass an option. |
| 14:30.42 | kpfleming | yep |
| 14:30.47 | Juggie | the other option is to set a channel variable. |
| 14:30.49 | kpfleming | something we should probably find a way to fix |
| 14:31.15 | Juggie | (de-ja vu, we just said the same thing ctooley :)) |
| 14:31.28 | ctooley | kpfleming, well... one option would be to have arguments to the child application separated by pipes and arguments to ExternalIVR separated by commas |
| 14:31.39 | kpfleming | ugh |
| 14:31.43 | Juggie | hah, no. |
| 14:31.55 | ctooley | Juggie, yeah, I know, I just wanted to get the original author's input. :) |
| 14:32.20 | ctooley | Well, I don't really care what the separators are, as long as they're distinguishable. |
| 14:32.33 | kpfleming | about the only backward-compatible way will be for the options to be the first argument and then push the other arguments out |
| 14:32.47 | kpfleming | but finding a way to distinguish between a command name and an option string is not going to be easy |
| 14:32.54 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 14:32.54 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 14:32.58 | ctooley | kpfleming, right. |
| 14:33.20 | kpfleming | so the syntax would be ExternalIVR([options,]command[,arg[,arg]]) |
| 14:33.48 | Juggie | well realistically, you have issues if you name your command=noanswer or something along those lines. |
| 14:33.58 | kpfleming | that's my point |
| 14:34.19 | kpfleming | so find some creative way to accomplish that and all will be good |
| 14:34.21 | Juggie | you could do a sanity check to see if the file existed when picking the value up as an option |
| 14:34.58 | Juggie | so if you see the option=noanswer then double check some crack head system admin has not created that file on the os |
| 14:35.14 | kpfleming | options are single characters, not words |
| 14:35.56 | Juggie | ya i guess they should be, but that is not allways true, eg playback. |
| 14:36.27 | kpfleming | i guess one way to do it would be to parse the first argument as options and if it consists *solely* of valid option characters and there are no repeats (and especially if any of the options take arguments themselves) then consider it opitions |
| 14:37.03 | ctooley | Anyway that solves this problem is going to make it "different" than other applications. |
| 14:37.03 | kpfleming | Juggie: all apps parse only the first character of options... accepting 'noanswer' is just for legacy compatibility |
| 14:37.48 | ctooley | Unless we completely break backwards compatibility and say, the options all come after the last comma. |
| 14:37.48 | Juggie | kpfleming, yeah, would be alot easier if alot of legacy stuff went away :) |
| 14:38.06 | Juggie | ctooley, except if the user has no options. |
| 14:38.16 | Juggie | its a catch 22, you are passing two kinds of options. |
| 14:38.32 | kpfleming | it should be marked deprecated in trunk... if you want to make a patch to trunk to make all word-style options for apps deprecated that would be awesome |
| 14:38.41 | ctooley | right, which makes a different kind of distinction seem more logical to me for the end user. |
| 14:40.21 | Juggie | does the options parser handle D(...) variables indefinitally? |
| 14:40.29 | Juggie | er, options i mean. |
| 14:40.46 | Juggie | eg, i can do D(1:2:3....) and so on? |
| 14:41.25 | kpfleming | what do you mean, does it parse the contents of the ()? |
| 14:41.52 | Juggie | no, i mean i have never seen a () bigger then 3 vars, eg call limit in dial is L(x:y:z) |
| 14:42.01 | Juggie | but i am wondering if that is hard coded or if it can go bigger. |
| 14:42.04 | kpfleming | the contents of the () are up to the application |
| 14:42.09 | Juggie | (automatically) |
| 14:42.17 | kpfleming | the options parser does not do anything with it except find the ( and the ) and strip them off |
| 14:42.41 | Juggie | ok, well then what about ExternalIVR(file,options) where options are like N for no answer and then A() for args. |
| 14:42.57 | Juggie | eg, ExternalIVR(file,NA(arg1,arg2)) |
| 14:43.18 | ctooley | how does the application get them though? Is there a distinction between N and arg1? |
| 14:43.45 | kpfleming | that is not backwards compatible |
| 14:43.51 | kpfleming | it would be a flag-day change for anyone who upgrades |
| 14:44.10 | kpfleming | ctooley: in his example yes, the arguments to A() are the arguments for the child application |
| 14:44.56 | ctooley | but, as you said, completely backwards incompatible. Which would have been easier to take 3 months ago before beta1 |
| 14:45.14 | Juggie | you could do some magic to tell if the first option was options for ExternalIVR or not (same as you suggested doing if we added the options to the start) |
| 14:45.41 | ctooley | anything that takes doing "magic" means it's unclear to the end user. |
| 14:45.42 | Juggie | and if you see any more then 2 parms for the application, then you know it has to be old style |
| 14:46.19 | ctooley | what if there's exactly 1 argument to the application and it's "N" for no? |
| 14:46.26 | kpfleming | right |
| 14:46.41 | kpfleming | the only possible way is for the options to be the first argument |
| 14:46.44 | Juggie | well ya, then there is going to be a conflict i guess. |
| 14:47.11 | kpfleming | or... ExternalIVR2() :-) |
| 14:47.14 | Juggie | but if we want to change the style of an app, how can we do that when we know its going to break compat |
| 14:47.43 | *** join/#asterisk-dev jcmoore (n=jcmoore@unaffiliated/tgrman) |
| 14:47.49 | kpfleming | we can't |
| 14:47.51 | kpfleming | that's the point |
| 14:47.52 | Qwell | my favorite app parsing oddity, was the guy who tried calling Voicemail(business1), and kept wondering why it was saying that "iness1" wasn't a valid mailbox |
| 14:48.02 | ctooley | kpfleming, or change it to something entirely different and change the name as well. It's useful for a lot more than just IVRs. :) |
| 14:48.03 | kpfleming | yeah... i'm glad we fixed that |
| 14:48.30 | kpfleming | ctooley: yes... well, we had a discussion here yesterday about how ExternalIVR and AGI need to become the same thing and support both synchronous and asynchronous modes |
| 14:48.40 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177583384.dsl.bell.ca) |
| 14:48.46 | kpfleming | that's more work though |
| 14:49.26 | ctooley | And a very complex application in general, lots of different modes, operational stuff, etc. |
| 14:49.51 | Juggie | which app are you calling complex, AGI? |
| 14:49.51 | ctooley | even if they use the same syntax for communication it becomes very complicated to weigh the usages. |
| 14:50.17 | ctooley | Juggie, a combination of EIVR and AGI with both synchronous and asynchronous modes |
| 14:50.34 | Juggie | o :) |
| 14:51.39 | ctooley | The thing is, EIVR is a fast, very handy protocol, especially when connecting to an existing daemon (we just submitted a tcp socket patch yesterday). |
| 14:51.46 | *** join/#asterisk-dev flujan (n=flujan@200-160-115-020.static.spo.ctbc.com.br) |
| 14:51.53 | ctooley | AGI isn't too bad, but it's much more verbose. |
| 14:55.24 | ctooley | I'm going to leave this open and will be back in a few minutes. I'm really open to input, we're willing to do the work to do the development and submit the patches. We just want to make sure we're not running up the wrong mountain. |
| 14:56.15 | ctooley | There's probably 5 or 6 companies/people for which EIVR has become important and I worked on two of those. |
| 14:59.46 | *** join/#asterisk-dev wwalker (n=wwalker@pdpc/supporter/sustaining/wwalker) |
| 15:04.35 | *** join/#asterisk-dev moy (n=moyhu@nat/ibm/x-40dba4d323eb66c8) |
| 15:07.05 | flujan | hi Corydon76-dig , The patch for M11386 does not apply well... Here is the output. |
| 15:07.06 | flujan | http://pastebin.com/m2536a45a |
| 15:07.57 | flujan | I will put a intel machine to work with a vanilla version of 1.4.17. I also compiled a version with the patch. If the bug persists on the first version, I will try the patched one. :) |
| 15:16.51 | ctooley | back |
| 15:18.37 | ctooley | What's the issue with using a different argument separator for ExternalIVR arguments and child application arguments (so I'm more familiar). |
| 15:19.39 | kpfleming | confusion, mostly |
| 15:20.11 | ctooley | seems to create a good distinction to me. |
| 15:20.15 | kpfleming | and it would also be not backwards-compatible unless the special separator was used for options to the app, which would then be inconsistent with the rest of Asterisk's apps |
| 15:20.18 | ctooley | but, I'm game for whatever. |
| 15:20.36 | kpfleming | there is another method we could follow... but again it is not backwards compatible |
| 15:21.01 | kpfleming | so I think that just making ExternalIVR2() be the new version with a first argument that is options for the app itself is the easiest course of action |
| 15:21.28 | ctooley | but isn't that inconsistent with the rest of Asterisk arguments as well? |
| 15:21.53 | ctooley | And it leads to other possible problems. |
| 15:22.17 | kpfleming | what problems are those? |
| 15:23.01 | ctooley | Well, detecting whether the argument is the two letters of ExternalIVR() arguments or a child command name. |
| 15:23.34 | kpfleming | umm... no |
| 15:23.54 | kpfleming | ExternalIVR2(options,command[,arg1[,arg2]]) |
| 15:24.08 | kpfleming | for this version of the app, the options argument must always be specified, even if empty |
| 15:24.34 | ctooley | wwalker brought up another option if we're going to break backwards compatibility. There's already an O argument, we could make ExternalIVR() never answer the call and add an Answer argument or Option. |
| 15:24.49 | kpfleming | if you want to make it clearer, you could use your suggestion in combination... there are other apps in Asterisk that use '^' to separate arguments that are going to passed to some other application |
| 15:25.27 | kpfleming | i don't think we can break backwards compatibility |
| 15:25.39 | ctooley | I meant for an ExternalIVR2() application |
| 15:25.39 | kpfleming | just adding another flavor of the app is simple and doesn't impact the code much at all |
| 15:25.50 | kpfleming | oh, i see |
| 15:25.53 | wwalker | while I made that recommendation, it breaks backward compatibility and is quite unintuitive for some foleks |
| 15:26.05 | kpfleming | well, the model in asterisk has always been that answer is implicit and has to be disabled if you don't want it |
| 15:26.15 | kpfleming | hi wayne :-) |
| 15:26.17 | ctooley | ok, I'm game for whichever. |
| 15:26.28 | kpfleming | so how about: |
| 15:26.55 | wwalker | I do like have the option in the child app to answer the channel at the time of our choosing (and maybe being able to return a value that would cause the call to roll to the next server in a hunt group |
| 15:27.01 | wwalker | hi Kevin |
| 15:27.02 | kpfleming | ExternalIVR2(command[,arg1[^arg2[^arg3...]]][,options]) |
| 15:27.39 | ctooley | wouldn't arg1 also have to be prepended with ^ in that scenario? |
| 15:27.44 | kpfleming | nope |
| 15:27.48 | ctooley | again, the arguments could be confused. |
| 15:28.05 | ctooley | if they're both optional that is. |
| 15:28.08 | kpfleming | the commas separate arguments to the ExternalIVR2 app, the ^ separate arguments to the command |
| 15:28.17 | kpfleming | uhh... my syntax was wrong |
| 15:28.23 | wwalker | if you want to add options, you must pass an empty args arg |
| 15:28.27 | kpfleming | right |
| 15:28.36 | kpfleming | ExternalIVR2(foobar,,AO(2)) |
| 15:28.44 | wwalker | ExternalIVR2(command,,options) |
| 15:29.02 | kpfleming | the syntax could be written properly, i'm just trying to read SIP RFCs right now :-) |
| 15:29.29 | ctooley | ok, sounds good to me. We submitted two patches to ExternalIVR() yesterday, those will be included in ExternalIVR2() by default. |
| 15:29.42 | ctooley | kpfleming, you have my sympathies |
| 15:30.09 | wwalker | lol |
| 15:30.29 | wwalker | At least _I_ didn't write the C code.... |
| 15:31.27 | wwalker | ExternalIVR2 - would it be possibly developed for 1.4, or only for 1.6? |
| 15:31.43 | wwalker | I assume 1.6, but one can dream... |
| 15:31.45 | kpfleming | we wouldn't add it to 1.4 |
| 15:31.51 | Qwell | tip: a remote that's 6"x3"x2" won't fit in a laptops expresscard slot |
| 15:32.11 | ctooley | hehehe |
| 15:32.34 | wwalker | Qwell: was that enlightenment alcohol driven or do you have kids? |
| 15:32.52 | Qwell | HP apparently can't read |
| 15:32.55 | *** join/#asterisk-dev D0nGz (n=D0nGz@dsl092-129-089.chi1.dsl.speakeasy.net) |
| 15:33.03 | kpfleming | wwalker: all these changes are isolated to app_externalivr.c and don't require any core API changes, so backporting would be trivial |
| 15:33.32 | ctooley | kpfleming, :) We don't need to backport, we have all the functionality in 1.4 already, it's all in how we forward port. |
| 15:33.44 | kpfleming | but he was asking about 1.4 support |
| 15:33.49 | wwalker | Wasn't sure how big the changes from 1.4 to 1.6 core was. Cool :) |
| 15:33.53 | ctooley | We're just dreaming of not going through a massive patch job every time we upgrade 1.4 versions |
| 15:33.59 | kpfleming | for any other 1.4 users who want this stuff, you could easily give it to them |
| 15:34.24 | kpfleming | run a diff between app_externalivr.c in 1.4 and trunk, i suspect they aren't much differnt |
| 15:34.27 | ctooley | kpfleming, there's actually already patches in bugs.digium.com for this functionality as well. |
| 15:34.32 | kpfleming | ok |
| 15:35.07 | ctooley | kpfleming, they wouldn't be if my patches from yesterday were applied. :) tcp socket support caused some significant code restructuring. |
| 15:35.07 | wwalker | With the addition of a socket interface as an option to the exec() interface, the patches aren't as small as you might think |
| 15:35.33 | kpfleming | you are missing my point |
| 15:35.46 | ctooley | kpfleming, yeah, your 1.4 and your 1.6 aren't much different. |
| 15:35.57 | kpfleming | no matter how much the trunk version has changed, it would be easy to use in 1.4 |
| 15:37.54 | ctooley | Since we're effectively creating a new application, could we maybe pick a different name? |
| 15:38.06 | kpfleming | if you like, sure |
| 15:38.15 | kpfleming | but it will still be in the same source file since it shares nearly all the code |
| 15:40.28 | ctooley | We can keep it makes more sense (but yes, it would be in the same source file), just have to go figure out how to do that. ;) |
| 15:41.56 | ctooley | There are other applications that do that I think, just have to go find an example. |
| 15:42.03 | *** join/#asterisk-dev sruffell (n=sruffell@216.207.245.1) |
| 15:42.03 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:42.19 | wwalker | So it's just going to be an alias for the same module. Based on name it will have a different argument parsing system and possibly different defaults? |
| 15:42.41 | kpfleming | right |
| 15:42.44 | ctooley | wwalker, yep |
| 15:43.02 | wwalker | 98% of the rest of the code is shared/used by both modes. |
| 15:43.02 | ctooley | can think of an app that does that already off the top of your head? |
| 15:44.03 | kpfleming | AGI :-) |
| 15:44.18 | wwalker | gzip/gunzip?? :) agi, busybox, PayPal (1 massive windows .exe for all their web interface :) |
| 15:44.39 | ctooley | ok |
| 15:44.40 | ctooley | will do |
| 15:45.18 | ctooley | wwalker, I was mostly concerned with how it's done in Asterisk. I'm relatively ok with how to do it in general. |
| 15:45.40 | wwalker | kpfleming: do you guys have code for argument parsing, or you just put the strtok or whatever in each module separately? |
| 15:45.53 | kpfleming | it's all in the API, in asterisk/app.h |
| 15:46.17 | ctooley | wwalker, Robison and I spent the day yesterday learning all the new argument parsing code. :) |
| 15:46.29 | wwalker | Cool, I'll bow outl. |
| 15:46.32 | wwalker | out. |
| 15:46.49 | ctooley | no worries, that's something we've become more familiar with though. |
| 15:57.49 | *** part/#asterisk-dev pnlarsson-work (n=pnlarsso@h3n1fls34o831.telia.com) |
| 15:58.14 | *** part/#asterisk-dev HeXeD (n=hex@87-194-8-43.bethere.co.uk) |
| 16:18.23 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 16:18.23 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 16:22.47 | *** join/#asterisk-dev uluatu (n=deg@200.195.161.164) |
| 16:27.31 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.12.183) |
| 16:33.15 | Qwell | jpeeler: I just assigned issue 11830 to you, fyi :) |
| 16:34.09 | jpeeler | yay more mantis work |
| 16:34.30 | Qwell | looks a bit silly - hopefully it'll be an easy fix |
| 16:34.40 | Qwell | I'm sure whoever wrote that code never expected that we'd have 6 digit revisions :D |
| 16:34.49 | jpeeler | yeah probably not |
| 16:34.55 | Qwell | it was probably a very reasonable assumption at the time |
| 16:36.39 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-9-100.dsl.telesp.net.br) |
| 16:37.04 | Qwell | Corydon76-dig: did those ifaddr changes also go into 1.4? |
| 16:37.50 | *** join/#asterisk-dev jeffg (i=cS6EI0QT@pdpc/supporter/active/jeffg) |
| 16:42.36 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 16:42.36 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 16:55.02 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 17:25.56 | *** part/#asterisk-dev bweschke (n=bweschke@204.13.233.213) |
| 17:44.06 | *** join/#asterisk-dev tzafrir (n=tzafrir@62.90.10.53) |
| 17:44.06 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 17:51.47 | *** join/#asterisk-dev janinge (i=j@ninge.net) |
| 17:55.22 | *** join/#asterisk-dev _ys (n=yuri@236-069.nat.mns.ru) |
| 17:57.30 | codefreeze | What does "Out of idle IAX2 threads for scheduling" mean? Anybody know? |
| 17:58.29 | bkruse | codefreeze: Really? |
| 17:58.48 | file | it means chan_iax2 deadlocked. |
| 17:59.01 | bkruse | I believe that in iax.conf (for asterisk >= 1.4) you have a maximum thread count |
| 17:59.17 | bkruse | When those threads are off doing their deal, and another call comes in, you deadlock |
| 17:59.19 | bkruse | right file? |
| 17:59.41 | file | ...not really |
| 18:00.03 | bkruse | oh. |
| 18:00.19 | file | one of the pvt structures is probably deadlocked, and all the other threads are probably looking through trying to find a free callno and hit that one and deadlock themselves |
| 18:01.06 | bkruse | This has happend to me with a relatively high call load |
| 18:01.23 | codefreeze | Well, that's the goal. |
| 18:01.32 | codefreeze | (I guess I succeeded |
| 18:01.53 | bkruse | bumping the iaxmaxthreadcount (in iax.conf) helped a ton when doing performance testing |
| 18:02.34 | codefreeze | My target iax asterisk is spitting tens of millions of "XXX ERROR XXX A thread holds more locks than '64'. Increase AST_MAX_LOCKS! |
| 18:03.09 | bkruse | Ouch, is this on a 'not to powerful' box? |
| 18:03.25 | bkruse | I have seen similar with short playback loops (both sides of the dialplan) and a huge number if iax calls in performance testing |
| 18:04.43 | codefreeze | Well, I'm pounding the target asterisk with a large set of long calls... I thought I could reach 100 simultaneous, tho. |
| 18:05.45 | mvanbaak | we dont support building on nativ windows right ? |
| 18:05.51 | mvanbaak | only inside cygwin |
| 18:07.03 | codefreeze | my intermediate 1.4 asterisk crashed... the end asterisk went nuts... looks for a good start... |
| 18:07.26 | mvanbaak | configure: error: installation or configuration problem: C compiler cannot create executables. |
| 18:07.29 | mvanbaak | OUCH |
| 18:07.42 | mvanbaak | wtf |
| 18:07.52 | bkruse | codefreeze: wow, did you bump up the amount of threads, ulimit -n unlimited |
| 18:08.03 | bkruse | (on a box with high amounts of ram, just for a test, to get a number) |
| 18:08.14 | file | that increases the file descriptor limit. |
| 18:09.06 | bkruse | when I was doing iax2 testing, and got to ~200ish calls, I had to bump the file descriptor limit, or it would stop accepting calls and die because it could not open anymore.... |
| 18:09.13 | codefreeze | bkruse: I did 'ulimit -n 8196' on the end machine; but I didn't for my intermediate 1.4. It should handle 100 simultaneous calls ok. I don't have 'too many open files' problems till I get to around 200. |
| 18:09.32 | bkruse | file: see :] |
| 18:10.02 | bkruse | codefreeze: interesting...So you have this box under test (box B) and box A pushing calls correct? |
| 18:12.37 | codefreeze | bkruse: yes. But it's worse. I have test box A I want to see how many iax calls it can handle. I have test boxes B and C running asterisk also, configured to get sip calls from sipp and to dial IAX to A. I have sipp running on B and C to basically convert a SIP call from sipp to an IAX call to A. |
| 18:13.08 | bkruse | Gotcha. So the load will NOT die on B or C but will bottleneck on A for sure correct? |
| 18:13.23 | bkruse | Box A is answering the IAX2 call and..... |
| 18:14.06 | codefreeze | Well... we'll see. The goal is to have each of B and C not really push their limits, but the cumulative traffic to A explode A instead. |
| 18:15.35 | bkruse | Right right |
| 18:16.01 | bkruse | I would make A answer, and go into a playback loop (demo-congrats) if you use a short audio file, the playback loop is then shorter, and more intensive |
| 18:16.33 | bkruse | (surprisingly, using a shorter file, eg 5-20 seconds vs the 60 or so of demo-congrats almost decreased performance 50%) |
| 18:18.12 | kpfleming | tzafrir: ping |
| 18:18.20 | tzafrir | here |
| 18:18.27 | codefreeze | bkruse: really? I infinite loop on a long file |
| 18:18.55 | codefreeze | The thread limit on iax is 100. 10 to start. |
| 18:18.59 | bkruse | right |
| 18:19.05 | kpfleming | tzafrir: simple question (i hope)... what package to i need to install on debian sid to get the kernel sources that were used to build the standard kernel so i can make a small change to it? |
| 18:19.19 | bkruse | codefreeze: yes, I used just goto's for a playback on demo-congrats (and optionally a wait()) then bumped my iax threads as high as they could go |
| 18:19.31 | bkruse | those few optimizations boosted performance a ton, try it out :] |
| 18:20.01 | tzafrir | there's generally kernel-source-2.6.23 and kernel-patches-2.6.23, IIRC |
| 18:20.06 | kpfleming | ok |
| 18:20.15 | tzafrir | but that part always seems kind of complicated |
| 18:20.37 | codefreeze | bkruse: do you have a feel for max simult. calls between iax and sip? |
| 18:20.46 | tzafrir | You want to change the source or the headers? |
| 18:20.57 | bkruse | codefreeze: oh its been a over 6 months since performance testing |
| 18:21.01 | kpfleming | i want to disable building the e1000 NIC module and replace it with the Intel one |
| 18:21.21 | bkruse | luckily, the testing tool for PQ is almost finished, that will give us these results with any revision of asterisk |
| 18:21.42 | codefreeze | bkruse: (in hypnotic voice:) Search deeply in your memory!!! |
| 18:21.42 | bkruse | codefreeze: no transcoding correct? |
| 18:21.56 | codefreeze | bkruse: just ulaw |
| 18:22.09 | bkruse | codefreeze: have you reached your bandwidth consumption also? |
| 18:22.18 | codefreeze | hope not |
| 18:22.21 | bkruse | That was actually a problem I ran into after hitting a huge number of those calls |
| 18:22.53 | bkruse | codefreeze: I could literally lab it up in a couple of minutes and see what I could cook up |
| 18:23.06 | bkruse | mogorman left, and hes someone I need on my main project, so I am not working on that today |
| 18:23.31 | codefreeze | my feel, is that my test machine has nowhere near the guts to saturate 100mb ethernet. |
| 18:23.54 | *** join/#asterisk-dev shido6 (n=shido6@204.126.120.132) |
| 18:24.27 | bkruse | codefreeze: that is a lot of calls, but just something to keep in the back of your head :] |
| 18:25.02 | bkruse | codefreeze: we should get together if you are serious about this and write up some tests. I used to do the "performance tests" for BE and open source asterisk (for the hardware guys) all the time |
| 18:25.24 | codefreeze | bkruse: I've got a lousy situation with tests of this kind. If you could lab this up and run some perf tests for me, I've got some code.... |
| 18:25.57 | bkruse | oh you got code? :] |
| 18:26.09 | bkruse | I would have no problem doing that today, and tomorrow if needed, just have to clear it |
| 18:30.48 | citats | anyone opposed to upping the size of char file[40] in astmm.c to something like 64? depending on where you keep your source it can truncate the names. in my case it was grouping allocations from /home/.../include/asterisk/strings.h with /home/.../threadstorage.h |
| 18:31.14 | russellb | citats: fine with me |
| 18:32.48 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 18:35.13 | Qwell | well |
| 18:35.18 | Qwell | why not just use AST_MAX_PATH or whatever? |
| 18:35.28 | kpfleming | PATH_MAX is 240 bytes IIRC |
| 18:35.33 | Qwell | yeah, that one |
| 18:35.50 | Qwell | sure, it's a little bigger, but there's a reason for it |
| 18:37.28 | kpfleming | another option would be store only the *last* N bytes of the file path instead of the *first* N bytes |
| 18:38.00 | Qwell | does it try to do anything with the filename, like a stat() or similar? |
| 18:38.21 | kpfleming | no |
| 18:40.25 | citats | kpfleming: the filename is coming from __FILE__ and seems to only have a full path for header files |
| 18:40.49 | kpfleming | right... the code that stores it would have to copy only the last 63 characters |
| 18:56.15 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 18:58.26 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 19:12.19 | codefreeze | bkruse: sorry, got dragged away for lunch... If you can get some time to do some perf tests, on my code, that'd be great. I've only got 2.5 computers to work with. For IAX, I have no tool like sipp (at the moment) I can use to do basic measurements... and I'm not really even sure the approach I'm taking with using sipp to trigger one asterisk to call another via IAX is really the easiest/best approach. It'd be nice to be able to have a IAX cl |
| 19:12.19 | codefreeze | ient app that would basically complement the situation and form a sort of closed loop between two asterisks.... |
| 19:14.08 | bkruse | codefreeze: I got the thumbs up for helpin |
| 19:14.08 | ctooley | codefreeze, if bkruse can't help you, I've got about 10 boxes I haven't brought into route yet which are already set up to do sipp load testing, but they're only one set of hardware. Plus we've tweaked /etc/security/limits.conf to have no file descriptor limits. I could change those settings on the fly though. |
| 19:14.36 | bkruse | ctooley: that would be of help also |
| 19:15.02 | ctooley | bkruse, codefreeze, if you guys just want a second test platform, let me know. |
| 19:15.13 | bkruse | nice nice |
| 19:15.21 | bkruse | codefreeze: I used a bash script and call files... :] |
| 19:15.27 | bkruse | instead of "sipp dialing in" |
| 19:15.32 | ctooley | Our servers are all 2 dual core 2.8GHz with 4GB of RAM and GigE between them. |
| 19:15.38 | bkruse | nice nice nice |
| 19:15.42 | codefreeze | ctooley: you are on the list! |
| 19:16.00 | codefreeze | bkuse: sounds good. I'm gonna give you a call... |
| 19:16.19 | ctooley | We don't always have 10 boxes idle, but we usually have 4 or 5. Just send me over the test set up. |
| 19:16.24 | bkruse | codefreeze: rockin |
| 19:16.51 | ctooley | Also, I need to know if I should do a 1.4 load or a 1.6 load. We can run them all simultaneously as we have 4 instances of 1.4 loaded on every box anyway |
| 19:20.22 | Qwell | anybody with GNU make foo that knows a good way to escape spaces in a variable? |
| 19:21.09 | Qwell | the problem, specifically, is that include cannot use "/path/to/something with spaces/" (with quotes), you have to use /path/to/something\ with\ spaces/ |
| 19:21.20 | russellb | $(shell echo $(MYVAR) | sed -e 's/ /\\ /g') |
| 19:21.22 | russellb | :-p |
| 19:21.43 | Qwell | yeah, I could cheat with bash foo, but if there's a way to do it directly in GNU make, I'd prefer that :D |
| 19:22.19 | Qwell | the problem is ASTTOPDIR in a location with spaces...build fails miserably |
| 19:22.19 | russellb | Qwell: don't know off of the top of my head ... check the gnu make manual for available functions |
| 19:22.25 | russellb | docs are pretty good |
| 19:22.35 | Qwell | russellb: almost too good ;) |
| 19:23.29 | putnopvut | A google brought this article up: http://www.cmcrossroads.com/articles/ask-mr.-make/gnu-make-meets-file-names-with-spaces-in-them.html |
| 19:23.33 | putnopvut | Not sure if it's helpful. |
| 19:23.36 | kpfleming | Qwell: can you give me an example of something that is failing? |
| 19:24.13 | Qwell | kpfleming: see above. mkdir "/usr/src/something with spaces", checkout asterisk, build. include is very unhappy with ASTTOPDIR, and quotes don't help |
| 19:24.26 | Qwell | (the GNU make include function/directive/thing) |
| 19:26.37 | mvanbaak | it's easy to fix |
| 19:28.23 | mvanbaak | patch uploaded |
| 19:30.58 | Qwell | mvanbaak: that's cheeky |
| 19:31.15 | mvanbaak | it's in the info pages of make somewhere |
| 19:31.32 | mvanbaak | I use it in all my own projects |
| 19:33.19 | kpfleming | link? |
| 19:33.29 | Qwell | http://bugs.digium.com/file_download.php?file_id=17456&type=bug |
| 19:33.33 | Qwell | M11834 |
| 19:33.34 | MuffinMan | [new] [Asterisk] Core/BuildSystem 0011834: compile - make fails if directory path contains spaces reported by spendergrass http://bugs.digium.com/view.php?id=11834 |
| 19:33.45 | mvanbaak | my dev/personal/skeletons/auto-tools/Makefile.in has it with comments: # as per make info pages we need to take care of spaces in pwd |
| 19:34.13 | kpfleming | nice |
| 19:34.59 | Qwell | well, it certainly works |
| 19:36.15 | Qwell | if people agree with that change, I'll commit it |
| 19:36.33 | russellb | Corydon76-dig: reminder to work on res_config_ldap for coding guidelines issues. |
| 19:37.21 | Qwell | russellb: he had done a bit last night, or the night before for that. I didn't look at how much more is left |
| 19:37.36 | russellb | oh, i didn't see any commits |
| 19:37.36 | russellb | sorry |
| 19:37.40 | Corydon76-vcch | russellb: Um, did you see areas that I missed? |
| 19:37.40 | russellb | don't know how i missed them |
| 19:37.56 | Corydon76-vcch | Night before last |
| 19:38.04 | russellb | ok, thank you, sorry |
| 19:38.38 | Corydon76-vcch | The one that wasn't just formatting was the 1.5 second sleep... |
| 19:38.51 | Corydon76-vcch | which seemed kind of like the wrong way to go |
| 19:38.55 | russellb | i still think realtime_ldap_entry_to_var() has some overly excessive nesting going on |
| 19:38.56 | russellb | yeah |
| 19:39.12 | russellb | same with realtime_ldap_result_to_vars |
| 19:39.17 | mvanbaak | food, brb |
| 19:39.26 | Qwell | mvanbaak: fail :( |
| 19:39.26 | Corydon76-vcch | I was primarily concerned with it working... |
| 19:39.32 | Qwell | it got all the way to the end though |
| 19:39.38 | russellb | did you test it? |
| 19:40.01 | Corydon76-vcch | No, I meant I was asking in the bug if it was working... |
| 19:40.41 | Qwell | oh, this is good... make requires that you use escaped spaces, but gcc doesn't appear to accept escaped spaces in -I |
| 19:41.09 | Corydon76-vcch | res_config_curl went from not existing to being committed in 48 hours... and ldap was lagging by two years... |
| 19:41.24 | russellb | yeah, well, i'm concerned with more than it just working ... code needs to be up to our standards, especially basic coding guidelines issues |
| 19:41.36 | russellb | and it took that long because the code was extremely gross |
| 19:41.45 | Corydon76-vcch | Fair enough |
| 19:42.00 | russellb | and we have to maintain this stuff |
| 19:42.09 | russellb | i want it to be not gross, and then still working, before i'm willing to maintain it |
| 19:42.15 | kpfleming | Qwell: the -I arguments will need to be double-quoted.. then the escapes should work |
| 19:42.24 | Qwell | quoted and escaped? |
| 19:42.55 | Corydon76-vcch | russellb: I'll be happy to call the realtime backends my area of expertise... you can assign all the bugs to me... ;-) |
| 19:42.55 | kpfleming | yes.. it's shell syntax, it doesn't have anything to do with gcc |
| 19:42.57 | Qwell | silly...open source...stuff |
| 19:43.05 | kpfleming | wait... i'm wrong |
| 19:43.19 | russellb | Corydon76-dig: ha, okay, I will take you up on that. |
| 19:43.37 | kpfleming | ok, so we need a makefile function to escape the spaces only when needed, and leave the variable's contents alone for everything else that already works |
| 19:43.40 | russellb | Corydon76-dig: thanks for the cleanups you did, and sorry I missed them |
| 19:43.47 | Corydon76-vcch | russellb: as long as it doesn't involve bridging code, I'm good. ;-) |
| 19:43.54 | russellb | ha, i can handle bridging code |
| 19:44.19 | russellb | bridging is simple ... stuff from here goes there. stuff from there goes here. |
| 19:44.19 | russellb | done |
| 19:44.28 | russellb | ... for 2 channels :-p |
| 19:44.29 | putnopvut | russellb: you assume all bridges are between two parties... |
| 19:45.03 | russellb | i said it first :-p |
| 19:45.11 | Corydon76-vcch | and aren't monitored for recording, DTMF, or keywords (thank you, NSA) |
| 19:45.19 | russellb | :) |
| 19:45.57 | Corydon76-vcch | or transfers |
| 19:46.17 | Corydon76-vcch | Masquerading is all you. ;-) |
| 19:46.54 | Corydon76-vcch | Okay, I think we've identified all of the really hard parts... |
| 19:47.18 | russellb | call features are currently handled on a bridge ... |
| 19:47.46 | file | how did we go from ldap to bridging? |
| 19:47.58 | Corydon76-vcch | file: who handles the bugs in each |
| 19:48.05 | file | ah |
| 19:49.10 | Corydon76-vcch | Are we sufficiently complex yet that we can call everything in main/ the kernel? |
| 19:50.34 | putnopvut | I prefer "core" |
| 19:50.44 | putnopvut | But I think that's an argument of semantics. |
| 19:51.44 | Corydon76-vcch | putnopvut: I've been trying to come up with a term that describes what I'm teaching in my class |
| 19:52.10 | Corydon76-vcch | I am NOT teaching stuff like the bridge code, the transcoding, smoother, etc. |
| 19:52.34 | Corydon76-vcch | corespace and userspace, perhaps? |
| 19:52.56 | file | what aspects are you teaching? |
| 19:53.23 | Corydon76-vcch | file: from 0 to writing your own apps, functions, formats, cdr engines, etc. |
| 19:54.06 | Corydon76-vcch | although I seem to be quickly making having to write your own cdr engine unnecessary |
| 19:54.12 | file | so core API usage |
| 19:54.23 | Corydon76-vcch | Yep, core API usage... |
| 19:54.52 | Corydon76-vcch | Trying to distinguish it from AMI or AGI, too |
| 19:55.42 | Corydon76-vcch | Y'know, cdr_curl sounds like a neat idea |
| 19:56.58 | putnopvut | Corydon76-vcch: your course sounds like a course on writing asterisk modules. |
| 19:57.24 | Corydon76-vcch | putnopvut: yep, pretty much... but with the addition that I'm also teaching C... |
| 19:57.56 | Corydon76-vcch | and hopefully enough background that somebody could start diving in and fixing bugs in the core |
| 19:58.19 | putnopvut | Corydon76-vcch: you committed the async agi stuff, right? |
| 19:58.45 | *** join/#asterisk-dev RoyKa (n=roy@91.149.3.168) |
| 19:58.45 | Corydon76-vcch | putnopvut: I don't remember |
| 19:59.07 | putnopvut | heh |
| 19:59.23 | Corydon76-vcch | Yes |
| 19:59.29 | Corydon76-vcch | A96174 |
| 19:59.31 | MuffinMan | [96174] Committed by tilghman on 2008-01-03 02:16:48: Add coordination between AMI and AGI applications, with an asyncagi method |
| 19:59.53 | putnopvut | Okay, I was checking through the code and thought I had found a bug in there. |
| 19:59.54 | Juggie | asyncagi.... ummmmmm |
| 20:00.18 | putnopvut | Juggie: it's not really asynchronous. |
| 20:00.47 | Corydon76-vcch | Well, the commands for it to execute are async |
| 20:01.08 | flujan | Corydon76-vcch: Hi... |
| 20:01.23 | flujan | I am trying to use the new patch for M11386 |
| 20:01.32 | Corydon76-vcch | flujan: update to 1.4 SVN |
| 20:01.40 | flujan | chan_sip.c.rej is bigger now http://pastebin.com/mc51764b |
| 20:01.50 | putnopvut | But line 412 seemed wrong, like the the agi.ctrl should be set to the other fd of the pipe. |
| 20:02.13 | flujan | Corydon76-vcch: humm... Ok. I am first try the 1.4.17 on this intel machine right? Than I will update to the svn |
| 20:02.18 | flujan | Corydon76-vcch: :) |
| 20:02.42 | flujan | Corydon76-vcch: I have a feeling that this issue could be related to the machine... |
| 20:04.53 | Corydon76-vcch | flujan: please, this discussion should be in #asterisk-bugs |
| 20:05.25 | flujan | Corydon76-vcch: Thanks for the tip, and sorry guys I do not know this channel. :( |
| 20:06.34 | Corydon76-vcch | New development here |
| 20:06.34 | Corydon76-vcch | Discussion related to an existing open bug in #asterisk-bugs |
| 20:06.35 | Qwell | mvanbaak: http://theory.uwinnipeg.ca/gnu/make/make_76.html#SEC75 |
| 20:06.35 | Qwell | uses your space:=$(empty) $(empty) magic :D |
| 20:07.14 | Qwell | kpfleming: the page linked above says there is no provision for making a Makefile function. Did you have some magic in mind? |
| 20:15.53 | mvanbaak | Qwell: I knew it was out there |
| 20:16.17 | mvanbaak | it's not something I came up with myself, like I said, I have it in my skeleton |
| 20:17.38 | Qwell | this variable is being passed around so much, that anything I try to do to it ends up being stripped |
| 20:18.47 | mvanbaak | hhmm, darn |
| 20:24.15 | mvanbaak | something is wrong with it indeed |
| 20:24.26 | mvanbaak | everytime I change dirname it does a full compile |
| 20:25.49 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177583384.dsl.bell.ca) |
| 20:28.12 | mvanbaak | gheh, all I can find is: "dont use spaces in the path to your sources. It will make building it more easy" |
| 20:32.09 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 20:32.09 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 20:36.13 | putnopvut | MeetMe is totally pissing me off. |
| 20:36.21 | putnopvut | Just had to get that off my chest. |
| 20:36.59 | file | putnopvut: awww |
| 20:37.15 | russellb | why is MeetMe on your chest? that seems odd. |
| 20:37.26 | file | russellb: I wasn't gonna ask that myself |
| 20:37.42 | putnopvut | "that" refers to the comment, not MeetMe itself. |
| 20:37.52 | putnopvut | I once did have a queue on my chest. |
| 20:38.40 | putnopvut | But anyway, whatever it is I'm doing is causing some sort of infinite loop to happen when I call into a meetme. |
| 20:38.53 | putnopvut | And it's bugging me...a lot. |
| 20:39.23 | file | >_< |
| 20:41.30 | jsmith | putnopvut: We could always rewrite it to use the bridging API ;-) |
| 20:42.21 | jsmith | file: Oh? |
| 20:42.33 | jsmith | file: But it doesn't have any features, right? |
| 20:42.57 | file | not yet, I use it for testing of the bridging core right now |
| 20:43.22 | mvanbaak | hhmm |
| 20:43.25 | file | but it does work :) |
| 20:43.25 | jsmith | Well... there's this thing called 1.6 coming out "Really Soon Now" |
| 20:43.31 | mvanbaak | cant we make the -I calls relative ? |
| 20:43.37 | mvanbaak | like |
| 20:43.41 | jsmith | Would be nice to say "Hey, check this out!" |
| 20:43.46 | Qwell | mvanbaak: relative to what? you can't just use ../include |
| 20:43.50 | putnopvut | Yeah, and this is totally bugging me because I know that people use MeetMe quite a lot, so it has to be something I'm doing wrong. |
| 20:43.53 | mvanbaak | replace the $(ASTTOPDIR)/include to be ./include |
| 20:44.09 | Qwell | no, because you can be 1 or more levels deep |
| 20:44.20 | mvanbaak | hhmm, yeah |
| 20:44.22 | mvanbaak | darn |
| 20:44.26 | file | jsmith: pfft stuff can always be added later |
| 20:44.38 | jsmith | file: I know, but I don't like it :-p |
| 20:45.54 | mvanbaak | and the -I does not like the \ character ? |
| 20:46.27 | Qwell | mvanbaak: right, it has to be quoted, but where we're setting it, by the time it works it's way down to editline, the quotes have long since been rmeoved |
| 20:46.32 | mvanbaak | can it handle the ? char maybe? |
| 20:47.02 | kpfleming | Qwell: $(call ) |
| 20:47.14 | kpfleming | http://www.gnu.org/software/make/manual/make.html#Call-Function |
| 20:47.30 | mvanbaak | yeah |
| 20:47.31 | Qwell | ahh |
| 20:47.43 | mvanbaak | have a look at chapter 7 of the make book by oreilly |
| 20:48.24 | mvanbaak | http://www.oreilly.com/catalog/make3/book/ch07.pdf |
| 20:52.43 | *** join/#asterisk-dev JunK-Y (n=junky@modemcable183.17-83-70.mc.videotron.ca) |
| 20:53.50 | putnopvut | So, um...waitstream_core is infinitely looping for some reason when I call a Meetme. |
| 20:54.09 | putnopvut | I wouldn't expect that to happen in such a core function. |
| 20:59.17 | mvanbaak | Qwell: any ideas ? |
| 21:04.33 | mvanbaak | ugh |
| 21:06.04 | JunK-Y | putnopvut: have you read my patch regarding stage_interface? |
| 21:09.00 | putnopvut | I don't believe so. |
| 21:15.50 | Qwell | mvanbaak: I give up. |
| 21:17.51 | putnopvut | JunK-Y: where is this patch? |
| 21:19.02 | JunK-Y | 01:53 < JunK-Y> take a look at: http://junky.homelinux.com/state.diff |
| 21:19.02 | JunK-Y | 01:53 -!- Irssi: Pasting 5 lines to #asterisk-dev. Press Ctrl-K if you wish to do this or Ctrl-C to cancel. |
| 21:19.06 | JunK-Y | 01:53 < JunK-Y> (gdb) bt |
| 21:19.08 | JunK-Y | 01:53 < JunK-Y> #0 add_to_interfaces (interface=0x0) at /usr/src/asterisk-trunk/include/asterisk/strings.h:180 |
| 21:19.11 | JunK-Y | 01:53 < JunK-Y> #1 0xb6e14a30 in add_to_queue (queuename=<value optimized out>, interface=0xb6e5e92c "SIP/10", membername=0xb6e5e937 "SIP/10", penalty=0, paused=0, dump=0, state_interface=0x0) at app_queue.c:3711 |
| 21:19.15 | JunK-Y | 01:53 < JunK-Y> #2 0xb6e16083 in load_module () at app_queue.c:3974 |
| 21:19.19 | JunK-Y | i was unable to report bugs on bugs.digium.com this night |
| 21:20.42 | ctooley | If I had like 30 minutes of contiguous time to complete this ExternalIVR2() would be done already. :( |
| 21:21.47 | putnopvut | JunK-Y: I think I see why that crashed. |
| 21:21.58 | putnopvut | but I can't seem to be able to load your patch, though. |
| 21:22.11 | putnopvut | by browser is taking forever to connect. |
| 21:27.41 | putnopvut | bbl |
| 21:28.47 | ctooley | Is there a reason that there's no type name for the args struct in app.h for AST_DECLARE_APP_ARGS? |
| 21:29.13 | ctooley | so instead of "struct app_args {}" it's just "struct {}" |
| 21:30.56 | kpfleming | there is no need to give it a type name, because you won't be declaring multiple instances of it |
| 21:30.59 | mvanbaak | Qwell: me too |
| 21:31.09 | mvanbaak | I've been playing with vpath |
| 21:31.53 | ctooley | kpfleming, we need to pass it between functions to be able to handle the arguments differently between ExternalIVR() and ExternalIVR2() |
| 21:32.20 | kpfleming | the old app doesn't take arguments |
| 21:32.39 | ctooley | kpfleming, sure it does, the arguments to the child command |
| 21:33.00 | kpfleming | oh |
| 21:33.16 | kpfleming | well, you can't really use it for that, because that is a variable number of arguments |
| 21:33.17 | *** join/#asterisk-dev puzzled (n=patrick@pni-128-64-192-252.prioritynetworks.net) |
| 21:33.38 | *** part/#asterisk-dev RoyKa (n=roy@91.149.3.168) |
| 21:33.51 | ctooley | that's how the arguments are handled in the older code. |
| 21:33.59 | kpfleming | let me take a look |
| 21:34.02 | ctooley | err old app (version 1.6) anyway |
| 21:34.19 | ctooley | 1.4 used ast_app_parse_ directly |
| 21:34.25 | Qwell | hey putnopvut, check out 11836 |
| 21:34.35 | kpfleming | oh...i see |
| 21:34.52 | Qwell | that sounds very similar to what you described to me earlier with meetme |
| 21:35.06 | kpfleming | well in the new version aren't you going to have two different argument orders so you couldn't use the same structure? |
| 21:35.45 | kpfleming | what syntax are you trying to implement for ExternalIVR2? |
| 21:36.16 | ctooley | We built an "options" structure which are options to ExternalIVR2() and then a argument list (using AST_NONSTANDARD_APP_ARGS). |
| 21:36.37 | ctooley | Then we're passing both into a "_full" exec the same way res_agi does. |
| 21:36.49 | kpfleming | ahh, OK |
| 21:37.09 | kpfleming | well, you can declare your own structure type if you like, the macro is just for convenience |
| 21:37.26 | kpfleming | if we ever change the API, it will cause your module to not compile and we'll see it right away |
| 21:38.11 | ctooley | so.... use ast_app_parse_options directly? |
| 21:38.23 | ctooley | or do the argument split ourselves? |
| 21:39.38 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 21:39.54 | kpfleming | no |
| 21:40.36 | kpfleming | just don't use AST_DECLARE_APP_ARGS, use your own structure definition with the same fields but with a type name so you can declare multiple instances, pointers to pass around, etc. |
| 21:40.54 | ctooley | ah |
| 21:41.05 | ctooley | ok |
| 21:41.14 | *** join/#asterisk-dev bkruse (n=bkruse@216.207.245.1) |
| 21:41.14 | *** mode/#asterisk-dev [+o bkruse] by ChanServ |
| 21:41.24 | kpfleming | and don't add any other fields to the structure or AST_STANDARD_APP_ARGS will break and you'll have to call ast_app_separate_args directly as well |
| 21:42.27 | *** join/#asterisk-dev trippedbreaker (n=trippedb@70.124.89.118) |
| 21:42.32 | ctooley | ok, we'll do that. |
| 21:51.11 | kpfleming | actually, with a commit i'm about to make, you can put other fields in that structure too, as long as the argv array is last (which it needs to be anyway) |
| 21:59.25 | trippedbreaker | kpfleming, sorry I arrived late to the party ... trying to confirm about that declaration macro that ctooley was talking about |
| 22:00.04 | trippedbreaker | Do I understand correctly that AST_DECLARE_APP_ARGS cannot be used more than once in a function? |
| 22:00.24 | trippedbreaker | If so, I'm curious about it |
| 22:00.24 | kpfleming | yes it can |
| 22:00.29 | trippedbreaker | ah ok |
| 22:00.33 | kpfleming | but it does not define a type, so you can't declare multiple instances of the struct it defines, or declare a pointer to that struct type |
| 22:00.44 | trippedbreaker | right |
| 22:01.02 | trippedbreaker | that was why I was thinking about putting in a type tag, but of course that would change the macro |
| 22:01.13 | kpfleming | yes |
| 22:01.21 | trippedbreaker | it would be nice if you could "overload" macros |
| 22:01.30 | kpfleming | shush! this is not C++ |
| 22:01.35 | trippedbreaker | :o) |
| 22:01.45 | russellb | it's a shame :-p |
| 22:01.49 | Corydon76-vcch | How do you overload a substitution? |
| 22:01.51 | ctooley | So, is there a reason not to put a type on the struct? |
| 22:02.13 | kpfleming | if we did, without changing the macro arguments, then you'd only be able to use it once per scope (function or file) |
| 22:02.17 | trippedbreaker | I wonder if there's an opportunity to make a new macro with the added parameter (struct type) and then deprecate the old one eventually |
| 22:02.18 | kpfleming | that would not be awful, i guess |
| 22:02.39 | kpfleming | let me try a test compile and see if that would break any existing modules... brb |
| 22:04.01 | trippedbreaker | I don't think it will be much use (to us anyway) if the type is a static token |
| 22:04.05 | ctooley | right, so since we can't create more than one it doesn't solve our problem anyway |
| 22:04.25 | trippedbreaker | it really needs to be something passed into the macro, or we'll have to look for another option |
| 22:04.35 | kpfleming | umm... i don't understand. |
| 22:04.41 | kpfleming | you don't have to use the instance it declares |
| 22:05.00 | kpfleming | as long as the type exists, you can declare more instances |
| 22:05.08 | trippedbreaker | hmm |
| 22:05.14 | kpfleming | do you need two different structures? |
| 22:05.21 | kpfleming | in the same scope? |
| 22:05.25 | trippedbreaker | wasn't thinking along those lines -- you're right ... |
| 22:05.27 | trippedbreaker | no |
| 22:05.33 | trippedbreaker | the only difference would be the length of the array |
| 22:05.36 | trippedbreaker | which is not important |
| 22:05.39 | trippedbreaker | we can use one length |
| 22:06.16 | trippedbreaker | so, one type, and then additional declarations off that type |
| 22:06.16 | kpfleming | we can't hardcode a typename in the macro... apps/app_exec.c execif_exec() calls AST_DECLARE_APP_ARGS twice in the same scope |
| 22:06.39 | trippedbreaker | k |
| 22:07.04 | trippedbreaker | so the only way, if we were to do something remotely like this, would be to make a new macro and eventually deprecate the old one |
| 22:07.05 | kpfleming | i will see if there are any more... if that's the only one, a workaround would be OK |
| 22:07.28 | kpfleming | there are other places in Asterisk where we have the 'simple' version of a macro and the 'full' version |
| 22:07.43 | kpfleming | that would work here, the full version would take a type name and the simple version wouldn't supply one |
| 22:07.51 | trippedbreaker | If the two macros are next to each other, then it would be an easier maintenance issue to make sure the resulting structs are compatible |
| 22:08.18 | kpfleming | don't go off doing anything until i finish testing this... |
| 22:08.27 | trippedbreaker | gets rid of the somewhat brittle "declare your struct just like ours" idea :o) |
| 22:08.29 | ctooley | sounds good to me. |
| 22:08.36 | trippedbreaker | no worries, waiting on the final judgement :o) |
| 22:09.03 | kpfleming | ok.. first answer is that there are at least seven places in the tree that use the macro twice in the same scope, so the really simple fix is out |
| 22:09.07 | kpfleming | let me try the more complex one |
| 22:09.08 | Corydon76-vcch | func_odbc does that, too |
| 22:10.04 | kpfleming | brb |
| 22:13.54 | *** join/#asterisk-dev eliel (n=eliel@170.51.222.60) |
| 22:14.23 | *** join/#asterisk-dev eliel (n=eliel@170.51.222.60) |
| 22:15.42 | kpfleming | first test worked... now to try the better way |
| 22:15.55 | trippedbreaker | really appreciate your help on this |
| 22:19.43 | jmls | Just a quick question: |
| 22:19.51 | Corydon76-vcch | Remind me why you aren't simply passing argc and argv? |
| 22:20.19 | jmls | if memory used by the asterisk process was 28M yesterday, and is now 32MB does that mean that there is a very small memory leak somewhere ? |
| 22:20.31 | kpfleming | not necessarily |
| 22:20.34 | ctooley | Corydon76-vcch, Mainly to make app_externalivr.c be consistent with the other apps, and because we have 2 different types of "arguments" |
| 22:20.43 | kpfleming | the glibc heap allocator is stingy about returning memory the kernel |
| 22:21.03 | jmls | 4031384 bytes in 4018 allocations in file 'cdr.c' |
| 22:21.19 | jmls | seems a bit high. (There are no calls at the moment) |
| 22:21.31 | russellb | yes, that's not right |
| 22:21.38 | russellb | jmls: do show memory cdr.c |
| 22:21.46 | russellb | or whatever the command is to show the stuff from that one file ... |
| 22:21.51 | russellb | show memory allocations cdr.c maybe |
| 22:22.10 | jmls | loads of |
| 22:22.11 | jmls | 1004 bytes allocated in ast_cdr_alloc at line 466 of cdr.c |
| 22:22.23 | jmls | 4031384 bytes allocated in 4018 allocations |
| 22:23.00 | jmls | SVN-branch-1.4-r98849 |
| 22:24.20 | russellb | are you doing things where there would be multiple CDRs on a channel perhaps? |
| 22:24.38 | jmls | such as ? |
| 22:24.48 | russellb | i know ... forkcdr i guess |
| 22:24.51 | jmls | nope |
| 22:24.52 | russellb | i haven't looked at cdrs in forever |
| 22:25.06 | jmls | all I do is "answer" ;) |
| 22:25.24 | jmls | we use a lot of local channels for inbound queues and outbound dialler calls |
| 22:25.30 | russellb | ok |
| 22:26.46 | jmls | is there any other info I can provide ? |
| 22:27.56 | kpfleming | ctooley: trippedbreaker: r100305 should have what you need |
| 22:28.07 | ctooley | kpfleming, ok, we'll check it out. |
| 22:29.53 | jmls | okies, gotta run. Goodnight all |
| 22:31.15 | snuff-work | russellb: any word from coverity? ;) |
| 22:31.27 | russellb | snuff-work: nope, they never replied. |
| 22:31.34 | snuff-work | ahh :( |
| 22:32.02 | russellb | we're a corporately sponsored open source project, didn't seem they like to give their services away for free to projects like ours |
| 22:32.34 | snuff-work | mm thought would be little issue with that.. worth a try though |
| 22:32.42 | russellb | definitely |
| 22:33.26 | trippedbreaker | kpfleming, did you mean to not use the "type" argument in the AST_DEFINE_ARGS_TYPE macro? |
| 22:33.31 | Corydon76-vcch | russellb: what's the output of 'ip moo' on your system? |
| 22:33.39 | mvanbaak | I like to discuss the astdb location again |
| 22:33.53 | kpfleming | trippedbreaker: oops :-) |
| 22:34.23 | trippedbreaker | :o) |
| 22:36.21 | russellb | Corydon76-dig: O.O |
| 22:36.29 | russellb | how random |
| 22:36.33 | kpfleming | trippedbreaker: fixed |
| 22:36.55 | Corydon76-vcch | Thought that was odd... |
| 22:36.58 | mvanbaak | Corydon76-vcch ;) |
| 22:37.00 | kpfleming | that's awesome |
| 22:37.18 | trippedbreaker | kpfleming: just grabbed it, awesome |
| 22:37.53 | Qwell | Corydon76-dig: where OBJECT := { link | addr | route | rule | neigh | ntable | tunnel | maddr | mroute | monitor | xfrm | moo } |
| 22:38.00 | Qwell | from `ip help` |
| 22:38.03 | mvanbaak | is it ok to define a seperate setting in /etc/asterisk/asterisk.conf for the astdb ? |
| 22:38.22 | mvanbaak | astdbdir => $somedir |
| 22:38.33 | Corydon76-vcch | Qwell: Yeah, I know... interesting easter egg anyway |
| 22:38.45 | russellb | we need more good easter eggs in asterisk |
| 22:38.58 | Corydon76-vcch | The birthday command was certainly good |
| 22:39.14 | Qwell | Corydon76-vcch: I thought it was, anyways |
| 22:39.26 | Corydon76-vcch | We need a perpetual one which tells you how long until the next developer's birthday |
| 22:39.38 | russellb | ha |
| 22:40.10 | mvanbaak | as I want the astdb in /var/db/astdb |
| 22:40.29 | Corydon76-vcch | mvanbaak: isn't there already one? |
| 22:40.37 | mvanbaak | any objections if I make that specific to OpenBSD ? |
| 22:41.25 | mvanbaak | in trunk it is :) |
| 22:41.48 | Corydon76-vcch | Well, that would the place for new features |
| 22:42.13 | mvanbaak | ok |
| 22:44.06 | mvanbaak | ok |
| 22:44.35 | mvanbaak | the build_tools/make_defaults_h need patching for that |
| 22:45.05 | mvanbaak | #define DEFAULT_DB "${INSTALL_PATH}${ASTVARLIBDIR}/astdb" |
| 22:45.09 | mvanbaak | that is not correct |
| 22:45.23 | mvanbaak | it should be: #define AST_DB "${INSTALL_PATH}${ASTDBDIR}/astdb" |
| 22:48.24 | *** part/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-159.bredband.comhem.se) |
| 22:51.12 | mvanbaak | you want me to open a ticket for that one ? |
| 22:54.02 | Corydon76-vcch | That change doesn't work correctly |
| 22:54.27 | mvanbaak | what's wrong with it ? |
| 22:54.29 | Corydon76-vcch | I get #define AST_DB "/astdb" as a result |
| 22:55.15 | mvanbaak | gheh |
| 22:55.23 | mvanbaak | the Makefile needs patching as well |
| 22:55.29 | mvanbaak | export ASTDBDIR |
| 22:55.44 | mvanbaak | in toplevel Makefile that is |
| 22:56.07 | mvanbaak | ok, two line patch it is |
| 22:56.17 | mvanbaak | I can create a .diff.txt for it |
| 22:56.55 | Corydon76-vcch | I've got it |
| 22:57.11 | mvanbaak | we do export all the other asterisk.conf dirs, but not the ASTDBDIR |
| 22:57.34 | mvanbaak | would be nice if it gets in, so the defaults.h actually matches the asterisk.conf file |
| 22:58.28 | Corydon76-vcch | Done |
| 22:58.36 | mvanbaak | great |
| 22:58.38 | mvanbaak | thanks a lot |
| 22:59.21 | mvanbaak | ok |
| 22:59.31 | mvanbaak | now we are doing OpenBSD cleanups |
| 22:59.39 | mvanbaak | you want to look at another 2 liner ? |
| 23:00.05 | Corydon76-vcch | want or need? |
| 23:00.11 | mvanbaak | in channels/Makefile |
| 23:00.19 | mvanbaak | in the OpenBSD part |
| 23:00.32 | mvanbaak | lpt_OpenBSD_x86_r => -lpt |
| 23:00.49 | mvanbaak | H323LIB=-lh323_OpenBSD_x86_r => H323LIB=-lh323 |
| 23:01.07 | Corydon76-vcch | Is this trunk only or 1.4, too? |
| 23:01.15 | mvanbaak | lines 19 and 20 |
| 23:01.17 | mvanbaak | trunk |
| 23:01.30 | mvanbaak | let me test 1.4 |
| 23:01.45 | mvanbaak | hhmm, yeah, 1.4 as well |
| 23:02.01 | *** join/#asterisk-dev DISA-HELP (n=phobosd@shell.intarwebnetorg.com) |
| 23:03.52 | mvanbaak | tested on OpenBSD 4.1, 4.2 and -current now |
| 23:03.59 | mvanbaak | with asterisk 1.4 and trunk |
| 23:04.28 | Corydon76-vcch | This is not my area, so I'm uncomfortable touching it |
| 23:04.36 | Corydon76-vcch | You'll need to file a bug for that one |
| 23:04.50 | mvanbaak | ok |
| 23:05.27 | file | you have to be really careful touching the h323 stuff |
| 23:05.55 | mvanbaak | yup |
| 23:06.18 | mvanbaak | works with gatekeeper here |
| 23:08.01 | mvanbaak | the channels/Makefile patch has been accepted to obsd ports tree. tested by 2 devs there |
| 23:18.52 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip68-103-153-140.ks.ok.cox.net) |
| 23:20.10 | Qwell | A calls B, B completes a # transfer to C, B then completes a # transfer to D, B hangs up, A and D are connected, while C remains on hold. What should happen with C? |
| 23:20.45 | Qwell | actually, that's not right, because completing it would require him hanging up |
| 23:21.11 | Qwell | A calls B, B starts a # transfer to C, B then starts a second # transfer to D, B hangs up, A and D are connected, while C remains on hold. |
| 23:21.39 | Qwell | apparently step 3 happens while he's still talking to C |
| 23:21.43 | mvanbaak | cant help you there because we use the transfer stuff on the phones |
| 23:23.58 | Qwell | I would almost suspect that C is waiting on either A or D to hangup, so it can have it's transfer completed (to A or D..not sure which) |
| 23:24.16 | *** join/#asterisk-dev ZX81 (n=ZX81@202.20.97.211) |
| 23:26.04 | putnopvut | Qwell: # transfer is blind, right? |
| 23:26.12 | mvanbaak | yup |
| 23:26.15 | Qwell | # is attended in the above scenario. sorry, I should've specified. |
| 23:26.17 | mvanbaak | by default it is |
| 23:26.25 | mvanbaak | ah |
| 23:26.30 | mvanbaak | that makes a difference |
| 23:26.36 | *** join/#asterisk-dev jeffg (i=tRYJo9O7@pdpc/supporter/active/jeffg) |
| 23:26.44 | Qwell | in a blind transfer, B would've never been connected with C. |
| 23:26.54 | mvanbaak | indeed |
| 23:27.08 | mvanbaak | ok, zzzzzzzzzzz time here |
| 23:27.13 | *** join/#asterisk-dev ZX81_ (n=ZX81@202.20.97.211) |
| 23:27.24 | mvanbaak | thanks for the patch again Corydon76-vcch |
| 23:27.51 | mvanbaak | OpenBSD + Asterisk rules |
| 23:28.34 | mvanbaak | I'll have to document my setup someday |
| 23:29.01 | mvanbaak | oeh, beer party tomorrow |
| 23:29.04 | mvanbaak | \o/ |
| 23:29.22 | mvanbaak | if you happen to be in .nl tomorrow |
| 23:29.33 | mvanbaak | mail me and I can give you the address |
| 23:29.41 | mvanbaak | free beer and stuff |
| 23:30.23 | mvanbaak | latero all |
| 23:32.12 | putnopvut | Qwell: I just tried reproducing it and couldn't. |
| 23:33.37 | Qwell | with # transfers? |
| 23:34.16 | putnopvut | Well I use *2 as my atxfer code, but shouldn't make a difference. |
| 23:34.23 | Qwell | right |
| 23:34.37 | Qwell | so what happens at step 3? |
| 23:35.05 | Qwell | his step 6-7-6(6 again?) |
| 23:35.17 | putnopvut | Well, I'm not sure how the steps are numbered, but when B attempts the second # transfer (the one to D), C is hung up. |
| 23:35.26 | putnopvut | And dialling D's number does nothing. |
| 23:35.27 | Qwell | hmm |
| 23:35.44 | Qwell | so B returns to A? |
| 23:35.51 | putnopvut | Nope. |
| 23:35.59 | putnopvut | It's a complete mess at that point. |
| 23:36.06 | Qwell | 1.4 or trunk? |
| 23:36.08 | putnopvut | Let me make sure that all the extensions have tT as options. |
| 23:36.09 | putnopvut | 1.4 |
| 23:36.20 | Qwell | he reported against trunk, and it may matter, but who knows |
| 23:37.11 | putnopvut | I'll try against trunk in a minute. Of course now that res_features has been ripped to shreds there... |
| 23:37.20 | Qwell | functionality hasn't changed |
| 23:38.08 | putnopvut | Hmmm, apparently because I'm using *2 as my transfer code, it does make a difference. |
| 23:38.14 | Qwell | really? |
| 23:38.21 | putnopvut | As soon as I press * to transfer a second time, it hangs up the call. |
| 23:38.28 | Qwell | huh |
| 23:39.10 | putnopvut | Nope I'm wrong. |
| 23:39.20 | putnopvut | Forget what I said about * hanging up the call. |
| 23:42.34 | *** join/#asterisk-dev ZX81 (n=ZX81@202.20.97.211) |
| 23:46.44 | putnopvut | Didn't happen in trunk either. |