| 00:10.40 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.ct.comcast.net) |
| 00:22.45 | _eric | zavoid- as soon as I changed dtmfmode to auto everything worked great! |
| 00:23.14 | ZaVoid | :) |
| 00:23.21 | _eric | thanks so much |
| 00:23.25 | ZaVoid | no problem man |
| 00:23.32 | _eric | the client looks like a toy |
| 00:23.35 | _eric | but it works pretty great |
| 00:26.49 | ZaVoid | which client? |
| 00:27.01 | ZaVoid | oh sjphone? |
| 00:27.06 | _eric | the zoipit or whatever it is |
| 00:27.33 | ZaVoid | oh yah |
| 00:27.36 | ZaVoid | i like sjphone |
| 00:27.38 | ZaVoid | brb |
| 00:27.42 | _eric | cool |
| 00:55.17 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.ct.comcast.net) |
| 02:13.52 | *** join/#asterisk-dev jpeeler (n=jpeeler@adsl-249-75-145.hsv.bellsouth.net) |
| 02:17.44 | jpeeler | tzafrir, i could be quite wrong, but i think in fxstest.c you need to check your include path for wctdm.h |
| 02:18.40 | tzafrir | jpeeler, right |
| 02:18.45 | tzafrir | fixing... |
| 02:18.46 | jpeeler | i assume it was forgotten during the kernel directory move |
| 02:18.48 | jpeeler | cool |
| 02:23.25 | tzafrir | done |
| 02:23.48 | jpeeler | woot! |
| 02:35.35 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.pa.comcast.net) |
| 02:54.28 | Corydon76-dig | jpeeler: yay, we got you coming in during the evening! |
| 02:57.54 | jpeeler | Corydon76-dig, yep! my presence will continue to increase now that i'm finally done with moving stuff (mostly) |
| 02:59.21 | *** join/#asterisk-dev JunK-Y (n=junky@modemcable183.17-83-70.mc.videotron.ca) |
| 03:01.59 | snuff-work | file giving away cookies.. that's not generally how it works |
| 03:04.18 | file | I didn't say they were baked |
| 03:05.52 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 03:05.52 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 03:06.33 | ZaVoid | kashi cookies are nice |
| 03:06.49 | ZaVoid | anyone taking bets on when the 6th undersea cable in the mid-east is gonna be cut? |
| 03:11.55 | russellb | a 5th one got cut?! |
| 03:12.38 | ZaVoid | yep |
| 03:12.41 | russellb | geez |
| 03:13.04 | ZaVoid | we thinking they'll wait to fri/sat for the next one |
| 03:13.16 | russellb | yay |
| 03:13.19 | ZaVoid | at least they stopped blocking our IP's since the cables started getting cut |
| 03:13.27 | ZaVoid | went through 2 weeks of complete IP blocks |
| 03:14.41 | ZaVoid | although when you block 3 of my /24's i can't feel bad when 80% of your internet gets cut off :) |
| 03:50.29 | *** join/#asterisk-dev putnopvut (n=putnopvu@user-24-214-112-81.knology.net) |
| 03:50.29 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 03:50.39 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 03:50.39 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 03:53.23 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 03:53.23 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 04:37.03 | Corydon76-dig | I hope he realized he did that to #asterisk too |
| 04:37.47 | putnopvut | I think it was a massive part from all channels. |
| 04:40.29 | *** join/#asterisk-dev ManxPower (n=manxpowe@251.sub-70-223-214.myvzw.com) |
| 05:36.19 | *** join/#asterisk-dev BBHoss (n=hoss@c-71-207-173-38.hsd1.al.comcast.net) |
| 05:36.51 | BBHoss | anyone using 1.6 with dundi? I seem to be having some trouble peering with someone on 1.4.17 |
| 05:38.23 | *** join/#asterisk-dev CunningPike (n=CunningP@S010600095b33697f.vc.shawcable.net) |
| 05:51.53 | Corydon76-dig | Qwell: danke. It's late. |
| 05:55.52 | *** join/#asterisk-dev outtolunc (n=me@c-67-174-216-60.hsd1.ca.comcast.net) |
| 05:56.24 | BBHoss | hey anyone here using the DUNDi-test network or using DUNDi period? There aren't any good docs for it |
| 06:51.33 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 06:51.33 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:59.29 | *** join/#asterisk-dev steliosk (n=Stelios@85.75.198.88) |
| 07:06.43 | sergee | morning all |
| 07:11.13 | snuff-work | hello |
| 07:12.21 | *** join/#asterisk-dev tzafrir (n=tzafrir@62.90.10.53) |
| 07:12.21 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:12.30 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@62.90.10.53) |
| 07:12.30 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 07:13.01 | sergee | snuff-work: any experience with gprof? |
| 07:13.40 | snuff-work | mm not much.. i remember using it at uni once or twice |
| 07:13.56 | snuff-work | no expert by far ;) |
| 07:16.36 | sergee | i'm trying to profile asterisk, but it always ends with code 155 and message (Profiling timer expired) |
| 07:17.10 | sergee | ok i should read some mans then.. |
| 07:19.10 | snuff-work | i'm assuming your at least compiling with -pg ;) |
| 07:20.06 | sergee | and even linking with it :) |
| 07:31.47 | snuff-work | sergee: http://209.85.173.104/search?q=cache:sXUWkkeQYdcJ:sam.zoy.org/writings/programming/gprof.html+Profiling+multithreaded+applications&hl=en&ct=clnk&cd=1&client=opera |
| 07:33.03 | sergee | snuff-work: thanks :) this .so is my primary tool, however something goes wrong when i using it with asterisk |
| 07:34.34 | snuff-work | ah.. |
| 07:35.38 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-159.bredband.comhem.se) |
| 07:44.36 | mvanbaak | mornin |
| 07:45.00 | jmls | morning |
| 07:46.17 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 07:46.17 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:57.04 | sergee | probably this problem with gprof is somehow connected with the way asterisk stops.. it cancells thread, so the end of code in the thread is never reached.. |
| 07:57.43 | *** join/#asterisk-dev OzyWebMaster (n=ozywebma@adsl123-108-66-11.dyn.koalatelecom.com.au) |
| 08:03.40 | *** join/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 08:55.49 | *** join/#asterisk-dev Sajjad_Ali_Musht (n=Sajjad_A@octroi.enst-bretagne.fr) |
| 09:15.36 | *** join/#asterisk-dev _ys (n=yuri@236-069.nat.mns.ru) |
| 09:17.18 | _ys | hi. mantis offline?testtesttesttest |
| 09:17.31 | _ys | hi. mantis offline? |
| 09:18.43 | _ys | o. online :) |
| 09:18.54 | mvanbaak | works great here |
| 09:27.04 | *** join/#asterisk-dev qdk (n=qdk@85.235.253.139) |
| 10:01.49 | *** part/#asterisk-dev jmls (n=jmls@81.138.42.77) |
| 10:14.30 | *** join/#asterisk-dev jmls (n=jmls@81.138.42.77) |
| 10:25.53 | jeremy_g | jmls:morning ;) |
| 10:29.18 | *** join/#asterisk-dev RoyK (n=roy@fw.fortel.no) |
| 10:31.16 | jmls_home | morning |
| 10:31.35 | *** join/#asterisk-dev nebojsajsimic (n=nebojsaj@cable-89-216-16-106.static.sbb.co.yu) |
| 11:19.50 | *** join/#asterisk-dev _ys (i=yuri@91.151.196.254) |
| 11:47.52 | *** join/#asterisk-dev michael-i (n=michael-@141.41.40.225) |
| 12:08.43 | *** part/#asterisk-dev jmls_home (n=jmls@81.138.42.77) |
| 12:09.41 | *** join/#asterisk-dev jmls_work (n=jmls@81.138.42.77) |
| 12:30.37 | *** join/#asterisk-dev flujan (n=flujan@200-160-115-020.static.spo.ctbc.com.br) |
| 13:01.55 | *** join/#asterisk-dev allankardec (n=root@189.13.34.128) |
| 13:05.33 | nebojsajsimic | hi all |
| 13:05.42 | nebojsajsimic | plz help for php agi |
| 13:06.09 | nebojsajsimic | write("SAY NUMBER 2233 X"); work fine |
| 13:06.11 | nebojsajsimic | but |
| 13:06.26 | nebojsajsimic | write("Dial(SIP/063481720@dragan,r,15)"); |
| 13:06.46 | nebojsajsimic | not working can somebody help little |
| 13:13.23 | *** join/#asterisk-dev ZaVoid (n=zavoid@66-95-182-90.client.dsl.net) |
| 13:20.36 | atis_work | nebojsajsimic: isn't it Dial(SIP/abc,15,r)? |
| 13:22.39 | nebojsajsimic | huh i will try NOW |
| 13:22.51 | atis_work | please continue in #asterisk |
| 13:23.32 | nebojsajsimic | not work |
| 13:27.42 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:27.42 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 13:29.12 | lmadsen | morning! :) |
| 13:33.21 | ZaVoid | morning lmadsen |
| 13:33.49 | BBHoss | had anyone been having problems with dundi on 1.6, i keep getting ENCREJ, and my keys match up because i just diffed |
| 13:34.25 | lmadsen | morn :) |
| 13:34.44 | lmadsen | BBHoss: not seen that error, but I haven't tried it on 1.6 |
| 13:34.46 | lmadsen | just 1.4 |
| 13:35.06 | BBHoss | hmm, anything that would cause an ENCREJ other than bad keys |
| 13:35.17 | lmadsen | no idea |
| 13:35.19 | BBHoss | there aren't any errors show with debug off |
| 13:35.38 | lmadsen | what is the error msg? |
| 13:35.42 | lmadsen | does it cause things to stop working? |
| 13:35.48 | BBHoss | nothing works |
| 13:35.57 | BBHoss | cant query, lookup etc |
| 13:36.02 | BBHoss | always returns no results |
| 13:36.13 | lmadsen | did you try using the same configs with 1.4 to see what happens? |
| 13:36.20 | BBHoss | when a guy on 1.4.17 query's me, it fails too |
| 13:36.26 | BBHoss | yeah im about to |
| 13:36.33 | lmadsen | I'd make sure it's not a config issue, then you can file a bug |
| 13:38.23 | mvanbaak | mornin |
| 13:39.39 | *** join/#asterisk-dev amessina (n=amessina@h-66-166-108-202.chcgilgm.covad.net) |
| 13:44.09 | *** part/#asterisk-dev amessina (n=amessina@h-66-166-108-202.chcgilgm.covad.net) |
| 14:00.19 | *** join/#asterisk-dev steliosk (n=Stelios@85.75.198.88) |
| 14:08.35 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 14:17.54 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 14:38.38 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 14:38.38 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 14:48.23 | *** join/#asterisk-dev miguel3239 (n=elguerom@ns1.nashuacs.com) |
| 14:50.26 | BBHoss | lmadsen, i tried my dundi config on 1.4.10 and it works, seems like a 1.6 issue |
| 14:51.22 | BBHoss | what kind of information do you guys want for the bug reports |
| 14:53.25 | lmadsen | ummm... I guess the configs and the error messages you're seeing? |
| 14:53.36 | BBHoss | ok |
| 14:53.36 | lmadsen | attach the relevant parts in a file to the note |
| 14:53.42 | lmadsen | and give as much information about how to reproduce as possible |
| 14:53.57 | BBHoss | do you know of anyone else using dundi on 1.6? |
| 14:54.18 | BBHoss | there is already a bug "lookup crashes asterisk" for the 1.6 |
| 15:09.25 | *** join/#asterisk-dev jameswf-home (n=james@dsl093-157-131.phx1.dsl.speakeasy.net) |
| 15:30.04 | tzafrir | M11941 |
| 15:30.06 | MuffinMan | [new] [Zaptel] General 0011941: too many arguments to function ‘kmem_cache_create’ reported by sperreault http://bugs.digium.com/view.php?id=11941 |
| 15:30.38 | tzafrir | This is not a zaptel issue at all . This (and 11942) is an misdn issue. Where should I move it to? |
| 15:31.03 | tzafrir | Is zaptel still the recommended installation procedure for misdn? |
| 15:33.50 | ZaVoid | can one of you dev guys explain to me what relaxdtmf does techincally in 1.4? |
| 15:40.58 | jeremy_g | how can i undo what ./configure && make install does to my file system? |
| 15:46.48 | jeremy_g | guys, asterisk 1.6 is lovely |
| 15:47.02 | jeremy_g | who wrote this Bridge thingie |
| 15:48.15 | jeremy_g | its just getting better and better |
| 15:59.40 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 15:59.40 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 16:01.41 | atis_work | hello putnopvut |
| 16:01.52 | putnopvut | Hi atis_work. |
| 16:02.12 | atis_work | would you want to respond on 11896? |
| 16:03.06 | lmadsen | M11896 |
| 16:03.07 | MuffinMan | [new] [Asterisk] Applications/app_queue 0011896: Optimized update_realtime_member_field function reported by atis http://bugs.digium.com/view.php?id=11896 |
| 16:03.07 | putnopvut | I'll have a look when I finish going through my e-mail. |
| 16:03.33 | atis_work | cool, does M11869 works inline? |
| 16:03.35 | *** join/#asterisk-dev ManxPower (n=manxpowe@175.sub-75-203-57.myvzw.com) |
| 16:04.05 | putnopvut | I don't understand the question? |
| 16:05.04 | atis_work | putnopvut: i'm just wondering - would you like me to rework patch more - to handle those cases |
| 16:05.50 | putnopvut | How were you planning on handling them? |
| 16:07.01 | atis_work | huh, i already forgot now, but i described that in last note |
| 16:07.24 | atis_work | like - checking return value of update |
| 16:08.00 | *** join/#asterisk-dev jpeeler (n=jpeeler@216.207.245.1) |
| 16:08.36 | putnopvut | If you can rework the patch to handle that second case I mentioned specifically, that would be fantastic. |
| 16:12.27 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 16:12.27 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 16:15.08 | *** join/#asterisk-dev troy42 (i=troy@z.paranode.com) |
| 16:15.35 | troy42 | morning |
| 16:15.45 | atis_work | putnopvut: ok, i'll try |
| 16:16.26 | putnopvut | Thanks :) |
| 16:18.36 | *** join/#asterisk-dev amessina (n=amessina@h-66-166-108-202.chcgilgm.covad.net) |
| 16:22.37 | jmls_work | atis_work: I also agree ;) |
| 16:23.43 | *** join/#asterisk-dev allankardec (n=root@20150057143.user.veloxzone.com.br) |
| 16:31.27 | *** join/#asterisk-dev Bourrelle (n=Bourrell@132.207.156.100) |
| 16:32.12 | Bourrelle | Hi, if I close a video session with asterisk with a SIP event, does asterisk send me back an ack or it just close the session.. |
| 16:32.22 | Bourrelle | its for a sequence diagram |
| 16:35.20 | Bourrelle | same question if I put an audio session onHold |
| 16:35.54 | ManxPower | Bourrelle: your best bet is to start with the RFCs, then find out how/where Asterisk differs from the RFC. |
| 16:36.21 | Bourrelle | any url for rfc ? |
| 16:36.28 | Bourrelle | im reading asterisk book right now |
| 16:38.22 | ManxPower | Results 1 - 10 of about 187,000 for sip rfc AND "too lazy to use google". (0.12 seconds) |
| 16:38.44 | ManxPower | The Asterisk book seems mostly user-centric. You are doing low level sutff. |
| 16:39.17 | ZaVoid | Bourrelle: why don't you just do a tethereal trace and look at what is in the SIP messages? |
| 16:40.00 | ZaVoid | tethereal is your friend |
| 16:41.30 | lmadsen | wireshark (ethereal) will even create the sequence diagram for you |
| 16:41.36 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 16:41.52 | ZaVoid | also get tracebuster |
| 16:41.57 | ZaVoid | its invaluable |
| 16:42.33 | jeremy_g | i am compiling 1.6 and says cannnot find : cannot find -lwrap |
| 16:42.39 | ZaVoid | lmadsen: you've used tracebuster right? |
| 16:42.45 | lmadsen | never even heard of it |
| 16:42.46 | jeremy_g | what am i missing |
| 16:42.57 | ZaVoid | btw where does wireshark create the sequence diagram.. iw as not aware of that |
| 16:43.12 | lmadsen | its in one of the drop down menus |
| 16:43.19 | lmadsen | I forget exactly where, but it's fairly obvious |
| 16:43.33 | ZaVoid | there is 3 versions.. i got the pro version.. the free version doesn't do rtp.. http://www.touchstone-inc.com/tbfeatures.htm |
| 16:43.33 | lmadsen | very handy feature |
| 16:43.37 | ZaVoid | check it out.. its amazing |
| 16:43.47 | ZaVoid | windows only though :( |
| 16:43.53 | ZaVoid | gotta fire up parallels to run it |
| 16:44.17 | lmadsen | ahh... ya, I use vmware server and fusion (server on my server, fusion on my laptop) |
| 16:45.13 | ZaVoid | any better you've found? |
| 16:45.27 | ZaVoid | i've got a parallels license.. only reason i've stuck with it... its hog sometimes |
| 16:46.10 | ZaVoid | your talking about the sequnce drawing from the statistics drop down menu i guess? |
| 16:48.05 | lmadsen | ZaVoid: I think so... been a long time since I've needed it |
| 16:48.17 | lmadsen | I like VMware Fusion. I used it for 30 days, and works quite well |
| 16:48.25 | ZaVoid | yeah i thought yuo meant somthing esle |
| 16:48.28 | lmadsen | big fan of VMware and their products |
| 16:48.34 | ZaVoid | check out the tracebuster though its really nice |
| 16:48.44 | lmadsen | will try and keep that in mind |
| 16:48.46 | ZaVoid | i use eventhelix to write my sip call flow docs |
| 16:49.54 | Corydon76-vcch | Deeewayne: ping |
| 16:51.18 | ZaVoid | you running a mac lmadsen ? |
| 16:54.16 | ZaVoid | i dunno |
| 16:54.25 | file | VMware Workstation, VMware Server, VMware <insert other products> |
| 16:55.08 | ZaVoid | linux version maybe? |
| 16:55.33 | ZaVoid | nope just mac :) |
| 16:55.59 | outtolunc | nods |
| 16:56.03 | ZaVoid | my stupid wireshark via x11 dies about 15% of the time |
| 16:59.52 | ZaVoid | lmadsen: have you been using skitch at all? great new mac program for marking up screenshots etc |
| 17:11.16 | jeremy_g | ZaVoid:memory leak in wireshark |
| 17:12.04 | jeremy_g | lmadsen:what does vmware fusion do? |
| 17:13.55 | ZaVoid | yeah even happens when i click on random menu's inside of it.. oh well not much ya can do |
| 17:15.09 | lmadsen | jeremy_g: it lets you run virtual machines on OSX... |
| 17:15.29 | lmadsen | fusion is just for mac afaik |
| 17:15.32 | lmadsen | I even paid for it |
| 17:15.49 | lmadsen | need it so I can do clustering on my laptop during presentations |
| 17:22.31 | *** part/#asterisk-dev amessina (n=amessina@h-66-166-108-202.chcgilgm.covad.net) |
| 17:25.00 | russellb | Corydon76-dig: ping |
| 17:25.03 | russellb | M11943 |
| 17:25.04 | MuffinMan | [assigned] [Asterisk] Functions/func_logic 0011943: Feature to write variables to existing channels other than your own (func chanvar) reported by ramonpeek http://bugs.digium.com/view.php?id=11943 |
| 17:25.26 | Corydon76-vcch | pong |
| 17:25.39 | russellb | just wanted to see if we could come to some agreement on that one |
| 17:26.04 | russellb | it seems reasonable to me, it's a much less dangerous thing for the dialplan than some other stuff we have, like ChannelRedirect |
| 17:26.06 | Corydon76-vcch | My vote is to close it as "won't fix" |
| 17:26.17 | russellb | yeah, i read your comments ... |
| 17:26.18 | Qwell | Corydon76-vcch: he wrote a patch to do so |
| 17:26.52 | russellb | wrote a patch to do what? |
| 17:26.57 | Qwell | nevermind |
| 17:27.48 | Qwell | hadn't read the comments |
| 17:27.53 | russellb | k |
| 17:28.22 | russellb | i can see how changing an iterator variable would be stupid, but other variables could be just fine |
| 17:28.35 | russellb | i'm having a hard time being convinced that the feature is that evil :) |
| 17:28.44 | jmls | russellb: see my comments re readonly variables |
| 17:28.57 | jmls | and Set(UNIQUEID=foobar) |
| 17:28.59 | russellb | jmls: yeah, i saw that in -bugs ... it's a good idea IMO |
| 17:29.18 | Qwell | if the issue is with supporting it, we could always have it print a log message on the channel in which the variable was modified |
| 17:29.31 | jmls | you could then allow this function, as long as it doens't try to modify an existing variable |
| 17:29.33 | Qwell | "Channel variable BLAH was modified by channel xyz" |
| 17:30.23 | russellb | well, that's not really a support issue |
| 17:30.30 | russellb | it's more of a make it easier for users to debug issue ... |
| 17:30.35 | russellb | the code itself is trivial |
| 17:30.52 | russellb | there is basically nothing to support in that regard |
| 17:31.17 | russellb | the issue is how much rope to provide in the dialplan. |
| 17:31.19 | Corydon76-vcch | It's also a matter of more bugs getting filed by users saying "it's a bug; fix it". I don't want to see those bugs. |
| 17:31.30 | russellb | what bugs? |
| 17:31.33 | Qwell | "No. Closing." :p |
| 17:31.34 | jmls | There is already enough rope for a stupid person to hang themselves, whilst shooting themselves in the foot ... |
| 17:31.43 | Corydon76-vcch | Qwell: that's what I'm saying right now. |
| 17:31.57 | Qwell | this can already be done with global variables, but that is a hack way to do it |
| 17:32.10 | Corydon76-vcch | Qwell: it can be done with a database intermediary, as well |
| 17:32.10 | jmls | Qwell: not really, as you need to clean those out |
| 17:32.13 | russellb | and a database ... |
| 17:32.15 | *** join/#asterisk-dev RoyK (n=roy@ip-107-15-149-91.dialup.ice.no) |
| 17:32.23 | russellb | less efficient, of course |
| 17:32.28 | Qwell | sure, so why not directly in the dialplan? |
| 17:32.33 | Corydon76-vcch | Yes, but more predictable |
| 17:32.39 | russellb | and right, it means you have more crap to clean up |
| 17:33.41 | russellb | here is a reasonable use case ... "Generally what I wanted to do was to set a variable in the originating channel containing information about the hangup of the called channel gathered from the 'h' extension in that channel. |
| 17:33.41 | russellb | And to achieve this there is currently no 'good' solution." |
| 17:33.59 | russellb | so, yes, some intermediary could do it ... but this code is trivial, and makes implementing it trivial ... |
| 17:34.24 | russellb | any other votes? |
| 17:34.26 | jmls | I really think that if you simply prevented a channel from modifying an _existing_ variable in the target channel then there is no problem |
| 17:34.28 | jmls | yes yes |
| 17:34.28 | Qwell | besides, IMO there's already a lot of stupid things a user could do that would be far "worse" |
| 17:35.03 | Qwell | I don't think "users can use this to do something stupid" should be a reason to not implement something |
| 17:35.21 | jmls | n,Answer() |
| 17:35.25 | jmls | n,Hangup() |
| 17:35.34 | jmls | "my call just disconnects" |
| 17:36.02 | jmls | :) |
| 17:36.06 | Qwell | jmls: you and me both.. |
| 17:36.15 | Corydon76-vcch | Qwell: I'm less concerned with people doing stupid things than with ME having to support issues related to it |
| 17:36.42 | Corydon76-vcch | "Well it works MOST of the time...." |
| 17:36.50 | jmls | Corydon76-vcch: is your problem with the variables being overwritten, or just the whole concept ? |
| 17:36.59 | Corydon76-vcch | "I want you to fix it the REST of the time" |
| 17:37.15 | russellb | Corydon76-vcch: fine. just like when i complained about code quality in ldap, you can assign these issues to me. |
| 17:37.16 | Corydon76-vcch | jmls: it's a race condition, and I don't like enabling race conditions of any form |
| 17:37.21 | jmls | cause you could argue the same with global variables |
| 17:37.38 | jmls | my ${foo} has changed on me |
| 17:37.44 | Corydon76-vcch | jmls: yes, but there's a fine delimiter between globals and locals |
| 17:37.57 | Corydon76-vcch | jmls: what they want to do is make local variables no longer local |
| 17:38.41 | jmls | so I come back to the point I've made earlier: prevent a channel from modifying an _existing_ variable in the target channel |
| 17:39.13 | jmls | All I wanted to do was to pass the zap channel to the local channel before the call was answered |
| 17:39.20 | Corydon76-vcch | jmls: that would almost work, except that you have some variables, like MONITOR_FILENAME, when they aren't set, they take default values |
| 17:40.00 | Corydon76-vcch | So even that is a risky race condition |
| 17:40.01 | Qwell | Corydon76-vcch: this isn't making vars no longer local. they're still local to the channel. if 2 channels set var BLAH, they'll be different values - except for when this function is used |
| 17:40.32 | Qwell | he's basically adding a .write method to IMPORT |
| 17:40.47 | Corydon76-vcch | Qwell: think about in C, if you had a bunch of variables on the stack, and another thread was permitted to change those variables at any time. |
| 17:40.57 | Corydon76-vcch | Qwell: how could you be sure that ANYTHING would work? |
| 17:41.31 | russellb | but it is possible to implement that |
| 17:41.33 | jmls | ok, how about only allowing a remote channel to create /update a variable called REM_XXXXXXX |
| 17:41.33 | russellb | :) |
| 17:41.53 | jmls | so that you *know* it's been created from elsewhere |
| 17:42.03 | jmls | and doesn't / can't update anything critical |
| 17:42.13 | Corydon76-vcch | How about a channel datastore instead, called SYSVSHARE, that lets you access a special space of variables meant for IPC |
| 17:42.20 | jmls | eek |
| 17:42.53 | jmls | sledgehammer. Nut. |
| 17:42.54 | jmls | ;) |
| 17:43.07 | Corydon76-vcch | THAT I could get behind, because it would KEEP separation between variable spaces |
| 17:43.19 | jmls | sure, that would work |
| 17:43.39 | Corydon76-vcch | russellb: is that acceptable? |
| 17:43.57 | jmls | as long as it was simple to use / manipulate |
| 17:44.13 | atis_work | i think, everybody already seen in mantis, that i agree |
| 17:44.14 | jmls | oooh, the WRITE function would be a wrapper to the target datastore ? |
| 17:44.23 | russellb | Corydon76-dig: basically a channel variable space reserved for sharing in this way? |
| 17:44.27 | Corydon76-vcch | Set(SHAREVAR(${somechan},foo)=bar) |
| 17:44.36 | atis_work | Corydon76-vcch: in comparison to C, channel can't return variable |
| 17:44.37 | Corydon76-vcch | russellb: exactly |
| 17:44.40 | atis_work | as function |
| 17:44.51 | russellb | Corydon76-dig: yes, that would be acceptable |
| 17:44.52 | russellb | :) |
| 17:45.15 | russellb | Corydon76-dig: interested in writing it? |
| 17:45.15 | jmls | and Set(bar = SHAREVAR(${somechan},foo)) ? |
| 17:45.29 | russellb | jmls: yeah |
| 17:45.41 | Corydon76-vcch | jmls: fix the syntax ;-) |
| 17:45.50 | jmls | I contribute my 346 delegates ... |
| 17:45.53 | russellb | heh |
| 17:46.06 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 17:46.06 | russellb | Corydon76-vcch: great idea ... thank you for the compromise |
| 17:46.25 | Corydon76-vcch | russellb: I'll look at it. There was a huge lighning strike in Memphis on Tuesday and I'm helping VCCH pick up the pieces today |
| 17:46.40 | Corydon76-vcch | Off to a meeting now |
| 17:47.04 | russellb | sorry to hear that |
| 17:47.06 | russellb | no rush, though |
| 17:47.13 | russellb | i assigned it over to you for whenever you get to it |
| 17:47.15 | russellb | thanks again |
| 17:47.15 | Corydon76-vcch | If you want horror stories, call someone at TWiT and ask them about their Memphis facilities |
| 17:47.29 | Corydon76-vcch | (TW Telecom) |
| 17:48.45 | atis_work | hey, what was the think about SHAREVAR? it allows to declare variables as shared, or i have to access it every time to read value of shared variable? |
| 17:50.06 | *** join/#asterisk-dev joetester (n=patrick@216.191.34.13) |
| 17:50.52 | Qwell | Corydon76-vcch: you could probably make it so that if you pass no channel, it uses current channel. just to avoid having to do ${SHAREVAR(${thischan},var)} |
| 17:51.05 | Qwell | then you could just do ${SHAREVAR(,var)} |
| 17:54.20 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.12.183) |
| 18:01.07 | *** join/#asterisk-dev _mihai_ (n=_mihai_@x42073b02.ip.e-nt.net) |
| 18:01.21 | _mihai_ | hi all |
| 18:02.28 | russellb | uh oh |
| 18:02.32 | russellb | what'd i break? |
| 18:02.41 | Qwell | the world |
| 18:02.44 | russellb | crap! |
| 18:03.06 | russellb | speaking of breaking stuff ... i have some 1.4.18 tarballs that i need to push out |
| 18:03.07 | russellb | heh |
| 18:03.48 | jmls | soo ${foo} in the channel variables would / could have a different value to SHAREVAR(,foo) ? |
| 18:04.05 | atis_work | hmm, i don't like that |
| 18:04.19 | atis_work | i would like to "declare variable as shareable" |
| 18:04.33 | atis_work | so other channels could access it if i share it before |
| 18:05.32 | jmls | atis_work: if you Set(SHAREVAR(,foo)=bar) that would do what you want |
| 18:06.00 | Qwell | jmls: in theory, yeah |
| 18:06.06 | atis_work | and then just use it as ${foo} or as ${SHAREVAR(,foo)} |
| 18:06.38 | jmls | the second one |
| 18:06.50 | atis_work | huh, seems ugly |
| 18:06.56 | jmls | my batter on my keboard is dyin |
| 18:06.59 | jmls | :) |
| 18:07.05 | Qwell | atis_work: it makes it much more explicit, which is good |
| 18:07.13 | atis_work | maybe :) |
| 18:07.31 | atis_work | how about having channel as second and optional argument, not first |
| 18:07.43 | Qwell | that's a good point |
| 18:07.45 | jmls | cool |
| 18:07.55 | atis_work | Set(SHAREVAR(foo)=bar) for this channel |
| 18:07.55 | Qwell | there's no reason for channel to be first arg. I'll note that bug |
| 18:08.07 | atis_work | Set(SHAREVAR(foo,Local/222@internal)=bar) |
| 18:08.16 | jmls | yup |
| 18:09.02 | jmls | that would remove the need for IMPORTVAR, no ? |
| 18:09.08 | Qwell | jmls: correct |
| 18:09.17 | atis_work | great :) |
| 18:09.19 | Corydon76-vcch | I'd leave IMPORT as-is |
| 18:09.30 | jmls | deprecate it ! |
| 18:09.37 | Corydon76-vcch | IMPORT lets you access a variable in the main space |
| 18:09.42 | Qwell | oh, hmm, with this method, IMPORT would still be useful |
| 18:09.42 | Qwell | yeah |
| 18:09.46 | Corydon76-vcch | read-only, though |
| 18:10.03 | jmls | why would import still be useful ? |
| 18:10.17 | Qwell | because with SHAREVAR, you *have* to use SHAREVAR to read/write |
| 18:10.18 | Corydon76-vcch | And I might shorten the variable to just ${SHARE()} |
| 18:10.30 | atis_work | (y) |
| 18:10.47 | jmls | and ? with import you *have* to use IMPORT ? |
| 18:10.57 | Corydon76-vcch | SHARE is a separate space |
| 18:11.12 | Qwell | with IMPORT, you can read a "normal" channel variable from another channel. Set(foo=bar), Set(baz=${IMPORT(foo,chan)}) |
| 18:11.14 | Corydon76-vcch | namespace, that is |
| 18:11.20 | jmls | oh. I see. |
| 18:11.40 | jmls | couldn't you make SHARE read normal channel variables as well ? |
| 18:11.51 | atis_work | well, but that could be written by SHARE too |
| 18:11.52 | Qwell | that's the point. no :p |
| 18:12.07 | Corydon76-vcch | jmls: read, possibly |
| 18:12.12 | Qwell | maybe with a special option to SHARE? |
| 18:12.17 | jmls | yeah, read only. Mimic import |
| 18:12.23 | Qwell | for - again - explicitosity |
| 18:12.30 | jmls | lol |
| 18:12.32 | Qwell | (my word, but feel free to use it) |
| 18:12.32 | jmls | wtf ? |
| 18:13.18 | Qwell | and, I like how after it was suggested that "maybe I'll shorten the function name", everybody instantly switched to that :p |
| 18:14.12 | jmls | sometimes there is something that you don't want to SHARE. |
| 18:14.14 | Corydon76-vcch | Well, SHAREVAR isn't exactly correct English, it should have been SHAREDVAR, but I was in a hurry, and since they sound the same, it's best to go with a shortened form of SHARE, which is less confusing |
| 18:14.17 | jmls | SHARE(${yourgirlfriend}) |
| 18:14.35 | jmls | <PROTECTED> |
| 18:14.57 | Corydon76-vcch | The downside is that a shorter name is more generic, which could lead to confusion, but I'm not sure with what. |
| 18:15.24 | atis_work | well, how about SHARED? |
| 18:15.51 | jmls | I don't know about that. You are sharing information . All information in the dialplan in asterisk is stored in variables |
| 18:16.04 | jmls | (that was to Corydon76-vcch) |
| 18:16.44 | Corydon76-vcch | jmls: this is off the top of my head, no decision made yet |
| 18:17.22 | Corydon76-vcch | Yeah, SHARED(foo) sounds better |
| 18:19.42 | lmadsen | w00t :) |
| 18:19.44 | lmadsen | nice discussion |
| 18:19.47 | lmadsen | all caught up now |
| 18:19.52 | lmadsen | more documentation to write... yay! |
| 18:21.28 | joetester | I need guidance... what is the surefire asterisky way of checking if a string is empty or not in the code? |
| 18:21.30 | _mihai_ | hey guys... when you have a few moments, can somebody take a peek at bug 11923 and tell me if I'm on the right track there? |
| 18:21.41 | atis_work | joetester: ast_strlen_zero |
| 18:21.59 | atis_work | M11923 |
| 18:22.00 | MuffinMan | [new] [Asterisk] Channels/chan_iax2 0011923: chan_iax2 does not send full video frames when it is supposed to reported by mihai http://bugs.digium.com/view.php?id=11923 |
| 18:23.56 | joetester | I see this in the code: if (somestring) else ... would ast_strlen_zero be the way to go? |
| 18:24.16 | *** join/#asterisk-dev qdk (n=qdk@0x573fe57e.bynqu2.broadband.tele.dk) |
| 18:27.22 | atis_work | joetester: ast_strlen_zero checks the pointer and strlen, i'd say - yes |
| 18:27.39 | jmls | man, I think that we have weird discussions on this forum: http://www.theregister.co.uk/2008/02/07/astronomical_unit_inaccurate_shrinking_sun/ |
| 18:27.43 | atis_work | i have another question regarding shared variables |
| 18:28.00 | atis_work | would Set(SHARED(__foo)) be inherited? |
| 18:28.06 | bkruse | can you set a variable inside a context? Without having it be globaled? |
| 18:29.17 | jmls | atis_work: I wouldn't have thought so. Unless the whole datastore is inherited .. |
| 18:29.54 | jmls | urgh |
| 18:30.22 | atis_work | jmls: well, that's the point. i would still want those inherited, because i keep some call settings in inherited variables, and sometimes would want to change them from child channel |
| 18:30.47 | jmls | I suppose that when a new channel is created, it could look through the datastore and create a new datastore in the new channel with only the __ variables set |
| 18:31.19 | jmls | atis_work: for what you want, you don't need __ |
| 18:31.37 | atis_work | jmls: why not? |
| 18:31.42 | jmls | in the child Set(SHARE(foo,ParentChannel)=bar) |
| 18:32.35 | atis_work | jmls: in that case, creating another child channel by parent, those variables wouldn't be there |
| 18:32.52 | Corydon76-vcch | jmls: I'd just let the datastore be inherited on the whole |
| 18:33.00 | jmls | Corydon76-dig: cool. |
| 18:33.07 | jmls | that's another problem solved ;) |
| 18:33.10 | Corydon76-vcch | We already have a method for datastore inheritance |
| 18:33.16 | atis_work | nice :) |
| 18:33.40 | jmls | atis_work: see, ask and thy shall receive ;) |
| 18:34.30 | jmls | mmmm. Corydon76-vcch: can a datastore be attached to anything but a channel > |
| 18:34.31 | jmls | ? |
| 18:34.33 | Corydon76-vcch | shalt |
| 18:34.38 | jmls | dammit |
| 18:34.48 | Corydon76-vcch | jmls: no it cannot |
| 18:34.52 | jmls | shame |
| 18:35.00 | Corydon76-vcch | And actually, it should be "thou" |
| 18:35.14 | Corydon76-vcch | "thy" is possessive |
| 18:35.37 | jmls | eek |
| 18:35.49 | jmls | if you could have a datastore on a group you could have a private storage area for a group of channels |
| 18:36.02 | jmls | like GROUP_COUNT |
| 18:36.26 | jmls | sorry, GROUP_SHARED() |
| 18:36.27 | jmls | heh |
| 18:36.54 | Corydon76-vcch | Tell me what happens if you set a group variable, then change your group? |
| 18:37.08 | jmls | no, not as in the groups we have now |
| 18:37.23 | jmls | instead of a channel, use a GroupName |
| 18:37.50 | jmls | Set(SHAREVAR(SomeGroup,foo)=bar) |
| 18:38.05 | Corydon76-vcch | Then you use a prefixed global variable |
| 18:38.14 | jmls | yeah, suppose :( |
| 18:38.16 | Corydon76-vcch | Because a group never goes away |
| 18:38.35 | jmls | neither does the global variable |
| 18:38.45 | Corydon76-vcch | Birds of a Feather |
| 18:38.55 | Corydon76-vcch | So we already have that |
| 18:39.04 | jmls | true, true |
| 18:41.22 | _eric | SuperCampaignProcessor? That sounds like an AGI for push-polling |
| 18:41.42 | jmls | posh word for powerdialler |
| 18:41.52 | jmls | they think I'm smart around here ;) |
| 18:43.12 | jameswf | I thought it was another ron paul fad |
| 18:43.27 | Corydon76-vcch | jmls: It's due to your British accent |
| 18:44.18 | jmls | "around here" meant my workplace, not asterisk-dev |
| 18:46.15 | _eric | heh |
| 18:52.30 | jmls_gone | gotta go home |
| 18:52.40 | jmls_gone | be back online soon(ish) |
| 18:52.43 | jmls_gone | ttfn |
| 18:56.46 | lmadsen | bkruse: LOCAL() I believe is what you want |
| 18:57.18 | bkruse | lmadsen: I believe I figured a way around it by referencing a channel variable in a macro |
| 18:57.21 | bkruse | thanks though :] |
| 18:57.36 | lmadsen | cool |
| 18:57.40 | lmadsen | Set(LOCAL(foo)=val) |
| 18:58.03 | lmadsen | I *think* you have to use Verbose(1,${LOCAL(foo)}) syntax to get back to it... but I've not used LOCAL() very much |
| 19:07.23 | bkruse | lmadsen: perfect, thank you thank you :] |
| 19:18.49 | mvanbaak | heya all |
| 19:19.13 | ZaVoid | Jared you there? |
| 19:23.29 | ZaVoid | does anyone know if in iax2 if i can specify a different port for the RTP? or is iax2 basically designed from the groundup to be REQUIRED to use the same port as signaling? |
| 19:24.03 | RoyK | ZaVoid: iax2 doesn't use rtp |
| 19:24.11 | ZaVoid | sorry the media i mean |
| 19:24.17 | ZaVoid | i knew it didn't use rtp |
| 19:24.19 | RoyK | I don't think so |
| 19:24.44 | mvanbaak | ZaVoid: it's all using the same port |
| 19:24.55 | mvanbaak | that's how it's designed |
| 19:25.08 | mvanbaak | and that's why it's so damn nice when going through nat etc |
| 19:26.30 | ZaVoid | right so theres no way to peel the media off at all |
| 19:26.41 | ZaVoid | or at least without bridging the calls i guess |
| 19:27.42 | ZaVoid | could i keep it on the same port and route the media through a different IP(media gw) |
| 19:40.59 | kpfleming | no |
| 19:42.39 | mvanbaak | nope |
| 19:42.52 | mvanbaak | it's all in the same packets |
| 19:43.00 | mvanbaak | signalling and audio |
| 19:44.11 | ZaVoid | ok |
| 19:44.23 | ZaVoid | so i guess asterisk treats it as 2 call legs and bridges it internally? |
| 19:46.16 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:50.18 | mvanbaak | that,.... I dont know |
| 19:50.26 | kpfleming | yes, that's the way asterisk treats everything |
| 19:50.43 | mvanbaak | kevin: had a good trip ? |
| 19:50.44 | kpfleming | although with 1.4 it is possible to push away the media if the call is two IAX2<->IAX2 legs |
| 19:50.48 | kpfleming | mvanbaak: yes, but very tired |
| 19:51.15 | mvanbaak | :) |
| 19:51.22 | RoyK | is the new jitterbuffer/plc code usable for iax yet? |
| 19:51.29 | mvanbaak | yup |
| 19:52.06 | mvanbaak | russellb: lmadsen and me did finish the cli-audit stuff :) |
| 19:52.28 | russellb | mvanbaak: great! |
| 19:52.33 | lmadsen | it's true! |
| 19:52.36 | lmadsen | I think it should get merged :) |
| 19:52.49 | russellb | ok, i'll add it to my page long todo list |
| 19:52.56 | lmadsen | w00t |
| 19:53.02 | lmadsen | russellb: is it done yet? |
| 19:53.05 | mvanbaak | lol |
| 19:53.10 | mvanbaak | hurray |
| 19:53.16 | mvanbaak | next |
| 19:53.33 | mvanbaak | fix app_alarmreceiver.c |
| 19:53.35 | mvanbaak | it's a mess |
| 19:53.37 | russellb | o.O |
| 19:53.53 | russellb | formatting? |
| 19:53.57 | mvanbaak | whole functions indented with spaces |
| 19:54.00 | russellb | ah. |
| 19:54.08 | *** join/#asterisk-dev agx (n=badpengu@81-174-45-198.dynamic.ngi.it) |
| 19:54.10 | mvanbaak | not following code guidelines at all |
| 19:54.14 | russellb | heh |
| 19:54.19 | mvanbaak | if(bla) |
| 19:54.20 | mvanbaak | { |
| 19:54.22 | mvanbaak | } |
| 19:54.27 | mvanbaak | and that with 1 statement |
| 19:54.29 | russellb | do you want trunk access for that? |
| 19:54.30 | mvanbaak | stuff like that |
| 19:54.39 | russellb | like i said, i don't mind, as long as you check diff -w :) |
| 19:54.43 | mvanbaak | if it's ok with you guys |
| 19:54.48 | mvanbaak | like I said |
| 19:54.58 | mvanbaak | I never work on 2 issues in the same checkout |
| 19:55.22 | russellb | yeah, it's fine, we know you pretty well at this point ... just don't commit anything that you're not absolutely comfortable with |
| 19:55.27 | mvanbaak | svn co ..... whitespacefixes |
| 19:55.32 | mvanbaak | I wont |
| 19:55.34 | russellb | and be really careful with formatting cleanups to not change code |
| 19:55.54 | mvanbaak | I'm not that good that I'll change actual code besides formatting fixes |
| 19:56.07 | russellb | heh |
| 19:56.14 | file | and respect licensing of course... |
| 19:56.17 | mvanbaak | <--- feels overrated already with the branch and repotools commit access |
| 19:56.27 | mvanbaak | file: no, all my code will be BSD ;) |
| 19:56.40 | russellb | right, you have to know the licensing rules |
| 19:56.44 | russellb | that's absolutely critical |
| 19:57.01 | mvanbaak | explain |
| 19:57.10 | mvanbaak | my wife is watching $random_boring_tvshow |
| 19:57.17 | mvanbaak | so I have all evening here |
| 19:57.56 | russellb | mvanbaak: the code you commit has to be yours, or it has to go through the bug tracker so licensing gets verified |
| 19:58.01 | russellb | that's the short version |
| 19:58.12 | mvanbaak | ah, that licensing rules |
| 19:58.13 | russellb | as we have to ensure that all code is properly licensed to us |
| 19:58.16 | russellb | right |
| 19:58.20 | mvanbaak | yeah, I'm acting all on my own here |
| 19:58.23 | file | a tainted codebase is a sad codebase |
| 19:58.35 | mvanbaak | file: tell me about it |
| 19:58.40 | mvanbaak | been there once |
| 19:58.40 | russellb | ok, so on that note, you have trunk/1.4 commit access now, too |
| 19:58.47 | russellb | with great power comes great responsibility! |
| 19:59.21 | mvanbaak | breath in, breath out |
| 19:59.47 | file | and don't let the fact that every commit you do goes to thousands of peoples email freak you out or anything |
| 20:00.42 | mvanbaak | :) |
| 20:00.53 | mvanbaak | like yours "I broke trunk so shoot me" |
| 20:01.08 | file | we catch trunk breakage within a minute or so now |
| 20:01.15 | mvanbaak | yeah |
| 20:01.21 | mvanbaak | the buildbot integration is nice |
| 20:02.09 | mvanbaak | I'll ask before I commit anything that's outside the stuff I'm working on after discussion here |
| 20:02.09 | russellb | k :) |
| 20:02.09 | mvanbaak | like now. doing the whitespace and {} fixes |
| 20:02.09 | russellb | i'm not worried ... you're here all the time :) |
| 20:02.10 | mvanbaak | but that's it |
| 20:02.13 | russellb | that's fine |
| 20:02.29 | mvanbaak | if I want to commit anything else I'll post to the bugtracker first and ask for feedback |
| 20:02.36 | russellb | k |
| 20:02.59 | mvanbaak | thanks a lot for your confidence. It makes my day |
| 20:03.52 | mvanbaak | *munch* *munch* yummee |
| 20:04.09 | jameswf | mvanbaak: botsnack |
| 20:04.10 | jameswf | :) |
| 20:04.19 | mvanbaak | hhmm, need to make gpg silent |
| 20:04.43 | mvanbaak | all them "encrypted for mvanbaak...." "need key to decrypt" messages are annoying ;) |
| 20:09.34 | russellb | mvanbaak: you're welcome ... you're pretty hardcore. i think you're here more than i am |
| 20:09.49 | Qwell | soooo, russellb |
| 20:10.03 | russellb | yes? |
| 20:10.16 | Qwell | I think it would make more sense to merge this branch, and then do the Makefile changes we talked about afterwards - since those will affect multiple repos |
| 20:10.35 | ZaVoid | kpfleming: what do you mean " although with 1.4 it is possible to push away the media if the call is two IAX2<->IAX2 legs" push away? |
| 20:11.08 | russellb | Qwell: that's fine |
| 20:11.21 | russellb | ZaVoid: media only, kind of like SIP |
| 20:11.31 | russellb | media between endpoints, signaling still through asterisk |
| 20:11.57 | ZaVoid | ahh because normally IAX2 media is direct through proxies you mean? |
| 20:12.07 | russellb | right |
| 20:12.16 | ZaVoid | ok so in theory it is possible |
| 20:12.29 | Qwell | hmm, I don't suppose any of you use chan_ooh323? |
| 20:12.45 | ZaVoid | i tried it a few times Qwell |
| 20:13.00 | Qwell | I have no idea if this module still actually works. it loads, but that's the extent of my testing |
| 20:13.23 | ZaVoid | i never had much luck with it to be honest... always got h323 errors with my vendors so i junked it |
| 20:14.38 | ZaVoid | i thought it was kinda DOA as far as updating and such |
| 20:15.16 | mvanbaak | on my and lmadsen's vote: 8925 can be merged as well |
| 20:16.05 | mvanbaak | Qwell: there are loads of issues with h323 and friends |
| 20:16.15 | mvanbaak | bugtracker has a bunch of them |
| 20:16.18 | Qwell | mvanbaak: yes, I know - but those are unrelated to this :p |
| 20:16.25 | mvanbaak | uhhuh |
| 20:16.26 | mvanbaak | :) |
| 20:16.28 | Qwell | I'd like to not break it *more* (actually, I'd love to, but...whatever) |
| 20:17.26 | mvanbaak | I can merge it myself, but that's just too much for me now |
| 20:17.46 | ZaVoid | break it qwell :) |
| 20:18.36 | ZaVoid | so how would the media in iax2 to iax2 be pushed away? iax.cfg? |
| 20:19.12 | mvanbaak | echo -e "void init_ooh323() {\n\treturn;\n}" > chan_ooh323.c |
| 20:19.33 | mvanbaak | that will unbreak it |
| 20:19.34 | Qwell | init? |
| 20:19.40 | Qwell | #error NO, DON'T DO THAT |
| 20:19.44 | mvanbaak | lol |
| 20:20.38 | mvanbaak | if (events_received == 0) |
| 20:20.38 | mvanbaak | /* Hangup with no events received should be logged in the DB */ |
| 20:20.38 | mvanbaak | database_increment("no-events-received"); |
| 20:20.38 | mvanbaak | else{ |
| 20:20.42 | mvanbaak | erm....... |
| 20:21.02 | mvanbaak | I wonder if this module is actually used |
| 20:21.04 | Qwell | somebody wanna do me a favor? https://origsvn.digium.com/svn/asterisk-addons/team/qwell/moddirmagic |
| 20:21.13 | Qwell | see if that builds/installs/loads? |
| 20:23.14 | mvanbaak | make running |
| 20:24.03 | mvanbaak | meh, I like the cli warning of chan_ooh323 |
| 20:24.08 | mvanbaak | --- This module is currently unsupported. Use it at your own risk. |
| 20:24.12 | Qwell | heh |
| 20:24.29 | Qwell | ooh323c/src/ooSocket.c:341: warning: passing argument 3 of ‘accept’ from incompatible pointer type |
| 20:24.33 | Qwell | that was there - I didn't add that. |
| 20:25.18 | mvanbaak | it compiles/loads fine on ubuntu 7.10 amd64 with ./configure --enable-dev-mode |
| 20:25.23 | mvanbaak | obsd is booting now |
| 20:26.20 | mvanbaak | congrats on 1.4.18 |
| 20:29.32 | mvanbaak | compiles and loads there as well |
| 20:29.50 | Qwell | modules load with asterisk trunk? |
| 20:31.43 | *** join/#asterisk-dev RoyKa (n=roy@ip-77-15-149-91.dialup.ice.no) |
| 20:31.53 | *** part/#asterisk-dev agx (n=badpengu@81-174-45-198.dynamic.ngi.it) |
| 20:35.38 | mvanbaak | uhhuh |
| 20:35.46 | mvanbaak | cli-command-audit version even |
| 20:36.08 | russellb | Qwell: want to review and merge the CLI audit branch? |
| 20:36.11 | russellb | that would rock ;) |
| 20:36.34 | mvanbaak | indeed |
| 20:36.39 | russellb | doesn't have to be this minute, but over the next couple days |
| 20:36.52 | mvanbaak | s/days/seconds/ |
| 20:36.54 | mvanbaak | ;) |
| 20:36.57 | mvanbaak | ok |
| 20:37.08 | mvanbaak | here it goes |
| 20:37.17 | mvanbaak | first commit to trunk |
| 20:38.27 | russellb | STOOOOOOP!!!! |
| 20:38.34 | mvanbaak | ^c |
| 20:38.37 | mvanbaak | eh ? |
| 20:38.46 | russellb | kidding |
| 20:38.54 | mvanbaak | gggrrrr |
| 20:39.03 | mvanbaak | svn commit -F svn-commit.tmp |
| 20:39.10 | file | russellb: eeeeeeeeeeeeeeevil |
| 20:39.33 | mvanbaak | yup |
| 20:39.59 | mvanbaak | let me apply $random_patch from bugs.digium.com and commit it |
| 20:40.04 | mvanbaak | without test compile ;) |
| 20:40.19 | mvanbaak | ugh |
| 20:40.25 | mvanbaak | connection closed |
| 20:44.10 | mvanbaak | hurray ! |
| 20:45.57 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 20:57.43 | *** part/#asterisk-dev RoyKa (n=roy@ip-77-15-149-91.dialup.ice.no) |
| 21:05.00 | *** join/#asterisk-dev bkruse (n=bkruse@216.207.245.1) |
| 21:05.00 | *** mode/#asterisk-dev [+o bkruse] by ChanServ |
| 21:12.24 | russellb | valgrind just saved the day again |
| 21:12.25 | russellb | <3 |
| 21:15.38 | *** join/#asterisk-dev osas (n=nnnnnnnn@nslu2-linux/osas) |
| 21:21.56 | mvanbaak | <--- happy and committing |
| 21:27.13 | Bourrelle | ciao ! :D |
| 21:29.14 | *** join/#asterisk-dev kpfleming (n=kpflemin@216.207.245.1) |
| 21:29.14 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 21:29.31 | mvanbaak | wb kevin |
| 21:37.11 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 21:46.41 | *** join/#asterisk-dev atis_work (n=atis_wor@81.198.164.2) |
| 22:25.19 | jpeeler | has anybody seen open() create a file with random file permissions before? |
| 22:28.07 | russellb | jpeeler: yes |
| 22:28.16 | russellb | if you don't specify permissions, it will be random |
| 22:28.19 | jpeeler | i did though |
| 22:28.37 | russellb | show me the line you used |
| 22:28.45 | jpeeler | ok |
| 22:28.49 | tzafrir | jpeeler, what's the umask? |
| 22:29.25 | jpeeler | no i didn't |
| 22:29.29 | jpeeler | i thought this would work |
| 22:29.31 | jpeeler | fd = open("test.txt", O_CREAT | O_EXCL | S_IRUSR | S_IWUSR | S_IROTH); |
| 22:29.39 | russellb | you didn't specify permissions |
| 22:29.44 | russellb | 3rd arg to open |
| 22:30.16 | russellb | you put the flags in the wrong place |
| 22:30.50 | russellb | heh, no problem |
| 22:31.04 | russellb | why not creat(), didn't want it to truncate? |
| 22:31.08 | russellb | guess that makes sense |
| 22:31.16 | jpeeler | yep exactly |
| 22:31.20 | jpeeler | that ok? |
| 22:31.26 | russellb | yes, that's a good idea |
| 22:34.01 | jpeeler | tzafrir, i never think of things in terms of umask... it's 7-bit complemented right? |
| 22:34.40 | russellb | jpeeler: you don't need to mess with the umask in the code |
| 22:34.56 | russellb | but if it was set weird on your system, it could have caused an issue |
| 22:35.00 | jpeeler | i know |
| 22:35.28 | Qwell | new versions of libc will yell at you about the above open() call, actually |
| 22:35.47 | Qwell | it's required that if you use O_CREAT, you specify perms. it'll fail the build now |
| 22:35.59 | russellb | nice |
| 22:54.45 | jpeeler | so how much more overhead is there in using a file stream vs a file descriptor? |
| 22:56.43 | russellb | not that much i guess |
| 22:56.47 | russellb | it's just not necessary |
| 22:57.17 | jpeeler | i was just curious |
| 22:57.54 | paravoid | russellb: like the new release process |
| 22:57.57 | paravoid | with the RCs et al |
| 22:58.27 | russellb | hm? |
| 22:58.33 | paravoid | I like it :) |
| 22:58.39 | russellb | oh, cool :) |
| 22:59.04 | paravoid | fewer bugs, that can only be a good thing :) |
| 22:59.16 | paravoid | it's so kernel-ish too |
| 23:00.57 | paravoid | what's the difference between chan_gtalk and jingle? |
| 23:02.53 | jpeeler | \brief Gtalk Channel Driver, until google/libjingle works with jingle spec |
| 23:02.58 | jpeeler | from chan_gtalk |
| 23:03.06 | paravoid | ah, silly me |
| 23:03.10 | jpeeler | did google not deploy according to spec? |
| 23:03.13 | jpeeler | no i'm just guessing |
| 23:03.34 | jpeeler | but i think it's a good one :) |
| 23:03.44 | paravoid | well, actually Google created the whole protocol |
| 23:03.46 | Qwell | jpeeler: they didn't |
| 23:03.53 | paravoid | but probably the XMPP foundation changed it along the way |
| 23:03.56 | Qwell | I believe they are much closer now |
| 23:04.08 | jpeeler | so they are moving towards compliance |
| 23:04.18 | jpeeler | any reason as to why they didn't in the first place? |
| 23:04.21 | Qwell | they may be all the way there by now |
| 23:04.33 | paravoid | jpeeler: you can't be compliant to something that doesn't exist |
| 23:04.43 | paravoid | iirc, Jingle didn't exist before Google Talk |
| 23:05.06 | jpeeler | heh, if you write the spec along with the protocol i don't see why not |
| 23:07.01 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 23:07.01 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 23:08.41 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.pa.comcast.net) |
| 23:47.41 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 23:47.50 | *** part/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 23:52.45 | lmadsen | I'm trying to debug a connection to the database when I do a dial, and I get an error that says, "varchar cannot be converted to bigint", however I want to see what the SQL statement that is being executed is (then I can find the offending column). I'm looking at around line 103 of res_odbc and I there is a call to prepare_cb that has the values obj, and data, but in the function the argument is void *data.... how can |
| 23:52.45 | lmadsen | I see what the value of data is? |