| 00:04.06 | *** join/#asterisk-dev outtolunc (n=me@c-67-170-211-86.hsd1.ca.comcast.net) |
| 00:06.09 | *** join/#asterisk-dev RoyK (n=roy@ip-137-59-149-91.dialup.ice.no) |
| 00:23.51 | *** part/#asterisk-dev mog (n=mog@c-68-62-219-86.hsd1.al.comcast.net) |
| 00:26.55 | *** join/#asterisk-dev stevie_ramjet (n=putnopvu@c-71-228-178-34.hsd1.al.comcast.net) |
| 00:26.55 | *** mode/#asterisk-dev [+o stevie_ramjet] by ChanServ |
| 00:34.05 | *** join/#asterisk-dev schmooze (n=schmooze@rrcs-67-52-210-44.west.biz.rr.com) |
| 00:34.49 | *** join/#asterisk-dev asdx (n=diego@adsl-133-186.click.com.py) |
| 00:55.39 | *** join/#asterisk-dev RoyK (n=roy@ip-137-59-149-91.dialup.ice.no) |
| 00:57.10 | *** part/#asterisk-dev RoyK (n=roy@ip-137-59-149-91.dialup.ice.no) |
| 01:13.08 | *** join/#asterisk-dev mog (n=mog@c-68-62-219-86.hsd1.al.comcast.net) |
| 01:13.08 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 01:23.05 | asdx | what is res_telepathy? |
| 01:23.42 | *** join/#asterisk-dev RoyK (n=roy@ip-137-59-149-91.dialup.ice.no) |
| 01:24.01 | tzafrir_laptop | asdx, if you have it, you should know |
| 01:24.32 | asdx | tzafrir_laptop: i don't know, that's why i ask |
| 01:26.46 | asdx | "Telepathy, from the Greek ????, tele meaning "distant" and ??????, patheia meaning "to be affected by",[2] describes the purported transfer of information on thoughts or feelings between individuals by means other than the five classical senses (See Psi)." |
| 01:27.20 | asdx | transfer of information |
| 01:27.50 | tzafrir_laptop | Right. And there's yet no such channel in Asterisk. |
| 01:28.18 | tzafrir_laptop | Thus noone here is able to guess what you think and you should write it clearly |
| 01:28.45 | tzafrir_laptop | (that's it. Nothing more to it) |
| 01:29.34 | asdx | hm |
| 01:30.22 | tzafrir_laptop | And then again, Psi is a nice Jabber client |
| 01:31.34 | tzafrir_laptop | And Telepathy is also a new IM/VoIP framework - http://en.wikipedia.org/wiki/Telepathy_%28software%29 |
| 01:32.27 | asdx | yeah |
| 01:33.13 | asdx | cool |
| 01:35.16 | *** part/#asterisk-dev RoyK (n=roy@ip-137-59-149-91.dialup.ice.no) |
| 01:37.52 | asdx | kde4 uses it in decibel, and nokia also... afaik |
| 01:40.09 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23) |
| 02:02.52 | *** join/#asterisk-dev obnauticus (n=obnautic@c-67-160-181-107.hsd1.wa.comcast.net) |
| 02:10.13 | asdx | would like to see asterisk kicking fs ass |
| 02:33.38 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 02:33.38 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 02:37.58 | *** join/#asterisk-dev De_Mon (i=de_mon@fl-71-55-24-227.dhcp.embarqhsd.net) |
| 02:44.53 | file | diegoviola: can you please stop leaving extremely rude comments on my blog? |
| 02:45.09 | diegoviola | yes |
| 02:45.11 | diegoviola | sorry |
| 02:46.05 | file | if you believe so strongly in Freeswitch then I would suggest focusing your efforts on progressing that project |
| 02:49.29 | russellb | diegoviola: you're doing it to file, too? after I already said something about that earlier today? |
| 02:49.36 | russellb | file: was it within the last say, 8 hours? |
| 02:49.40 | file | russellb: no |
| 02:49.42 | russellb | ok. |
| 02:49.44 | file | it was yesterday |
| 02:49.59 | file | russellb: that reminds me, I'm working on mail on quark |
| 02:50.02 | diegoviola | sorry guys, it wont happen again |
| 02:50.07 | russellb | thank ou. |
| 02:50.10 | russellb | file: yay, thanks! |
| 02:50.37 | russellb | that will make my site happy. |
| 02:53.51 | russellb | i just got a comment that said "SRTP or STFU" |
| 03:02.11 | file | russellb: fixed! |
| 03:04.07 | Corydon76-dig | http://churchcrosstalk.typepad.com/jonedmiston/2008/06/asterisk-contin.html |
| 03:17.54 | diegoviola | file: i actually believe in asterisk more, sorry... didn't meant to offend anyone, i wont do it again |
| 03:29.50 | Qwell | http://yro.slashdot.org/yro/08/07/01/0141207.shtml |
| 03:32.24 | Qwell | FIOA request on Joybubbles - shows the FBI had his phones tapped in '69. heh |
| 03:32.54 | Qwell | I wonder how many of us are being watched.. :P |
| 03:33.17 | file | Qwell: I do not think you are that important... |
| 03:33.30 | Qwell | neither was Joybubbles! |
| 03:33.45 | file | so you think! |
| 03:36.25 | Corydon76-dig | If the FBI is tapping my phone, they are surely disappointed... I almost never make PSTN calls. |
| 03:36.38 | Qwell | quite |
| 04:05.05 | *** part/#asterisk-dev mog (n=mog@c-68-62-219-86.hsd1.al.comcast.net) |
| 04:14.43 | *** join/#asterisk-dev CunningPike (n=arodgers@S010600095b33697f.vc.shawcable.net) |
| 04:16.58 | *** part/#asterisk-dev diegoviola (n=diego@adsl-133-186.click.com.py) |
| 04:18.47 | *** join/#asterisk-dev CunningPike_ (n=arodgers@S010600095b33697f.vc.shawcable.net) |
| 04:40.56 | *** join/#asterisk-dev RoyK (n=roy@ip-137-59-149-91.dialup.ice.no) |
| 04:42.17 | *** part/#asterisk-dev RoyK (n=roy@ip-137-59-149-91.dialup.ice.no) |
| 05:01.20 | *** join/#asterisk-dev outtolunc (n=me@c-67-170-211-86.hsd1.ca.comcast.net) |
| 05:04.39 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 05:06.10 | *** join/#asterisk-dev fabled (n=fabled@xdsl-83-150-94-239.nebulazone.fi) |
| 05:18.46 | *** join/#asterisk-dev shtoom (n=shtoom@121.246.167.147) |
| 05:35.49 | *** join/#asterisk-dev steliosk (n=Stelios@athedsl-106428.home.otenet.gr) |
| 05:58.32 | *** join/#asterisk-dev steliosk (n=Stelios@79.131.121.52) |
| 07:04.01 | oej | Morning |
| 07:06.08 | jmls | morning oej |
| 07:23.12 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23) |
| 07:38.48 | *** join/#asterisk-dev Corydon76-dig (i=pink@pdpc/supporter/bronze/Corydon76-home) |
| 07:38.48 | *** join/#asterisk-dev elguero (n=elguero@ns1.nashuacs.com) |
| 07:38.48 | *** mode/#asterisk-dev [+o Corydon76-dig] by irc.freenode.net |
| 07:50.45 | oej | Someone removed the merge information for trunk. Ha ha. |
| 07:50.56 | oej | Will have to check that later... Back. |
| 07:51.01 | oej | Back later. |
| 07:56.53 | *** join/#asterisk-dev qdk (n=qdk@85.235.253.139) |
| 08:16.38 | *** join/#asterisk-dev oej (n=olle@80.251.192.2) |
| 08:16.38 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:44.16 | *** join/#asterisk-dev RoyK (n=roy@ip-137-59-149-91.dialup.ice.no) |
| 08:45.44 | *** join/#asterisk-dev _Vile (n=vile@208.100.152.234) |
| 08:59.37 | *** join/#asterisk-dev obnauticus (n=obnautic@c-67-160-181-107.hsd1.wa.comcast.net) |
| 09:36.13 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 09:36.13 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:36.32 | *** join/#asterisk-dev cristina_crow (n=cvintila@212.146.94.66) |
| 09:42.32 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.131) |
| 09:52.18 | oej | Fixed it. |
| 10:02.50 | *** part/#asterisk-dev cristina_crow (n=cvintila@212.146.94.66) |
| 10:11.34 | tzafrir_laptop | mvanbaak, here? |
| 10:39.18 | *** part/#asterisk-dev RoyK (n=roy@ip-137-59-149-91.dialup.ice.no) |
| 10:41.55 | *** join/#asterisk-dev cristina_crow (n=cvintila@212.146.94.66) |
| 10:42.21 | *** part/#asterisk-dev cristina_crow (n=cvintila@212.146.94.66) |
| 11:31.34 | shtoom | hi how we can set pause in asterisk dialing ? |
| 11:32.45 | tzafrir_laptop | w (half a second), at least in zap. But this is a question for #asterisk |
| 11:32.59 | shtoom | sorry wrong channel |
| 11:34.56 | shtoom | tzafrir_laptop:when we press 0 we get dialtone on our line, Dial(Zap/g0/0w${EXTEN}) would do right ? |
| 11:35.45 | tzafrir_laptop | and if one w is not enough, try ww or maybe even www |
| 11:52.40 | ctooley | oej, did you see murf's emails about the chan_sip slowdown? |
| 11:52.55 | oej | Yes. Haven't played much with 1.6 lately. |
| 11:53.06 | oej | Seems to be a serious issue though. |
| 11:53.28 | oej | Has anyone tested if it's only chan_sip or if it affects other VoIP channels as well? I think that would be a logical thing to test. |
| 11:54.06 | ctooley | Yeah, I just don't have any way to really test the other VoIP types here. |
| 11:54.37 | ctooley | I can crank up hundreds of concurrent calls through SIP, but we don't do much else. |
| 11:55.24 | oej | Can do that too. But in order to help murf, we need to figure out if this is in chan_sip or the core. |
| 11:56.25 | ctooley | yeah, I just don't even know how to simulate IAX, 323, or skinny calls the way I do SIP calls with sipp |
| 11:57.16 | ctooley | Since the same lock and unlock occurs in the 1.4 version of chan_sip, I'd guess that it has to be in core. |
| 11:57.30 | oej | Yep |
| 11:57.45 | oej | As we scale up on new systems, we will run into a lot of issues with locks, threads and ethernet drivers |
| 11:58.39 | ctooley | I do have some customers that use IAX, but very low volumes and they tend not to have lab environments. |
| 11:58.57 | *** join/#asterisk-dev awk (n=awk@security.web.za) |
| 11:59.57 | ctooley | the only way I can think to do it would be to spawn calls via manager commands from another Asterisk box, but that doesn't really test it to the same level. |
| 12:00.40 | ctooley | I suppose I could get our IT team to set up 5 or 6 boxes and slam 1 box from all the others. |
| 12:08.02 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 12:08.02 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 12:08.48 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:19.59 | *** join/#asterisk-dev shido6 (n=shido6@209.114.208.192) |
| 12:31.17 | ctooley | An interesting little tidbit. I get about 30 calls per second (after 5 runs of each type) improvement by switching to the Hoard memory allocator. |
| 12:33.30 | ctooley | makes exactly zero claim to know why this would be the case though. |
| 12:35.27 | russellb | ctooley: yay :) |
| 12:35.57 | russellb | basically, it should help a lot on SMP systems in setups that involve a lot of malloc/free |
| 12:36.25 | russellb | realtime configuration ... chanspy/mixmonitor ... anything iax2 ... |
| 12:36.26 | ctooley | you mean like setting up and tearing down a lot of calls on a 4 way box. :) |
| 12:36.36 | russellb | and yes, lots of call setups :) |
| 12:37.24 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177582944.dsl.bell.ca) |
| 12:37.42 | ctooley | I went from 130 to 160 calls/second stable throughput on trunk with codefreeze-lap 's change to comment out the channel lock/unlock. |
| 12:37.51 | ctooley | going to run the same tests on our 1.4 build |
| 12:39.52 | ctooley | BTW we're not stable at 280 cps on 1.4 |
| 12:39.56 | ctooley | without hoard |
| 12:41.08 | russellb | if you documented this stuff and posted it on a web site you wanted people to go too, you would get mad crazy traffic |
| 12:41.42 | ctooley | I'm going to post it to simplified |
| 12:42.03 | russellb | cool :) |
| 12:43.45 | ctooley | awesome, over 300cps |
| 12:44.22 | ctooley | still seems to break down between 300-310 calls per second |
| 12:45.14 | russellb | that's still a nice little boost, for basically not doing any work to improve the code :) |
| 12:45.54 | russellb | concurrent calls would also be interesting |
| 12:46.18 | russellb | for just SIP to SIP, I doubt it would make much of a difference, though |
| 12:47.31 | seanbright | ctooley: are you just doing the LD_PRELOAD magic? |
| 12:47.38 | seanbright | ctooley: or are you linking hoard in? |
| 12:47.45 | ctooley | LD_PRELOAD |
| 12:47.55 | seanbright | cool |
| 12:48.34 | ctooley | russellb, as soon as we get our proxy in place I will be able to post more specific results on concurrent call capacities. |
| 12:49.06 | russellb | cool :) |
| 12:49.09 | ctooley | right now it's too big of a pain in the butt to redistribute load balancing to push more calls to one server or another. |
| 12:49.48 | russellb | you're not ... doing this with live traffic, are you? :) |
| 12:55.57 | *** join/#asterisk-dev jeffg (i=YU8XxyB7@pdpc/supporter/active/jeffg) |
| 12:56.20 | ctooley | <grin>Why no, of course not</grin> |
| 12:57.05 | ctooley | Actually, the tests I'm running now, no. We don't need to. |
| 12:57.43 | ctooley | Building a call flow diagram in a wiki is a PITA |
| 12:58.02 | ctooley | "I want monospaced text!" |
| 12:59.43 | russellb | yeah. |
| 12:59.54 | russellb | does it have like ... <code> ? or, <pre> ? |
| 13:00.02 | ctooley | don't know. Trac. |
| 13:00.57 | ctooley | found it. |
| 13:00.59 | ctooley | http://simplified.org/trac/wiki/GriffinRoutingEngine |
| 13:01.18 | ctooley | Trac needs a blog plugin... |
| 13:01.21 | russellb | http://trac.edgewall.org/wiki/WikiFormatting |
| 13:01.21 | ctooley | goes in search... |
| 13:01.29 | seanbright | great domain name |
| 13:02.02 | ctooley | a Trac Blog Plugin.... hmmm I wonder what "TracBlogPlugin" does? :) |
| 13:02.04 | russellb | that page shows how to use monospace |
| 13:02.27 | seanbright | ctooley: it's a trap! |
| 13:02.28 | ctooley | russellb, yeah, I found it. We have the same thing docs on the simplified site as part of the Trac installation. |
| 13:02.35 | russellb | ah |
| 13:02.50 | ctooley | but the first time I tried it, it didn't work. |
| 13:03.02 | ctooley | apparently {{{ }} isn't the same as {{{ }}} |
| 13:03.24 | ctooley | And firefox's editor doesn't have the same fancy brace matching as vim. |
| 13:07.09 | ctooley | seanbright, apparently you're right, it is a trap. I can either upgrade my Trac installation to the current version and switch to FullBlogPlugin, or I can not do the Trac upgrade and install TracBlogPlugin and it's myriad of dependencies. If I do option 1 there's a huge time sink, and if I do option 2 there's a smaller time sink with no forward path. :( |
| 13:07.48 | seanbright | ctooley: ugh |
| 13:07.54 | seanbright | mediawiki is where it's at |
| 13:08.03 | *** join/#asterisk-dev anonymouz666 (n=anonymou@200.218.193.6) |
| 13:08.24 | ctooley | We use Trac for other things besides just the wiki, and we've done some "additions" to it. |
| 13:08.29 | seanbright | ah |
| 13:08.41 | seanbright | i need to set up a blog |
| 13:08.44 | seanbright | i keep meaning to |
| 13:09.35 | *** join/#asterisk-dev dwayne (n=dwayne@76.29.245.9) |
| 13:11.14 | ctooley | upgrade it is. :( |
| 13:13.22 | seanbright | this make_linker_eo_script stuff is voodoo |
| 13:15.56 | russellb | if enough people set up a blog, then i can probably justify getting someone around here to set up planet.asterisk.org |
| 13:16.01 | *** join/#asterisk-dev shido6 (n=shido6@209.114.208.192) |
| 13:16.22 | seanbright | hot |
| 13:16.58 | russellb | yes, it would be hawt. |
| 13:18.04 | dwayne | roasts marshmallows on the hawtness |
| 13:18.10 | russellb | you can be a guest poster on mine if you want :-p |
| 13:18.30 | seanbright | moi? or dwayne? |
| 13:18.43 | russellb | both |
| 13:19.20 | seanbright | i'll try to think of something to post about :) |
| 13:19.28 | codefreeze-lap | ctooley: any progress since yesterday? |
| 13:19.36 | ctooley | codefreeze-lap, well, yes, and no |
| 13:19.48 | Corydon76-dig | russellb: now that he has committer privs, shouldn't he be able to blog already on asterisk.org ? |
| 13:19.50 | ctooley | progress on identifying the actual issue, no. |
| 13:20.32 | Corydon76-dig | That was the original intent... all developers would have the ability to post blogs on asterisk.org |
| 13:20.42 | ctooley | yay! upgrading Trac completely broke our re-themeing of it. |
| 13:20.50 | Corydon76-dig | (and have the @asterisk.org email alias) |
| 13:20.56 | tzafrir_laptop | the asterisk tarball includes .moduleinfo and other files that are deleted on 'make dist-clean' |
| 13:21.29 | russellb | yeah ... except the blog stuff on asterisk.org is pretty terrible. |
| 13:21.38 | russellb | but yeah. |
| 13:21.39 | russellb | :) |
| 13:21.51 | tzafrir_laptop | Thus dpkg complains that those are missing when building a package |
| 13:22.05 | ctooley | codefreeze-lap, anyway, back to your query.... I have not made any progress in determining the slowdown, but as I was discussing with russellb and seanbright earlier, I have run the tests several times using libhoard.so as the memory allocator and that does speed things up. |
| 13:23.28 | codefreeze-lap | ctooley: by how much? |
| 13:23.47 | ctooley | 130 cps to roughly 160 cps |
| 13:23.51 | ctooley | not enough |
| 13:24.06 | ctooley | our 1.4 build went from 280 cps to around 300 cps. |
| 13:29.11 | codefreeze-lap | ctooley: I've been thinking. |
| 13:29.18 | codefreeze-lap | still am. |
| 13:29.38 | ctooley | codefreeze-lap, that's good, means you're still alive. |
| 13:30.07 | codefreeze-lap | did I say thinking? Perhaps "plotting", "scheming", etc are also appropriate... |
| 13:30.18 | ctooley | ok... |
| 13:30.41 | ctooley | does this involve providing you with a VPN key so you can "plot" tests? :) |
| 13:30.53 | codefreeze-lap | lol, no |
| 13:30.59 | ctooley | darn |
| 13:31.09 | codefreeze-lap | I'm sure I can duplicate things here. |
| 13:31.57 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 13:33.26 | snuff-home | notices murf eyeing off pvt locks in speed quest |
| 13:33.56 | codefreeze-lap | I want to get back the 400 cps I had on my test machine, ctooley. From the sounds of it, that mean around 1200 cps on your machine. |
| 13:34.24 | codefreeze-lap | w/o libhoard |
| 13:35.02 | ctooley | codefreeze-lap, Did you happen to read oej's comments from above about checking to see if that same change effected other channel types? If so, it really has to be a core thing. |
| 13:35.20 | ctooley | I'd really like to get there too, for that matter 400cps would be great. |
| 13:35.32 | codefreeze-lap | If you want a little fun, check out revision.... |
| 13:35.53 | codefreeze-lap | makes shuffling sounds as he searches his notebook.... |
| 13:37.32 | ctooley | codefreeze-lap, I suppose to could do the tedious task of starting where the performance was good, and then start incrementing revisions to try to find the "not so good" performance to see what causes it. |
| 13:37.56 | ctooley | But, I have a feeling it's going to be in some commit that's a massive change. That's how my luck runs. |
| 13:39.52 | codefreeze-lap | ctooley: yes, I spent some time charting every revision made to my branch from Jan to Apr, over a hundred; but I have the rev # on my branch... here it is: 95623 |
| 13:39.57 | codefreeze-lap | and the branch is |
| 13:40.02 | oej | Corydon76-dig: Have a minute? |
| 13:40.07 | codefreeze-lap | makes more shuffling noises |
| 13:40.45 | oej | Will shuffling your computers help speeding up the core? |
| 13:40.52 | oej | Cool feature. |
| 13:41.06 | codefreeze-lap | team/murf/bug11210, I *think* -- let me check that out |
| 13:41.11 | ctooley | unfortunately that will probably have to wait until Thursday. I took Thursday off and I could spend some of it on Asterisk work. |
| 13:41.11 | Corydon76-dig | oej: yep |
| 13:41.51 | ctooley | I have to get my calling card billing project done and I have now broken the simplified.org site, so I have to get that back up. :( |
| 13:41.56 | codefreeze-lap | oej: shuffle implies "slow", especially at *my* age! |
| 13:42.25 | codefreeze-lap | ctooley: OK, good luck... |
| 13:43.23 | ctooley | codefreeze-lap, Sorry, I'm very willing to help though. |
| 13:44.54 | wwalker | ctooley: want me to fic trac? |
| 13:45.31 | oej | corydon76-dig: Please check 12215. I need your input on that. |
| 13:46.26 | ctooley | wwalker, it's not a terrible thing, just lost the theme in the upgrade. |
| 13:46.27 | Corydon76-dig | oej: putnopvut has actually been working on a similar issue |
| 13:46.29 | ctooley | almost have it working. |
| 13:46.32 | codefreeze-lap | Hmmm. http://svn.digium.com/view/asterisk/team works fine, but http://svn.digium.com/view/asterisk/team/murf won't reply! |
| 13:47.04 | ctooley | codefreeze-lap, didn't anyone tell you? you're not part of the "team" anymore. :) |
| 13:47.18 | codefreeze-lap | guess not! |
| 13:48.31 | Corydon76-dig | russellb: is someone spidering carolina again? bugs is awfully slow today |
| 13:49.22 | russellb | unknown |
| 13:49.34 | oej | Is putnopvut around? |
| 13:49.44 | Corydon76-dig | I just got a 30 second timeout while adding a relationship |
| 13:50.02 | oej | Corydon76-dig: I have a gut feeling that the patch doesn't fix the problem, but the symtoms... |
| 13:50.12 | file | Corydon76-dig: normal traffic levels |
| 13:50.13 | Corydon76-dig | oej: see related issue 7403 |
| 13:50.22 | file | Corydon76-dig: did the issues have a lot of notes/watchers? |
| 13:50.30 | Corydon76-dig | probably |
| 13:50.37 | file | that would be oit. |
| 13:50.43 | file | erm it |
| 13:51.06 | Corydon76-dig | both are SIP issues, so yeah |
| 13:52.42 | ctooley | <PROTECTED> |
| 13:52.59 | ctooley | not a "lot" of watchers, but quite a few notes |
| 13:54.25 | Corydon76-dig | ctooley: look at the related issue 7403, though |
| 13:56.19 | Corydon76-dig | bbryant: ping |
| 13:59.29 | *** join/#asterisk-dev mbranca (n=matteo@81.208.92.210) |
| 14:00.15 | *** join/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 14:07.11 | ctooley | cool: http://www.simplified.org/trac/blog |
| 14:08.18 | ctooley | now.... 1) make blog entries 2) wait on google to spider it 3) ??? 4) profit. |
| 14:13.36 | *** join/#asterisk-dev mbranca (n=matteo@81.208.92.210) |
| 14:25.42 | codefreeze-lap | ctooley: reviewing my notes; It may be that 103695 is the better version... of the bug11210 stuff, I mean |
| 14:25.57 | ctooley | codefreeze-lap, ok |
| 14:26.37 | codefreeze-lap | and if I could get into the svn view stuff, I might be able to verify that! |
| 14:27.27 | ctooley | Just sent an email to myself and wwalker as a reference for checking out |
| 14:27.36 | codefreeze-lap | mutters under breath at the non-responsive web site |
| 14:29.15 | *** part/#asterisk-dev dwayne (n=dwayne@76.29.245.9) |
| 14:48.35 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 14:48.35 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:50.33 | *** join/#asterisk-dev sruffell (n=sruffell@216.207.245.1) |
| 14:50.33 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:54.38 | russellb | putnopvut: oej was looking for you earlier |
| 14:54.56 | bbryant | Corydon76-dig: pong |
| 14:55.54 | putnopvut | oej: still around? |
| 14:56.00 | oej | Yes. |
| 14:56.22 | putnopvut | oej: cool, what is it you wanted to talk about earlier? |
| 14:56.31 | oej | I was looking at issue 12215 and Corydon said you had your head around that. |
| 14:56.43 | russellb | M12215 |
| 14:56.52 | MuffinMan | [new] [Asterisk] Channels/chan_sip/General 0012215: Asterisk returns 482 Loop Detected upon receiving re-invite reported by jpyle (Karma: neutral) http://bugs.digium.com/view.php?id=12215 |
| 14:57.14 | putnopvut | Hmm, I haven't looked at that issue specifically, but I have been working on 7403. |
| 14:57.16 | putnopvut | M7403 |
| 14:57.20 | oej | I don't think it's related to 7403 at all... |
| 14:57.27 | putnopvut | Yeah, I'm not sure it is either. |
| 14:57.33 | oej | And there's a lot to discuss around 7403... |
| 14:57.45 | MuffinMan | [ready for testing] [Asterisk] Channels/chan_sip/General 0007403: [patch] allow SIP Spiral to work instead of causing a '482 Loop Detected' condition reported by stephen_dredge (Karma: +1.00) http://bugs.digium.com/view.php?id=7403 |
| 14:58.38 | putnopvut | I have uploaded a patch for 7403 which will handle the most common spiral scenario as I know it. That is, an INVITE from Asterisk goes to a proxy which then changes the RURI and sends the INVITE back to Asterisk. |
| 14:59.08 | jsmith | putnopvut: Oooh! |
| 14:59.29 | putnopvut | jsmith: test, test, test! |
| 14:59.35 | putnopvut | :) |
| 15:00.21 | jsmith | putnopvut: I don't have the test setup I used to... but I'll ask a friend to test it |
| 15:00.29 | putnopvut | jsmith: wonderful! |
| 15:00.32 | putnopvut | Thanks |
| 15:00.36 | oej | putnopvut: Yes, I saw the code. Good work. What happens if we get five INVITE's back to us? |
| 15:00.59 | oej | With the same r-uri? |
| 15:01.15 | putnopvut | oej: If they have the same r-uri, then we'll send a 482 just as before. |
| 15:01.39 | oej | But if the via has changed, we should not... |
| 15:01.50 | oej | At least it's a small step forward. |
| 15:02.06 | putnopvut | Exactly. Like I said, I was just trying to solve the most common scenario as I knew it. |
| 15:02.21 | oej | That URI parsing function you made should be more generic so we can use it just for URI parsing. We know have two of them. |
| 15:03.19 | putnopvut | oej: I thought the same thing. Once the patch has been tested more (just to make sure there aren't any critical flaws), I can work on integrating it more with the rest of chan_sip. |
| 15:04.50 | oej | yes, there's some really good changes we can do with that code. |
| 15:08.49 | russellb | yay putnopvut |
| 15:10.06 | russellb | oej: thanks a lot for your help on bugs today :) |
| 15:11.39 | oej | russellb: It's only fun. Had to do something else and found a lot of open issues. |
| 15:12.01 | oej | It surprises me that I find issues from april that no one has added a comment on. Are we short of bug marshals again? We should at least respond. |
| 15:12.18 | russellb | yes, we are very short on resources for the bug tracker |
| 15:14.17 | file | very very short |
| 15:14.32 | russellb | there are people in here that have been a great help |
| 15:14.43 | russellb | but we're still short for keeping up |
| 15:14.45 | seanbright | tzafrir_laptop: should ifup-hdlc be in the dahdi/tools project somewhere? |
| 15:15.04 | russellb | part of that is because we have been putting digium resources into attacking longer-term really old issues |
| 15:15.10 | russellb | like putnopvut's time going into the SIP spiral issue |
| 15:15.18 | russellb | instead of knocking out smaller/newer ones |
| 15:15.25 | russellb | but it'll help in the long run |
| 15:15.43 | oej | We need an administrator that can manage and not try to solve the issues |
| 15:15.47 | oej | Like the old bug marshals. |
| 15:15.51 | russellb | nods |
| 15:15.56 | oej | So that everyone gets a response |
| 15:16.47 | oej | It's embarrassing that people try to help us with bug reports and patches and get silence... |
| 15:16.53 | oej | I am sure you agree |
| 15:17.21 | ctooley | is shamed into going in search of bugs he can help with. |
| 15:17.35 | file | I had bbryant add a filter that will show issues that are in new and have no note, to make sure we at least add a note to say we are going to get to it |
| 15:18.39 | russellb | sure, I agree |
| 15:18.46 | russellb | if only resources grew on trees :) |
| 15:19.28 | russellb | i guess we could start a new bug marshal campaign, heh |
| 15:19.36 | russellb | of course, doing that takes time, which we still don't have |
| 15:20.02 | oej | Well, we have jtodd :-) |
| 15:20.14 | oej | He could work on that. As if he had plenty of free time... |
| 15:20.22 | russellb | right |
| 15:20.27 | russellb | and it is something he is _very_ interestd in |
| 15:20.33 | jsmith | oej: Right... I *had* his job |
| 15:20.34 | russellb | and much more likely to be able to help with post-astricon |
| 15:20.39 | oej | At least we could blame him that we haven't got a large group of bug marshals. |
| 15:20.45 | oej | Or even better, blame jsmith. |
| 15:20.53 | oej | He could find bug marshals amongst his students |
| 15:21.00 | jsmith | takes the blame, and runs off to sulk in the corner |
| 15:21.10 | russellb | jsmith: i don't blame you :) |
| 15:21.14 | russellb | i dont' blame anyone. |
| 15:21.26 | file | a large group of people would be nice... overall everyone wouldn't have to do too much... if it was large enough |
| 15:21.26 | russellb | i blame myself, more than anything |
| 15:21.38 | seanbright | so besides kpfleming and tzafrir_laptop, who is the resident dahdi expert? |
| 15:21.40 | russellb | file: throwing people at a problem doesn't usually solve it :) |
| 15:21.47 | jsmith | has actually tried to help out in the bug tracker over the past few days |
| 15:21.47 | russellb | seanbright: you |
| 15:21.49 | file | russellb: you and your logic |
| 15:21.52 | seanbright | throws russellb at a problem |
| 15:22.02 | russellb | has enough problems |
| 15:22.08 | seanbright | tell us about it |
| 15:22.10 | seanbright | ba dum dum |
| 15:22.28 | oej | I need to start working on my own SIP issues .... |
| 15:22.38 | *** join/#asterisk-dev I-MOD (n=I-MOD@c-68-62-216-5.hsd1.al.comcast.net) |
| 15:22.51 | seanbright | was just joking |
| 15:22.56 | oej | Have a rewrite of the outbound proxy code with failover, that will replace the failover branch too... |
| 15:23.11 | russellb | neat |
| 15:23.27 | file | become a bug marshal and get a muffin! |
| 15:23.35 | *** join/#asterisk-dev Deeewayne (n=Deeewayn@216.207.245.1) |
| 15:23.35 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 15:23.39 | file | (some restrictions apply, only valid in Guam) |
| 15:24.32 | oej | What do we do with bug reports that require large architecture changes to fix? Way too much. |
| 15:25.02 | oej | Like the bug report on transfer() and SIP. It's caused by the pbx transfer() function being badly architectured. To fix that requires a major rewrite. |
| 15:25.09 | ctooley | oej, if you need some help testing the failover branch, I've got a bigger lab for testing that stuff no. |
| 15:25.24 | oej | ctooley: cool stuff. Will come back to you. |
| 15:26.43 | ctooley | We now have a complete Veraz lab environment as well as asterisk simulating Veraz environment (although without failover capabilities as Asterisk doesn't do that). |
| 15:26.46 | *** join/#asterisk-dev jameswf-home (n=james@dsl093-157-131.phx1.dsl.speakeasy.net) |
| 15:27.02 | ctooley | And we can generate calls through and get traces from multiple places for debugging issues. |
| 15:29.34 | jameswf-home | s |
| 15:30.04 | oej | ctooley: That is an amazing lab. |
| 15:30.35 | ctooley | We shouldn't have ever been without it. The number of products, changes, and new code releases we were doing without it was mind-numbingly stupid. |
| 15:31.23 | ctooley | Besides, Griffin required a lab, it has the ability to take down our entire network when we deploy it if we do it wrong. |
| 15:32.34 | ctooley | oej, russellb, codefreeze-lap our griffin02 test box has been running a 100M call test job at 50 calls/sec for a couple weeks |
| 15:32.44 | ctooley | no asterisk lockups, no crashes, no hung channels |
| 15:32.49 | ctooley | thankfully. |
| 15:33.19 | JerJer | yet the freeswitch FUD bloggers would make you think differently |
| 15:33.39 | *** part/#asterisk-dev I-MOD (n=I-MOD@c-68-62-216-5.hsd1.al.comcast.net) |
| 15:33.59 | russellb | ctooley: you should blog that when it's done :) |
| 15:34.00 | ctooley | shrugs |
| 15:34.04 | russellb | ctooley: and i will linkify it! |
| 15:34.30 | ctooley | russellb, it's not like it's really a environment many people will run, there's no RTP |
| 15:34.53 | Corydon76-dig | bbryant: I noticed that when you add a relationship between two issues, it marks one of the issues as updated and doesn't mark the other as updated (or vice-versa, removing a link) |
| 15:37.36 | russellb | ctooley: ssshhhh |
| 15:38.07 | ctooley | russellb, I could some some more impressive results from our prepaid system though. :) |
| 15:38.57 | russellb | dooo ittttt |
| 15:39.37 | ctooley | hmmmm isn't there a way to show the number of calls that a server has handled? |
| 15:39.45 | ctooley | or is that only with --enable-dev-mode? |
| 15:39.45 | Corydon76-dig | bbryant: even though it notifies the watchers of both issues that a link has been added |
| 15:39.51 | kpfleming | seanbright: hey, thanks for the dahdi makefile fix... i banged my head against the wall for a while and never figured it out |
| 15:40.01 | Qwell | ooo, I was going to mention |
| 15:40.06 | Qwell | I wonder if that'll fix my DESTDIR problem |
| 15:40.17 | Qwell | I should...test |
| 15:41.57 | Qwell | nope ;/ |
| 15:42.06 | Qwell | make[1]: *** No rule to make target `dahdi-fw-oct6114-064-1.05.01.tar.gz', needed by `hotplug-install'. Stop. |
| 15:42.27 | kpfleming | that is the same problem it had before |
| 15:42.38 | Qwell | make DESTDIR=`pwd`/blah install |
| 15:42.50 | tzafrir_laptop | any chance to make that download earlier than install time? |
| 15:42.58 | bbryant | Corydon76-dig: should be fixed |
| 15:43.04 | bbryant | in theory |
| 15:43.30 | kpfleming | tzafrir_laptop: there used to be a way to do it... it's on my list to get resolved before we make the first -rc tarball (hopefully today) |
| 15:45.56 | JerJer | is there some other way to upgrade the firmware on the asterisk appliance? (superiaxy) |
| 15:46.16 | JerJer | it always just hangs when i use the web interface method |
| 15:46.37 | JerJer | then again this is one from quite a while ago |
| 15:47.09 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 15:47.44 | kpfleming | yes, if you can ssh into there is a script that can download firmware via TFTP |
| 15:48.01 | kpfleming | it can also be done using the console serial port, but that's harder |
| 15:48.54 | ctooley | Does the appliance happen to have OpenVPN on it? |
| 15:49.03 | kpfleming | no |
| 15:49.43 | ctooley | bummer. I need to find something that I can use to connect to our network. Would have been a good reason to justify them getting me an appliance |
| 15:53.49 | *** join/#asterisk-dev IgorG (n=IgorG@host-90-188-188-119.pppoe.omsknet.ru) |
| 15:59.12 | oej | JerJer: Agree. FS FUD is all around now. |
| 16:01.04 | oej | ctooley: SNOM phones can connect over OpenVPN. |
| 16:01.27 | ctooley | yeah, now that they're complaining about my cell phone bill maybe they'll get me one. :) |
| 16:06.56 | Corydon76-dig | oej: 'sokay. People don't seem to be paying attention to the FUD. I wonder how many have tried FS and went back to Asterisk |
| 16:07.56 | oej | Corydon76-dig: Lost my first project to FS the other week. People who believed and used asterisk years ago took a big risk too. There are people willing to do that today with FS. We wouldn't have gotten anywhere without them... |
| 16:09.09 | Corydon76-dig | oej: give them 6 months |
| 16:09.19 | oej | But I still wonder how they can push 3000 calls through the same IP stack and ethernet interface as we use... And we can't come up above 900 with the p2p bridge... |
| 16:09.34 | ctooley | We had a project that we were told FS would be a better fit for. In the course of investigating the solution, it turned out that FS couldn't act in any other way than a B2BUA, which defeated the purpose of investigating an alternative solution. Turned out to be a pointless time. |
| 16:09.37 | Corydon76-dig | I have to wonder if the FUD is meant to get a reaction, where the reaction trumps every other push they've made in the past 2 years |
| 16:10.25 | ctooley | oej, I keep hearing those kinds of numbers, but we threw a lot of money and weight behind the project I just talked about and we never could get anyone to demonstrate anything better than what I can do with Asterisk on the same server. |
| 16:10.37 | kpfleming | oej: we get almost that many calls (900) including transcoding on an 8-core box here, i wonder why you can't get more without any media transcoding |
| 16:11.00 | oej | kpfleming: The ethernet card blew away one of our eight cores. |
| 16:11.02 | ctooley | We can push well over 1K on a single server |
| 16:11.29 | ctooley | but, we do it by breaking up the traffic across multiple instances on a single box. |
| 16:11.36 | oej | One core went up to 100% and call quality dropped totally around 900 calls. We could push over 1000 calls (2000 channels) but with bad quality |
| 16:11.47 | oej | So 900 calls is 1800 channels in chan_sip and the core |
| 16:12.03 | oej | ctooley: And multiple ethernet interfaces I guess? |
| 16:12.04 | ctooley | We run into massive CPU overhead traversing lists as the channel count climbed |
| 16:12.07 | ctooley | oej, nope |
| 16:12.09 | russellb | well, i think it was 900 channels, using g729 transcoding |
| 16:12.53 | oej | 900 channels != 900 calls with two legs... :-) |
| 16:13.26 | oej | Anyway, the problem we're facing is the ethernet drivers. We changed ethernet card and could go from below 800 to 900 calls. |
| 16:14.18 | ctooley | We have modded the sip call limit stuff to only "block" on inbound legs (actually bounces back with a response that route advances in our switch), set them the call limits to 400 and run 4 instances per server |
| 16:14.54 | ctooley | (by block, I mean we only increment/decrement inbound legs) |
| 16:15.11 | ctooley | We can actually get better performance out of 8 instances per server, but we start losing ground on the memory consumption front |
| 16:15.22 | oej | ctooley: You could use "maxcalls" as well. |
| 16:15.24 | ctooley | core and everything else start eating up more memory than we gain in performance |
| 16:15.27 | kpfleming | but memory is dirt cheap |
| 16:16.05 | russellb | oej: if you got the load on one CPU, i think there is some support for distributing interrupts accross multiple CPUs ... can't remember if that' something you ahve to enable or what |
| 16:16.14 | ctooley | kpfleming, our call/meg ROI plateaus |
| 16:16.22 | oej | I was wondering if we could randomly pick an IP/ethernet/port for RTP and load balance over a range of ports, that would propably make it possible to push a larger number of calls. Provided they don't share IRQ. |
| 16:16.34 | ctooley | ok |
| 16:16.39 | ctooley | sorry, wrong windo |
| 16:16.53 | oej | russellb: irqbalancer was working all right, but we just had one IRQ from the ethernet card to balance... |
| 16:17.05 | ctooley | oej, We have the ability to do that, but we haven't needed to do it. |
| 16:17.53 | Qwell | russellb: iirc, it also requires some stuff in the driver for the ethernet chip |
| 16:18.10 | ctooley | Took some serious routing tricks, but we can spread RTP load across NICs based on the media gateway subnet that is being connected to. |
| 16:18.59 | ctooley | oej, additionally we've had the same experience on Intel dual port NICs (only one port being used for Asterisk) and onboard Broadcom NICs that are in our HP DL-140s |
| 16:20.27 | ctooley | One of the biggest reasons I'd love to see RTP/Audio setup more divorced from channel setup is to help alleviate some of the problems you're experiencing though. |
| 16:21.29 | ctooley | Well, that and it's pointless to spin up audio resources for channels that end up never using it. ie: We don't want to answer the call, we just transfer the call, or the call is completed with no audio anyway. |
| 16:23.29 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.131) |
| 16:25.04 | ctooley | russellb, ok, for your blogging pleasure, I've started a 100M call job running at 250cps |
| 16:25.09 | ctooley | It should be done by the end of the week. |
| 16:27.08 | russellb | hehe, yay |
| 16:27.43 | outtolunc | geez, i thought *today* was the last day for astricon discount |
| 16:28.40 | ctooley | outtolunc, yesterday I think |
| 16:29.57 | outtolunc | some reason i read it 'through july 1st' |
| 16:30.11 | outtolunc | anyways... :( |
| 16:31.02 | oej | qwell: Are you working on 8824? |
| 16:31.06 | oej | M8824 |
| 16:31.11 | Qwell | probably not |
| 16:31.36 | oej | So you won't be upset if I reassign it to me and start looking into the SIP issues there? |
| 16:31.44 | oej | skinny I leave to you... :-) |
| 16:31.53 | MuffinMan | [assigned] [Asterisk] Channels/NewFeature 0008824: [patch] Remote (called) Party Identification - chan_sip & chan_skinny implementation reported by gareth (Karma: +9.00) http://bugs.digium.com/view.php?id=8824 |
| 16:32.07 | oej | Latency on MuffinMan today |
| 16:32.12 | Qwell | oej: yeah, I'm not touching the SIP stuff there |
| 16:32.30 | putnopvut | oej: Today is Canada day. Muffinman is relaxing a bit :) |
| 16:32.34 | Qwell | mvanbaak was/is going to review the skinny part. I think Tilghman looked at the overall patch |
| 16:32.38 | oej | Ok, I'll take a look at it tomorrow and we'll discuss it tomorrow then. |
| 16:33.04 | oej | I need to read through it. There are multiple ways to handle caller ID updates in SIP (not surprising) and I need a solution to that. |
| 16:33.19 | ctooley | oej, 12941 looks like a bit odd |
| 16:33.44 | ctooley | I haven't personally seen this behavior, but if it's true, it looks like a fairly major problem. |
| 16:34.04 | putnopvut | M12941 |
| 16:34.08 | MuffinMan | [new] [Asterisk] Channels/chan_sip/Registration 0012941: Failing registrations to peer via DNS name breaks all other peers reported by btrain1227 (Karma: neutral) http://bugs.digium.com/view.php?id=12941 |
| 16:35.02 | oej | ctooley: DNS failures cause a lock when reloading. You need a local resolver until we have true asynch DNS. |
| 16:35.27 | oej | Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/insects.digium.com/core/config_api.php on line 134 |
| 16:35.30 | oej | Oops. |
| 16:35.46 | oej | That bug again. Welcome back, old friend. How many times have we fixed this? |
| 16:35.51 | oej | php.ini needs a fix. |
| 16:36.11 | ctooley | so dns failure locks until a timeout, or indefinitely? |
| 16:36.55 | oej | Yes, a DNS failure - total lack of reply or IP failure, will cause a failure when we try to resolve at reload/restart - host names in the config file. |
| 16:37.14 | anonymouz666 | using dnsmgr does not help in anything? |
| 16:37.18 | oej | That's a well known issue. If you have a local resolver, like bind, running bind will handle the failure for you. |
| 16:37.28 | oej | dnsmgr fixes other issues, but not asynch dns. |
| 16:37.35 | oej | and it causes other issues too :-) |
| 16:37.40 | ctooley | resolver should eventually timeout though |
| 16:37.53 | ctooley | causing it to move on. |
| 16:38.05 | ctooley | dns lookups do not hang forever. |
| 16:38.09 | oej | "should" yes. |
| 16:40.03 | ctooley | hmmm |
| 16:40.18 | anonymouz666 | and how complex is to code "true asynch DNS"? |
| 16:40.37 | anonymouz666 | I think 12941 affects lots of people |
| 16:40.50 | jsmith | oej: Are you seriously gonna tackle 8824? That would make my entire *week* |
| 16:43.03 | oej | Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/insects.digium.com/core/history_api.php on line 137 |
| 16:43.24 | oej | jsmith: Dead serious. It's time. |
| 16:43.29 | russellb | M8824 |
| 16:43.38 | jsmith | oej: Oh happy day! |
| 16:43.38 | oej | Can someone fix php.ini on bugs? |
| 16:43.54 | jsmith | oej: I'd be happy to test on every device I can get my hands on, once you feel the patch is ready for testing |
| 16:44.10 | MuffinMan | [assigned] [Asterisk] Channels/NewFeature 0008824: [patch] Remote (called) Party Identification - chan_sip & chan_skinny implementation reported by gareth (Karma: +9.00) http://bugs.digium.com/view.php?id=8824 |
| 16:44.13 | oej | Great! I'm still confused on what is what in that patch. |
| 16:44.16 | jsmith | oej: (Unfortunately, I'll be on the road a lot this next month, but I'm still happy to try) |
| 16:44.19 | oej | sorry - in that bug report |
| 16:44.38 | jsmith | oej: Basically, just go with the last patch (or maybe two) on that bug... the earlier patches were, well... scary. |
| 16:44.51 | oej | jsmith: And I'll try to stay off the road and be home, working on this and other issues. Avoiding airports takes a lot of my time. |
| 16:45.07 | russellb | if someone could document the architecture side of that patch and post to -dev, that would rock |
| 16:45.10 | oej | jsmith: Ok, thanks. I'll take a look at the last one. |
| 16:45.28 | jsmith | oej: Actually, use asterisk-1.6.0-beta8-connectedline-v2.patch |
| 16:45.38 | oej | russellb: I will have to do that, since we have to change some core signalling to update caller IDs, add an AST_CONTROL message. So you will get that mail. |
| 16:45.59 | russellb | oej: yes, something like that. that would be great. |
| 16:46.07 | oej | We will have to agree on a way to say "Hey! I've changed caller ID!" for both ends of a call leg |
| 16:46.13 | russellb | exactly |
| 16:46.19 | russellb | that is what i want to officially agree on |
| 16:46.31 | russellb | and then once it works using the agreed upon architecture, it can be committed |
| 16:46.34 | russellb | and the world will be happy |
| 16:46.37 | oej | I agree that we will have to agree on those kind of changes |
| 16:46.58 | oej | ...and the universe will be glorius... |
| 16:47.29 | oej | In return, maybe someone can look at videocaps... |
| 16:47.33 | oej | he he. Couldn't resist... |
| 16:47.45 | russellb | :) |
| 16:48.28 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.131) |
| 16:49.06 | oej | These patches change a lot of things outside of the patch issue... |
| 16:49.52 | oej | I need to break it up into pieces |
| 16:52.08 | seanbright | kpfleming: no problem. i'm not entirely sure why that fixed it, but it works, so... |
| 16:52.09 | ctooley | [Jul 1 16:44:31] ERROR[30474]: rtp.c:1947 ast_rtp_new_with_bindaddr: Unexpected bind error: Bad file descriptor |
| 16:52.09 | ctooley | [Jul 1 16:44:31] WARNING[30474]: chan_sip.c:4689 sip_alloc: Unable to create RTP audio session: Bad file descriptor |
| 16:52.09 | ctooley | [Jul 1 16:44:31] WARNING[20537]: rtp.c:1140 ast_rtp_read: RTP Read error: Bad file descriptor. Hanging up. |
| 16:52.17 | ctooley | argh |
| 16:52.52 | ctooley | I might have to undertake this issue after all.... RTP is not happy with the channel living for less than 40ms. |
| 16:53.36 | Corydon76-dig | woot, I got commit 127001... |
| 16:53.37 | Qwell | Luigi put the leaning tower in his "even uglier gui". heh |
| 16:53.47 | putnopvut | heh |
| 16:53.52 | seanbright | kpfleming: also, if you have a sec, re: 12968, i'm not sure why d1mas is having that problem, but for me it fails just after trying to install ifup-hdlc. is this something i can just bring forward from the old zaptel repo? |
| 16:54.02 | Corydon76-dig | putnopvut: as in 127.0.0.1 ? |
| 16:54.09 | putnopvut | Yeah, I got it. |
| 16:54.14 | Qwell | ~pat Corydon76-dig |
| 16:54.15 | jbot | ACTION pats Corydon76-dig and says "Nicely Done!" |
| 16:54.33 | Corydon76-dig | Heh, nice |
| 16:55.05 | kpfleming | seanbright: no, leave it alone for now, i'm going to spend most of this afternoon going through open dahdi bug reports and getting the rest of the necessary bits from zaptel 1.4 copied over so we can get a release candidate out |
| 16:55.21 | seanbright | kpfleming: will do. thanks. |
| 16:57.02 | seanbright | kpfleming: and if you have any idea why my patch actually fixed the firmware install, feel free to enlighten me when you have a moment :) |
| 17:01.01 | kpfleming | i don't |
| 17:01.06 | kpfleming | it looks like a make bug |
| 17:01.28 | seanbright | yeah, just found a bunch of similar sounding problems on savannah |
| 17:02.18 | Qwell | what was the bug? |
| 17:02.40 | putnopvut | Qwell: 12967 |
| 17:03.09 | Qwell | weird |
| 17:04.16 | seanbright | ouch... gnu make has been at 3.81 for 2+ years :-/ |
| 17:04.45 | oej | Time for food. See you later. |
| 17:04.48 | Qwell | they wanted to give Etch a chance. |
| 17:05.43 | russellb | at what, being current? |
| 17:05.45 | russellb | with something? |
| 17:06.14 | Qwell | That's left up to the readers imagination. |
| 17:10.53 | *** join/#asterisk-dev KenLee (n=k3leland@bg-fw2out.monmouth.com) |
| 17:15.33 | kpfleming | ugh... 12968 is MAJOR, even though the code has never been released |
| 17:17.59 | *** part/#asterisk-dev jmls_work (n=jmls_wor@mail.tessera.co.uk) |
| 17:25.41 | *** join/#asterisk-dev file (n=file@asterisk/developer-and-muffin-lover/file) |
| 17:25.41 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 17:33.25 | kpfleming | does anyone here either have, or know anyone who has, skills at doing digital signal processing code on standard CPUs? i've got a project where i need someone to do a floating-point to fixed-point conversion on an echo canceller to go into DAHDI |
| 17:33.34 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 17:33.34 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:34.49 | seanbright | stares blankly |
| 17:35.01 | ctooley | kpfleming, wwalker might |
| 17:35.27 | Qwell | so...hmm. random thought. jsmith just reminded me of this (something completely unrelated to the topic at hand) |
| 17:35.38 | russellb | dahdi project in mantis created |
| 17:35.44 | jsmith | Qwell: I did? |
| 17:35.49 | jsmith | is all ears |
| 17:35.54 | Qwell | on some MUDs (text-based inet games), there is a command to "copyover" current code, after being rebuilt |
| 17:35.57 | kpfleming | ok, there are issues that should be moved |
| 17:36.15 | Qwell | basically, it forks the new binary, and players that were connected stay connected to the new code |
| 17:36.33 | Qwell | I wonder if something like that would be feasible at all for Asterisk |
| 17:36.48 | russellb | it has been brought up before |
| 17:36.50 | seanbright | i thought i read somewhere that asterisk had "stackable modules" |
| 17:36.55 | kpfleming | but you lose a lot of stuff |
| 17:36.58 | russellb | right |
| 17:36.59 | seanbright | or that it was "conceivable" |
| 17:37.04 | kpfleming | how can you do hints if some of the calls are in a separate instance? |
| 17:37.12 | Qwell | the old instance goes away |
| 17:37.15 | jsmith | seanbright: Asterisk has lots of modules... I wouldn't go so far as to call them "stackable" yet |
| 17:37.28 | kpfleming | oic |
| 17:37.28 | russellb | it's basically maintaining open connections even though you switch out the binary that is running |
| 17:37.30 | Qwell | I'd need to figure out how the socket connections get moved over.. |
| 17:37.32 | seanbright | jsmith :P |
| 17:37.34 | russellb | i've heard of that being done for IRCd's |
| 17:37.34 | wwalker | ctooley: kpfleming: sorry, beyond me. But I'll ask a couple of guys that used to do DSP work for Moto. |
| 17:37.39 | kpfleming | thanks |
| 17:37.41 | Qwell | russellb: yeah, same concept I guess |
| 17:37.46 | russellb | but ... asterisk has a lot more data ... |
| 17:37.51 | Qwell | granted |
| 17:38.07 | putnopvut | kpfleming: floating-point to fixed-point? I don't have the DSP experience, but I'm familiar with IEEE floating point and could potentially throw together some sort of conversion. |
| 17:38.15 | kpfleming | and how do you convert in-memory call structures to the new versions that are needed? seems impossible with our current architecture |
| 17:38.22 | Qwell | no idea |
| 17:38.27 | jsmith | russellb: Yeah... and because Asterisk is *not* stateless, it seems almost impossible |
| 17:38.31 | russellb | yeah, does seem impossible. |
| 17:38.41 | kpfleming | putnopvut: no i think the person who does this has to understand signal processing so they don't introduce subtle problems |
| 17:38.41 | tzafrir_laptop | "freeze"? |
| 17:39.51 | seanbright | what happens today if i reload app_queue.so with a dozen callers and a handful of agents going? |
| 17:39.56 | seanbright | err |
| 17:40.03 | seanbright | that was the dumbest thing i've ever said |
| 17:40.05 | seanbright | goes to the corner |
| 17:40.14 | putnopvut | seanbright: everything should be "graceful" |
| 17:44.18 | *** join/#asterisk-dev jeffg (i=YU8XxyB7@pdpc/supporter/active/jeffg) [NETSPLIT VICTIM] |
| 17:45.29 | seanbright | putnopvut: so it actually reloads the .so? or just re-reads the conf? |
| 17:45.41 | seanbright | and yes, i could just look at the code, but it's easier to ask |
| 17:45.42 | seanbright | :) |
| 17:45.59 | putnopvut | heh, a "module reload app_queue.so" just reloads the conf file. |
| 17:46.02 | kpfleming | we never reload the .so file |
| 17:46.11 | seanbright | gotcha |
| 17:46.12 | *** join/#asterisk-dev MuffinMan (n=muffinma@asterisk/issue-tracker-bot/muffinman) |
| 17:46.19 | seanbright | MuffinMan: wb |
| 17:46.32 | ctooley | kpfleming, even when an unload and subsequent load are called? |
| 17:46.40 | kpfleming | yes |
| 17:46.50 | kpfleming | in that case, of course we reload from disk |
| 17:46.56 | ctooley | that's what I thought. |
| 17:47.10 | ctooley | that of course would be fairly destructive to anything that was using it. :) |
| 17:48.14 | tzafrir_laptop | seanbright, so is the same firmware issue present in zaptel 1.4 as well? |
| 17:48.37 | seanbright | for *some* reason, when i first started working with asterisk, i remember hearing or reading something that suggested that you could load a new version of a module while it was running, and all new channels would be serviced by that module while the old ones stayed with the old module. |
| 17:48.37 | kpfleming | probably is, since i put the same makefile changes there |
| 17:49.06 | seanbright | woops. sorry. i just got access the dahdi repo and assumed i shouldn't commit to 1.4 |
| 17:49.19 | kpfleming | that is correcyt |
| 17:49.22 | ctooley | crap, after all that excitement over how well things were going.... the 1.4.19.1 build that I haven't had a deadlock on for weeks just deadlocked in __ast_read(). :( |
| 17:49.28 | kpfleming | branches/1.4 in the dahdi repo should not receive commits |
| 17:50.29 | ctooley | I guess it's time to bring the Excel tree in line with the 1.4.21.1 Digium tree. |
| 17:50.57 | seanbright | kpfleming: so should i make the corresponding change in the zaptel repo? |
| 17:50.59 | ctooley | russellb, no blogness for me today. :( |
| 17:51.09 | kpfleming | if you have access to do, yes you should |
| 17:51.15 | seanbright | i'll give it a shot |
| 17:51.37 | kpfleming | never mind... i didn't put the same changes there |
| 17:51.44 | kpfleming | so the problem does not exist there |
| 17:51.46 | seanbright | cool |
| 17:52.07 | seanbright | ah... all separate targets |
| 17:52.20 | kpfleming | yeah.. i 'improved' it :-) |
| 17:52.26 | seanbright | :) |
| 17:56.13 | *** join/#asterisk-dev jmls_work (n=jmls_wor@mail.tessera.co.uk) |
| 18:07.41 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 18:07.42 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:29.32 | tzafrir_laptop | kpfleming, any idea why those pci warnings appear on http://bugs.digium.com/12945 appears on stock 2.6.24 but not on Debian's kernel? |
| 18:29.43 | kpfleming | no |
| 18:29.54 | kpfleming | i've never looked at the differences in the header files |
| 18:37.33 | *** part/#asterisk-dev jmls_work (n=jmls_wor@mail.tessera.co.uk) |
| 18:38.54 | kpfleming | tzafrir_laptop: i *do* see them using ubuntu's kernel from hardy heron |
| 18:47.18 | *** join/#asterisk-dev qdk (n=qdk@195.242.194.42) |
| 18:47.35 | tzafrir_laptop | M12657 |
| 18:47.37 | MuffinMan | [new] [DAHDI] General 0012657: No room for chans on E1 span (insmod: page allocation failure. order:5) reported by tzafrir (Karma: +98.00) http://bugs.digium.com/view.php?id=12657 |
| 18:48.30 | tzafrir_laptop | The problem here is not to find a some 128kb, but to find an available memory block at that size |
| 18:48.59 | tzafrir_laptop | After various allocations/deallocations the memory gets fragmented |
| 18:50.38 | tzafrir_laptop | We often run into this with system of 256MB after enough loads/unloads of E1 devices |
| 18:54.03 | tzafrir_laptop | kpfleming, ==^ |
| 18:55.21 | tzafrir_laptop | hmm... the init.d script is in dahdi linux? But it needs tools |
| 18:55.58 | kpfleming | we can certainly move it |
| 18:56.02 | kpfleming | i'd be fine with that |
| 18:56.10 | kpfleming | in fact, i should have done that... will do it |
| 18:56.11 | tzafrir_laptop | there's already dahdi.init in the tools directory... |
| 18:56.21 | kpfleming | then somebody didn't finish the job |
| 19:15.01 | jpeeler | tzafrir_laptop: did you have a chance to look at the dahdi restart code? |
| 19:16.34 | jsmith | kpfleming: I noticed in your last dahdi commit that you still reference "ztcfg". Is that utility going to be renamed? |
| 19:16.39 | tzafrir_laptop | I plan to today, after I get home. Time to leave now, indeed |
| 19:17.04 | tzafrir_laptop | jsmith, it has already been renamed in the init.d script in the tools directory |
| 19:17.42 | tzafrir_laptop | It has been renamed to dahdi_cfg |
| 19:18.47 | shido6 | <PROTECTED> |
| 19:18.55 | tzafrir_laptop | generally: s/ZT_/DAHDI_/; s/zt_/dahdi_/; s/(zt|zap|zaptel)/dahdi_/; |
| 19:19.04 | shido6 | was fine once i restarted asterisk |
| 19:19.30 | jsmith | shido6: Probably a deadlock, and possibly the one fixed in 1.4.21.1... but that's just a guess |
| 19:19.36 | shido6 | heh |
| 19:54.02 | kpfleming | jsmith: that whole commit is going to get reverted and moved to the proper place (dahdi-tools) |
| 19:54.46 | jsmith | kpfleming: Works for me ;-) |
| 19:54.58 | jsmith | kpfleming: Just trying to be another set of eyes |
| 20:00.17 | jsmith | codefreeze-lap: Glad to hear this wasn't one of your teenage kids http://blog.wired.com/27bstroke6/2008/06/hacker-launches.html |
| 20:03.41 | russellb | hackers in wyoming ... makes sense |
| 20:03.44 | russellb | what else are they going to do? |
| 20:03.45 | russellb | runs |
| 20:05.41 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 20:07.42 | russellb | Corydon76-dig: so we should now be able to remove the code that emits the warning, don't you think? |
| 20:08.32 | russellb | well, i guess it doesn't hurt to leave it (except it hurts performance) |
| 20:08.46 | russellb | i realllly want to remove it, heh |
| 20:15.49 | Corydon76-dig | russellb: um, maybe |
| 20:16.13 | russellb | i guess we should wait a bit longer to see if anyone sees the message |
| 20:16.13 | Corydon76-dig | It would only ever execute if somebody was attempting to attack us, right? |
| 20:16.32 | Corydon76-dig | i.e. send us invalid packets |
| 20:16.37 | russellb | nope |
| 20:16.43 | russellb | also any time a session is being initiated |
| 20:16.51 | russellb | i.e., receiving a NEW, REGREQ, etc |
| 20:17.09 | russellb | it will fail to find an existing session, and will get to the following block of code which allocates a new pvt |
| 20:19.14 | Corydon76-dig | Oh, right |
| 20:19.49 | Corydon76-dig | or POKE or REGREL or FWDOWNL |
| 20:19.55 | russellb | right |
| 20:20.08 | russellb | i mean, it's better than doing it for every media frame :) |
| 20:20.16 | russellb | but it still gets executed a little bit |
| 20:21.14 | Corydon76-dig | russellb: how about if we make it a define that people can turn on if something stops working |
| 20:21.26 | Corydon76-dig | because most people, I think, won't need it on |
| 20:21.30 | Corydon76-dig | i.e. just in case |
| 20:22.12 | Corydon76-dig | #ifdef IAX_OLD_FIND |
| 20:22.48 | russellb | sure, that we can enable if we get a bug report or something ... |
| 20:23.12 | russellb | with what you just fixed, i'm pretty confident about it not being needed anymore |
| 20:23.37 | *** join/#asterisk-dev bkruse (n=bkruse@216.207.245.1) |
| 20:23.37 | *** mode/#asterisk-dev [+o bkruse] by ChanServ |
| 20:48.27 | kpfleming | tzafrir_laptop: pinbg |
| 20:48.36 | file | steals the b |
| 21:02.44 | snuff-home | yawns |
| 21:04.15 | putnopvut | kpfleming: commit 127113 is causing problems. Specifically, if I dial a local channel, the caller hears ringing forever and I have one-way audio (callee->caller). |
| 21:04.40 | kpfleming | is that the change i made? |
| 21:04.50 | putnopvut | Yes, the change to __ast_answer() |
| 21:05.03 | kpfleming | ok, i didn't memorize the revision number' |
| 21:05.19 | russellb | commit asterisk 127113 |
| 21:05.25 | MuffinMan | [127113] Committed by kpfleming on 2008-07-01T19:53:03.715606Z: change the process of inserting a delay into the ast_answer() path so that we don't tell the calling channel that it has been answered unutil after the delay; for a single-thread call this won't matter all, but for a dual-thread call |
| 21:05.25 | MuffinMan | ..(using chan_local) this may fix the problem in issue 12924 |
| 21:05.31 | kpfleming | so marking the channel as UP before calling ->answer is badness then |
| 21:05.55 | kpfleming | so the next possibility would be to just do the delay first |
| 21:06.14 | kpfleming | well, mark the CDR as answered first, then delay, then the rest of the stuff |
| 21:06.29 | putnopvut | kpfleming: I'll try that locally. |
| 21:06.33 | kpfleming | ok |
| 21:09.16 | putnopvut | kpfleming: I think we have a winner :) |
| 21:09.26 | kpfleming | good to hear |
| 21:12.59 | *** join/#asterisk-dev smurf (n=smurf@debian/developer/smurf) |
| 21:18.38 | *** part/#asterisk-dev smurf (n=smurf@debian/developer/smurf) |
| 21:24.58 | jsmith | Corydon76-dig: Random question... would it be helpful in the MOH AMI event to show the MOH file (and class?) that was played? |
| 21:27.26 | *** join/#asterisk-dev Deeewayne (n=Deeewayn@216.207.245.1) |
| 21:27.26 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 21:27.26 | *** join/#asterisk-dev mbranca (n=matteo@81.208.92.210) |
| 21:27.26 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 21:27.26 | *** join/#asterisk-dev _charly_ (i=kroseneg@sunrise.schmidham.net) [NETSPLIT VICTIM] |
| 21:27.26 | *** join/#asterisk-dev denon (n=denon@tooth.decay.org) [NETSPLIT VICTIM] |
| 21:27.26 | *** join/#asterisk-dev frieze (n=frieze@pool-98-113-86-28.nycmny.fios.verizon.net) [NETSPLIT VICTIM] |
| 21:27.27 | *** join/#asterisk-dev simond (n=simon@syria.uc.org) [NETSPLIT VICTIM] |
| 21:27.27 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) [NETSPLIT VICTIM] |
| 21:27.27 | *** mode/#asterisk-dev [+oooo Deeewayne putnopvut jpeeler kpfleming] by irc.freenode.net |
| 21:27.27 | *** join/#asterisk-dev bbryant (n=brett@216.207.245.1) |
| 21:27.28 | *** join/#asterisk-dev Qwell (i=north@pdpc/sponsor/digium/Qwell) |
| 21:27.28 | *** join/#asterisk-dev corramor (n=corramor@216.207.245.1) [NETSPLIT VICTIM] |
| 21:27.28 | *** mode/#asterisk-dev [+oo bbryant Qwell] by irc.freenode.net |
| 21:27.30 | Corydon76-dig | jsmith: random answer: maybe |
| 21:28.57 | russellb | class, sure |
| 21:28.59 | russellb | but the file is going to change |
| 21:29.20 | Corydon76-dig | changes file |
| 21:31.33 | russellb | heh |
| 21:35.27 | *** join/#asterisk-dev philippel (n=p_lindhe@pool-71-164-18-224.sttlwa.fios.verizon.net) |
| 21:35.50 | jsmith | Hey philippel... welcome! |
| 21:36.15 | philippel | jsmith hey |
| 21:36.22 | philippel | russellb ping |
| 21:37.20 | philippel | ok then someone else, here is the question. |
| 21:38.18 | philippel | func_devstate.c - 1.4 backport, I noticed when you stop and then restart asterisk, devices that subscribe to any hints get the proper status however 'show hints' shows the status as unavailable. Is this a bug? does it happen on 1.6 also (I don't have a 1.6 system to test)? |
| 21:39.06 | russellb | checks |
| 21:39.23 | philippel | second question related to func_devstate.c - what would one consider the proper way to keep the astb 'clean' with no longer used Custom states? |
| 21:40.08 | philippel | I noticed if I set it to nothing, it just reflects that in the database - I could delete teh database variable, but that seems to be cicumventing the system? |
| 21:40.34 | russellb | there should be a way to delete it using DBDel or whatever it is |
| 21:40.39 | russellb | and that's ok |
| 21:40.55 | russellb | as far as "show hints" goes, i guess that would be a bug |
| 21:41.09 | russellb | not sure why that would show one thing, but phones get another |
| 21:41.53 | philippel | russellb I know I can delet the database variable - but it woudl seem cleaner to keep it in the interface, so if you do someothing liek "DEVSTATE(Custom:lamp1)=" that would have the same effect? |
| 21:42.23 | russellb | it wouldn't now, but that's a good idea :) |
| 21:42.27 | philippel | russellb on the hints - yeah it had me confused, but being it's the 1.4 backport I didn't think it was appropiate to file a bug |
| 21:42.49 | russellb | right, it's not ... |
| 21:42.54 | russellb | and i don't really have time to work on it, either |
| 21:43.57 | russellb | added a todo to the module |
| 21:44.10 | philippel | russellb I wouldn't exacty consider it a high priority since the phones work, but if it still has that behavior on 1.6 it shoudl be filed until someone has time to fix the hint thing |
| 21:44.20 | russellb | nods |
| 21:44.24 | russellb | not sure if it does or not |
| 21:45.00 | philippel | well if I get a chance to test it on 1.6, I'll file it if I notice that behavior |
| 21:53.09 | russellb | thanks :) |
| 22:28.29 | *** join/#asterisk-dev qdk (n=qdk@0x573fe57e.bynqu2.broadband.tele.dk) |
| 22:29.21 | Qwell | BLAH="-a\"123 456\"" Is there some magic way to make BLAH include the quotes? |
| 22:29.58 | putnopvut | Qwell: what language? |
| 22:30.00 | Qwell | hmm, it does.. |
| 22:30.03 | Qwell | sh |
| 22:30.25 | putnopvut | I'll be quiet... |
| 22:30.48 | Qwell | this isn't doing what I want... |
| 22:33.34 | putnopvut | Qwell: which quotes are you trying to include? The inner or outer ones? |
| 22:33.50 | Qwell | inner |
| 22:34.04 | putnopvut | Could you use single quotes instead of double quotes for the outer quotes? |
| 22:34.37 | putnopvut | I know that is typically a more "literal" quotation in sh, but I don't know if that includes being able to quote double quotes or not. |
| 22:35.20 | putnopvut | The other option would be BLAH=`echo -e "-a\"123 456\""` |
| 22:36.40 | Qwell | that isn't doing it either... stupid sh |
| 22:37.21 | Qwell | somecmd ${BLAH} needs to be exactly equiv to somecmd -a"123 456" |
| 22:37.25 | Qwell | but it's not. |
| 22:39.55 | Qwell | you'd think this would be easy.. |
| 22:40.22 | putnopvut | Qwell: root@belew:/usr/src/asterisk# BLAH=`echo -e "-a\"123 456\""`; echo ${BLAH}; |
| 22:40.22 | putnopvut | -a"123 456" |
| 22:40.22 | putnopvut | root@belew:/usr/src/asterisk# |
| 22:40.39 | Qwell | BLAH technically contains \" though |
| 22:40.47 | putnopvut | yikes... |
| 22:40.50 | Qwell | yeah...heh |
| 22:41.52 | putnopvut | root@belew:/usr/src/asterisk# BLAH='-a"123 456"'; echo ${BLAH}; |
| 22:41.52 | putnopvut | -a"123 456" |
| 22:42.17 | Qwell | somecmd `echo $BLAH` doesn't appear to do it either... |
| 22:43.16 | putnopvut | Does the single-quote way also result in escaped quotation marks? |
| 22:43.38 | Qwell | huh? |
| 22:43.43 | putnopvut | What I just pasted. |
| 22:43.58 | Qwell | 456 is $(somecmd) |
| 22:44.07 | Qwell | so ' won't work |
| 22:44.15 | putnopvut | Okay, I'm totally misunderstanding what you're doing then. |
| 22:44.19 | Qwell | come look :D |
| 23:37.46 | *** join/#asterisk-dev jmls (n=jmls@host217-36-208-155.in-addr.btopenworld.com) |
| 23:40.42 | *** join/#asterisk-dev d1mas (n=chatzill@host-99.dataart.net) |
| 23:40.56 | d1mas | kpfleming : hello. are you there? |
| 23:41.05 | kpfleming | for a few minutes |
| 23:41.33 | d1mas | kpfleming : regarding 12968 - how can I avoid DAHDI if I'm installing 1.6? It does not recognize ZAP anymore... |
| 23:41.47 | kpfleming | 1.6 is not released yet |
| 23:42.07 | d1mas | (btw, you are wrong, I read UPGRADE file and I'm aware zaptel was split into two parts so I built both) |
| 23:42.10 | kpfleming | it will be cleaned up in the next day or two and we'll get synchronized release candidates of all of them out |
| 23:42.21 | kpfleming | you need to install 1.6.0-beta9 and use Zaptel 1.4.11 for now |
| 23:42.32 | kpfleming | 1.6.0 from SVN is not ready for anyone to use yet |
| 23:42.42 | d1mas | oh... |
| 23:42.49 | d1mas | got it |
| 23:42.53 | d1mas | thanks |
| 23:42.57 | kpfleming | sorry about that, it seemed like you were assuming that 'make config' would be there, it was only there because i hadn't removed it yet, because it belongs in dahdi-tools |
| 23:43.00 | kpfleming | no problem |
| 23:45.59 | d1mas | kpfleming : by the way, what is the sense in splitting into two parts if asterisk requires BOTH of them to build channel driver ? |
| 23:46.31 | kpfleming | because there are versions of zaptel for other platforms besides linux, this will enabel them to eventually just use dahdi-tools without having to duplicate it |
| 23:46.46 | kpfleming | plus the version numbers and release cycles for the kernel modules and the userspace tools are very different |
| 23:47.10 | d1mas | ah. I see |