| 00:08.43 | JerJer | the patch looks good to me, but it fails to apply :( |
| 00:09.48 | snuff-work | mm.. wait mine was l ittle old.. (didn't do svn update 1st |
| 00:11.43 | snuff-work | mm.. might be your older version.. code has moved |
| 00:12.15 | snuff-work | 85764 (latest) vs 85279 (urs) |
| 00:13.48 | snuff-work | either way.. if you goto the line that it complains about and just add the extra arguement like i did in the patch file.. you should be fine |
| 01:18.02 | *** join/#asterisk-dev Corydon76-dig (i=silver@pdpc/supporter/bronze/Corydon76-home) |
| 01:18.02 | *** mode/#asterisk-dev [+o Corydon76-dig] by ChanServ |
| 01:18.18 | *** join/#asterisk-dev miguel3239 (n=elguerom@ns1.nashuacs.com) |
| 01:25.13 | *** join/#asterisk-dev outtolunc (n=me@c-67-174-216-60.hsd1.ca.comcast.net) |
| 01:54.20 | *** join/#asterisk-dev IgorG (n=FeedomPa@195.162.32.126) |
| 02:15.21 | IgorG | Hello |
| 02:16.42 | IgorG | Qwell, you forget to close 10860 and add a karma $) |
| 02:24.29 | snuff-work | mm you might also want to commit my patch 10986 |
| 02:24.36 | snuff-work | then see if trunk builds |
| 02:24.39 | snuff-work | :) |
| 02:46.32 | Qwell | IgorG: no I didn't :D |
| 02:46.58 | IgorG | Qwell: for some reason this not close automaticaly... |
| 02:47.06 | Qwell | yeah, forgot to put a # |
| 02:47.15 | IgorG | =) |
| 02:47.18 | Qwell | it was a quittin' time commit :) |
| 02:48.15 | *** join/#asterisk-dev tzafrir (n=tzafrir@62.90.10.53) |
| 02:48.15 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 02:48.19 | IgorG | I have write message to *-dev list for close it few minutes ago |
| 02:49.06 | Qwell | sorry about that |
| 02:49.07 | IgorG | Qwell: thanks |
| 02:50.41 | IgorG | can you see for #10550, looks some people need this fix |
| 02:58.45 | *** join/#asterisk-dev JerJer (n=PhatJ@pdpc/supporter/bronze/jerjer) |
| 02:58.45 | *** mode/#asterisk-dev [+o JerJer] by ChanServ |
| 03:09.50 | *** join/#asterisk-dev JerJer (n=PhatJ@pdpc/supporter/bronze/jerjer) |
| 03:09.50 | *** mode/#asterisk-dev [+o JerJer] by ChanServ |
| 04:18.36 | *** join/#asterisk-dev outtolunc (n=me@c-67-174-216-60.hsd1.ca.comcast.net) |
| 05:33.36 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-12-187.bredband.comhem.se) |
| 05:55.58 | *** join/#asterisk-dev mitcheloc (n=mitchel@adsl-67-125-156-53.dsl.irvnca.pacbell.net) |
| 06:08.42 | IgorG | latest trunk don't compile in dev mode |
| 06:08.43 | IgorG | <PROTECTED> |
| 06:08.43 | IgorG | cc1: warnings being treated as errors |
| 06:08.44 | IgorG | ../main/threadstorage.c: In function 'handle_cli_threadstorage_show_summary': |
| 06:08.46 | IgorG | ../main/threadstorage.c:179: warning: ISO C90 forbids mixed declarations and code |
| 06:08.48 | IgorG | make[1]: *** [../main/threadstorage.o] Error 1 |
| 06:19.24 | snuff-work | yer i know |
| 06:19.32 | snuff-work | i fixed 1 error of that igorg |
| 06:19.44 | snuff-work | will post on bug tracker soon |
| 06:21.53 | snuff-work | the 2nd error i get after that is a little harder to figure out why |
| 06:22.38 | *** join/#asterisk-dev syle (n=blah@unaffiliated/syle) |
| 06:36.05 | snuff-work | this is the next error i get |
| 06:36.06 | snuff-work | threadstorage.o(.text+0xa4): In function `__ast_threadstorage_object_add': |
| 06:36.06 | snuff-work | ../main/threadstorage.c:59: undefined reference to `_ast_calloc' |
| 06:36.06 | snuff-work | collect2: ld returned 1 exit status |
| 07:09.53 | sergee | there are 2 ways to transfer DTMF in SIP INFO message: application/dtmf-relay and application/dtmf - i wonder why application/dtmf is not supported? is it a political decision? or nobody have enough time to implement it? |
| 07:23.59 | sergee | and 1 more question if i decide to implement application/dtmf what is the best way to do it? |
| 07:24.18 | sergee | from code point of view |
| 07:25.16 | sergee | add a new statement like : #define SIP_DTMF_INFO2 (5 << 16) |
| 07:25.40 | sergee | or add an extension for existing SIP_DTMF_INFO |
| 07:26.39 | IgorG | Ii think this is a question for *-dev mail list. All of key-devs sleeping now... |
| 07:27.09 | sergee | IgorG: well, they will wake up sooner or later :) |
| 07:27.13 | sergee | i hope :) |
| 07:28.16 | IgorG | i think no early than over 6 hours |
| 07:28.33 | sergee | i'm patient :) |
| 07:28.45 | IgorG | =) |
| 08:02.20 | *** join/#asterisk-dev Corydon76-dig (i=beige@pdpc/supporter/bronze/Corydon76-home) |
| 08:02.20 | *** mode/#asterisk-dev [+o Corydon76-dig] by ChanServ |
| 08:02.23 | *** join/#asterisk-dev Corydon76-home (i=gold@pdpc/supporter/bronze/Corydon76-home) |
| 08:02.23 | *** mode/#asterisk-dev [+o Corydon76-home] by ChanServ |
| 08:59.51 | syle | recommended development is what OS? |
| 09:00.25 | syle | i prefer freebsd but if linux is more stable/tested i'd like to hear that |
| 09:01.13 | jtodd | considering I think I'm running into DNS issues with OpenBSD on some of the SIP stuff, I'd suggest Linux of some flavor to start with. Get familiar, then move to *BSD after you've cut your teeth on Linux development. |
| 09:07.13 | syle | dns issues? |
| 09:08.27 | jtodd | ENUM failures. There's a ticket in mantis somewhere, but i'm too tired to look it up right now. |
| 09:12.57 | *** join/#asterisk-dev kamanashisroy (n=root@202.56.7.136) |
| 09:13.08 | kamanashisroy | hi, can anyone help me with beep detection ? I have used spandsp library which goertzel algorithm to measure the energy of a specific frequency .. |
| 09:33.17 | *** part/#asterisk-dev kamanashisroy (n=root@202.56.7.136) |
| 09:46.20 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 09:46.20 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:50.10 | *** join/#asterisk-dev IvanV3835 (n=Miranda@styx.mcn.ru) |
| 10:12.06 | sergee | oej: g'day! |
| 10:12.24 | oej | hello there! |
| 10:12.41 | sergee | oej: quick question about SIP INFO: |
| 10:12.50 | oej | Right |
| 10:12.53 | sergee | oej: there are 2 ways to transfer DTMF in SIP INFO message: application/dtmf-relay and application/dtmf - i wonder why application/dtmf is not supported? is it a political decision? or nobody have enough time to implement it? |
| 10:13.10 | oej | Well, neither is a standard |
| 10:13.20 | oej | Who's using application/dtmf ? |
| 10:13.26 | sergee | oej: yeah i know that, |
| 10:13.29 | oej | That's not even CIsco-compatible |
| 10:13.34 | oej | So that's a strange version |
| 10:13.52 | sergee | oej: we baught ClosedSource CallCenter recentlay |
| 10:13.58 | sergee | oej: NaumenCC |
| 10:14.08 | oej | I think that must be a bug on their side |
| 10:14.51 | sergee | oej: well, i found some references to application/dtmf on the net, some hardware using it... |
| 10:15.10 | oej | Well, then we have to fix it |
| 10:15.20 | oej | That must be ver simple |
| 10:15.31 | sergee | oej: i will implement it anyway, i just wonder if community would be interested in this addition and if it is so, then how to do it right :) |
| 10:15.37 | sergee | oej: yes |
| 10:16.23 | oej | gotta run, back soon |
| 10:16.25 | sergee | oej: if we have 2 methods, then how we should chose between it? |
| 10:16.33 | oej | I don't see any problem implementing that. If it enhances connectivity then fine. |
| 10:16.48 | oej | Well, has to be another ugly setting for DTMF, doesn't it? |
| 10:17.02 | sergee | oej: i mean if peer has dtmfmode=info, how should we decide whever we send application/dtmf or application/dtmf-relay ? |
| 10:17.02 | oej | dtmfmode=stupidinfo :-) |
| 10:17.03 | oej | he he |
| 10:17.09 | sergee | oej: :) |
| 10:17.24 | oej | dtmfmode=info-dtmf and info-cisco |
| 10:17.34 | sergee | oej: ok, i'll think about it :) |
| 10:17.50 | oej | gotta go, time for lunch |
| 10:18.00 | sergee | oej: bon appetite! |
| 10:18.11 | oej | merci! |
| 10:35.08 | sergee | oej: i have a better idea, we can use dtmfmode=info for both modes, we'll chose right apptype according to "Accept" received from remote party. if both options (application/dtmf and application/dtmf-relay) are supported - we will prefer the last one. What do you think? |
| 10:37.24 | tzafrir | oej, are you aware of any work done to support V.150 (modem over IP) in Asterisk? Is it used anywhere? |
| 10:38.12 | *** join/#asterisk-dev _ys (i=ys@91.151.196.254) |
| 10:57.56 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 10:58.58 | _ys | hello, gdb guru are here ? |
| 10:59.53 | _ys | I got "pid 93884 (asterisk), uid 0: exited on signal 11 (core dumped)" after "sip reload" |
| 11:00.02 | _ys | gdb bt say me: |
| 11:00.07 | _ys | #1360 0x080e23bc in ast_udptl_reload () at udptl.c:1239 |
| 11:00.12 | _ys | <PROTECTED> |
| 11:00.16 | _ys | <PROTECTED> |
| 11:00.20 | _ys | <PROTECTED> |
| 11:00.25 | _ys | Previous frame inner to this frame (corrupt stack?) |
| 11:01.25 | _ys | asterisk version 1.4.13 |
| 11:03.09 | _ys | As I know |
| 11:03.21 | _ys | if ((s = ast_variable_retrieve(cfg, "general", "udptlstart"))) { |
| 11:03.38 | _ys | ast_variable_retrieve return incorrect pointer ? |
| 11:20.54 | *** join/#asterisk-dev Whisk (n=whisk@82-44-47-95.cable.ubr04.croy.blueyonder.co.uk) |
| 11:59.12 | *** join/#asterisk-dev blitzrage (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:18.22 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) |
| 12:40.30 | *** join/#asterisk-dev bweschke (n=bweschke@204.13.233.213) |
| 12:40.30 | *** mode/#asterisk-dev [+o bweschke] by ChanServ |
| 12:42.43 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 12:46.04 | puzzled | hi |
| 12:46.29 | bweschke | morning |
| 12:49.19 | blitzrage | yo |
| 12:58.53 | bweschke | morning |
| 13:03.03 | sergee | chan_sip.c:10405 static int get_msg_text(char *buf, int len, struct sip_request *req) |
| 13:03.18 | sergee | 10411 y = len - strlen(buf) - 5; |
| 13:03.31 | sergee | can anybody explain me the secret meaning of "5" ? |
| 13:05.15 | sergee | strlen(buf) right after buf[0] = '\0'; - doesn't make any sense either... |
| 13:27.40 | *** join/#asterisk-dev zerohalo (n=zeroHalo@pool-72-70-79-233.bstnma.east.verizon.net) |
| 13:28.13 | sergee | where chan_sip stores capabilities claimed in "Accept:" header by remote peer? can i access those values through struct ast_channel? |
| 13:28.36 | sergee | hmm both peer are remote from asterisk point of veiw... |
| 13:32.01 | snuff-away | mm.. maybe like ${SIPHeader(Accept)} ? |
| 13:33.41 | snuff-away | mm.. that wont work.. function is sipaddheader.. |
| 13:34.37 | snuff-away | mm wait that should work :) |
| 13:35.41 | snuff-away | mm SIP_HEADER() |
| 13:43.47 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 13:43.47 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 13:46.55 | sergee | snuff-away: i want to send events from asterisk to remote party, i want to senf DTM in a rare SIP_INFO modification, in this case i don't have a request from remote party, so i don't have any headers, i have only opened SIP dialog, but it seems that asterisk doesn't store recieved capabilities for a dialog.. |
| 13:47.16 | sergee | ... to send DTMF ... |
| 13:47.24 | snuff-away | mm :( |
| 13:54.05 | mvanbaak | use meld :) |
| 13:54.31 | snuff-away | meh i won eventually |
| 13:54.37 | snuff-away | M10995 |
| 13:54.38 | MuffinMan | [new] [Asterisk] Core-General 0010995: [patch] Issues with threadstorage.c reported by snuffy http://bugs.digium.com/view.php?id=10995 |
| 13:55.10 | mvanbaak | congrats |
| 13:55.11 | mvanbaak | :) |
| 13:55.28 | snuff-away | fixed the initial issue with threadstorage.. but can't solve that part on linking it fails |
| 13:56.55 | snuff-away | time for tv ep then zzz |
| 14:08.57 | mvanbaak | latero |
| 14:09.43 | file | snuff-away: ooh nifty find |
| 14:11.20 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.12.183) |
| 14:11.39 | *** join/#asterisk-dev Cresl1n (i=matt@nat/digium/x-7be70ff1c3de00de) |
| 14:11.39 | *** mode/#asterisk-dev [+o Cresl1n] by ChanServ |
| 14:11.41 | snuff-away | file.. also i recommend the imap patch |
| 14:11.43 | snuff-away | M0010986 |
| 14:11.44 | MuffinMan | [assigned] [Asterisk] Applications/app_voicemail 0010986: [patch] Issue with IMAP compilation reported by snuffy http://bugs.digium.com/view.php?id=0010986 |
| 14:11.46 | *** join/#asterisk-dev blitzrage (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:11.57 | snuff-away | that should get trunk closer to compile :) |
| 14:13.01 | file | that one I wouldn't just commit, more to it... |
| 14:13.15 | snuff-away | yer thought there might be ;) |
| 14:14.50 | file | what platform is this on? |
| 14:15.04 | snuff-away | centos 4.3 linux |
| 14:20.59 | *** join/#asterisk-dev jsmith (n=jsmith@h460565e0.area3.spcsdns.net) |
| 14:21.00 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 14:21.03 | snuff-away | mm.. file did u see the 'additional info' bit? |
| 14:21.40 | file | what compiler flags are you using? |
| 14:21.51 | snuff-away | lots ;) |
| 14:21.59 | file | such as? |
| 14:22.07 | snuff-away | 1 sec loggin back into box |
| 14:22.45 | snuff-away | DEBUG_CHANNEL_LOCKS |
| 14:23.48 | snuff-away | <PROTECTED> |
| 14:23.51 | snuff-away | total :) |
| 14:24.19 | *** join/#asterisk-dev ctooley_ (n=ctooley@209.33.109.32) |
| 14:24.21 | snuff-away | Linux 2.6.9-34.0.2.EL |
| 14:31.37 | bweschke | /me waves to file |
| 14:35.32 | file | snuff-away: interesting! |
| 14:40.38 | snuff-away | it is a little.. if i changed the ast_calloc to just calloc |
| 14:40.48 | snuff-away | it would compile + link fine |
| 14:41.07 | snuff-away | otherwise it would do that error i have on the bug report |
| 14:42.24 | *** join/#asterisk-dev putnopvut (i=putnopvu@nat/digium/x-6788265e7022a3ca) |
| 14:42.24 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:44.45 | Juggie | good morning |
| 14:44.56 | putnopvut | good morning Juggie |
| 14:45.04 | *** join/#asterisk-dev popvoxdave (n=davetroy@pool-71-179-109-229.bltmmd.fios.verizon.net) |
| 14:45.33 | *** join/#asterisk-dev miguel3239 (n=elguerom@ns1.nashuacs.com) |
| 14:47.11 | snuff-away | i'd help more with 'threadstorage' issue but i need some zzz's :) |
| 14:49.00 | Cresl1n | russellb: ping... |
| 14:49.17 | putnopvut | Cresl1n: I think he may be in transit at this point. |
| 14:49.40 | putnopvut | He's scheduled to get into HSV at 12:30 |
| 14:49.44 | jsmith | Cresl1n: Ping?!? |
| 14:49.50 | Cresl1n | hey jsmith ! |
| 14:50.03 | jsmith | Cresl1n: Any idea on that error message I sent you the other day? |
| 14:50.14 | Cresl1n | yeah, did you get my reply? |
| 14:50.18 | Cresl1n | it's not an error message |
| 14:50.42 | jsmith | Nope, I didn't get your reply |
| 14:50.46 | jsmith | What does it mean? |
| 14:51.08 | Cresl1n | it just means that if you did a ZT_DIAL on the channel, that's the exception you get when it completes |
| 14:51.27 | Cresl1n | a kind of asynchronous notification |
| 14:57.33 | jsmith | Ah... so nothing to worry about then, right? |
| 14:57.52 | Cresl1n | yep |
| 15:12.24 | paravoid | Cresl1n: remember the bug I've filled ages ago? |
| 15:12.34 | paravoid | that you told me to ask the list for testers? |
| 15:12.56 | paravoid | well, it seems that I can't mail the list; I've been trying since August |
| 15:13.14 | paravoid | so, please ask the list for testers... |
| 15:13.22 | Cresl1n | which bug was that? |
| 15:14.04 | paravoid | hrm |
| 15:14.12 | jsmith | paravoid: If you can't mail the list, please open an IT request... they'll un-spam-block your posts :-) |
| 15:14.25 | paravoid | jsmith: how can I do that? |
| 15:14.36 | paravoid | M10552 |
| 15:14.37 | MuffinMan | [assigned] [LibPRI] General 0010552: Immediately releases channel after a DISCONNECT with In-band audio reported by paravoid http://bugs.digium.com/view.php?id=10552 |
| 15:15.02 | Cresl1n | yeah, actually I think I'm going to put it in anyway |
| 15:15.15 | Cresl1n | I've just been really busy with a couple of other things |
| 15:15.16 | jsmith | paravoid: Actually, just email me and I'll take care of it jsmith-at-digium-dot-com |
| 15:15.34 | Cresl1n | paravoid: you said you have tested it and it works well for ou? |
| 15:15.39 | paravoid | yes |
| 15:15.43 | paravoid | well, there is a misfeature |
| 15:15.46 | Cresl1n | jsmith: you might be interested in that bug |
| 15:15.49 | paravoid | to be completely honest |
| 15:15.54 | Cresl1n | paravoid: what? |
| 15:15.58 | jsmith | Cresl1n: Oh? |
| 15:16.02 | paravoid | when it's busy |
| 15:16.10 | paravoid | as in, simply busy |
| 15:16.17 | paravoid | I'm getting a busy tone from the carrier |
| 15:16.25 | paravoid | which is played inband |
| 15:16.35 | Cresl1n | and busy frames from asterisk? |
| 15:16.46 | paravoid | but it's a tone (unlike the "wrong number", "technical problem" etc. recorded messages) |
| 15:16.54 | paravoid | so, I'm getting the tone for 20 seconds |
| 15:17.05 | paravoid | before asterisk realizes it's Busy and moves to the next priority |
| 15:17.20 | paravoid | which could e.g. handle it or something like that |
| 15:17.24 | Cresl1n | wait a second.... |
| 15:17.29 | Cresl1n | start over. |
| 15:17.43 | Cresl1n | what's broken now? |
| 15:17.49 | paravoid | nothing is "broken" |
| 15:17.50 | paravoid | it's just |
| 15:17.56 | paravoid | that if you have a dialplan that says |
| 15:18.07 | paravoid | _X.,1,Dial(Zap/g1/NNNNN) |
| 15:18.42 | paravoid | _X.,n,<handle busy by using dialstatus/goto/gotoif) |
| 15:19.16 | paravoid | you'll have to *hear* the inband audio for N seconds (N=defined by the carrier, max 30secs) |
| 15:19.29 | paravoid | before it moves to 2 |
| 15:19.44 | Cresl1n | Hrm.... |
| 15:19.59 | Cresl1n | I guess that's the consequence of doing that |
| 15:20.04 | paravoid | right. |
| 15:20.12 | Cresl1n | we could make it a zapata.conf behavior option |
| 15:20.20 | paravoid | that's what I was thinking |
| 15:20.40 | paravoid | there's an inband progress option that could be (ab)used, isn't there? |
| 15:20.51 | Cresl1n | paravoid: would you like to update the patch so that it does that? |
| 15:20.57 | Cresl1n | yeah, I'm trying to remember which one |
| 15:21.13 | paravoid | i'm not sure how to do that, I'll have a look |
| 15:21.20 | paravoid | too busy right now however, it might take a bit |
| 15:21.21 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 15:21.43 | *** join/#asterisk-dev jcmoore (n=jcmoore@unaffiliated/tgrman) |
| 15:23.34 | Cresl1n | priindication |
| 15:23.47 | Cresl1n | right now it's how we send the other end indication |
| 15:24.16 | Cresl1n | we could overload it so that it works in the other direction as well |
| 15:25.25 | paravoid | bristuff is overloading it, I think. |
| 15:26.17 | paravoid | yep. |
| 15:26.34 | paravoid | <PROTECTED> |
| 15:26.37 | paravoid | <PROTECTED> |
| 15:26.40 | paravoid | +; passthrough: Listen to the telco |
| 15:26.42 | paravoid | <PROTECTED> |
| 15:26.45 | paravoid | <PROTECTED> |
| 15:26.59 | paravoid | (it's not actual code, so I guess it was OK to copy/paste it...) |
| 15:30.42 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 15:45.22 | *** join/#asterisk-dev ctooley (n=ctooley@209.33.109.249) |
| 15:55.41 | paravoid | I have successfully backported the libcap/ToS patch to 1.4 |
| 15:56.08 | paravoid | it's small and straightforward, but its functionality is important IMHO |
| 15:56.16 | paravoid | may be the next 1.4.x release should include it as well? |
| 15:56.19 | paravoid | russellb: ? |
| 16:13.09 | blitzrage | paravoid: new features do not go into a release |
| 16:13.40 | blitzrage | although it may be possible that a port could live on svncommunity or something... but that is something for someone else to decide upon :) |
| 16:27.35 | *** join/#asterisk-dev kpfleming (i=kpflemin@nat/digium/x-45eb5bf90ac65ade) |
| 16:27.35 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:32.52 | paravoid | blitzrage: it's not exactly a new feature |
| 16:32.59 | paravoid | it's a bug fix, sort of |
| 16:33.35 | paravoid | currently (= 1.4) you can't run asterisk as non-root and set the low-delay IP ToS values at the same time |
| 16:33.37 | blitzrage | paravoid: does that feature exist in 1.4? I'm still a little out of it... so I guess I just read "backport" and assumed new feature :) |
| 16:33.44 | blitzrage | gotcha |
| 16:34.00 | blitzrage | you might want to open a bug then on the tracker and document this with the patches |
| 16:34.53 | paravoid | blitzrage: it doesn't need documentation |
| 16:35.08 | paravoid | it's *fixed* in trunk, hence known and acknowledged |
| 16:35.26 | blitzrage | but you created a backport... i.e. patch yes? |
| 16:35.48 | paravoid | I took trunk's changes and made them apply to 1.4, yes. |
| 16:35.51 | blitzrage | and by document... I just meant, "hey, I've got this patch which fixes issue FOO" |
| 16:35.55 | paravoid | it isn't anything special |
| 16:36.04 | blitzrage | it still needs to go through the bug tracker I believe |
| 16:41.13 | *** join/#asterisk-dev jsmith (n=jsmith@h460565e0.area3.spcsdns.net) |
| 16:41.14 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 16:48.41 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 17:06.53 | *** join/#asterisk-dev matsk (n=mk@host-217-213-138-53.mobileonline.telia.com) |
| 17:13.48 | *** part/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-12-187.bredband.comhem.se) |
| 17:22.16 | *** join/#asterisk-dev Netgeeks (n=chris@204.11.231.198.static.etheric.net) |
| 17:22.51 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.182.176) |
| 18:03.34 | *** join/#asterisk-dev ACiDV (n=acidv@97-147.dr.cgocable.ca) |
| 18:04.09 | ACiDV | Does exist a way to confirm that an Asterisk has been build w/ DEBUG_THREAD and DONT_OPTIMIZE ? |
| 18:05.32 | jcmoore | Anyone else notice that in the latest 1.4 that ast_localtime() isn't setting the correct GMT offset? When strftime() prints its result, it's always +0000 for me, ex "Tue, 16 Oct 2007 12:25:04 +0000" |
| 18:06.05 | jcmoore | even though the timezone is set to "America/Chicago" |
| 18:16.39 | *** join/#asterisk-dev Corydon76-lap (i=Corydon7@pdpc/supporter/bronze/Corydon76-home) |
| 18:16.40 | *** mode/#asterisk-dev [+o Corydon76-lap] by ChanServ |
| 18:18.56 | ACiDV | Please =) Someone has an idea ? |
| 18:19.15 | *** join/#asterisk-dev philippel (n=p_lindhe@c-98-203-245-82.hsd1.wa.comcast.net) |
| 18:19.55 | jsmith | Corydon76-lap: Did you see jcmoore's comment there? |
| 18:20.06 | Corydon76-lap | noop |
| 18:20.08 | jsmith | Corydon76-lap: Weren't you doing something with timezones? |
| 18:20.13 | jsmith | jcmoore> Anyone else notice that in the latest 1.4 that ast_localtime() isn't setting the correct GMT offset? When strftime() prints its result, it's always +0000 for me, ex "Tue, 16 Oct 2007 12:25:04 +0000" |
| 18:20.46 | Corydon76-lap | Interesting |
| 18:20.49 | jcmoore | Running CentOS 4 with tzdata-2007h-1.el4 |
| 18:21.10 | Corydon76-lap | I wasn't aware that gmt offsets were even in tzdata |
| 18:22.08 | philippel | ping to one of the ops I'm trying to send some information about a security attack to asterisk to security@asterisk.org which is bouncing, is that not the correct adderess? (I've searched a bit on the website couldn't find the info yet)? |
| 18:22.31 | Corydon76-lap | It's probably because glibc extends in some platform-dependent way |
| 18:22.54 | Qwell | philippel: it should work.. |
| 18:22.56 | Corydon76-lap | At some point, we'll be switching to ast_strftime, probably |
| 18:23.07 | Qwell | kpfleming: should he just send it to you directly, until we can figure out the problem? |
| 18:23.20 | Corydon76-lap | but I've been off in left field with crypto recently |
| 18:23.47 | kpfleming | Qwell: yeah, i guess our mail alias is borked, because we haven't received any mail from the security lists for a while either |
| 18:23.50 | philippel | Qwell I'm sending it through my freepbx.org gmail domain account and getting PERM_FAILURE: SMTP Error (state 13): 550 relay not permitted |
| 18:23.52 | kpfleming | time for another itrequest |
| 18:24.06 | Qwell | philippel: send it to kpfleming at digium.com, please :) |
| 18:24.07 | kpfleming | philippel: send me the bounce message and your problem(s) report |
| 18:24.08 | jcmoore | I'd thought the tz stuff was in tzdata, could be wrong though |
| 18:24.22 | jcmoore | er, gmt offsets |
| 18:24.23 | philippel | kpfleming where should I send it to you, is it just kpfleming@digium? |
| 18:24.28 | kpfleming | yes |
| 18:24.55 | philippel | I'll send the original message and the error message to help you fix the issue (unless it is on my side) |
| 18:25.02 | kpfleming | i'm sure it is on our side |
| 18:25.28 | kpfleming | we just moved into a new building and our IT department built a new network... that server is probably not something that they tested |
| 18:25.58 | file | have to admit it could have been worse... |
| 18:26.08 | kpfleming | much |
| 18:27.02 | ACiDV | I see in menuselect.makeopts this line, enough to confirm that theses flags are enabled ? : MENUSELECT_CFLAGS=DEBUG_THREADS DONT_OPTIMIZE LOADABLE_MODULES |
| 18:27.18 | kpfleming | philippel: got it, thanks |
| 18:27.47 | philippel | kpfleming great - you should have both now so you can send the IT guys the failure message |
| 18:27.56 | kpfleming | yep, working on that too |
| 18:28.30 | philippel | kpfleming this is the same issue I discussed with Brian at Swtichvox in case he already brought it up |
| 18:28.55 | kpfleming | he did |
| 18:30.19 | russellb | Cresl1n: pong |
| 18:32.51 | Corydon76-lap | jcmoore, generally speaking, the gmt offsets aren't used all that much because the offset varies with dst |
| 18:33.07 | jcmoore | i see |
| 18:33.31 | jcmoore | so where do we think the incorrect calculation is coming from? |
| 18:33.58 | Corydon76-lap | I think it's simply not doing any calculation, which is why you're getting 0 |
| 18:34.17 | jcmoore | yeah, that could be |
| 18:34.58 | Corydon76-lap | The timezone offset appears to be a GNU extension to the standard |
| 18:36.25 | Corydon76-lap | Yep, it's gnu (just checked the manpage), which is why the code (which is platform independent) doesn't support it |
| 18:36.25 | jcmoore | nice |
| 18:40.21 | putnopvut | it's time to play a little game called "bug or feature." I'm going to name a peculiar behavior of app_queue, and I want to hear if you think it's a bug or a feature. |
| 18:40.48 | jcmoore | ooooh, what are the prizes? |
| 18:40.55 | putnopvut | You can issue a "queue remove member" CLI command for a static member, and it will be removed from the queue. |
| 18:41.11 | Corydon76-lap | Good question |
| 18:41.23 | jmls | feature |
| 18:41.29 | putnopvut | Issuing a reload won't do anything unless you have made some change to queues.conf. |
| 18:41.39 | Corydon76-lap | Right, in trunk |
| 18:41.53 | Corydon76-lap | That's a bug. |
| 18:42.12 | Corydon76-lap | You aren't supposed to be able to remove static members by using the dynamic interface |
| 18:42.17 | *** join/#asterisk-dev mog (n=mog@c-71-207-220-220.hsd1.al.comcast.net) |
| 18:42.17 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 18:43.20 | outtolunc | which came first, the member or the interface {giggles} |
| 18:43.42 | outtolunc | bad joke, sorry |
| 18:45.02 | Corydon76-lap | Member came first... interface is a field in the member. :-P |
| 18:46.50 | jcmoore | so, since the %z variable in strftime is a GNU extension, how do we make GNU based strftime happy while not breaking others? |
| 18:47.27 | outtolunc | side note: http://asterisknow.org/downloads has a link for [ftp] still (it should be removed) |
| 18:47.30 | Corydon76-lap | Well, we'd need to figure out where in the struct it is putting that field |
| 18:47.51 | Corydon76-lap | Right now, it's just referencing memory in no-man's land |
| 18:47.58 | jcmoore | yay, the tm struct :-) |
| 18:48.00 | *** join/#asterisk-dev snuff-away (i=snuff@220-253-159-93.VIC.netspace.net.au) |
| 18:48.10 | Corydon76-lap | Actually, the ast_tm struct in trunk |
| 18:48.24 | Corydon76-lap | We're now storing milliseconds in the struct, too |
| 18:48.36 | bweschke | putnopvut: feature |
| 18:52.35 | putnopvut | so that's 2 who say feature and 1 who says bug. |
| 18:53.16 | Corydon76-lap | If it gets readded when somebody reloads the config, then it's a bug to be able to remove it that way |
| 18:53.49 | putnopvut | My initial inclination was that it's a bug, but I didn't want to disrupt some "feature" that people take advantage of. |
| 18:54.10 | Corydon76-lap | People have taken advantage of bugs before, that's nothing new |
| 18:55.26 | putnopvut | The member does get re-added on a reload (in 1.4 unconditionally, in trunk if any change has been made to queues.conf) |
| 18:56.07 | Corydon76-lap | Think of persistent queue members... that also means that members who get turned off should STAY off |
| 18:56.23 | putnopvut | Which, speaking of trunk's behavior of not taking action if the .conf file has not changed, does that affect static realtime in an adverse way? |
| 18:56.47 | putnopvut | I haven't delved into the internals, but if someone changes their database, but not the .conf file, will trunk ignore those changes on a reload? |
| 18:57.00 | Corydon76-lap | No, because it only takes effect for text file loads |
| 18:57.30 | putnopvut | All right, now I know (and knowing is half the battle) |
| 18:57.32 | Corydon76-lap | and it tracks #exec and #include, so if you change a dependent file, it reloads the whole enchilada |
| 18:57.32 | putnopvut | Thanks. |
| 19:02.55 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 19:03.31 | kpfleming | yumm.. enchiladas |
| 19:05.17 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 19:12.39 | jcmoore | Corydon76-lap: seemed to have fixed it on my box but don't know how platform independent it is... |
| 19:12.53 | Corydon76-lap | jcmoore, eh? |
| 19:13.05 | jcmoore | the GMT offset |
| 19:13.38 | Corydon76-lap | Dare I ask how? |
| 19:14.07 | jcmoore | Just need to set tmp->tm_gmtoff in localsub() |
| 19:15.29 | jcmoore | Is that the "right" way to do that? |
| 19:16.11 | Corydon76-lap | Yes, looks okay to me |
| 19:16.15 | jcmoore | :-) |
| 19:16.46 | jcmoore | could I persuade you to commit that to 1.4? |
| 19:16.48 | Corydon76-lap | Submit the patch on bugs, if you don't mind |
| 19:16.52 | jcmoore | ah, will do |
| 19:22.50 | *** join/#asterisk-dev elixer (n=elixer@65.207.74.18) |
| 19:28.16 | *** part/#asterisk-dev mog (n=mog@c-71-207-220-220.hsd1.al.comcast.net) |
| 19:29.46 | jcmoore | M11002 |
| 19:29.47 | MuffinMan | [new] [Asterisk] Core-General 0011002: GMT offset not stored/reported correctly reported by jcmoore http://bugs.digium.com/view.php?id=11002 |
| 19:30.08 | putnopvut | ooh, we've crossed 11000. |
| 19:31.47 | jmls | that's what timezones do to you ;) |
| 19:35.06 | Corydon76-lap | Can we cross in the opposite direction and lose bugs? |
| 19:37.10 | russellb | i wish |
| 19:37.21 | russellb | bugs are lame |
| 19:37.30 | *** join/#asterisk-dev d1mas (n=chatzill@ip195.117.adsl.wplus.ru) |
| 19:39.11 | d1mas | hello again.Question: currently ael/pbxconfig will refuse processing a context which which is already declared. I'm curious why? Specifying the same context multiple times could just add more extensions to the same context... |
| 19:40.32 | outtolunc | i'd guess that because usually they indicate dupilcation |
| 19:40.38 | Corydon76-lap | Because it doesn't actually add it to the same context |
| 19:40.40 | outtolunc | er li |
| 19:40.48 | Corydon76-lap | Instead, it creates a new context with the same name |
| 19:41.06 | Corydon76-lap | Patched welcome, though |
| 19:42.13 | d1mas | well the question is - will a such a behavior break something or not |
| 19:42.48 | d1mas | (ie each time encountering a context, AEL parser will find_or_create instead of just create) |
| 19:44.33 | d1mas | outtolunc: well, it still can display warnings in attempt to add already defined extension |
| 19:45.00 | outtolunc | well it would have to then parse each extension within, then in the case of x,n,yadda have to define a priority in which to toss that salad |
| 19:45.02 | codefreeze | d1mas: hmmmmmm. In extensions.conf, you can use the (+) to add stuff to an existing context.... |
| 19:45.43 | jsmith | codefreeze: Can you do something similar from ael? |
| 19:45.51 | d1mas | hmmm... did not know about that |
| 19:46.04 | codefreeze | jsmith: d1mas: uh, no........ not yet.... |
| 19:47.33 | Corydon76-lap | If you change the load order, and load ael first, then use the + syntax in extensions.conf, you're golden |
| 19:48.40 | Corydon76-lap | As long as you don't have to reload, that is |
| 19:48.44 | codefreeze | Hmmmm. Could use a new keyword, like addcontext instead of context in ael.... |
| 19:49.08 | d1mas | Corydon: I do not use extensions.conf at all. Everything is defined in AEL |
| 19:49.25 | Corydon76-lap | How is this a problem, then? |
| 19:49.56 | d1mas | Ah. Ok, let me clarify :) |
| 19:50.16 | Corydon76-lap | outtolunc, you getting a shiver down MY spine is spine-tingling, indeed |
| 19:53.39 | d1mas | What I want is to have some "default" configuration available for all cluster members and only override (actually extend with additional extensions) specific context on per-site basis. Like "services" context defines "echo" service, "disa" and so on while particular site adds its specific. I know that I can create separate "site-services" and include it into "services" to get the problem... |
| 19:53.41 | d1mas | ...solved :) But in addition to services I have about 10 other contexts and I will have create "site-XXX" for all of them. Not difficult of course, just not very nice. |
| 19:54.43 | d1mas | And I thought that ability to extend context would help. Also it would solve the problem of inability to "mix" ael/conf context. But this is just a bonus - not the goal |
| 19:58.02 | *** join/#asterisk-dev _charly_ (i=kroseneg@sunrise.schmidham.net) |
| 20:02.45 | *** join/#asterisk-dev mog (n=mog@c-71-207-220-220.hsd1.al.comcast.net) |
| 20:02.45 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 20:03.48 | d1mas | silence... :) |
| 20:06.13 | codefreeze | just thinkin' |
| 20:06.44 | Corydon76-lap | I dunno, I like creating different contexts... seems cleaner to me |
| 20:07.06 | Corydon76-lap | Less ambiguous |
| 20:07.09 | jtodd | d1mas: just include a generic context name, and then specify that generic context name in an included file. Then just create specific files for each site that get stuffed into /etc/asterisk which contain the site-specific stuff. |
| 20:08.11 | codefreeze | Well, not that I dislike the idea. There's a certain sense of symmetry if both ael and exten.conf have a way to extend a context... |
| 20:08.13 | codefreeze | but... |
| 20:08.31 | codefreeze | You could do a #include inside the context.... and.... |
| 20:09.04 | codefreeze | ?? |
| 20:09.51 | codefreeze | Hmmmm. there's no #ifdef equivalent in either the configs or in ael. |
| 20:12.15 | russellb | codefreeze: if we were going to go that far, we might as well literally use the C preprocessor |
| 20:12.33 | russellb | :) |
| 20:12.54 | russellb | that probably won't work.. |
| 20:14.36 | d1mas | not sure I understood your idea, jtodd. What you mean by generic context names ? |
| 20:14.36 | Corydon76-lap | Ooo, preprocessor... |
| 20:14.58 | codefreeze | russellb: not work? |
| 20:15.00 | putnopvut | #error |
| 20:15.26 | Corydon76-lap | #warn |
| 20:15.36 | codefreeze | #LINE!!! |
| 20:15.43 | d1mas | :) |
| 20:16.19 | Corydon76-lap | #pragma I'm sure is still the most obscure |
| 20:16.24 | jtodd | d1mas: In your general contexts where you need site specific stuff, do something like "include => site-specific-stuff", then create a file (unique on each machine) called "site-specific-contexts" which contains the context "[site-specific-stuff]", and then "#include site-specific-contexts" at the top of your extensions.conf |
| 20:17.00 | codefreeze | or even ael file |
| 20:17.26 | Corydon76-lap | #pragma memorymodel small |
| 20:17.51 | d1mas | jtodd: hmm... Well, how is that different from what I wrote above? (To have site-services and including it into generic services) |
| 20:18.52 | *** join/#asterisk-dev mvanbaak (i=michiel@vanbaak.xs4all.nl) |
| 20:26.48 | jtodd | d1mas: perhaps it's not that different, other than using the filesystem to create the ease of context separation and generic usage. |
| 20:26.49 | codefreeze | russellb: hey, I had an idea about the lock this morning. |
| 20:26.59 | russellb | orly. |
| 20:27.16 | russellb | i feel stupid... |
| 20:27.32 | putnopvut | Fun. |
| 20:28.05 | russellb | oh yes |
| 20:28.07 | jsmith | russellb: No, don't feel stupid... feel great! Anytime you can close bugs that easily! |
| 20:28.26 | russellb | at least it didn't take long to find |
| 20:28.33 | russellb | i thought i was about to spend hours tracking something down |
| 20:28.44 | file | 11003? |
| 20:28.49 | outtolunc | at least you didn't spend those hours |
| 20:28.50 | putnopvut | The most annoying fixes are the ones that take hours to track and end up being a one line fix. |
| 20:28.50 | russellb | file: correct, sir |
| 20:28.55 | file | yay |
| 20:29.51 | codefreeze | .... actually, about the crash while checking the lock, I mean |
| 20:30.55 | codefreeze | ok |
| 20:31.02 | codefreeze | picture this: |
| 20:31.24 | d1mas | btw, guys do you know the time when you going to sprint 1.6 off the trunk |
| 20:31.26 | d1mas | ? |
| 20:31.35 | russellb | d1mas: probably next week |
| 20:31.35 | d1mas | spring |
| 20:31.52 | d1mas | great! And will SIP session timers be included ? |
| 20:31.53 | russellb | d1mas: more details coming to a -dev list near you |
| 20:31.57 | codefreeze | problem 1: something is releasing a lock more times than its allocated. in the q stuff. |
| 20:32.14 | russellb | d1mas: maybe, maybe not. but, 1.6 will not be feature frozen |
| 20:32.20 | codefreeze | problem 2: the check that detects this crashes sometimes |
| 20:32.25 | d1mas | great to know |
| 20:33.36 | codefreeze | problem 3: sometimes, because between the time the lock innards are checked to see if they are there, and the time they are accessed, another thread zeroes out the lock contents... |
| 20:34.14 | russellb | so i'd say the place to start is problem #1 :) |
| 20:34.38 | codefreeze | solving 1 will help, but it will not solve 3 |
| 20:35.15 | putnopvut | q stuff? Does this mean app_queue? |
| 20:35.23 | russellb | well, #3 is an issue outside of the locking code |
| 20:35.54 | codefreeze | really? we never init a lock? |
| 20:36.09 | russellb | sure, we init locks ... |
| 20:36.28 | russellb | but that has to be complete before the lock gets touched elsewhere |
| 20:36.36 | putnopvut | codefreeze: have you looked at the patch on 10571? |
| 20:36.43 | putnopvut | That is a potential fix for the lock issue. |
| 20:37.00 | putnopvut | If it's the one I think you're talking about. |
| 20:37.04 | russellb | M10571 |
| 20:37.06 | MuffinMan | [new] [Asterisk] Applications/app_dial 0010571: SIP hairpin invokes Local within app_dial to produce a crash. reported by dtyoo http://bugs.digium.com/view.php?id=10571 |
| 20:37.28 | putnopvut | The latest patch on there is one that people are saying fixes the lock crash that had been discussed. |
| 20:37.41 | codefreeze | putnopvut: no, I've been up to my eyeballs in ^%$#&$(*%@! cdr fix. |
| 20:38.32 | putnopvut | The lock issue I'm referring to is the one people were having where there was a segfault from garbage lock data (the reentrancy variable especially) due to a race condition. |
| 20:39.22 | codefreeze | putnopvut: sounds close. I saw a crash because t get set to 0 in the lock struct. |
| 20:39.34 | d1mas | but IMHO it only happens when debugging locks... |
| 20:39.51 | codefreeze | yep.... debugging lockss... |
| 20:40.55 | codefreeze | was it t? anyway, reentrancy is in there. getting the ptr nulled out is hard on the access. |
| 20:42.28 | russellb | i suppose his patch is right |
| 20:42.46 | russellb | but the problem exists in corner cases |
| 20:42.56 | snuff-away | mm @ person in this case.. |
| 20:42.59 | snuff-away | M10973 |
| 20:43.00 | MuffinMan | [assigned] [Asterisk] CDR/cdr_odbc 0010973: several crashes in Trunk using cdr_odbc and func_odbc with SQL Server. fretds 0.64 (latest) reported by falves11 http://bugs.digium.com/view.php?id=10973 |
| 20:43.02 | russellb | so i'd be surprised if it fixes as many crashes as have been reported |
| 20:44.14 | putnopvut | russellb: so far, there have been two users who have had their crashes cleared by that patch, but I don't know if that's indicative enough of a good fix. |
| 20:44.26 | russellb | putnopvut: alrighty. |
| 20:44.26 | putnopvut | What do you mean by "corner cases"? |
| 20:44.44 | Corydon76-lap | snuff-away, eh? |
| 20:44.45 | russellb | when it's accessing data to log locking errors |
| 20:45.16 | snuff-away | just the user wanting a diff bug marshell thinking your not fast enough to respond? |
| 20:45.51 | Corydon76-lap | snuff-away, based on responses, it appears to be crashing within a TDS-specific thread |
| 20:46.25 | Corydon76-lap | so unless this is a case of memory corruption (not impossible), it's probably going to need to be addressed by the FreeTDS team |
| 20:46.25 | *** part/#asterisk-dev mog (n=mog@c-71-207-220-220.hsd1.al.comcast.net) |
| 20:46.46 | Corydon76-lap | but if he wants someone else, so be it |
| 20:47.03 | snuff-away | fair enough.. |
| 20:49.41 | *** join/#asterisk-dev mog (n=mog@c-71-207-220-220.hsd1.al.comcast.net) |
| 20:49.41 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 20:52.12 | russellb | putnopvut: have any idea what "cs" stands for in that patch? |
| 20:54.13 | putnopvut | critical section |
| 20:54.33 | putnopvut | (just a guess) |
| 20:54.40 | russellb | ah, yep |
| 20:55.10 | putnopvut | Yay Asterisk locked up!! |
| 20:55.41 | paravoid | yay! |
| 20:55.54 | ctooley | putnopvut, that's an awesome state of operation. |
| 20:56.15 | putnopvut | Yeah, I couldn't issue a core show locks either. The CLI was unresponsive. |
| 20:56.17 | elixer | "locked up" == "stable" |
| 20:56.23 | putnopvut | heh |
| 20:56.43 | paravoid | putnopvut: were you trying to lock it up? |
| 20:57.03 | putnopvut | no. the "yay" was sarcastic unfortunately. |
| 20:57.11 | paravoid | ah |
| 20:57.13 | paravoid | ouch. |
| 20:57.14 | putnopvut | I'm testing a patch I just wrote, and it locked up. |
| 20:57.37 | putnopvut | Hopefully, it's something wrong with the patch and I can correct it with no trouble. |
| 21:01.03 | bweschke | putnopvut: feature |
| 21:01.06 | bweschke | :-p |
| 21:02.20 | putnopvut | nice. |
| 21:03.49 | *** part/#asterisk-dev zerohalo (n=zeroHalo@pool-72-70-79-233.bstnma.east.verizon.net) |
| 21:03.56 | mvanbaak | hahahahaha |
| 21:03.59 | mvanbaak | omg |
| 21:04.02 | mvanbaak | vista++ |
| 21:04.25 | mvanbaak | dont use it when you copy files sometimes |
| 21:04.43 | mvanbaak | it will run out of memory and wont report that the file copy was unsuccesfull |
| 21:05.45 | mvanbaak | there's a fix, but you have to download it manually. it's not in ms update :) |
| 21:05.45 | paravoid | vista are the new windows me |
| 21:05.45 | mvanbaak | it's worse |
| 21:05.45 | putnopvut | Vista is ultra terrible. |
| 21:05.57 | paravoid | nope, can't get worse than ME |
| 21:06.03 | Qwell | yes it can |
| 21:06.03 | file | paravoid: yes you can... |
| 21:06.05 | putnopvut | Vista is seriously making my old college friends (not computer people at all) consider Linux. |
| 21:06.06 | paravoid | well, tbh, I have briefly seen vista |
| 21:06.21 | paravoid | but I remember ME with pain |
| 21:06.39 | elixer | i'd like people to remember me with pain |
| 21:06.55 | *** part/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 21:07.15 | d1mas | ME or me ? :) |
| 21:09.04 | putnopvut | pain is French for bread. |
| 21:09.08 | elixer | me |
| 21:09.10 | elixer | heh |
| 21:11.26 | paravoid | russellb: did you see my comment above for the backport of the tos/libcap patch to 1.4? |
| 21:11.33 | paravoid | (if not, that's essentialy it ;) |
| 21:11.52 | russellb | heh, no i didn't |
| 21:11.56 | russellb | but ... ok, heh |
| 21:11.56 | paravoid | right |
| 21:12.03 | paravoid | well, I was/am proposing |
| 21:12.07 | russellb | oh. |
| 21:12.18 | russellb | um, well, not into the official 1.4 branch, no |
| 21:12.38 | russellb | but i'm not going to stop you from doing it, heh |
| 21:12.40 | paravoid | it's simple enough and provides an important functionality |
| 21:12.43 | russellb | and if you do, i can throw it in my backports repo |
| 21:12.47 | paravoid | oh I already did |
| 21:12.55 | russellb | as are another 12390123 tiny features |
| 21:13.16 | paravoid | http://svn.debian.org/wsvn/pkg-voip/asterisk/trunk/debian/patches/tos-libcap?op=file&rev=0&sc=1 |
| 21:13.21 | russellb | which is why i'm trying to change our release policy dramatically for 1.6 :) |
| 21:13.26 | russellb | cool .. |
| 21:13.34 | paravoid | it's not exactly a new feature |
| 21:13.39 | paravoid | it *is* a bugfix |
| 21:14.02 | russellb | my mind can't multitask very well today |
| 21:14.07 | paravoid | I'm considering not being able to set the ToS when running as non-root as a bug |
| 21:14.12 | russellb | put it on mantis if you feel strongly about it |
| 21:14.15 | d1mas | Question 3: What is the reason of refusing loading dialplan where exist jump/goto to non-existent extension in some context? |
| 21:14.17 | russellb | and i'll address it later when i can think |
| 21:14.45 | paravoid | nah, I don't care that much (as I said, it's already backported for us) |
| 21:15.00 | paravoid | btw, any list of what bits have you backported? |
| 21:15.02 | paravoid | and where? :) |
| 21:15.17 | russellb | you know, there are actually some issues with distributing versions of asterisk that are patched ... |
| 21:15.26 | russellb | i'd have to check with kevin to be sure |
| 21:15.38 | russellb | but i think you can't distribute something called "asterisk" unless it is _exactly_ what we distribute |
| 21:16.09 | d1mas | you can distribute something *based* on asterisk :) |
| 21:16.57 | paravoid | argh |
| 21:16.58 | russellb | but you can't call it asterisk, if you do |
| 21:17.03 | paravoid | that smells like iceweasel :( |
| 21:17.13 | jsmith | You must call it --- IcePBX |
| 21:17.42 | russellb | paravoid: the details of the trademark policy are here ... http://www.digium.com/en/company/profile/trademarkpolicy.php |
| 21:17.51 | russellb | but i'm fairly certain i'm right |
| 21:17.53 | paravoid | I've read it |
| 21:17.57 | russellb | ok. |
| 21:18.04 | paravoid | I don't think that we're abusing your trademark |
| 21:18.10 | russellb | oh, no |
| 21:18.17 | paravoid | or hurting you |
| 21:18.19 | russellb | i don't imply that you are at all |
| 21:18.25 | paravoid | if anything, we're promoting you |
| 21:18.44 | paravoid | but yes, I think we are not in compliance of the above trademark policy |
| 21:19.12 | paravoid | and we can't be |
| 21:19.23 | paravoid | see iceweasel/icedove/iceape etc. |
| 21:19.43 | russellb | well, just making sure you were aware ... |
| 21:19.47 | russellb | i just remember it. |
| 21:19.48 | paravoid | I am |
| 21:19.54 | russellb | s/remember/remembered/ |
| 21:20.06 | file | trademarks are... interesting |
| 21:20.13 | paravoid | there was no reason to rename our package without getting a complain from you |
| 21:20.19 | russellb | heh, makes sense |
| 21:20.27 | paravoid | but if you do complain, we'd be forced to change the name |
| 21:20.39 | paravoid | I just hope that you don't :) |
| 21:20.58 | russellb | i wouldn't complain, until we get to where we disagree on a patchset |
| 21:21.21 | putnopvut | I won't, unless you distribute some hugely borked version. (which you won't do) |
| 21:22.18 | elixer | heh |
| 21:22.34 | russellb | paravoid: where do i see a list of patches on packages.debian.org ? |
| 21:22.50 | elixer | lots of "unless"s and "until"s in those stipulations :) |
| 21:22.59 | Qwell | except on Sundays |
| 21:23.15 | russellb | paravoid: we may have a problem with asterisk-bristuff ... |
| 21:23.28 | russellb | that is an invasive set of patches |
| 21:23.52 | Qwell | and has caused problems for us on mantis before... ;/ |
| 21:23.58 | russellb | yes. |
| 21:24.23 | Corydon76-lap | paravoid, if you add bristuff, just call it DisAsterisk |
| 21:24.34 | d1mas | my "Question 3" couple of screens above? anyone? :) |
| 21:24.36 | putnopvut | I think it's a matter of telling the people who have a problem to report to the package distrubitor instead of to the Asterisk team. |
| 21:26.04 | Corydon76-lap | d1mas, question didn't really make sense |
| 21:26.23 | d1mas | Corydon76-lap: why? |
| 21:26.51 | Corydon76-lap | d1mas, probably because the question wasn't translated correctly. ;-) |
| 21:27.48 | d1mas | to me question is pretty much Ok. At dialplan parsing time Asterisk just can NOT properly verify existence of extension (because there are DUNDi/realtime switches). But it refuses adding explicit GoTo |
| 21:27.49 | russellb | oh wow ... the set of patches applied to the regular asterisk package is huge, too |
| 21:27.55 | russellb | this conversation is going to have to go out of band. |
| 21:28.44 | d1mas | To me this check is dumb because I always can put two priorities: ext=123456 and jump${ext}@context |
| 21:28.47 | Corydon76-lap | d1mas, what refuses? |
| 21:28.56 | d1mas | I just can not say jump 123456@context |
| 21:29.24 | Corydon76-lap | uh, that's Goto(context,123456,1) |
| 21:30.55 | Corydon76-lap | So I'm thinking you just had the wrong syntax for Goto |
| 21:34.29 | d1mas | well. I was using "jump" everywhere not goto. Anyway it is working fine right now, so it is false alarm. But I had to twice change literal (like 123) in the jump to variable because asterisk refused to load ael saying this is not a valid extension. Can't reproduce now... |
| 21:35.17 | Corydon76-lap | jump? |
| 21:36.11 | d1mas | yes. I'm using AEL |
| 21:36.21 | d1mas | jump ext@context; |
| 21:36.45 | Corydon76-lap | Tell codefreeze |
| 21:40.35 | mvanbaak | paravoid == member of debian-voip ? |
| 21:41.20 | russellb | indeed |
| 21:42.33 | russellb | pq needs to stfu |
| 21:42.33 | mvanbaak | k |
| 21:42.33 | mvanbaak | eh ? |
| 21:42.33 | mvanbaak | hhmm |
| 21:42.33 | mvanbaak | cool |
| 21:42.41 | russellb | i shouldn't be able to hear them yelling from here |
| 21:42.46 | mvanbaak | iax2 show peers gave all my iax peers 4 times |
| 21:42.59 | russellb | :-p |
| 21:43.03 | russellb | that's hot. |
| 21:43.25 | russellb | mvanbaak: that's actually a very bad sign |
| 21:43.30 | russellb | every time? |
| 21:43.45 | mvanbaak | yeah, till I did a reload |
| 21:43.55 | mvanbaak | and now it acts normal again |
| 21:44.07 | russellb | hm |
| 21:44.07 | mvanbaak | if it happens again I'll yell and open ssh |
| 21:44.10 | russellb | let me know if it happens again |
| 21:44.24 | russellb | heh |
| 21:44.39 | mvanbaak | my ISP had some trouble |
| 21:44.57 | mvanbaak | I had pages and pages of: |
| 21:44.59 | mvanbaak | [2007-10-16 23:38:43] NOTICE[11265]: chan_iax2.c:8968 __iax2_poke_noanswer: Peer 'speakup03' is now UNREACHABLE! Time: 8168 |
| 21:45.10 | russellb | interesting |
| 21:45.11 | mvanbaak | [2007-10-16 23:42:17] NOTICE[11265]: chan_iax2.c:8968 __iax2_poke_noanswer: Peer 'speakup03' is now UNREACHABLE! Time: 549 |
| 21:45.30 | mvanbaak | reachable/unreachable/reachable...... |
| 21:45.33 | russellb | right |
| 21:45.36 | mvanbaak | over and over again for the whole night |
| 21:45.47 | mvanbaak | I lost track |
| 21:45.54 | mvanbaak | so I typed: iax2 show peers |
| 21:45.59 | mvanbaak | to see what was up and what was down |
| 21:46.09 | russellb | are you using realtime, perhaps? |
| 21:46.22 | mvanbaak | I was shocked to see 12 iax peers where normally I have 3 |
| 21:46.28 | mvanbaak | no, all static in config file |
| 21:46.34 | russellb | ok .. |
| 21:47.36 | mvanbaak | auth=rsa |
| 21:47.39 | mvanbaak | outkey set |
| 21:47.41 | mvanbaak | hostname set |
| 21:48.01 | mvanbaak | accountcode, amaflags set |
| 21:48.07 | mvanbaak | qualify=yes |
| 21:48.08 | mvanbaak | that's it |
| 21:49.27 | mvanbaak | if it happens again I wont touch anything |
| 21:49.47 | mvanbaak | only my pf.conf that's protecting the machines to let you in ;) |
| 21:49.52 | russellb | you can touch it |
| 21:49.56 | russellb | i'm not sure access to it will help |
| 21:50.04 | russellb | info about what was goign on with the system is helpful though |
| 21:50.07 | russellb | like you were already telling me |
| 21:50.19 | russellb | i'm just going to have to dig through the code to see how it is possible |
| 21:50.34 | mvanbaak | there were no calls |
| 21:50.45 | mvanbaak | and there were no calls in the hours before it happened |
| 21:50.55 | russellb | k |
| 21:50.56 | mvanbaak | before I went to bed I had 3 iax peers |
| 21:51.01 | russellb | just weird network issues |
| 21:51.05 | mvanbaak | yup |
| 21:51.11 | russellb | k |
| 21:51.13 | codefreeze | d1mas: what's this about a problem with jump? |
| 21:51.24 | mvanbaak | ISP was having issues, and I was leeching 12 torrents on another machine |
| 21:51.55 | mvanbaak | had to make sure to have all Heroes episodes in HD quality ;) |
| 21:52.19 | d1mas | mvanbaak: nothing I can reproduce at the moment. But I can swear 'ael reload' refused to load dialplan when I had jumps to nonexistent extensions... |
| 21:52.30 | d1mas | sorry it was to codefreeze |
| 21:52.46 | mvanbaak | rdr pass on $irc from d1mas -> codefreeze |
| 21:53.28 | mvanbaak | russellb: trying to regenerate bad latency and stuff |
| 21:53.37 | russellb | cool |
| 21:53.44 | mvanbaak | I found episode 1-4 season2 of heroes in HD |
| 21:53.53 | mvanbaak | leeching them now with bittorrent |
| 21:54.02 | mvanbaak | upload is maxed now |
| 21:54.11 | elixer | mvanbaak: that is against copyright law |
| 21:54.15 | elixer | heh |
| 21:54.24 | elixer | i'm telling! |
| 21:54.26 | mvanbaak | elixer: but it makes a kickass latency trouble generator |
| 21:54.38 | mvanbaak | elixer: I'm downloading to /dev/null |
| 21:54.41 | elixer | haha |
| 21:54.50 | mvanbaak | just to fill my modem queues and stuff |
| 21:54.56 | mvanbaak | YEAH RIGHT |
| 21:55.12 | mvanbaak | rm /dev/null && mkdir /dev/null |
| 21:55.13 | mvanbaak | ;) |
| 21:56.03 | mvanbaak | i find popular torrents a nice way to test traffic shaping |
| 21:58.57 | mvanbaak | russellb: have fun browsing code, I'm going to browse my bed |
| 21:59.48 | mvanbaak | latero all |
| 22:27.40 | *** join/#asterisk-dev sb_mx (n=sb_mx@201.155.80.181) |
| 22:33.39 | *** join/#asterisk-dev ZX81 (n=matt@202.49.106.158) |
| 22:39.05 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 22:50.43 | *** part/#asterisk-dev sb_mx (n=sb_mx@201.155.80.181) |
| 23:07.43 | russellb | anybody mind me changing the default featuredigittimeout from 500ms to 1000ms? |
| 23:07.49 | russellb | i always thought 500ms was a bit ridiculous |
| 23:10.42 | Netgeeks | hey is file around? |
| 23:10.51 | file | I am. |
| 23:11.19 | Netgeeks | what was the option that allowed a spying channel to hear while read is playing a file? |
| 23:11.29 | Netgeeks | you told me this once before but i forgot |
| 23:11.53 | file | there's no option for that ... it should just work I do believe |
| 23:12.00 | Netgeeks | a config file option ha to be set? |
| 23:12.31 | Netgeeks | sorry, not read, record |
| 23:12.47 | file | to transmit silence? |
| 23:12.51 | Netgeeks | yes |
| 23:13.06 | file | transmit_silence_during_record in asterisk.conf |
| 23:13.12 | file | options section |
| 23:13.23 | putnopvut | Is MixMonitor dependent on any external program for mixing the audio? |
| 23:13.26 | Netgeeks | thanks |
| 23:13.31 | file | putnopvut: no |
| 23:13.40 | putnopvut | cool, more reasons to get rid of monitor-join then. |
| 23:22.50 | russellb | putnopvut: file codefreeze Corydon76-dig Corydon76-lap kpfleming Qwell ... signage of -addons tarballs please |
| 23:23.25 | Qwell | done |
| 23:23.28 | Qwell | :P |
| 23:24.40 | file | yes sir |
| 23:25.58 | file | done |
| 23:28.05 | *** join/#asterisk-dev elixer (n=elixer@65.207.74.18) |
| 23:31.59 | putnopvut | signed. |
| 23:33.45 | d1mas | russellb: btw, we changed it to 1500. People are slow :) |
| 23:33.54 | russellb | heh, ok |
| 23:36.04 | russellb | putnopvut: file codefreeze Corydon76-dig Corydon76-lap kpfleming Qwell ... if you haven't signed yet, don't worry about it ... i got a few, that's enough |
| 23:53.01 | russellb | putnopvut: ping |
| 23:55.45 | putnopvut | pang |
| 23:58.04 | russellb | the priv msg was all |
| 23:58.21 | putnopvut | Cool. I'm heading out. |