| 00:24.00 | *** join/#asterisk-dev _charly_ (i=kroseneg@sunrise.schmidham.net) |
| 00:24.29 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.pa.comcast.net) |
| 00:26.38 | *** join/#asterisk-dev troy42 (i=troy@z.paranode.com) |
| 00:32.32 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) [NETSPLIT VICTIM] |
| 00:32.32 | *** join/#asterisk-dev qdk (n=qdk@0x573fe57e.bynqu2.broadband.tele.dk) [NETSPLIT VICTIM] |
| 00:32.32 | *** join/#asterisk-dev JonMcN (n=Jon@cpc4-sout2-0-0-cust715.sotn.cable.ntl.com) [NETSPLIT VICTIM] |
| 00:32.32 | *** join/#asterisk-dev wedhorn (n=nwedhorn@dsl-58-6-89-11.act.westnet.com.au) [NETSPLIT VICTIM] |
| 00:32.48 | *** join/#asterisk-dev troy42 (i=troy@z.paranode.com) |
| 00:38.56 | *** join/#asterisk-dev bmd (n=bmd@wsip-70-183-82-162.sd.sd.cox.net) |
| 00:38.56 | *** mode/#asterisk-dev [+o bmd] by ChanServ |
| 00:39.26 | *** part/#asterisk-dev bmd (n=bmd@wsip-70-183-82-162.sd.sd.cox.net) |
| 00:39.32 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 00:39.32 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 00:52.49 | *** join/#asterisk-dev outtolunc (n=me@c-67-174-216-60.hsd1.ca.comcast.net) |
| 01:25.54 | snuff-work | Corydon76-dig: might want to merge that fix to trunk not just 1.4 |
| 02:11.09 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.pa.comcast.net) |
| 02:17.12 | *** join/#asterisk-dev miguel3239 (n=elguerom@ns1.nashuacs.com) |
| 02:43.50 | *** join/#asterisk-dev RoyK (n=roy@ip-2-29-149-91.dialup.ice.no) |
| 02:44.36 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 02:48.08 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.ct.comcast.net) |
| 02:49.36 | *** part/#asterisk-dev RoyK (n=roy@ip-2-29-149-91.dialup.ice.no) |
| 02:55.25 | Corydon76-dig | snuff-work: you're too impatient |
| 03:29.11 | *** join/#asterisk-dev putnopvut (n=putnopvu@user-24-214-112-81.knology.net) |
| 03:29.11 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 03:31.12 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.ct.comcast.net) |
| 03:52.23 | snuff-work | ah i try not to be |
| 03:52.52 | snuff-work | 1st look i thought it was committed to both that was all.. |
| 03:57.16 | *** join/#asterisk-dev RoyK (n=roy@ip-2-29-149-91.dialup.ice.no) |
| 03:59.25 | *** part/#asterisk-dev RoyK (n=roy@ip-2-29-149-91.dialup.ice.no) |
| 04:07.01 | snuff-work | compilation success |
| 04:07.03 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.ct.comcast.net) |
| 04:41.20 | *** join/#asterisk-dev CunningPike (n=CunningP@S010600095b33697f.vc.shawcable.net) |
| 04:49.23 | *** join/#asterisk-dev jameswf-home (n=james@ip72-204-221-181.ph.ph.cox.net) |
| 05:54.37 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 05:54.37 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 06:21.18 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 06:21.18 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:01.57 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 07:32.18 | *** join/#asterisk-dev oej (n=olle@gw-sthlm01.rebtel.com) |
| 07:32.18 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:06.35 | *** join/#asterisk-dev nebojsajsimic (n=nebojsaj@cable-89-216-16-106.static.sbb.co.yu) |
| 08:18.08 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-159.bredband.comhem.se) |
| 08:26.26 | *** join/#asterisk-dev oej (n=olle@gw-sthlm01.rebtel.com) |
| 08:26.26 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:28.05 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 08:33.14 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@62.90.10.53) |
| 08:33.14 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:47.53 | *** join/#asterisk-dev _ys (n=yuri@80.70.236.69) |
| 08:56.56 | oej | morning |
| 09:05.41 | _ys | hello |
| 09:12.29 | *** join/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 09:12.30 | sergee | aloha |
| 09:13.34 | tzafrir | (Asterisk uses the magical -O6) |
| 09:15.58 | tzafrir | I suspect that if -O will be disabled (from the default) we'll start to see premature optimizations in the C code that will make it even less readable |
| 09:16.23 | tzafrir | e.g: deep preprocessor magic |
| 09:17.38 | atis_work | tzafrir: what's the deal about backtraces? i read that they can be obtained anyway.. so why then it's required to enable DONT_OPTIMIZE? |
| 09:18.11 | tzafrir | The thing is that some of the compiler optimizations make the code not as it is written |
| 09:18.34 | tzafrir | you tell the compiler to do one thing, and the compiler finds a more efficient way to do that |
| 09:19.12 | tzafrir | loop unrolling, inlining (or not) of functions, and other stuff |
| 09:19.25 | _ys | file: why you resent auth request in chan_sip.c in case, if wrong digest responce received from peer (trunk rev 102452)? |
| 09:19.36 | tzafrir | Compilers are pretty smart with the code that they generate |
| 09:20.15 | tzafrir | Therefore sometimes the list of functions in the backtrace is not the same as the one in the code |
| 09:20.28 | _ys | in case, if both digest responce and nonce is wrong |
| 09:22.27 | oej | _ys: THat's how you tell the other side that they're wrong. |
| 09:26.36 | atis_work | hmm, then DONT_OPTIMIZE isn't actually needed unless compiler optimization is suspected? |
| 09:27.07 | atis_work | i would actually like some way how to obtain backtraces without enabling DONT_OPTIMIZE |
| 09:27.24 | atis_work | btw, afaik -O2 is considered safe, but -O3 not anymore |
| 09:28.17 | atis_work | so, i think by default it should go with -O2.. that shouldn't break anything.. optionally -O3 could be allowed by some menuselect option |
| 09:28.36 | atis_work | and then an option for debug symbols would be desirable |
| 09:32.00 | atis_work | tzafrir: what's the -O now without DONT_OPTIMIZE? |
| 09:32.22 | tzafrir | atis_work, check Makefile.rules |
| 09:33.02 | atis_work | huh, really -O6 :p |
| 09:33.08 | atis_work | never heard of it |
| 09:33.54 | tzafrir | Though I believe a number of package builders replace the -O6 there with -O2 |
| 09:34.03 | tzafrir | At least in Debian it is that way, IIRC |
| 09:35.36 | tzafrir | So far I have not managed to get a clear answer to what the -O6 is |
| 09:35.45 | atis_work | i wonder what does -O6 does.. can't find it anywhere |
| 09:36.23 | mvanbaak | it breaks the gsm codec with gcc 4.2 |
| 09:36.25 | atis_work | well, -O2 is generally considered as "safe" optimization.. |
| 09:36.44 | atis_work | mvanbaak: so, gsm would work with -O2 and gcc 4.2? |
| 09:37.03 | mvanbaak | no idea, I only tried with normal build and with DONT_OPTIMIZE |
| 09:37.17 | mvanbaak | normal build == bad audio quality |
| 09:37.36 | tzafrir | There was a success story with -O2 |
| 09:37.37 | mvanbaak | DONT_OPTIMIZE == good audio quality (well, good as in gsm format good) |
| 09:37.59 | oej | That's really bad |
| 09:38.23 | mvanbaak | gcc 4.1 does not have that problem |
| 09:38.41 | tzafrir | well, -O6 is not a documented gcc feature |
| 09:38.50 | mvanbaak | indeed |
| 09:39.06 | atis_work | it's not only undocumented, but it's purpose is well hidden |
| 09:39.51 | tzafrir | I thik anything beyond 3 is supposed to be equivalent of 3. Hopefully |
| 09:39.56 | mvanbaak | no |
| 09:39.58 | tzafrir | Never dug into the gcc code |
| 09:40.16 | mvanbaak | anything beyond 3 is 'more invasive and more aggressive' |
| 09:40.42 | _ys | oej: If auth fail? How about comment in chan_sip: (Tell the UAS not to re-send this authentication data, because it will continue to fail) |
| 09:40.59 | oej | good thinking |
| 09:41.34 | oej | many UAS doesn't understand, that's why I added the 403 forbidden to make them quiet. That's non-standard, but devices with bad passwords stopped hammering my asterisk |
| 09:46.06 | _ys | oej: May be at first check Digest, and if wrong - send 403 in all case? |
| 09:49.42 | oej | I haven't checked file's changes, but we used to do that |
| 09:50.30 | mvanbaak | oej: i changed 'agi dumphtml' into 'agi dump html' |
| 09:50.35 | mvanbaak | thanks for spotting that one |
| 09:52.34 | mvanbaak | hhmm |
| 09:58.16 | sergee | have anybody seen serge-v or PCadach recently? |
| 10:05.23 | mvanbaak | not me |
| 10:18.32 | sergee | !seen PCadach |
| 10:18.35 | sergee | ~seen PCadach |
| 10:18.37 | jbot | pcadach <~paul@www.east.telecom.kz> was last seen on IRC in channel #asterisk, 1000d 20h 9m 9s ago, saying: 'JerJer: Please, check #4164. Also, check #4185 and #4194 - the ones is first part of split of dead3 from #3967.'. |
| 10:19.23 | sergee | 1000 days - anniversary |
| 10:27.15 | mvanbaak | yeah |
| 10:27.25 | mvanbaak | and tickets in the 4000 range |
| 10:41.00 | sergee | ~seen vechers |
| 10:41.01 | jbot | vechers <n=103326C9@64.61.117.138> was last seen on IRC in channel #asterisk, 629d 15h 48m 6s ago, saying: 'djacob-wcgs: Vonage perhaps?'. |
| 10:41.07 | sergee | ~seen serge-v |
| 10:41.08 | jbot | i haven't seen 'serge-v', sergee |
| 10:58.41 | *** join/#asterisk-dev Sajjad_Ali_Musht (n=Sajjad_A@octroi.enst-bretagne.fr) |
| 11:07.03 | *** join/#asterisk-dev _ys (i=yuri@91.151.196.254) |
| 11:23.43 | *** join/#asterisk-dev RoyK (n=roy@fw.fortel.no) |
| 11:37.05 | sergee | ~seen sergey-v |
| 11:37.09 | jbot | sergee: i haven't seen 'sergey-v' |
| 11:37.26 | sergee | jbot: you are blind |
| 11:37.26 | jbot | sergee: what are you talking about? |
| 11:39.31 | tzafrir | ~seen sergee-v |
| 11:39.32 | jbot | i haven't seen 'sergee-v', tzafrir |
| 11:45.08 | *** join/#asterisk-dev qdk (n=qdk@193.164.155.7) |
| 11:53.26 | *** join/#asterisk-dev ctooley (n=ctooley@doc-72-47-33-80.maryville.mo.cebridge.net) |
| 12:04.17 | tzanger | tzafrir: ping |
| 13:05.10 | *** join/#asterisk-dev ZaVoid (n=zavoid@66-95-182-90.client.dsl.net) |
| 13:08.05 | ZaVoid | <PROTECTED> |
| 13:43.50 | *** join/#asterisk-dev _ys (i=yuri@91.151.196.254) |
| 14:07.49 | *** join/#asterisk-dev Greek-Boy (n=grb@41.221.58.4) |
| 14:20.20 | *** join/#asterisk-dev JunK-Y (n=junky@modemcable183.17-83-70.mc.videotron.ca) |
| 14:32.27 | sergee | my asterisk ends with code 155 after a compiled it with -pg, seems it doesn't like SIGPROF, however sigprof reaction doesn't explicitly defined in source |
| 14:33.08 | sergee | as far as i understand, if dignal's reaction is not defined - it should be ignored, am i wrong? |
| 14:38.44 | _ys | sergee: SIGPROF terminate process profiling timer alarm |
| 14:39.02 | _ys | this is default sigaction |
| 14:39.24 | file | _ys: if you had the same packet come in at virtually the same time the first would create a new nonce and a 401 would get sent back, the second (even though it was the same packet as the first cseq wise) would also create a new nonce, which means the first 401's nonce would be invalid |
| 14:41.01 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 14:41.01 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:41.41 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:41.41 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 14:48.07 | _ys | file: why not, at first check the Digest (w/received nonce) and afterward, if it correct, check the nonce, noncecount etc... |
| 14:48.52 | _ys | if DIgest basicaly incorrect - send 403 and forgot :) |
| 14:48.59 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 14:48.59 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 14:50.06 | file | it's not like my code actually changed it for all scenarios... only for the case of retransmitted packets |
| 14:50.12 | file | the old logic still applies in every other case |
| 14:54.17 | *** join/#asterisk-dev _gm (n=mustafa@58.27.175.222) |
| 14:54.59 | _gm | is ldap driver with 1.6beta working? it was working fine with my 1.4 install |
| 14:55.08 | _ys | file: Hmm. In this case, potentially, someone can emulate duplicate request and try to find the password (nonce unchanged)? |
| 14:55.10 | _gm | dont know why its not working with 1.6b |
| 14:55.13 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 14:55.13 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:56.00 | file | oej: what did YOU think of the change? |
| 14:56.10 | oej | What change? |
| 14:56.26 | oej | Afternoon, file :-) |
| 14:56.29 | file | oej: not changing the nonce on retransmitted inbound REGISTERs |
| 14:56.35 | file | and hi! |
| 14:57.17 | oej | I need to check it, but if that's what you did then you follow the RFC. Retransmits need exactly the same answer as the original transmit. |
| 14:57.30 | file | that is what I thought |
| 14:57.36 | oej | If it's a new request (call-id, cseq) then we need a new nonce |
| 14:57.57 | oej | But that's really according to policy. We can implement a policy saying that a nonce is valid for 23 hours and 42 minutes if we want. |
| 14:58.08 | oej | Security-wise, that's not really a good thing though. |
| 14:58.09 | file | well this gives it a chance to actually work |
| 14:58.33 | oej | yes, because if you answer with a different nonce on the retransmit, and the device responds to the first answer, you're screwed. |
| 14:58.44 | file | yeah exactly... which was happening |
| 14:58.57 | oej | Ok then, then you did exactly the right thing. |
| 14:59.02 | oej | Over to RTP as next topic. |
| 14:59.13 | file | they both already contained an Auth header, the first created a new nonce and sent back a 401... the second created another new 401 and sent back a 401 |
| 14:59.22 | file | first REGISTER came with first nonce, failed out as stale |
| 14:59.30 | file | and it went down hill from there.... |
| 14:59.56 | oej | Oh yeah. That's an interesting scenario. |
| 15:00.02 | oej | Did you prevent the same from happening on INVITE's |
| 15:00.16 | oej | We really need to rewrite the whole IGNORE stuff. It's bad, really bad. |
| 15:00.21 | file | I dunno, I still have my test case |
| 15:00.28 | file | I can change it to an INVITE and see what happens |
| 15:00.31 | oej | Ok, next topic |
| 15:00.44 | oej | We have severe problems with DTMF on RTP with *one* service provider |
| 15:01.00 | oej | There's a timestamp problem I need to analyze, but it's been reported for a while in the bug tracker |
| 15:01.15 | oej | Are you aware of this issue, file? |
| 15:01.29 | file | probably, but I did not know it was a timestamp issue |
| 15:02.06 | file | are they a nice provider and are telling you what they are expecting versus what we send? |
| 15:03.31 | oej | I just wanted to know if you had the details or if you wanted me to debug the stuff |
| 15:03.53 | oej | It's one of my customers. I'll be there on friday so I can take wireshark dumps and rtp debug and stuff. |
| 15:04.00 | file | nifty |
| 15:04.07 | file | what codec is it using? |
| 15:04.19 | oej | Obviously there's a skew in the time stamps, so that the duration of the dtmf is clipped down to zero and thus ignored |
| 15:04.38 | oej | I don't really know the codec, G729 or alaw |
| 15:05.15 | oej | I just got it from them today on the list of Asterisk stuff to go through... Been working with zaptel timers since friday morning. |
| 15:05.15 | file | mmmk |
| 15:05.22 | oej | Somethings really bad in zaptel timer land. |
| 15:05.32 | oej | Ahh. Afternoon Simpsons on TV. |
| 15:05.56 | file | alas, I do not know much of that |
| 15:06.18 | oej | Neither did I. |
| 15:06.25 | oej | I'm beyond the point of no return in hardwareland |
| 15:06.43 | file | having a vacation in kernel land? |
| 15:07.03 | oej | I'm just surprised that not using chan_zap running sip calls to playback affects the timer. |
| 15:07.24 | oej | But I suscpect the fastagi - that's something for you to look into |
| 15:07.52 | oej | Fastagi is not using the standard core poll, it's running it's own. Add 200 channels running FastAGI and you have 200 extra poll's running. Can kill any system |
| 15:08.04 | oej | And masquerading a local channel into a SIP channel kills fastagi sessions |
| 15:08.19 | oej | I think we should move fastagi to standard file handles and standard poll |
| 15:09.16 | file | welllllllll when a channel is setup it grabs a file descriptor to the zaptel timer if available |
| 15:09.33 | file | then when it has to play back a file it does some ioctl stuff with the timer to say "wake me up every 20ms" or whatever... |
| 15:10.28 | oej | for all channels? Regardless of tech? |
| 15:11.03 | oej | I wasn't aware of that. |
| 15:11.28 | oej | So a zaptel timer powers all channels in an asterisk if available, and if we have too many channels it starts skewing. |
| 15:11.41 | file | that is why if you have a card in the machine that doesn't generate interrupts until configured playing back of prompts sort of halts |
| 15:11.44 | oej | ztdummy more than others |
| 15:12.23 | oej | say that again - what do you mean with "until configured" |
| 15:12.53 | oej | Isn't RTP clocked on incoming? |
| 15:13.08 | Qwell | if internaltiming=no, right? |
| 15:13.08 | file | the timer is only used for playback of files |
| 15:13.21 | file | or if you have it for that internal timing thing |
| 15:13.36 | file | so bridged traffic wouldn't realllllllly be affected |
| 15:13.44 | Qwell | oej: what kernel version is this? |
| 15:14.00 | file | as for not configured... if I remember correctly if you have a PRI card in the machine and don't ztcfg it |
| 15:14.09 | oej | 2.6 something |
| 15:14.54 | sergee | when i enter in CLI "stop gracefully", system starts sending a lot of SIGURG (23) signals, can anybosy explain me - what does it mean? pleeease? |
| 15:14.55 | oej | We have machines with ztdummy and one with wctdm |
| 15:15.28 | oej | So all playback of files use the zap timer regardless of tech? That's new to me. |
| 15:15.35 | Qwell | oej: I meant more specifically :p |
| 15:15.35 | file | if available. |
| 15:15.52 | oej | Qwell: I'll know more on friday, back home now |
| 15:16.03 | Qwell | oh |
| 15:16.16 | oej | Centos 5 I believe |
| 15:16.23 | file | home is nice... but I wish I could turn down the thermostat |
| 15:16.41 | oej | I wish I could turn up the thermostat - outside |
| 15:16.43 | putnopvut | sergee: SIGURG means urgent data. Asterisk handles SIGURG by ignoring it pretty much. |
| 15:17.12 | oej | putnopvut: Our MGCP expert! Hail the MGCP pro! |
| 15:17.28 | file | oej: careful, you might scare him away |
| 15:17.33 | putnopvut | oej: lol |
| 15:17.55 | putnopvut | Oh, it was an attack? |
| 15:18.09 | jmls | I think that you were being setup ... |
| 15:18.12 | oej | Claiming that anyone is an MGCP expert can be considered harmful |
| 15:18.16 | sergee | putnopvut: thanks |
| 15:18.46 | oej | I thought that was a trick Digium only gave to new employees: Here's some MGCP bugs, fix them! |
| 15:19.01 | oej | s /gave to/played on/ |
| 15:19.44 | jmls | careful ! he might hear you ! |
| 15:20.55 | file | we are sort of evil like that I suppose... |
| 15:21.07 | file | putnopvut: here's some app_voicemail IMAP bugs and app_queue bugs, go fix! |
| 15:25.32 | oej | I thought putnopvut started developing app_voicemail over Webdav now. |
| 15:25.39 | jmls | thank god for that. the noise was deafening ;) |
| 15:37.20 | *** join/#asterisk-dev ManxPower (n=manxpowe@251.sub-70-223-214.myvzw.com) |
| 15:37.37 | *** join/#asterisk-dev sruffell (n=sruffell@216.207.245.1) |
| 15:37.37 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:51.54 | *** join/#asterisk-dev joetester (n=patrick@216.191.34.13) |
| 16:07.54 | *** join/#asterisk-dev RoyK (n=roy@fw.fortel.no) |
| 16:19.35 | *** join/#asterisk-dev qdk (n=qdk@0x573fe57e.bynqu2.broadband.tele.dk) |
| 16:26.04 | *** part/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 16:37.59 | *** join/#asterisk-dev RoyK (n=roy@fw.fortel.no) |
| 16:39.42 | *** join/#asterisk-dev jameswf-home (n=james@dsl093-157-131.phx1.dsl.speakeasy.net) |
| 16:39.53 | *** join/#asterisk-dev ramonpeek (n=ramonpee@e135042.upc-e.chello.nl) |
| 16:42.04 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 16:46.23 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.12.183) |
| 16:59.32 | ramonpeek | I have a patch for a small new feature, but have a question about in which manner it should be applied to SVN. |
| 16:59.32 | ramonpeek | Anyone care to discuss this? |
| 16:59.54 | file | what do you mean? |
| 17:02.20 | *** join/#asterisk-dev hugorebelo (n=hugorebe@200-171-132-124.completo.com.br) |
| 17:02.35 | ramonpeek | @file: Did you notice the private channel I opened to you? |
| 17:02.52 | file | I do not accept private messages from random people |
| 17:03.06 | ramonpeek | OK I'll post it here then.. |
| 17:03.14 | ramonpeek | I wrote a simple new feature for 1.4.17 called 'ExportVar' as the opposite to "ImportVar'. |
| 17:03.14 | ramonpeek | Obviously I like to add to code to the SVN as well, but here ImportVar has been deprecated |
| 17:03.14 | ramonpeek | in favor of Set(varname=${IMPORT(channel,variable)}), which is a good thing ! ;-) |
| 17:03.14 | ramonpeek | But ExportVar is the opposite of ImportVar, so it would be logical to create this feature by |
| 17:03.14 | ramonpeek | using Set(IMPORT(channel,variable)=value). |
| 17:03.15 | ramonpeek | However this is sounding a bit weird |
| 17:03.17 | ramonpeek | Something like Set(CHANVAR(channel,variable)=value) or Set(varname=${CHANVAR(channel,variable)}) |
| 17:03.19 | ramonpeek | would be alot more logical. |
| 17:03.21 | ramonpeek | No my question would be what to do; Create an add beside, replace or remove the IMPORT func? |
| 17:03.43 | JerJer | file: word |
| 17:03.58 | file | JerJer: hrm... I'm gonna guess... muffin? |
| 17:04.04 | JerJer | yup |
| 17:04.12 | file | sweet! do I get a prize? |
| 17:04.40 | JerJer | tell em what he won Johnny.... |
| 17:04.46 | ramonpeek | I bet you would want to win something... a Miffin? |
| 17:04.52 | ramonpeek | or Muffin? |
| 17:04.59 | Qwell | ramonpeek: so, you want to set a channel variable on another channel? |
| 17:05.18 | ramonpeek | Yep... but from the calling channel |
| 17:06.41 | ramonpeek | So whilst in one channel set something like Set(foo=${CHANVAR(${BRIDGEPEER}, bla)}) |
| 17:06.58 | ramonpeek | from the 'h' extension |
| 17:10.27 | ramonpeek | Qwell: Still there? |
| 17:10.41 | Qwell | yeah, I can't think of any way to do that currently |
| 17:11.33 | ramonpeek | @QWell: I did that for a long time too, but couldn't find any ... finally it took me less time creating the feature than searching for a solution |
| 17:11.42 | ramonpeek | ;-) |
| 17:12.16 | Qwell | seems pretty trivial to do in code |
| 17:12.32 | Qwell | I guess the question is what do you call the function? IMPORT doesn't make much sense |
| 17:12.41 | ramonpeek | Indeed... |
| 17:12.55 | Qwell | and if whatever function you've written supports .write (which it would have to), that would make IMPORT useless for .read |
| 17:13.14 | Qwell | or, rather, if it supported .write and .read, which I assume it would |
| 17:13.24 | ramonpeek | That why I said CHANVAR, but that would mean deprecating the IMPORT... (a bit earliy for that?) |
| 17:13.38 | Qwell | ramonpeek: I don't think it's too early. |
| 17:13.55 | Qwell | it was useful for a while - now it won't be any longer. not a big deal IMO |
| 17:14.02 | Qwell | IMPORT is only in trunk, right? |
| 17:14.11 | ramonpeek | yes |
| 17:14.31 | Qwell | anybody have any thoughts on foregoing the deprecation process of IMPORT if something like what ramonpeek is talking about gets added? |
| 17:17.38 | Qwell | ramonpeek: You already have a patch written, right? |
| 17:18.23 | ramonpeek | I have one for 1.4.17, but I'll port it to SVN... already checked out that code, shouldn't be too hard. |
| 17:18.29 | Qwell | svn trunk |
| 17:18.39 | ramonpeek | yep svn trunk |
| 17:18.46 | Qwell | go ahead and create a bug at bugs.digium.com, and upload the patch there |
| 17:18.54 | Qwell | "bug".. feature request, of course |
| 17:19.15 | ramonpeek | OK, do you want me to report the IMPORT func as deprecated or remove it? |
| 17:19.31 | Qwell | neither - yet - that's something we can discuss |
| 17:19.44 | Qwell | just point out that with yours, IMPORT would become useless |
| 17:19.53 | ramonpeek | OK fine too |
| 17:20.01 | ramonpeek | i'll do, that.. |
| 17:20.13 | ramonpeek | First... dinner : Pizza! |
| 17:20.16 | ramonpeek | ;-) |
| 17:30.11 | mvanbaak | Qwell: any idea when russell will be here ? |
| 17:30.47 | Qwell | mvanbaak: he's out today - probably unavailable most of the day |
| 17:37.13 | mvanbaak | ok |
| 17:37.16 | mvanbaak | and kevin ? |
| 17:38.07 | Qwell | same |
| 17:39.07 | mvanbaak | thanks |
| 17:46.35 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 17:56.21 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 17:56.21 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:17.36 | *** join/#asterisk-dev RoyK (n=roy@ip-197-29-149-91.dialup.ice.no) |
| 19:32.36 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 19:32.36 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:34.08 | *** join/#asterisk-dev _ys (n=yuri@80.70.236.69) |
| 19:37.56 | *** join/#asterisk-dev joetester (n=patrick@216.191.34.13) |
| 19:46.01 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:56.56 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 19:56.56 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:29.28 | *** join/#asterisk-dev iulius (n=iulius@mail1.technologieshq.com) |
| 20:46.37 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 20:58.15 | putnopvut | Yeah, it's a regular party channel here today! |
| 20:58.28 | Corydon76-dig | Life of the party is missing |
| 20:58.48 | putnopvut | Who's that? |
| 20:58.58 | Corydon76-dig | The drum killah |
| 20:59.11 | putnopvut | I guess he's traveling right now. |
| 20:59.13 | jpeeler | haha, i thought it killed that name |
| 20:59.16 | jpeeler | *he |
| 20:59.39 | putnopvut | jpeeler: he will always be drumkilla to me. |
| 20:59.53 | jpeeler | good enough :) |
| 21:00.16 | Corydon76-dig | jpeeler: next time he's on, do a /whos russellb |
| 21:00.24 | Corydon76-dig | He hasn't quite killed it yet |
| 21:00.42 | jpeeler | well, then i stand corrected |
| 21:00.58 | Corydon76-dig | or sit |
| 21:01.20 | putnopvut | I should put some sort of device in my office that will allow me to lie at my desk. |
| 21:01.37 | Corydon76-dig | putnopvut: a Roman couch? |
| 21:01.52 | putnopvut | That would do. |
| 21:01.57 | putnopvut | Or a bed. |
| 21:01.58 | Corydon76-dig | Those are rather comfortable |
| 21:02.02 | joetester | He means something that will allow him to lie to you people! |
| 21:02.11 | putnopvut | I already do that :) |
| 21:02.18 | joetester | lol |
| 21:02.25 | joetester | liar |
| 21:02.30 | Corydon76-dig | You might need a projector to put your screen up on the wall so you can still type |
| 21:02.55 | joetester | But how will that help his lying skills? |
| 21:03.47 | Corydon76-dig | If he's lying when he says he lies, does that make him telling the truth? |
| 21:04.01 | joetester | Who knows. |
| 21:04.02 | Corydon76-dig | in which case you have to believe that he lies |
| 21:04.20 | Corydon76-dig | But he can't be lying, so he must be telling the truth |
| 21:04.32 | Corydon76-dig | But if he's telling the truth, then he must be lying. |
| 21:05.25 | mvanbaak | brain overload |
| 21:06.06 | Corydon76-dig | mvanbaak: where's this conference location, again? |
| 21:06.31 | mvanbaak | .nl ? |
| 21:06.38 | Corydon76-dig | Yeah, but where? |
| 21:06.41 | putnopvut | The entire country! |
| 21:06.45 | mvanbaak | indeed |
| 21:06.58 | mvanbaak | it's a 1 hour drive from west to east .nl |
| 21:07.11 | Corydon76-dig | It's small, but it's not quite small to hear from one end to the other |
| 21:07.25 | mvanbaak | it is. we have fiber everywhere |
| 21:07.26 | putnopvut | We could have a cross-country meetme. |
| 21:07.32 | mvanbaak | put some asterisk boxen there and we are set |
| 21:07.48 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 21:07.58 | mvanbaak | but I think kevin had some thing going in philly |
| 21:07.59 | Corydon76-dig | Yeeeeeeeeaaaahhhh |
| 21:08.21 | Corydon76-dig | For this side of the pond, yes |
| 21:08.34 | mvanbaak | then it's philly |
| 21:08.47 | mvanbaak | I have no final location |
| 21:08.47 | putnopvut | Corydon76-dig: does that imply there could be multiple devcons? |
| 21:08.55 | Corydon76-dig | I thought there was the thought to have one on each side of the pond |
| 21:09.01 | mvanbaak | no |
| 21:09.05 | Corydon76-dig | So the the Europeans could attend cheaply |
| 21:09.22 | mvanbaak | idea was to ship all you guys to .nl |
| 21:09.45 | putnopvut | It think we need to quiz Kevin on the current status upon his return to Huntsville. |
| 21:09.51 | Corydon76-dig | Oh, then I can toss this passport application |
| 21:09.52 | mvanbaak | yup |
| 21:10.09 | mvanbaak | but both kevin and russell are on the road |
| 21:10.15 | mvanbaak | so cant ask them right now |
| 21:10.22 | Corydon76-dig | That's what they tell me |
| 21:10.42 | mvanbaak | I talked about it with both of them |
| 21:11.01 | file | Corydon76-dig: you don't have a passport? |
| 21:11.06 | mvanbaak | btw, if someone feels like it, my branch is ready for merge |
| 21:11.07 | putnopvut | Corydon76-dig: you should still apply for the passport. International travel rocks! |
| 21:11.21 | file | yeah... it probably takes a century to get one |
| 21:11.25 | Corydon76-dig | file: correct. I do not. |
| 21:11.43 | mvanbaak | wow, here in .nl you have to have a passport |
| 21:11.48 | mvanbaak | or you are a criminal |
| 21:11.59 | mvanbaak | they can send you to jail for like 6 months for not having one |
| 21:12.05 | mvanbaak | identification law |
| 21:12.20 | Corydon76-dig | Well, see, I'm a criminal. Send me to a pound-me-in-the-ass prison |
| 21:12.32 | mvanbaak | we have lots of them here ;) |
| 21:13.09 | Corydon76-dig | mvanbaak: Americans have long been against a national ID card |
| 21:13.10 | mvanbaak | we have funny laws |
| 21:13.24 | putnopvut | mvanbaak: I like some of them though ;) |
| 21:13.46 | mvanbaak | you go to prison for not having a passport, but they wont do shit when you are eating shrooms, drinking and smoking pot in public |
| 21:13.54 | Corydon76-dig | mvanbaak: many people see it as a way to round up people and put them in camps... I wonder what other country might have done that... |
| 21:14.13 | mvanbaak | Corydon76-dig: zat would be ze germanz ! |
| 21:14.38 | Corydon76-dig | mvanbaak: and nl was a part of Germany for a couple years back then |
| 21:14.59 | mvanbaak | yup, thank god it was restored to it's normal state |
| 21:15.21 | Corydon76-dig | Old habits die hard, apparently |
| 21:17.15 | Corydon76-dig | It appears that the Real ID Act is about to be ignored by a great many branches of the federal government, come May. |
| 21:26.09 | jpeeler | anybody familiar enough with http.c to assist me adding post support? |
| 21:26.28 | jpeeler | as far as i can tell the request is handled the same as get, just with the variables in the header instead |
| 21:26.45 | jpeeler | yeah i know this is kind of vague... |
| 21:27.23 | putnopvut | jpeeler: yeah, my experience with GET vs. POST is just that GET has the variables in the URL and POST has them...somewhere else. |
| 21:27.43 | Qwell | jpeeler: there is limited POST support in trunk |
| 21:27.43 | putnopvut | So in other words, I probably shouldn't be the one to look over that sort of change. |
| 21:27.50 | Qwell | (very limited) |
| 21:27.58 | jpeeler | yeah there is post support for uploading files |
| 21:28.01 | Qwell | right |
| 21:28.53 | jpeeler | just thought it'd see if anybody had it fresh on their mind, the code is complicated, at least to me |
| 21:29.50 | Corydon76-dig | jpeeler: not in the header; in the body |
| 21:30.07 | jpeeler | yeah after the header i meant |
| 21:30.44 | Corydon76-dig | jpeeler: what do you want to do in the POST, exactly? |
| 21:31.44 | jpeeler | have the variables send to the asterisk server and processed, specifically for manager actions |
| 21:32.52 | jpeeler | i can check the content-type to see if the post is a file upload or just a form submission |
| 21:33.28 | Corydon76-dig | Okay, but there are two encoding types that you'll need to process for POST |
| 21:33.31 | jpeeler | i was hoping once i parsed the variables i could just somehow treat it like a get request since as far as i can tell the only difference is where the variables are |
| 21:33.56 | jpeeler | well i assume of them is for file uploads and the other for form submissions |
| 21:34.20 | Corydon76-dig | Well, kind of |
| 21:34.49 | Corydon76-dig | Only one of them can be used for file uploads. But both can be used for form submission |
| 21:35.36 | jpeeler | yeah i think i read that somewhere, so if that's true, how can i tell if it is an upload or form submission? |
| 21:36.06 | Corydon76-dig | Well, if it's that encoding type, then you check the headers of the individual section for a filename. |
| 21:36.33 | Corydon76-dig | Note that you can have a file upload AND fields submitted in the same form |
| 21:37.32 | jpeeler | right but we've already decided to not follow the RFC on that one... |
| 21:37.43 | Corydon76-dig | Heh |
| 21:37.44 | jpeeler | at least that is what i was told |
| 21:37.47 | mvanbaak | whehehehehe |
| 21:38.02 | jpeeler | yeah, maybe one day that can be fixed |
| 21:38.03 | mvanbaak | we should put that line in all our product design plans |
| 21:38.05 | mvanbaak | as line 1 |
| 21:38.08 | jpeeler | first just form submission |
| 21:38.40 | Corydon76-dig | multipart/form-data |
| 21:39.14 | Corydon76-dig | Well, if you're doing both types of encoding, you might as well do it to the RFC |
| 21:39.45 | Corydon76-dig | When we said we weren't doing it to the RFC, I think it was just meant that we weren't implementing everything |
| 21:40.02 | Corydon76-dig | If you're now implementing everything, well, I don't see a reason why not |
| 21:42.13 | *** join/#asterisk-dev mcargile (n=mcargile@mail.in-florida.net) |
| 21:42.27 | Corydon76-dig | Besides, multipart/form-data is just done with the minimime library |
| 21:42.34 | jpeeler | Corydon76-dig, so how does application/x-www-form-urlencoded fit into the picture? |
| 21:43.13 | Corydon76-dig | That's the other type. It's EXACTLY the same format as the QUERY_STRING, except that it occurs in the body and therefore there is no length limitation |
| 21:43.18 | mcargile | what are the correct compiler flags for Asterisk to get usable backtraces when test 1.6-beta? |
| 21:43.36 | Corydon76-dig | I think the URL has a maxlen of something like 1024 chars |
| 21:43.51 | Corydon76-dig | mcargile: DONT_OPTIMIZE |
| 21:43.58 | mcargile | any others? |
| 21:44.21 | mvanbaak | no |
| 21:44.25 | mcargile | k |
| 21:44.56 | Corydon76-dig | mcargile: DEBUG_THREADS if you're having deadlock issues |
| 21:45.07 | mcargile | k |
| 21:46.14 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 21:48.33 | lmadsen | Corydon76-dig: if I specify multiple dsn= in a func_odbc call, that is just used for failover (i.e. only try the 2nd DSN if the 1st fails)? |
| 21:48.53 | Corydon76-dig | Not multiple dsn, one dsn separated by commas |
| 21:49.11 | Corydon76-dig | and yes, only used for failover |
| 21:49.34 | Corydon76-dig | And really, it's writehandle= at that point, not dsn |
| 21:49.40 | Corydon76-dig | or readhandle= |
| 21:50.50 | lmadsen | oh that's right (using BE C.1.x, which I can't remember if it even had that functionality or not) |
| 21:51.03 | lmadsen | I don't think it did |
| 21:51.06 | lmadsen | only in trunk |
| 22:46.11 | *** part/#asterisk-dev RoyK (n=roy@ip-197-29-149-91.dialup.ice.no) |
| 22:50.50 | *** part/#asterisk-dev corramor (n=corramor@216.207.245.1) |
| 22:51.37 | *** join/#asterisk-dev corramor (n=corramor@216.207.245.1) |
| 23:29.30 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.ct.comcast.net) |
| 23:31.26 | mvanbaak | this is new for me: how to continue when a branch is done ? |
| 23:33.27 | mvanbaak | in my projects they report to the dev that handles the part of the system where the branch is for |
| 23:33.43 | mvanbaak | but dont know how it's done in digium svn |
| 23:40.56 | mvanbaak | I'm off to bed |
| 23:40.57 | mvanbaak | latero |
| 23:57.52 | snuff-work | bye mvanbaak |