| 00:00.16 | gtjoseph | WIMPy: are you ok with the semicolon/dialplan save fix going onto 12 onwards or do you need it in earlier versions? |
| 00:00.41 | WIMPy | I don't need it at all. |
| 00:00.58 | gtjoseph | even better. :) |
| 00:01.00 | WIMPy | I just came up with it because of an discussion in #asterisk. |
| 00:01.07 | gtjoseph | gotcha |
| 00:01.36 | WIMPy | I had enough motivation at that point to try if it actually worked. |
| 00:20.29 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-cgboqylhwhhzcfhz) |
| 00:27.20 | *** join/#asterisk-dev ipengineer (~zconkle@108-206-120-218.lightspeed.mckntx.sbcglobal.net) |
| 00:28.03 | ipengineer | coreyfarrell: Your suggested fix must have worked because I am no longer seeing res_hep.c in the memory summary |
| 00:31.20 | coreyfarrell | ipengineer: thanks for testing, I'll get a review posted soon |
| 00:31.58 | ipengineer | no problem.. Glad we found it.. If they call all be that easy weâd have it made! :) |
| 00:32.16 | ipengineer | could* |
| 00:33.14 | file | is overjoyed to find out he can indeed put electronics in his recycling |
| 00:35.13 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 00:35.14 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 01:12.19 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 01:12.19 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 01:12.27 | mjordan | coreyfarrell: your first Asterisk 11 run - https://bamboo.asterisk.org/bamboo/browse/AST-ATSRC0-C632TE-1 |
| 01:12.31 | mjordan | just a few failures ;-) |
| 01:13.24 | coreyfarrell | ok well that's very different from what happens on my system |
| 01:13.41 | mjordan | heh |
| 01:13.58 | mjordan | I took a look at a few of them, looks like res_odbc and I would *guess* one channel driver is accounting for almost all of it |
| 01:14.25 | coreyfarrell | oh yeah, I don't even build res_odbc |
| 01:15.13 | mjordan | this is the script the agents use - http://svn.asterisk.org/svn/testsuite/bamboo/trunk/bin/build-asterisk-only.sh |
| 01:17.22 | coreyfarrell | ast_format_cap_add really sucks for not using caller info for REF_DEBUG |
| 01:17.30 | mjordan | options passed to it are -v -e app_voicemail -e app_directory -e test_voicemail_api -e FILE_STORAGE -e REF_DEBUG -d chan_pjsip -d res_pjsip |
| 01:18.03 | mjordan | coreyfarrell: yeah... it makes it very hard to figure out what is running. That does enable every channel driver, and the system has all the libraries for just about any of them |
| 01:18.21 | mjordan | I'd guess one of the extended or deprected channel drivers doesn't clean up its format capability structure for its channel technology |
| 01:24.46 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 01:24.46 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 01:27.08 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 01:27.15 | coreyfarrell | I just skimmed source of all the channel drivers that I can't build, they all seem to cleanup the format_cap at unload |
| 01:28.13 | *** join/#asterisk-dev nix8n82 (~AndChat56@2600:100e:b025:9700:75c8:3ae8:91cb:da6c) |
| 01:28.34 | coreyfarrell | well I just checked 13.. need to see what else is in 11 (probably one of those modules we removed) |
| 01:30.23 | coreyfarrell | chan_jingle leaks jingle_tech.capabilities :) |
| 01:31.31 | coreyfarrell | mjordan: can you just disable build of chan_jingle? |
| 01:31.47 | mjordan | yup |
| 01:31.51 | coreyfarrell | for 11 that is.. not sure what would happen if you try to disable a module that doesn't exist (ie in 13) |
| 01:32.07 | mjordan | should get caught on the next run |
| 01:32.16 | mjordan | and it won't care - it tries to disable chan_pjsip in 11 :-) |
| 01:32.29 | mjordan | and updated |
| 01:32.49 | mjordan | once the backlog clears out I'll kick off another manual run |
| 01:33.44 | coreyfarrell | sorry also disable res_odbc, I don't know what would be needed to enable unloading.. I assume few or no tests require it |
| 01:35.12 | coreyfarrell | if someone fixes res_odbc we can turn it back on, but I don't want it polluting the results |
| 01:36.36 | coreyfarrell | and it looks like it's trying to do trunk right now.. if you have the ability to abort the current job I'd say go for it, since we know the entire thing will fail |
| 01:38.01 | mjordan | hey, 9 passed |
| 01:38.27 | coreyfarrell | so 9 tests don't run asterisk or otherwise have autoload=no? |
| 01:38.36 | mjordan | apparently :-P |
| 01:38.40 | mjordan | or are lua tests |
| 01:38.46 | mjordan | if you want to take a quick peek in the 13 failures and see if there's anything else we want to cancel |
| 01:39.08 | coreyfarrell | ah yeah i'll check it out now |
| 01:39.34 | mjordan | res_odbc disabled |
| 01:39.40 | *** join/#asterisk-dev dms1 (~dms1@172.56.4.168) |
| 01:40.33 | coreyfarrell | 13 is fine (res_odbc is the only leak in the first test I looked at) |
| 01:43.52 | coreyfarrell | glad you ran the test now, I would have been disappointed if I didn't find this out until Sunday :) |
| 01:48.34 | coreyfarrell | fastagi tests are really lame... they keep freezing on my system |
| 01:52.10 | gtjoseph | they freeze for me too. |
| 01:52.45 | coreyfarrell | gtjoseph: hey how are you! |
| 01:53.00 | gtjoseph | muddling along. :) |
| 01:56.52 | coreyfarrell | so I don't know if you've had a chance to check it out, I added notification to ao2 weak objects.. should allow us to eventually use it to create an ao2_container that transparently uses weak objects and automatically removes dead objects |
| 01:57.33 | gtjoseph | cool. it's on my list :) |
| 01:58.18 | *** join/#asterisk-dev dms1 (~dms1@2601:0:5480:5c00:fc13:6aa9:da25:6d6) |
| 01:58.32 | coreyfarrell | one thing that might need to do be done though is to have the notification callbacks run after the weak object is unlocked or even have it run in a separate thread.. could have a risk of deadlock if the callback tries locking something |
| 02:00.45 | gtjoseph | yeah, that wouldn't be good. damn those pesky callbacks where you can't control what happens. |
| 02:02.56 | coreyfarrell | yeah so probably need to copy the callback list to a temporary structure and run them from another thread.. maybe use a taskprocessor |
| 02:04.26 | gtjoseph | like real garbage collection maybe :) |
| 02:05.12 | coreyfarrell | well no.. the notifications are letting the subscriber know that the 'real' object is already gone |
| 02:06.01 | gtjoseph | ah, i gotcha |
| 02:06.51 | coreyfarrell | so for example if we decide to implement weak container's we can have it ao2_unlink from the callback to remove the weak object that now points to NULL |
| 02:08.35 | gtjoseph | a little late in the day for me to fully digest that. besides i'm waiting for the mega-millions drawing to see if I can retire. |
| 02:08.57 | coreyfarrell | good luck :) |
| 02:09.43 | gtjoseph | :) |
| 02:46.41 | *** join/#asterisk-dev terryw (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 03:51.22 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-ejfwlkbwguwkioxx) |
| 03:51.22 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 04:03.53 | *** join/#asterisk-dev tuxd00d (~tuxd00d@wsip-24-255-117-2.ph.ph.cox.net) |
| 06:20.08 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip70-162-151-19.ph.ph.cox.net) |
| 07:06.19 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 07:07.39 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 09:12.02 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:d5ae:8941:e8f0:9a21) |
| 09:33.46 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 09:33.46 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:34.05 | oej | Morning folks! |
| 09:40.11 | tuxd00d | Morning oej |
| 10:02.34 | Stefan27 | does this core-dump make sense to anyone? http://pastebin.com/XFdZFijX |
| 10:14.25 | coreyfarrell | Stefan27: looks like you have optimization turned on |
| 10:14.58 | Stefan27 | is it normal with that many ao_cleanups? |
| 10:15.23 | coreyfarrell | not recursively to my knowledge |
| 10:15.39 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 10:15.40 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 10:27.06 | wdoekes | I believe mark was looking at a similar cdr recursion bt recently |
| 10:27.56 | wdoekes | https://issues.asterisk.org/jira/browse/ASTERISK-24241 |
| 10:28.09 | wdoekes | https://issues.asterisk.org/jira/secure/attachment/51029/backtrace.txt |
| 11:00.53 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 11:00.54 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:14.52 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip70-162-151-19.ph.ph.cox.net) |
| 12:01.19 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 12:01.19 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Asterisk 13.0.0-beta2 now released. Do the (beta) release dance! -=- Follow on Twitter at @AsteriskDev |
| 12:11.31 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 12:11.31 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:35.45 | *** join/#asterisk-dev LooserOuting (~LooserOut@dsdf-4d0a1b89.pool.mediaWays.net) |
| 12:36.04 | LooserOuting | Hi. when you run tests/channels/SIP/directrtpsetup from asterisk test suite at one point phone A will hang up but asterisk sends INVITES to phone B instead of a bye. How can I turn on debugging when starting the test ? |
| 13:11.35 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 13:21.01 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-105-58.user.veloxzone.com.br) |
| 13:21.23 | *** join/#asterisk-dev TazzNZ (~TazzNZ@office-nat1.ytechops.co.nz) |
| 13:21.49 | file | hrm - so Nir is changing the priority to a string in his label fix which is fine for query params... but if it's JSON then that's a problem - do we accept that as JSON in any operations? |
| 13:24.10 | file | I don't... think... so |
| 13:24.53 | anonymouz666 | I am just back from Elastix event! |
| 13:30.31 | *** join/#asterisk-dev LooserOuting (~LooserOut@dsdf-4d0a1b89.pool.mediaWays.net) |
| 13:35.48 | file | opticron, I think I had a question for you but I forgot |
| 13:35.53 | file | anonymouz666, welcome back! |
| 13:51.51 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 13:51.51 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:58.19 | opticron | well, let me know if you remember the question you might have had |
| 14:01.42 | opticron | was it related to SIPp scenarios? |
| 14:01.45 | file | no? |
| 14:02.01 | opticron | or tests of some nature? |
| 14:02.01 | file | although I'll likely ask you how to do what you said on the optimistic SRTP test |
| 14:02.22 | opticron | the check_it_inverse attribute is what you'll want |
| 14:02.49 | opticron | when I said three, I must have been counting some of the BYE responses as well |
| 14:03.37 | file | 1, 2, 3! |
| 14:14.12 | leifmadsen | 1 ah ah ah! |
| 14:14.18 | leifmadsen | twooooo! ah ah ah! |
| 14:21.19 | skrusty | out of interest, why is ari using both 1.1 and 1.2 spec? (1.2 for events, the rest seem to use 1.1) |
| 14:55.57 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-kotgqurtoxymjaai) |
| 14:55.57 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:00.39 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:00.39 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:12.47 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-zmfnblnjbrqwgkiq) |
| 15:25.59 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-hdeknnxbpcmerlow) |
| 15:34.30 | *** join/#asterisk-dev hexanol (~bibi@modemcable094.94-70-69.static.videotron.ca) |
| 15:36.55 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:36.55 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:38.30 | *** join/#asterisk-dev otherwiseguy (~otherwise@99-46-2-71.lightspeed.mssnks.sbcglobal.net) |
| 15:52.02 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-94-139.user.veloxzone.com.br) |
| 15:52.14 | *** join/#asterisk-dev otherwiseguy (~otherwise@99-46-2-71.lightspeed.mssnks.sbcglobal.net) |
| 15:55.40 | *** join/#asterisk-dev terryw (~otherwise@99-46-2-71.lightspeed.mssnks.sbcglobal.net) |
| 16:00.33 | *** join/#asterisk-dev otherwiseguy (~otherwise@99-46-2-71.lightspeed.mssnks.sbcglobal.net) |
| 16:04.18 | *** join/#asterisk-dev dms1 (~dms1@172.56.4.168) |
| 16:16.47 | *** join/#asterisk-dev dms1 (~dms1@172.56.4.168) |
| 16:18.28 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-crwkshstzxwkbgab) |
| 16:58.15 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-sabvwjdfsnqsvefw) |
| 16:58.15 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 16:58.22 | *** join/#asterisk-dev dms1 (~dms1@2601:0:5480:5c00:6859:dc2e:3348:7f14) |
| 17:00.40 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 17:08.22 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 17:08.22 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 17:25.24 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-94-139.user.veloxzone.com.br) |
| 18:28.27 | coreyfarrell | rmudgett: I've found another (related) issue with stringfield allocations. it seems that optimal_alloc_size always returns double or quadruple the amount requested. so when chan_sip runs ast_string_field_init(peer, 512), it actually results in a 2k allocation (including the space used by struct ast_string_field_pool). after the first pool is filled, the next is 8k |
| 18:38.35 | rmudgett | coreyfarrell: That code is weird. It seems the intent was to get a power of two size allocation that is just above the requested size/ |
| 18:39.34 | rmudgett | I don't see where ALLOCATOR_OVERHEAD gets its value. |
| 18:40.03 | coreyfarrell | ALLOCATOR_OVERHEAD is also wrong.. we should probably replace it with sizeof(struct ast_string_field_pool) |
| 18:41.39 | coreyfarrell | the other thing is that most (all?) callers of ast_string_field_init use a power of 2 - 512, 1024, etc. Once we add the overhead for the pool struct, it causes the allocation to be ~4x requested instead of ~2x requested |
| 18:42.11 | coreyfarrell | also add_string_pool has: size_t alloc_size = optimal_alloc_size(sizeof(*pool) + size); |
| 18:42.39 | coreyfarrell | this should probably be: size_t alloc_size = sizeof(*pool) + optimal_alloc_size(size); |
| 18:43.45 | coreyfarrell | and this is why when sip requests a stringfield of 512, the first allocation is 2k, the second is 8k.. I think every time a new pool is allocated it is at least 4x the size of the previous one |
| 18:44.28 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 18:44.30 | coreyfarrell | but I guess the question is do I proceed with what I have "Ship It!" on, start a separate issue? or work these new findings into the existing issue..? |
| 18:45.57 | rmudgett | These are more cleanup changes and not really part of the memory leak issue. |
| 18:46.37 | rmudgett | optimal_alloc_size() does seem to be used incorrectly in the two places it is called. |
| 18:47.19 | coreyfarrell | ok so I have a meeting soon, after I'm done I'll get r4114 committed. then I'll open a new ticket/review to address the incorrect calculation allocation size |
| 19:01.19 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-xvxvytetmyrowwyc) |
| 19:01.19 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 19:03.32 | kharwell | file: for sorcery realtime I created a container to maintain current objects. really though since the other backends do something similar (config, memory) I could push this into sorcery main. any reason why that might be a bad idea? |
| 19:03.58 | *** join/#asterisk-dev benasse (~benasse@cicogna.fr) |
| 19:03.59 | file | kharwell, what do you mean for sorcery realtime - how is it used? |
| 19:05.02 | coreyfarrell | file: I made a first attempt at res_pjsip/res_pjsip_session unloading (for shutdown only). if you have time my patch and strange backtrace are posted to https://issues.asterisk.org/jira/browse/ASTERISK-24485 |
| 19:06.10 | kharwell | file: well each alloc'ed object will get stored in an ao2 container. that way when a reload/lookup/whatever is done it can push an applied and existing object to the consumer (for instance res_outbound_reg) |
| 19:06.43 | file | kharwell, I don't understand |
| 19:07.06 | file | kharwell, like - you are caching the object from realtime in a container? |
| 19:07.14 | kharwell | yeah |
| 19:07.17 | file | uhhhhh |
| 19:07.46 | file | 1. You don't need to do that for outbound_reg and 2. Sorcery has a caching system built-in (albeit not touched much) |
| 19:08.20 | file | coreyfarrell, I'll look in a day or two |
| 19:09.01 | kharwell | file: there needs to be a way to maintain the object so there will be an "existing" object when another lookup is done |
| 19:09.01 | coreyfarrell | file: thanks! |
| 19:09.11 | file | kharwell, why? |
| 19:09.35 | file | you need to store the *state* in a container - and that state object can have a reference to the last configuration |
| 19:10.41 | kharwell | outbound registrations for instance - the can_reuse_reg functions needs the applied and existing object |
| 19:10.55 | file | correct - that's why you hold a reference to it on the state object |
| 19:11.22 | file | you can then compare what has been done in the apply callback to what exists for the state already |
| 19:11.52 | kharwell | I figured why do that, but just reverse it since similar things are already being done. Just keep the object that has a pointer to the state. the way it is now |
| 19:12.17 | kharwell | that way sorcery just knows about objects and there is no sense of some objects are for state and others are not |
| 19:13.06 | kharwell | either way one is caching the realtime data object |
| 19:13.16 | file | the fact it needs the old configuration is an implementation detail of outbound registration |
| 19:13.27 | file | due to how it's ideal to not drop registration and redo it on minor changes |
| 19:14.18 | file | from a "this concept could be used elsewhere" I'd focus on state being the thing that is persisted in-memory |
| 19:14.44 | file | and if the other way were done, it should not act as a local cache within sorcery at all for any sorcery API calls |
| 19:16.29 | kharwell | file: I am curious as to why not? |
| 19:16.40 | file | because there's already a caching mechanism built-in |
| 19:16.55 | file | duplicating it is not good, and ideally you want finer grain control over caching |
| 19:17.06 | file | ie: a method to expire things from a cache, automatic timed expiration |
| 19:19.09 | file | coreyfarrell, I don't know what the heck happened... in there... |
| 19:19.29 | kharwell | file: okay yeah that makes sense |
| 19:20.13 | coreyfarrell | file: somehow stasis_subscription_is_subscribed was called with sub != NULL but sub->topic == NULL -- I can't figure out how this is possible though |
| 19:26.19 | *** join/#asterisk-dev Dovid (~Dovid@static-173-63-105-210.nwrknj.fios.verizon.net) |
| 19:35.31 | coreyfarrell | I did have a few FRACK's before the crash so I'm going to try again with DO_CRASH, I'm guessing it means that something did an extra unref on sub and the memory was already freed |
| 19:35.34 | *** join/#asterisk-dev otherwiseguy (~otherwise@24.27.227.0) |
| 19:44.29 | *** join/#asterisk-dev newtonr (~newtonr@173-17-135-67.client.mchsi.com) |
| 19:44.29 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 19:54.18 | *** join/#asterisk-dev Ta^3 (~tacvbo@187.189.162.201) |
| 20:26.24 | *** join/#asterisk-dev fornax (~fornax@p5797AF3B.dip0.t-ipconnect.de) |
| 20:38.34 | gtjoseph | file: kharwell: when i do ast_sorcery_delete on an outbound registration, the registration's destructor is being called. no other objects do this. Is this expected? |
| 20:39.25 | file | if that drops the last ref, that'll happen |
| 20:39.42 | gtjoseph | yeah, but I still have the ref from the sorcery_alloc |
| 20:40.05 | gtjoseph | and i use the same exact pattern for the endpoint, aor, identify, etc. |
| 20:40.58 | file | something is dropping a ref |
| 20:41.06 | file | well... |
| 20:41.15 | file | yeah. |
| 20:41.17 | gtjoseph | yeah, i'll keep looking. |
| 20:41.27 | file | you could add an abort in the destructor to see the path |
| 20:41.48 | gtjoseph | good idea |
| 21:46.46 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 21:46.46 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 21:51.11 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 22:07.41 | coreyfarrell | gtjoseph: I think I'm dealing with a similar issue in ASTERISK-24485.. when I call ast_sorcery_unref it causes a long chain of destructor's which ends with a crash due to a stasis_subscription being used after it's destroyed.. it's somehow related to endpoints |
| 22:11.22 | gtjoseph | my issue was self-imposed. i made a temp change to outbound registration and forgot to bump a ref count. |
| 22:14.12 | *** join/#asterisk-dev bweschke (~bweschke@74-94-3-210-Philadelphia.hfc.comcastbusiness.net) |
| 22:15.51 | *** join/#asterisk-dev bweschke (~bweschke@74-94-3-210-Philadelphia.hfc.comcastbusiness.net) |
| 22:16.57 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 22:23.37 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 22:23.37 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 22:30.59 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 22:30.59 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 22:44.24 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 22:44.24 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 22:49.59 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 23:12.41 | *** join/#asterisk-dev terryw (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 23:39.27 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 23:41.12 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-xvxvytetmyrowwyc) |
| 23:46.44 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-zmfnblnjbrqwgkiq) |