| 00:04.30 | snuff-work | :) |
| 00:04.36 | blitzrage | codefreeze: !!! |
| 00:08.33 | codefreeze | blitzrage: hi! |
| 00:08.39 | blitzrage | hi! |
| 00:09.05 | *** join/#asterisk-dev mog (i=mog@nat/digium/x-8173594dedc301f2) |
| 00:09.05 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 00:33.27 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 01:07.49 | *** join/#asterisk-dev RoyK (n=roy@ip-26-2-149-91.dialup.ice.no) |
| 01:13.38 | *** join/#asterisk-dev RoyK (n=roy@ip-26-2-149-91.dialup.ice.no) |
| 01:16.07 | ctooley | Is there a "direction" in a SIP channel? ie Can I tell if it's an incoming call versus outgoing call somehow? |
| 01:31.23 | *** join/#asterisk-dev mog (n=mog@c-68-62-172-83.hsd1.al.comcast.net) |
| 01:31.23 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 02:02.39 | blitzrage | ctooley: I'd just think you could only do something like that with a channel variable or something... ? |
| 02:02.59 | ctooley | blitzrage, I think it's the "SIP_OUTGOING" flag in chan_sip.c |
| 02:03.36 | blitzrage | hrmmm... interesting |
| 02:03.38 | blitzrage | and how would you use that? |
| 02:10.08 | ctooley | I think... "if(SIP_OUTGOING) { ast_log(NOTIFY, "this is an outgoing call"); }" |
| 02:10.13 | ctooley | in the C code |
| 02:10.43 | *** join/#asterisk-dev moy (n=moyhu@189.169.152.237) |
| 02:10.56 | blitzrage | hrmmm... interesting |
| 02:11.26 | ctooley | at least I really really hope so |
| 02:16.06 | blitzrage | hehehe |
| 02:16.40 | ctooley | I'm hoping to be able to get my version of chan_sip to ignore call-limit on outgoing calls |
| 02:18.46 | ctooley | YES!!! |
| 02:19.26 | ctooley | NO!!! |
| 02:21.04 | ctooley | It now ignores call-limit for outgoing calls, but unfortunately ignores it for incoming too |
| 02:28.47 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177584269.dsl.bell.ca) |
| 02:30.13 | *** join/#asterisk-dev RoyK (n=roy@ip-26-2-149-91.dialup.ice.no) |
| 03:02.13 | Damin | xit |
| 03:09.29 | *** join/#asterisk-dev jsmith (n=jsmith@68.247.223.142) |
| 03:09.29 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 03:15.42 | *** join/#asterisk-dev IgorG (n=FeedomPa@195.162.32.126) |
| 03:30.31 | blitzrage | Damin: +e! |
| 03:30.44 | Qwell | +/! |
| 04:20.23 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 04:20.23 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 04:27.36 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 05:25.40 | *** join/#asterisk-dev wedhorn (n=nnnwedho@dsl-58-6-89-11.act.westnet.com.au) [NETSPLIT VICTIM] |
| 05:37.35 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.8.149) |
| 05:58.29 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-159.bredband.comhem.se) |
| 06:10.55 | *** join/#asterisk-dev wedhorn (n=nnnwedho@dsl-58-6-89-11.act.westnet.com.au) |
| 06:29.51 | *** join/#asterisk-dev CunningPike (n=arodgers@S010600095b33697f.vc.shawcable.net) |
| 06:34.07 | *** join/#asterisk-dev wedhorn (n=nnnwedho@dsl-58-6-89-11.act.westnet.com.au) [NETSPLIT VICTIM] |
| 06:57.13 | *** join/#asterisk-dev snuff-away (n=nffot@220-253-158-108.VIC.netspace.net.au) |
| 07:15.12 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 07:15.15 | *** join/#asterisk-dev mvanbaak (n=mafkees@vanbaak.xs4all.nl) |
| 07:16.59 | *** join/#asterisk-dev blitzrage (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 07:16.59 | *** mode/#asterisk-dev [+o blitzrage] by ChanServ |
| 07:19.12 | *** join/#asterisk-dev mog (n=mog@c-68-62-172-83.hsd1.al.comcast.net) |
| 07:19.12 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 07:26.25 | *** join/#asterisk-dev dlynes (n=chatzill@d154-20-45-103.bchsia.telus.net) |
| 07:32.57 | snuff-work | mmm.. Corydon76-dig think i might have found why it was not using the solaris-compat file going to test now |
| 07:54.14 | snuff-work | mm interesting nothing includes the solaris-compat routines so its basically dead code though that sys/queue.h has a lotof info |
| 08:00.49 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 08:00.49 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 08:11.52 | *** join/#asterisk-dev blitzrage (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 08:11.52 | *** mode/#asterisk-dev [+o blitzrage] by ChanServ |
| 08:31.53 | *** join/#asterisk-dev tzafrir (n=tzafrir@62.90.10.53) |
| 08:31.53 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:36.12 | *** join/#asterisk-dev snuff-away (n=nffot@220-253-158-108.VIC.netspace.net.au) |
| 08:36.12 | *** join/#asterisk-dev wedhorn (n=nnnwedho@dsl-58-6-89-11.act.westnet.com.au) |
| 09:02.25 | *** join/#asterisk-dev agx (n=AGX@88.34.216.63) |
| 09:06.06 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-159.bredband.comhem.se) |
| 09:44.50 | *** join/#asterisk-dev RoyK (n=roy@80.239.107.70) |
| 10:00.39 | *** join/#asterisk-dev snuff-away (n=nffot@220-253-158-108.VIC.netspace.net.au) |
| 10:00.39 | *** join/#asterisk-dev wedhorn (n=nnnwedho@dsl-58-6-89-11.act.westnet.com.au) [NETSPLIT VICTIM] |
| 10:45.16 | *** join/#asterisk-dev snuff-away (n=nffot@220-253-158-108.VIC.netspace.net.au) |
| 10:45.16 | *** join/#asterisk-dev wedhorn (n=nnnwedho@dsl-58-6-89-11.act.westnet.com.au) [NETSPLIT VICTIM] |
| 11:07.31 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:13.41 | *** join/#asterisk-dev snuff-away (n=nffot@220-253-158-108.VIC.netspace.net.au) |
| 11:13.41 | *** join/#asterisk-dev wedhorn (n=nnnwedho@dsl-58-6-89-11.act.westnet.com.au) [NETSPLIT VICTIM] |
| 11:31.05 | *** join/#asterisk-dev _ys (n=yuri@80.70.236.69) |
| 12:08.08 | *** join/#asterisk-dev snuff-away (n=nffot@220-253-158-108.VIC.netspace.net.au) |
| 12:08.08 | *** join/#asterisk-dev wedhorn (n=nnnwedho@dsl-58-6-89-11.act.westnet.com.au) [NETSPLIT VICTIM] |
| 12:27.02 | *** join/#asterisk-dev ksteward (n=ksteward@71.174.94.169) |
| 12:27.19 | *** part/#asterisk-dev ksteward (n=ksteward@71.174.94.169) |
| 12:34.02 | *** join/#asterisk-dev snuff-away (n=nffot@220-253-158-108.VIC.netspace.net.au) |
| 12:34.02 | *** join/#asterisk-dev wedhorn (n=nnnwedho@dsl-58-6-89-11.act.westnet.com.au) [NETSPLIT VICTIM] |
| 12:45.51 | caio1982 | I've found that sip show registry limits the username output in CLI to 12 chars, when it actually accepts a lot more (char username[256]; /*!< Username */), is it accetable to change the ast_cli to snprintf for this line output? snprintf is already used in many 'sip show' commands anyway, just to avoid a FORMAT define |
| 12:48.22 | caio1982 | the same occurs with sip show users, which only outputs 25 chars |
| 12:50.56 | caio1982 | is it too early in huntsville? |
| 12:51.04 | caio1982 | :) |
| 13:07.05 | *** join/#asterisk-dev Laureano (n=Laureano@200.59.172.38) |
| 13:09.44 | *** join/#asterisk-dev eliel (n=eliel@200.59.172.38) |
| 13:25.39 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) |
| 13:49.51 | *** join/#asterisk-dev ctooley (n=ctooley@doc-72-47-33-80.maryville.mo.cebridge.net) |
| 13:53.21 | caio1982 | anyway, that solved the issue mentioned: http://caio.ueberalles.net/asterisk/sip_show_lengths.diff |
| 14:00.59 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 14:00.59 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 14:26.04 | *** join/#asterisk-dev jsmith (n=jsmith@68.247.223.142) |
| 14:26.04 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 14:41.30 | tzafrir | kpfleming, here? |
| 14:42.02 | file | not yet. |
| 15:00.33 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 15:00.33 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 15:15.40 | *** join/#asterisk-dev oej (n=olle@193.126.30.214) |
| 15:15.40 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:27.59 | oej | We need a way to mark bugs/patches as experimental. |
| 15:28.03 | oej | Or just close them. |
| 15:28.13 | oej | I have several things that disturb my view in the sip category |
| 15:28.42 | oej | M11372 |
| 15:28.43 | MuffinMan | [new] [Asterisk] Channels/chan_sip/General 0011372: Dial option L(limit in ms) is not working reported by falves11 http://bugs.digium.com/view.php?id=11372 |
| 15:28.45 | oej | Someone? |
| 15:28.48 | oej | Please! |
| 15:30.57 | eliel | you need a tester? |
| 15:31.08 | caio1982 | is there a reason for SIP allowing 255 chars peers and IAX allowing just 80-length peers? |
| 15:31.40 | _ys | "experimental bugs" :) |
| 15:32.36 | oej | caio1982: I don't know. We're more open in SIP I guess |
| 15:33.17 | caio1982 | oej: ok :) |
| 15:33.53 | eliel | we could be more open in iax2 allowing peers of 81 chars... |
| 15:34.05 | oej | IAX2 should have one-bit device names |
| 15:34.34 | *** join/#asterisk-dev iulius (n=iulius@mail1.technologieshq.com) |
| 15:35.40 | eliel | thats why iax2 use less bandwith :-) |
| 15:36.18 | caio1982 | haha |
| 15:44.15 | caio1982 | eliel: don't you think the patch in 11464 solves the issue? just saw you comment after attaching it |
| 15:45.43 | eliel | I think that truncating the names on the cli isn't a problem at all, it is just a way of making the command more clean.. if we let print names bigger the command will show on a 24 chars console a bit complicated.. |
| 15:46.24 | eliel | but i also think that manager should show all the info without truncating it, so if you need a sip show registry 'verbose' we could add a manager action to solve it... |
| 15:47.12 | eliel | I didn't run the attached patch, I will try it and see how it looks the cli command with bigger names.. |
| 15:47.52 | eliel | it is just my opinion.. |
| 15:48.03 | caio1982 | eliel: they look awful because it breaks tabbing/fixed spacing in some CLI headers, but still it shows all information available... though I understand you point :/ |
| 15:48.24 | caio1982 | I think you're right, the problem is just the lack of output from real information, but... who am i? :) |
| 15:49.18 | De_Mon | why hasn't the meetmecount app been converted to a function? |
| 15:50.26 | caio1982 | eliel: just for the record, the output gets awful for very long names, the minimum char length is still respected |
| 15:52.29 | eliel | caio1982: ok, I think a more experienced developer could reply this better than me... |
| 15:57.59 | Corydon76-dig | caio1982: We will NOT adapt CLI commands for manager usage. Create a native Manager command, instead. |
| 15:59.06 | caio1982 | Corydon76-dig: I know corydon, I just wanted to display the full username value in CLI, the reporter wants it in manager, which is another story, but the patch solves both |
| 15:59.19 | caio1982 | i dont want to adapt cli for the too... |
| 16:00.56 | jsmith | caio1982: I think that was the same idea behind the "sip show channels concise" patch a few weeks ago |
| 16:01.08 | jsmith | The reporter wanted to see the untruncated channel name from the CLI |
| 16:01.25 | caio1982 | ops, I didnt follow this thread |
| 16:01.57 | caio1982 | what I meant is: usernames can be 255 but CLI shows 12, 25 or 10 chars lenght, never 255, then some people might think it's buggy when it's not |
| 16:02.17 | Corydon76-dig | I think it's quite clear that the CLI output is intentional |
| 16:02.19 | caio1982 | I'll see that thread, jsmith, thanks for pointing |
| 16:03.05 | Corydon76-dig | I'm not really sure why usernames are set that long. It does not serve any functional purpose |
| 16:03.44 | Corydon76-dig | 12 alphanumerics are enough to represent every human being alive on the planet at any given time |
| 16:04.03 | Corydon76-dig | and then some |
| 16:04.18 | caio1982 | users^Wclients sucks, we know :) |
| 16:04.41 | jsmith | SIP/polycom -- there's eleven characters right there (assuming I know how to count) |
| 16:05.07 | jsmith | I'd be OK with twelve, if the "SIP/" on the front didn't count against the twelve |
| 16:06.23 | caio1982 | but then you'll need to decrease it in chan_sip.c after convincing oej , because it reads username[256] by now |
| 16:07.14 | oej | caio1982: The CLI lists do cut off a lot of stuff |
| 16:07.24 | oej | "sip show user" and "sip show peer" should not cut off strings |
| 16:07.25 | *** join/#asterisk-dev ManxPower (n=manxpowe@170.sub-70-221-241.myvzw.com) |
| 16:07.26 | *** join/#asterisk-dev IgorG (i=FeedomPa@host-90-188-188-119.pppoe.omsknet.ru) |
| 16:07.34 | jsmith | No, I'm saying I'm OK with the CLI only showing 16 (including the SIP/), but 12 is a bit short |
| 16:07.50 | jsmith | Internally, I could care less if SIP itself allows 255 character peer names |
| 16:08.01 | oej | which cli command are you guys discussing? |
| 16:08.05 | caio1982 | oej: it's cuting right now |
| 16:08.18 | oej | which one? |
| 16:08.19 | caio1982 | oej: sip show peers, users and registry |
| 16:08.42 | caio1982 | try configuring a user with 30 chars |
| 16:08.54 | oej | yes, all of those truncate to fit a screen |
| 16:09.02 | jsmith | And don't forget "sip show channels" |
| 16:09.04 | oej | That's part of the purpose, we don't want line-wraps |
| 16:09.24 | caio1982 | hmm |
| 16:09.26 | oej | If you want full data, run "sip show channel", "sip show peer" and "sip show user" or the manager |
| 16:09.35 | oej | We don't have registry in the manager though. |
| 16:09.39 | oej | That needs to be fixed. |
| 16:10.00 | jsmith | "sip show channels" cuts the channel name, which sometimes makes it hard to type "sip show channel blah" on the correct channel |
| 16:10.26 | oej | Yes |
| 16:10.35 | oej | But we have tab completion in "sip show channel blah" |
| 16:11.34 | oej | The caller ID is a bit too much truncated. So what other field do we kill? |
| 16:12.28 | oej | Hmm IP address 15 chars |
| 16:12.53 | oej | 3+3+3+3+3 is fifteen, but rarely used fully |
| 16:13.00 | *** join/#asterisk-dev mog (i=mog@nat/digium/x-01c9c2aa9f3b284c) |
| 16:13.00 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 16:13.08 | *** join/#asterisk-dev putnopvut (i=putnopvu@nat/digium/x-d8c16df9bc9a9188) |
| 16:13.08 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 16:13.46 | oej | The sequence numbers is not really needed. Anyone that needs sequence numbers in "sip show channels" - speak up NOW! |
| 16:14.01 | caio1982 | rofl |
| 16:14.10 | jsmith | Down with sequence numbers! |
| 16:14.14 | jsmith | Kill them! |
| 16:14.34 | ManxPower | But I like sequins! |
| 16:14.44 | ManxPower | Oh, sequence. Nevermind. |
| 16:14.44 | caio1982 | ManxPower: you meant penguins, right? |
| 16:14.54 | Corydon76-dig | oej: I think you're missing the point. The point is that for automated tasks, a native Manager interface is needed, not adapting the CLI to automated processes |
| 16:14.55 | jsmith | ManxPower: Only if they're on dresses? |
| 16:15.04 | ManxPower | 8-) |
| 16:15.07 | jsmith | Corydon76-dig: I think we all agree there |
| 16:15.28 | ManxPower | I just fired a cutomser. |
| 16:15.52 | Corydon76-dig | I'd be happy if "Action: Command" went away entirely, but I'm not holding my breath |
| 16:16.27 | oej | Corydon76: I fully agree. But jsmith pointed out another problem with "sip show channels" that I am trying to fix. So in this case, you missed the point :-) |
| 16:17.05 | jsmith | Corydon76-dig: I guess I"m just the opposite on that... I wish "Action: Command" would completely replace the CLI |
| 16:17.17 | jsmith | Corydon76-dig: And then we'd have a good solid remote CLI capability :-) |
| 16:17.32 | oej | He he. If we marked "Action: Command" as deprecated we would propably get LOTS of manager patches in the bug tracker. |
| 16:17.35 | eliel | Corydon76-dig: I agree about deprecating Action: Command |
| 16:17.38 | jsmith | Something like: |
| 16:17.42 | jsmith | Action: Command |
| 16:17.44 | eliel | oej: nice :-) |
| 16:17.47 | jsmith | Command: sip show peers |
| 16:17.52 | jsmith | Output: Human |
| 16:17.58 | oej | Hmm. |
| 16:18.04 | oej | Output: Inhuman |
| 16:18.04 | jsmith | (or Output: computer) |
| 16:18.09 | jsmith | Sure! |
| 16:18.11 | jsmith | Inhuman it is! |
| 16:18.13 | Qwell | jsmith: with something we discussed, that won't be necessary |
| 16:18.24 | jsmith | Qwell: Oh? We'll teach everyone to read XML? |
| 16:18.30 | Qwell | exactly! |
| 16:18.30 | oej | Ok, no one needs the cseq in "sip show channels" - it's going away. |
| 16:18.33 | oej | XML is HUMAN! |
| 16:18.45 | oej | ASN.1 is inhuman in every aspect. |
| 16:18.55 | Qwell | so is SIP |
| 16:18.56 | jsmith | oej: You're preaching to the choir... you forget I wrote a book in XML (in vim!) |
| 16:19.03 | Qwell | IAX2 is more readable by humans than SIP ;) |
| 16:19.35 | oej | Qwell: Man oh man. You're in for a huge discussion. I need to go back to teaching for a while more. Lab's over. |
| 16:19.40 | Qwell | :) |
| 16:19.50 | jsmith | oej: We'll carry on the discussion while you're gone |
| 16:21.43 | oej | In you guys I trust... |
| 16:21.49 | *** join/#asterisk-dev _ys (n=yuri@80.70.236.69) |
| 16:24.27 | tzafrir | Corydon76-dig, well, Action: Command is also used to perform actions, not only provide information |
| 16:25.05 | jsmith | tzafrir: Exactly... like "Command: restart when convenient" |
| 16:25.24 | Qwell | Action: Restart |
| 16:25.27 | Qwell | When: Convenient |
| 16:26.21 | jsmith | Qwell: There is no restart action... feel free to write one! |
| 16:26.53 | jsmith | Qwell: (at least in 1.4 -- trust me, I've probably stared at the list of manager commands longer than anyone else in this chat room) |
| 16:27.00 | Qwell | not in trunk either |
| 16:27.55 | tzafrir | It would help to provide better permissions system |
| 16:28.03 | jsmith | tzafrir: Definitely! |
| 16:28.23 | jsmith | Alright, I think it's time we officially stick a flag in the ground and say "It's time for Manager 3.0!" |
| 16:28.46 | De_Mon | Why is MeetMeCount() still an app instead of a function like almost everything else was converted |
| 16:29.08 | Qwell | De_Mon: I imagine because nobody has changed it |
| 16:29.12 | tzafrir | what permissions, though? |
| 16:29.32 | jsmith | De_Mon: Because most programmers are lazy? |
| 16:29.33 | tzafrir | I'm still unhappy with the fact that "call" is so omnipotent |
| 16:29.34 | file | plus MeetMeCount plays back the count |
| 16:29.41 | file | it doesn't return it via setting a variable |
| 16:29.45 | Qwell | file: audio? |
| 16:29.46 | jsmith | Ah! |
| 16:29.50 | De_Mon | it does audio?>?? |
| 16:29.52 | jsmith | So it's really SayMeetMeCount() |
| 16:29.53 | Qwell | that would explain it then |
| 16:30.10 | De_Mon | dang, how did I miss that |
| 16:30.13 | Qwell | SayDigits(${MEETME(count,1234)}) |
| 16:30.13 | Qwell | :D |
| 16:30.16 | jsmith | While we're ripping the guts out of Manager, let's rename all the applications as well |
| 16:30.18 | De_Mon | well a variable is optional |
| 16:30.37 | De_Mon | MeetMeCount(conf|[var]) plays audio and stores result in var |
| 16:30.59 | Qwell | "plays audio" - that's so descriptive |
| 16:31.19 | De_Mon | "there are currently <count> members in the conference" I bet |
| 16:33.17 | putnopvut | jsmith: awesome idea! |
| 16:33.59 | Corydon76-dig | jsmith: good choice |
| 16:34.13 | jsmith | Somebody's gotta do it |
| 16:34.22 | Corydon76-dig | jsmith: who's teaching this week? |
| 16:34.34 | jsmith | Corydon76-dig: Nobody that I know of... I'll be back there next week |
| 16:34.52 | Corydon76-dig | in Miami |
| 16:35.14 | Corydon76-dig | jsmith: I'll bring my 2nd edition and you can sign that one |
| 16:35.25 | jsmith | Corydon76-dig: Fair enough |
| 16:43.03 | *** join/#asterisk-dev russellb (i=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 16:43.03 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 16:45.34 | oej | When did background start to need waitexten to react to dtmf? |
| 16:46.56 | *** join/#asterisk-dev Juggie (n=Juggie@CPE001601df17fb-CM001a6682d7b6.cpe.net.cable.rogers.com) |
| 16:47.54 | Simon-- | oej: autofallthrough=no ? |
| 16:48.11 | oej | Could that be the difference? |
| 16:48.18 | oej | Something changed in 1.4 |
| 16:49.39 | *** join/#asterisk-dev flujan (n=flujan@200-160-115-020.static.spo.ctbc.com.br) |
| 16:49.55 | jsmith | oej: It shouldn't... |
| 16:50.01 | jsmith | oej: If it does, it's a bug |
| 16:50.17 | oej | It must be. I've used the same lab for two years, and it doesn't work in 1.4 |
| 16:51.03 | jsmith | Now, after the sound is done playing, you'll need a WaitExten if you want to continue waiting for input from the caller |
| 16:51.16 | jsmith | (unless you turn off auto-fallthrough) |
| 16:51.28 | oej | And it has a separate timeout, not the responsetimeout or digittimeout |
| 16:51.36 | oej | I guess the digit-timeout still applies though |
| 16:51.50 | jsmith | oej: The response timeout is used if you don't specify any arguments to WaitExten() |
| 16:52.09 | jsmith | exten => 123,1,Background(menu) |
| 16:52.17 | jsmith | exten => 123,n,WaitExten() |
| 16:55.00 | tzafrir | kpfleming, here? |
| 16:55.09 | _ys | jsmith as documented here: http://www.voip-info.org/wiki/index.php?page=Asterisk+cmd+BackGround , WaitExten() is unneeded. that wrong? |
| 16:55.23 | kpfleming | tzafrir: yep |
| 16:55.40 | _ys | jsmith ah |
| 16:55.52 | _ys | jsmith "To continue waiting for digits after this application has finished playing files, the WaitExten application should be used" hm |
| 16:55.56 | tzafrir | some smaller technical issues: |
| 16:56.32 | jsmith | _ys: Yes, that's correct, as long as autofallthrough is on (which it now defaults to) |
| 16:56.36 | tzafrir | the Bus ID field you have added is basically: "bus type, bus number, device number" |
| 16:56.44 | tzafrir | This is not such a good idea for USB: |
| 16:56.52 | kpfleming | i didn't add a Bus ID field |
| 16:57.36 | tzafrir | you indeed have a bus ID and a device ID for each device. But the device ID is rather random: it changes every time you unplug / plug the device |
| 16:57.54 | kpfleming | no i did not... i added a 'location' field, which can contain anything the driver wants to put there |
| 16:58.13 | kpfleming | your USB drivers can leave it empty, or put something that makes sense for USB |
| 16:59.16 | tzafrir | we already have something that makes sense: |
| 16:59.56 | tzafrir | 'man zaptel_hardware' to see the sample output of zaptel_hardware |
| 17:00.18 | tzafrir | As you can see, we have a "connector" field |
| 17:02.37 | tzafrir | so if this is "anything", there is basically no hope in making it actually parsable |
| 17:02.53 | kpfleming | it's not supposed to be parseable, that's why it is in text format |
| 17:03.16 | kpfleming | the same reason i added 'lboname'... some tools want to just know what the information is, not have the raw details |
| 17:04.25 | kpfleming | have machine parseable information will be the job of sysfs, as you have already proposed |
| 17:04.51 | tzafrir | kpfleming, well, you can try |
| 17:04.52 | kpfleming | these changes were designed to just expose information that the drivers already had in the simplest possible way so that users could see them and the GUI could use them |
| 17:05.11 | kpfleming | i plan on updating zttool to also use this information, so that the user can see which card zttool is referring to more easily |
| 17:05.22 | kpfleming | but it's not intended for use by tools to parse and configure things |
| 17:06.05 | tzafrir | The fact is that I could deduce TE/NT information from PRI and BRI spans of zapbri, Sangoma, Rhino and of ours. Just not from Digium's. |
| 17:06.37 | tzafrir | Why not make life easy for users who don't want to hack C code? |
| 17:07.21 | Qwell | users who don't want to write code wouldn't be parsing it |
| 17:07.22 | ManxPower | It was hard to write, it should be hard to understand! |
| 17:07.34 | Qwell | ManxPower: what was that from? |
| 17:07.48 | Qwell | I seem to recall it being a comment in some code somewhere, or something |
| 17:08.33 | jsmith | That's what I was told when I first tried to use Asterisk |
| 17:08.49 | jsmith | "If you can't read the source code and figure it out yourself, you don't deserve to be using Asterisk" |
| 17:09.09 | kpfleming | i don't understand... haven't i already said that i agree 1000% percent with exposing this information in sysfs? what I merged today does not impact that all, it's just a quick fix to an immediate problem that needs to be solved |
| 17:09.10 | tzafrir | Those are quite big changes. Let's just think about them for a while and not just rush them to release, OK? |
| 17:09.27 | kpfleming | and there are no TE/NT modes for PRI, so i don't know what you mean there |
| 17:09.57 | kpfleming | what are you referring to as a 'big change'? |
| 17:10.43 | tzafrir | kpfleming, check out how both zapconf (using zaptel-perl) and genzaptelconf (in clunky shell code) decide if a span is TE or NT |
| 17:10.56 | tzafrir | The sane default is TE |
| 17:11.07 | kpfleming | what does that have to do with what i committed today? |
| 17:11.21 | tzafrir | (good for at least 75% of the users) |
| 17:11.37 | *** join/#asterisk-dev RoyK (n=roy@sbs.hardrockcafe.no) |
| 17:12.57 | tzafrir | It is yet another time when I suddenly see see some surprising code in Zaptel |
| 17:13.16 | kpfleming | and it's of very low impact, and doesn't affect any existing users |
| 17:13.42 | kpfleming | don't ascribe any sinister purpose or 'master plan' to it, it was just a quick way to get some information exposed via means that were already available |
| 17:13.46 | tzafrir | It's not low impact: it forces every driver that needs to be configured with the asterisk-gui to be modified |
| 17:13.57 | kpfleming | and all of them are done |
| 17:14.10 | kpfleming | except for people who have extended the gui |
| 17:14.12 | tzafrir | There are two of those under xpp/ (OK, only one of them actuvely used) |
| 17:14.34 | kpfleming | and the gui has not been released yet, and is still undergoing massive changes on a frequent basis, so developers working with the GUI have to be prepared for this |
| 17:14.46 | kpfleming | and the changes in the driver are no more than a few lines |
| 17:15.02 | kpfleming | i'd be happy to make them if you want me to, i just didn't think about it yesterday |
| 17:15.43 | tzafrir | I have also had some issues with the approach used by ztscan several times in the past (monthes ago) |
| 17:15.52 | tzafrir | And was answered that "no way" |
| 17:16.14 | russellb | huh? |
| 17:16.15 | tzafrir | On our version of the asterisk-gui we simply disable zapscan |
| 17:16.19 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 17:17.06 | tzafrir | Because it's trivial to implement in a better and saner way |
| 17:17.44 | tzafrir | We'll now have to see what about ztscan |
| 17:25.40 | kpfleming | well of course you are free to do that |
| 17:25.57 | kpfleming | zapscan was nearly useless, and the combination of zapscan and the old ztscan was worse |
| 17:26.33 | *** join/#asterisk-dev blitzrage (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 17:26.33 | *** mode/#asterisk-dev [+o blitzrage] by ChanServ |
| 17:31.03 | *** join/#asterisk-dev yannj_fr (n=yannj_fr@APuteaux-152-1-18-82.w82-120.abo.wanadoo.fr) |
| 17:34.56 | *** join/#asterisk-dev mav3rick (n=t0m@trankil.biz) |
| 17:38.36 | tzafrir | what happens when you try to run ztscan with an older version of zaptel? |
| 17:38.51 | Qwell | it's in zaptel now, isn't it? |
| 17:39.26 | kpfleming | yes it is |
| 17:39.36 | Qwell | then maybe I don't understand the question |
| 17:40.01 | kpfleming | and if you try to run it with an older version of zaptel it will fail gracefully because the new ioctl number won't be supported by the older version of zaptel |
| 17:42.24 | tzafrir | hmm... why does it write the totalspans in the output? |
| 17:42.31 | tzafrir | Anybody uses that count? |
| 17:42.53 | tzafrir | This can be a mess if someoone needs to manually edit that file |
| 17:43.05 | tzafrir | (fonts.dir, anybody?) |
| 17:43.14 | kpfleming | it doesn't create a file |
| 17:43.24 | kpfleming | it generates output for a tool to parse, so there is no 'manual editing' |
| 17:43.24 | tzafrir | its output |
| 17:43.51 | tzafrir | if I want to manipulate that output? |
| 17:44.00 | tzafrir | remove one span? |
| 17:44.03 | kpfleming | then manipulate it |
| 17:44.07 | tzafrir | The count will be wrong |
| 17:44.19 | kpfleming | then fix the count, or change your gui to not care about the count |
| 17:44.29 | kpfleming | or maybe the gui doesn't care and i just didn't remove it because i didn't spend the time |
| 17:45.17 | tzafrir | As for my previous question: when run on a previous version of zaptel, the ioctl luckly fails |
| 17:45.20 | tzafrir | So no problems |
| 17:45.30 | kpfleming | it's not luck, it's by design |
| 17:45.37 | kpfleming | that's how ioctl interface changes are supposed to work |
| 17:48.02 | tzafrir | But it means we have to rebuild Asterisk, right? |
| 17:48.26 | kpfleming | no |
| 17:48.35 | kpfleming | just like when this happened the last time |
| 17:48.40 | kpfleming | existing binaries are totally unaffected |
| 17:48.58 | tzafrir | Asterisk uses the same ioctl, right? |
| 17:49.05 | kpfleming | yes |
| 17:49.19 | kpfleming | well, one CLI command in chan_zap does to be specific |
| 17:52.47 | kpfleming | tzafrir: totalspans (and the entire [general] section) are gone |
| 17:55.32 | eliel | ups... compilation is broken due to global_datastores.c I think.. |
| 17:55.49 | Qwell | eliel: typo in .o filename? Already fixed. |
| 17:57.56 | eliel | Qwell: great. Done. |
| 17:58.08 | putnopvut | Yeah, that was my mistake. |
| 17:58.19 | Qwell | woah, something is unhappy though |
| 17:58.44 | Qwell | very much so, actually |
| 17:58.49 | putnopvut | What's the problem? |
| 17:58.55 | eliel | nop, |
| 17:58.57 | Qwell | it's spewing errors :D |
| 17:58.57 | eliel | yes |
| 17:59.01 | putnopvut | What is? |
| 17:59.21 | Qwell | it starts: (in global_datastores.c) |
| 17:59.21 | Qwell | /usr/src/asterisk/trunk/include/asterisk/abstract_jb.h:97: error: expected specifier-qualifier-list before ‘FILE’ |
| 17:59.41 | putnopvut | ...that doesn't happen here at all... |
| 17:59.52 | putnopvut | I'm coming over. |
| 18:00.35 | file | I fear it happens here as well |
| 18:00.37 | eliel | I have the same problem |
| 18:01.24 | kpfleming | tzafrir: thanks for that catch... i was too aggressive with my makefile changes... don't know what was wrong with my brain when i was doing that on friday :-) |
| 18:02.27 | *** part/#asterisk-dev RoyK (n=roy@sbs.hardrockcafe.no) |
| 18:03.02 | eliel | FILE is undefinied? |
| 18:04.38 | oej | eliel: Always. Forever. |
| 18:04.46 | Qwell | #undef file |
| 18:04.48 | eliel | include "asterisk.h" in global_data |
| 18:04.55 | eliel | global_datastores.c |
| 18:05.06 | Qwell | eliel: yeah, probably - my build is almost finished here |
| 18:05.07 | eliel | oej: he |
| 18:05.16 | Qwell | will try that if it fails after distclean |
| 18:05.20 | putnopvut | Why is it that I'm the only one not having these compilation errors... |
| 18:06.16 | kpfleming | local changes? |
| 18:06.25 | putnopvut | Nope. |
| 18:07.14 | Qwell | eliel: yep, that did it - but it needs ASTERISK_FILE_VERSION too |
| 18:07.15 | eliel | gcc fear you so, it doesn't give any error... :-) |
| 18:07.49 | eliel | Qwell: yeaph! |
| 18:07.53 | Qwell | fixed |
| 18:08.08 | putnopvut | Thanks, Qwell...I still don't know why it didn't fail here. |
| 18:08.26 | Qwell | who knows... |
| 18:10.16 | Qwell | kpfleming: is it correct that a Makefile target should be in .PHONY if it does not create a file? |
| 18:10.27 | kpfleming | yes |
| 18:10.37 | Qwell | so, pdf: asterisk.pdf, pdf should be there? |
| 18:10.44 | kpfleming | yes |
| 18:10.47 | Qwell | excellent |
| 18:10.53 | kpfleming | otherwise if there is a 'file' called pdf present the target won't be run |
| 18:10.58 | Qwell | gotcha |
| 18:11.28 | Qwell | so, if all isn't in .PHONY, and you run make by itself... will it stop, or will it only fail if you explicitly ask for all? |
| 18:11.40 | Qwell | (where "all" is replaced by whatever the first target is) |
| 18:11.59 | Qwell | (assuming a file named "all" exists) |
| 18:12.01 | kpfleming | it will only fail if you have a file named the same as the first target and it's timestamp is newer than the dependencies of that target |
| 18:12.10 | Qwell | makes sense |
| 18:16.44 | russellb | on a related note, as it will bite you in the future if you don't know, there is nothing special about the "all" target |
| 18:16.57 | russellb | running "make" simply runs the first target listed in the makefile |
| 18:17.12 | Qwell | right, I corrected myself :) |
| 18:17.18 | Qwell | That has bitten me before |
| 18:17.20 | russellb | oh, right, d'oh |
| 18:17.25 | russellb | heh, me too :-D |
| 18:17.45 | Qwell | multiple times, actually - I just didn't know why it was a problem until recently |
| 18:38.55 | wedhorn | Qwell: have you had a chance to fire up the 30VIP? |
| 18:42.49 | Qwell | wedhorn: I keep meaning to bring it... I have another phone to bring too. I'll try to de-sticker the other one tonight, and bring them both tomorrow |
| 18:45.28 | wedhorn | ok, on another thing, what's the issue with M10396, sort of needed to progress transfer. |
| 18:45.30 | wedhorn | M10396 |
| 18:45.31 | MuffinMan | [assigned] [Asterisk] Channels/chan_skinny 0010396: Restructure transmit_callstate function and calls to transmit_ reported by wedhorn http://bugs.digium.com/view.php?id=10396 |
| 18:51.31 | *** part/#asterisk-dev flujan (n=flujan@200-160-115-020.static.spo.ctbc.com.br) |
| 18:54.43 | jmls | ooh ooh ooh |
| 18:54.50 | jmls | blitzrage: found it ! |
| 18:54.57 | blitzrage | jmls: found it? |
| 18:55.11 | jmls | hangup during a long odbc call does not execute the h extension |
| 18:55.18 | blitzrage | ahhhhh |
| 18:55.22 | blitzrage | nicely done! |
| 18:55.36 | jmls | <PROTECTED> |
| 18:55.37 | jmls | <PROTECTED> |
| 18:55.37 | jmls | <PROTECTED> |
| 18:55.47 | jmls | note there is no h extension |
| 18:55.59 | jmls | in the log, that is. there is an h extension in the dialplan |
| 18:58.49 | jmls | oooh, it also seems to have stopped my zap channel |
| 18:58.57 | jmls | channel 1 is locked |
| 18:59.50 | blitzrage | oh hawt... |
| 19:00.13 | blitzrage | how interesting... asterisk behind NAT doesn't work with my ITSP if I use externip... |
| 19:00.30 | jmls | ok, I can reproduce this at will. |
| 19:02.03 | jmls | not only is the h extension not executing, but the channel that the call came in on is still "in use" even though the channel was hungup |
| 19:02.05 | jmls | http://pastebin.com/m68e09ad6 |
| 19:05.20 | Qwell | besides just not having been done, is there any reason that the echo can in zaptel isn't in menuselect? |
| 19:08.03 | Corydon76-dig | That's pretty much it |
| 19:08.11 | Qwell | I guess nobody really ever changes it anyways |
| 19:09.50 | Corydon76-dig | Not since the days of MARK2, when the EC was much worse |
| 19:10.06 | Qwell | right |
| 19:10.25 | Qwell | the only time people really would need to change it, is for OSLEC. HPEC is automatic |
| 19:10.32 | Qwell | (but OSLEC requires a patch anyways) |
| 19:18.20 | blitzrage | wow... the weirdest thing. My Asterisk behind NAT won't work if I provide an externip... but works fine without it (and no port forwarding). Only problem is that seems to break the ability to recieve calls directly from a SIP URI. I'm not missing an option that says I can specify externip for just for guests am I? |
| 19:20.09 | file | blitzrage: you do have localnet right? |
| 19:20.15 | blitzrage | file: yeppers |
| 19:21.22 | blitzrage | what actually happens, is the call comes in and works fine, but when Asterisk sends the 200 OK, the ACK doesn't get back in to Asterisk |
| 19:21.49 | blitzrage | so asterisk sends 6 200 OKs, then drops the call when the ACK doesn't come back. Without externip, the ACK comes back in fine |
| 19:28.32 | tzafrir | well, if the zaptel echo canceller won't be selectable through the environment, it would break my builds |
| 19:29.12 | Qwell | tzafrir: You could still set it with a menuselect.makeopts file |
| 19:29.33 | tzafrir | Qwell, through the environment. With no code changes |
| 19:29.46 | Qwell | yes, with a menuselect.makeopts file |
| 19:30.07 | tzafrir | I want to be able to build the same source tarball to a different EC |
| 19:30.44 | tzafrir | Right now I just set a value in the environment and it works |
| 19:31.21 | tzafrir | (on every system. Not just on a system I have set up specifically) |
| 19:32.05 | *** join/#asterisk-dev JerJer[mobile] (n=jj@24-231-253-65.dhcp.aldl.mi.charter.com) |
| 19:32.19 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.12.183) |
| 19:33.34 | tzafrir | For instance, how can I tell menuselect "build just ztcfg"? |
| 19:34.00 | Qwell | EC=someechocan && make MENUSELECT_MAKEOPTS=menuselect.makeopts_echocan-$EC |
| 19:34.44 | eliel | M0011464 |
| 19:34.45 | MuffinMan | [new] [Asterisk] Channels/chan_sip/General 0011464: Long usernames doesn't appear in manager or CLI reported by msetim http://bugs.digium.com/view.php?id=0011464 |
| 19:35.02 | Qwell | erm, USER_MAKEOPTS |
| 19:35.04 | tzafrir | Qwell, but I don't run make directly |
| 19:35.07 | eliel | please can someone update the sumary to reflect that a patch has been added? |
| 19:35.26 | tzafrir | I run it via several layers of scripts |
| 19:35.51 | russellb | oh goodness ... i am not interested in having this menuselect discussion again |
| 19:35.55 | russellb | we have had this discussion so many times |
| 19:36.07 | tzafrir | russellb, I mentioned a requirement |
| 19:36.22 | tzafrir | Please tell me how to do that with menuselect |
| 19:37.01 | tzafrir | (not that I require that you implement this now) |
| 19:38.04 | *** join/#asterisk-dev mvanbaak (n=mafkees@vanbaak.xs4all.nl) |
| 19:38.05 | tzafrir | I also mentioned another issue: If I wanted to build "just ztcfg" and followed ther same way, I would end up after today building both ztcfg and ztscan |
| 19:38.39 | tzafrir | And this is not the first time I mention those issues |
| 19:39.39 | russellb | and i have addressed them before, i don't want to talk about it |
| 19:41.48 | *** join/#asterisk-dev atisss (n=atisss@193.238.212.171) |
| 19:42.22 | tzafrir | russellb, I asked a simple question: "how can I pass options through the environment? |
| 19:43.13 | tzafrir | "USER_MAKOPTS" is not the answer. This is set from a file in my home directory. something that is set from the build script alone |
| 19:43.19 | tzafrir | I want to run: |
| 19:43.43 | tzafrir | VAR=val1 build # get result1 |
| 19:43.59 | tzafrir | VAR=val2 build # get result2 |
| 20:13.05 | *** join/#asterisk-dev jtodd (n=jtodd@h211.101.89.75.ip.alltel.net) |
| 20:26.17 | snuff-work | Qwell: i made the storage stuff mostly compile.. but have error with it claiming there is no __ast_free |
| 20:26.26 | snuff-work | storage.c:177: error: structure has no member named `__ast_free' |
| 20:26.39 | Qwell | let me update - I probably need to pull in some files that were added to trunk |
| 20:26.56 | snuff-work | i have updated the manager commands to the new CLI |
| 20:28.36 | tzafrir | russellb, hmm... where exactly is mwimonitornotify reset on reload? Isn't it set on a part of process_zap() that is only called on !reload? |
| 20:29.09 | snuff-work | :q |
| 20:29.18 | Qwell | #~/> |
| 20:30.10 | snuff-work | qwell i'll post my starting diff to pastebin ? |
| 20:30.15 | Qwell | sure |
| 20:30.22 | Qwell | well |
| 20:30.24 | Qwell | no |
| 20:30.34 | Qwell | licensing reasons |
| 20:30.43 | snuff-work | so where? |
| 20:30.51 | Qwell | one sec - let me build - if I can't get it really quick, I'd say open a bug |
| 20:31.45 | snuff-work | k.. my diff is 300 lines.. to make it compile cept the ast_free issue |
| 20:32.04 | Qwell | alright, yeah, it's non-trivial - go ahead and open a bug for it |
| 20:33.11 | snuff-work | k |
| 20:36.09 | snuff-work | M11466 |
| 20:36.10 | MuffinMan | [new] [Asterisk] Core-General 0011466: Get storage api to compile reported by snuffy http://bugs.digium.com/view.php?id=11466 |
| 20:39.38 | *** join/#asterisk-dev atisss (n=atisss@193.238.212.171) |
| 20:39.54 | Qwell | snuff-away: it compiles fine with your changes here.. |
| 20:41.05 | snuff-work | mm |
| 20:41.49 | Qwell | My line 177 isn't a free (or ast_free) - that's 178. Do you have more changes than just that? |
| 20:41.57 | Qwell | or any build options I might be missing? |
| 20:42.09 | snuff-work | nope |
| 20:42.19 | snuff-work | that's a straight svn diff > out.diff |
| 20:42.27 | Qwell | weird, try updating? |
| 20:42.32 | snuff-work | just have |
| 20:42.37 | snuff-work | waitin on compile |
| 20:42.37 | Qwell | still line 177? |
| 20:43.10 | snuff-work | i think i should remove some of my compiler options.. atm i have like 2/3rds of it selected |
| 20:48.06 | jmls | so, who do I need to pester about a) the h extension not executing, and b) a zap channel getting stuck ? |
| 20:48.08 | jmls | (Both of which I can reproduce at will ..) |
| 20:48.54 | snuff-work | jmls h exten not exec'ing? is the call hanging up in the same place as your h exten? |
| 20:48.55 | blitzrage | jmls: got a bug opened? I'm gonna guess it'll be Corydon76-dig when he has some time (since it sounds ODBC related?) |
| 20:49.20 | jmls | snuff-work: yup |
| 20:49.42 | jmls | blitzrage: not yet - wanted to get the dev eyes on it before polluting the bug database ;) |
| 20:49.45 | snuff-work | trunk or 1.4 ? |
| 20:49.47 | jmls | 1.4 |
| 20:49.56 | snuff-work | mm unusual |
| 20:50.18 | blitzrage | ya, I hadn't seen it before, but jmls seems to see it happen when a DB call takes a really like time... ? |
| 20:50.23 | jmls | yes |
| 20:50.28 | jmls | every time |
| 20:51.07 | jmls | I was talking to blitzrage about this a couple of days ago - I found that 2 of of 10000 calls didn't enter the h extension for some reason |
| 20:51.10 | snuff-work | Qwell: yes it does compile now.. i think it might have been the MTX_PROFILE or MALLOC_DEBUG flags probably the latter |
| 20:51.21 | Qwell | okay, I'm adding the changes I had locally too |
| 20:51.43 | snuff-work | malloc_debug loves breaking things :) |
| 20:56.52 | Qwell | try that :) |
| 20:58.48 | jmls | so I created an odbc function that takes a loooooooooooooooong time to execute, hung up the call during the odbc function |
| 20:59.08 | jmls | and, not only did h not get executed, but the zap channel gets stuck. |
| 20:59.30 | jmls | could explain a lot of these "my zap channels are stuck" problems. |
| 21:00.00 | jmls | I'm wondering if this may be the case with any function .. or if it's just odbc |
| 21:01.04 | snuff-work | technically jmls i dont think there are that many other functions that could wait along time other than odbc/mysql queries |
| 21:01.14 | Qwell | wait(5000000000) |
| 21:01.41 | snuff-work | mm u sure wait takes that big int? |
| 21:01.43 | jmls | no, but there is a possibility of the call hanging up *during* the millisecond or so of executing |
| 21:01.51 | jmls | oh, I'll try that ine |
| 21:01.53 | Qwell | snuff-away: no, but still |
| 21:01.54 | jmls | (one) |
| 21:02.37 | jmls | nope, that works |
| 21:03.24 | jmls | (h is executed, zap is ok) |
| 21:03.25 | atisss | hey |
| 21:03.34 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 21:03.46 | Qwell | jmls: it might be related to the autoservice that those funcs put on the channel |
| 21:03.52 | atisss | while on this topic - i've seen that ResetCDR hangs for a really long time, if there's something with database going on |
| 21:03.54 | atisss | some lock |
| 21:04.08 | atisss | with cdr_addon_mysql |
| 21:04.20 | *** join/#asterisk-dev joetester (n=patrick@216.191.34.13) |
| 21:04.31 | jmls | Qwell: what other functions use autoservice ? |
| 21:04.42 | Qwell | curl |
| 21:05.25 | Qwell | func_cut also, it looks like |
| 21:05.51 | Qwell | func_shell should be an easy one to test with - just shell out to a sleep |
| 21:06.54 | jmls | yes. curl fails |
| 21:07.17 | jmls | no h, zap stuck |
| 21:11.20 | atisss | from my experience, SIP channels are executing h after really long ResetCDR |
| 21:16.32 | *** join/#asterisk-dev RoyK (n=roy@ip-138-8-149-91.dialup.ice.no) |
| 21:17.21 | Qwell | jmls: does it only happen if you hang up while the func is executing? |
| 21:17.49 | jmls | yes |
| 21:18.18 | jmls | well, 100% so far in testing (25/25) |
| 21:18.41 | jmls | and if I make the odbc call effiicent, it never happens |
| 21:19.16 | Qwell | trunk or 1.4? |
| 21:19.17 | *** join/#asterisk-dev snuff-work (n=bradl@61.29.30.137) |
| 21:19.27 | jmls | 1.4 |
| 21:19.33 | jmls | latest svn |
| 21:19.38 | Qwell | I'm not sure those funcs have an autoservice in 1.4 |
| 21:19.48 | Qwell | oh, okay, they do |
| 21:19.53 | jmls | r90876 |
| 21:20.57 | blitzrage | ok, I'm copping out and just getting a 2nd IP address for my router instead of this NAT nonsense :) |
| 21:21.09 | mvanbaak | blitzrage: good idea |
| 21:21.42 | blitzrage | mvanbaak: ya -- it was working, but I can't get both my ITSP *and* URI dialing to work, so external IP here I come :) |
| 21:21.46 | mvanbaak | I just ordered a /24. it will arrive soon |
| 21:21.49 | blitzrage | lol |
| 21:22.08 | blitzrage | I think 2 IPs will do me fine :) |
| 21:22.16 | mvanbaak | I could only order a /24 |
| 21:22.18 | blitzrage | 1 for the apt., the other for the server |
| 21:22.33 | blitzrage | ya... I think most places won't let you order bigger blocks until you actually use the ones you get |
| 21:22.34 | mvanbaak | 10 euro/year |
| 21:22.44 | blitzrage | what... |
| 21:22.53 | blitzrage | it's gonna cost me $9.95 a month for 1 extra IP |
| 21:23.05 | jmls | mvanbaak: wish they did that in the uk |
| 21:23.15 | mvanbaak | jmls: it's not on my home setup though |
| 21:23.26 | mvanbaak | colocated boxen |
| 21:23.33 | mvanbaak | I had a /28 there |
| 21:23.38 | jmls | heh. My N95GB is now working on asterisk as a sip extension. |
| 21:23.39 | mvanbaak | now I get an extra /24 |
| 21:23.52 | mvanbaak | speakup.nl switched from IAX to SIP |
| 21:23.57 | *** part/#asterisk-dev RoyK (n=roy@ip-138-8-149-91.dialup.ice.no) |
| 21:24.13 | mvanbaak | since they are our main ITSP we gonna test SIP with them once the /24 is here |
| 21:24.30 | mvanbaak | 4 load-balanced asterisk boxen |
| 21:33.56 | Qwell | void blah() {int i = 0; if (i < 10) i++; return;} |
| 21:34.01 | Qwell | best useless op ever |
| 21:34.24 | mvanbaak | eh ? |
| 21:34.29 | mvanbaak | wtf is that ? |
| 21:34.59 | Qwell | I just removed a var that was completely unused, from zaptel.. |
| 21:35.03 | mvanbaak | ah |
| 21:35.09 | Qwell | from the int i, to the i++, was the entire usage of it |
| 21:35.52 | putnopvut | How pointful. |
| 21:35.54 | Qwell | wait a minute, that was static |
| 21:36.36 | Qwell | well, it compiled - it couldn't have possibly been used anywhere |
| 21:37.08 | jmls | maybe someone was getting paid per line of code .. |
| 21:37.14 | mvanbaak | must be |
| 21:37.20 | Qwell | Mark committed it, forever ago :p |
| 21:37.22 | Qwell | r87 |
| 21:37.29 | jmls | eep |
| 21:37.30 | mvanbaak | hahahahaha |
| 21:37.45 | Qwell | who knows - maybe he meant to use it somewhere |
| 21:38.03 | jmls | maybe he put it in waiting to see how long it woul dbe before someone found it |
| 21:38.19 | jmls | either you're going to get some reward, or fired for taking so long ;) |
| 21:38.32 | Qwell | I didn't find it. Somebody reported a bug :p |
| 21:38.45 | jmls | on something that did nothing ??? |
| 21:38.50 | mvanbaak | yeah, maybe it was a test |
| 21:38.52 | Qwell | to remove something that did nothing |
| 21:39.17 | putnopvut | My guess is that that variable used to be used for something but its functionality was removed bit-by-bit until all that was left was a useless set of lines. |
| 21:39.18 | mvanbaak | the one who reported the bug can have the company, and all current devs are fired |
| 21:39.24 | jmls | oh, ok. I was wondering how he found the bug in the first place .. |
| 21:39.34 | Qwell | putnopvut: yeah, but nothing referenced it in the commit in which it was added :) |
| 21:39.43 | putnopvut | Oh, nice. |
| 21:39.57 | jmls | ... ask ..... him ..... |
| 21:40.13 | *** join/#asterisk-dev atisss (n=atisss@193.238.212.171) |
| 21:41.09 | jmls | "Mark, do you have any idea how many more useless lines of code you've put into the system ?" |
| 21:42.38 | file | I believe the world is burning to the ground, oh well I guess we're gonna find out |
| 21:42.41 | file | let's see how far we've come |
| 21:49.19 | jmls | Qwell: any thoughts on the missing "h" ? |
| 21:49.52 | Qwell | nope, but it probably has something to do with autoservice. I'm not very familiar with how it actually works - somebody else may have to comment. You should probably open a bug though. |
| 21:50.29 | jmls | mm. Under what category ? Core ? |
| 21:50.44 | snuff-work | speaking of blah Qwell.. in storage.c you have char blah[path_max] could possibly be changed to mean something more ;) |
| 21:50.54 | Qwell | snuff-away: see the comment above it :) |
| 21:51.01 | snuff-work | ah |
| 21:51.04 | Qwell | it's just...blah. it doesn't do anything |
| 21:51.58 | snuff-work | i might be able to do little more work on it before end of week we'll see how much free time i have.. |
| 21:52.57 | Qwell | snuff-away: that'd be great |
| 21:53.08 | Qwell | if you have any API questions, I'll be around |
| 21:53.19 | snuff-work | :) |
| 21:53.30 | jmls | M11467 |
| 21:53.31 | MuffinMan | [new] [Asterisk] Core/Channels 0011467: h extension not executing, zap channel getting stuck reported by jmls http://bugs.digium.com/view.php?id=11467 |
| 21:53.41 | jmls | go, devs ! |
| 21:55.00 | mvanbaak | bbl all |
| 21:59.26 | tzafrir | What is ZT_SET_HWGAIN for? Is it for something like the fx[so][rt]xgain parameters of wctdm? |
| 21:59.46 | Qwell | tzafrir: sort of - but it can be done live, I believe |
| 22:00.11 | tzafrir | Sure it can be done live. Those just set values to registers |
| 22:00.21 | tzafrir | Set them to something else, and you're done |
| 22:00.57 | jmls_sleeping | goodnight all |
| 22:08.48 | *** join/#asterisk-dev paravoid (n=paravoid@zebra.cslab.ece.ntua.gr) |
| 22:09.02 | paravoid | Corydon76-dig: hi |
| 22:09.20 | paravoid | - void *_private; /* pointer to private buffer */ |
| 22:09.20 | paravoid | + /* pointer to private buffer */ |
| 22:09.20 | paravoid | + union { |
| 22:09.21 | paravoid | + void *_private; |
| 22:09.21 | paravoid | +#ifndef __cplusplus |
| 22:09.24 | paravoid | + /* be compatible with <= 1.4.14 */ |
| 22:09.26 | paravoid | + void *private __attribute__ ((deprecated)); |
| 22:09.29 | paravoid | +#endif |
| 22:09.31 | paravoid | + }; |
| 22:09.51 | paravoid | Corydon76-dig: any reason not to do something like that? |
| 22:10.30 | putnopvut | I think it's still a problem for people using C++ since the "private" token is reserved. |
| 22:10.37 | Qwell | That change was ABI compatible. |
| 22:10.48 | paravoid | putnopvut: that's what the ifdef is there for |
| 22:10.54 | putnopvut | Oh, I'm blind. |
| 22:10.57 | paravoid | Qwell: yes, but ABI was broken by the buildsum |
| 22:21.45 | paravoid | so? |
| 22:23.53 | Qwell | that wouldn't fix out of tree c++ modules |
| 22:25.41 | paravoid | what do you mean? |
| 22:26.18 | paravoid | it'll keep the API for all the working modules out there and it will let out-of-tree C++ modules to compile |
| 22:27.05 | Qwell | nm |
| 22:27.26 | paravoid | ? |
| 22:36.04 | Corydon76-dig | How was ABI broken? |
| 22:36.58 | Corydon76-dig | At the runtime level, there are no names, only position offsets and the position offsets did not change |
| 22:37.54 | russellb | Corydon76-dig: the loader changes changed the ABI |
| 22:38.09 | Qwell | it changed it, but it was still ABI compat... those modules just won't load :p |
| 22:40.59 | Corydon76-dig | Are you sure? |
| 22:41.25 | Corydon76-dig | The only pieces that go into the buildsum are the menuselect flags, which didn't change |
| 22:42.18 | russellb | it's a big addition to the module info structure that wasn't previously there |
| 22:42.49 | russellb | it was a conscious decision made because we felt it was worth it |
| 22:43.04 | Corydon76-dig | Oh, a different change |
| 22:43.06 | Qwell | it was at the end of the ast_module_info struct, so ABI compat remains - no? |
| 22:43.13 | russellb | no, it does not |
| 22:43.45 | russellb | because the structs live in the modules, allocated at build time |
| 22:43.53 | russellb | if you load an old module, it accessing bogus memory |
| 22:44.04 | Qwell | I guess it's also setting it on that struct. |
| 22:44.11 | russellb | and when it finds the garbage, it won't load it |
| 22:44.23 | Qwell | right, of course |
| 22:44.44 | Corydon76-dig | Oh, goodie. Faidon replied with a non-sequitur to the issue in the original thread. |
| 22:44.52 | Qwell | Corydon76-dig: paravoid ^^ |
| 22:45.05 | mvanbaak | gheh |
| 22:45.05 | Corydon76-dig | Ah |
| 22:45.12 | mvanbaak | I own an irc network |
| 22:45.17 | mvanbaak | with two hub servers |
| 22:45.20 | mvanbaak | one is down |
| 22:45.30 | mvanbaak | and the other is moving colocation in 15 minutes |
| 22:45.35 | mvanbaak | nice situation ;) |
| 22:45.47 | putnopvut | Well, it is nearly midnight where you are. |
| 22:45.58 | mvanbaak | yup |
| 22:46.05 | mvanbaak | the main hub will be shutdown at 00:00 |
| 22:46.17 | mvanbaak | so the box can be driven to the new colocation |
| 22:46.30 | mvanbaak | and our backup hub is dead since an hour |
| 22:46.36 | mvanbaak | gotta love murphy |
| 22:58.39 | *** part/#asterisk-dev ManxPower (n=manxpowe@170.sub-70-221-241.myvzw.com) |
| 23:00.29 | tzafrir | Anybody actually relying on the fact that TELEPHONY=yes is set after 'make config' (normally)? |
| 23:00.39 | tzafrir | in zaptel, that is |
| 23:01.15 | tzafrir | It gets in my way when I want to tweak the script to look for alternative config file locations |
| 23:02.01 | snuff-work | mmm.. with skinny is there a 'blind xfer' |
| 23:02.18 | tzafrir | I can't find a scenario where this is actually useful |
| 23:02.26 | Qwell | snuff-work: there is no transfer at all, right now. There is a patch on mantis though |
| 23:02.38 | Qwell | at least - I don't think I committed it yet |
| 23:02.39 | mvanbaak | or use asterisk blind xfer |
| 23:02.45 | mvanbaak | Qwell: you didn't |
| 23:02.53 | Qwell | yeah, there's always the features.conf transfer |
| 23:03.07 | snuff-work | yer.. i was wondering if the cisco phones actually supporting it |
| 23:03.15 | mvanbaak | they do |
| 23:03.16 | Qwell | M9939 |
| 23:03.18 | MuffinMan | [assigned] [Asterisk] Channels/chan_skinny 0009939: Transfer implementation reported by wedhorn http://bugs.digium.com/view.php?id=9939 |
| 23:03.20 | snuff-work | i know 7940's have blind xfer.. |
| 23:03.27 | tzafrir | heck, let's reimplement the init.d script |
| 23:03.30 | mvanbaak | 7905 and 7960 have too |
| 23:03.42 | mvanbaak | tzafrir: what init.d script ? safe_asterisk ? |
| 23:03.45 | snuff-work | but every image of 79x1 phones do not seem to have blind |
| 23:03.47 | Qwell | snuff-work: it's implemented as attended, but can be made blind |
| 23:03.51 | tzafrir | no. zaptel |
| 23:04.01 | Qwell | it's skinny, so it's the implementation that decides, not the phone |
| 23:04.15 | snuff-work | mm :( |
| 23:04.22 | mvanbaak | I like that idea |
| 23:04.41 | mvanbaak | I've been in too much device specific trouble lately to like the idea that a device can handle it |
| 23:05.24 | mvanbaak | freaking gs/snom/sipura incompatibility |
| 23:05.40 | mvanbaak | ok, the gs is incompatible with almost everything |
| 23:06.31 | mvanbaak | snuff-work: you talking skinny or sip here ? |
| 23:06.40 | snuff-work | sip.. |
| 23:06.45 | mvanbaak | ah |
| 23:06.48 | mvanbaak | cant help you there |
| 23:07.01 | mvanbaak | been almost a year since I tried sip on them |
| 23:07.01 | snuff-work | sip image of a 7940 has blindxfer... sip image of 7941 no blindxfer |
| 23:07.22 | mvanbaak | 00:06 ho [ambernet] Split: irc.fucking.rememberit.com.au. |
| 23:07.22 | mvanbaak | 00:06 ho [ambernet] Split: chanfix.ambernet.org. |
| 23:07.22 | mvanbaak | 00:06 ho [ambernet] Split new server: dev.ankeborg.nu. |
| 23:07.22 | mvanbaak | 00:06 ho [ambernet] Split: irc.ankeborg.nu. |
| 23:07.22 | mvanbaak | 00:06 ho [ambernet] Split: irc.wootgnu.org. |
| 23:07.24 | mvanbaak | 00:06 ho [ambernet] Split: irc.softakt.com. |
| 23:07.27 | mvanbaak | 00:06 ho [ambernet] Split: hub.se. |
| 23:07.29 | mvanbaak | OUCH |
| 23:07.32 | mvanbaak | wrong channel |
| 23:07.34 | mvanbaak | sorry |
| 23:07.35 | snuff-work | heh |
| 23:08.22 | Qwell | snuff-work: convert a phone to skinny, and test that patch out |
| 23:08.39 | mvanbaak | hub.se went down |
| 23:08.53 | mvanbaak | now the network is just a bunch of single, non-linked servers |
| 23:09.48 | mvanbaak | *cry* |
| 23:10.39 | mvanbaak | hhmm, the mwi stuff is never going into 1.4 right ? |
| 23:10.45 | mvanbaak | for skinny that is |
| 23:10.51 | Qwell | mwi stuff? |
| 23:11.51 | Qwell | oh, right |
| 23:11.51 | Qwell | no |
| 23:12.27 | mvanbaak | too bad |
| 23:12.34 | mvanbaak | I have a backported patch for it |
| 23:16.07 | mvanbaak | gheh, I just found out I wrote that stuff in the first place ;) |
| 23:16.19 | Qwell | :p |
| 23:16.48 | mvanbaak | ah well |
| 23:16.52 | mvanbaak | all hail svk |
| 23:17.40 | mvanbaak | I really cant get my mind to accept SIP behind NAT |
| 23:25.40 | mvanbaak | lol |
| 23:25.48 | mvanbaak | SIPNOGO |
| 23:29.11 | mvanbaak | ok, my irc network is linked again. time to go to bed |
| 23:30.03 | paravoid | Corydon76-dig: I believe that the API breakage could be easily avoided |
| 23:30.07 | paravoid | and I've demonstrated that |
| 23:30.55 | paravoid | I think that you haven't tried hard enough to keep API (and ABI for that matter) |
| 23:31.14 | paravoid | the question is, is there any reason not to merge the patch I just gave you? |
| 23:34.50 | russellb | that patch looks good, i'll merge it in a second |
| 23:35.17 | paravoid | good, thanks. |
| 23:35.30 | paravoid | if only the ABI issue was that easy :-) |
| 23:36.30 | russellb | heh ... |
| 23:40.57 | tzafrir | russellb, hmm.... I have a feeling that mwimonitornotify gets reset after a reload and thus won't work anymore |
| 23:41.05 | paravoid | russellb: btw, attribute deprecated is gcc 3.1+ |
| 23:43.04 | russellb | paravoid: i'm adding a configure script check for it |
| 23:43.15 | paravoid | you have one in trunk |
| 23:43.19 | russellb | tzafrir: after? |
| 23:43.22 | russellb | paravoid: yeah, but not 1.4 |
| 23:43.30 | paravoid | you might want to drop it completely, it's just a warning after all... |
| 23:43.40 | russellb | nah, it's easy to add |
| 23:43.40 | tzafrir | reload |
| 23:43.47 | paravoid | or you could just add an ifdef |
| 23:43.52 | paravoid | that defined __deprecated |
| 23:43.55 | paravoid | conditionally |
| 23:43.59 | russellb | that's what it does |
| 23:44.00 | tzafrir | or "reload" of chan_zap.so |
| 23:45.12 | tzafrir | The thing is that the keyword "mwimonitornotify" is only read if (!reload) |
| 23:45.14 | russellb | tzafrir: k, let me look |
| 23:46.05 | russellb | A91032 |
| 23:46.07 | MuffinMan | [91032] Committed by russell on 2007-12-04 19:46:40: Modify file.h to maintain API compatibility with earlier versions. If a recent |
| 23:46.30 | russellb | s/recent/non-ancient/ .... compiler ... |
| 23:46.30 | russellb | heh |
| 23:47.27 | russellb | tzafrir: oops, yeah, i'll move it out of that if (!reload) block |
| 23:50.59 | paravoid | russellb: I suppose the buildsum could be fixed by adding a flag |
| 23:51.05 | paravoid | AST_MODFLAG_INCLUDES_BUILDSUM |
| 23:51.05 | paravoid | or so |
| 23:51.10 | paravoid | but it's a bit late for that, isn't it |
| 23:51.52 | paravoid | all in all, I hope that you were a bit more cautious involving people's setups and people's code... :/ |
| 23:51.59 | paravoid | solutions can always be found |
| 23:55.51 | paravoid | russellb: so, would you find such a patch (adding a flag and checking buildopt_sum only if the flag is set) acceptable? |
| 23:56.15 | paravoid | you should probably add a version member (1.4, 1.6 etc.) to the structure by the way |
| 23:56.39 | russellb | hm, i don't know, i'd have to think about it, and i'd like to ask kevin, too |
| 23:56.41 | russellb | since that was his thing |
| 23:56.51 | paravoid | ok |
| 23:56.56 | paravoid | thanks :) |
| 23:58.42 | russellb | if you post to the -dev list, he'll see it |