| 00:35.03 | *** join/#asterisk-dev obnauticus (~obnauticu@about/windows/regular/obnauticus) |
| 01:12.13 | *** join/#asterisk-dev Deeewayne (~dwayne@c-71-207-214-190.hsd1.al.comcast.net) |
| 01:12.13 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 02:38.40 | *** join/#asterisk-dev miguel3239 (~miguel323@ns1.nashuacs.com) |
| 04:03.40 | *** join/#asterisk-dev diegomad (mad@190.158.78.204) |
| 04:48.45 | *** join/#asterisk-dev cobolfoo (~cobolfoo@70.52.71.17) |
| 04:49.07 | cobolfoo | Hello, there is a way to load /dev/dahdi files with another user than root? |
| 04:49.18 | cobolfoo | I can do a chmod/chown myself but it reset on every reboot |
| 04:51.47 | cobolfoo | I put a chown line directly in /etc/init.d/dahdi in load_module() function, there is something better than that? |
| 06:56.11 | *** join/#asterisk-dev mpe (~mpe@gate.ipvision.dk) |
| 06:59.49 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 07:27.07 | *** join/#asterisk-dev Deeewayne (~dwayne@c-71-207-214-190.hsd1.al.comcast.net) |
| 07:27.07 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 07:44.32 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 08:23.12 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 08:23.13 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 09:03.38 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 09:03.38 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 10:01.10 | *** join/#asterisk-dev ApOgEE (apogee@gateway/shell/bshellz.net/x-mjzwbmvfsyxvydby) |
| 12:19.30 | tzafrir_laptop | wonders how no-reply@dropbox.com managed to subscribe to the dev list. |
| 12:21.29 | *** join/#asterisk-dev jnicola (~quassel@186.124.123.2) |
| 12:22.31 | jnicola | people... i did a capture with wireshark.. |
| 12:23.02 | jnicola | A and B are registered in asterisk, but asterisk send the invite to billing proxy and invite comes back to the asterisk |
| 12:23.07 | jnicola | A -> asterisk -> proxy -> asterisk -> B |
| 12:23.16 | jnicola | invite is ok... but 200ok ACK and BYE, are never routed through the proxy |
| 12:24.22 | jnicola | <PROTECTED> |
| 12:25.32 | jnicola | but...bye messages is not sent through the proxy,, |
| 12:26.11 | jnicola | i red about bug 7403 |
| 12:26.51 | mvanbaak | tzafrir_laptop: I wonder as well |
| 12:27.01 | mvanbaak | tzafrir_laptop: got the mail and was like: huh ? |
| 12:27.29 | jnicola | any path could work with asterisk 1.4.30 ? |
| 12:27.34 | jnicola | patch |
| 12:45.55 | *** join/#asterisk-dev eliel (~eliels@201.234.94.226) |
| 12:45.55 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 13:05.41 | pabelanger | morning |
| 13:21.49 | eliel | pabelanger: morning! |
| 13:23.59 | atis_work | afternoon :) |
| 13:40.44 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 13:43.46 | eliel | 10:43am |
| 13:47.35 | mvanbaak | being awake for 33 hours is fun |
| 13:47.46 | hurdman | mmh 15:47 pm |
| 13:48.18 | *** join/#asterisk-dev caio1982 (~caio1982@CAcert-br/caio1982) |
| 13:50.41 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 13:50.41 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 13:52.49 | atis_work | 16:52 |
| 13:53.21 | atis_work | however i just finished my morning coffee at the office :) |
| 14:05.55 | *** join/#asterisk-dev moy (~moy@74.12.128.42) |
| 14:09.25 | *** join/#asterisk-dev wdbl (~not@ool-44c0668f.dyn.optonline.net) |
| 14:39.29 | *** join/#asterisk-dev marv (~timr@24.214.206.254) |
| 14:45.36 | *** join/#asterisk-dev jpeeler (~jpeeler@asterisk/digium-software-dev/jpeeler) |
| 14:45.36 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 14:50.05 | *** join/#asterisk-dev mbranca (~matteo@host139-217-static.224-95-b.business.telecomitalia.it) |
| 15:39.55 | *** join/#asterisk-dev CunningPike (~CunningPi@204.239.8.157) |
| 15:45.31 | *** join/#asterisk-dev elguero (~miguel323@12.187.84.162) |
| 16:57.34 | pabelanger | recompiling custom kernels stinks sometimes |
| 16:58.52 | Corydon76-dig | Quiet day |
| 17:00.18 | pabelanger | too quiet |
| 17:01.25 | file | or not quiet enough |
| 17:04.05 | Corydon76-dig | pokes file with a bridge |
| 17:05.04 | file | dies |
| 17:06.33 | Corydon76-dig | file: I think you have to become a zombie first |
| 17:13.52 | *** join/#asterisk-dev pabelanger (~pabelange@yoda.kanatek.com) |
| 17:17.25 | *** join/#asterisk-dev pabelanger (~pabelange@yoda.kanatek.com) |
| 17:46.58 | atis_work | bridges Corydon76-dig with file<zombie> |
| 17:54.14 | *** join/#asterisk-dev mnick86 (~mnick86@whhem00002.cip.uni-regensburg.de) |
| 17:59.05 | atis_work | hmm, is there some function from outside chan_sip to force load peer from realtime without creating a channel? |
| 17:59.57 | atis_work | i'm looking at ast_request and it seems to proceed with audio initialization, etc |
| 18:00.12 | atis_work | that's too much of what i'd like |
| 18:00.23 | *** part/#asterisk-dev mnick86 (~mnick86@whhem00002.cip.uni-regensburg.de) |
| 18:05.34 | atis_work | or perhaps anyone can explain what does ast_request does and returns? |
| 18:18.02 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 18:18.17 | *** join/#asterisk-dev diegomad (mad@186.81.136.65) |
| 18:31.12 | Corydon76-dig | atis_work: ast_request requests an allocation of a channel, typically for calling later |
| 18:32.42 | Corydon76-dig | It more or less checks whether an outgoing channel is available and reserves it, if so |
| 18:36.52 | atis_work | ah, ok |
| 18:37.26 | atis_work | Corydon76-dig: I managed to get to your fix with rtautoclear, however i'd like to change it so that peer is loaded from realtime whenever it's device state is requested |
| 18:37.53 | atis_work | Corydon76-dig: i see you patched this in M12707 |
| 18:39.28 | atis_work | Corydon76-dig: I'll probably go on changing sip_devicestate back for my own use |
| 18:42.49 | atis_work | perhaps i can add some setting there, as i really want all peers who are somehow accessed to just refresh every N seconds, not just expire and go away |
| 18:49.45 | Corydon76-dig | atis_work: the problem is that when you purge realtime peers out of memory the first thing that happens is it performs a devicestate update. If you remove that fix, your realtime peers will NEVER disappear out of memory for more than a millisecond |
| 18:50.19 | atis_work | well, that's mostly fine with me, as i just want them to refresh data from db, not go away |
| 18:50.25 | Corydon76-dig | atis_work: THAT was the problem |
| 18:50.29 | atis_work | perfectly every devicestate request would reload them |
| 18:50.46 | Corydon76-dig | But that's not what SIP should be doing |
| 18:51.04 | Corydon76-dig | It should allow deregistered peers to exit from memory properly |
| 18:51.17 | atis_work | ah, deregistered it's different case |
| 18:51.35 | Corydon76-dig | Yeah, if the peer is registered, it should not disappear out of memory |
| 18:51.50 | atis_work | i think i'll still haev to fix schedulers, as deregistration is currently on the same scheduler as autoexpire.. i want them separate |
| 18:52.20 | Corydon76-dig | Now you see why you need the fix |
| 18:52.53 | Corydon76-dig | and yes, if a scheduler is dual purpose, that might explain why you thought you needed to remove that code, but in fact, it's a different problem |
| 18:53.47 | atis_work | ah, so you think if i make separate schedulers for registration timeout/autoclear then it will just go away? |
| 18:54.02 | Corydon76-dig | Yes, I believe so |
| 18:54.09 | atis_work | ok, let's try that first |
| 18:54.30 | atis_work | i'll revert back one of our production servers, as it's currently broken :D |
| 18:54.37 | atis_work | i was playing on it :) |
| 18:54.42 | Corydon76-dig | autoclear should be registration timeout, actually |
| 18:54.49 | atis_work | why? |
| 18:54.56 | Corydon76-dig | I think that's the default, unless you force it to be another interval |
| 18:54.56 | atis_work | it shouldn't |
| 18:55.14 | atis_work | well, i noticed that autoclear works perfectly until peer reregisters |
| 18:55.25 | atis_work | then registration just overwrites autoclear |
| 18:55.34 | Corydon76-dig | Because that was the idea... automatically clear it out of memory when registration expires |
| 18:55.59 | atis_work | well, i wanted to use it for something different.. for refreshing peer data from db |
| 18:56.09 | Corydon76-dig | that's why registration overwrites autoclear... because a refresh of registration should cause the timer to be reset |
| 18:57.17 | Corydon76-dig | If you want to refresh peer data from db, why aren't you instead pruning the realtime db? |
| 18:57.39 | atis_work | do you mean "sip prune realtime peer all"? |
| 18:57.51 | Corydon76-dig | Pruning allows the data to be flushed, and it will reload from db the next time the peer is referenced |
| 18:58.25 | atis_work | well, not really, sip_devicestate will just ignore it |
| 18:58.37 | atis_work | and i don't want to do that from script every 10 seconds |
| 18:58.52 | Corydon76-dig | Then don't prune the whole db, just prune the peers you alter in the db |
| 18:59.16 | atis_work | hah, they are too many.. actually ~400 peers changing all the time |
| 18:59.34 | Corydon76-dig | Why are they changing in the db independent from Asterisk? |
| 18:59.45 | atis_work | because there's another asterisk on the same db |
| 18:59.56 | Corydon76-dig | Oh, see, there's the problem |
| 19:00.04 | Corydon76-dig | You shouldn't be doing that |
| 19:00.27 | atis_work | well.. umm, i have to |
| 19:00.34 | Corydon76-dig | Why? |
| 19:00.44 | atis_work | otherwise it would be way too complex to implement clustered queue |
| 19:01.37 | Corydon76-dig | you want a different realtime storage that stores the devicestate for sharing |
| 19:01.57 | Corydon76-dig | Or really, you want distributed devicestate, which is a completely different animal |
| 19:03.15 | Corydon76-dig | and realtime wasn't really meant as a method for distributing devicestate. Not appropriate use of that resource |
| 19:03.51 | atis_work | well, i tried setting up distributed devicestate, but russellb couldn't help me with setting it up (it just didn't compile), and it would have some flaws i already fixed with distributed chan_sip |
| 19:04.32 | Corydon76-dig | Yeah, but this is just the wrong approach |
| 19:04.44 | atis_work | it would just push new state not caring about previous state.. however state can change simultenously on more than one server |
| 19:04.45 | Corydon76-dig | It won't scale the way you want |
| 19:05.39 | atis_work | well, i believe i can fix problems with chan_sip so that it fits, which wasn't true for distributed devicestate |
| 19:05.51 | Corydon76-dig | You really need distributed devicestate, so that it will scale |
| 19:06.28 | Corydon76-dig | You're running into scaling problems right now |
| 19:06.47 | Corydon76-dig | You're fixing little problems, but running into the elephant in the room |
| 19:07.24 | atis_work | well, the problem is that server A will push state of device 123 as INUSE, then server B will also put device 123 INUSE, then server A puts it NOT_INUSE and - here it's available |
| 19:07.58 | atis_work | and i already mentioned - i tried to set it up, but russellb couldn't help me as he wrote that long time ago |
| 19:08.03 | atis_work | so it just doesn't compile |
| 19:08.49 | atis_work | distributed device state needs a way to keep count of device uses on each server and set state depending on that |
| 19:09.02 | Corydon76-dig | So work on that |
| 19:09.08 | atis_work | i have it already :) |
| 19:09.20 | Corydon76-dig | Not scalably |
| 19:09.26 | atis_work | ah, there's also cool topic - distributed locking |
| 19:14.06 | Corydon76-dig | I could see the way you're doing it maybe working reliably for up to 50 peers, perhaps, but above that point, you'll run into the scalability problems you're attempting to solve |
| 19:14.49 | Corydon76-dig | At some point, you're going to need to cut your losses and find a better solution |
| 19:14.59 | atis_work | youre underestimating mysql power on tables with <10k records :) |
| 19:15.31 | Corydon76-dig | I'm not talking about MySQL. I'm talking about the realtime infrastructure. |
| 19:33.17 | *** join/#asterisk-dev elguero (~miguel323@12.187.84.162) |
| 19:34.46 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 19:35.27 | *** join/#asterisk-dev diegomad (~mad@190.146.200.120) |
| 19:43.46 | *** join/#asterisk-dev mcateer (~jmcateer@75.76.254.162) |
| 20:44.42 | *** join/#asterisk-dev Deeewayne (~dwayne@c-71-207-214-190.hsd1.al.comcast.net) |
| 20:44.42 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 20:53.34 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189.24.87.110) |
| 21:23.49 | *** join/#asterisk-dev miguel3239 (~miguel323@12.187.84.162) |
| 21:44.14 | *** join/#asterisk-dev jtodd (vlv96qfsmj@asterisk/community-director-and-tie-dye-shirt-lover/jtodd) |
| 21:44.14 | *** mode/#asterisk-dev [+o jtodd] by ChanServ |
| 21:44.26 | *** join/#asterisk-dev philipp64 (~chatzilla@mail.redfish-solutions.com) |
| 21:56.56 | Deeewayne | M17078 has been verified by the reporter to be fixed. Reviewboard has the patch if anyone has time for a simple review. https://reviewboard.asterisk.org/r/611/ |
| 22:31.51 | *** join/#asterisk-dev hluesea (~hluesea@88.247.127.66) |
| 23:28.38 | *** join/#asterisk-dev [psy] (~psy0rz@lounge.datux.nl) |
| 23:29.25 | [psy] | in what kind of AMI events can i find presence information? (like dnd) |
| 23:57.29 | hardwire | http://hardwire.pastey.net/135025 |
| 23:57.35 | hardwire | I'm assuming that would work just fine |
| 23:58.12 | hardwire | Personally, I'd use that to determine route selection (may be more useful than the timestamp) |