| 01:28.48 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 01:28.48 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 01:37.23 | *** part/#asterisk-dev korihor (~korihor@190.205.251.97) |
| 02:00.58 | Corydon76-dig | kpfleming: ping |
| 02:02.59 | kpfleming | hello |
| 02:11.10 | Corydon76-dig | kpfleming: remember the 'make menuselect' issue you were having last week? |
| 02:11.51 | Corydon76-dig | It's now solved in all branches |
| 02:12.01 | Corydon76-dig | See the last Makefile change |
| 02:12.18 | kpfleming | yes, i saw that, thanks a ton |
| 02:12.42 | kpfleming | you could improve it slightly, by ensuring that 'menuselect' is the *only* goal in MAKECMDGOALS |
| 02:12.49 | kpfleming | but that's a good improvement regardless |
| 02:13.02 | Corydon76-dig | Well, it could be menuselect or nmenuselect or 2 others... |
| 02:15.34 | kpfleming | right |
| 02:15.46 | kpfleming | but if someone does 'make menuselect install', for example, that could be un-pretty |
| 02:16.45 | kpfleming | but then our makefiles would probably fail in nasty ways with multiple targets (goals) anyway |
| 03:19.10 | *** join/#asterisk-dev snuff-work (~aaa@120.17.154.236) |
| 03:19.10 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 04:16.46 | snuff-work | Corydon76-dig: you fixed a possible 'null' to printf in app_parkandannounce.c the other week right? |
| 04:59.39 | *** join/#asterisk-dev Deeewayne (~dwayne@c-71-207-214-190.hsd1.al.comcast.net) |
| 04:59.39 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 05:11.57 | Corydon76-dig | snuff-work: for Solaris? I don't remember where it was, actually |
| 05:12.14 | Corydon76-dig | Don't think it was that file |
| 05:12.49 | snuff-work | mm.. i might need to do it for 'that file' as 'context' can be null :) good old S_OR |
| 05:12.53 | Corydon76-dig | It was in res/res_agi.c |
| 05:12.58 | snuff-work | ah |
| 05:13.27 | Corydon76-dig | and there's a define for it as HAVE_NULLSAFE_PRINTF |
| 05:14.21 | snuff-work | oh so it can't happen anymore? nice |
| 05:15.21 | Corydon76-dig | No, it could |
| 05:15.50 | Corydon76-dig | I cannot really stop it from happening without rewriting *printf functions |
| 05:16.27 | snuff-work | mmm.. well solaris 11 / opensolaris handles null's in printf now.. |
| 05:17.21 | Corydon76-dig | Well, it should detect it then |
| 05:17.43 | Corydon76-dig | It's a configure test that tests for that |
| 05:19.40 | snuff-work | i haven't checked a configure output lately.. but i still have the sparc thing.. i will find a way to solve it for ast_str ;) |
| 05:30.00 | Corydon76-dig | ast_str should never return a NULL for its string buffer |
| 05:32.44 | snuff-work | mm i shouldn't have 'merged' the 2 replies |
| 05:33.09 | snuff-work | i know ast_str doesn't have an issue |
| 05:38.19 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-155-145.cablep.bezeqint.net) |
| 05:38.19 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 05:47.40 | *** part/#asterisk-dev benngard (~benngard@90-230-92-67-no148.tbcn.telia.com) |
| 06:23.29 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 06:23.29 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:41.24 | pentanol | hi there, anybody knows something about radius auth? |
| 06:58.02 | *** join/#asterisk-dev snuff-work (~aaa@210.9.82.197) |
| 06:58.02 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 07:41.07 | *** join/#asterisk-dev mpe (~mpe@217.74.220.92) |
| 08:01.26 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 08:01.26 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:25.16 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 08:28.09 | *** join/#asterisk-dev oej (~olle@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 08:28.09 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:36.49 | *** join/#asterisk-dev Antonjs (~anton@mm-headoffice.clients.fishnet.net.nz) |
| 08:52.55 | oej | Morning folks |
| 08:59.44 | mvanbaak | mornin oej |
| 08:59.57 | oej | Listening to musiconhold with many gaps |
| 09:00.01 | mvanbaak | I figured it was you. I heard Abba in the background |
| 09:18.05 | *** join/#asterisk-dev pentanol (~pentanol@77.35.48.247) |
| 09:31.27 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 10:05.55 | *** join/#asterisk-dev _ys (~Miranda@178.109.dsl.westcall.net) |
| 10:41.54 | *** join/#asterisk-dev dseeb_ (~Adium@CPE-58-169-81-65.lns1.bat.bigpond.net.au) |
| 10:52.14 | *** join/#asterisk-dev |Cybex| (~John@atwork-21.r-212.178.82.atwork.nl) |
| 10:53.22 | *** join/#asterisk-dev |Cybex| (~John@atwork-21.r-212.178.82.atwork.nl) |
| 11:30.01 | Antonjs | I hope this is the right channel, does anyone know how Asterisk reads data coming in on the SIP socket? |
| 11:30.23 | Antonjs | It seems to be failing to read it for 20-30 seconds at a time, then processing a whole bunch of requests at once |
| 11:41.34 | pentanol | Antonjs looks like it here... main/netsock.c |
| 11:44.38 | Antonjs | cheers |
| 11:45.03 | Antonjs | absolutely strange behaviour, sometime this morning our entire system just started barely responding to SIP requests |
| 11:45.22 | Antonjs | turns out they're just timing out because asterisk is taking so long to process them |
| 11:47.31 | oej | At what load? |
| 11:48.09 | Antonjs | none whatsoever |
| 11:48.20 | Antonjs | the system normally handles around 100 extensions |
| 11:48.37 | Antonjs | but this still happens after a fresh reboot with a single sip client plugged in to the server with a crossover cable |
| 11:49.15 | Antonjs | I can see a SIP INVITE showing up in tcpdump on the ethernet interface, but nothing appears in asterisk's sip debug until much, much later |
| 11:49.37 | oej | that is really weird |
| 11:49.42 | Antonjs | hmm |
| 11:49.58 | Antonjs | seems to be only sip as well |
| 11:50.13 | Antonjs | IAX and mISDN connections work great |
| 12:05.37 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:05.38 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:09.14 | Antonjs | hrm, think I've worked it out |
| 12:09.29 | Antonjs | surely the entire chan_sip doesn't block on dns requests? |
| 12:09.44 | oej | It does, yes it does |
| 12:09.50 | Antonjs | :( |
| 12:10.02 | oej | There has been many mails about it recently on asterisk-users and many more during the years |
| 12:10.06 | oej | We don't have asynch dns |
| 12:10.23 | Antonjs | and an outdated reference to a server which didn't cause a problem until the dns record stopped being published last night.... |
| 12:10.28 | Antonjs | aha |
| 12:10.41 | Antonjs | as always, it comes down to getting your damned search terms right ;) |
| 12:10.50 | oej | Right :-) |
| 12:10.56 | oej | You need to run a local resolver |
| 12:11.06 | Antonjs | I do |
| 12:11.15 | Antonjs | it plugs into our local dns infrastructure |
| 12:11.47 | Antonjs | the ref was to fwd.pulver.com --- which went down last year some time IIRC |
| 12:12.01 | Antonjs | but I guess they only stopped publishing the domain in the last couple of days |
| 12:12.02 | Antonjs | hmm |
| 12:13.07 | oej | it's still in our sip.conf.sample, but commented out. We should remove it. |
| 12:14.46 | Antonjs | ah |
| 12:15.03 | Antonjs | wouldn't have helped in this case, this is from our live config that has been running for years |
| 12:15.14 | Antonjs | I guess it was in there for the 1800 termination that was there way back |
| 12:15.21 | Antonjs | never caused any problems so it was never removed |
| 12:15.28 | Antonjs | probably a good idea to get it out of the examples though ;) |
| 13:11.53 | *** join/#asterisk-dev sgimeno (~chatzilla@226.Red-80-33-64.staticIP.rima-tde.net) |
| 14:45.44 | seanbright | did anything ever come of that 10,000 simultaneous calls stuff? |
| 14:45.51 | seanbright | i don't remember seeing a white paper or anything |
| 14:46.48 | jsmith | Architectural question... are application and function modules still loaded dynamically (as needed) by the core, but resource modules always resident in memory? |
| 14:47.29 | *** join/#asterisk-dev korihor (~korihor@190.205.251.97) |
| 14:49.25 | file | jsmith: I don't know what you mean by apps/funcs being loaded dynamically, everything is loaded the same |
| 14:51.00 | jsmith | file: See, this is why I ask :-) |
| 14:51.23 | jsmith | file: Some of my training notes implied that application modules weren't loaded until they were needed by the core, but I didn't see that in my own experience |
| 14:51.37 | jsmith | Hence the reason I'm asking people who know more than I do |
| 14:51.55 | file | that would require the core knowing what module has an application and loading it at that time.. which would be unfun |
| 14:53.06 | jsmith | Makes sense. |
| 14:53.10 | jsmith | I'll fix my notes |
| 14:54.54 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:54.55 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:57.14 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:04.35 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:04.35 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 15:12.09 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:12.09 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:28.47 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:28.48 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:48.49 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 15:52.20 | *** join/#asterisk-dev Deeewayne (~dwayne@75.76.254.162) |
| 15:52.20 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 16:00.22 | *** join/#asterisk-dev jpeeler (~jpeeler@asterisk/digium-software-dev/jpeeler) |
| 16:00.22 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 16:17.08 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 16:18.50 | *** join/#asterisk-dev marv (~timr@24.214.206.254) |
| 16:38.59 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 16:38.59 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:42.15 | *** join/#asterisk-dev CunningPike (~CunningPi@204.239.8.157) |
| 16:48.07 | putnopvut | I've been using the ast_str API as a model for how to properly handle va_list variables. However, there is something I'm a bit lost on. In the stdarg(3) man page, it says, regarding va_copy: "Each invocation of va_copy() must be matched by a corresponding invocation of va_end() in the same function" It appears there are many code paths in __ast_str_helper in main/strings.c that do not result in va_end() being called on th |
| 16:48.07 | putnopvut | e aq variable. |
| 16:49.03 | russellb | interesting, I didn't know va_end() was needed after va_copy() :-) |
| 16:49.03 | putnopvut | The way I read the manpage, it's important to call va_end() for every invocation of va_copy(). Since we are not doing this, is there a possible memory leak in the ast_str code as a result? |
| 16:50.15 | Kobaz | leaks some memory on russellb |
| 16:50.22 | putnopvut | ew |
| 16:50.39 | russellb | putnopvut: if that's what the man page says, then yeah, sounds wrong to me |
| 16:51.07 | putnopvut | All right. I can make a commit to branches that have ast_str functions and add appropriate va_end calls to the function. |
| 16:51.15 | Corydon76-dig | putnopvut: it only leaks memory on non-glibc platforms |
| 16:51.37 | putnopvut | Corydon76-dig: thanks for the info! |
| 16:51.50 | Kobaz | i don't |
| 16:51.51 | Kobaz | er |
| 16:51.54 | putnopvut | So the fact that it does leak on some platforms does necessitate a fix. |
| 16:52.01 | kpfleming | yes |
| 16:52.15 | Corydon76-dig | Absolutely |
| 16:52.16 | Kobaz | wrong window |
| 16:52.18 | russellb | correct |
| 16:52.25 | putnopvut | Of course part of me also wants to write a unit test for ast_str at the same time. |
| 16:52.37 | kpfleming | your left earlobe? |
| 16:52.37 | Kobaz | votes for the unit test |
| 16:52.38 | putnopvut | But man that would be deviating from what I was trying to do in the first place :) |
| 16:52.48 | putnopvut | kpfleming: close, the anvil bone in my left ear. |
| 16:52.53 | kpfleming | nice |
| 16:55.24 | putnopvut | Thanks for the discussion. I'll write up a unit test as well as a fix for the current problem. |
| 16:57.59 | kpfleming | at some point our unit tests will want to measure memory consumption as well... we may have to have an interface into the MALLOC_DEBUG machinery for doing that |
| 16:58.09 | Kobaz | that would be completely awesome |
| 16:58.32 | Kobaz | i'll have to make some cookies for whoever adds that |
| 16:58.58 | kpfleming | although really, it would need to live even lower than that... maybe an LD_PRELOAD library, but even that would not likely catch missing calls to va_end()... so it's possible we'll just need to run our unit tests under valgrind and rely on that |
| 16:59.21 | Kobaz | well, there's memory errors that even valgrind won't find |
| 16:59.31 | Kobaz | like overuns of static buffers... need mudflap for that |
| 16:59.58 | Kobaz | which i was trying to get to work with asterisk, but i haven't finished monkeying up the makefiles for it |
| 16:59.59 | kpfleming | yes, our test slaves could be setup to use that as well |
| 17:00.11 | putnopvut | kpfleming: one simple thing to do would be to call a function telling the MALLOC_DEBUG workings to set a flag on all memory allocations that come from this particular function. Then, when the test is done, have it search all allocated regions. Any with the flag set were not properly freed. |
| 17:00.33 | kpfleming | right. but if va_start() allocates memory, MALLOC_DEBUG won't know about it. |
| 17:00.36 | putnopvut | RIght. |
| 17:01.18 | kpfleming | this is one of those cases where a partial solution could be less useful than no solution at all, because people would tend to see the lack of problems reported as an 'all clear' when it's not that at all |
| 17:06.24 | tzafrir_laptop | We're finally getting to test freepbx on asterisk 1.6.2 . |
| 17:06.55 | Corydon76-dig | tzafrir_laptop: sounds like punishment |
| 17:07.02 | tzafrir_laptop | And, surprise, surprise: on a new system you get plenty of errors due to #include of missing files |
| 17:07.18 | Qwell | they fixed that... |
| 17:07.33 | tzafrir_laptop | aparantly not everywhere |
| 17:08.09 | tzafrir_laptop | I wonder if a different '#includeopt' that would not err on missing files would help |
| 17:08.25 | kpfleming | #exec cat /path/to/file |
| 17:08.35 | file | is hidden |
| 17:08.46 | jsmith | sets file as immutable |
| 17:08.49 | tzafrir_laptop | With worse error handling |
| 17:08.53 | kpfleming | darnit, i was just about to do that |
| 17:09.01 | jsmith | kpfleming: You snooze, you lose |
| 17:09.05 | tzafrir_laptop | What happens if file is a directory? |
| 17:09.17 | kpfleming | i have no idea |
| 17:09.37 | kpfleming | that proposed solution was untested and came with no warranty, express or impllied |
| 17:09.51 | jsmith | kpfleming: the imp lied? |
| 17:09.56 | tzafrir_laptop | #exec is also disabled by default, and for a good reason |
| 17:10.26 | Qwell | tzafrir_laptop: it should be touching any #include'd file |
| 17:11.08 | tzafrir_laptop | Qwell, frankly I was thinking of using a similar method elsewhere |
| 17:11.28 | tzafrir_laptop | but having to actually have that optional file makes things less desirable |
| 17:12.25 | Qwell | hrm, I wonder what happens in php when you modify the loop var inside of the loop |
| 17:12.34 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 17:12.34 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:12.43 | Qwell | foreach($output as $file) { stuff(); $output=something; } |
| 17:12.52 | Qwell | that seems broken |
| 17:14.45 | jsmith | Qwell: Very much so |
| 17:15.00 | kpfleming | has no clue what the syntax actually does in PHP |
| 17:16.35 | russellb | runs in circles |
| 17:17.07 | Qwell | kpfleming: $output is an array. It sets $file to the array item for every item in the array |
| 17:17.28 | kpfleming | ugh... that seems backwards |
| 17:17.34 | kpfleming | but whatever |
| 17:17.49 | kpfleming | wait... so you aren't modifying the loop variable, you're modifying the array you are looping over! |
| 17:17.54 | Qwell | right |
| 17:18.01 | kpfleming | even worse then |
| 17:18.02 | Qwell | sorry, had trouble coming up with the wording for that |
| 17:18.56 | Qwell | So, in the loop, if the file doesn't exist, it tries to exec(touch) it, and sets the output of the exec to $output |
| 17:19.00 | Qwell | that's silly |
| 17:19.28 | kpfleming | unless $output inside the loop is a different variable due to scoping rules |
| 17:19.33 | Qwell | (worst part about that, is that it never actually does anything with the output..) |
| 17:19.45 | kpfleming | or like in perl, where different syntax means scalar vs. list vs. array |
| 17:20.06 | Qwell | tzafrir_laptop: are you testing 2.5 or 2.6? |
| 17:20.13 | tzafrir_laptop | 2.6 |
| 17:20.37 | Qwell | yeah, there's a pretty obvious difference between the two. right before the exec(), it's setting $output=array(); in 2.6, but not 2.5 |
| 17:20.44 | Qwell | amp_conf/bin/retrieve_conf |
| 17:21.35 | Qwell | The scope of a variable is the context within which it is defined. For the most part all PHP variables only have a single scope. This single scope spans included and required files as well. For example: |
| 17:22.25 | Qwell | it's not in a function, so there is no local scope |
| 18:16.53 | *** join/#asterisk-dev mnt_real (~sinan@bas1-montreal43-1177754737.dsl.bell.ca) |
| 18:24.45 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 18:24.45 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 18:52.27 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 19:02.10 | atis_work | huh, anybody seen " Program terminated with signal 7, Bus error." |
| 19:02.24 | atis_work | i got backtrace but no idea what to look for :p |
| 19:02.59 | kpfleming | bus error would usually indicate an unaligned access to data or something of the sort... what hardware platform is this on? |
| 19:03.45 | atis_work | kpfleming: x86_64 / xeon |
| 19:04.02 | kpfleming | very strange indeed |
| 19:04.06 | kpfleming | it's not common, that's for sure |
| 19:04.16 | atis_work | yeah, i see it for first time |
| 19:05.22 | atis_work | i left small memory leak in my patches to chan_sip, then i recompiled and replaced module, hoping to reload it later, but it just crashed :p |
| 19:05.31 | atis_work | memory was still enough for couple of hours.. |
| 19:07.51 | kpfleming | oh! how did you replace the module? |
| 19:10.01 | seanbright | unlink is the key |
| 19:10.05 | seanbright | kpfleming taught me that |
| 19:10.22 | kpfleming | yes.. you absolutely do not want to use 'cp' |
| 19:24.53 | *** join/#asterisk-dev niekvlessert (~niek@5ED25657.cable.ziggo.nl) |
| 19:25.33 | jsmith | file: Was the new Bridging API introduced in 1.6.1 or 1.6.2? I know that ConfBridge was in 1.6.2, but when did the bridge modules get introduced? |
| 19:26.07 | file | when app_confbridge did. |
| 19:26.55 | *** join/#asterisk-dev wedhorn (~nnnnnnnnn@123-243-209-34.static.tpgi.com.au) |
| 19:27.46 | Kobaz | yeah cp is bad for .so's |
| 19:30.01 | seanbright | so is there anything in asterisk that can be simplified with the bridging api? |
| 19:30.06 | seanbright | that hasn't already been done? |
| 19:30.57 | Kobaz | making coffee |
| 19:31.04 | Kobaz | would be much simpler with bridging |
| 19:33.43 | kpfleming | yes.. what hasn't been done yet is convert the standard call bridging to use it, so that adding and removing channels to a 'standard' 2-channel call becomes possible without having to redirect the channels into a conference |
| 19:34.13 | seanbright | ahh. |
| 19:34.27 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 19:35.11 | *** join/#asterisk-dev moy (~moy@74.12.129.100) |
| 19:35.25 | Kobaz | oh yes |
| 19:35.29 | Kobaz | that would be really awesome |
| 19:35.31 | jsmith | kpfleming: Oh, is that all :-p |
| 19:35.37 | Kobaz | on-demand channel adding |
| 19:35.45 | kpfleming | correct, that's all :-) |
| 19:35.51 | atis_work | did i missed something? |
| 19:35.58 | atis_work | network.. :p |
| 19:36.00 | jsmith | missed a lot... |
| 19:36.25 | jsmith | was watching a few minutes of Olympic curling while he choked down some lunch |
| 19:36.32 | kpfleming | curling! |
| 19:36.40 | malcolmd | i don't have a tv and the wikipedia's not been updated; is the us playing yet? did canada defeat norway? |
| 19:36.43 | atis_work | curl ing:// |
| 19:36.58 | kpfleming | malcolmd: is the us women's team still composed of those two cute blondes? |
| 19:37.08 | jsmith | malcolmd: Norway and Canada were still at it... Germany was beating the US at the 8th end |
| 19:37.16 | jsmith | malcolmd: (7 to 5) |
| 19:37.23 | malcolmd | jsmith: thanks |
| 19:37.30 | jsmith | malcolmd: Hey, anything for a fellow curling fan |
| 19:37.32 | malcolmd | kpfleming: thanks, jonas brother |
| 19:37.38 | kpfleming | no prob! |
| 19:37.58 | atis_work | so, are asterisk modules constantly accessed on disk? |
| 19:38.23 | kpfleming | that depends on the OS |
| 19:38.28 | kpfleming | but in general, they can be, yes |
| 19:46.08 | Corydon76-dig | kpfleming: they are? |
| 19:46.15 | kpfleming | yes |
| 19:46.33 | kpfleming | pages of an executable can be dropped from memory at will by the OS when it knows it can bring them back in from disk |
| 19:46.50 | kpfleming | read-only sections, of course |
| 19:47.08 | atis_work | ah, so memory leak favoured that crash.. |
| 19:47.16 | kpfleming | probably so, yes |
| 19:47.28 | Corydon76-dig | Well, provided that the executable isn't overwritten |
| 19:47.38 | kpfleming | no, overwriting does not change it |
| 19:47.52 | kpfleming | if you change the contents of the file, the OS will still load from that file, without knowing the contents have changed |
| 19:48.06 | kpfleming | this is why 'install' does not do that, it moves the old file out of the way and puts the new one in its place |
| 19:48.57 | atis_work | uff, i always thought that it's handled by filesystem by allocation new inode if used file is being written to |
| 19:49.34 | Corydon76-dig | Yeah, I think the kernel is smarter than that |
| 19:49.37 | Amorsen | atis_work: It can be handy to be able to read a file as it is changing. E.g. "tail" |
| 19:49.53 | kpfleming | no |
| 19:50.00 | kpfleming | if you write to an existing file, the contents of that file are changed |
| 19:50.35 | Corydon76-dig | I understand that part, but I think that the kernel also notices that and ensures that it keeps a pristine copy from when the executable was originally loaded |
| 19:50.38 | kpfleming | there are filesystems that will do copy-on-write, but it's not common and it must be enabled |
| 19:50.54 | kpfleming | no, the kernel (at least on linux) makes no such attempt to do that |
| 19:51.03 | kpfleming | it essentially has a file handle open to the file, and that is all |
| 19:51.18 | kpfleming | it does not monitor the file for writes |
| 19:51.41 | atis_work | huh, all we lost is 120 calls from customers :D |
| 19:52.42 | Amorsen | However, does cp really reuse the inode? |
| 19:53.06 | Amorsen | Let's find out |
| 19:53.12 | seanbright | if the destination exists? probably |
| 19:53.23 | seanbright | bets $0.50 |
| 19:53.53 | kpfleming | Amorsen: cp opens the file if it exists, truncates it, and writes the content into it |
| 19:54.09 | Amorsen | Right kpfleming, I just tested it |
| 19:54.18 | Amorsen | ls -i is handy |
| 19:54.24 | kpfleming | has learned this the hard way |
| 19:54.27 | kpfleming | also 'stat' |
| 19:55.18 | Amorsen | I wonder why it does that... Is it really that much cheaper than opening a new file and replacing? |
| 19:55.27 | kpfleming | so just for fun, on a test box, start up asterisk, then 'rm' /usr/lib/asterisk/modules/chan_sip.so. if you do an 'lsof', you'll see that the asterisk process still has that file open, but it no longer has an inode associated with it |
| 19:55.42 | kpfleming | yes... that could require 2x the disk space |
| 19:55.55 | kpfleming | remember, all this stuff was designed back in the day of tiny expensive disks |
| 19:55.57 | Amorsen | Good point |
| 19:56.40 | Amorsen | If you delete glibc, you can find a random daemon and grab the inode back from /dev/12345/fd/ |
| 19:56.44 | file | I remember nothing! |
| 19:56.54 | kpfleming | yep |
| 19:57.21 | kpfleming | and if you write into the existing glibc shared object, your system will probably go boom in a spectacular way |
| 20:09.16 | leifmadsen | jsmith: malcolmd: you like curling too?! |
| 20:09.35 | leifmadsen | I still can't believe Canada blew a 5-1 lead in one end |
| 20:10.41 | jsmith | leifmadsen: Duh! |
| 20:10.52 | jsmith | leifmadsen: How could you not know I'm a curling fan? |
| 20:11.11 | malcolmd | leifmadsen: it's great fun to watch |
| 20:11.14 | leifmadsen | I don't know lots of things |
| 20:11.23 | jsmith | leifmadsen: I've been watching curling since before you were born |
| 20:11.29 | leifmadsen | end 10, Canada up 6-4, norway with the hammer |
| 20:11.36 | leifmadsen | jsmith: that doesn't mean anything but that you're old :) |
| 20:11.39 | jsmith | leifmadsen: How are USA and Germany doing? |
| 20:11.48 | jsmith | leifmadsen: Or that you're still a baby :-p |
| 20:11.49 | leifmadsen | they haven't shown the US/Germany score yet |
| 20:12.00 | leifmadsen | ;) |
| 20:12.51 | malcolmd | us lost to germany says wikipedia |
| 20:12.53 | leifmadsen | jsmith: I'll update if/when they show it |
| 20:12.58 | leifmadsen | ah |
| 20:13.31 | leifmadsen | ah, here comes the update |
| 20:13.35 | malcolmd | norway canada match is over, too, but i won't spoil it |
| 20:13.40 | leifmadsen | this must be slightly behind |
| 20:13.48 | leifmadsen | thanks :) |
| 20:14.06 | jsmith | leifmadsen: Propagation delay... takes a while for the signals to get back across the border... |
| 20:14.13 | jsmith | ducks and hides |
| 20:14.25 | leifmadsen | heh |
| 20:17.23 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 20:25.29 | Kobaz | do de do |
| 20:34.51 | *** join/#asterisk-dev davidbrillert (~aragon125@h216-235-8-130.host.egate.net) |
| 20:41.10 | leifmadsen | malcolmd: wow! Canada wins a nail-biter! |
| 20:41.17 | malcolmd | leifmadsen: yup :) |
| 20:41.56 | leifmadsen | malcolmd: did you see the final shot? wow! 3 red rocks in the house blocking the centre, and canada draws around the 2 blocking rocks and takes the point by putting it in the centre |
| 20:42.47 | malcolmd | nice :) i didn't get to see anything, i just saw the boxscore on wikipedia |
| 20:43.01 | leifmadsen | gotcha |
| 20:43.14 | kpfleming | wikipedia? i'm surprised it's being used for real time score updates |
| 20:43.34 | malcolmd | i don't think they're real-timing it, just posting the scores of the completed matches |
| 20:45.18 | *** join/#asterisk-dev LauPro (~LauPro@87.233.6.201) |
| 20:45.31 | LauPro | hi, i've a question about running asterisk from source |
| 20:45.35 | LauPro | when debugging it |
| 20:45.59 | kpfleming | malcolmd: but how are box scores even wikipedia material? |
| 20:46.05 | LauPro | how can i run it in some way that is automatically finds all the modules? |
| 20:46.12 | LauPro | instead of make install |
| 20:46.47 | kpfleming | you can't, but you can use make menuselect to embed the modules into the binary, and then it will run from the source tree |
| 20:46.58 | malcolmd | kpfleming: http://en.wikipedia.org/wiki/Curling_at_the_2010_Winter_Olympics_%E2%80%93_Men%27s_tournament |
| 20:47.04 | kpfleming | wow |
| 20:47.06 | LauPro | ah wauw, make menuselect, thanks |
| 20:47.15 | kpfleming | i'll start wikipedia pages for baseball game box scores then :-) |
| 20:47.51 | putnopvut | Welp, I think everyone will be simultaneously happy and sad to know that my ast_str test I've been writing has exposed bugs in the ast_str code. |
| 20:48.00 | kpfleming | yay-boo! |
| 20:48.12 | putnopvut | One of the more interesting ones is this: |
| 20:49.16 | putnopvut | Er, it's hard to explain in text. |
| 20:49.37 | kpfleming | would music be better? |
| 20:50.18 | putnopvut | But essentially, I tried to write a large string into an ast_str using ast_str_set. However, I passed 5 as the second parameter to ast_str_set, which to my understanding of the documentation, means to only actually write the first 5 characters of the long string to the ast_str. |
| 20:50.37 | putnopvut | The result, though, was that the entire allocated space of the ast_str was written to instead. |
| 20:50.57 | kpfleming | that does sound bug-like |
| 20:51.30 | putnopvut | Yes, the problem appears to be that the vsnprintf call in __ast_str_helper does not take into account the actual max_len passed to the function. |
| 20:52.13 | putnopvut | The only time the max_len is taken into account is if the max_len is greater than the size of the current ast_str's size or if the max_len is 0. |
| 20:52.16 | Corydon76-dig | putnopvut: second parameter only affects the maximum size of the buffer, not the size of any buffer already allocated |
| 20:52.45 | putnopvut | Corydon76-dig: Okay, then the documentation needs to be reworded. |
| 20:53.03 | Corydon76-dig | maximum reallocation size, that is |
| 20:53.32 | putnopvut | So in other words, if the max_len passed in is smaller than the current size, it is rightfully ignored then. |
| 20:53.38 | Corydon76-dig | Correct |
| 20:53.46 | putnopvut | But if the string needs to be reallocated, then we only will reallocate it up to the max_len. |
| 20:53.54 | Corydon76-dig | Correct |
| 20:54.24 | putnopvut | So by extension, if an ast_str is created via ast_str_alloca, then the max_len value is superfluous. |
| 20:54.40 | Corydon76-dig | Correct |
| 20:55.03 | putnopvut | All right, thanks for that. I'm going to fix up the documentation of that parameter then. |
| 20:56.02 | putnopvut | There is something else I found as well. |
| 20:56.13 | Corydon76-dig | If it's created via ast_str_alloca, then the second parameter is effectively always -1 |
| 20:57.40 | putnopvut | If passing a stack-allocated ast_str to ast_str_set with max_len == 0 or max_len > allocated space of the ast_str, then ast_str_set_returns -1. However, it appears that the call actually does successfully set the string up to the current allocated size. |
| 20:58.12 | kpfleming | that's one aspect of the ast_str API that never made any sense to me... why you'd need to supply the maximum size every time you do anything to the object, rather than just once when you create it. |
| 20:58.58 | putnopvut | kpfleming: I interpreted the max_len, up until Corydon76-dig's explanation in here, as the max_len of the string to write to the ast_str rather than the max_len of allocation space. |
| 20:59.10 | Corydon76-dig | kpfleming: shoulda brought that up when it was only in trunk, so we coulda changed it |
| 20:59.27 | kpfleming | i know, but i had no time, and it's not worth changing now |
| 20:59.29 | putnopvut | So in the test I referenced above where I wrote a really long string to the buffer but passed 5 as the max_len, I expected only 5 characters to be written to the ast_str. |
| 21:00.04 | Corydon76-dig | Right, so that was a documentation mistake |
| 21:00.08 | putnopvut | Anyway, what about the -1 return of ast_str_set that I referenced? |
| 21:00.35 | Corydon76-dig | Depends on whether the entire string was able to be written or not |
| 21:00.40 | putnopvut | I feel like we should instead be returning the number of chars written instead. |
| 21:01.00 | Corydon76-dig | -1 means that it wasn't able to write all characters, correct? |
| 21:01.21 | putnopvut | The only documentation says that <0 is returned "in case of error" |
| 21:01.25 | putnopvut | Not very descriptive. |
| 21:01.42 | putnopvut | But the other part of the \return of the doxygen for ast_str_set is: |
| 21:02.12 | putnopvut | "All the functions return <0 in case of error, or the length of the string added to the buffer otherwise" |
| 21:02.36 | putnopvut | So since chars were added to the buffer, I was expecting a >0 return. |
| 21:02.53 | putnopvut | However, I can also see how an error occurred since we couldn't write the entire string to the buffer. |
| 21:03.11 | Corydon76-dig | I'd say the current behavior is correct |
| 21:03.38 | Corydon76-dig | In fact, I don't know of anyplace that the non-negative return value is even used! |
| 21:03.59 | Corydon76-dig | Can you find any examples where that value is used? |
| 21:04.35 | putnopvut | I can look, but I'd be willing to bet that in 99% of the cases that ast_str_set is used, the return is completely ignored :) |
| 21:04.42 | Corydon76-dig | right |
| 21:04.50 | *** join/#asterisk-dev shin-shoryuken_ (~shin-shor@hephaestus.restechservices.net) |
| 21:05.20 | Corydon76-dig | My inclination is that the current behavior is correct and that we fix the documentation to match |
| 21:05.35 | putnopvut | All right. Will do. |
| 21:05.53 | Corydon76-dig | I mean, unless you find a case where it doesn't make sense |
| 21:06.18 | Corydon76-dig | but the implementation, I think, is very straightforward |
| 21:06.27 | shin-shoryuken_ | Anyone familiar with a deadlock situation in __dahdi_exception? I haven't seen a bug report on it, and I'm not sure how to proceed (never submitted one before). |
| 21:06.33 | putnopvut | Yeah, the documentation just leaves much to be desired :) |
| 21:07.04 | Corydon76-dig | shin-shoryuken_: compile with DEBUG_THREADS and get a 'core show locks' when the deadlock occurs |
| 21:07.37 | putnopvut | Corydon76-dig: the only places I've found so far that even inspect the return of ast_str_set are just making sure that a negative value is not returned. And these instances are pretty rare. |
| 21:07.45 | shin-shoryuken_ | I've got that, and output of 'thread apply all bt full' from running gdb on the running process. |
| 21:07.49 | Corydon76-dig | shin-shoryuken_: 'make menuselect', in case you weren't aware. |
| 21:08.08 | Corydon76-dig | shin-shoryuken_: if you've got the 'core show locks', then submit a report on issues.asterisk.org |
| 21:08.14 | shin-shoryuken_ | I'm running it on my sandbox with 'DEBUG_CHANNEL_LOCKS' as well. |
| 21:08.33 | shin-shoryuken_ | Okay, will do. Thanks! |
| 21:08.39 | Corydon76-dig | I don't think that second define is worth much now |
| 21:09.31 | Corydon76-dig | putnopvut: yeah, because if memory fails, we already output an error |
| 21:09.45 | LauPro | using STATIC_MODULES and get I this error: multiple definition of `__lll_unlock_wake_private |
| 21:10.11 | LauPro | STATIC_BUILD* |
| 21:14.36 | LauPro | ok fixed it, thanks for the embed tip |
| 21:22.27 | niekvlessert | hello, how would you do an attended transfer (with Aastra SIP phones) when you want to be able to do some dialplan stuff when it happens? |
| 21:22.36 | *** join/#asterisk-dev bklang (~bklang@tesla.alkaloid.net) |
| 21:28.07 | *** join/#asterisk-dev ZX81 (~Matt_Ridd@121-74-248-216.telstraclear.net) |
| 21:28.47 | *** part/#asterisk-dev ZX81 (~Matt_Ridd@121-74-248-216.telstraclear.net) |
| 21:37.49 | mvanbaak | meh, that bug with free ram .... |
| 21:38.12 | mvanbaak | a system for asterisk with 12GB ram ... |
| 21:49.22 | *** join/#asterisk-dev dseeb_ (~Adium@CPE-58-169-81-65.lns1.bat.bigpond.net.au) |
| 21:55.27 | niekvlessert | mvanbaak: how would you do an attended transfer (with Aastra SIP phones) when you want to be able to do some dialplan stuff when it happens? Should I listen to AMI if it happens? Should I implement it myself in some php instead of using the Aastra feature, with a meetme for example? |
| 21:58.22 | mvanbaak | we did it in php |
| 21:59.54 | niekvlessert | k thx |
| 21:59.57 | mvanbaak | if you do an attended transfer on the aastra phone, it's possible asterisk does not know about it |
| 22:00.16 | niekvlessert | possibly, that would suck |
| 22:00.30 | mvanbaak | the call is put on hold on the phone, and the phone is starting a second call |
| 22:00.41 | mvanbaak | no need to instruct asterisk to do all the magic |
| 22:00.49 | *** part/#asterisk-dev shin-shoryuken_ (~shin-shor@hephaestus.restechservices.net) |
| 22:00.59 | mvanbaak | only if you use features.conf attended transfer you know for sure asterisk knows about it |
| 22:01.13 | mvanbaak | but the 'smart' features of a phone happen in the phone, not in asterisk |
| 22:01.22 | niekvlessert | yeah, but is there not some place in the sip header where it gets mentioned that it's happened? |
| 22:01.26 | mvanbaak | and it's up to the phone to provide some info about it to the proxy |
| 22:02.33 | mvanbaak | yeah, it's possible there's a sip header, but it's not needed |
| 22:03.18 | mvanbaak | depends on the phone (and possibly also on the firmware version loaded into the phone, or phone settings) |
| 22:03.31 | niekvlessert | downloading aastra admin guide now.. |
| 22:03.45 | mvanbaak | I wouldn't put my money on the 'there should be sip headers about it' assumption |
| 22:04.26 | niekvlessert | so if there are i could check if it's happening through ami right? |
| 22:04.46 | mvanbaak | we always programmed the transfer key of the phones to send some DTMF sequence to asterisk, and this sequence triggered an agi script |
| 22:04.57 | mvanbaak | yeah, then you can use ami |
| 22:05.41 | mvanbaak | the benifits of the agi (at least in our opinion) is that you can do smart attended transfer |
| 22:05.59 | niekvlessert | interesting. because Aastra has a weird way of doing transfers, users don't get. It might be good to implement our own way |
| 22:06.14 | mvanbaak | like, we checked if the far end was busy or had a meeting in their calendar and give the ppl starting the transfer some feedback before even attempting the transfer |
| 22:06.27 | niekvlessert | sweet |
| 22:07.07 | mvanbaak | you can do all kinds of stuff that way :) |
| 22:07.31 | mvanbaak | if you have a collegue you dont like you simply play weasels.gsm instead of starting the transfer agi ;) |
| 22:07.52 | niekvlessert | SIP Message Sequence for Blind Transfer |
| 22:10.25 | mvanbaak | btw |
| 22:10.25 | niekvlessert | :) |
| 22:10.45 | mvanbaak | does somebody know of a webbased config system for asterisk that can handle multiple asterisk servers ? |
| 22:11.07 | mvanbaak | it should also be multitenant |
| 22:11.16 | mvanbaak | there are some for a single asterisk box |
| 22:11.31 | mvanbaak | but I want to manage 30 asterisk boxen with a single webinterface |
| 22:11.43 | niekvlessert | we're building that |
| 22:11.48 | niekvlessert | not there yet |
| 22:11.50 | niekvlessert | :) |
| 22:11.58 | mvanbaak | If I create a new customer, I dont care what server they are going to end up on, as long as the software knows it |
| 22:12.17 | mvanbaak | hhmm, interesting |
| 22:12.18 | niekvlessert | i believe what should happen in such a case is that a new VM is created which boots from pxe |
| 22:12.30 | mvanbaak | no, that's not what I mean |
| 22:12.32 | niekvlessert | it should mount the asterisk stuff through nfs |
| 22:12.43 | niekvlessert | and all that should be configurable in 1 gui |
| 22:13.01 | mvanbaak | that means: 1 vm per customer |
| 22:13.05 | niekvlessert | true |
| 22:13.12 | mvanbaak | that's not what I'm looking for |
| 22:13.21 | mvanbaak | because that's not scalable enough |
| 22:13.22 | niekvlessert | why not, get a VM cluster :) |
| 22:13.50 | mvanbaak | well, right now we host roughly 50 to 60 customers on one asterisk instance |
| 22:13.53 | *** join/#asterisk-dev cusco (~trilili@2001:0:53aa:64c:1406:7aaa:a077:acde) |
| 22:13.56 | cusco | hi |
| 22:13.59 | cusco | how can I find out if the patch for issue 0015609 is in 1.6.2.3 rc2 ? |
| 22:14.19 | mvanbaak | cusco: is it committed to 1.6.2 branch ? |
| 22:14.25 | mvanbaak | cusco: should say so in the bugnotes |
| 22:14.48 | mvanbaak | niekvlessert: so instead of this one instance we need 50 vm's in your setup |
| 22:15.01 | niekvlessert | oh, so they're small customers |
| 22:15.11 | niekvlessert | how many users would you want on 1 system? |
| 22:15.20 | mvanbaak | most of them under 30 extensions yes |
| 22:15.44 | mvanbaak | we now stop at 1000 sip devices |
| 22:16.18 | mvanbaak | MAX_SIP_USERS_PER_PBX is set to 1000 |
| 22:16.57 | cusco | mvanbaak: in the bug notes it states that it is svn revision 236985 |
| 22:17.08 | mvanbaak | cusco: in what branch ? |
| 22:17.11 | cusco | how can I find out if that rc is prior or not |
| 22:17.17 | cusco | the one Im after, 1.6.2 |
| 22:17.40 | niekvlessert | yeah, so what you would need is a system that would put in a DB how many sip devices there are on a single box and if there's no room, move along |
| 22:17.54 | niekvlessert | to the next asterisk, which you made ready |
| 22:18.03 | niekvlessert | and then per customer |
| 22:18.03 | mvanbaak | cusco: svn log --stop-on-copy http://svn.digium.com/svn/asterisk/tags/1.6.2.3-rc2 |
| 22:18.28 | niekvlessert | but I guess it's hard to split all the management a user can do when on 1 asterisk right? |
| 22:18.33 | mvanbaak | niekvlessert: yeah, I know what is needed. just wondered if it has been done before |
| 22:18.57 | niekvlessert | yeah, i know you know stuff :) |
| 22:19.08 | mvanbaak | I have it all drawn and written out on my whiteboard. |
| 22:19.20 | mvanbaak | but I dont have the time to code it right now ;) |
| 22:19.56 | mvanbaak | and before starting this project as opensource free-time thingie, I wanted to know if it has been done |
| 22:20.18 | mvanbaak | because if it's already out there .... |
| 22:21.15 | mvanbaak | hhmm, I think I'll do it anyways. the system on my whiteboard is awesome ! |
| 22:21.18 | mvanbaak | ;) |
| 22:21.21 | niekvlessert | so users always remain on the same asterisk box right? No moving around when it's crowded |
| 22:22.21 | niekvlessert | well, what part of such a solution would you create? load balancing |
| 22:22.22 | niekvlessert | ? |
| 22:23.11 | mvanbaak | no, provisioning |
| 22:23.25 | mvanbaak | the system would be able to transfer a customer to another box |
| 22:24.09 | mvanbaak | for the uberadmin (company providing the services) there's a dropdown for every customer that lists all the available boxen |
| 22:24.28 | mvanbaak | when a customer signs up they get assigned a pbx based on current load by the system |
| 22:24.45 | mvanbaak | but uberadmin can alter this, and the system will push the customer configuration to this new box |
| 22:25.11 | mvanbaak | and set the dns records and registration timeout so the phones will send a re-register |
| 22:26.18 | mvanbaak | a simple getHostForCustomer('mvanbaak'); would return the current active pbx for this customer |
| 22:26.50 | mvanbaak | the system should be push based as well |
| 22:27.18 | mvanbaak | so customer alters their voicemail pin, our backend sends a soap call to the getHostForCustomer() box to alter the pin |
| 22:27.21 | mvanbaak | stuff like that |
| 22:28.00 | niekvlessert | you could decide the register ip moves along to the other box? would mean less downtime. so every customer gets their own register ip |
| 22:28.35 | mvanbaak | yes |
| 22:29.15 | mvanbaak | that's the idea |
| 22:29.23 | niekvlessert | sounds interesting! |
| 22:29.30 | cusco | mvanbaak: thanks. that fix is in place then |
| 22:29.46 | *** part/#asterisk-dev cusco (~trilili@2001:0:53aa:64c:1406:7aaa:a077:acde) |
| 22:29.52 | mvanbaak | niekvlessert: my idea :) |
| 22:30.05 | niekvlessert | :) |
| 22:30.57 | niekvlessert | hmmm lot's of stuff going through my mind now :) |
| 22:31.35 | mvanbaak | same here |
| 22:31.56 | niekvlessert | you know |
| 22:32.02 | niekvlessert | another approach |
| 22:32.08 | niekvlessert | imagine you have a huge company |
| 22:32.23 | mvanbaak | uhhuh |
| 22:33.23 | niekvlessert | usually a phone has a number by sip account. In our system it has as well, but with that number you can only call 112, otherwise you get an ivr that you should login |
| 22:34.09 | niekvlessert | if you do the system does xml push to the phone and then 'you're logged in'. so the dialplan changes a little, and the phone will 'become' the user's phone |
| 22:34.27 | mvanbaak | hot-desking |
| 22:34.29 | niekvlessert | and will display your name ofcourse |
| 22:34.37 | niekvlessert | yeah |
| 22:34.50 | niekvlessert | but what if you have 15k users |
| 22:35.01 | niekvlessert | and you should be able to hotdesk all over the place |
| 22:35.08 | niekvlessert | then it's getting interesting :) |
| 22:35.14 | mvanbaak | agreed |
| 22:35.21 | mvanbaak | cant do that with 1 box |
| 22:35.37 | niekvlessert | and isdn is local |
| 22:35.43 | mvanbaak | aaaaaah |
| 22:35.51 | mvanbaak | there's something I dont have to worry about ;) |
| 22:36.03 | niekvlessert | yeah, but that's the 2 scenario's |
| 22:36.11 | niekvlessert | big cloud: lot's of small companies |
| 22:36.13 | mvanbaak | ok, got it |
| 22:36.16 | niekvlessert | big cloud: huge company |
| 22:36.21 | mvanbaak | yeah, kwartje valt |
| 22:36.52 | niekvlessert | so how do you do the cloud.... that's what we're currently deciding |
| 22:36.54 | mvanbaak | hhmm |
| 22:37.10 | mvanbaak | I think I would solve that with dundi |
| 22:37.15 | kpfleming | niekvlessert: don't use apostrophes to indicate plurality... it's almost never the correct punctuation (in most cases, there shouldn't be any punctuation) |
| 22:37.53 | Qwell | waits for the theoatmeal link |
| 22:37.58 | kpfleming | not this time |
| 22:38.02 | mvanbaak | lol |
| 22:38.04 | kpfleming | although it's very, very funny |
| 22:38.30 | niekvlessert | or with an opensips + rtp proxy in the middle with a xml pus'h registe'r mysq'l bo'x |
| 22:38.45 | kpfleming | niekvlessert: stop trolling :-) |
| 22:38.56 | mvanbaak | ;) |
| 22:39.28 | niekvlessert | kpfleming: i'll try to not do it... in dutch it's most of the times with the 's |
| 22:39.36 | mvanbaak | at least that would leverage all the synergy! |
| 22:41.18 | niekvlessert | how would you make SURE that no company bothers the other when they're on the same asterisk |
| 22:41.24 | niekvlessert | and what about security |
| 22:41.50 | mvanbaak | it's all about dialplan context's' |
| 22:42.29 | niekvlessert | maybe not para virtualisation but some less CPU consuming form? |
| 22:42.31 | niekvlessert | true. but you could sniff the other traffic |
| 22:42.37 | niekvlessert | maybe do a vlan per user... hmmmm |
| 22:42.43 | mvanbaak | only at pbx level |
| 22:42.44 | niekvlessert | per company |
| 22:42.58 | niekvlessert | is that safe enough? |
| 22:43.00 | mvanbaak | and we dont give customers ssh access to our pbx |
| 22:43.10 | niekvlessert | ofc not, just web |
| 22:43.18 | mvanbaak | so there's nothing to sniff |
| 22:43.50 | niekvlessert | i don't agree right away on that one :) |
| 22:43.55 | mvanbaak | they can put traffic sniffers at their network, but they will only see traffic that belongs to their phones |
| 22:44.27 | mvanbaak | hhmm, you put your customer phones on the same subnet as your pbx ? |
| 22:45.08 | mvanbaak | we give each customer their own registration/proxy ip |
| 22:45.21 | niekvlessert | no! but is there no way to get the sip stuff? |
| 22:45.29 | niekvlessert | ah like that |
| 22:45.32 | mvanbaak | not if it's not for their phones |
| 22:45.59 | mvanbaak | and besides that, it's ptp |
| 22:46.04 | niekvlessert | yeah, so that ip would move along to another asterisk box when it's crowded |
| 22:46.07 | mvanbaak | it's not broadcast or anything |
| 22:46.12 | mvanbaak | yups! |
| 22:46.49 | mvanbaak | and after your remarks about this huge company, I think I'll add some extra stuff here |
| 22:46.50 | niekvlessert | ok i'm gonna have a guy at work make this when we're done with the big system. :) |
| 22:46.54 | niekvlessert | he owns at gui's |
| 22:47.02 | niekvlessert | guis! (?) |
| 22:47.17 | Qwell | GUIs |
| 22:47.26 | kpfleming | wow... someone on asterisk-users wrote FILTER() in dialplan script |
| 22:47.28 | mvanbaak | if a company becomes over say 700 extensions we are going to give them more then one ip |
| 22:48.01 | mvanbaak | and our backend system will devide the users over those ips |
| 22:48.31 | mvanbaak | so when the customer logs in, and creates a new endpoint, the system will show the correct reg-ip for this device |
| 22:48.36 | niekvlessert | what about hotdesking and queues? |
| 22:48.57 | mvanbaak | hotdesking is not a problem |
| 22:49.12 | mvanbaak | that's where dundi helps |
| 22:49.31 | mvanbaak | queues can become interesting |
| 22:49.54 | mvanbaak | unless you create a dedicated queue box |
| 22:50.07 | mvanbaak | (or multiple) |
| 22:50.30 | mvanbaak | and call your agents like SIP/customerboxX/agentX |
| 22:50.45 | mvanbaak | SIP/agentX@customerboxX |
| 22:50.51 | mvanbaak | whatever does the job for you |
| 22:52.31 | mvanbaak | kpfleming: nice ! |
| 22:53.19 | mvanbaak | The_Boy_Wonder: thanks for taking that one ;) |
| 22:54.16 | mvanbaak | I know I've been slacking when it comes to asterisk work |
| 22:54.16 | The_Boy_Wonder | mvanbaak: np, I should be able to bring it to completion tomorrow |
| 22:54.28 | mvanbaak | yeah, it's almost done |
| 22:54.51 | The_Boy_Wonder | yeah, well that patch was nearly there. the only thing i found was a ref counting leak so far |
| 22:55.16 | mvanbaak | nice |
| 22:55.52 | niekvlessert | interesting. xml push capabilities would also be doable, because the aastra only accept from a few ip's |
| 22:57.29 | mvanbaak | think big. xmlpush.voip.israpunt.nl |
| 22:57.59 | mvanbaak | dedicated xml push instance (can be on one of the pbx-en, or a dedicated box, or a vm) |
| 22:58.30 | mvanbaak | xmlpush is one way traffic right ? |
| 22:59.03 | mvanbaak | no other data then ACK needs to be send back IIRC |
| 22:59.14 | mvanbaak | if so, you can even do the xmlpush on the backend :) |
| 22:59.55 | niekvlessert | that's what i meant |
| 23:00.10 | niekvlessert | ok |
| 23:00.13 | niekvlessert | in a few weeks |
| 23:00.20 | niekvlessert | we'll have 2 clouds ready |
| 23:00.25 | mvanbaak | whehehehe |
| 23:00.36 | niekvlessert | double SAN, 10 Gb/s |
| 23:00.50 | mvanbaak | nice |
| 23:01.01 | niekvlessert | with a bunch of nodes |
| 23:01.08 | niekvlessert | will easily run 75 vm's |
| 23:02.09 | niekvlessert | we could use one of them for developing this |
| 23:02.13 | niekvlessert | not kidding here! |
| 23:02.23 | mvanbaak | interesting |
| 23:03.05 | niekvlessert | so i guess we should 'hakken in stukken, zagen in lagen' |
| 23:03.17 | mvanbaak | exactly |
| 23:03.35 | mvanbaak | you cannot do this as 1 thing |
| 23:03.41 | mvanbaak | out of the question |
| 23:03.52 | niekvlessert | a small daemon would have to be in control of this |
| 23:04.08 | mvanbaak | yup |
| 23:04.26 | mvanbaak | actually I was thinking like this |
| 23:04.37 | mvanbaak | the backend knows most of the stuff |
| 23:04.56 | mvanbaak | and does a soap call to the pbx (Controller) when a change is needed |
| 23:05.15 | mvanbaak | the Controller checks if the call is for him, and stores the stuff in a db |
| 23:05.34 | mvanbaak | some cronjob is running on the pbx that reads the local db and applies the changes waiting |
| 23:06.40 | mvanbaak | this controller job will then do a soap call to a special part of the backend (which can later be put on it's own box if load grows) to instruct it to send the customer an email with the new settings |
| 23:07.28 | niekvlessert | but why would he need new settings? |
| 23:07.40 | mvanbaak | settings webpage will do a soap call to ask for current settings of customer, and do a soap call to backend to modify stuff |
| 23:08.07 | mvanbaak | it doesn't have to be new settings |
| 23:08.30 | mvanbaak | but in my experience company admins want something they can forward to a person that is going to manage this |
| 23:08.39 | niekvlessert | agree |
| 23:08.41 | mvanbaak | so send a mail just to be sure |
| 23:08.48 | mvanbaak | even if it has the same settings |
| 23:09.01 | niekvlessert | we seperated frontend (GUI) and backend in a similar way |
| 23:09.12 | mvanbaak | we dont care, the customer has proof everything was setup, and we give the customer something they can forward |
| 23:09.15 | mvanbaak | yups |
| 23:09.37 | niekvlessert | i hate cron jobs |
| 23:09.57 | mvanbaak | we could make it a chain of soap calls |
| 23:10.10 | niekvlessert | why not let the backend create another thread which applies pbx stuff |
| 23:10.10 | mvanbaak | but that will be borked once there's a connectivity problem |
| 23:10.18 | mvanbaak | (believe me, they will happen) |
| 23:10.23 | niekvlessert | agree |
| 23:11.01 | mvanbaak | if you ever had the 'nice' job of fighting a layer2 loop you know what I'm talking about ;) |
| 23:11.43 | niekvlessert | maybe a chain of calls and a cronjob to make sure. :) |
| 23:11.45 | niekvlessert | or what we do: |
| 23:11.57 | niekvlessert | backend updates frontend db field |
| 23:12.05 | niekvlessert | frontend looks at db field with a daemon |
| 23:12.19 | mvanbaak | yeah, a daemon is the other option |
| 23:12.27 | mvanbaak | and not a bad option |
| 23:13.21 | mvanbaak | we do: backend sends soap call to frontend, and frontend runs cron |
| 23:13.37 | mvanbaak | but we can of course replace the cronjob with a daemon in this new setup |
| 23:14.05 | mvanbaak | as long as it's not multithreaded ;) |
| 23:14.19 | mvanbaak | because I HATE multithreading programming |
| 23:14.25 | niekvlessert | me too! |
| 23:14.27 | russellb | me too |
| 23:14.37 | seanbright | multiplexed i/o |
| 23:14.42 | niekvlessert | had a course at school once... with the spaghetti and stuff |
| 23:14.47 | seanbright | that's twice today i have said that. |
| 23:14.49 | mvanbaak | wtf is wrong with fork() ? |
| 23:15.00 | seanbright | i'm pretty excited about it. |
| 23:15.35 | niekvlessert | seanbright: still looking at the ton/npi stuff |
| 23:15.40 | Corydon76-dig | Nothing is wrong with fork(). I just prefer clone(). |
| 23:15.56 | mvanbaak | Corydon76-dig: you must dig bsdm |
| 23:15.57 | russellb | makes obligatory spoon() joke ... |
| 23:16.08 | seanbright | niekvlessert: how long does it take to look? either you can make outbound calls or you can't |
| 23:16.13 | Qwell | points russellb to knife(3) |
| 23:16.22 | seanbright | spork() ftw |
| 23:16.39 | mvanbaak | there is no spoon |
| 23:16.59 | Corydon76-dig | mvanbaak: Unless we're at Spring VON |
| 23:17.00 | niekvlessert | i'm currently able to compile the latest dahdi, but the thing is, on voip-info.org is a chan_dahdi.conf which says you can set ton/npi in dialplan, but the latest dahdi doesn't say it in the example file |
| 23:17.32 | mvanbaak | the only accurate documentation is the source |
| 23:17.46 | mvanbaak | welcome to the wonderful world of opensores |
| 23:18.00 | niekvlessert | nice dutch wordjoke :) |
| 23:18.03 | seanbright | niekvlessert: it may be settable via dialplan, i j |
| 23:18.06 | mvanbaak | yup |
| 23:18.13 | seanbright | ust don't thikn it's supported in the version of libpri you are running |
| 23:18.16 | seanbright | which is what my patch was against |
| 23:18.23 | Corydon76-dig | It IS settable via dialplan |
| 23:18.32 | seanbright | well then there you go |
| 23:18.58 | seanbright | niekvlessert: what version of libpri? |
| 23:19.03 | Corydon76-dig | And it's described fine in chan_dahdi.conf |
| 23:19.12 | niekvlessert | i know, but right now i'm getting there: latest 1.4.29 with 2 patches, latest dahdi, latest libpri, misdn 3dparty digium 1.1.9 (NOT 1.1.9.1) |
| 23:19.28 | niekvlessert | Corydon76-dig: thanks a lot :D |
| 23:19.35 | Corydon76-dig | niekvlessert: line 130 in trunk |
| 23:19.54 | seanbright | oh, well then you can ignore my patch to libpri |
| 23:20.02 | mvanbaak | niekvlessert: yeah, and one of those patches will never be accepted in svn. it's new functionality :( |
| 23:20.08 | seanbright | that only applied to 1.4.3 or whatever you were originally working with |
| 23:20.19 | mvanbaak | niekvlessert: thank god they decided to go a different route with 1.6 |
| 23:20.46 | niekvlessert | seanbright: we got segfaults all over the place, but still not sure if that's because of you |
| 23:20.52 | seanbright | it's not |
| 23:21.01 | mvanbaak | niekvlessert: did accounting ask you about the invoice ? |
| 23:21.05 | mvanbaak | just curious |
| 23:21.12 | Corydon76-dig | Everything is Sean's fault |
| 23:21.18 | niekvlessert | mvanbaak: no(t yet) |
| 23:21.22 | Corydon76-dig | including the snow |
| 23:21.24 | mvanbaak | lol |
| 23:21.27 | seanbright | instead of sending a 1 over the link we sent a 0 |
| 23:21.38 | seanbright | somehow doubt that caused 'segfaults all over the place' |
| 23:21.51 | mvanbaak | unless we expect a 1 |
| 23:21.59 | seanbright | *sending a 1* |
| 23:22.06 | niekvlessert | seanbright: bristuff sucks, i guess it's that :) |
| 23:22.17 | mvanbaak | amen to that |
| 23:22.34 | Corydon76-dig | BTW, Colbert suggested packing snow in an envelope and sending it to Vancouver |
| 23:22.45 | niekvlessert | Corydon76-dig: so the npi/ton stuff is in Dahdi trunk but not in Dahdi stable |
| 23:22.47 | mvanbaak | wtf was he smoking ? |
| 23:22.51 | Corydon76-dig | (since they don't have enough) |
| 23:23.17 | mvanbaak | well, they do have enough ice to kill bulgarians |
| 23:23.20 | Corydon76-dig | niekvlessert: it was always in chan_dahdi, not the driver, anyway |
| 23:23.32 | Corydon76-dig | mvanbaak: Georgians |
| 23:23.44 | mvanbaak | that's what I said ;) |
| 23:24.04 | mvanbaak | s/said/ment/ |
| 23:24.22 | Corydon76-dig | Interesting fact. Did you know that the word "buggar" is a corruption of "Bulgarian"? |
| 23:24.22 | seanbright | niekvlessert: i think the issue was the version of libpri you were using |
| 23:24.34 | niekvlessert | Corydon76-dig: now i get it....... duh... so it's not in 1.4.29, but somewhere between 1.6.0 and trunk it came in............... |
| 23:24.57 | niekvlessert | seanbright: it came as a package |
| 23:25.01 | mvanbaak | Corydon76-dig: did not know that. nice to know |
| 23:25.14 | Corydon76-dig | niekvlessert: it's in 1.6.0, too |
| 23:25.34 | seanbright | goes back to find the conversation |
| 23:25.36 | Corydon76-dig | Line 119 in 1.6.0 |
| 23:27.40 | niekvlessert | seanbright: i reverted stuff to origal, compiled all over, still segfault... maybe the machine is screwed |
| 23:27.53 | mvanbaak | bad ram ? |
| 23:28.02 | seanbright | compile would probably fail in that cast |
| 23:28.06 | seanbright | case* |
| 23:28.22 | mvanbaak | sometimes |
| 23:28.34 | seanbright | most times |
| 23:28.43 | mvanbaak | I can compile OpenBSD in virtualbox without trouble, but bash segfaults big time |
| 23:28.47 | niekvlessert | mvanbaak: machine is stable |
| 23:28.50 | seanbright | five 9s |
| 23:29.10 | mvanbaak | and ls as well |
| 23:29.19 | Corydon76-dig | 5 9s is a dirty word |
| 23:29.23 | mvanbaak | pretty cool to see 'ls /etc' segfault |
| 23:29.58 | seanbright | using gnu software on openbsd |
| 23:30.07 | Corydon76-dig | What they don't tell you is that if they can schedule an outage before it crashes, then the crash doesn't count against their downtime |
| 23:30.08 | seanbright | i thought that was against your religion? |
| 23:30.12 | mvanbaak | since when is ls gnu ? |
| 23:30.20 | seanbright | "but bash segfaults big time" |
| 23:30.25 | mvanbaak | yeah |
| 23:30.28 | mvanbaak | ok ok |
| 23:30.55 | Corydon76-dig | It was interesting to hear that flex is not GNU |
| 23:30.55 | mvanbaak | zsh and ksh have the same problem |
| 23:31.18 | mvanbaak | gheh, and csh as well |
| 23:31.40 | mvanbaak | I blame virtualbox |
| 23:32.14 | mvanbaak | let me rephrase that |
| 23:32.19 | mvanbaak | I blame virtualisation |
| 23:33.32 | mvanbaak | virtualisation is like communism. It looks great on paper but sucks in reality |
| 23:33.46 | niekvlessert | lol |
| 23:35.01 | niekvlessert | ok, i know, will do our certification with an asterisk 1.6 box, so the npi/ton stuff works, then we have the autograph for asterisk, that's all that matters |
| 23:35.35 | mvanbaak | whehehehehe |
| 23:35.52 | mvanbaak | niiiiiiiiice |
| 23:36.06 | niekvlessert | stupid thing: i could also use an audiocodes to do the PRI stuff with a digium sticker on it |
| 23:36.17 | niekvlessert | the guy with us would'nt even notice |
| 23:36.17 | mvanbaak | yup |
| 23:36.33 | niekvlessert | wouldn't |
| 23:37.16 | mvanbaak | we have a wiki page called Security_Policy |
| 23:37.26 | mvanbaak | it has <h1> with Security Policy |
| 23:37.31 | niekvlessert | pretty nice. Brands like siemens, ericsson and other fossils are allowed to connect to grip |
| 23:37.34 | mvanbaak | rest of the page is lorum ipsum |
| 23:37.35 | niekvlessert | then asterisk as well |
| 23:37.45 | mvanbaak | they never looked at it |
| 23:38.32 | mvanbaak | they simply checked the box 'has appropiate security policy and risk analysis' |
| 23:38.41 | niekvlessert | btw irc stuff doesn't get on google automatically right? then i would have to change my nick ;) |
| 23:38.41 | mvanbaak | based on a <title> and <h1> tag |
| 23:39.03 | niekvlessert | lol |
| 23:39.07 | niekvlessert | but you'll win in court |
| 23:39.12 | niekvlessert | that's all |
| 23:39.14 | mvanbaak | yups ! |
| 23:40.03 | mvanbaak | just give the guys a nice time and a good meal with shitloads of booze and you're fine |
| 23:40.32 | mvanbaak | that's the way to buy certification |
| 23:41.05 | mvanbaak | hhmm, I should be in bed for at least an hour already |
| 23:41.18 | mvanbaak | maybe it's time to give in and actually go to bed |
| 23:42.07 | mvanbaak | cats are getting nervous. they think they wont get any food here anymore ;) |
| 23:42.56 | mvanbaak | niekvlessert: talk to you later. good luck with the cert guys |
| 23:43.16 | niekvlessert | mvanbaak: sleep well |
| 23:43.22 | niekvlessert | it's way to late for me as well |
| 23:43.36 | niekvlessert | but i'm doing all kinds of stuff :( |
| 23:48.27 | *** part/#asterisk-dev korihor (~korihor@190.205.251.97) |