| 00:01.42 | jsmith | Corydon76-dig: Oh really... |
| 00:13.33 | Corydon76-dig | Yep, because IAXVAR depends upon datastore inheritance working |
| 00:54.13 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-20-153.hsd1.sc.comcast.net) |
| 00:54.13 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 00:59.30 | *** join/#asterisk-dev russellb (n=russellb@asterisk/developer-and-stable-maintainer/drumkilla) |
| 00:59.30 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 01:00.29 | *** join/#asterisk-dev Juggie (n=Juggie@CPE001601df17fb-CM001a6682d7b6.cpe.net.cable.rogers.com) |
| 01:00.29 | *** join/#asterisk-dev awk (n=awk@security.web.za) |
| 01:40.27 | *** join/#asterisk-dev mvanbaak_ (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 01:40.27 | *** mode/#asterisk-dev [+o mvanbaak_] by ChanServ |
| 02:20.44 | *** join/#asterisk-dev kamanashisroy (n=kamanash@119.30.34.3) |
| 02:39.05 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 02:39.05 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 02:57.53 | *** join/#asterisk-dev jameswf-home (n=james@ip72-223-0-183.ph.ph.cox.net) |
| 03:07.50 | *** join/#asterisk-dev luxxx77 (n=luxxx77@e176229022.adsl.alicedsl.de) |
| 03:40.47 | *** join/#asterisk-dev juanjoc (n=juanjoc@host162.200-45-97.telecom.net.ar) |
| 03:43.26 | *** join/#asterisk-dev mvanbaak (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 03:43.26 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 04:15.34 | *** join/#asterisk-dev jsolis (n=jimmy@200.106.75.107) |
| 04:45.43 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@bzq-179-75-202.static.bezeqint.net) |
| 04:45.43 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 04:59.43 | *** join/#asterisk-dev denon (n=denon@tooth.decay.org) |
| 05:04.02 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-20-153.hsd1.sc.comcast.net) |
| 05:04.02 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 05:06.33 | *** join/#asterisk-dev jeffspeff (i=jeff@c-98-240-113-135.hsd1.ky.comcast.net) |
| 05:54.12 | *** join/#asterisk-dev kamanashisroy (n=kamanash@119.30.34.3) |
| 06:17.55 | *** join/#asterisk-dev obnauticus (n=obnautic@about/windows/regular/obnauticus) |
| 06:21.58 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 06:21.58 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 07:24.39 | *** join/#asterisk-dev steliosk (n=Stelios@91.140.115.22) |
| 10:02.14 | *** join/#asterisk-dev jeffspeff2 (i=jeff@c-98-240-113-135.hsd1.ky.comcast.net) |
| 10:08.51 | *** join/#asterisk-dev gones (n=gones@203.193.37.251) |
| 10:16.45 | *** join/#asterisk-dev oej (n=olle@193.214.109.195) |
| 10:16.45 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 10:37.38 | *** join/#asterisk-dev steliosk (n=Stelios@91.140.115.22) |
| 11:35.03 | *** join/#asterisk-dev eliel (n=eliel@200.61.172.61) |
| 11:51.36 | *** join/#asterisk-dev IsUp (n=nocturne@88.255.77.200) |
| 11:57.21 | *** join/#asterisk-dev moy (n=moy@CPE000d9d59afef-CM00140454d33e.cpe.net.cable.rogers.com) |
| 11:58.04 | eliel | good morning |
| 11:58.34 | eliel | mvanbaak: Did you have time to review the colorization commit? |
| 12:03.20 | tzafrir_laptop | kpfleming, here? |
| 12:10.04 | *** join/#asterisk-dev russellb (n=russellb@asterisk/developer-and-stable-maintainer/drumkilla) |
| 12:10.04 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 12:14.01 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:28.41 | *** join/#asterisk-dev bbryant (n=Brett_Br@adsl-212-77-233.chs.bellsouth.net) |
| 12:28.41 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 12:32.39 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:32.39 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 12:37.36 | *** join/#asterisk-dev JunK-Y (n=junky@modemcable156.137-20-96.mc.videotron.ca) |
| 12:43.39 | *** join/#asterisk-dev DarylVOIP (n=daryl@75.147.121.177) |
| 13:12.38 | lmadsen | morning all! |
| 13:20.28 | lmadsen | anyone here running Debian Lenny or kernel 2.6.26? |
| 13:28.00 | atis_work | lmadsen: on home router, want to test anything? |
| 13:28.33 | atis_work | lmadsen: but it's 2.6.25-2 |
| 13:28.43 | lmadsen | atis_work: well there is a bug that people can't compile zaptel on 2.6.26. I'm not even entirely sure if we want to support that or not... |
| 13:28.51 | lmadsen | kpfleming might be able to answer that question |
| 13:28.57 | lmadsen | 2.6.25 != 2.6.26 :) |
| 13:29.10 | lmadsen | oh but its probably running Lenny eh? :) I guess I assumed Lenny == 2.6.26 |
| 13:29.26 | atis_work | lmadsen: oh, sorry, it's sid already :p |
| 13:29.31 | lmadsen | heh |
| 13:29.33 | atis_work | but it's more fresh than lenny |
| 13:29.38 | atis_work | sid = unstable |
| 13:29.38 | lmadsen | I know nothing about Debian :) |
| 13:29.43 | lmadsen | gotcha |
| 13:29.53 | atis_work | lenny = testing (currently) |
| 13:32.07 | atis_work | lmadsen: if you throw me a patch, i could test (just for compile) on sid |
| 13:32.54 | atis_work | there shouldn't be any 2.6.26 on debian |
| 13:36.59 | *** join/#asterisk-dev mog (n=mog@nat/digium/x-ad3699e575f6eab7) |
| 13:36.59 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 13:37.17 | tzafrir_laptop | lmadsen, Lenny 2.6.25-2 here |
| 13:37.50 | tzafrir_laptop | (Sid currently has 2.6.26) |
| 13:38.07 | lmadsen | ahh, then someone told me wrong :) |
| 13:38.21 | tzafrir_laptop | What did they tell you? |
| 13:38.32 | tzafrir_laptop | I believe Lenny will eventually have 2.6.26 |
| 13:38.37 | lmadsen | well they told me Lenny and 2.6.26, but I guess that is really Sid (or something) |
| 13:38.50 | lmadsen | must have been an upgraded Lenny box |
| 13:39.03 | lmadsen | M13308 |
| 13:39.04 | MuffinMan | [new] [Asterisk] Core/General 0013308: ztdummy gives unresolved symbols on Linux kernel 2.6.26.1 reported by ssh (Karma: neutral) http://bugs.digium.com/view.php?id=13308 |
| 13:39.11 | lmadsen | that's why I was asking :) |
| 13:39.24 | tzafrir_laptop | 2.6.26.1 is self-compiled, not from a package |
| 13:39.55 | lmadsen | someone else had mentioned that on #asterisk this morning though as well using the 2.6.26 kernel on what I suppose is Sid |
| 13:42.11 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 13:42.31 | lmadsen | but you're right that I might need to ask them to reproduce on a stock distro kernel |
| 13:43.39 | tzafrir_laptop | It is a stock kernel. Anyway, answered it. |
| 13:44.08 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 13:44.30 | lmadsen | oh ok, thanks tzafrir_laptop ! |
| 13:51.15 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 14:02.25 | *** join/#asterisk-dev corramor (n=corramor@nat/digium/x-e79e2131cf041faf) |
| 14:05.11 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) |
| 14:05.44 | atis_work | tzafrir_laptop: i just checked possible upgrades for sid, it's still 2.6.25-2 |
| 14:06.20 | atis_work | tzafrir_laptop: ooh, sorry, my mistake.. there's also linux-image-2.6.26-1-686{a} in added section |
| 14:06.57 | tzafrir_laptop | try: rmadison linux-headers-2.6.26-1-all |
| 14:07.02 | atis_work | upgrading.. hope that nothing will fail :) |
| 14:07.21 | tzafrir_laptop | half an hour ago it wasn't in testing, I think |
| 14:11.41 | *** join/#asterisk-dev [xpl] (i=xpl@84.126.207.62.dyn.user.ono.com) |
| 14:21.52 | atis_work | ooh, unsuccessful.. so, now i'm left with my home router down after upgrade :p |
| 14:30.38 | *** join/#asterisk-dev jeffspeff (i=jeff@c-98-240-113-135.hsd1.ky.comcast.net) |
| 14:33.02 | *** join/#asterisk-dev jeffspeff2 (i=jeff@c-98-240-113-135.hsd1.ky.comcast.net) |
| 14:39.38 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.95.130) |
| 14:46.09 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 14:46.09 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 14:48.37 | *** join/#asterisk-dev Laureano (n=Laureano@190.245.108.2) |
| 14:56.31 | *** join/#asterisk-dev jeffspeff (i=jeff@c-98-240-113-135.hsd1.ky.comcast.net) |
| 15:03.22 | *** join/#asterisk-dev putnopvut (n=putnopvu@nat/digium/x-3b6f2d7a9f9dd5e3) |
| 15:03.22 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:14.14 | *** join/#asterisk-dev jeffspeff2 (i=jeff@c-98-240-113-135.hsd1.ky.comcast.net) |
| 15:22.52 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 15:45.54 | lmadsen | when I run 'make config' in DAHDI linux-complete, it tells me to set an ideal MODULES variable, but there is no example of what that should be set to. Would it make sense for that to be updated? |
| 15:48.12 | *** join/#asterisk-dev smurf (n=smurf@debian/developer/smurf) |
| 15:51.39 | tzafrir_laptop | lmadsen, the wording is incorrect . Edit /etc/dahdi/modules |
| 15:51.59 | lmadsen | oh ok, that makes more sense |
| 15:55.51 | lmadsen | wonder if I should report that as a bug... |
| 15:56.27 | *** join/#asterisk-dev jameswf-home (n=james@dsl093-157-131.phx1.dsl.speakeasy.net) |
| 15:56.48 | lmadsen | I'll look this afternoon and see if I can come up with a patch for some documentation |
| 15:56.54 | lmadsen | I've seen a couple things now |
| 15:59.23 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.8.157) |
| 16:11.32 | tzafrir_laptop | zaptel fails to build with kernel 2.6.27-rc: it's the same semaphore.h thing from http://svn.digium.com/view/zaptel?view=rev&revision=4496 |
| 16:14.25 | Qwell | did they change it again or something? |
| 16:16.58 | tzafrir_laptop | I figure wctc4xxp was re-added after r4496 |
| 16:17.07 | Qwell | oh |
| 16:17.19 | Qwell | that's probably right |
| 16:19.16 | Qwell | actually, nope |
| 16:23.47 | tzafrir_laptop | ah, so that's my old version from 1.4.11 |
| 16:24.24 | tzafrir_laptop | is stuck with 1.4.11 on the Debian package :-( |
| 16:26.48 | lmadsen | hrmmm... wonder if there should be a test to make sure zaptel stuff isn't running when you go to start up dahdi |
| 16:26.52 | lmadsen | I just got burned by that :) |
| 16:31.39 | *** join/#asterisk-dev eliel (n=eliel@200.61.172.61) |
| 16:33.02 | *** join/#asterisk-dev mvanbaak_ (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 16:33.02 | *** mode/#asterisk-dev [+o mvanbaak_] by ChanServ |
| 16:53.13 | tzafrir_laptop | lmadsen, zaptel and dahdi currently can't be loaded at the same time |
| 16:53.28 | tzafrir_laptop | both try to register major number 196 |
| 16:53.52 | lmadsen | right, thats what I ran into, but dahdi I think should detect the zaptel drivers being loaded and tell you thats the problem |
| 16:54.05 | tzafrir_laptop | Actually, there is mostly no need for a static major number . Unless you use static device files |
| 16:54.08 | lmadsen | once I unloaded zaptel (which I forgot I had loaded because its just a VM), then it was cool |
| 16:54.16 | tzafrir_laptop | Anybody actually uses static device files? |
| 16:54.55 | tzafrir_laptop | lmadsen, some of the drivers even have the same name . What happens when you run 'modprobe wctdm'? |
| 16:55.09 | lmadsen | hrmmm, thats true too I suppose |
| 16:55.13 | tzafrir_laptop | Depends on the first wctdm you have |
| 16:55.17 | lmadsen | right |
| 17:04.41 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 17:16.38 | *** join/#asterisk-dev Deeewayne (n=Deeewayn@nat/digium/x-2221ab5d258f1ff3) |
| 17:16.38 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 17:31.52 | *** join/#asterisk-dev km- (n=pgrace@2001:4830:1215:2:20c:29ff:fee9:9689) |
| 17:45.13 | *** part/#asterisk-dev Rem| (n=remi@bg-fw2out.monmouth.com) |
| 17:49.16 | tzafrir_laptop | hmm.... this seems to expose an "interesting" race |
| 17:49.30 | tzafrir_laptop | insmod dahdi |
| 17:49.35 | tzafrir_laptop | insmod zaptel |
| 17:49.58 | tzafrir_laptop | it will fail to load , but not clean up everything |
| 17:52.33 | tzafrir_laptop | in zt_init: |
| 17:53.19 | tzafrir_laptop | register_chardev is done after we create the devices |
| 17:53.29 | tzafrir_laptop | And if it fails we don't remove them |
| 17:53.57 | tzafrir_laptop | now have /dev/zap/ctl and for this reason Asterisk can't start :-( |
| 18:56.20 | *** join/#asterisk-dev DarylVOIP (n=daryl@75.147.121.177) |
| 19:03.55 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:07.24 | *** join/#asterisk-dev korihor (n=korihor@200.7.99.2) |
| 19:59.02 | codefreeze-lap | seanbright: about freetds |
| 20:00.01 | codefreeze-lap | seanbright: is trunk updated to work with 0.82? |
| 20:04.30 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 20:14.14 | russellb | putnopvut: in app_queue, if a caller into a queue gets bridged to an agent, will the queue application always return -1 (thus, hanging up on the caller) when it exits? |
| 20:14.39 | putnopvut | russellb: It should unless the c option is specified. I think that's 1.6.0 and up. |
| 20:14.47 | putnopvut | Let me double-check, for sanity's sake. |
| 20:14.47 | russellb | Ok, thanks. |
| 20:15.01 | *** join/#asterisk-dev jeffspeff (i=jeff@c-98-240-113-135.hsd1.ky.comcast.net) |
| 20:18.24 | putnopvut | russellb: I believe you are correct. If bridged to a queue member, app_queue will return non-zero. |
| 20:18.34 | russellb | got it |
| 20:18.35 | russellb | thanks |
| 20:21.28 | dioedu | hi all, the column cat_metric in realtime static configuration of zapata.conf doesn't work... this is a bug or a default configuration ? |
| 20:22.44 | dioedu | i can configure many zap channels just changing var_metric... if i have more than one value in cat_metric, asterisk doesn't recognize it... |
| 20:26.22 | seanbright | codefreeze-lap: yes |
| 20:26.43 | seanbright | codefreeze-lap: it should work with all versions of freetds |
| 20:26.57 | seanbright | codefreeze-lap: and i have a developer branch where i am backporting it to 1.4 |
| 20:27.08 | Qwell | seanbright: 0.23? |
| 20:27.25 | seanbright | only tested .60+ |
| 20:28.34 | seanbright | codefreeze-lap: i have the code itself backported, just working on the build system foo required to make it work |
| 20:28.56 | *** join/#asterisk-dev mvanbaak_ (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 20:28.56 | *** mode/#asterisk-dev [+o mvanbaak_] by ChanServ |
| 20:29.07 | seanbright | codefreeze-lap: i am being too fancy for menuselect though so i might just dumb it down and allow the user to compile and install both versions |
| 20:31.23 | seanbright | codefreeze-lap: why? what's up? |
| 20:32.56 | jpeeler | Corydon76-dig: what do i need to look at for the terminal colors? i haven't changed anything, but my background is white instead of black |
| 20:33.18 | Corydon76-dig | jpeeler: add -W to the startup options |
| 20:33.28 | jpeeler | still white |
| 20:33.46 | Corydon76-dig | jpeeler: asterisk -vvvvcgW ? |
| 20:34.01 | jpeeler | Corydon76-dig: yep |
| 20:34.51 | putnopvut | jpeeler: is the text easier to read with -W though? |
| 20:34.54 | dioedu | someone could tell me if this is a bug ? |
| 20:34.54 | dioedu | http://pastebin.ca/1187832 |
| 20:35.08 | Corydon76-dig | jpeeler: you already have a light colored background, correct? |
| 20:35.22 | jpeeler | well, yes, it is easier |
| 20:35.34 | jpeeler | so no more black background? |
| 20:35.47 | Corydon76-dig | Only if you set it in your terminal |
| 20:36.05 | jpeeler | but it |
| 20:36.10 | Corydon76-dig | The idea is for Asterisk to work with your terminal colors, not override them blindly |
| 20:36.14 | jpeeler | but it's always been black for me |
| 20:36.36 | Corydon76-dig | I don't understand |
| 20:36.50 | Corydon76-dig | In the past, Asterisk overrode the terminal colors |
| 20:36.57 | Corydon76-dig | It will no longer do that. |
| 20:37.35 | Qwell | so what does -W do? |
| 20:37.43 | jpeeler | i see, i kind of liked it overriding it though |
| 20:38.18 | putnopvut | Qwell: It makes the text easy to read for light background colors. |
| 20:38.32 | Corydon76-dig | Qwell: changes the terminal colors so that it's easier to read on a light-colored background |
| 20:38.49 | Corydon76-dig | similar to :set bg=dark or :set bg=light in vim |
| 20:39.03 | jpeeler | so do most of you normally use a terminal with a dark background? |
| 20:39.13 | Corydon76-dig | Yes, I generally do |
| 20:39.30 | jpeeler | is there a config option for the old behavior? |
| 20:39.40 | Corydon76-dig | No, there is not |
| 20:40.54 | Corydon76-dig | I kind of agreed with Phillip that people choose their terminal colors |
| 20:41.13 | jpeeler | this is going to sound lame, but i liked not even having to focus my eyes on the text and yet know if asterisk was running |
| 20:41.36 | jpeeler | but it's not that big of a deal |
| 20:41.36 | Corydon76-dig | Heh |
| 20:42.10 | *** join/#asterisk-dev KenLee (n=k3leland@bg-fw2out.monmouth.com) |
| 20:42.50 | KenLee | Has anyone heard anything about digium hardware becoming NEBS certified? |
| 20:44.04 | Corydon76-dig | Sir, I'm an officer of the International Organization Against Acronym Abuse (IOAAA) and I'm afraid I have to issue you a citation |
| 20:44.48 | Qwell | "NEBS is the most common set of safety, spatial and environmental design guidelines applied to telecommunications equipment in the United States. NEBS is why telephones work after an earthquake or thunderstorm! The NEBS equipment design guidelines, (requirements and objectives in Telco-speak) are described in Telcordia documents:" |
| 20:47.31 | *** join/#asterisk-dev jeffspeff2 (i=jeff@c-98-240-113-135.hsd1.ky.comcast.net) |
| 20:48.07 | KenLee | thanks qwell.. so any rumors? |
| 20:49.08 | Corydon76-dig | Try calling sales and posing the question there |
| 20:49.10 | kpfleming | i don't believe individual cards can be NEBS certified |
| 20:49.37 | *** join/#asterisk-dev Rem| (n=remi@bg-fw2out.monmouth.com) |
| 20:50.20 | Corydon76-dig | kpfleming: it's more about the installation/grounding requirements? |
| 20:50.39 | KenLee | They certainly can... and they must be before the telcos will allow them into a central office.. |
| 20:50.54 | KenLee | Anything you install in a central office must be accompanied by a list of plug-in cards |
| 20:51.23 | KenLee | neither digium or sangoma are certified |
| 20:52.22 | Corydon76-dig | KenLee: again, you'd need to talk to sales, tell them your needs and give them a quantity you would buy if Digium had that certification |
| 20:52.50 | Corydon76-dig | KenLee: it's the only way you're going to get that ball rolling |
| 20:54.57 | Corydon76-dig | Well, maybe not the only way. But it's your best bet. |
| 20:55.41 | KenLee | ha.. well the salesperson said hes heard the word passed around but no official press releases have indicated any interest |
| 20:56.18 | Corydon76-dig | which is why you need to pass him a unit quantity that you would buy if it had that certification |
| 20:57.19 | bkw_ | KenLee: the quote I just got from Sangoma was this... "the box needs NEBS compliance, not the cards" |
| 20:57.21 | Corydon76-dig | Trust me, if the number is high enough, the word will pass through the right channels, and the ball will get rolling |
| 20:58.08 | bkw_ | KenLee: call Sangoma and ask to talk to Doug Vilim at extension 114 |
| 21:00.55 | kpfleming | Corydon76-dig: installation, fire resistance, grounding, etc. |
| 21:01.00 | kpfleming | nearly all safety-related issues |
| 21:01.41 | Corydon76-dig | Right, and I believe we already have UL listing, which covers most of the issues applicable to the card |
| 21:01.44 | KenLee | haha i am already on the phone with him |
| 21:01.47 | KenLee | doug v that is |
| 21:01.57 | bkw_ | KenLee: thats funny.. I'm talking to him on IM too :P |
| 21:02.32 | kpfleming | no, UL listing is a far cry from NEBS certification |
| 21:03.14 | *** join/#asterisk-dev jeffspeff (i=jeff@c-98-240-113-135.hsd1.ky.comcast.net) |
| 21:04.10 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 21:05.33 | KenLee | To be continued... Doug V is going to pass the info on to the engineers who deal with certifications and get back to me |
| 21:05.43 | bkw_ | KenLee: good to hear |
| 21:06.44 | KenLee | Here is the list Verizon recognizes and allows to be installed in their central offices: http://www22.verizon.com/wholesale/utils/attach-redirect/?target=/wholesale/attachments/collocation/vz_nebs_products.xls |
| 21:08.22 | Corydon76-dig | Heh, they've certified Cat5 cable |
| 21:08.40 | KenLee | check out line 1950.. riser card |
| 21:08.48 | bkw_ | LOL riser card |
| 21:09.09 | Qwell | 1956.. |
| 21:09.14 | Qwell | they certified a rack. |
| 21:09.31 | Qwell | maybe I'm reading that wrong. |
| 21:09.35 | bkw_ | its verizon did you expect them to be sane? |
| 21:09.47 | seanbright | 2463 |
| 21:09.52 | Corydon76-dig | I can understand a grounded rack. I can't understand certifying a cable |
| 21:10.00 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-20-153.hsd1.sc.comcast.net) |
| 21:10.00 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 21:10.09 | kpfleming | sure.. flame-retardant jacket/insulation, stuff like that |
| 21:10.16 | Qwell | seanbright: nice. |
| 21:10.26 | seanbright | "piece of black plastic... check" |
| 21:10.37 | kpfleming | NEBS-compliant equipment must resist fire and flame |
| 21:10.42 | bkw_ | I bet you "Cardboard Box" isn't on that list |
| 21:10.44 | KenLee | The list is inconsistent because some manufacturers have listed each individual plug in card but some have listed only the name of the system |
| 21:10.48 | lmadsen | file: are you NEBS compliant?! |
| 21:10.58 | kpfleming | and when it does burn, it can't give off large amounts of noxious fumes, etc. |
| 21:11.03 | file | lmadsen: no, but I bet you are nub compliant |
| 21:11.06 | kpfleming | most cables are not made that way |
| 21:11.08 | lmadsen | true |
| 21:11.17 | Deeewayne | file gives off too much noxious fumes |
| 21:11.23 | kpfleming | ouch |
| 21:11.32 | bkw_ | Deeewayne: you were at the first cluecon? |
| 21:11.38 | bkw_ | file: I recall your luggage getting lost |
| 21:11.45 | Deeewayne | no |
| 21:11.49 | file | harsh times |
| 21:11.51 | tzafrir_laptop | kpfleming, about the dahdi init script, |
| 21:11.59 | bkw_ | file: true dat! |
| 21:12.33 | tzafrir_laptop | did you see what I posted? |
| 21:13.23 | kpfleming | where? |
| 21:13.57 | tzafrir_laptop | http://tzafrir.org.il/~tzafrir/dahdi.init |
| 21:14.32 | kpfleming | no, i did not know about that |
| 21:15.17 | tzafrir_laptop | http://tzafrir.org.il/~tzafrir/dahdi.init.diff |
| 21:15.37 | kpfleming | i really don't like that |
| 21:15.43 | tzafrir_laptop | there are two separate changes there: |
| 21:15.53 | kpfleming | the whole point of using /etc/dahdi/modules is to provide deterministic load order for the modules |
| 21:16.06 | kpfleming | that is under the control of the system admin, and not buried in some perl module |
| 21:16.25 | tzafrir_laptop | yes, but the "automatic" list is only used if the list from the modules file is empty |
| 21:16.47 | kpfleming | so who is going to know about this? why would anyone choose that method? |
| 21:17.01 | tzafrir_laptop | For a typical case of one device this works well |
| 21:17.10 | kpfleming | so does kernel hotplug loading |
| 21:17.16 | kpfleming | and it doesn't require perl or perl modules |
| 21:17.34 | tzafrir_laptop | the point is to have an empty modules file (maybe by default) |
| 21:17.41 | kpfleming | what happens if someone has an empty list but no perl? are they going to get weird error messages? what about if they have perl but haven't installed the DAHDI perl modules? |
| 21:17.46 | kpfleming | no, it's not |
| 21:17.57 | kpfleming | if that was the point, we'd eliminate the init script entirely and let the kernel autoload the moduels |
| 21:18.07 | tzafrir_laptop | well, a 2>/dev/null can fix that |
| 21:18.42 | tzafrir_laptop | Is the init script only used at startup? |
| 21:18.53 | kpfleming | when the sample modules file is not empty, i can't see very many users ever intentionally emptying it so they can use this method instead |
| 21:19.04 | kpfleming | when else would it be used? |
| 21:19.31 | tzafrir_laptop | I often find the need to "restart" . e.g. when upgrading |
| 21:19.57 | kpfleming | ok, but that still does a 'stop' then a 'start', so it's not much different from startup |
| 21:20.11 | tzafrir_laptop | Can you trigger a hotplug? |
| 21:20.21 | Corydon76-dig | If you want to do that in the Debian package, I suppose that's your prerogative (and your support problem) |
| 21:20.21 | kpfleming | and i'm sure there is a way to 'kick' udev into loading modules for all hardware that doesn't have modules already loaded |
| 21:21.31 | kpfleming | /sbin/udevadm trigger |
| 21:21.43 | tzafrir_laptop | anyway, one thing I would really like to clarify: with the current dahdi.init I can put ini /etc/dahdi/modules a line of the sort of: |
| 21:22.01 | tzafrir_laptop | <PROTECTED> |
| 21:22.10 | kpfleming | not intentionally |
| 21:22.14 | kpfleming | we already covered this, twice |
| 21:22.46 | tzafrir_laptop | yes, but it is supported by the script . And thus people will use it. |
| 21:23.05 | kpfleming | so you want to filter that stuff out? fine, make that change |
| 21:23.18 | kpfleming | when the documentation tells people not to do that, if they do it anyway, i don't really care |
| 21:23.21 | tzafrir_laptop | Now, if we leave aside the perl one-liner |
| 21:24.17 | tzafrir_laptop | the other change there is that it gets a list of modules and can do "something" if that list is empty, before attempting to load anything |
| 21:25.38 | tzafrir_laptop | also note that with the current script the failiure is in a subprocess. That sub-process cannot send out to the parent process any useful information besides its return value |
| 21:25.59 | kpfleming | i noted all of this yesterday or the day before |
| 21:26.12 | kpfleming | and right now, if there are no modules to load, we want the script to continue so it will load dahdi and dahdi_dummy |
| 21:26.51 | tzafrir_laptop | one technical problem: that delay loop |
| 21:27.05 | tzafrir_laptop | (caused by the buggy udev in RHEL4) |
| 21:27.19 | tzafrir_laptop | so dahdi has to be loaded before it :-( |
| 21:27.25 | kpfleming | before what? |
| 21:28.09 | tzafrir_laptop | while [ ! -d /dev/dahdi ] ; do |
| 21:28.30 | kpfleming | ok, so explcitly modprobe dahdi before doing anything else then |
| 21:28.33 | tzafrir_laptop | (alternatively, if it works without it on RHEL 4, even better) |
| 21:28.49 | kpfleming | and then remove the loop |
| 21:37.23 | tzafrir_laptop | ok. Updated script and diff accordingly |
| 21:37.40 | kpfleming | just commit it |
| 21:44.01 | tzafrir_laptop | Next on my list: slightly reformat UPDATES.txt for: http://tzafrir.org.il/~tzafrir/README.html#_upgrade |
| 21:45.57 | tzafrir_laptop | http://tzafrir.org.il/~tzafrir/UPGRADE.txt |
| 21:46.06 | kpfleming | why did you remove the message about no modules found in /etc/dahdi/modules? |
| 21:48.29 | *** join/#asterisk-dev IsUp (n=nocturne@88.255.77.200) |
| 21:51.12 | tzafrir_laptop | two cases: 1. someone who wants to load modules on his own, 2. dahdi_dummy |
| 21:52.07 | kpfleming | then add some way to explicitly specify 'none' as a module name so that users who accidentally remove all the modules will get a warning |
| 21:52.23 | kpfleming | if you want to load modules on your own, then you won't even install the init script |
| 21:53.06 | tzafrir_laptop | the init script runs ztcfg, fxotune, hpec utils, and such |
| 21:53.16 | tzafrir_laptop | dahdi_cfg, that is :-) |
| 21:54.31 | kpfleming | right, but all of that cannot be done if you are going to load the modules by hand at some other time |
| 21:54.45 | tzafrir_laptop | The result will be that everyone will have all the modules loaded |
| 21:54.53 | tzafrir_laptop | And this is something I'd like to avoid |
| 21:56.08 | tzafrir_laptop | well, not everone. But still most systems |
| 21:56.42 | kpfleming | this is why i advocated using hotplug loading, but everyone else shot me down because it's not deterministic |
| 21:56.54 | kpfleming | you can't have automatic loading in a user-defined order |
| 21:56.59 | kpfleming | the user has to define the order |
| 21:57.58 | kpfleming | i also suggested making the sample /etc/dahdi/modules file have all the modules commented out, so that the message about 'no configured modules' would show up and the user would know to edit the file |
| 21:58.16 | kpfleming | again, everyone (here) said no, that's too much of a behavior change and requires configuration for the modules to get loaded |
| 21:59.09 | *** join/#asterisk-dev viraptor (n=viraptor@awh178.internetdsl.tpnet.pl) |
| 22:00.10 | kpfleming | i have to go now... |
| 22:00.58 | seanbright | codefreeze-lap: i think i see where you were going with that question... i haven't found any leaks in cdr_tds, but i can run my tests again this evening to make sure. |
| 22:02.50 | *** join/#asterisk-dev jeffspeff2 (i=jeff@c-98-240-113-135.hsd1.ky.comcast.net) |
| 22:03.47 | codefreeze-lap | seanbright: no, that's not exactly where I was headed... what would it take to backport freetds to 1.4? |
| 22:04.06 | codefreeze-lap | I mean, to make 1.4 use 0.82 |
| 22:05.21 | *** join/#asterisk-dev jeffspeff2 (n=jeff@c-98-240-113-135.hsd1.ky.comcast.net) |
| 22:05.34 | seanbright | codefreeze-lap: /svn/asterisk/team/seanbright/cdr-tds-backport-ugh/ |
| 22:05.57 | seanbright | it builds and runs fine |
| 22:06.21 | seanbright | some have mentioned a lot of chatter about this on the -users list but i haven't been able to find it |
| 22:06.37 | codefreeze-lap | lol, cdr-tds-backport-ugh? |
| 22:06.51 | seanbright | yes... the 'ugh' means "i don't wanna!" |
| 22:06.52 | seanbright | heh |
| 22:07.55 | seanbright | codefreeze-lap: i'll be finishing it up tonight and testing, etc. |
| 22:07.59 | seanbright | codefreeze-lap: why do you ask? |
| 22:08.06 | seanbright | besides falves |
| 22:08.28 | codefreeze-lap | seanbright: I am quite ignorant on the issues... Why would a 1.4 based user want to use both odbc and tds? |
| 22:09.09 | codefreeze-lap | to get to mssql...? |
| 22:09.14 | lmadsen | hrmmm.... |
| 22:09.16 | seanbright | i would assume it was more of an _or_ thing and not an _and_ thing |
| 22:09.22 | lmadsen | ODBC will get you to mssql too won't it? |
| 22:09.27 | seanbright | yes indeed |
| 22:09.36 | Deeewayne | :q |
| 22:10.02 | seanbright | there is a perception that since FreeTDS is a 'native' connection that it will be faster |
| 22:10.27 | seanbright | when in reality, the difference is probably insignificant for most purposes |
| 22:10.33 | codefreeze-lap | OK, I have a user that is using odbc, I guess, then, because 1.4 doesn't work with freetds 0.82 |
| 22:10.43 | seanbright | codefreeze-lap: falves? |
| 22:10.46 | codefreeze-lap | yes |
| 22:10.50 | seanbright | yeah |
| 22:10.59 | seanbright | he is the reason i started the backport |
| 22:11.00 | lmadsen | chuckles |
| 22:11.27 | seanbright | but it will hit more and more users going forward |
| 22:11.47 | seanbright | i *want* to replace cdr_tds in 1.4 with the newer implementation, as it is functionally identical |
| 22:12.12 | seanbright | but russellb has suggested adding a new module (which i have tentatively called cdr_tds_dblib) |
| 22:12.50 | viraptor | is there any benefit in setting audiobuffers > 2 for meetme when I already pass all the calls through Local channel with dejittering (I believe I won't get any answer for that on #ast... :/ ) |
| 22:14.01 | seanbright | codefreeze-lap: but as it stands, you could grab cdr_tds_dblib.c from my branch, drop it in a 1.4 src directory, configure, make menuselect, make, make install and you're off to the races |
| 22:14.12 | seanbright | codefreeze-lap: it's a drop-in replacement (same configuration, etc) |
| 22:14.50 | seanbright | but the reason falves wants to use cdr_tds instead of odbc is because of the memory leak that he may or may not be experiencing |
| 22:17.08 | seanbright | but if history is any indication, his memory leak is probably due to some third-party out-of-tree module he is running or some changes he made himself |
| 22:17.13 | seanbright | not to be negative :) |
| 22:17.22 | lmadsen | :) |
| 22:17.24 | lmadsen | obviously |
| 22:17.43 | codefreeze-lap | seanbright: oh, he's got one heckuva leak alright. And I'm in the middle of trying to replicate the situation and find the leaker... |
| 22:17.58 | seanbright | codefreeze-lap: you've confirmed it? |
| 22:18.06 | seanbright | codefreeze-lap: by logging in, etc? |
| 22:18.17 | codefreeze-lap | Well, finding out where it's leaking is the challenge. |
| 22:18.38 | seanbright | codefreeze-lap: have you seen his setup/examined what codebase he is using? |
| 22:18.48 | codefreeze-lap | His 64-bit machines make valgrind crash. |
| 22:18.55 | seanbright | or is this his ABE install you are working with?/ |
| 22:18.58 | codefreeze-lap | yeah, he's using BE C |
| 22:19.03 | [xpl] | hi people |
| 22:19.03 | [xpl] | who can i see if the license of the g729 codec is valid and works ? |
| 22:19.12 | seanbright | digium.com |
| 22:19.50 | seanbright | codefreeze-lap: keep in mind that unixODBC uses FreeTDS for mssql |
| 22:19.58 | codefreeze-lap | and I'm trying to build an asterisk with odbc and freetds on a 32-bit machine |
| 22:20.10 | codefreeze-lap | on RHEL 5 |
| 22:20.13 | seanbright | codefreeze-lap: freetds 0.64 is the best you can do |
| 22:20.22 | *** join/#asterisk-dev Schmooze (n=Schmooze@rrcs-67-53-189-178.west.biz.rr.com) |
| 22:20.36 | seanbright | codefreeze-lap: that was the last version to install libtds.so |
| 22:20.50 | codefreeze-lap | Yeah, i"ve been looking thru the rpm areas |
| 22:20.56 | [xpl] | Presario*CLI> show g729 |
| 22:20.57 | [xpl] | No such command 'show g729' (type 'help' for help) |
| 22:21.05 | seanbright | [xpl]: try #asterisk |
| 22:21.14 | [xpl] | yes but nobody want to help me |
| 22:21.15 | [xpl] | :( |
| 22:21.20 | seanbright | [xpl]: i can't imagine why... |
| 22:21.34 | seanbright | [xpl]: did you buy the codec from digium? |
| 22:21.41 | [xpl] | yes |
| 22:21.45 | seanbright | [xpl]: call digium |
| 22:21.50 | [xpl] | yes yes |
| 22:21.59 | [xpl] | i have the licence |
| 22:22.05 | seanbright | no no |
| 22:22.06 | seanbright | call digium |
| 22:22.09 | codefreeze-lap | [xpl]: yes, they should be able to help you install and check it |
| 22:22.27 | seanbright | [xpl]: digium *support* |
| 22:22.32 | [xpl] | my english its a litte bad |
| 22:22.32 | [xpl] | :( |
| 22:22.40 | seanbright | [xpl]: that's ok |
| 22:22.45 | seanbright | but we can't help you here |
| 22:22.54 | [xpl] | oK |
| 22:23.10 | codefreeze-lap | [xpl]: they might have a speaker around in your language, too, you never know |
| 22:23.19 | [xpl] | yep.. |
| 22:23.21 | [xpl] | thanks |
| 22:23.22 | seanbright | codefreeze-lap: i'll be back later on if you would like another pair of eyes |
| 22:23.39 | seanbright | but for now... |
| 22:23.40 | seanbright | goes |
| 22:24.02 | codefreeze-lap | gooooooooooooooooodbyeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee, seanbright... I'll look for ya later |
| 22:30.36 | lmadsen | bye :) |
| 22:31.48 | *** join/#asterisk-dev mog (n=mogorman@c-68-62-219-86.hsd1.al.comcast.net) |
| 22:31.48 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 22:42.34 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 23:08.11 | *** join/#asterisk-dev russellb (n=russellb@asterisk/developer-and-stable-maintainer/drumkilla) |
| 23:08.11 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 23:12.05 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-20-153.hsd1.sc.comcast.net) |
| 23:12.05 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 23:24.13 | *** join/#asterisk-dev juniowww (n=juniowww@201.86.13.74.adsl.gvt.net.br) |
| 23:42.43 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |