| 00:10.20 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 00:10.20 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 00:10.21 | *** join/#asterisk-dev sergee (n=serg@195.94.224.197) [NETSPLIT VICTIM] |
| 00:10.22 | *** join/#asterisk-dev ManxPower (n=manxpowe@195.sub-75-201-209.myvzw.com) |
| 00:10.22 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.138) |
| 00:10.22 | *** join/#asterisk-dev sruffell (n=sruffell@adsl-074-185-078-025.sip.bhm.bellsouth.net) [NETSPLIT VICTIM] |
| 00:10.22 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 00:10.53 | *** join/#asterisk-dev moy (n=moy@189.169.83.78) |
| 00:29.31 | *** part/#asterisk-dev ManxPower (n=manxpowe@195.sub-75-201-209.myvzw.com) |
| 00:52.58 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip68-103-153-140.ks.ok.cox.net) |
| 01:01.51 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 01:01.51 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 01:06.21 | *** join/#asterisk-dev unpaidbill (i=bill@420nugs.info) |
| 01:17.53 | *** join/#asterisk-dev snuff-work (n=snuff-wo@203.176.96.250) |
| 01:40.06 | *** join/#asterisk-dev outtolunc (n=me@c-67-170-211-86.hsd1.ca.comcast.net) |
| 01:54.59 | *** join/#asterisk-dev ta^3 (n=tacvbo@189.146.188.205) |
| 02:48.18 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23) |
| 04:05.27 | *** join/#asterisk-dev denon (n=denon@tooth.decay.org) |
| 04:54.57 | tzafrir_laptop | just got another spam from atcom |
| 04:55.54 | tzafrir_laptop | even after explicitly asking them not to |
| 05:08.24 | *** join/#asterisk-dev oron (n=oron@line25-214.adsl.actcom.co.il) |
| 05:08.58 | *** join/#asterisk-dev obnauticus (n=obnautic@c-67-160-181-107.hsd1.wa.comcast.net) |
| 06:13.29 | sergee | does anybody have a problems with t38 and current 1.6.0 branch? it seems that my asterisk doesn't relay reinvite... |
| 06:14.36 | snuff-work | sergee: silly question but have u also tried trunk ? |
| 06:14.58 | snuff-work | at leas that might narrow it down if its in 1 n not the other |
| 06:15.36 | sergee | snuff-work: silly answer - no i didn't :) - i'll try now |
| 06:36.36 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 06:36.36 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 06:37.12 | *** join/#asterisk-dev gones (n=gones@203.193.37.251) |
| 07:11.56 | sergee | snuff-work: trunk doesn't work as well |
| 07:13.48 | snuff-work | file a bug then.. make sure u include debug/sip |
| 07:41.23 | *** join/#asterisk-dev pputman (n=centrex@216.207.245.1) |
| 08:30.38 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 08:43.31 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23) |
| 10:26.52 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 10:52.27 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-9-100.dsl.telesp.net.br) |
| 10:55.22 | *** join/#asterisk-dev snuff-away (n=snuffy@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 11:12.39 | *** join/#asterisk-dev _ys (i=yuri@91.151.196.254) |
| 11:22.44 | *** join/#asterisk-dev jmls (n=chatzill@host217-36-208-155.in-addr.btopenworld.com) |
| 11:23.57 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 11:25.47 | *** join/#asterisk-dev DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 11:30.45 | *** join/#asterisk-dev pputman (n=centrex@216.207.245.1) |
| 11:40.04 | jmls | anyone used koji with asterisk ? |
| 11:51.31 | tzafrir_laptop | Aren't all Fedora packages built that way? |
| 11:52.42 | *** join/#asterisk-dev RoyK (n=roy@ti211210a080-3097.bb.online.no) |
| 11:59.06 | jmls | tzafrir_laptop: yeah. |
| 11:59.25 | jmls | I was wondering if anyone had used it to build an asterisk rpm from source |
| 12:04.07 | *** join/#asterisk-dev oron (n=oron@local.xorcom.com) |
| 12:07.03 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:08.15 | *** join/#asterisk-dev M1s3ry (n=M1s3ry@216.207.245.1) |
| 12:08.37 | *** join/#asterisk-dev file (n=file@asterisk/developer-and-muffin-lover/file) |
| 12:08.37 | *** join/#asterisk-dev _ys (i=yuri@91.151.196.254) |
| 12:08.37 | *** join/#asterisk-dev jeffg (i=w1zns8U9@pdpc/supporter/active/jeffg) [NETSPLIT VICTIM] |
| 12:08.37 | *** join/#asterisk-dev fabled (n=fabled@xdsl-83-150-94-239.nebulazone.fi) [NETSPLIT VICTIM] |
| 12:08.38 | *** join/#asterisk-dev Mw3 (n=mw3@ip59934bd1.rubicom.hu) |
| 12:08.38 | *** join/#asterisk-dev citats (n=james@mrplow.gnuinternet.com) |
| 12:08.38 | *** mode/#asterisk-dev [+oo file citats] by irc.freenode.net |
| 12:11.11 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 12:11.11 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 12:11.31 | *** join/#asterisk-dev shido6 (n=shido6@209.114.208.192) |
| 12:14.35 | *** join/#asterisk-dev DarkRift (n=dark@bas10-montreal02-1177582770.dsl.bell.ca) |
| 12:23.22 | *** join/#asterisk-dev qdk (n=qdk@195.242.194.42) |
| 12:34.23 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.228.111) |
| 12:35.41 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 12:57.52 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 13:00.00 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.228.111) |
| 13:02.58 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:02.58 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 13:19.17 | lmadsen | morning everyone |
| 13:21.35 | lmadsen | does anyone think it would be useful to have [bt] in the topic of a bug to signify a useful backtrace is attached to a crash bug? |
| 13:24.28 | *** join/#asterisk-dev jmls (n=chatzill@host217-36-208-155.in-addr.btopenworld.com) |
| 13:29.28 | snuff-away | technically.. anything that is a 'crash' should have a bt on it to start with |
| 13:30.24 | lmadsen | agreed, but not everyone attaches a useful backtrace |
| 13:31.05 | lmadsen | would be nice for the devs I'd think to know not to bother looking at a 'crash' status bug unless a useful bt is attached? |
| 13:32.26 | russellb | sounds useful |
| 13:33.09 | *** join/#asterisk-dev moy (n=moy@nat/ibm/x-38702e3175386c7c) |
| 13:33.56 | snuff-away | i dont mind.. gives me somethin else to do |
| 13:34.01 | lmadsen | heh |
| 13:34.15 | lmadsen | well we'll try it out and see if anyone finds it useful |
| 13:48.05 | seanbright | hmmm |
| 13:48.20 | seanbright | for length > 0, snprintf guarantees NULL termination, right? |
| 13:49.47 | russellb | yes |
| 13:50.02 | seanbright | super |
| 13:50.08 | russellb | man snprintf |
| 13:50.09 | russellb | :-p |
| 13:50.19 | russellb | RTFMP |
| 13:51.11 | seanbright | yeah, it's so clear and concise |
| 13:52.28 | russellb | "The functions snprintf() and vsnprintf() write at most size bytes (including the trailing null byte (â\0â)) to str." |
| 13:52.39 | seanbright | yes |
| 13:52.41 | seanbright | how is that clear? |
| 13:52.58 | russellb | it's clear to me :-p |
| 13:53.07 | russellb | you need to get out of the windows world of verbose documentation! |
| 13:53.16 | seanbright | ignores that |
| 13:53.23 | russellb | learn to love terse linux documentation |
| 13:53.53 | russellb | fine then! |
| 13:53.56 | russellb | ignores seanbright |
| 13:53.57 | russellb | :-p |
| 13:57.03 | *** join/#asterisk-dev RoyK (n=roy@ti211210a080-3097.bb.online.no) |
| 14:00.22 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.135) |
| 14:02.34 | *** join/#asterisk-dev sruffell (n=sruffell@adsl-074-185-078-025.sip.bhm.bellsouth.net) |
| 14:02.35 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:03.47 | anonymouz666 | why do we have DEFAULT_FREQ_OK hardcored in chan_sip.c? 60 secs couldn't be enough in some cases. |
| 14:03.47 | anonymouz666 | hardcoded |
| 14:04.46 | Corydon76-dig | anonymouz666: Patches may be submitted on bugs.digium.com |
| 14:06.58 | seanbright | if you make a change in 1.4 that you do not want in trunk or 1.6.0, you just have to block for trunk, right? |
| 14:07.49 | Corydon76-dig | seanbright: block the block in 1.6.0, too |
| 14:08.05 | Corydon76-dig | seanbright: otherwise it shows up in 'svnmerge avail' |
| 14:08.13 | seanbright | k |
| 14:09.42 | seanbright | ok, it's ugly, but it works. |
| 14:11.20 | anonymouz666 | Corydon76-dig: after reading the lastest posts in -dev list I feel chan_sip.c is very sensitive place to send any kind of patches or turning on by default some experimental feature :-) |
| 14:14.22 | russellb | anonymouz666: everything is always up for discussion |
| 14:14.26 | russellb | please don't hesitate |
| 14:15.04 | russellb | if you hesitate to work on the code, then the terrorists win |
| 14:15.34 | lmadsen | and god kills a kitten |
| 14:16.31 | *** join/#asterisk-dev tzanger (n=tzanger@gromit.mixdown.ca) |
| 14:17.31 | *** join/#asterisk-dev jeffg (i=lU9xllww@pdpc/supporter/active/jeffg) |
| 14:17.54 | Corydon76-dig | anonymouz666: but you can also make the change on your own system and test it out, before submitting the patch for general inclusion |
| 14:18.11 | Corydon76-dig | anonymouz666: that's what anybody submitting a new patch should be doing |
| 14:18.20 | Corydon76-dig | (even us) |
| 14:20.26 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) |
| 14:20.26 | Corydon76-dig | In other words, I'm not suggesting that you do anything different from what we already do... |
| 14:20.41 | snuff-away | seanbright: at least now he admits to czech localization |
| 14:21.21 | Corydon76-dig | The Czech's in the male. |
| 14:21.30 | snuff-away | heh.. |
| 14:21.40 | snuff-away | goes for some zzz's now |
| 14:24.58 | seanbright | i love how people submit bugs with a custom patched version and say how the patch is "irrelevant" to the bug |
| 14:25.22 | russellb | feel free to close and say feel free to reopen when reproduced on a non-patched version |
| 14:25.30 | seanbright | done and done |
| 14:25.35 | russellb | unless it's someone we know well and don't mind doing extra work for _and_ the patch is supplied |
| 14:26.11 | seanbright | festr |
| 14:26.20 | seanbright | heh |
| 14:26.22 | russellb | karma-- |
| 14:26.23 | seanbright | and he's here |
| 14:26.24 | seanbright | :) |
| 14:26.34 | seanbright | festr_: stop breaking app_queue! ;) |
| 14:32.14 | *** join/#asterisk-dev jsmith (n=jsmith@72.21.36.138) |
| 14:32.14 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 14:32.16 | sruffell | on the mantis bug tracker, why do we have the "mark as progress" checkbox? |
| 14:33.03 | sruffell | ...or rather how is the progress information used? |
| 14:33.24 | caio1982 | upstream leftover? |
| 14:33.35 | *** join/#asterisk-dev mcargile (n=mcargile@gateway.in-florida.net) |
| 14:33.40 | sruffell | ok...thanks. |
| 14:34.07 | caio1982 | sruffell: it's just a guess :) |
| 14:34.31 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 14:34.31 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:45.42 | tzanger | asterisk has generic dsp (tone detect/generate, fsk modem) functions that a channel driver can use if the channel driver does not have that functionality, right? |
| 14:45.57 | tzanger | I'm thinking specifically fsk stuff for CID generation for fxs-style interfaces |
| 14:46.50 | *** join/#asterisk-dev joetester2 (n=chatzill@216.191.34.13) |
| 14:47.32 | seanbright | do you think people rely on the format of 'core show uptime'? |
| 14:47.49 | jets | Probably |
| 14:48.01 | Corydon76-dig | seanbright: to a minor degree perhaps |
| 14:48.05 | jets | I imagine most scripters just use the raw format and put it on the status of their php/perl page, or whatever have you |
| 14:48.12 | Corydon76-dig | seanbright: I can't see it as a critical functionality |
| 14:48.31 | seanbright | it would be difficult to parse as it stands today |
| 14:48.45 | seanbright | you could have something like "1 year, 1 second" |
| 14:48.58 | mcargile | you never know someone could rely on it for some kind of script that automatically does some task at a certain period of time |
| 14:49.06 | Corydon76-dig | seanbright: besides, CLI command output is explicitly not supposed to be used for machine parsing |
| 14:49.14 | seanbright | well there is 'core show uptime seconds' |
| 14:49.18 | mcargile | this is true |
| 14:49.19 | seanbright | which returns the raw number of seconds |
| 14:49.23 | Corydon76-dig | That's what we have AMI for |
| 14:49.28 | seanbright | true |
| 14:50.20 | Corydon76-dig | seanbright: replace that with an AMI command |
| 14:51.25 | Corydon76-dig | At some point in the future, we'd like for external interface developers not to need Command privilege in AMI for general users |
| 14:51.51 | Corydon76-dig | (Still allowed for administrators, though) |
| 14:57.55 | jets | It seems harder and harder for me to wake up these days. I need to quit coding so late so i can code oh-so early. |
| 15:01.27 | tzafrir_laptop | Corydon76-dig, right. But how do you setup AMI from cron? without first creating a manager user. And storing the password in a separate place for the cron user to read, and such |
| 15:02.10 | putnopvut | seanbright: thanks for your marshalling on 13047 :) |
| 15:09.43 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 15:09.43 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:09.57 | Corydon76-dig | tzafrir_laptop: um, setup AMI from cron? |
| 15:10.28 | tzafrir_laptop | so you won't use asterisk -rx's output |
| 15:10.41 | tzafrir_laptop | you mentioned it as the laternative |
| 15:11.14 | tzafrir_laptop | alternative, that is |
| 15:11.24 | Corydon76-dig | tzafrir_laptop: I'm not sure how system administrator tasks have anything to do with external interface design |
| 15:12.23 | tzafrir_laptop | Corydon76-dig, astcli is almost a perfect substitution here. "almost", because it requires some setup that cannot be automated |
| 15:12.23 | Corydon76-dig | tzafrir_laptop: and there are better ways to get process uptime as a local Unix user. The process table has the exact timestamp |
| 15:12.50 | Corydon76-dig | tzafrir_laptop: I didn't even mention astcli today |
| 15:12.57 | tzafrir_laptop | So is there a robust way to edit manager.conf? |
| 15:13.51 | Corydon76-dig | I find vim works wonders |
| 15:15.04 | tzafrir_laptop | But can you write editing instructions that will always work? Can you know in advance if there is such a user or no? |
| 15:17.05 | Corydon76-dig | 1) type 'vim manager.conf' 2) ??? 3) PROFIT!! |
| 15:17.51 | tzafrir_laptop | My inspiration is the way mysql/mysqladmin "just work" for root on Debian using /etc/mysql/debian.cnf |
| 15:18.05 | Qwell | local socket? |
| 15:18.58 | Corydon76-dig | mysqladmin: Unknown command: 'just work' |
| 15:20.37 | Corydon76-dig | tzafrir_laptop: it only works because you've set up a user in advance. If I change that username or the password, then things will cease to work |
| 15:20.46 | tzafrir_laptop | alias root_sql '/usr/bin/mysql --defaults-file=/etc/mysql/debian.cnf' |
| 15:20.54 | Corydon76-dig | tzafrir_laptop: you can do the same thing with Asterisk |
| 15:20.56 | tzafrir_laptop | root_sql asterisk |
| 15:21.39 | Corydon76-dig | tzafrir_laptop: that doesn't help if you've change the permissions on the mysql server |
| 15:21.46 | tzafrir_laptop | Right. But with manual work. And thus I cannot assume it is there and base instructions I give on it |
| 15:21.59 | tzafrir_laptop | Which is why I'm looking for a way to automate this |
| 15:22.04 | Corydon76-dig | tzafrir_laptop: can't assume that on mysql, either |
| 15:22.17 | tzafrir_laptop | I can, if it is on Debian |
| 15:22.36 | Corydon76-dig | tzafrir_laptop: you can setup either Asterisk or mysql with a default user, and the admin can remove that user. You can't stop the admin. |
| 15:23.36 | Corydon76-dig | The only thing that mysql has in this regard is the ability to start up the server with the permissions set completely disabled |
| 15:29.54 | tzafrir_laptop | I can't stop the admin from doing something very foolish. /etc/mysql/debian.cnf is basically the equivalent of /etc/asterisk/astcli.conf or whatever this is called |
| 15:30.45 | tzafrir_laptop | But mysql has a standard method for adding a user. The postinstall script of Debian uses it to add such a user (with a random secret) |
| 15:31.34 | tzafrir_laptop | How do I "add a user" automatically to manager.conf? |
| 15:31.41 | Corydon76-dig | Use the GUI |
| 15:32.10 | tzafrir_laptop | that connects to asterisk through..... the manager interface |
| 15:32.17 | Corydon76-dig | Or I'm sure someone could come up with a command to append to the file |
| 15:32.36 | Corydon76-dig | like... 'echo' |
| 15:32.47 | tzafrir_laptop | Setting up the asterisk GUI requires editing manager.conf . I still didn't figure a decent fix for this in my package |
| 15:33.35 | *** join/#asterisk-dev RoyK (n=roy@ti211210a080-3097.bb.online.no) |
| 15:33.37 | Corydon76-dig | tzafrir_laptop: you can't use 'echo' in your package? |
| 15:34.12 | tzafrir_laptop | How can I test that there's no such entry already? |
| 15:34.20 | *** join/#asterisk-dev iulius (n=iulius@mail1.technologieshq.com) |
| 15:34.43 | tzafrir_laptop | I know how to write things that will work most of the times |
| 15:34.52 | Corydon76-dig | tzafrir_laptop: If you're installing for the first time, you assume there isn't, and if you're upgrading, you assume it's already there? |
| 15:35.06 | jsmith | tzafrir: Can't you use the "UpdateConfig" AMI action to add users to manager.conf? |
| 15:35.12 | Corydon76-dig | That will work most of the time |
| 15:35.45 | Corydon76-dig | jsmith: he's worrying about adding the FIRST ami user |
| 15:35.48 | tzafrir_laptop | jsmith, sure :-) |
| 15:36.13 | *** join/#asterisk-dev mog (n=mog@c-68-62-219-86.hsd1.al.comcast.net) |
| 15:36.13 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 15:36.28 | tzafrir_laptop | Not to mention that using UpdateConfig from a shell script is not nice |
| 15:36.30 | Corydon76-dig | tzafrir_laptop: how do you work on a mysql update if the admin has disabled the default user? |
| 15:36.43 | jsmith | Corydon76-dig: Ah, gotcha... |
| 15:36.56 | tzafrir_laptop | If the sysadmin did something stupid, things will break |
| 15:37.17 | Corydon76-dig | tzafrir_laptop: precisely. You're assuming that the sysadmin hasn't disabled something |
| 15:37.52 | tzafrir_laptop | But we're not talking about "something stupid". It could be left-overs from other things. e.g: "#include manager_additional.conf" with a user that has the same name |
| 15:38.30 | Corydon76-dig | tzafrir_laptop: but that won't exist on Debian |
| 15:39.24 | Corydon76-dig | tzafrir_laptop: you're providing completely different scenarios for MySQL vs Asterisk and expecting Asterisk to do magical things that you aren't expecting of MySQL |
| 15:39.30 | tzafrir_laptop | reminds Corydon76-dig that a freepbx package for debian exists in the same place an asterisk-gui package one exists |
| 15:40.15 | Corydon76-dig | tzafrir_laptop: then in that package, you've already created your Debian default user. Not an issue. |
| 15:41.03 | Corydon76-dig | tzafrir_laptop: If I install a MySQL server from source in the same place as Debian expects to put a mysql package, things will break. |
| 15:41.27 | Corydon76-dig | Same with Asterisk, no matter the flavor |
| 15:42.23 | tzafrir_laptop | Corydon76-dig, as I mentioned: this is one of the things I haven't sorted out yet |
| 15:43.01 | Corydon76-dig | tzafrir_laptop: what do you do for XML config files? |
| 15:43.28 | *** join/#asterisk-dev mcargile (n=mcargile@gateway.in-florida.net) |
| 15:43.32 | tzafrir_laptop | rxml is something I cannot even edit from a shell script. Let alone decently include and such |
| 15:43.42 | Corydon76-dig | Seems to me there could be an INI-style parser for the same purpose |
| 15:44.06 | Corydon76-dig | tzafrir_laptop: isn't the GNOME registry in XML? |
| 15:44.09 | tzafrir_laptop | It's not INI. "INI" implies that it is a dictionary. |
| 15:44.31 | Corydon76-dig | tzafrir_laptop: the format is identical to an ini file |
| 15:44.33 | tzafrir_laptop | where did I say I liked the gnome registry? |
| 15:44.48 | tzafrir_laptop | (it requires a specil daemon up just to access it) |
| 15:44.57 | Corydon76-dig | tzafrir_laptop: yet other Debian maintainers don't have trouble with the gnome registry. What tool do they use? |
| 15:45.29 | tzafrir_laptop | gconf-tool, probably |
| 15:45.50 | Corydon76-dig | You could write your own tool to deal with ini-style files |
| 15:45.52 | tzafrir_laptop | and must use some voodoo to keep the deamons up |
| 15:46.52 | Corydon76-dig | Heck, I could probably whip up something in Perl in 15 minutes that would do it. |
| 15:47.09 | russellb | i could do it in 10 with python. |
| 15:47.14 | tzafrir_laptop | http://search.cpan.org/~hoowa/Asterisk-config-0.96/ |
| 15:47.32 | Corydon76-dig | See? even easier |
| 15:49.37 | Qwell | russellb: I could do it in ruby with 1. |
| 15:49.44 | Qwell | what are we talking about again? |
| 15:49.45 | russellb | oh snap |
| 15:49.52 | russellb | doesn't know, either |
| 15:50.07 | Corydon76-dig | Qwell: ruby minutes with the 1 language? |
| 15:50.18 | Qwell | huh? |
| 15:50.19 | russellb | lol |
| 15:50.23 | tzafrir_laptop | speaking about that module, anybody tried the GUI its author wrote? |
| 15:50.26 | tzafrir_laptop | http://www.freeiris.org/ |
| 15:50.31 | Qwell | oic |
| 15:50.35 | Qwell | no, ruby lines |
| 15:51.10 | russellb | that page is very not English :) |
| 15:51.36 | Qwell | That picture at the top is *awesome* |
| 15:51.44 | russellb | agreed :) |
| 15:51.47 | tzafrir_laptop | It was originally called "Astercon2" |
| 15:51.56 | Qwell | tzafrir_laptop: yeah, that's a silly name |
| 16:01.56 | *** join/#asterisk-dev jameswf-home (n=james@dsl093-157-131.phx1.dsl.speakeasy.net) |
| 16:04.53 | mog | russellb, hit the english button ^_^ |
| 16:07.45 | putnopvut | English button appears to not work. |
| 16:08.06 | mvanbaak | heya all |
| 16:08.06 | putnopvut | lol, look at what the English URL actually is. |
| 16:08.13 | putnopvut | http://www.freeiris.org/# |
| 16:08.15 | putnopvut | Thanks! |
| 16:08.27 | russellb | hehe |
| 16:08.47 | Qwell | it's javascript - I bet it works in IE |
| 16:09.00 | russellb | i bet i don't care enough to try |
| 16:13.24 | *** join/#asterisk-dev Schmooze (n=Schmooze@rrcs-67-53-189-178.west.biz.rr.com) |
| 16:14.34 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 16:15.45 | *** join/#asterisk-dev jmls (n=chatzill@host217-36-208-155.in-addr.btopenworld.com) |
| 16:15.48 | kpfleming | russellb: 'pbx_spool.so module loaded or pbx_spool embedded' :-) |
| 16:16.35 | russellb | fair enough :) |
| 16:21.34 | mvanbaak | russellb: 'show parkedcalls' has been deprecated for some time. Should I merge the removal of that command to 1.6.0 ? |
| 16:22.21 | russellb | if that's what was done with everything else, then i guess so |
| 16:22.46 | mvanbaak | ah, then I block it |
| 16:23.05 | mvanbaak | because that's what we did with some of the others |
| 16:23.17 | russellb | k |
| 16:29.07 | tzanger | asterisk has generic dsp (tone detect/generate, fsk modem) functions that a channel driver can use if the channel driver does not have that functionality, right? |
| 16:29.13 | tzanger | I'm thinking specifically fsk stuff for CID generation for fxs-style interfaces |
| 16:30.06 | russellb | yeah, that's the theory |
| 16:31.51 | kpfleming | actually, it's always done in the core |
| 16:31.59 | kpfleming | channel drivers don't do it, as far as i know |
| 16:32.19 | tzanger | kpfleming: ? I thought channel drivers were able to say I can do it myself, don't busy up the CPU for DSP task Alpha |
| 16:32.40 | tzanger | i.e. echo can, tone detect, tone gen, etc. |
| 16:32.54 | kpfleming | only echo can and tone detect |
| 16:33.01 | kpfleming | and tone generation |
| 16:33.07 | kpfleming | but not FSK generation or detection |
| 16:33.26 | kpfleming | those are separate functions (tone gen/det is in dsp.c, the FSK stuff is in callerid.c) |
| 16:33.34 | tzanger | aha |
| 16:33.35 | tzanger | perfecto |
| 16:34.18 | tzanger | that makes my plan all the more sinister :) |
| 16:34.37 | tzanger | any plan for adding capabilities bits for things like conferencing and such? |
| 16:35.06 | kpfleming | in file's bridging rework, yeah |
| 16:35.12 | tzanger | nifty |
| 16:41.56 | *** join/#asterisk-dev codefreeze-lap (n=murf@216.166.159.235) |
| 16:41.56 | *** mode/#asterisk-dev [+o codefreeze-lap] by ChanServ |
| 16:42.14 | *** part/#asterisk-dev codefreeze-lap (n=murf@216.166.159.235) |
| 16:42.43 | *** join/#asterisk-dev codefreeze-lap (n=murf@216.166.159.235) |
| 16:42.43 | *** mode/#asterisk-dev [+o codefreeze-lap] by ChanServ |
| 16:45.15 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.138) |
| 16:46.06 | *** join/#asterisk-dev eliel (n=eliel@host-cotesma-163-176.smandes.com.ar) |
| 16:58.12 | jmls | can anyone point me in the right direction .. |
| 16:58.28 | Qwell | points "that-a-way" |
| 16:58.29 | jmls | I want to take a live cd (ubuntu), mount it on a running linux box |
| 16:58.54 | jmls | modify it so that there is no gui, install asterisk, zaptel and libpri |
| 16:59.06 | jmls | and remaster the cd |
| 16:59.11 | jmls | so I could just boot the server from the cd |
| 16:59.17 | Qwell | jmls: easier said than done |
| 16:59.23 | jmls | so I've found |
| 17:00.18 | jmls | "all" I want to do is to stick a te412p into a machine, slap in a couple of drives, and boot it from either cd, network or usb |
| 17:00.45 | jmls | and have * up and running with _no_ installation. All my .conf files use curl to get the config externally |
| 17:01.12 | kpfleming | you'll have to use the 'spin' tools available with various distros to make yourself a customized version of their livecd |
| 17:01.57 | jmls | from the sites I've found, you need to be as master at linux to achieve this with spin ;) |
| 17:02.02 | jmls | is no master |
| 17:02.20 | tzafrir_laptop | points jmls to http://updates.xorcom.com/iso/ |
| 17:02.40 | jmls | consider me pointed |
| 17:03.33 | *** join/#asterisk-dev Laureano (n=Laureano@190.245.121.203) |
| 17:03.36 | Laureano | Hello |
| 17:04.27 | tzafrir_laptop | jmls, it should have all the configuration there required for remastering |
| 17:04.52 | tzafrir_laptop | not remastrering, though. recreating |
| 17:16.01 | tzafrir_laptop | err... how can I set a default echo canceller to all the channels? |
| 17:19.10 | sruffell | tzafrir_laptop: Not implemented yet.... |
| 17:19.42 | sruffell | as far as I know... |
| 17:20.15 | tzafrir_laptop | Is there a real point for this separation (the per-channel structure)? I cannot even make this a load-time parameter to dahdi, because it has to be made after all channels are loaded |
| 17:20.49 | tzafrir_laptop | Unless I try to do it at channel registration time |
| 17:21.16 | tzafrir_laptop | we took something that required no configuration and made it to require configuration |
| 17:21.33 | tzafrir_laptop | Even though the sane default is clear |
| 17:21.44 | sruffell | afaik, the per channel structure allows users to set up the best echocanceller for that particular channel. But, I think an option for a global default is in order. |
| 17:23.45 | tzafrir_laptop | The nice thing about a (read-only) module parameter is that you can always be sure its value will never change |
| 17:24.33 | sruffell | I think the intent was always to make a default setting: http://svn.digium.com/view/dahdi?view=rev&revision=4435 |
| 17:26.01 | *** join/#asterisk-dev allankardec (n=root@189.104.17.52) |
| 17:27.18 | sruffell | true....but it's much harder to tune lines when you have to constantly reload the drivers. I think eventually moving all the setup of the echocancellers into chan_dahdi makes sense to keep it all together. You can turn it on / off, select which one to use, send in the parameters all at the same place. Currently, you load the ec cancellers at compile (in zaptel) or config (dahdi) time, then parameters are adjusted in c |
| 17:32.44 | tzafrir_laptop | I think it is fundenmentally broken that asterisk or whatever will force loading of a kernel module |
| 17:33.10 | tzafrir_laptop | There is no reason not to make the common case simple |
| 17:33.26 | tzafrir_laptop | An echo canceller should "just work" |
| 17:35.42 | sruffell | if they did...that would certainly save much troubleshooting a tweaking time depending on environmental conditions. But I too am of the opinion that the common case should be simple. |
| 17:40.12 | *** join/#asterisk-dev codefreeze-lap (n=murf@216.166.159.235) |
| 17:40.12 | *** mode/#asterisk-dev [+o codefreeze-lap] by ChanServ |
| 17:45.05 | kpfleming | with dahdi, there is no need to reload drivers to change echo cancellers |
| 17:46.47 | kpfleming | and yes, there is a significant reason why this was done. any binary packaging of dahdi without this new work would require the packager to choose an echo canceler, and then the user could not change it after installing the package |
| 17:47.01 | kpfleming | so it had to be moved to being a load-time option |
| 17:47.26 | kpfleming | going that route, it seemed to make the most sense to make it per-channel, because there are going to be cases where users want it to be per-channel |
| 17:48.55 | kpfleming | and how is it any more broken for dahdi_cfg/asterisk to force a kernel module to be loaded than for iptables (or many other tools) to do the same? |
| 17:54.24 | tzafrir_laptop | What I mean is: I think it would be bad if the echo canceller module would only be loaded at asterisk startup |
| 17:54.54 | kpfleming | why? |
| 17:54.59 | tzafrir_laptop | asterisk is not run by root |
| 17:55.12 | kpfleming | but root made it possible by loading dahdi in the first place |
| 17:55.32 | tzafrir_laptop | It also increases the chance for a kernel panic at that time, rather than on initial module load time |
| 17:55.37 | kpfleming | the asterisk user doesn't get to *provide* the module, they only get to request that a module that the root user supplied actually get loaded |
| 17:55.39 | tzafrir_laptop | is very optimistic today |
| 17:57.55 | tzafrir_laptop | It also means that if any of the less-used EC modules has an exploitable hole, it now also becomes explitable by Asterisk |
| 17:58.16 | kpfleming | wow... that just seems so far fetched |
| 17:58.18 | tzafrir_laptop | (which suggests not to build by default the ECs noone will use) |
| 17:58.34 | kpfleming | but in any case, i suspect the admin could cause that to be a non-issue by blacklisting the modules he doesn't want to be loaded |
| 17:58.53 | sruffell | ...would need to delete them from the /lib/modules directory. |
| 17:59.03 | tzafrir_laptop | This is something the admin will not see coming. |
| 17:59.09 | kpfleming | blacklist doesn't take effect on request_module()? |
| 17:59.16 | sruffell | nope.... |
| 17:59.23 | kpfleming | weird |
| 17:59.24 | sruffell | it's only read by the userspace tools. |
| 17:59.28 | tzafrir_laptop | BTW: "blacklist" here == "alias modulename off" or "blacklist modulename"? |
| 17:59.29 | sruffell | the blacklist file. |
| 17:59.32 | kpfleming | request_module() forwards to userspace |
| 17:59.51 | sruffell | but not by PCI id....by name. |
| 18:01.07 | sruffell | if this is really something to be concerned about, dahdi_cfg could be setup to load in available ec modules before associating them with the channels. |
| 18:04.00 | sruffell | tzafrir_laptop: it must be blacklist "modulename" because the ec modules do not have alias. |
| 18:04.00 | sruffell | ..es |
| 18:04.27 | tzafrir_laptop | if you alias it to "off" it will try loading the module "off" (and fail) |
| 18:05.00 | sruffell | ahh...I see what you mean. |
| 18:05.13 | tzafrir_laptop | Though I don't think that it is an officially-supported method |
| 18:11.45 | eliel | Too trivial fix: can someone remove the \n at the end of the CLI command summary 'sip unregister' in channels/chan_sip.c at line: 22108 (AST_CLI_DEFINE(sip_unregister,... \n"),'. Thanks! |
| 18:12.03 | seanbright | eliel: can you submit a patch to mantis? |
| 18:12.07 | seanbright | (heh heh heh) |
| 18:12.21 | russellb | make sure that change is properly licensed! |
| 18:12.38 | eliel | hehe |
| 18:12.39 | seanbright | speaking of which |
| 18:12.45 | seanbright | localtime.c has the following line in it |
| 18:13.13 | seanbright | This file is in the public domain, so clarified as of |
| 18:13.20 | seanbright | 1996-06-05 by Arthur David Olson. |
| 18:14.00 | seanbright | so adding anything to that file puts it in the public domain? |
| 18:16.32 | seanbright | eliel: committed |
| 18:16.41 | seanbright | eliel++ |
| 18:16.51 | eliel | seanbright: Thanks |
| 18:17.10 | eliel | seanbright: Now I will be able to sleep at night.. :-) |
| 18:17.15 | seanbright | heh |
| 18:20.00 | Qwell | seanbright: no |
| 18:20.35 | seanbright | Qwell: ok. i was confused. |
| 18:20.48 | Qwell | seanbright: it just means that the origins of the file were public domain |
| 18:21.06 | tzafrir_laptop | if you add anything there it is a work by you. Derieved from the earlier work |
| 18:21.18 | seanbright | alrighty |
| 18:21.19 | tzafrir_laptop | You can choose whatever license to give it |
| 18:21.25 | Qwell | derivision(?) of public domain can be any license |
| 18:21.39 | Qwell | as far as I understand it, anyhow |
| 18:21.42 | seanbright | that's all well and good |
| 18:21.58 | seanbright | but maybe we change "This file is in the public domain" to "This file was in the public domain" |
| 18:22.01 | seanbright | or is that not kosher? |
| 18:22.37 | Corydon76-dig | seanbright: I left it that way because I was fine with my changes also having the same status |
| 18:22.41 | Qwell | seanbright: the following comment clarifies the license |
| 18:22.58 | Corydon76-dig | seanbright: it would be nice if they incorporated the main changes upstream |
| 18:23.12 | Qwell | erm, preceding comment, I guess |
| 18:23.27 | seanbright | well i had planned to add a new function to that file |
| 18:23.37 | seanbright | so it's ok if i do that? |
| 18:23.52 | Corydon76-dig | seanbright: what function, specifically? |
| 18:24.19 | seanbright | Corydon76-dig: ast_format_duration |
| 18:24.24 | Corydon76-dig | seanbright: generally speaking, that file is up for replacement at any time with the version from upstream |
| 18:25.30 | seanbright | Corydon76-dig: ah. so where would i put date/time related functions? |
| 18:25.32 | Corydon76-dig | seanbright: tell me why utils.c would not be more appropriate as a location? |
| 18:25.45 | seanbright | Corydon76-dig: no reason. utils.c it is. |
| 18:26.32 | seanbright | just thought it made sense to consolidate date/time formatting functions in the same place |
| 18:27.29 | Corydon76-dig | seanbright: for that matter, if you want to take this opportunity to move ast_strftime, that would probably be good, too |
| 18:27.38 | seanbright | will do |
| 18:28.01 | Corydon76-dig | What does ast_format_duration do, anyway? |
| 18:28.38 | seanbright | takes a number of seconds and returns "X years, X days, X hours, etc." |
| 18:28.46 | seanbright | its duplicated in a few places |
| 18:28.53 | seanbright | or similar code is, at least. |
| 18:29.22 | Corydon76-dig | Might I suggest ast_app_durationstr or something in app.c? |
| 18:29.58 | seanbright | oh really? heh |
| 18:29.59 | seanbright | woops |
| 18:30.11 | seanbright | reverts |
| 18:30.16 | Corydon76-dig | No |
| 18:30.19 | Corydon76-dig | I meant, put it there |
| 18:30.37 | seanbright | why in app.c? |
| 18:30.50 | seanbright | its dup'd in 2 res modules and in main/asterisk.c |
| 18:31.07 | Corydon76-dig | I dunno, just a thought |
| 18:31.34 | seanbright | alrighty |
| 18:31.37 | Corydon76-dig | I'm not some god to hand down commandments from on high, I'm just making suggestions... |
| 18:31.57 | seanbright | you're not? |
| 18:31.57 | Corydon76-dig | but put it where you think it's most appropriate |
| 18:32.08 | seanbright | will do |
| 18:32.13 | russellb | either that or utils.c |
| 18:32.16 | russellb | app.c is probably better |
| 18:32.19 | russellb | but *shrugs* |
| 18:32.21 | jmls | here's a really authoritative comparison of asterisk vs freeswitch |
| 18:32.23 | jmls | http://pastebin.com/mb77b19b |
| 18:32.52 | jmls | diegoviola has done well there |
| 18:32.54 | jmls | ;) |
| 18:34.10 | seanbright | why in app.c? |
| 18:34.52 | seanbright | just so we're clear, this isn't an asterisk function |
| 18:34.55 | seanbright | it's a C function |
| 18:35.05 | Corydon76-dig | seanbright: think of it as a level thing. utils.c implements a lot of grunt work functions. app.c implements higher level conceptual stuff |
| 18:36.04 | seanbright | in my mind it serves the same purpose as ast_strftime, just not quite as flexible |
| 18:36.13 | seanbright | take time data and stringifies it |
| 18:36.29 | Corydon76-dig | Well, ast_strftime doesn't exist right now in either place |
| 18:36.48 | seanbright | i'm aware of that |
| 18:37.16 | seanbright | but before i started writing it i thought to myself "where is the most logical place to put this?" |
| 18:37.21 | seanbright | and grepped for ast_strftime |
| 18:37.26 | seanbright | fast forward to now |
| 18:37.31 | Corydon76-dig | Ah |
| 18:38.30 | russellb | heh |
| 18:38.38 | russellb | how dare you demand logic |
| 18:39.30 | seanbright | i know, i'm crazy |
| 18:39.31 | Corydon76-dig | seanbright: There certainly is some cleanup that needs to be done in terms of how code is organized |
| 18:39.40 | seanbright | i'm not complaining |
| 18:39.52 | seanbright | just trying to understand where certain pieces should go |
| 18:40.04 | seanbright | you guys say app.c or utils.c, i will defer to your better judgement |
| 18:40.07 | Corydon76-dig | Even acl.c has morphed from its original purpose |
| 18:40.09 | seanbright | and i will move ast_strftime in the process |
| 18:40.49 | seanbright | this all goes away with my C++ version anyway... |
| 18:40.52 | seanbright | giggles |
| 18:40.54 | seanbright | brb |
| 18:41.23 | Corydon76-dig | and there are even some code files, like ulaw.c and alaw.c, which would be better served out in the codecs/ directory, I think |
| 18:45.05 | Corydon76-dig | jmls: "I suck, therefore I use FreeSWITCH" |
| 18:45.26 | jmls | heh |
| 18:45.59 | russellb | same guy that basically told both file and I to go to hell and that we were terrible people via comments on our blogs |
| 18:46.14 | russellb | (gitguy on IRC, btw) |
| 18:46.34 | seanbright | ohhh |
| 18:46.37 | jmls | I may not be the sharpest knife in the drawer, but at least I can put together a better proposal than that >) |
| 18:46.40 | russellb | he is no longer welcome in #asterisk-anything |
| 18:46.43 | seanbright | the douche bag |
| 18:46.45 | seanbright | heh |
| 18:46.51 | russellb | haven't banned him yet, was waiting for him to join first. |
| 18:46.55 | seanbright | nice |
| 18:47.13 | jmls | at least he raised the average IQ level of -dev when he left |
| 18:47.25 | seanbright | ok, ok, we win, we're better |
| 18:47.29 | seanbright | let us move on |
| 18:47.38 | jmls | oh. |
| 18:47.46 | jmls | I was having such _fun_ |
| 18:47.47 | seanbright | points at ibot.rikers.org... |
| 18:50.13 | Corydon76-dig | russellb: /msg chanserv flags #asterisk-dev gitguy +b |
| 18:51.46 | russellb | yeah but, waiting until he could see it would be more fun. |
| 18:52.40 | outtolunc | remembers that <G> |
| 18:52.51 | Corydon76-dig | Not quite as fun as what I did to one guy on my website |
| 18:53.16 | Corydon76-dig | When his IP attempted to access the site, I prepared a special page just for him |
| 18:53.35 | putnopvut | uh oh... |
| 18:53.38 | russellb | lol, goatse? |
| 18:53.53 | putnopvut | everyone's immune to goatse by now. |
| 18:53.59 | putnopvut | Okay, not "everyone" |
| 18:54.00 | seanbright | not me |
| 18:54.05 | Corydon76-dig | No, a message telling him that he was an idiot for being unable to follow instructions |
| 18:54.11 | seanbright | it's worse than tubgirl |
| 18:54.16 | Corydon76-dig | and naming him |
| 18:54.20 | tzanger | speaking of goatse, they've changed it now |
| 18:54.23 | tzanger | not quite as fun |
| 18:54.34 | putnopvut | I've just seen goatse so many times that it doesn't have the same shock value it once had. |
| 18:54.37 | Corydon76-dig | You know, at first blush, he probably thought all site visitors saw that |
| 18:54.39 | tzanger | I keep waiting for it to change |
| 18:54.47 | tzanger | but it looks like theyv'e given up |
| 18:54.59 | Corydon76-dig | tzanger: http://www.meatspin.com |
| 18:55.17 | Corydon76-dig | Make sure your speakers are on |
| 18:55.36 | tzanger | yeah I saw that one before |
| 18:56.14 | Corydon76-dig | tzanger: http://www.motherman.com |
| 18:56.59 | tzanger | hahaha ok I haven't seen that one before |
| 18:57.01 | *** join/#asterisk-dev emiller (n=ed@216.207.245.1) |
| 18:57.34 | Corydon76-dig | tzanger: there are others which are painful to watch |
| 18:58.13 | russellb | damnit Tilghman |
| 18:58.19 | russellb | you could have at least said NSFW |
| 18:58.24 | tzanger | hahahaha |
| 18:58.31 | tzanger | russellb: you should have been paying attention to context |
| 18:58.37 | Corydon76-dig | Oh, sorry, I thought that was obvious from the goatse discussion |
| 18:58.42 | seanbright | Corydon76-dig is NSFW |
| 18:58.44 | russellb | should have been |
| 18:58.57 | russellb | but i instinctively saw a link and clicked |
| 18:59.01 | russellb | without really thinking about it, heh |
| 18:59.17 | tzanger | you're how new to the interweb again? |
| 18:59.24 | russellb | 3 months |
| 18:59.35 | lmadsen | I beat the Internet -- the end boss was hard |
| 18:59.36 | russellb | and #asterisk-dev is usually safe :) |
| 18:59.39 | Corydon76-dig | tzanger: the painful one is http://www.swollentip.com/ NSFW |
| 19:00.00 | seanbright | i can tell from the domain name that i should not click on that link |
| 19:00.08 | caio1982 | goatse and tubgirl, i love this channel hahah |
| 19:00.10 | lmadsen | I clicked it -- it goes to a search engine |
| 19:00.12 | seanbright | it's what i would call, a "subtle hint" |
| 19:00.37 | seanbright | ok |
| 19:00.39 | seanbright | time for me to go home |
| 19:00.55 | lmadsen | bye! |
| 19:00.56 | russellb | got enough non-work done for the day? |
| 19:00.58 | russellb | :-D |
| 19:01.01 | seanbright | plenty |
| 19:01.09 | Corydon76-dig | russellb: which one did you click on? |
| 19:01.27 | russellb | motherman :( |
| 19:02.54 | Corydon76-dig | passes russellb the brain bleach |
| 19:03.18 | russellb | hehe |
| 19:04.04 | putnopvut | brain bleach == vodka |
| 19:04.05 | *** join/#asterisk-dev joetester2 (n=chatzill@216.191.34.13) |
| 19:04.20 | tzanger | brain bleach, haha |
| 19:04.30 | Corydon76-dig | putnopvut: more stuff I'm not supposed to have anymore |
| 19:04.42 | tzanger | how is that nsfw? |
| 19:05.05 | putnopvut | Corydon76-dig: Just vodka or all alcohol? |
| 19:05.07 | Corydon76-dig | chocolate, alcohol, peppermint, fried foods, fatty foods... |
| 19:05.33 | Corydon76-dig | Oh, and caffeine |
| 19:06.59 | *** join/#asterisk-dev eliel_ (n=eliel@host-cotesma-163-176.smandes.com.ar) |
| 19:07.18 | Corydon76-dig | I don't think I'm going to be able to give up chocolate, though |
| 19:07.50 | putnopvut | Just peppermint or any sort of mint? |
| 19:08.08 | Corydon76-dig | peppermint and spearmint were the two specifically mentioned |
| 19:08.16 | lmadsen | chocolate is too good |
| 19:08.45 | Corydon76-dig | I suppose that means I can have wintergreen and catnip |
| 19:09.15 | putnopvut | "fatty foods" is kind of vague. Does that include fatty fish like tuna? Does it include peanuts, olives, and avocados, which have a high oil content? |
| 19:09.40 | Corydon76-dig | putnopvut: I'm not giving up peanut butter, either |
| 19:09.48 | lmadsen | it means Corydon76-dig is going to become a level 5 vegan |
| 19:09.54 | pputman- | I had a question about this janitor project: Use the ast_str API in strings.h to replace multiple calls to strncat(), snprintf(). Is it desired to change all strings in ast_str structures, or only in certain situations? |
| 19:09.58 | putnopvut | and he's going to pocket mulch? |
| 19:10.07 | pputman- | s/in/to |
| 19:10.45 | Corydon76-dig | pputman: the main intent is to get rid of the multiple library calls, as well as the arbitrarily large static buffers |
| 19:11.27 | Corydon76-dig | Anywhere you see something like: char buf[256], ast_str might be a good replacement |
| 19:11.38 | pputman- | okay, thanks |
| 19:11.57 | Corydon76-dig | Just remember that it needs to be paired with a free() |
| 19:13.40 | Corydon76-dig | We could probably do with dynamically allocated buffers, even without ast_str, in the structure within func_odbc.c, for example |
| 19:14.02 | Corydon76-dig | sql_read[2048] |
| 19:15.27 | pputman- | Corydon76-dig, But if there are a lot of library calls to strncat, snprintf, etc... then ast_str would be better? |
| 19:16.02 | Corydon76-dig | Heh, it depends |
| 19:16.45 | Corydon76-dig | I think some of that is really an advanced janitor, because some of those are done for pure speed |
| 19:17.20 | Corydon76-dig | cat/copy is always faster than a printf |
| 19:17.21 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.138) |
| 19:19.02 | *** join/#asterisk-dev ManxPower (n=manxpowe@115.sub-75-250-134.myvzw.com) |
| 19:19.11 | Corydon76-dig | pputman-: take a look at say.c, line 7374 |
| 19:19.16 | Corydon76-dig | (in trunk) |
| 19:19.28 | ManxPower | I don't see an upgrade.txt in the 1.6 beta9 |
| 19:19.40 | Corydon76-dig | pputman-: that's a prime candidate to simplification to a single statement |
| 19:20.58 | Corydon76-dig | pputman-: there are a ton of examples like that in say.c |
| 19:21.14 | ManxPower | nevermind, I see you put the doc file not in the doc directory |
| 19:21.51 | *** join/#asterisk-dev AdamWest (n=Leif@CPE001d7e2f9574-CM0012c9db3d2e.cpe.net.cable.rogers.com) |
| 19:23.17 | pputman- | Corydon76-dig, okay I get it, thanks |
| 19:26.03 | *** part/#asterisk-dev ManxPower (n=manxpowe@115.sub-75-250-134.myvzw.com) |
| 19:30.33 | *** join/#asterisk-dev bweschke (n=BJ_Wesch@c-76-124-82-215.hsd1.nj.comcast.net) |
| 19:30.33 | *** mode/#asterisk-dev [+o bweschke] by ChanServ |
| 19:42.53 | eliel_ | Is there any macro to check the linux kernel version? |
| 19:43.48 | tzafrir_laptop | eliel_, what for? |
| 19:44.29 | Corydon76-dig | eliel_: yes |
| 19:44.31 | tzafrir_laptop | kernel we build with? kernel we run with? |
| 19:44.40 | eliel_ | tzafrir_laptop: 'core show sysinfo' is not working as expected |
| 19:44.49 | file | hello there bweschke |
| 19:44.57 | eliel_ | sysinfo has different minings if kernel >= 2.3.23 |
| 19:44.57 | bweschke | file: hi! hi! |
| 19:45.03 | Corydon76-dig | Afternoon, BeeJ |
| 19:45.19 | tzafrir_laptop | eliel_, and where did you dig up a system with an older kernel? |
| 19:45.24 | eliel_ | so, if we run 'core show sysinfo' on kernels >= 2.3.23 we see all 0s in the output |
| 19:45.53 | jsmith-teaching | Well if it isn't bweschke... how ya been? |
| 19:45.59 | tzafrir_laptop | eliel_, again, a test you do at build time is not for the running kernel |
| 19:46.00 | bweschke | Hey Tilghman! |
| 19:46.19 | bweschke | hey jared! been ok.. busy, as usual. :-/ |
| 19:47.08 | eliel_ | tzafrir_laptop: 'core show sysinfo' was expected to run on kernels < 2.3.23 thats is why it returns al 0s in the memory output. because sysinfo is already returning memory in blocks of memunit bytes, and we are dividing the return value again by mem_unit |
| 19:47.32 | tzafrir_laptop | eliel_, for instance, Zaptel is only supported from zaptel 2.4.8, I believe (and hasn't been tested with anything below 2.4.18 for quite some time) |
| 19:48.20 | tzafrir_laptop | eliel_, linux kernel < 2.3.23? Do you actually have such a system? And it builds Asterisk? |
| 19:48.38 | bweschke | how goes it with everyone else? |
| 19:48.55 | eliel_ | tzafrir_laptop: I don't have that, so that is why 'core show sysinfo' is giving me all 0s.. |
| 19:51.41 | eliel_ | tzafrir_laptop: hmmm, I think I found the problem... I will submit a patch... |
| 20:00.13 | eliel_ | submitted patch on issue 13057 to fix 'core show sysinfo' I don't know why this was working... |
| 20:00.13 | *** join/#asterisk-dev ctooley (n=ctooley@209.33.108.119) |
| 20:00.13 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 20:00.50 | ctooley | I joined asterisk-dev this morning and had been, up to this point, amazed at how little traffic there was. It was only a minute ago that I realized I had joined asterisk-devv |
| 20:00.56 | ctooley | which.... is not the same |
| 20:01.01 | seanbright | heh |
| 20:01.18 | seanbright | you missed a bunch. we rewrote asterisk today. |
| 20:01.28 | ctooley | oh, ok |
| 20:01.43 | ctooley | let me know when that branch dies and we revert back to reality |
| 20:03.51 | jtodd | Anyone here have experience with Linux driver interrupt coalescence for improving throughput with large numbers of channels? |
| 20:04.03 | seanbright | i think we all do |
| 20:04.18 | seanbright | except for me... i have no clue what you are talking about |
| 20:04.35 | jtodd | http://www.29west.com/docs/THPM/latency-interrupt-coalescing.html |
| 20:04.41 | jtodd | http://www.google.com/search?num=50&hl=en&newwindow=1&safe=off&q=interrupt+coalescing+linux&btnG=Search |
| 20:06.11 | jtodd | One of the current problems with "large" Asterisk installations (that are handling media) is the number of IRQs from the I/O cards overwhelms the CPU that is handling interrupts. |
| 20:07.06 | eliel_ | you can distributed irqs between processors, if you have more than one... |
| 20:07.11 | jtodd | This is what was run into with the tests at Sun, and others have run into it as well. Haven't seen a very good documentation on how to resolve that problem yet. |
| 20:07.57 | jtodd | eliel_: From what I've just been told, the irqbalance stuff will simply shift the IRQs to one CPU or the other, but it's still a firehose problem - too many IRQs pointed at whatever the target is. |
| 20:08.29 | jtodd | It sounds like interrupt coalescing might be a better solution, but I'm hoping someone has experience with it because I don't have the time or lab to try it out at the moment. :-) |
| 20:08.50 | eliel_ | hmmm, that is were my "knowledge" finish... |
| 20:13.31 | ctooley | jtodd, with proper hardware availability I could probably lab it. But, we don't have many cards. |
| 20:16.06 | russellb | i wonder if we could arrange something in exchange for documenting the test and its results :) |
| 20:18.36 | ctooley | Just let me know. |
| 20:20.30 | ctooley | Also, what kind of machine would you guys want to see it tested in? I don't have 8 core tower servers lying around unused at the moment. :) |
| 20:20.55 | ctooley | And how many, what kind of cards? |
| 20:22.00 | russellb | defers to jtodd |
| 20:23.33 | tzafrir_laptop | Cards? Isn't it the same issue with voip? |
| 20:23.43 | mvanbaak | yup |
| 20:23.58 | mvanbaak | udp and/or tcp packets are handled during interrupts as well |
| 20:24.04 | mvanbaak | Linux suffers from this big time |
| 20:24.06 | russellb | ctooley: FWIW, on the list, you've essentially described how things already work, unofficially |
| 20:24.20 | tzafrir_laptop | mvanbaak, also depends on the network adapter |
| 20:24.22 | tzafrir_laptop | IIRC |
| 20:24.24 | ctooley | russellb, in my -dev email or here? |
| 20:24.26 | mvanbaak | yup |
| 20:24.29 | russellb | ctooley: -dev email |
| 20:24.31 | ctooley | ah |
| 20:24.53 | ctooley | Then I'd vote for just making it a somewhat more official setup. |
| 20:25.38 | mvanbaak | broadcom, intel and sis have good stuff |
| 20:25.48 | russellb | shrugs |
| 20:25.49 | russellb | we shall see. |
| 20:25.54 | mvanbaak | they can handle moltiple packages per interrupt |
| 20:26.12 | russellb | ctooley: i don't feel like we're having any problems with the loose structure we have, but others may disagree. |
| 20:26.25 | russellb | ctooley: anyway, we should probably keep this on the list, sorry for bringing it here :0 |
| 20:26.27 | russellb | er, :) |
| 20:29.34 | *** join/#asterisk-dev hubguruJR (n=hubguruJ@mail.ntegratedsolutions.com) |
| 20:34.29 | *** join/#asterisk-dev Schmooze (n=Schmooze@rrcs-67-53-189-178.west.biz.rr.com) |
| 20:34.33 | ctooley | russellb, kthx |
| 20:40.13 | jtodd | ctooley, russelb: sorry, was away for a moment. I think even a dual-core machine would probably be sufficient for this test; it should be feasible to bog it down with sufficient RTP that interrupts will be what causes the blockage. |
| 20:40.53 | jtodd | I think that an interrupt test could be created with fairly modest hardware. You'd need 2 other systems producing the load, of course. |
| 20:41.05 | dioedu | hi all, i wanna know which module mixmonitor uses to record a call, because, after update from 1.4.19 to 1.4.20 or 1.4.21.1 the files are very bad... |
| 20:41.40 | jtodd | And as for cards on the interrupt test: I'd suggest Intel, but I don't know the model numbers. |
| 20:41.40 | bweschke | uses the spy module |
| 20:41.57 | bweschke | or is 1.4 using audiohooks now? |
| 20:41.58 | dioedu | the include of zaptel.h and ioctl.h in the asterisk.c could change this files ? |
| 20:42.20 | russellb | bweschke: audiohooks |
| 20:42.31 | bweschke | ah |
| 20:42.31 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 20:43.07 | *** part/#asterisk-dev hubguruJR (n=hubguruJ@mail.ntegratedsolutions.com) |
| 20:43.53 | jtodd | ctooley: Do you have three spare machines floating around of roughly equivalent horsepower? |
| 20:44.26 | dioedu | one thing important, chan_sip -> chan_sip i don't have any problem, just chan_khomp (a card from brazil) -> chan_sip that i have this problem... |
| 20:45.51 | mvanbaak | jtodd: is this about testing RTP on linux or just RTP in general ? |
| 20:45.55 | dioedu | curious that 1.4.19 doesn't have this problem... the record's staying with a high speed when i have audio both channels |
| 20:46.02 | mvanbaak | if the latter, try something besides linux |
| 20:46.11 | ctooley | jtodd, yeah |
| 20:46.16 | ctooley | at least 3 |
| 20:46.25 | mvanbaak | OpenBSD 4.3 has some cool stuff for pps |
| 20:46.57 | mvanbaak | they fixed some stuff so even the cheapass soekris hardware with SIS nics can do 99mbit traffic with very small packets |
| 20:47.41 | jtodd | mvanbaak: Well, this is right now a Linux test since that's the first OS that comes to mind with Asterisk. Linux first, then Solaris/BSD/etc. |
| 20:47.46 | putnopvut | dioedu: there's a bug report open right now. Let me find it. |
| 20:47.54 | mvanbaak | jtodd: fair enough |
| 20:48.05 | jtodd | mvanbaak: Of course, that's just my opinion. If anyone wants to test out with *NIX, go for it. |
| 20:48.16 | ctooley | jtodd, If SIP will do, I have 3 or 4 of them |
| 20:48.24 | putnopvut | M13005 |
| 20:48.27 | MuffinMan | [feedback] [Asterisk] Applications/app_mixmonitor 0013005: Recording speed too fast (running BRI B410P) reported by alexb_uk (Karma: neutral) http://bugs.digium.com/view.php?id=13005 |
| 20:48.30 | jtodd | I've got an OpenBSD 4.3 box sitting right here next to me. What's the packet coalescence kernel man page for that? |
| 20:48.50 | ctooley | But, those boxes won't do many TDM channels because they only have 1 slot in them. |
| 20:48.51 | jtodd | ctooley: Yes, SIP is perfect. RTP is RTP. |
| 20:48.59 | putnopvut | dioedu: the problem was reported using a BRI card, but someone else has reported that it's not necessarily a BRI-specific problem. |
| 20:49.26 | dioedu | putnopvut, ok... i'll see that... thanks |
| 20:49.30 | jtodd | ctooley: The point here is to generate a lot of RTP from Box [C,D,...] to Box A, and Box A just sends the calls to "Echo". |
| 20:49.32 | ctooley | jtodd, in that case, I'm game. |
| 20:49.58 | ctooley | jtodd, bah! I can do that with production traffic. :) |
| 20:50.01 | putnopvut | dioedu: there's no fix yet because I haven't been able to reproduce the issue yet, but just thought I'd let you know that it's a known issue at least. |
| 20:50.11 | jtodd | ctooley: then just crank up the number of calls until packets start dropping (testable by putting a "real" call through to Box A and listening to results, or watching packet loss stats on short calls) |
| 20:50.16 | ctooley | I could fill up a server with no issues. :) |
| 20:51.04 | ctooley | well, there'd be no issues with the ability to fill up the server, having the server provide good service is a different story. |
| 20:51.05 | jtodd | ctooley: Then once you hit the "maximum limit" of RTP with your test environment, use the IRQ coalescence kernel parameters (previously referenced via HTML link) to see if you can get more channels. |
| 20:51.36 | dioedu | putnopvut, i saw... i can help |
| 20:51.53 | dioedu | i can reproduce this error easily |
| 20:52.02 | jtodd | ctooley: the point here is to find the limit of the box (assuming the limit of the box is when you hit the wall with IRQ volume) and then testing to see if you get better results with the interrupt coalescence kernel setting. |
| 20:52.08 | mvanbaak | jtodd: be sure to test with intel and broadcom |
| 20:52.29 | jtodd | ctooley: of course, if the bottleneck isn't IRQs, then you have other issues to work out first. :-) |
| 20:52.31 | ctooley | mvanbaak, All I have are Intel and Broadcom boxes. |
| 20:52.33 | putnopvut | dioedu: it's interesting that you can't reproduce it with SIP -> SIP calls. There was a person who wrote a note saying he could. |
| 20:52.38 | mvanbaak | those are the two chipsets that handle the interupt stuf the best |
| 20:52.46 | snuff-away | mutters something about broadcom and their 2 piece driver that caused him issues with windows pxe booting |
| 20:52.53 | putnopvut | dioedu: I suspect there's some option somewhere that I need to enable in order to have the speedy recordings occur. |
| 20:53.16 | dioedu | yes, i saw that, but in my case, sip - sip i have no problem |
| 20:53.20 | mvanbaak | snuff-away: almost every vendor gives me trouble with windows pxe booting |
| 20:53.26 | mvanbaak | it's because they dont log anything :) |
| 20:53.54 | jtodd | ctooley: make sure you even are running a kernel and card that support InterruptThrottleRate |
| 20:53.54 | dioedu | putnopvut, but in the app_mixmonitor.c doesnt't have any changes in this versions |
| 20:54.01 | dioedu | right ? |
| 20:54.19 | snuff-away | i found out that binl is also v picky on case sensitivity.. took 4 hrs to work out why something wasn't loading |
| 20:54.21 | dioedu | i wanna know which module is called by mixmonitor |
| 20:54.37 | putnopvut | dioedu: that is correct. However audiohook.c (which is used by app_mixmonitor.c) does have a change which I suspect causes the issue to occur. |
| 20:54.48 | dioedu | ok |
| 20:54.52 | dioedu | let me see |
| 20:55.13 | putnopvut | dioedu: there was a bug reported that mixmonitor had out-of-sync audio, and so some code was added to correct this. I think this is what is causing the new problem. |
| 20:55.15 | jtodd | ctooley: Interrupt moderation paper from Intel on their gigabit drivers: http://download.intel.com/design/network/applnots/ap450.pdf |
| 20:55.34 | mvanbaak | snuff-away: we use pxeboot to boot linux, freebsd and openbsd. and it's been very sweet to us |
| 20:56.06 | mvanbaak | jtodd: intel has a couple of gigabit drivers. some are good, some dont do more then roughly 200mbit |
| 20:56.16 | *** part/#asterisk-dev bweschke (n=BJ_Wesch@c-76-124-82-215.hsd1.nj.comcast.net) |
| 20:56.24 | ctooley | marks Interrupt Coalescence down on his lab test schedule. |
| 20:56.29 | *** join/#asterisk-dev bweschke (n=BJ_Wesch@c-76-124-82-215.hsd1.nj.comcast.net) |
| 20:56.30 | *** mode/#asterisk-dev [+o bweschke] by ChanServ |
| 20:56.32 | ctooley | Now all I have to do is find lab time |
| 20:56.41 | snuff-away | mm we are using 'Ultimate Deployment Appliance' for that allows us not to get 'down low' all the time manage from gui |
| 20:56.50 | jtodd | mvanbaak: Any ideas which cards/chips are the "good" ones? |
| 20:57.43 | mvanbaak | jtodd: cards listed here are very good: |
| 20:57.44 | mvanbaak | http://www.openbsd.org/cgi-bin/man.cgi?query=em&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html |
| 20:58.00 | mvanbaak | yeah, it's an OpenBSD manual page |
| 20:58.03 | russellb | putnopvut: nice optimization |
| 20:58.09 | mvanbaak | but the same cards work great in Linux as well |
| 20:58.47 | mvanbaak | make sure you get a model with checksum offload and jumbo frames |
| 20:59.05 | jtodd | mvanbaak: so as a side note does OpenBSD support interrupt moderation/coalescence? |
| 20:59.24 | dioedu | putnopvut, out-of-sync... i have a problem like this... do you know what is the bug report ? let me find... |
| 20:59.28 | mvanbaak | yup |
| 20:59.29 | jtodd | mvanbaak: how would jumbo frame help in this situation? These are all tiny packets. |
| 20:59.49 | mvanbaak | jtodd: the boards with jumbo frame handling are the better ones |
| 20:59.57 | mvanbaak | they have more logic directly on the nic |
| 21:00.10 | jtodd | OK, I see. It's not the jumbo frame capability itself; that's just a marker for 'better' chips/boards. |
| 21:00.17 | mvanbaak | yup |
| 21:00.38 | jtodd | mvanbaak: where are the flags for interrupt moderation kept in the OpenBSD drivers? |
| 21:01.07 | putnopvut | dioedu: 12996 maybe |
| 21:01.09 | putnopvut | M12996 |
| 21:01.10 | MuffinMan | [closed] [DAHDI] Utilities/* 0012996: [patch] dahdi.init not correct for Debian reported by mvanbaak (Karma: +41.75) http://bugs.digium.com/view.php?id=12996 |
| 21:01.17 | putnopvut | oops, not that one. |
| 21:01.23 | putnopvut | M12296 |
| 21:01.26 | MuffinMan | [closed] [Asterisk] Applications/app_mixmonitor 0012296: MixMonitor with 'b' option record the 'Ringing' and audio is out of sync reported by jvandal (Karma: +2.75) http://bugs.digium.com/view.php?id=12296 |
| 21:01.37 | putnopvut | or |
| 21:01.42 | mvanbaak | jtodd: I'm not into that so deeply. |
| 21:01.43 | putnopvut | M11945 |
| 21:01.47 | MuffinMan | [closed] [Asterisk] Applications/app_mixmonitor 0011945: MixMonitor - Out Of Sync Audio With Zap Channels reported by xheliox (Karma: neutral) http://bugs.digium.com/view.php?id=11945 |
| 21:01.54 | mvanbaak | but I do know they did a lot of work on that in the last hacketon |
| 21:02.21 | mvanbaak | as far as I know they did it in the network stack, and just probe the card if it's capable of doing it |
| 21:03.05 | mvanbaak | it was two commits and they fixed the stuff for sis, em and broadcom in one go |
| 21:15.28 | *** join/#asterisk-dev eliel (n=eliel@host-cotesma-163-176.smandes.com.ar) |
| 21:21.35 | mvanbaak | blegh |
| 21:21.50 | mvanbaak | time to attend 'basic course C programming' again |
| 21:21.58 | mvanbaak | everything I try fails badly |
| 21:22.16 | codefreeze-lap | Tilghman-- reviewing your changes from 128027 |
| 21:23.12 | mvanbaak | what's this phoneprov stuff anywayz ? |
| 21:23.58 | eliel | ping snuffy |
| 21:24.28 | *** part/#asterisk-dev Rem| (n=remi@bg-fw2out.monmouth.com) |
| 21:24.38 | tzafrir_laptop | mvanbaak, polycom phones, IIRC |
| 21:24.56 | russellb | can be used for any phones that provision over http, though |
| 21:25.07 | mvanbaak | hhmm, interesting |
| 21:25.22 | mvanbaak | so we can use it for snom and grandstream as well eh? |
| 21:25.23 | tzafrir_laptop | Is there any other type that is supported, in practice? |
| 21:25.24 | Corydon76-dig | codefreeze-lap: cool |
| 21:25.52 | snuff-away | eliel: ? |
| 21:26.22 | eliel | snuff: Which typo error are you talking about in issue: 13057? |
| 21:26.38 | mvanbaak | blegh, only a .tex file in doc/ for phoneprov |
| 21:27.02 | snuff-away | mm in the patch.. there is .. |
| 21:27.06 | snuff-away | mm its gone now |
| 21:27.15 | russellb | mm i dunno |
| 21:27.17 | snuff-away | stupid opera must have rendered wrong 1st time |
| 21:27.30 | eliel | snuff: ok |
| 21:27.32 | snuff-away | dels note |
| 21:28.00 | snuff-away | basically i seen.. + ast_cli(sdfsdfsdfsdf + ast_cli |
| 21:28.11 | snuff-away | on same line |
| 21:28.26 | eliel | snuff: ok, thanks anyway |
| 21:29.21 | mvanbaak | ah, the phoneprov stuff relies on users.conf |
| 21:29.28 | russellb | snuff-away: so um, what time is it? |
| 21:29.36 | mvanbaak | Thu Jul 10 23:29:36 CEST 2008 |
| 21:30.11 | snuff-away | Fri Jul 11 07:33:49 EST 2008 |
| 21:30.25 | russellb | snuff-away: did you just get up or never go to bed? :) |
| 21:30.51 | snuff-away | mm was up at 6 this morning.. no idea why.. generally i make the motions at 645 |
| 21:30.58 | russellb | gotcha. |
| 21:31.06 | russellb | felt like i had seen you around all day, just wondering :) |
| 21:31.33 | snuff-away | mm well u get in close to 10-11pm |
| 21:32.27 | snuff-away | i'm hoping after we fix said alignment issues with sparc i can produce a little doco of what u need to have to get * running in general on solaris x86 / sparc |
| 21:32.42 | snuff-away | aka libraries etc |
| 21:33.49 | snuff-away | maybe i get time today to retest kpfleming's branch.. but need to rebuild that server cause i dont trust it |
| 21:34.14 | dioedu | putnopvut, bug fixed |
| 21:35.03 | putnopvut | dioedu: Awesome, how did you fix it? |
| 21:35.27 | dioedu | well, i don't know if cause other problem, like "out of sync" |
| 21:35.59 | *** join/#asterisk-dev geek_cl (n=geek@190.54.42.62) |
| 21:36.32 | dioedu | but i commented a part of code in audiohook.c... |
| 21:37.10 | dioedu | that check sync trigger |
| 21:37.27 | geek_cl | hi, guys, anyone can see http://fpaste.org/paste/3434 please? |
| 21:38.00 | dioedu | know i need to know what is wrong in this function... |
| 21:38.19 | dioedu | because it doesn't here for nothing |
| 21:38.20 | dioedu | right ? |
| 21:38.21 | dioedu | :) |
| 21:38.23 | geek_cl | i need compile for chan_mobile |
| 21:38.39 | putnopvut | dioedu: That part is what was added to prevent the out-of-sync recordings. |
| 21:39.05 | putnopvut | geek_cl: did you backport chan_mobile from trunk to 1.4? |
| 21:39.28 | dioedu | in my test, i don't have this problem "out of sync" but i did tests with 1 minute call duration |
| 21:40.22 | geek_cl | Not really |
| 21:41.19 | putnopvut | geek_cl: it looks like the asterisk trunk version of CLI command execution is attempted to be used against the Asterisk 1.4 code base. |
| 21:41.58 | codefreeze-lap | Hot day today. My room thermom reads 97 F. The swamp cooler is blowing dry outside air. Gotta get that fixed. |
| 21:42.17 | putnopvut | codefreeze-lap: that must be miserable. |
| 21:42.18 | geek_cl | putnopvut> nope, asterisk is not running |
| 21:42.35 | codefreeze-lap | The moving dry air makes it bearable. |
| 21:43.01 | putnopvut | geek_cl: sorry I wasn't clear. What I meant is, did you compile Asterisk version 1.4 and then try to compile the trunk version of Asterisk add-ons? That won't work. |
| 21:43.34 | Corydon76-dig | codefreeze-lap: I was in the crawlspace of my house last Friday. It's nice and cool under there. |
| 21:43.55 | codefreeze-lap | Corydon76-dig: must have been nighttime! |
| 21:44.01 | geek_cl | putnopvut: uhmmm but http://www.chan-mobile.org/?page_id=5 it's wrong ? |
| 21:44.09 | geek_cl | then is all for trunk? |
| 21:44.14 | Corydon76-dig | codefreeze-lap: I need to go down there with some duck tape and seal up some of the ducts |
| 21:44.46 | Corydon76-dig | I'm sure some of the tape down there is 22 years old... |
| 21:44.59 | Corydon76-dig | (and has come unstuck) |
| 21:45.12 | putnopvut | geek_cl: did you apply the patch mentioned on that page? |
| 21:45.18 | codefreeze-lap | Corydon76-dig: Thank goodness for duct tape! |
| 21:45.21 | geek_cl | yes |
| 21:45.44 | Corydon76-dig | codefreeze-lap: "duck" tape, actually |
| 21:46.04 | russellb | duck brand duct tape? :) |
| 21:46.10 | geek_cl | yes |
| 21:46.12 | codefreeze-lap | Depends on who you buy it from... Some do say "duck". |
| 21:46.17 | russellb | right, brand |
| 21:46.26 | Corydon76-dig | Originally used to seal ammo cases, so they would be "dry as a duck" |
| 21:46.33 | putnopvut | geek_cl: I just looked at the patch and there's no way that it could work. All the patch does is to change ast_debug calls to ast_log calls. |
| 21:46.40 | Corydon76-dig | (before duct work was common under houses) |
| 21:46.50 | russellb | oic |
| 21:46.54 | russellb | sits corrected |
| 21:46.58 | putnopvut | geek_cl: much more is needed to convert from trunk to 1.4. I'm guessing that patch is very old. |
| 21:47.04 | codefreeze-lap | me too. |
| 21:47.41 | putnopvut | geek_cl: oh, and for some reason it removes the dependency on bluetooth. That's just strange. |
| 21:47.56 | dioedu | putnopvut, do you want that i write a report in the bug mantis ? |
| 21:48.00 | geek_cl | yes |
| 21:48.02 | putnopvut | dioedu: yes please. |
| 21:48.19 | codefreeze-lap | my wife loves me! She sent in a cup filled with an icy smoothie (chocolate). |
| 21:48.22 | geek_cl | <putnopvut>: then,... what do you suggest me, all asterisk from trunk ? |
| 21:48.25 | Corydon76-dig | russellb: the oil on a duck's feathers keeps the water off its skin, which allows it to launch into the air off the water |
| 21:48.41 | putnopvut | geek_cl: yes |
| 21:48.41 | russellb | neato |
| 21:48.42 | Corydon76-dig | russellb: if the feathers became waterlogged, waterfowl would not be able to do that |
| 21:49.11 | codefreeze-lap | Corydon76-dig: picture a 20 pound wet duck trying to launch anywhere.... |
| 21:49.17 | geek_cl | Ok, many any thanks |
| 21:49.31 | Corydon76-dig | codefreeze-lap: 40 lb eagle? |
| 21:50.02 | codefreeze-lap | I think, with my chest-waders filled, I could top 300 lbs. |
| 21:51.04 | *** part/#asterisk-dev bweschke (n=BJ_Wesch@c-76-124-82-215.hsd1.nj.comcast.net) |
| 21:51.57 | geek_cl | <putnopvut>: i will do , that you say right now :) |
| 21:54.52 | codefreeze-lap | Corydon76-dig: on a less frivolous note, the code to remove extens has a bug or two... it's leaving dead hashtab entries either way. Trying to figure out why... tedious code... |
| 21:56.40 | Corydon76-dig | k |
| 21:56.52 | Corydon76-dig | I thought I had it, but maybe not |
| 21:58.20 | dioedu | putnopvut, just to confirm, in the diff command, first is the original file or the update file ? |
| 21:58.25 | dioedu | :p |
| 21:58.32 | putnopvut | dioedu: first is the original file |
| 21:58.59 | mvanbaak | dioedu: I learned: diff -ruN orig.tree patched.tree |
| 21:59.07 | putnopvut | dioedu: don't forget to use the -u flag for diff so that the result is in unified format. |
| 21:59.31 | putnopvut | looks up what -N does |
| 21:59.43 | Qwell | new files |
| 21:59.55 | mvanbaak | putnopvut: it shows added files as well |
| 22:00.09 | mvanbaak | the orig line will have 01-01-1970 as date ;) |
| 22:00.19 | mvanbaak | which means: non-existant |
| 22:00.25 | putnopvut | Unix timestamp of 0. |
| 22:00.29 | mvanbaak | yup |
| 22:00.50 | Qwell | can you have a 0? |
| 22:00.59 | Qwell | I guess so |
| 22:01.01 | putnopvut | I can have a Coke Zero. |
| 22:01.02 | mvanbaak | yup |
| 22:01.05 | snuff-away | mmm.. why does buildbot.digium.com show trunk = non compile (TONEZONE error in configure) |
| 22:01.13 | mvanbaak | date("d-m-Y", 0); |
| 22:01.23 | mvanbaak | that works |
| 22:01.43 | bbryant | eliel: what kernel version are you running on the machine you were having sysinfo problems with? |
| 22:01.50 | file | snuff-away: because it hasn't been reconfigured to do dahdi stuff yet, and I haven't had time to play with it |
| 22:02.13 | snuff-away | ah knew there would be good reason :) |
| 22:02.17 | eliel | bbryant: 2.6.24-19 |
| 22:04.32 | eliel | bbryant: when I run this command I get all 0s. I checked manpages for sysinfo and they say that sysinfo return in mem_unit units the number of bytes of memory, so I couldn't find why it was being divided the result by mem_unit. |
| 22:04.55 | bbryant | eliel: you're correct, i was trying to figure out why i got the right answer, but it was because mem_unit was 1 |
| 22:05.23 | dioedu | putnopvut, done. thanks for your help |
| 22:05.27 | eliel | bbryant: great. |
| 22:06.36 | dioedu | tomorrow i'll try to discover a better solution for it... |
| 22:20.15 | mvanbaak | I'm off to bed |
| 22:20.18 | mvanbaak | latero all |
| 22:24.37 | *** join/#asterisk-dev RoyK (n=roy@ti211210a080-3097.bb.online.no) |
| 22:25.08 | *** join/#asterisk-dev qdk (n=qdk@0x573fe57e.bynqu2.static.dsl.tele.dk) |
| 22:29.27 | bbryant | eliel: i've added a patch to your bug if you don't mind testing it |
| 22:30.05 | eliel | bbryant: let me try |
| 22:36.16 | eliel | bbryant: It is working fine |
| 22:37.25 | bbryant | alright, thanks |
| 22:43.05 | tzafrir_laptop | snuff-away, configure errors where, exactly? what version of asterisk? |
| 22:55.14 | *** part/#asterisk-dev mog (n=mog@c-68-62-219-86.hsd1.al.comcast.net) |
| 23:35.37 | *** join/#asterisk-dev jbot (i=ibot@pdpc/supporter/active/TimRiker/bot/apt) |
| 23:35.37 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- IAX2/guest@pbx.digium.com/asterisk-dev -=- Asterisk trunk: res_telepathy release tomorrow-=- Tier 2 and Tier 3.14159 support is in #asterisk -=- Automated Builds, thx file! - http://buildbot.digium.com -=- Yay to russellb for tracking down a nasty deadlock! |
| 23:35.38 | putnopvut | Okay, I'm not sure what you're talking about now. |
| 23:35.53 | putnopvut | You want me to start MixMonitor, do a Record(), and then a dial? |
| 23:35.57 | file | yes |
| 23:36.01 | putnopvut | gotcha |
| 23:36.09 | file | Record() will only be reading frames in, it won't be writing frames out |
| 23:36.21 | file | when you do the Dial() frames will both be read in and written out |
| 23:36.31 | putnopvut | ah, I see. |
| 23:37.03 | putnopvut | Also, in ast_audiohook_init, I'm curious why only one slinfactory is initialized. |
| 23:37.19 | file | it isn't |
| 23:37.21 | file | both are :) |
| 23:37.27 | file | there isn't a break under TYPE_SPY |
| 23:37.36 | putnopvut | Ah, I mentally placed a break there. |
| 23:39.30 | *** join/#asterisk-dev IamTux (n=kman@64.5.9.121) |
| 23:39.55 | IamTux | hello |
| 23:40.32 | putnopvut | file: one-way audio :( |
| 23:40.56 | file | really? interesting |
| 23:41.01 | file | IamTux: hello. |
| 23:42.08 | IamTux | I am trying to have a sip extension dial out a specific zap channel only (e.g. ext 101 dials out zap/1 ext 102 out zap/2... etc.) |
| 23:42.34 | snuff-work | sounding more like #asterisk question.. |
| 23:42.44 | IamTux | kk |
| 23:43.11 | IamTux | anyone figure out how to flash the CO yet ? |
| 23:44.01 | IamTux | that has been a big project that I have been trying to get working also |
| 23:44.45 | putnopvut | file: adding an Answer prior to the MixMonitor made the audio two-way. |
| 23:45.06 | file | huh |
| 23:45.34 | putnopvut | there are some goofy things going on here. I need to figure this dookie out. |
| 23:45.38 | snuff-work | 2nd part of call not setup until answer? |
| 23:46.26 | putnopvut | snuff-work: No idea. When I add the answer prior to MixMonitor, the call isn't actually recorded. |
| 23:46.35 | snuff-work | mm bizzare |
| 23:47.50 | putnopvut | I need to write up a summary of everything and pastebin it, because everything seems to have a unique issue. |
| 23:48.16 | putnopvut | Actually no need to pastebin. |
| 23:48.29 | putnopvut | Record and then Mixmonitor causes one-way audio. |
| 23:48.52 | putnopvut | Answer, record, then Mixmonitor has two-way audio, but Mixmonitor doesn't record anything (Record does though) |
| 23:48.58 | putnopvut | oops. |
| 23:49.12 | putnopvut | I have that completely out of whack. Ignore everything I've said. |
| 23:49.14 | putnopvut | :) |
| 23:49.50 | putnopvut | I'll get to the bottom of this! |
| 23:52.37 | *** join/#asterisk-dev IamTux (n=kman@64.5.9.121) |
| 23:55.59 | sruffell | probably I am missing something, but I don't see how I can make a mantis filter that sees more than one project at a time.. (i.e. I would like for my view to include both existing zaptel issues and DAHDI issues...) am I missing something? |
| 23:56.12 | sruffell | at http://bugs.digium.com that is. |
| 23:59.15 | putnopvut | sruffell: I can't say I've ever tried doing that. |
| 23:59.36 | sruffell | hmm.... |