| 00:14.03 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-wlfvrizudiifvuez) |
| 00:14.03 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 00:35.56 | mjordan | coreyfarrell: hey, if you're around I'm working out some issues for what's left on the media format stuff. How did your investigation into the file API end up? |
| 00:52.57 | coreyfarrell | mjordan: not much progress, but I had some really good chicken wings :) |
| 00:55.42 | coreyfarrell | mjordan: what you missed after you left - http://paste.ubuntu.com/7708755/ |
| 00:57.49 | TazzNZ | makes me think of that "Least I have chicken" video |
| 01:02.35 | TazzNZ | https://www.youtube.com/watch?v=LkCNJRfSZBU <-- that one |
| 01:36.17 | gtjoseph | anyone have any experience with the gcc split-wide-types optimization? |
| 01:36.50 | mjordan | coreyfarrell: I'm curious why we wouldn't release the format in the frame during __frame_free. Are the frames not bumping the reference count to the format? |
| 01:37.46 | coreyfarrell | mjordan: in the case of file.c, the frame is being initialized once at the start of ast_filestream, cleaned up with ast_filestream |
| 01:38.09 | coreyfarrell | so unless we want to reinitialize s->fr for every frame... |
| 01:38.12 | mjordan | hm. |
| 01:38.22 | mjordan | it is what it does now. |
| 01:38.34 | mjordan | but yeah, the format doesn't change at all |
| 01:38.38 | coreyfarrell | now as in asterisk 12 or media_formats? |
| 01:38.39 | mjordan | the file format is the file format. |
| 01:38.55 | mjordan | in 12 |
| 01:38.59 | coreyfarrell | ah |
| 01:39.27 | coreyfarrell | I'm going to email you a patch for what I'm working on. |
| 01:39.47 | mjordan | k |
| 01:39.50 | coreyfarrell | right now my test call (Answer+Playback+Hangup) produces only 4 ast_format leaks and no fracks |
| 01:40.12 | mjordan | I've got a few issues made up that are rather general. Basically, once we get format attribute negotiation working, get iax, sip, and pjsip working |
| 01:41.41 | coreyfarrell | I see |
| 01:41.56 | coreyfarrell | well I'll probably do the bulk of the chan_sip testing |
| 01:42.02 | mjordan | It's kind of hard to predict what all we'll run into :-) |
| 01:42.28 | coreyfarrell | I think it's important for testing to be done with REF_DEBUG and possibly DO_CRASH |
| 01:42.32 | mjordan | indeed |
| 01:42.51 | mjordan | asserts are our friend |
| 01:43.09 | coreyfarrell | let me know if you get/don't get the patch I sent |
| 01:44.48 | mjordan | got it |
| 01:45.04 | mjordan | I'm going to go back to digging into packetization. Hopefully I'll get something working tonight |
| 01:45.12 | mjordan | later man - thanks for all the help with this work :-) |
| 01:45.16 | coreyfarrell | no problem |
| 01:45.27 | coreyfarrell | i'm going to keep trying to find the last 4 reference leaks from my test call |
| 02:20.01 | coreyfarrell | mjordan: in res_rtp_asterisk.c how does it prevent conflicts between rtp->f.subclass.frame and rtp->f.subclass.integer? I'm talking about one overwriting the other.. |
| 03:22.07 | mjordan | coreyfarrell: do you mean subclass.integer and subclass.format? |
| 03:22.30 | mjordan | it's a union of three different possible types. The one in use is determined by the frametype |
| 03:23.54 | mjordan | now that I say that, however, there are a few problems in there, in particular with video frames. Video formats have to use subclass.video.format |
| 03:25.11 | coreyfarrell | yup that's what I'm talking about |
| 03:25.24 | coreyfarrell | btw I'm down to 1 leaked reference for ast_format_ulaw |
| 03:26.22 | coreyfarrell | some callers of ast_translator_best_choice were leaking one or both returned formats |
| 03:30.10 | coreyfarrell | mjordan: also on the flip side I think we could be asking for trouble in some places where we ao2_replace(rtp->f.subclass.format, fmt) - like if rtp->f.subclass.integer == 1 |
| 03:32.01 | mjordan | well, really, you have to look at the media type. I know I pushed for adding the video portion to the union, but seeing how it is used in practice, I may suggest we move the video rtp marker bit back up into the frame structure |
| 03:32.06 | mjordan | it's a little too complicated |
| 03:32.40 | mjordan | for the others, I'm not sure |
| 03:33.00 | mjordan | er, not media type. frame type. |
| 03:33.24 | coreyfarrell | how much storage would it take to just not have the union? |
| 03:33.40 | coreyfarrell | I mean aren't we talking about a pointer, an integer, and whatever the video stuff is? |
| 03:36.40 | mjordan | video stuff really exists just so that the structure makes sense |
| 03:36.42 | coreyfarrell | the video actually has struct ast_format as the first field, so that probably isn't really an issue |
| 03:36.57 | mjordan | right. It's more that if you aren't a video frame, the rtp marker bit isn't useful |
| 03:37.09 | mjordan | I'd be fine with a general restructuring of the frame structure so that it made some more sense |
| 03:37.20 | mjordan | the union is less about storage and more about exclusionary types |
| 03:37.24 | coreyfarrell | rtp marker bit == frame_ending? |
| 03:37.30 | mjordan | yeah |
| 03:37.55 | mjordan | the union was less of a concern when things weren't ref counted. |
| 03:38.45 | coreyfarrell | what if we make ast_frame_subclass a struct, and get rid of video (just use subclass.integer for the rtp marker bit) |
| 03:39.52 | coreyfarrell | in my opinion the real problem is that &subclass.integer == &subclass.format... format really should have it's own storage |
| 03:40.01 | coreyfarrell | since it's refcounted |
| 03:43.00 | mjordan | agreed |
| 03:43.36 | mjordan | welp. Packetization defeated me tonight. Have some things to mull over. |
| 03:43.41 | coreyfarrell | I've found myself wishing that ast_frame was an ao2 object, but that's probably too much to get done by 13 freeze |
| 03:43.46 | mjordan | things that use the old format preferences do not mesh will |
| 03:43.59 | mjordan | yeah... |
| 03:44.13 | mjordan | I'm kind of concerned with how much pressure we're exerting on ao2 objects :-) |
| 03:44.18 | mjordan | but I understand your sentiment |
| 03:44.44 | coreyfarrell | it's a trade-off.. we're no longer copying the entire struct ast_format all over the place |
| 03:45.14 | mjordan | I don't have a good feel for whether or not dup'ing a frame when crossing certain boundaries (with thread local storage and caches to prevent lots of memory allocations) is cheaper or not than ao2_alloc + ref'ing |
| 03:45.29 | mjordan | part of the reason that motivated that change in ast_format were two factors: |
| 03:45.44 | mjordan | (1) formats are generally immutable |
| 03:46.04 | mjordan | (2) formats can be large |
| 03:46.17 | mjordan | when Josh did his profiling, we were spending a silly amount of time just moving them around |
| 03:46.38 | mjordan | frames may fit in the same boat |
| 03:46.44 | mjordan | just not sure :-) |
| 03:46.52 | mjordan | a frame is generally immutable once created |
| 03:48.31 | coreyfarrell | we have 27 calls to ast_frdup and 27 to ast_frisolate.. and we don't really work with frames in area's of code that are not performance critical |
| 03:49.05 | coreyfarrell | I agree that profiling would be needed to really know, I'm just thinking out loud |
| 03:49.50 | coreyfarrell | damn I wish I could find this last reference leak |
| 03:52.10 | mjordan | got a ref debug log? |
| 03:52.20 | mjordan | or snippet for the object that leaked? |
| 03:53.28 | coreyfarrell | yup |
| 03:54.17 | mjordan | I'll take a look if you want - I'm fried on packetization for the night |
| 03:54.23 | mjordan | need to sleep on that problem |
| 03:55.17 | coreyfarrell | i'll email you the /var/logs/asterisk/refs filtered to the format leak |
| 03:56.06 | coreyfarrell | it's 4.5MB, is that an issue for your email? |
| 03:57.18 | mjordan | er |
| 03:57.22 | mjordan | tar it? |
| 03:57.27 | mjordan | (or is that tar'd?) |
| 03:57.44 | coreyfarrell | I guess tar would have helped |
| 03:57.51 | mjordan | it worked :-) |
| 03:58.12 | mjordan | holy crap :-P |
| 03:58.19 | mjordan | ast_format_cap_add ... adds some refs |
| 03:59.09 | coreyfarrell | try: cat ast_format_ulaw-leak.txt|cut -d, -f-2,4-6|sort|uniq -c|sort -n |
| 04:01.32 | mjordan | I'm curious what calls ast_format_cap_add that many times |
| 04:03.41 | mjordan | was that for a single call? |
| 04:04.11 | coreyfarrell | yes |
| 04:04.28 | coreyfarrell | inbound call, dialplan: Answer(), Playback(invalid), Hangup() |
| 04:04.54 | coreyfarrell | chan_sip peer locked down to ulaw only, with only ulaw audio installed |
| 04:06.25 | mjordan | I think I found it |
| 04:06.34 | mjordan | channel.c set_format |
| 04:06.40 | mjordan | best_native_fmt |
| 04:06.58 | mjordan | calling ast_translator_best_choice will cause both formats passed to it by reference to get bump'd |
| 04:07.09 | mjordan | we only RAII_VAR best_set_fmt |
| 04:07.26 | mjordan | we copy it to rawformat later |
| 04:07.26 | coreyfarrell | did you apply the patch I included in the email? |
| 04:07.29 | mjordan | er |
| 04:07.30 | mjordan | nope! |
| 04:07.32 | mjordan | not yet |
| 04:07.37 | mjordan | you already caught that one |
| 04:07.40 | mjordan | ? |
| 04:07.40 | coreyfarrell | because it resolves 3 leaks caused by ast_translator_best_choice |
| 04:07.44 | mjordan | k |
| 04:07.45 | mjordan | moving on! |
| 04:08.27 | mjordan | looks at the patch, just to make sure |
| 04:08.48 | coreyfarrell | mjordan: http://paste.ubuntu.com/7709311/ is what I'm looking at right now, the same thing you have with what I believe to be balanced refs removed |
| 04:09.08 | mjordan | hm. |
| 04:09.14 | coreyfarrell | much smaller :) |
| 04:09.17 | mjordan | yes |
| 04:09.55 | mjordan | I looked at the frame patch you sent me; I'm not sure that's going to clean up what I'm seeing |
| 04:10.58 | mjordan | best_native_fmt in set_format is going to get ref bump'd by ast_translator_best_choice, and I'm not sure where in the code it gets cleaned up. I don't see that in the frame patch - but I could be missing it |
| 04:11.19 | coreyfarrell | set_format = channel.c? |
| 04:11.42 | mjordan | yeah |
| 04:11.54 | coreyfarrell | btw I sent you a new patch in the email with the refs leak file |
| 04:12.07 | coreyfarrell | that patch should have RAII_VAR on best_native_fmt |
| 04:12.42 | mjordan | drat |
| 04:12.45 | mjordan | I didn't look at that one. |
| 04:12.49 | mjordan | nevermind! |
| 04:13.48 | coreyfarrell | yeah that patch is much more complete in my "vision" for not always cleaning fr->subclass.format in __frame_free |
| 04:14.46 | mjordan | the de-ref in free_translation matches to one of the ast_format_cap_get_format |
| 04:16.02 | coreyfarrell | i'm down to 11 lines in my reduced ref's |
| 04:16.10 | mjordan | you remove set_next_mime_type? |
| 04:17.21 | coreyfarrell | http://paste.ubuntu.com/7709332/ |
| 04:17.24 | coreyfarrell | yup |
| 04:19.09 | mjordan | your ast_format_cache_set at line 447 will correspond to the container destruction |
| 04:20.42 | mjordan | and line 353 in format_cache corresponds to the shutdown entry in format_cache on line 296 |
| 04:21.14 | coreyfarrell | looks like we have an extra call to ast_format_cap_get_format :( |
| 04:21.58 | coreyfarrell | 71 possible sources for that |
| 04:22.01 | mjordan | yeah |
| 04:22.08 | coreyfarrell | well not really since we're dealing with limited modules |
| 04:22.39 | coreyfarrell | 24 references between chan_sip and main/*.c |
| 04:22.53 | mjordan | and you can rule out the other channel drivers |
| 04:23.39 | mjordan | you didn't use a bridge, did you? |
| 04:24.02 | mjordan | because bridge_make_compatible looks leaky |
| 04:24.08 | coreyfarrell | the possibilities are chan_sip.c, translate.c, format_cap.c, channel.c, sounds_index.c, rtp_engine.c, file.c, format_compatibility.c |
| 04:24.11 | coreyfarrell | no bridge |
| 04:24.20 | coreyfarrell | just call into the 3 line of dialplan.. |
| 04:24.52 | coreyfarrell | format_cap.c is clean |
| 04:27.23 | coreyfarrell | I think it's in chan_sip.c |
| 04:27.26 | coreyfarrell | mjordan: ^^ |
| 04:27.49 | mjordan | k |
| 04:27.56 | coreyfarrell | in process_sdp: tmp_fmt = ast_format_cap_get_format(p->jointcaps, 0); |
| 04:27.59 | mjordan | Found a leak in res_speech and res_pjsip_sdp_rtp |
| 04:28.00 | mjordan | :-P |
| 04:28.45 | coreyfarrell | nice |
| 04:28.59 | mjordan | yup |
| 04:29.07 | coreyfarrell | i'm running the test again see if I can get a leak free call |
| 04:29.11 | mjordan | not the first instance where it gets used, but when AUDIO is the media type |
| 04:30.30 | coreyfarrell | I might have changed a header file :( |
| 04:30.59 | mjordan | heh |
| 04:33.38 | coreyfarrell | yeah I was fiddling with frame.h to see how it would look if we killed subclass, must have accidentally saved |
| 04:34.01 | coreyfarrell | I just reduced the build to chan_sip + res_rtp_asterisk + app_playback |
| 04:37.24 | coreyfarrell | so as far as the API rename goes, I think we need to think about an ABI rename for some functions.. like ast_format_cap_get_format to __ast_format_cap_get_format, with a macro on the original name to handle REF_DEBUG |
| 04:38.10 | mjordan | I'd say that would be nice for any of the ref bumping functions |
| 04:38.57 | coreyfarrell | even if we don't initially get all of the REF_DEBUG functions done we should __ prefix the ABI and setup the macro's |
| 04:39.04 | mjordan | I was hoping to have packetization done by then, but I think I may rename first. I have a feeling ast_rtp_packetization_set is going to die |
| 04:39.23 | mjordan | REF_DEBUG versions of things usually aren't too hard |
| 04:40.08 | mjordan | I am a little worried how much ast_format_cap_add is called and how much it modifies the ref count. That was... crazy. |
| 04:40.52 | mjordan | it also means that ref debug logs are going to be generally worthless on production systems |
| 04:41.04 | coreyfarrell | hmm next build I will make add a malloc(1) every 1000'th call to it, see what valgrind says |
| 04:41.42 | mjordan | that didn't fix it? |
| 04:42.09 | coreyfarrell | fuck |
| 04:42.16 | coreyfarrell | sorry for swearing in the channel |
| 04:42.40 | coreyfarrell | well I definitely found "A" ref leak.. unfortunately it was THE ref leak :( |
| 04:44.10 | mjordan | has been known to drop f bombs |
| 04:44.20 | coreyfarrell | so the possibilities are translate.c, channel.c, sounds_index.c, rtp_engine.c, file.c, format_compatibility.c |
| 04:44.23 | mjordan | blech |
| 04:44.28 | mjordan | I'm going to have to call it a night |
| 04:44.40 | mjordan | if you want a hand digging through logs tomorrow, let me know |
| 04:44.47 | coreyfarrell | i'm going to find this leak tonight |
| 04:44.50 | mjordan | heh |
| 04:44.52 | mjordan | good luck man |
| 04:44.54 | coreyfarrell | then I'm going to post my changes to reviewboard |
| 04:45.01 | mjordan | cool |
| 04:45.09 | coreyfarrell | I know file won't like what I'm doing in __frame_free, but I think it has to be done |
| 04:45.10 | mjordan | I think this does highlight one concern with this change |
| 04:45.29 | mjordan | with as many refs get changed on a format, if it leaks, it's a bear to find |
| 04:45.52 | mjordan | that actually could get worse too |
| 04:46.06 | coreyfarrell | way worse. this is for a single call that is like 10 seconds long |
| 04:46.15 | mjordan | with format attributes, you actually have to generate a new format (and can't use a cached one) if an SDP negotiates format attributes |
| 04:46.22 | mjordan | yeah |
| 04:46.29 | mjordan | we need to figure out what is spamming ast_format_cap_add |
| 04:46.33 | mjordan | that just feels way wrong |
| 04:46.56 | coreyfarrell | yeah I'll do a valgrind test with a leak every 1000'th call to ast_format_cap_add... that will give me a bunch of backtraces |
| 04:47.05 | coreyfarrell | the ast_backtrace kinda sucks |
| 04:47.08 | mjordan | I can't think of any reason why we would need to re-generate a capability structure on every frame (which is all I can think of) |
| 04:47.10 | mjordan | heh |
| 04:47.14 | mjordan | ast_backtrace is useful for some things |
| 04:47.25 | mjordan | I've used it to hunt down who was generating Stasis channel snapshots |
| 04:47.32 | coreyfarrell | I have code someplace that leaks but produces backtraces pretty close to how valgrind looks |
| 04:47.41 | coreyfarrell | i'll have to find it and look into submitting |
| 04:47.47 | mjordan | that'd be cool |
| 04:47.49 | mjordan | anywho |
| 04:47.50 | mjordan | g'night |
| 04:47.53 | coreyfarrell | later |
| 05:49.43 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 05:49.43 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:28.56 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 07:21.57 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 07:40.50 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 07:40.51 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:03.07 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 08:03.08 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:30.36 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 08:47.59 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 08:47.59 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:52.49 | *** join/#asterisk-dev wdoekes (~walter@wjd.osso.nl) |
| 09:27.04 | *** join/#asterisk-dev Tim_Toady (~fuzzy@83.212.108.130) |
| 09:59.09 | *** join/#asterisk-dev danjenkins__ (~dan@nat/digium/x-kmilshgevypgbetv) |
| 10:31.44 | file | catches up |
| 10:32.48 | file | coreyfarrell, all makes sense |
| 10:34.29 | coreyfarrell | turns out ast_media_index_update is responsible for the excessive ast_format_cap_add |
| 10:40.08 | coreyfarrell | I started asterisk, waited a minute then shutdown graceful, then did the same test with a call to Playback(invalid). the test with the call ran ast_format_cap_add 97677 times, without the call was 78 less |
| 10:40.32 | file | yow'sa |
| 10:41.25 | coreyfarrell | I did some debug code for a backtrace every 2500 calls to ast_format_cap_add, all of them had ast_media_index_update in them |
| 10:43.35 | file | that's bizzare |
| 10:47.49 | coreyfarrell | I eventually found a new set of frack's (by calling into dialplan that just does Answer then Hangup).. so I got annoyed and gave up |
| 10:48.39 | file | changing the universe is hard |
| 10:49.37 | file | TGIF! |
| 10:50.44 | coreyfarrell | yeah well the other work I started doing is less hard but more annoying.. I'm packaging Catalyst (it's a perl web platform) |
| 12:06.09 | *** join/#asterisk-dev tgu (~tgu@host-212-68-194-46.brutele.be) |
| 12:16.15 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 12:20.06 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:25.32 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:3d59:c78:415a:d602) |
| 13:06.54 | jameswf | Anyone familiar with the gateway api, do I have to send the whole structure every time to update things or can I just send items to update. |
| 13:37.04 | malcolmd | jameswf: send an e-mail to chinkle@digium.com and he'll chase down the answers for you |
| 13:38.09 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:38.09 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:09.19 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-fcqwnrcipvibcnct) |
| 14:13.28 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-bigplrlqgfenikkt) |
| 14:13.28 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:23.50 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:23.51 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:25.07 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 14:27.23 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-awxqhqjxuqrnbmhg) |
| 14:34.08 | *** join/#asterisk-dev Dovid (~Dovid@static-173-63-105-210.nwrknj.fios.verizon.net) |
| 15:13.57 | jameswf | malcolmd he is on vacation.... what the heck is that? |
| 15:14.20 | jameswf | I thought vacations only happen in the movies |
| 15:15.25 | malcolmd | jameswf: that would explain why he wasn't in the meeting i just came from... :D (we didn't know he was on vacation) |
| 15:15.57 | jameswf | slacker |
| 15:17.47 | [TK]D-Fender | I was a Slacker, but then I switched to CentOS |
| 15:24.09 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 15:24.35 | *** join/#asterisk-dev otherwiseguy (~otherwise@172.56.11.158) |
| 15:32.28 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-vhvpiugysbpilnga) |
| 15:32.28 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 16:13.17 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-hhbceceayvuyapri) |
| 16:13.17 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 16:23.36 | pabelanger | is res_statsd use by anything else in asterisk? |
| 16:24.24 | file | instead of...? |
| 16:24.55 | pabelanger | we'll it's just a statsd client from what I see |
| 16:25.27 | pabelanger | I don't see any dialplan functions |
| 16:25.32 | pabelanger | unless I am missing something |
| 16:26.27 | file | David did it as a proof of concept using Stasis, it doesn't expose dialplan functions or anything |
| 16:27.24 | pabelanger | okay, res_chan_stats uses it |
| 16:32.33 | pabelanger | Ya, would be need to add channel core functionality to a res module |
| 16:33.02 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-84-109-18-138.red.bezeqint.net) |
| 16:33.02 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 16:33.07 | pabelanger | looks like it has some stasis functionality for it |
| 16:37.21 | pabelanger | For now, just going to scrape AMI events and generate the data |
| 16:37.32 | pabelanger | Should be straightforward |
| 16:38.32 | *** join/#asterisk-dev datachomper (~russ@nat/digium/x-drjpagspdvdhhnkj) |
| 16:40.15 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 16:52.17 | *** join/#asterisk-dev danjenkins__ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 16:58.25 | *** join/#asterisk-dev danjenkins_ (~dan@nat/digium/x-gfxctmeugruiqfnh) |
| 17:07.56 | JunK-Y | pabelanger: whats up canadian? |
| 17:14.34 | pabelanger | JunK-Y, slugging away |
| 17:14.48 | pabelanger | where you at these days? |
| 17:15.37 | JunK-Y | been busy lately with work. |
| 17:16.06 | JunK-Y | so now I should be back :) |
| 17:18.38 | JunK-Y | are ya coming to astricon? |
| 17:32.45 | *** join/#asterisk-dev jrose_atDigium (~jrose@nat/digium/x-idhdxyuunvxoowwq) |
| 17:37.36 | pabelanger | JunK-Y, should be |
| 17:51.36 | *** join/#asterisk-dev otherwiseguy (~otherwise@99-46-2-71.lightspeed.mssnks.sbcglobal.net) |
| 17:55.58 | *** join/#asterisk-dev hexanol (~bibi@modemcable094.94-70-69.static.videotron.ca) |
| 18:13.37 | *** join/#asterisk-dev otherwiseguy (~otherwise@99-46-2-71.lightspeed.mssnks.sbcglobal.net) |
| 18:56.20 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-eeuwdlrnlhvxtbbc) |
| 18:56.20 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 19:18.01 | *** join/#asterisk-dev terryw (~otherwise@99-46-2-71.lightspeed.mssnks.sbcglobal.net) |
| 20:28.36 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-170-9.mci.googlefiber.net) |
| 20:31.52 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 20:39.39 | *** join/#asterisk-dev Dovid (~Dovid@ool-2f113d03.dyn.optonline.net) |
| 21:13.44 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-fcqwnrcipvibcnct) |
| 21:15.52 | *** join/#asterisk-dev HeN (uid3747@gateway/web/irccloud.com/x-nvzbzuaibcgieaqb) |
| 21:25.01 | *** join/#asterisk-dev mvanbaak (~michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 21:25.01 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 22:35.28 | *** join/#asterisk-dev coreyfarrell (~cfarrell@2001:4830:117f:2:582c:4bc3:6681:c9d) |
| 22:42.36 | tm1000 | file: it appears as though the asterisk AMI command “MessageSend” doesnt work with PJSIP: “Message technology not found" |
| 22:50.05 | tm1000 | nevermind if I would just read the docs.... |
| 22:50.11 | tm1000 | and the source code,.., |
| 23:53.12 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 23:53.12 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |