| 00:03.05 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.pa.comcast.net) |
| 00:32.56 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 00:32.56 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 00:58.33 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 00:58.33 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 01:10.38 | *** join/#asterisk-dev obnauticus (n=obnautic@c-67-160-183-109.hsd1.wa.comcast.net) |
| 01:19.06 | *** join/#asterisk-dev JerJer[mobile] (n=jj@45.210.254.244) |
| 01:25.15 | *** join/#asterisk-dev ectospasm (n=ectospas@c-71-207-229-248.hsd1.al.comcast.net) |
| 01:37.23 | *** join/#asterisk-dev elguero (n=elguero@ns1.nashuacs.com) |
| 01:41.58 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23) |
| 01:46.30 | *** join/#asterisk-dev JerJer[mobile] (n=jj@45.210.254.244) |
| 01:51.57 | *** join/#asterisk-dev philipp64 (n=chatzill@nat/microsoft/x-84bb84d47a399fe7) |
| 01:52.09 | philipp64 | howdy. |
| 01:52.46 | philipp64 | was wondering when CALLERID(num) isn't the same as CALLERID(ani)... |
| 01:54.00 | philipp64 | doc/channelvariables.txt doesn't make it very clear. |
| 01:54.28 | Juggie | it would be different when the telco makes it different |
| 01:55.31 | philipp64 | so... which can I count on being useful/accurate? |
| 01:56.00 | Juggie | ani in theory should be more correct. |
| 01:56.01 | philipp64 | and is the ANI only set on PRI trunks (i.e. when doing Q.931 signalling?) |
| 01:56.12 | Juggie | ani will not be set on analog trunks i do not believe. |
| 01:56.30 | Juggie | if it is set its just a copy of the cid |
| 01:57.03 | Juggie | ani is like a unblockable callerid. |
| 01:57.48 | Juggie | so if a caller has their line flagged as private with the telco you should not have any callerid |
| 01:57.51 | Juggie | but you should get ani |
| 01:57.57 | Juggie | so long as your pri provider provides it. |
| 02:01.11 | *** join/#asterisk-dev tuxd00d (n=tuxd00d@128.187.132.25) |
| 02:01.46 | philipp64 | ok. I keep getting calls where CALLERID(num) is "MissingCpn" |
| 02:02.16 | philipp64 | I'm thinking it's some idiot using FG-A or FG-C T1's so he can hide his identity. |
| 02:02.28 | philipp64 | I'd like to busyout all such calls. |
| 02:03.06 | philipp64 | (the switch I'm peering with is a Coppercom... don't know if other switches also generate that value or not.) |
| 02:03.51 | Juggie | CPN = Calling Party Number |
| 02:05.05 | philipp64 | right. that's what gets populated into the CID, right? |
| 02:05.29 | Juggie | try adding a Noop(CALLERPRES()) |
| 02:05.34 | Juggie | to see what the presentation flag is |
| 02:05.39 | Juggie | if you see the call on the cli |
| 02:06.18 | philipp64 | I'm peering SIP to a Coppercom, which trunks SS7 to the PSTN. |
| 02:06.34 | Juggie | ah, well i dunno no expirence with coppercom |
| 02:06.40 | Juggie | but SS7 should give you everything |
| 02:06.43 | Juggie | even blocked CID. |
| 02:06.52 | philipp64 | would that be conveyed via SIP, or only locally significant on the SS7 gateway? |
| 02:07.03 | Juggie | hmmm ani via sip |
| 02:07.04 | Juggie | i am not sure |
| 02:07.10 | Juggie | that is something you would probally have to configure |
| 02:07.12 | philipp64 | does the SS7 => SIP conversion carry it over? |
| 02:07.28 | Juggie | no idea. |
| 02:07.32 | Juggie | depends on implementation. |
| 02:07.36 | Juggie | no expirence in that area. |
| 02:08.15 | Qwell | philipp64: Microsoft uses Asterisk? :) |
| 02:08.20 | JerJer[mobile] | <PROTECTED> |
| 02:08.34 | JerJer[mobile] | and asterisk doesn't support SIP-T |
| 02:08.51 | philipp64 | no fair peeking behind the curtain. |
| 02:09.02 | philipp64 | No, I run it at home. |
| 02:09.02 | Juggie | we accept patches though :) |
| 02:09.05 | Qwell | ahh, cool |
| 02:09.19 | philipp64 | It's a carry over from previous lives. |
| 02:09.23 | Juggie | you should sip debug the communication between your coppercom & asterisk |
| 02:09.34 | Juggie | and see if there is any ani information in it. |
| 02:09.46 | Juggie | during call setup i mean when the call is incomming. |
| 02:09.52 | JerJer[mobile] | Qwell: any idea what chan_skinny would do if a a real CM tried to trunk with it? |
| 02:10.04 | Qwell | JerJer[mobile]: nothing, because CM can't act as a phone |
| 02:10.13 | Qwell | (and neither can chan_skinny) |
| 02:10.16 | JerJer[mobile] | i think it would barf at the CM |
| 02:10.28 | JerJer[mobile] | but the CM can have a trunk that is SCCP |
| 02:10.34 | Qwell | oh can it? |
| 02:10.36 | philipp64 | what field would it be in? |
| 02:10.54 | Qwell | yeah, it would probably do "Bad Things" |
| 02:10.56 | JerJer[mobile] | its not really a phone - i think its actually a trunk extension to SCCP |
| 02:11.01 | JerJer[mobile] | me too |
| 02:11.25 | Qwell | it could work though, in theory |
| 02:11.55 | philipp64 | speaking of previous lives... |
| 02:12.02 | Qwell | already linkedin |
| 02:12.03 | Qwell | :P |
| 02:12.26 | philipp64 | I still have nightmares about maintaining SCCP and MGCP at Cisco. |
| 02:12.32 | Qwell | you maintained sccp? |
| 02:12.42 | philipp64 | long time ago. |
| 02:12.47 | Qwell | why have I never talked to you? |
| 02:13.02 | Qwell | I'm maintaining the chan_skinny driver in Asterisk, heh |
| 02:13.15 | philipp64 | long story. the short version is that I worked in the platform group, not the protocol group that owned it. |
| 02:13.20 | Qwell | eww |
| 02:13.42 | Qwell | I talked to one guy a long time ago, but he was "no longer in that dept", and couldn't help me with protocol stuff. |
| 02:13.53 | philipp64 | we just used to get bugs mis-dispatched to us. "we hit the bug on a as5400, so it must be a 5400 bug!" (duh...) |
| 02:13.59 | philipp64 | I'd fix whatever I could. |
| 02:14.30 | philipp64 | the code was pretty horrendous. |
| 02:14.37 | Qwell | I don't doubt that |
| 02:15.12 | philipp64 | buffer overflows, people having absolutely no idea of the cost of a strlen() (and using them abusively...) |
| 02:15.28 | philipp64 | sprintf()'s everywhere... |
| 02:15.30 | philipp64 | gah. |
| 02:15.47 | philipp64 | sprintf()'s used instead of strncpy()'s. |
| 02:16.01 | Qwell | sprintf(buf, "%s", buf2); |
| 02:16.12 | Qwell | hooray for terrible coding |
| 02:16.18 | philipp64 | if only they were smart enough to use "%s". |
| 02:16.24 | Qwell | eww |
| 02:16.36 | Qwell | just straight sprintf(buf, buf2); ? |
| 02:16.49 | philipp64 | no, sometimes you could crash a box by putting "%s" in just the right place, and causing it to dereference random memory. |
| 02:16.55 | Qwell | no comment |
| 02:16.58 | philipp64 | (yeah, just like that...) |
| 02:17.11 | Qwell | (we recently had a similar vuln...*cough*) |
| 02:17.31 | philipp64 | well, sprintf() is bad enough. |
| 02:17.32 | Qwell | we use format checking stuff in gcc now.. |
| 02:17.54 | philipp64 | I'm old enough to remember Robert Morris's worm shutting down the internet in '89. |
| 02:18.46 | philipp64 | yeah, gcc could try a little harder. I filed a bunch of bugs about format checking... but management was cheap about getting the redhat contractors to fix them and feed them upstream (or just fix them and not upstream them). |
| 02:19.22 | philipp64 | Juggie: I'm getting 0 for the presentation, and I can't tell where in the SIP message it would be encoded. |
| 02:19.37 | philipp64 | (Cisco wasn't hot on SIP when I was there...) |
| 02:19.49 | Qwell | I noticed they finally made a SIP-only IP phone. |
| 02:20.10 | Qwell | outsourced no doubt, but still...good direction |
| 02:20.40 | Qwell | they need to send me a bunch of free stuff so I can make chan_skinny better, and let them sell more phones. |
| 02:20.50 | philipp64 | which? the SPA-94x's? Or the 7960's with the "special" SIP-only images? |
| 02:21.02 | Qwell | I once had somebody high up tell me that "less than 1/100 of 1%" of phones sold are used with asterisk |
| 02:21.07 | JerJer[mobile] | i just rapped with the Cisco guy here and we are gonna point a real CM at chan_skinny to see what kind of mess we can make :) |
| 02:21.08 | philipp64 | folks weren't happy about releasing SIP-only CM or SIP-only 3750's... |
| 02:21.18 | Qwell | 5xxx model I think |
| 02:21.24 | Juggie | philipp64, i'm not sure what that references to as far as presentation goes |
| 02:22.23 | philipp64 | ok... remind me what the calling presentation was interesting (at least in theory)? |
| 02:22.33 | philipp64 | I haven't stared at Q.931 in 15 years. |
| 02:22.50 | Juggie | if the number is blocked, etc. |
| 02:22.58 | philipp64 | (well, okay... less than that... but it was being used for data calls only...) |
| 02:25.02 | Juggie | qwell would be fun if you were here |
| 02:25.14 | Qwell | where's here? |
| 02:25.37 | Juggie | it360 |
| 02:25.52 | Juggie | jared, mark, and kevin are here somewhere. |
| 02:25.52 | Qwell | ahh |
| 02:26.37 | Qwell | that's in TO? |
| 02:26.43 | Juggie | yep |
| 02:26.49 | Qwell | no passport |
| 02:26.57 | Qwell | (that's the least of the reasons though) |
| 02:27.12 | philipp64 | Qwell: where are you? |
| 02:27.12 | Juggie | get a passport! :) |
| 02:27.23 | Qwell | AL |
| 02:27.30 | philipp64 | ah. of course. |
| 02:27.57 | philipp64 | here in WA, we have these new biometric "enhanced driver's licenses". they're a pilot program. |
| 02:28.09 | Qwell | ugh.. |
| 02:28.21 | philipp64 | canada accepts them instead of passports, because they're hard to forge and contain your nationality/resident status. |
| 02:28.28 | Qwell | speaking of driver's licenses...maybe I should get mine now |
| 02:28.37 | Juggie | hhaha |
| 02:28.39 | Qwell | been here 18 months, and still have my CA license... |
| 02:28.39 | Juggie | would be nice |
| 02:28.47 | Juggie | thats illegal |
| 02:28.49 | philipp64 | well, it's handy. I can drive up from Seattle without having to run home and get my passport. |
| 02:28.53 | Qwell | Juggie: yeah... |
| 02:28.55 | Juggie | at least it is in ontario |
| 02:29.15 | philipp64 | most places. 30-90 days max. |
| 02:29.30 | Qwell | I only started driving here recently, so never needed it |
| 02:29.47 | philipp64 | cops like to know where to go looking for you if your car flees the scene of a hit-and-run. |
| 02:30.25 | philipp64 | other states might start picking them up... look for VT next. |
| 02:30.27 | philipp64 | and MI. |
| 02:30.38 | philipp64 | places with a lot of cross-border traffic. |
| 02:30.38 | Qwell | philipp64: so, got any contacts at Cisco that can get me a bunch of phones for testing? :D |
| 02:30.57 | philipp64 | I doubt it. I sort of burned that bridge when I left. |
| 02:31.05 | Qwell | excellent |
| 02:31.15 | philipp64 | but I'll ask. maybe tempers have calmed. |
| 02:31.35 | Qwell | nah, don't - they probably hate us too |
| 02:32.09 | Corydon76-dig | Well, of course. We're making their phones into a commodity |
| 02:32.23 | Qwell | they always were - they just never realized it |
| 02:32.26 | Qwell | and they still don't |
| 02:32.27 | Corydon76-dig | And commodity goods don't fetch a premium price |
| 02:32.34 | philipp64 | (maybe the mistake of telling a director of IT that in a "company full of software engineers", she can't afford to not have open door design meetings for the future of Cisco's IT. unless she wanted to make a lot of mistakes that anyone could have easily pointed out to her before the fact, of course.) |
| 02:33.12 | philipp64 | went over like a turd in the punch bowl. because she had, of course, had a disastrous email server rollout (Exchange based). |
| 02:34.05 | Corydon76-dig | I'm frankly surprised that Cisco doesn't have its own unified messaging solution |
| 02:34.06 | philipp64 | making a commodity drives the price down. and Cisco only likes to manufacture gear that has 70% or better margins. |
| 02:34.33 | philipp64 | yeah... they were working on that when I got there in 2000... and they were working on that when I left in 2005... |
| 02:34.43 | Corydon76-dig | or if they do, that they don't eat their own dog food |
| 02:35.00 | Juggie | i need a mitel contact in engineering who isnt a dumbass |
| 02:35.09 | philipp64 | :-) |
| 02:35.19 | Corydon76-dig | s/in engineering// |
| 02:35.25 | Juggie | i need to know how to jtag their phones |
| 02:35.37 | Juggie | i have 10 that commited suicide, but the only problem is bad firmware |
| 02:36.25 | Juggie | the phones needed to upgrade to v5 of the firmware to update the bootloader to version2 before upgrading to version6 but when i powered on the phones they went to mitels http server and found the latest version (version 6) and upgraded right to 6 |
| 02:36.30 | Juggie | and killed themselves :( |
| 02:36.33 | Juggie | a whole lab full |
| 02:37.12 | Juggie | the firmware was set to auto update by default. |
| 02:38.37 | philipp64 | that's one way to sell more phones. :-) |
| 02:38.40 | philipp64 | or less. |
| 02:43.41 | philipp64 | hmmm.... I need a good recorded message saying, "stop trying to hide your callerid, dumbass..." |
| 02:44.12 | philipp64 | said in that friendly, female, connecticut-accented voice, of course. |
| 02:44.33 | philipp64 | ok. time for food. |
| 02:51.18 | philipp64 | Juggie: ok, just one last thought before I leave... |
| 02:52.06 | philipp64 | if someone was calling from an Internet phone (skype or whatever) and didn't have a phone number and it got gatewayed.... or else if they were calling from outside of the US and Canada... what would their CPN/ANI look like? |
| 02:53.21 | philipp64 | I'm wondering if gatewaying international calls and calls without originating phone numbers is the real cause... and not FG-A/FG-B trunks... |
| 02:53.52 | philipp64 | (of course, such calls are a bitch to trace back to their point-of-origin... even when you do have a warrant...) |
| 02:54.37 | philipp64 | Qwell: which model did you want, anyway? |
| 02:54.49 | Qwell | of what? |
| 02:54.53 | philipp64 | phone. |
| 02:54.58 | Qwell | I don't :) |
| 02:54.59 | philipp64 | 7960's? |
| 02:55.22 | philipp64 | I thought you wanted Cisco phones for testing... |
| 02:55.25 | Qwell | I actually have quite a few different ones |
| 02:55.34 | Qwell | I meant like as they come out, heh |
| 02:55.40 | philipp64 | ah. |
| 02:55.41 | Qwell | was being a bit facetious |
| 02:55.49 | philipp64 | sorry. the best I could do would be refurbs. |
| 02:56.19 | philipp64 | but knowing what I do about the release process.... the SCCP protocol engine isn't likely to change much between product cycles. |
| 02:56.33 | philipp64 | it's the same codebase across all platforms. |
| 02:56.40 | Qwell | the protocol doesn't... |
| 02:56.46 | Qwell | but boy are some phones picky |
| 02:57.18 | philipp64 | if you have a working implementation with one phone, there's a high probability it will work with others too. |
| 02:57.30 | Qwell | sadly, that isn't often the case |
| 02:57.40 | philipp64 | MWI? intercom? |
| 02:57.46 | Qwell | 7921/7936 are a good example |
| 02:57.56 | philipp64 | how do they differ? |
| 02:58.14 | Qwell | they're more picky. the code we had didn't work. however, when we changed it to work with it, it did work with the old stuff |
| 02:58.33 | Qwell | things like the order of the messages mattering more |
| 03:04.09 | philipp64 | hmm. well, I'll ask around about who maintains that stuff. |
| 03:04.25 | philipp64 | did you try "cs-sccp"? |
| 03:04.30 | Qwell | what's that? |
| 03:04.30 | Corydon76-dig | Okay, I have a gcc question... http://pastebin.ca/977846 |
| 03:05.09 | Corydon76-dig | Why does this code generate a warning that "value computed is not used" |
| 03:05.13 | philipp64 | it's the customer-support alias for cs-sccp stuff. at least it should be. there's a cs-* alias for just about everything. |
| 03:05.23 | Qwell | hmm |
| 03:06.25 | philipp64 | wouldn't _in.codec = in be safer/more portable? |
| 03:06.43 | philipp64 | what line is the warning on, anyway? |
| 03:06.51 | Corydon76-dig | philipp64: it's new code |
| 03:07.24 | Corydon76-dig | philipp64: no, it does the same |
| 03:07.33 | philipp64 | huh. |
| 03:07.33 | Corydon76-dig | philipp64: it's warning specifically on the two for lines |
| 03:08.00 | Corydon76-dig | which is insane, because they ARE used. They're my results. |
| 03:09.43 | philipp64 | and if you used two temp variables, and copied them into *page and *bits on the "return 0"? |
| 03:09.56 | Corydon76-dig | Just tried it, and that suppressed the warning |
| 03:10.04 | Corydon76-dig | That's just annoying |
| 03:10.20 | Corydon76-dig | Hand optimize code and the compiler bitches at you |
| 03:11.36 | philipp64 | can you live with the workaround? |
| 03:12.53 | philipp64 | ok. food for real this time. |
| 03:15.35 | Corydon76-dig | No, I'm going to bitch about it. |
| 03:21.21 | Corydon76-dig | Qwell: ping |
| 03:21.26 | Qwell | pong |
| 03:21.35 | Corydon76-dig | Take a look at something... |
| 03:21.44 | Corydon76-dig | Do a 'core show translation' |
| 03:21.57 | Qwell | the odd "round" numbers? |
| 03:22.07 | Corydon76-dig | then a 'core show translation recalc 1000' and tell me that the new numbers don't look weird to you |
| 03:22.11 | Qwell | that's normal |
| 03:22.19 | Qwell | I can explain it tomorrow if you'd like |
| 03:22.35 | Corydon76-dig | I mean that some numbers go up and some numbers go down |
| 03:22.41 | Qwell | oh |
| 03:22.47 | Qwell | yeah, that's to be expected |
| 03:22.55 | Qwell | it's got a 4ms resolution |
| 03:23.09 | Corydon76-dig | No, it's worse than that |
| 03:23.11 | Qwell | (in most cases) |
| 03:23.18 | Qwell | those are usec |
| 03:23.33 | Qwell | so you'll see weird things like 4002, 8001, 12003 |
| 03:23.52 | Corydon76-dig | gsm->ulaw went from 4001 to 444, alaw->ulaw went from 1 to 20 |
| 03:24.02 | Qwell | 444? |
| 03:24.07 | Corydon76-dig | Yep |
| 03:24.13 | Qwell | that one is odd |
| 03:24.16 | Corydon76-dig | We're talking massive difference |
| 03:24.31 | Qwell | trunk? |
| 03:24.35 | Corydon76-dig | Right |
| 03:24.40 | Qwell | what's your kernel hz? |
| 03:24.45 | Qwell | 250 probably? |
| 03:24.52 | Corydon76-dig | It's like the default calculations aren't even getting done at boot |
| 03:25.18 | Corydon76-dig | No idea |
| 03:25.46 | Corydon76-dig | So when you boot up Asterisk, you get bogus numbers... |
| 03:26.07 | Corydon76-dig | and considering the translation matrix took 20 seconds to build, I'm not that surprised |
| 03:27.13 | Qwell | by default it does 20ms of audio, I believe |
| 03:28.31 | Corydon76-dig | Okay, at 20ms, alaw->ulaw is back to 1, but gsm->ulaw is 401 |
| 03:28.31 | Corydon76-dig | So still not close to the original 4001 |
| 03:57.52 | *** join/#asterisk-dev CunningPike (n=arodgers@S010600095b33697f.vc.shawcable.net) |
| 04:02.45 | *** join/#asterisk-dev jameswf-home (n=james@ip72-204-221-181.ph.ph.cox.net) |
| 04:03.32 | *** join/#asterisk-dev outtolunc (n=me@c-67-174-216-60.hsd1.ca.comcast.net) |
| 04:08.28 | *** join/#asterisk-dev fakhir_ (n=fakhir@unaffiliated/fakhir) |
| 04:31.00 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177582637.dsl.bell.ca) |
| 04:48.10 | *** join/#asterisk-dev davevg-btwtech (n=davevg-b@nj-67-76-177-147.sta.embarqhsd.net) |
| 04:55.50 | *** join/#asterisk-dev davevg-btwtech (n=davevg-b@nj-67-76-177-147.sta.embarqhsd.net) |
| 05:38.08 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 05:38.08 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 05:51.34 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 05:51.34 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 06:06.37 | *** join/#asterisk-dev Sir0x (n=cmayer@p5B084951.dip.t-dialin.net) |
| 06:07.29 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23) |
| 06:24.26 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.138) |
| 06:28.55 | *** join/#asterisk-dev janinge (i=j@ninge.net) |
| 06:35.20 | *** join/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 06:42.21 | *** join/#asterisk-dev moy (n=moyhu@189.169.207.127) |
| 07:40.44 | *** join/#asterisk-dev jsmith-teaching (n=jsmith@208.113.13.58) |
| 07:40.44 | *** mode/#asterisk-dev [+o jsmith-teaching] by ChanServ |
| 08:25.31 | festr_ | asterisk 1.4 Revision: 105676 (In addition to setting the marker bit let's change our ssrc so they know for sure it is a different source.) |
| 08:25.58 | festr_ | this is causing 10 seconds of silence on Siemens C450 voip phone until RTCP comes from asterisk to this phone |
| 08:26.45 | festr_ | is this change acceptable by RFC? |
| 08:31.45 | *** join/#asterisk-dev qdk_ (n=qdk@85.235.253.139) |
| 08:36.36 | Sir0x | Why the cid struct is overwritten in app_dial.c line 1232 in the asterisk-source? |
| 08:37.13 | Sir0x | i thought the cid_num and cid_name of the channel is always the same!? |
| 08:39.08 | Sir0x | isn' it? |
| 08:39.16 | Sir0x | isn't it? |
| 09:10.13 | *** join/#asterisk-dev CrashHD (n=CrashHD@76-14-102-131.rk.wavecable.com) |
| 09:43.40 | *** join/#asterisk-dev RoyK (n=roy@fw.fortel.no) |
| 09:48.13 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.131) |
| 10:19.39 | *** join/#asterisk-dev panerai_go (n=neo@88-149-176-89.static.ngi.it) |
| 10:19.44 | panerai_go | Hi, I need to play the queue member id when the call is connected, like "you're now talking with operator number 1234". Has anyone had experience on this ? |
| 10:26.47 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23) |
| 10:43.35 | *** join/#asterisk-dev RoyK (n=roy@ti200720a080-0467.bb.online.no) |
| 10:55.07 | snuff-home | anyone about.. question bout ao2 stuff |
| 11:01.00 | *** join/#asterisk-dev _ys (i=yuri@91.151.196.254) |
| 11:22.08 | *** join/#asterisk-dev _foxfire_ (n=_foxfire@cica-adm.fe.up.pt) |
| 11:23.00 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 11:23.00 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 11:34.30 | *** join/#asterisk-dev matozzao (n=matozzao@201.76.228.176) |
| 11:34.58 | *** part/#asterisk-dev matozzao (n=matozzao@201.76.228.176) |
| 12:05.28 | *** join/#asterisk-dev shido6 (n=shido6@204.126.120.132) |
| 12:07.13 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:12.03 | *** join/#asterisk-dev RoyK (n=roy@fw.fortel.no) |
| 12:45.27 | *** join/#asterisk-dev ctooley_ (n=ctooley@209.33.106.198) |
| 13:28.43 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 13:28.43 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:57.22 | *** join/#asterisk-dev codefreeze (n=steve_mu@216.166.159.235) |
| 13:57.22 | *** mode/#asterisk-dev [+o codefreeze] by ChanServ |
| 14:04.51 | putnopvut | Corydon76-dig: I haven't looked a lot at your codec_bits branch, but is the idea just to provide sufficient space to support more codecs in the future, or is it also addressing codec negotiation algorithms? |
| 14:11.30 | *** join/#asterisk-dev jorgeraidel2000 (n=jorgerai@c-66-176-203-45.hsd1.fl.comcast.net) |
| 14:11.35 | jorgeraidel2000 | hola |
| 14:11.50 | jorgeraidel2000 | necesito los servicios de alguien con esperiencia sobre asterisk? |
| 14:11.51 | jorgeraidel2000 | :(' |
| 14:15.02 | jeffg | jorgeraidel2000, con cual? (no se habla espa?ol alli por verdad... se puede escribir en ingles?) |
| 14:16.03 | jeffg | jorgeraidel2000, http://www.digium.com/en/services/ |
| 14:18.28 | tzafrir | Shouldn't 1.6.0 be in a feature freeze? |
| 14:19.08 | putnopvut | tzafrir: yes, was this violated? |
| 14:19.31 | tzafrir | Jst watching the svn commit log |
| 14:20.32 | tzafrir | I hardly recall anything that got into trunk but not into 1.6.0 |
| 14:21.12 | putnopvut | tzafrir: as I understand it, if you're fixing a bug that was in trunk, then then it should be merged into 1.6, but if you're adding a new feature to trunk, then block it in 1.6. |
| 14:21.32 | tzafrir | well, look at the commit log yourself... |
| 14:22.21 | file | assumes you are talking about the script |
| 14:22.45 | snuff-home | wonders off to get some zzz's |
| 14:22.45 | file | (astcli) |
| 14:22.52 | caio1982 | the new dial flag i suppose |
| 14:23.05 | putnopvut | caio1982: that was blocked in 1.6.0 |
| 14:23.06 | file | caio1982: that was blocked from 1.6.0 |
| 14:23.16 | putnopvut | ...scary... |
| 14:23.33 | caio1982 | haha |
| 14:23.45 | caio1982 | right :) |
| 14:24.27 | caio1982 | may i ask what's the difference between 'in' and 'from' in this case? just a non-native curiosity |
| 14:24.46 | putnopvut | "from" is probably more correct. |
| 14:25.55 | putnopvut | My sentence would probably have been better as "that was blocked from being in 1.6.0" |
| 14:26.18 | putnopvut | I just left off "from being" |
| 14:26.52 | caio1982 | :) |
| 14:40.17 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 14:40.17 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 14:44.33 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177584618.dsl.bell.ca) |
| 14:51.18 | tzafrir | file, hmm... it seems I managed to miss the "Blocked" there, indeed |
| 14:53.06 | *** join/#asterisk-dev joetester2 (n=joeteste@216.191.34.13) |
| 14:58.17 | *** join/#asterisk-dev sruffell (n=sruffell@216.207.245.1) |
| 14:58.17 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:06.06 | Qwell | tzafrir: ha, you rock |
| 15:06.21 | Qwell | tzafrir: that loop was a change I wanted to make, but I'm pretty terrible with perl |
| 15:06.48 | Qwell | (for astcli) |
| 15:07.36 | tzafrir | Qwell, one thing that may help there is a "flood mode" - just continue to throw commands, and don't wait for the output |
| 15:08.05 | tzafrir | I also have no idea about error handling (needed? how?) |
| 15:08.12 | Qwell | like `echo -e "core show channels\nsip show channels" | astcli -` ? |
| 15:08.55 | Corydon76-dig | putnopvut: sorry, didn't see your message earlier. codec_bits is to provide more bits |
| 15:09.27 | *** join/#asterisk-dev IgorG (n=IgorG@host-90-188-188-119.pppoe.omsknet.ru) |
| 15:09.33 | putnopvut | Corydon76-dig: okay, just thought I'd ask. |
| 15:09.55 | tzafrir | hmm... someone just posted a bug to Debian that the default dialplan does not provide 911 |
| 15:10.17 | Qwell | Debian only works in the US now? |
| 15:10.26 | Juggie | heh |
| 15:10.30 | tzafrir | and suggested an "[emergency]' context. |
| 15:10.39 | Juggie | hah |
| 15:10.40 | Qwell | err, is 911 part of NANP requirements? |
| 15:10.48 | tzafrir | well, that was a bug reported. I wonder if it has any merits |
| 15:10.50 | Qwell | ie; does Canada use it? |
| 15:10.56 | Qwell | tzafrir: imo no.. |
| 15:10.59 | file | we use 911. |
| 15:11.01 | Juggie | canada uses 911 of course :) |
| 15:11.10 | Qwell | how are you going to dial out? SIP? Analog? |
| 15:11.33 | Qwell | if you provide a default, there may be some liability that goes with it |
| 15:11.46 | tzafrir | Using the ${TRUNK} variable. and, well, assume that it is valid... |
| 15:11.54 | Qwell | best to stay far away :) |
| 15:31.58 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.12.183) |
| 15:52.41 | *** join/#asterisk-dev jcollie (n=jcollie@fedora/jcollie) |
| 15:52.44 | *** join/#asterisk-dev flujan (n=flujan@internet.nube.com.br) |
| 15:53.04 | flujan | hello all |
| 15:53.49 | flujan | guys, did the zaptel developers use this channel or there is a specific channel for zaptel discussion? |
| 15:54.07 | Qwell | flujan: they're usually around |
| 15:55.17 | flujan | ok Qwell, which is the nick of some of them ? I am having problems with a transcoder digium card, asked help in support... But I want some tools to debug it... |
| 15:55.41 | Qwell | flujan: support would have everything they need to help debug |
| 15:56.02 | flujan | Qwell: ok... will try the svn zaptel first... :D |
| 15:56.11 | flujan | thanks for the help. :D |
| 15:59.57 | tzafrir | flujan, zaptel 1.4.10 is practicalyl the same as svn |
| 16:00.45 | tzafrir | (at this specific point) |
| 16:00.56 | flujan | tzafrir: yeap I diff it agains 1.4.9.2 and no much changes... I dunnot that there is a 1.4.10 out there... |
| 16:01.26 | *** join/#asterisk-dev DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 16:03.00 | *** join/#asterisk-dev qdk_ (n=qdk@0x573fe57e.bynqu2.broadband.tele.dk) |
| 16:03.18 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 16:12.02 | *** join/#asterisk-dev jameswf-home (n=james@dsl093-157-131.phx1.dsl.speakeasy.net) |
| 16:22.55 | *** join/#asterisk-dev jmesquita (n=jmesquit@201.7.117.114) |
| 16:23.18 | *** join/#asterisk-dev JerJer[mobile] (n=jj@45.210.254.244) |
| 16:44.18 | *** part/#asterisk-dev jmls_work (n=jmls_wor@mail.tessera.co.uk) |
| 16:49.03 | *** join/#asterisk-dev jayrod422 (n=jayrod42@node2.164.136.64.1dial.com) |
| 16:51.55 | *** join/#asterisk-dev jmls_work (n=jmls_wor@mail.tessera.co.uk) |
| 17:18.50 | *** part/#asterisk-dev jmls_work (n=jmls_wor@mail.tessera.co.uk) |
| 17:23.08 | tzafrir | vi fans, this one is for you: http://wordwarvi.sourceforge.net/ |
| 17:25.41 | caio1982 | 80's graphics style, neat |
| 17:25.54 | Qwell | to go along with an 80's style editor |
| 17:25.55 | Qwell | hides |
| 17:26.27 | caio1982 | haha |
| 17:28.43 | Corydon76-dig | I admit, it's not an editor for Alzheimer's patients |
| 17:29.04 | Corydon76-dig | Vi doesn't remind you of its command set on the lower lines. :-P |
| 17:34.06 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.138) |
| 17:41.34 | ctooley_ | Corydon76-dig, nor does it require extra fingers to execute them. |
| 17:46.58 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 17:49.34 | JerJer[mobile] | is cdr.conf required for cdr_csv to operate now ? |
| 17:50.01 | JerJer[mobile] | i upgraded a box and now cdr_csv is not writing out to Master.csv - running as root, cdr_csv.so is loaded |
| 17:51.56 | putnopvut | JerJer[mobile]: what asterisk version? |
| 17:52.06 | *** join/#asterisk-dev qdk_ (n=qdk@195.242.194.42) |
| 17:52.30 | JerJer[mobile] | tried 1.4.18 and 1.4.19 - upgraded from early 1.2 |
| 17:54.18 | putnopvut | JerJer[mobile]: looking at the code, it looks as though your conclusion is correct. You do need cdr.conf |
| 17:55.07 | JerJer[mobile] | ok so i resume a full restart is requried - a reload didn't magically re-start cdr_csv logging |
| 17:55.50 | putnopvut | JerJer[mobile]: try module load cdr_csv.so |
| 17:56.28 | JerJer[mobile] | that is what i tried |
| 17:58.09 | putnopvut | crud. Okay, then yeah, a restart is what's needed. |
| 18:03.47 | *** join/#asterisk-dev jmls_work (n=jmls_wor@mail.tessera.co.uk) |
| 18:12.12 | *** part/#asterisk-dev jmls_work (n=jmls_wor@mail.tessera.co.uk) |
| 18:14.04 | Corydon76-dig | Or more particularly, you need to unload cdr_csv.so, first |
| 18:15.10 | *** join/#asterisk-dev joetester2 (n=joeteste@216.191.34.13) |
| 18:16.50 | putnopvut | Corydon76-dig: it should have declined to load if the conf file was not there? |
| 18:17.14 | Corydon76-dig | putnopvut: declining to load is not the same as being unloaded |
| 18:18.04 | putnopvut | I guess I'm saying that unloading shouldn't do anything since the module should not have loaded in the first place. |
| 18:19.35 | Corydon76-dig | putnopvut: it's in memory, even if the module isn't activated |
| 18:20.30 | putnopvut | um, why? |
| 18:21.45 | Corydon76-dig | Because trying to unload it automatically causes crashes |
| 18:22.46 | putnopvut | So if a module declines to load, it's still in memory but it just is inert? |
| 18:22.58 | Corydon76-dig | Correct |
| 18:32.43 | *** join/#asterisk-dev Greek-Boy (n=email@41.221.58.13) |
| 18:46.02 | JerJer[mobile] | putnopvut: restarting didn't help |
| 18:47.08 | Corydon76-dig | JerJer[mobile]: can you pastebin the contents of cdr.conf ? |
| 18:47.30 | JerJer[mobile] | just [general] and enabled=yes |
| 18:47.37 | Corydon76-dig | Ah... |
| 18:47.44 | Corydon76-dig | It's "enable" not "enabled" |
| 18:47.50 | JerJer[mobile] | er yeah |
| 18:47.54 | JerJer[mobile] | its enable |
| 18:47.59 | JerJer[mobile] | phat fingered |
| 18:48.00 | JerJer[mobile] | it |
| 18:48.04 | JerJer[mobile] | here |
| 18:48.13 | JerJer[mobile] | i see it finding cdr.conf |
| 18:48.23 | Corydon76-dig | You also need a [csv] section |
| 18:48.55 | Corydon76-dig | with possibly a 'loguniqueid=yes' in it, but blank works, as well |
| 18:51.12 | Corydon76-dig | But a reload event should be sufficient |
| 18:51.57 | Corydon76-dig | Err, no... It needs an unload/load cycle to get it to come up |
| 18:52.05 | Corydon76-dig | Otherwise it doesn't register the backend |
| 18:56.33 | JerJer[mobile] | trying now |
| 19:06.13 | Corydon76-dig | Bug fixed, btw |
| 19:10.09 | moy | Qwell: I see that while ZT_SENDTONE is in-progress (ms->dialing), any read will return only 0's, could you explain briefly why? |
| 19:10.29 | Qwell | nope.. |
| 19:11.15 | moy | any one else who might know? need to be able to do both things, wonder if is possible with zaptel |
| 19:11.51 | moy | otherwise MF R2 signaling will not work |
| 19:13.36 | moy | Mark suggested just get rid of ms->dialing when ZT_SENDTONE is doing R2 MF, but that causes the tone to be intermitent |
| 19:16.09 | Juggie | mark was at a conference today, did a speech and talked about working on R2 with you. |
| 19:16.29 | Juggie | in response to someone asking what was the coolest thing you were working on right now that you can talk about |
| 19:18.20 | moy | Juggie: yeah, thanks to Makr now ast_dsp detect MF R2 tones just fine :) |
| 19:18.30 | moy | s/Makr/Mark |
| 19:18.41 | Juggie | yeah he mentioned writing that today |
| 19:19.07 | caio1982 | Juggie: what conference was that? |
| 19:19.23 | moy | unfortunately I'm still stuck with this issue with zaptel |
| 19:20.25 | Juggie | it360 in toronto |
| 19:21.57 | *** join/#asterisk-dev Greek-Boy (n=email@41.221.58.13) |
| 19:29.40 | JerJer[mobile] | Corydon76-dig: that did it - big thanks |
| 19:31.24 | *** part/#asterisk-dev gmaruz1 (n=maruzz@213-140-6-122.ip.fastwebnet.it) |
| 19:31.28 | mvanbaak | nice, that commit to fix 12224 is a revert of something that went in last month |
| 19:34.20 | file | M12224 |
| 19:34.24 | MuffinMan | [closed] [Asterisk] Channels/chan_skinny 0012224: Use ast_verb instead of ast_debug for channel driver debugging reported by DEA http://bugs.digium.com/view.php?id=12224 |
| 19:36.15 | mvanbaak | they were ast_verbose() earlier |
| 19:36.41 | mvanbaak | converted to ast_debug() because it was debug info |
| 19:38.07 | Qwell | oh? |
| 19:38.18 | Qwell | know what bug number? |
| 19:38.31 | sruffell | tzafrir: Sorry about the 1.2.25 build problem with fxo_modes.h. Clearly I didn't build from a fresh checkout after merging the wctdm24xxp and wcte12xp changes into the 1.2 branch. |
| 19:38.47 | sruffell | ...looking forward to a single zaptel branch. |
| 19:39.35 | tzafrir | sruffell, yeah. I should have nightly builds for 1.2 as well :-( |
| 19:39.58 | mvanbaak | Qwell: not on a bug |
| 19:40.00 | Qwell | M11967 |
| 19:40.01 | MuffinMan | [closed] [Asterisk] Channels/chan_skinny 0011967: [patch] replace ast_verbose with ast_debug(1, for debugging reported by mvanbaak http://bugs.digium.com/view.php?id=11967 |
| 19:40.07 | mvanbaak | ah, there |
| 19:40.08 | mvanbaak | yeah |
| 19:41.20 | Qwell | but why would skinnydebug be set? |
| 19:41.57 | mvanbaak | hhmm |
| 19:42.05 | mvanbaak | maybe this is better indeed. |
| 19:42.47 | JerJer[mobile] | ugh someone wants MWI on chan_h323 now |
| 19:43.08 | Qwell | mvanbaak: I'll leave it then :D |
| 19:43.50 | mvanbaak | or maybe not |
| 19:44.05 | mvanbaak | looks like a sip debug is using ast_verb as well |
| 19:45.14 | file | JerJer[mobile]: are they considering lack of it a bug? |
| 19:46.11 | JerJer[mobile] | i guess |
| 19:46.34 | Qwell | M12397 |
| 19:46.35 | MuffinMan | [new] [Asterisk] Applications/app_voicemail 0012397: [patch] Add a flag to VoiceMail to force write to 'default' context reported by serg_remote http://bugs.digium.com/view.php?id=12397 |
| 19:46.38 | Qwell | does that make any sense to anybody? |
| 19:47.46 | Qwell | I think he's saying he's using voicemail contexts as the language? |
| 19:48.35 | putnopvut | Qwell: I have no idea what he's talking about. |
| 19:48.42 | putnopvut | Moreover, it's a feature request without a patch. |
| 19:48.45 | Qwell | closing |
| 19:48.48 | mvanbaak | Qwell: looks like it |
| 19:50.31 | mvanbaak | I still have this weird thing in skinny, but cant really pinpoint where it goes wrong |
| 19:50.40 | mvanbaak | if I'm on the phone, and a second call comes in |
| 19:50.51 | mvanbaak | my 7960 rings and shows the second call |
| 19:51.10 | mvanbaak | if the caller hangs up, the call disappears from the lcd of the 7960, but it keeps ringing |
| 19:51.14 | mvanbaak | today I had this again |
| 19:51.21 | mvanbaak | but found out something funny |
| 19:51.33 | Qwell | heh, he had a patch |
| 19:51.34 | mvanbaak | if it is still ringing, but the call is gone and no longer on the lcd |
| 19:51.53 | mvanbaak | and another call comes in, it keeps ringing and this call is on the lcd |
| 19:52.16 | mvanbaak | if that one is not answered and the caller hangs up, it dissapears from the lcd AND THE RINGING STOPS ! |
| 19:52.21 | mvanbaak | it's weird |
| 19:52.58 | mvanbaak | oh, and when that happened, and I hang up the call I was in, it wont go away from the lcd |
| 19:53.07 | Qwell | I've seen that too |
| 19:53.10 | mvanbaak | so something must be wrong with call cancel/end |
| 19:53.44 | mvanbaak | I was too busy to troubleshoot it today |
| 19:55.17 | mvanbaak | dont know if it happens on my 7905. that one only has one line configured |
| 19:55.23 | mvanbaak | my 7960 has 2 lines configured |
| 19:55.35 | Qwell | I think it still happens with subs |
| 19:57.07 | putnopvut | I just got three e-mails from the bugtracker with completely blank bodies. |
| 19:57.23 | Qwell | hmm, I thought my thunderbird was being stupid |
| 19:58.10 | file | funky |
| 19:58.27 | *** join/#asterisk-dev gmaruz1 (n=maruzz@213-140-6-122.ip.fastwebnet.it) |
| 20:00.06 | Juggie | i have the perfect idea for multi hosted asterisk and AMI |
| 20:00.22 | mvanbaak | putnopvut: I have them as well |
| 20:00.44 | Qwell | putnopvut: it's just that one bug for me |
| 20:00.47 | Qwell | 12388 |
| 20:00.53 | Juggie | and the problem of seeing other peoples events, make it such that you can set the AMI account to require a channel variable be equal to a certain value to display the event to the given user |
| 20:01.10 | Juggie | that wo uld be perfect for multihosting |
| 20:04.18 | putnopvut | Qwell: same here. |
| 20:04.32 | Qwell | jpeeler: any idea why that might happen? :D |
| 20:04.36 | putnopvut | Qwell: well, it could be other bugs too, but that's the only one for which I've received e-mails. |
| 20:04.50 | Qwell | I've gotten other ones today, and they're fine |
| 20:04.56 | file | ditto. |
| 20:05.53 | mvanbaak | I get those empty emails from time to time |
| 20:06.00 | mvanbaak | started like a month ago I think |
| 20:06.10 | mvanbaak | it's not often, but sometimes 2 or 3 in a row |
| 20:06.51 | jpeeler | not really... they are totally blank? |
| 20:06.59 | putnopvut | jpeeler: yep. |
| 20:07.18 | Qwell | subject is fine |
| 20:07.45 | Qwell | headers are all intact |
| 20:08.49 | Qwell | only thing I can think of is that the description is pretty long |
| 20:09.18 | jpeeler | for 12388? |
| 20:09.22 | Qwell | yeah |
| 20:09.45 | jpeeler | i don't see a description? |
| 20:09.53 | Qwell | it's hidden in the basic view |
| 20:09.57 | Qwell | err |
| 20:09.58 | Qwell | maybe not |
| 20:10.03 | Qwell | and yeah, it's there, but not showing up |
| 20:10.16 | Qwell | if you hit update, you'll see it all |
| 20:10.28 | jpeeler | i did that |
| 20:11.05 | *** join/#asterisk-dev snuff-home (i=snuff@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 20:11.11 | putnopvut | Hmmm, I wonder...I may have caused the problem... |
| 20:11.15 | jpeeler | am i the only one not seeing the description? |
| 20:11.30 | Qwell | putnopvut: nope, it happened to me before you commented on it |
| 20:11.45 | putnopvut | There was a bug earlier where I mis-clicked and clicked "update issue" and then immediately hit the back button on my browser. |
| 20:11.53 | putnopvut | It may have been 12388. I can't remember. |
| 20:12.00 | putnopvut | But I don't know how that would cause this to happen. |
| 20:12.10 | putnopvut | But it's the one thing I can think of that I did odd recently. |
| 20:12.28 | putnopvut | jpeeler: Mind if I come over and see? |
| 20:12.39 | jpeeler | of course not :) |
| 20:18.40 | Qwell | fixed! |
| 20:18.50 | Qwell | "The following issue has been UPDATED. " |
| 20:20.15 | jpeeler | Qwell: you got an email? |
| 20:20.18 | Qwell | yep |
| 20:20.35 | jpeeler | any chance that it was queued or something? |
| 20:20.55 | jpeeler | i didn't get one and it doesn't look like putnopvut has commented yet |
| 20:20.57 | Qwell | 04-09-08 15:13 jpeeler Description Updated |
| 20:21.04 | jpeeler | oh right |
| 20:21.10 | jpeeler | i guess i wouldn't get that email |
| 20:21.29 | putnopvut | I just commented. |
| 20:21.39 | Qwell | much better |
| 20:21.46 | putnopvut | yes...interesting. |
| 20:21.55 | jpeeler | yep fixed |
| 20:22.10 | Qwell | since file wasn't there... the problem was the overly long description, apparently? |
| 20:22.51 | file | raises eyebrow |
| 20:23.04 | jpeeler | i've noted the problem and will try to fix it in the next version, if the mantis people didn't already |
| 20:23.08 | *** join/#asterisk-dev ta^3 (n=tacvbo@189.146.192.67) |
| 20:25.37 | Juggie | grrrr... i have no idea whats going on with merging with svn |
| 20:25.43 | Juggie | my branch is totally hosed. |
| 20:26.50 | Juggie | i wonder if my svnmerge is buggy. |
| 20:27.11 | mvanbaak | Juggie: you use svnmerge from repotools ? |
| 20:27.14 | Juggie | yes |
| 20:27.28 | Juggie | and its dying it merges a couple of updates and dies |
| 20:27.32 | mvanbaak | hhmm, that never failed on me |
| 20:27.34 | Juggie | just exits without any error |
| 20:27.51 | Juggie | but doesnt do all that it shows when you do svnmerge avail |
| 20:28.02 | mvanbaak | is it a lot ? |
| 20:28.12 | Juggie | 30-40 revisions |
| 20:28.25 | mvanbaak | hhmm, not too much |
| 20:28.45 | Juggie | its probally all out of sync now i'm going to have to delete it |
| 20:29.03 | mvanbaak | jpeeler: it did show the mail now for me as well |
| 20:29.23 | Juggie | hmmm when i did svnmerge.real |
| 20:29.24 | Juggie | it worked |
| 20:29.34 | Qwell | Juggie: try raising the timeout in svnmerge |
| 20:29.37 | Juggie | the version of svnmerge i have from digium repo must be hosed. |
| 20:29.43 | Juggie | Qwell, its not taking that long |
| 20:30.06 | mvanbaak | looking at the commit mails show only 4 or 5 lines changed indeed |
| 20:30.22 | mvanbaak | weird |
| 20:30.35 | jpeeler | mvanbaak: yeah, it seemed to be having a problem with the long description length |
| 20:30.56 | mvanbaak | I used the repotools svnmerge today with a project hosted on sf.net. merging 3 new tinymce versions etc around |
| 20:30.59 | mvanbaak | worked fine |
| 20:31.04 | mvanbaak | jpeeler: ah |
| 20:31.36 | mvanbaak | jpeeler: make sure it's not a php bug |
| 20:31.36 | jpeeler | mvanbaak: i almost have everything working in the multiparking branch, at least for zap devices |
| 20:31.47 | mvanbaak | jpeeler: I noticed :) |
| 20:32.08 | mvanbaak | it's nice to see all my work was in the right direction :) |
| 20:32.40 | mvanbaak | of course it's more like a port of oej's first version, but that lacked a lot of stuff |
| 20:33.31 | jpeeler | i wouldn't be surprised if once i get "finished" that some major chance is decided to be made |
| 20:33.45 | *** part/#asterisk-dev sruffell (n=sruffell@216.207.245.1) |
| 20:34.00 | jpeeler | s/chance/change |
| 20:34.57 | mvanbaak | jpeeler: that already happened while I was working on it |
| 20:35.05 | mvanbaak | the whole features stuff was changed |
| 20:35.12 | mvanbaak | made the branch a complete mess |
| 20:35.18 | mvanbaak | took me a day to fix it up |
| 20:38.37 | jpeeler | cont |
| 20:38.47 | jpeeler | argh, not gdb |
| 20:39.06 | file | jpeeler: very true, this is not gdb |
| 20:39.26 | jpeeler | sets a breakpoint on file |
| 20:39.34 | file | breaks |
| 20:44.54 | outtolunc | can't believe how some people thing if it isn't in the thebook it must not be possible <G> |
| 20:44.59 | outtolunc | er think |
| 20:56.09 | *** join/#asterisk-dev qdk_ (n=qdk@0x573fe57e.bynqu2.broadband.tele.dk) |
| 21:00.34 | *** join/#asterisk-dev jmls_home (n=jmls_hom@mail.tessera.co.uk) |
| 21:03.25 | jpeeler | mvanbaak: i just want to check if i have this part clear |
| 21:03.36 | mvanbaak | what part ? |
| 21:03.46 | jpeeler | the parkinglot set in each respective config file is the default parking lot |
| 21:03.57 | jpeeler | and everything else is done with the channel variables set in the dialplan |
| 21:04.03 | mvanbaak | yeah |
| 21:04.15 | mvanbaak | channel variable should overwrite what was set in the config file |
| 21:05.20 | jpeeler | right, ok |
| 21:05.36 | mvanbaak | I thought that logic already was in features.c |
| 21:05.51 | jpeeler | could have been |
| 21:06.14 | mvanbaak | actually |
| 21:06.17 | mvanbaak | I'm pretty sure |
| 21:07.53 | jpeeler | well actually i had to add something in chan_zap to read the parkinglot from the config file |
| 21:07.55 | mvanbaak | it is |
| 21:08.02 | mvanbaak | line 393 |
| 21:08.13 | mvanbaak | yeah, the config file stuff was removed |
| 21:08.24 | mvanbaak | oej put it in chan_zap |
| 21:08.35 | mvanbaak | but that made chan_zap non-compilable under devmode |
| 21:08.52 | jpeeler | i should be compiling under dev mode |
| 21:09.00 | mvanbaak | and I felt it was better to get features.c running before putting in the <channeldriver>_config_file stuff |
| 21:09.13 | mvanbaak | jpeeler: the way oej did it was bad bad bad |
| 21:09.15 | jpeeler | heh, well maybe i shouldn't worry about it either |
| 21:09.17 | mvanbaak | so I removed it |
| 21:10.02 | mvanbaak | features.c already overwrites the channeldrivers setting if a channel variable is set |
| 21:10.10 | mvanbaak | PARKINGLOT |
| 21:10.30 | mvanbaak | function findparkinglotname |
| 21:10.57 | jpeeler | correct |
| 21:10.59 | mvanbaak | so if the channel has a parkinglot set in it's configfile it will use that, unless dialplanvar overwrites it |
| 21:11.26 | jpeeler | but none of the config files are currently checked? |
| 21:11.30 | mvanbaak | nope |
| 21:11.32 | jpeeler | should i worry about that |
| 21:11.47 | mvanbaak | like I said, I removed that because the zap version was borked++ |
| 21:11.53 | mvanbaak | I can fix that if you want |
| 21:12.02 | jpeeler | well i added it to chan_zap, it's two lines |
| 21:12.08 | mvanbaak | yup |
| 21:12.10 | jpeeler | but, i'm not sure if it's in the best place |
| 21:12.20 | mvanbaak | oej used 8 lines and all 8 were borked |
| 21:12.48 | mvanbaak | I tried to fix it, but after 2 hours I gave up and removed it |
| 21:13.02 | mvanbaak | it should be implemented, but zap was the latest channeldriver on my list |
| 21:13.06 | jpeeler | i had totally forgotten about users.conf though, so i need to commit where i have it now |
| 21:13.09 | mvanbaak | <--- does not have zap stuff |
| 21:13.18 | jpeeler | ah, well glad i started with zap then |
| 21:13.21 | mvanbaak | I _HATE_ users.conf |
| 21:13.57 | mvanbaak | I am ready to implement it in chan_sip and chan_skinny and chan_iax2 |
| 21:14.28 | mvanbaak | should be a 2 or 3 line patch |
| 21:15.35 | jpeeler | i'm not sure if the config file stuff is a good thing or not |
| 21:15.45 | jpeeler | is there much benefit to it? |
| 21:16.20 | jpeeler | still have to use dialplan variables when going to a non-default parking lot |
| 21:16.36 | jpeeler | the only case i think it saves you anything is when you want a call to be parked in a non-default parking lot |
| 21:16.44 | jpeeler | then you don't have to set the parkinglot var |
| 21:16.48 | jpeeler | or am i missing something? |
| 21:19.05 | mvanbaak | well |
| 21:19.17 | mvanbaak | think multihosting |
| 21:19.29 | mvanbaak | in the configfile you can define the parkinglot for a peer/device/line |
| 21:19.44 | mvanbaak | makes it easier to create configfiles from a database |
| 21:20.02 | mvanbaak | [companyA_1000] |
| 21:20.10 | mvanbaak | parkinglot=companyA |
| 21:20.12 | mvanbaak | ... |
| 21:20.19 | mvanbaak | [companyB_1000] |
| 21:20.24 | mvanbaak | parkinglot=companyB |
| 21:20.41 | mvanbaak | no need to mess with the dialplan chanvars |
| 21:21.13 | jpeeler | perhaps there is more coding to be done |
| 21:21.15 | mvanbaak | that way your [macro-call-mortal] does not have to take care of the parkinglot |
| 21:21.28 | jpeeler | but currently, if the parkinglot is set in the config file |
| 21:21.28 | mvanbaak | hhmm, why ? |
| 21:21.46 | jpeeler | then the call will be parked there |
| 21:21.51 | jpeeler | which is fine |
| 21:21.52 | mvanbaak | yup |
| 21:21.54 | mvanbaak | /* Check if the channel has a parking lot */ |
| 21:21.54 | mvanbaak | if (!ast_strlen_zero(chan->parkinglot)) |
| 21:21.54 | mvanbaak | parkinglot = chan->parkinglot; |
| 21:22.16 | jpeeler | but then when trying to pick up a parked call, i've been having to set the parkinglot in the dialplan to pickup that call |
| 21:22.16 | mvanbaak | so the config file needs something like: |
| 21:22.48 | mvanbaak | } else if (!strncasecmp(v->name, "parkinglot")) { |
| 21:23.14 | mvanbaak | <PROTECTED> |
| 21:23.46 | mvanbaak | why ? the pickup code uses findparkinglotname as well |
| 21:24.11 | jpeeler | i don't know, but now that i know that is not intended behavior that makes more sense |
| 21:24.35 | jpeeler | not sure if i did that or it did that before... |
| 21:25.14 | jpeeler | so once the parkinglot is set from the config file, the only time the parkinglot changes afterwards is by a setting the parkinglot in the dialplan, right? |
| 21:25.19 | mvanbaak | the findparkinglotname will first set the parkinglot to the channels configured parkinglot, and use the one set in the dialplan to overwrite it |
| 21:25.26 | mvanbaak | indeed |
| 21:25.46 | jpeeler | in that case, i'll fix whatever is causing the problem |
| 21:25.59 | jpeeler | and if you want to add the config file stuff for the other channel drivers, be my guest :) |
| 21:26.09 | mvanbaak | already working on it ;) |
| 21:27.46 | mvanbaak | I think it should be: parkinglot[AST_MAX_CONTEXT]; |
| 21:28.58 | jpeeler | yeah that was already in chan_zap |
| 21:30.02 | jpeeler | but that was not where the channel got the parkinglot from, which was very confusing to figure out |
| 21:30.56 | mvanbaak | ********** Re-run 'make' to pick up H.323 parameters ********** |
| 21:30.59 | mvanbaak | ugh |
| 21:34.00 | jpeeler | i was wrong about having to set the parkinglot in the dialplan, all is well |
| 21:34.10 | mvanbaak | I knew it ! |
| 21:34.12 | mvanbaak | ;) |
| 21:35.20 | jpeeler | i guess i'm ready to dive into astobj2, which will probably take a while |
| 21:36.50 | mvanbaak | yeah |
| 21:36.55 | mvanbaak | that's why it stalled |
| 21:37.28 | mvanbaak | ao2 hurts my brain |
| 21:38.31 | Corydon76-dig | How so? |
| 21:40.45 | mvanbaak | I cant understand how to use an ao2 with ast_lists |
| 21:42.10 | Corydon76-dig | You don't |
| 21:42.18 | Corydon76-dig | Pick one or the other, not both |
| 21:42.51 | mvanbaak | I have astobj with a member that is an ast_list |
| 21:42.54 | snuff-work | small q.. if you do ao2_ref(o, -1) with 'o' locked does it release the lock on 'o' after unreffing? |
| 21:43.48 | file | snuff-home: no. |
| 21:44.26 | mvanbaak | Corydon76-dig: look at team/group/multiparking/main/features.c |
| 21:44.35 | Corydon76-dig | It must be unlocked before you can unref it |
| 21:44.41 | mvanbaak | line 102-142 |
| 21:46.29 | snuff-work | k thanks |
| 21:50.17 | Corydon76-dig | mvanbaak: I'd take out the AST_LIST_ENTRY item |
| 21:50.32 | Corydon76-dig | and use the ao2 container |
| 21:50.50 | mvanbaak | Corydon76-dig: when I tried that it became a disaster ;) |
| 21:51.00 | mvanbaak | like I said, for some reason I just dont get it |
| 21:51.01 | Corydon76-dig | No, just a lot of work |
| 21:51.15 | jpeeler | that's what i am supposed to do |
| 21:51.20 | mvanbaak | astobj (like it is now) makes perfect sense to me |
| 21:51.57 | Corydon76-dig | mvanbaak: let jpeeler do it, and all will be clear soon |
| 21:52.22 | mvanbaak | yup |
| 21:52.29 | mvanbaak | I'll bug him to explain it to me |
| 21:52.54 | mvanbaak | jpeeler: I just committed code to make the 'parkinglot' config stuff for chan_skinny |
| 21:53.05 | jpeeler | yeah i saw, thanks |
| 21:53.20 | mvanbaak | is that like how you did it in chan_zap ? |
| 21:54.36 | mvanbaak | if so, I'll add it to chan_sip as well |
| 21:57.59 | *** part/#asterisk-dev gmaruz1 (n=maruzz@213-140-6-122.ip.fastwebnet.it) |
| 21:58.20 | mvanbaak | ugh, chan_sip is ......... interesting |
| 21:59.12 | jpeeler | that appears to be the same, although the parkinglot was a little more buried in chan_zap |
| 21:59.28 | jpeeler | which makes me uneasy if i put it in the right place |
| 21:59.42 | mvanbaak | did you commit it ? |
| 21:59.52 | jpeeler | let me commit the latest copy |
| 22:00.07 | mvanbaak | wow, this is not good |
| 22:00.25 | mvanbaak | I had long hair, did not go to haircutter for 5 years |
| 22:00.42 | mvanbaak | now I have it 6mm short, and I have to cut it every week |
| 22:00.44 | mvanbaak | blegh |
| 22:04.33 | jpeeler | should be there, the bot didn't report it though |
| 22:05.01 | mvanbaak | I have it |
| 22:05.06 | mvanbaak | looks correct to me |
| 22:05.35 | mvanbaak | hhmm |
| 22:05.38 | jpeeler | it works |
| 22:05.47 | mvanbaak | going to 3 mm hair tomorrow |
| 22:06.06 | mvanbaak | ok, if it works I can fold it into chan_sip as well |
| 22:06.13 | mvanbaak | it works on chan_skinny |
| 22:06.16 | mvanbaak | just tried |
| 22:06.22 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 22:06.34 | mvanbaak | gheh |
| 22:06.53 | mvanbaak | s/dslextreme/dslextremeunstable/ |
| 22:06.54 | jpeeler | how many more does that leave? |
| 22:07.00 | mvanbaak | erm |
| 22:07.03 | outtolunc | haha yeah it sure is <G> |
| 22:07.03 | mvanbaak | a lot |
| 22:07.04 | mvanbaak | ? |
| 22:08.18 | mvanbaak | alsa, gtalk, h323, iax2, local, mgcp, misdn, unistim |
| 22:08.42 | mvanbaak | oh, skip the local one |
| 22:08.59 | jpeeler | alsa needs it? |
| 22:09.10 | mvanbaak | I'm not touching it ;) |
| 22:09.40 | jpeeler | jingle would need it i guess |
| 22:10.32 | *** join/#asterisk-dev anthm (n=anthm@mb40736d0.tmodns.net) |
| 22:10.32 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 22:12.48 | mvanbaak | I'll have to look at it tomorrow |
| 22:12.52 | mvanbaak | Thu Apr 10 00:12:52 CEST 2008 |
| 22:13.11 | jpeeler | goodnight mvanbaak |
| 22:13.25 | mvanbaak | niters. |
| 22:13.37 | mvanbaak | thanks for taking the time to fix multiparking |
| 22:16.31 | jpeeler | sure, i would start requesting testing, but might as well wait until the conversion to ao2 is done |
| 22:18.20 | mvanbaak | first the channel driver config files should hold the default parkinglot stuff |
| 22:18.24 | mvanbaak | then it's time for testing |
| 22:18.46 | mvanbaak | and if you want to move it to ao2 be my guest |
| 22:18.55 | jpeeler | has to |
| 22:18.58 | mvanbaak | and expect a shitload of questions by me |
| 22:19.13 | jpeeler | heh, well i suppose once i finish i can answer them |
| 22:19.26 | jpeeler | i'm starting from the ground |
| 22:19.44 | mvanbaak | yeah |
| 22:20.02 | mvanbaak | like I mentioned before, the list inside the object is what caused my pain |
| 22:21.23 | *** join/#asterisk-dev RoyK (n=roy@ip-79-17-149-91.dialup.ice.no) |
| 22:21.41 | *** join/#asterisk-dev RoyK (n=roy@ip-79-17-149-91.dialup.ice.no) |
| 22:21.44 | mvanbaak | dont get me wrong: I want to learn |
| 22:22.07 | mvanbaak | but I'm also a guy who believes in: "If it aint broken, dont fix it" |
| 22:22.25 | mvanbaak | and since most stuff in asterisk is still using astobj1 ..... |
| 22:22.56 | mvanbaak | I was glad to get this working with astobj1 |
| 22:23.16 | jpeeler | understood |
| 22:23.24 | mvanbaak | it has been my biggest work on asterisk |
| 22:23.50 | mvanbaak | and asterisk is the first project in C I touch |
| 22:24.51 | mvanbaak | well, first real project |
| 22:25.07 | mvanbaak | I've done some C before for the irc network I manage |
| 22:25.35 | mvanbaak | but a serious bug there means we have to live without that service for a week. and that impacts 6 servers ;) |
| 22:25.59 | jpeeler | who needs stability |
| 22:26.05 | mvanbaak | indeed |
| 22:26.15 | mvanbaak | it creates connection info and dns stuff |
| 22:26.24 | mvanbaak | who cares. it's only 50 users |
| 22:26.59 | mvanbaak | and I want to do it right when it comes to asterisk |
| 22:27.15 | mvanbaak | fixing stuff is different from implementing new stuff |
| 22:28.07 | mvanbaak | this multiparking branch is my first real work on a real project when it comes to implementing new stuff |
| 22:28.18 | mvanbaak | and to be honest, I'm pretty proud of it |
| 22:28.46 | mvanbaak | when I see what you altered.... it's not that much |
| 22:28.53 | jpeeler | nope it isn't |
| 22:29.36 | mvanbaak | all thanks to the asterisk project |
| 22:29.41 | jpeeler | the key was passing null to select can block indefinitely |
| 22:30.00 | mvanbaak | I got a lot of help here about the object stuff, and oej spend a day helping/training me |
| 22:30.01 | jpeeler | has much to learn as well |
| 22:30.03 | mvanbaak | that was great |
| 22:30.36 | mvanbaak | both oej and me were at FOSDEM in Brussels this year |
| 22:30.53 | mvanbaak | and we sit together almost a whole day to talk/hack on this |
| 22:31.17 | *** part/#asterisk-dev RoyK (n=roy@ip-79-17-149-91.dialup.ice.no) |
| 22:31.46 | mvanbaak | that's where I fixed most of the stuff, and oej only commented on the stuff I did, giving me pointers on how to do it |
| 22:31.50 | mvanbaak | it was a great time |
| 22:32.41 | mvanbaak | specially since he did not tell me how to do it, but where to get ideas and documentation on how to do it |
| 22:33.04 | file | is off for a walk |
| 22:33.15 | mvanbaak | latero file |
| 22:33.20 | mvanbaak | is off for sex |
| 22:33.44 | mvanbaak | bye all |
| 22:33.56 | jpeeler | see ya mvanbaak |
| 22:34.00 | mvanbaak | and thnx again jpeeler for spending time on multiparking |
| 22:34.11 | jpeeler | np |
| 23:53.24 | Corydon76-dig | "off for sex"? |