| 03:12.58 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 03:12.58 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Many thanks to kpfleming for 7 years of awesome. |
| 03:41.05 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 03:41.05 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 04:07.48 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 04:07.48 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 05:39.10 | *** join/#asterisk-dev Sean-Der (~sean@cpe-68-175-54-64.nyc.res.rr.com) |
| 06:39.08 | jmls1 | morning |
| 06:39.17 | jmls1 | just got this whilst compiling trunk: |
| 06:39.19 | jmls1 | [CC] res_rtp_asterisk.c -> res_rtp_asterisk.o |
| 06:39.20 | jmls1 | res_rtp_asterisk.c: In function âast_rtp_on_ice_tx_pktâ: |
| 06:39.20 | jmls1 | res_rtp_asterisk.c:691: warning: dereferencing type-punned pointer will break strict-aliasing rules |
| 06:39.20 | jmls1 | res_rtp_asterisk.c:695: warning: dereferencing type-punned pointer will break strict-aliasing rules |
| 06:53.28 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 06:53.31 | schmidts | good morning |
| 07:01.58 | *** join/#asterisk-dev ahmadhasssani (~ahmad.2.h@203.130.22.202) |
| 07:02.46 | jmls1 | no, it isn't. |
| 07:03.00 | jmls1 | has a core dump in trunk :'( |
| 07:08.32 | jmls1 | http://pastebin.com/pUL8UL4J |
| 07:08.50 | jmls1 | SVN-trunk-r370726 |
| 07:09.16 | jmls1 | caused by "sip reload" :( |
| 07:14.30 | schmidts | jmlsl ouch could you pastebin the rest of the gdb output |
| 07:16.41 | schmidts | or btw jmlsl could you try rev r370676 |
| 07:16.49 | schmidts | cause in r370677 there was a change in sip reload |
| 07:17.29 | schmidts | also one i have written which make it even more bad :( |
| 07:19.08 | jmls1 | schmidts: you want the bt full ? |
| 07:20.24 | schmidts | yes please |
| 07:20.24 | jmls1 | aw, crap. changed asterisk version already |
| 07:20.45 | jmls1 | I'll see if 676 works, if it does I'll go back to 677 and try again |
| 07:22.19 | jmls1 | hah. wait. still have the old asterisk & gdb running |
| 07:22.32 | jmls1 | how to I get it all dumped to file (I forget) |
| 07:24.28 | jmls1 | set logging on |
| 07:27.07 | schmidts | i also have to search it, give me a second ;) |
| 07:27.40 | schmidts | jmlsl https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace |
| 07:27.45 | jmls1 | http://pastebin.com/1gnEjfu9 |
| 07:27.51 | jmls1 | (it's pretty big) |
| 07:27.53 | schmidts | gdb -se "asterisk" -ex "bt full" -ex "thread apply all bt" --batch -c core > /tmp/backtrace.txt |
| 07:28.22 | schmidts | ok the values are optimized out :( |
| 07:28.38 | jmls1 | ffs. you'd think that I'd remember to do that |
| 07:28.40 | jmls1 | sorry |
| 07:28.48 | schmidts | ;) |
| 07:28.53 | jmls1 | i'll rebuild 677 and try again |
| 07:28.56 | schmidts | is it reproduceable every time? |
| 07:28.59 | schmidts | ok |
| 07:29.21 | jmls1 | yeah |
| 07:29.23 | schmidts | no use one below 677, cause 677 was the change on sip reload |
| 07:29.38 | jmls1 | yeah, thought that you wanted a bt ? |
| 07:29.51 | schmidts | ok ;) |
| 07:29.52 | jmls1 | (a proper bt, that is) |
| 07:29.57 | schmidts | sorry its still too early in the morning |
| 07:30.02 | schmidts | brb need more coffee |
| 07:30.03 | jmls1 | cooooffffffffeeeeeeeeee |
| 07:30.15 | jmls1 | races schmidts for the cofffee |
| 07:32.15 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:29ed:6b18:fae5:6887) |
| 07:59.00 | schmidts | coffee and nikotin done ;) |
| 08:00.13 | jmls1 | dammit. interception by wife. :-D |
| 08:01.22 | jmls1 | urg |
| 08:01.30 | jmls1 | 676 still has the problem |
| 08:01.39 | jmls1 | cleans everything |
| 08:01.43 | jmls1 | lemme start again |
| 08:01.48 | schmidts | ok ;) just to make sure |
| 08:02.10 | jmls1 | oh, and dont_optimize ;) |
| 08:02.24 | schmidts | it was just a guess cause that was the latest change for sip reload i have found |
| 08:07.09 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 08:07.09 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:18.53 | jmls1 | crap |
| 08:19.00 | jmls1 | guess that this isn't good ... |
| 08:19.02 | jmls1 | <PROTECTED> |
| 08:19.02 | jmls1 | <PROTECTED> |
| 08:19.02 | jmls1 | Segmentation fault |
| 08:19.34 | jmls1 | thinks that a move to -10 may be on the cards |
| 08:20.45 | schmidts | segfault on startup ruins every morning ;) |
| 08:24.02 | jmls1 | http://pastebin.com/TXXsicqt |
| 08:25.02 | schmidts | was this on sip reload or allready at startup? |
| 08:25.32 | jmls1 | this was on startup :( |
| 08:26.02 | jmls1 | Revision: 370676 |
| 08:26.13 | schmidts | :( |
| 08:26.31 | schmidts | cseq = 0x7 <Address 0x7 out of bounds> for an incoming OPTIONS message is bad |
| 08:28.19 | jmls1 | thought that out of bounds only happened to him on the golf course |
| 08:28.48 | schmidts | :D |
| 08:29.00 | jmls1 | ok, so where do I find a history of changes ? |
| 08:29.18 | schmidts | http://svnview.digium.com/svn/asterisk?view=revision&revision=370677 |
| 08:29.21 | schmidts | for example |
| 08:30.44 | jmls1 | meant a history of the changesets , not what was in each changeset ;) |
| 08:30.49 | schmidts | but this change was merged into 1.8 and 10 too |
| 08:30.58 | jmls1 | is mecurial guy. |
| 08:31.21 | jmls1 | not this old fashioned svn :P |
| 08:31.25 | schmidts | http://svnview.digium.com/svn/asterisk/trunk/channels/chan_sip.c?view=log |
| 08:32.09 | jmls1 | jsmith: I broke it _again_ ... |
| 08:32.54 | schmidts | ok i have just checked out trunk and have done several sip reloads without any problems |
| 08:33.05 | jmls1 | heh |
| 08:33.08 | schmidts | only the warning for nat=yes is deprecated for EVERY peer is annoying but its working |
| 08:33.25 | jmls1 | in that case I have a problem ... |
| 08:33.26 | schmidts | on this test system i have 4600 peers so its a lot of warnings ;) |
| 08:33.34 | jmls1 | I have one :) :) |
| 08:33.39 | schmidts | :D |
| 08:34.25 | jmls1 | ___interesting___ |
| 08:34.42 | jmls1 | I removed my peer defs , and it loads .. |
| 08:35.02 | schmidts | ok then you should pastebin your peer def :D |
| 08:37.06 | jmls1 | http://pastebin.com/f5TuWyup |
| 08:38.16 | jmls1 | I am #including this from sip.conf (#include /home/my_user/data/asterisk/sip/*) |
| 08:38.36 | jmls1 | this was working recently. I'll have to find the revision that works |
| 08:39.33 | schmidts | hmm empty username and secret maybe thats the problem |
| 08:41.47 | schmidts | i have tried your sip config and it still works |
| 08:42.39 | jmls1 | with a remote ip address ? |
| 08:43.01 | jmls1 | if I enter an invalid ip address (foo) it hangs for a few seconds, can't resolve the host, and loads |
| 08:43.09 | jmls1 | with a valid ip address, boom! |
| 08:44.54 | schmidts | Aug 2 10:40:26] NOTICE[27405]: chan_sip.c:22465 handle_response_peerpoke: Peer '98CTEp5gi' is now Reachable. (1ms / 1000ms) |
| 08:45.23 | schmidts | http://pastebin.com/52yKS8LQ |
| 08:45.46 | jmls1 | hmm. if I comment out host, starts just fine |
| 08:46.22 | schmidts | tcp or udp? |
| 08:46.25 | schmidts | i only use udp |
| 08:46.35 | jmls1 | http://pastebin.com/ZXYTsWav |
| 08:46.36 | jmls1 | udp |
| 08:48.02 | schmidts | strange ;) |
| 08:48.38 | jmls1 | ffs, it's working ... |
| 08:48.45 | schmidts | http://pastebin.com/JpLViP8X |
| 08:48.52 | jmls1 | I was using a sip.conf from -10 |
| 08:48.59 | schmidts | maybe you had some old packages laying around somewhere ;) |
| 08:49.10 | jmls1 | copied the -11 .conf, added the lines back in |
| 08:49.14 | jmls1 | and its fine .. |
| 08:49.24 | jmls1 | that#s 2 hours of my life that I won't get back |
| 08:50.43 | jmls1 | aaarrrgggggghhhhhhhhhhhhhh |
| 08:50.53 | jmls1 | it's borken again :'( |
| 08:53.08 | schmidts | hmm |
| 08:55.26 | jmls1 | http://pastebin.com/cbq8d5wW |
| 08:56.56 | schmidts | gdb output would be interesting |
| 08:57.14 | jmls1 | can't ... seem ... to ... find ... the ... core .... |
| 08:57.20 | jmls1 | what have I done now ? |
| 08:58.41 | jmls1 | you know what I have done recently - changed the compiler flag to "low_memory" |
| 08:58.45 | jmls1 | I wonder ... |
| 08:58.51 | jmls1 | rebuilds without the flag |
| 09:01.59 | schmidts | why you want to do this? |
| 09:02.39 | jmls1 | I was going to be running it on a low memory machine :-/ |
| 09:03.02 | jmls1 | raspberry pi, to be precise ... :P |
| 09:08.01 | schmidts | ok |
| 09:19.57 | jmls1 | dances a jig |
| 09:19.59 | jmls1 | works |
| 09:20.20 | jmls1 | would someone _please_ either fix or remove low_memory ... |
| 09:27.06 | schmidts | jmlsl i am just trying to reproduce this with trunk and low memory |
| 09:27.11 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 09:27.11 | *** mode/#asterisk-dev [+o ChanServ] by niven.freenode.net |
| 09:28.50 | schmidts | hmm it runs, i will try now your sip.conf |
| 09:33.14 | schmidts | but it looks there is another problem, i cant shut it down (core stop now, restart now) doesnt work |
| 09:34.10 | jmls1 | heh. that worked for me ;) |
| 09:37.54 | schmidts | ok i guess this was of some old modules from 10 i had on the machine |
| 09:38.02 | schmidts | no problems for me even with low memory |
| 10:35.51 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 10:35.52 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 10:36.27 | jmls1 | schmidts: it's now working for me, so I'm just going to place low_memory under the title "here be dragons" |
| 10:36.40 | jmls1 | is not going to fight dragons today |
| 10:37.30 | schmidts | jmlsl http://lolzombie.com/wp-content/uploads/2012/05/555352_297889453633889_206800869409415_685337_1160558311_n.jpeg ;) |
| 11:32.20 | jmls1 | heh |
| 12:00.07 | jsmith | jmls1: You really expect me to be surprised that you broke it again? |
| 12:00.22 | jmls1 | err, nope. suppose not ... |
| 12:09.10 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-znqdipkdooqaquyn) |
| 12:09.10 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 12:36.17 | *** join/#asterisk-dev sustav (~vpp@nat/digium/x-quhawtelwfxehusl) |
| 12:42.22 | *** join/#asterisk-dev acidfoo (~nib@modemcable094.94-70-69.static.videotron.ca) |
| 13:30.17 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-lmcyqxjcbwqicaax) |
| 13:40.19 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-mieinapfniiyyktz) |
| 13:40.19 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 13:42.32 | *** join/#asterisk-dev bulkorok (~bulkorok@217.110.197.225) |
| 14:03.57 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:03.57 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:23.04 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:23.04 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:28.27 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:28.27 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:30.14 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 14:30.14 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 14:46.48 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 15:55.59 | kpfleming | rock on testsuite for finding that regression in chan_sip! |
| 15:56.02 | kpfleming | that's pretty epic |
| 15:56.28 | mvanbaak | nice |
| 15:56.51 | kpfleming | mjordan: not that the general software dev community doesn't already know it, but i think that warrants a blog post showing how the testing efforts are paying off, and trying to solicit more people to participate |
| 15:58.23 | mjordan | kpfleming: not to sound a little out of the information flow, but which regression are we referring to? :-) |
| 15:58.36 | kpfleming | opticron's commit from about 2 minutes ago |
| 15:58.39 | mjordan | ah |
| 15:58.44 | mjordan | that would be a good one |
| 15:59.40 | mjordan | The testsuite is sometimes a bit of an unsung hero. Heck, we caught a crash introduced by a patch yesterday as well. |
| 16:00.07 | kpfleming | even better |
| 16:00.11 | mjordan | opticron's would have been rather subtle :-) |
| 16:01.29 | kpfleming | yes, it would have taken quite a while, and a *user*, to find that one |
| 16:03.39 | opticron | shakes a fist at 1 letter insertions |
| 16:05.29 | russellb | yay testsuite |
| 16:05.40 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-znqdipkdooqaquyn) |
| 16:05.48 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-znqdipkdooqaquyn) |
| 16:05.49 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 16:12.30 | pabelanger | \o/ |
| 16:12.43 | pabelanger | rbot still spamming on failures? |
| 16:13.35 | russellb | rbot <3 |
| 16:13.42 | mjordan | he's just the messenger |
| 16:14.06 | mjordan | and yes, he's still spamming |
| 16:14.10 | mjordan | spam spam spam SPAM |
| 16:15.00 | kpfleming | oh i'm a lumberjack and i'm ok |
| 16:16.57 | jsmith | kpfleming: You sleep all night and you work all day? |
| 16:17.02 | kpfleming | i do! |
| 16:17.15 | kpfleming | wait, no, the other way around |
| 16:17.20 | kpfleming | i work all night and i sleep all day |
| 16:18.06 | jsmith | You program in your sleep? |
| 16:18.15 | kpfleming | no, i write blog posts :-) |
| 17:05.12 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 17:05.12 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 17:45.41 | *** join/#asterisk-dev Tim_Toady (~fuzzy@195.74.224.226.dsl.dyn.forthnet.gr) |
| 19:01.01 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-arnuhsyxjvuttwew) |
| 19:01.01 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 19:18.28 | Kobaz | allrightey |
| 19:18.53 | Kobaz | so it seems when asterisk starts up for the first time, when it's building sip peers in chan_sip it gets the cached count of messages for mwi |
| 19:19.16 | Kobaz | since it's starting up for the first time the cache is zero and for all peers the count will be zero (even though there are messages sitting in the mailbox) |
| 19:19.22 | Kobaz | so what's a good way to fix that |
| 19:19.45 | Kobaz | i was thinking of some sort of flag set on load_module that forces skipping the cache and counting manually |
| 19:19.54 | Kobaz | and then when the load is done, clear the flag |
| 19:27.09 | Kobaz | or should the cache be cleared/ignored on sip reload |
| 19:38.06 | Kobaz | ah, it's a bigger problem than that |
| 19:38.18 | Kobaz | voicemail isn't ready when chan_sip is loading on startup |
| 20:05.51 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-nyeitfokvvdrmlki) |
| 20:05.51 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 20:07.07 | putnopvut | Kobaz: is it a problem that app_voicemail is loaded after chan_sip or is it a deeper issue than that? |
| 20:07.19 | mjordan | it should be just that |
| 20:07.26 | putnopvut | I would assume that app_voicemail would populate the event cache on startup. |
| 20:08.02 | mjordan | putnopvut: IIRC, chan_sip actually calls the inboxcount2 function |
| 20:08.17 | putnopvut | Ah, so not even the event cache. |
| 20:08.23 | putnopvut | Directly checking mailboxes. |
| 20:08.45 | putnopvut | So yeah, it probably does come down to load order. |
| 20:08.48 | mjordan | I'd have to double check what it is on startup. |
| 20:13.14 | mjordan | blech |
| 20:13.17 | mjordan | it is from the event cache |
| 20:13.56 | mjordan | but that should still be fine |
| 20:14.06 | mjordan | it will either use the cached mwi totals if they exist, otherwise it will go out and get the inbox count |
| 20:14.22 | mjordan | so if you have app_voicemail loaded before chan_sip, you should be fine |
| 20:14.24 | kpfleming | why does it do that? |
| 20:14.41 | kpfleming | if app_voicemail is loaded after chan_sip, chan_sip will receive events updating all the mwi counts |
| 20:17.53 | mjordan | kpfleming: yeah, I think that happens sometime. There's a comment in 1.8 (line 28049) that indicates on start up we should send MWI notifications from the event cache only, but it probably doesn't work that way. The cache_only flag in sip_send_mwi_to_peer will prevent chan_sip from using app_voicemail's inbox count functions, but it won't prevent app_voicemail from raising any events itself and from the events from being acted upon w |
| 20:18.13 | kpfleming | it's not supposed to |
| 20:18.52 | kpfleming | if chan_sip loads before app_voicemail, it may send out NOTIFY requests to phones indicating that they don't have any messages waiting, because the event cache is empty |
| 20:19.09 | kpfleming | however, moments later when app_voicemail loads, it will generate events, and new NOTIFYs will go out to the phones |
| 20:19.20 | kpfleming | so for a very short time, the phone may not display that it has messages waiting |
| 20:21.38 | mjordan | well, then its working as intended, because that should be what happens. The comment is a bit misleading, as it seems to imply that the purpose of the cache_only flag is to prevent chan_sip from sending events if app_voicemail hasn't been loaded yet - which isn't what happens |
| 20:23.52 | mjordan | So - Kobaz - are you not seeing the batch of event messages getting kicked off when app_voicemail is loaded? |
| 20:26.40 | mjordan | you will need poll_mailboxes turned on |
| 20:27.32 | kpfleming | really? app_voicemail doesn't do an initial poll on startup? |
| 20:28.01 | mjordan | not without poll_mailboxes |
| 20:28.11 | kpfleming | that's crazy |
| 20:28.22 | kpfleming | i don't see how that could be expected to work |
| 20:29.00 | russellb | is it using ast_event stuff? |
| 20:29.10 | kpfleming | yes, but it's the event publisher |
| 20:29.43 | kpfleming | poll_mailboxes should only be necessary if the mailboxes are being modified by something else, in addition to app_voicemail itself |
| 20:29.51 | russellb | for MWI? |
| 20:29.56 | kpfleming | right |
| 20:30.53 | mjordan | mb_poll_thread gets kicked off in start_poll_thread, which is only started if poll_mailboxes is set to true |
| 20:31.05 | kpfleming | ok, then we have a problem |
| 20:31.08 | mjordan | we'll do a single poll of a mailbox for each SUBSRIBE that comes in |
| 20:31.16 | kpfleming | ahh |
| 20:31.27 | mjordan | right |
| 20:31.30 | kpfleming | and chan_sip may have tried to do subscribes before app_voicemail was loaded |
| 20:31.31 | mjordan | which is how this works at all :-) |
| 20:31.51 | kpfleming | so those event subscriptions failed, or were queued, or ??? |
| 20:32.40 | mjordan | If the event requests came in before app_voicemail was loaded, you would have nothing able to respond to the event requests. I'd imagine they'd get serviced and dropped on the floor, but russellb probably knows the answer :-) |
| 20:33.06 | russellb | subscriptions will always work |
| 20:33.12 | russellb | (if we're talking ast_event) |
| 20:33.26 | mjordan | russellb: we are. If an event is published and no one has subscribed to it, what happens to it? |
| 20:33.32 | kpfleming | no, the other way around |
| 20:33.45 | kpfleming | if someone subscribes to an event but there is no publisher, what happens to the subscription |
| 20:33.46 | russellb | mjordan: it goes to free(); |
| 20:33.55 | russellb | subscriptions stays |
| 20:34.08 | russellb | and app_voicemail should fire off events when it loads |
| 20:34.21 | kpfleming | but when the publisher arrives, will it be told about the subscriptions that happened before it was loaded? |
| 20:34.52 | kpfleming | if not, then app_voicemail won't check the mailbox for that subscription |
| 20:34.58 | russellb | no such notifications exist IIRC |
| 20:35.00 | russellb | you can ask if there are subscriptions for things |
| 20:35.02 | mjordan | I think we're using two terms for subscription |
| 20:35.05 | russellb | but you don't get told |
| 20:35.09 | russellb | yeah maybe |
| 20:36.07 | russellb | and actually if you publish an MWI event, it should get cached even if no one has subscribed to it |
| 20:37.11 | mjordan | right. So app_voicemail will publish an MWI in two different ways: either by polling for it, or by handling an ast_event subscription |
| 20:37.38 | russellb | does "handling an ast_event subscription" actually exist? |
| 20:37.48 | russellb | i don't think it does ... but my memory is fading of these things sadly |
| 20:37.58 | mjordan | russellb: handle_subscribe in app_voicemail |
| 20:38.13 | russellb | oh sure enough |
| 20:38.26 | russellb | ok then i obviously don't remember how this stuff works, sorry |
| 20:39.32 | mjordan | no, I think you're actually still correct. I'm wrong. The notification that someone has subscribed for MWI is itself an event. |
| 20:40.17 | russellb | yeah |
| 20:40.20 | russellb | and app_voicemail subscribes to those |
| 20:40.20 | mjordan | so the order is more like this: chan_sip decides its going to subscribe for MWI notifications, so it asks to receive those events. Then it raises the event that it has subscribed. app_voicemail has subscribed for the events that say that chan_sip has subscribed |
| 20:40.27 | mjordan | when it receives that event, it sends the MWI event |
| 20:40.29 | russellb | <PROTECTED> |
| 20:40.30 | russellb | <PROTECTED> |
| 20:40.31 | mjordan | yup |
| 20:40.40 | russellb | there's also that, so when it loads it says "tell who has already subscribed" |
| 20:40.57 | mjordan | which explains again why app_voicemail wouldn't send this out on startup - it isn't around to receive the subscription event |
| 20:41.13 | russellb | but it should still get it when it starts up |
| 20:41.24 | mjordan | ah |
| 20:41.25 | russellb | that code i just pasted is saying "tell me who has already subscribed" |
| 20:41.27 | mjordan | yeah |
| 20:41.28 | russellb | and they all come in as events then |
| 20:41.53 | mjordan | So .... yeah. This should be working :-) |
| 20:41.58 | russellb | who wrote this confusing stuff geez |
| 20:42.20 | mjordan | at least we didn't have to mention SUBSCRIBE requests in there |
| 20:42.48 | russellb | yeah that's when a whiteboard is needed |
| 20:43.20 | mjordan | To the collab area! Oh wait :-( |
| 20:43.31 | russellb | :-( |
| 20:43.38 | russellb | that's still the most epic whiteboard i have seen |
| 20:43.50 | mjordan | FYI: the left side is still a memorial |
| 20:43.59 | russellb | orly |
| 20:44.01 | mjordan | rly |
| 20:44.08 | russellb | neat |
| 20:44.11 | datachomper | every time I get summoned to the collab area somebody gets voted off the island |
| 20:44.22 | mjordan | we need tiki torches |
| 20:44.29 | russellb | need to use it more often then |
| 20:44.41 | Qwell | less often! |
| 20:45.05 | mjordan | or the collab area needs to become a euphemism for someplace with liquid refreshments |
| 20:45.08 | russellb | heh, not what i meant :-) |
| 20:45.11 | Qwell | mjordan: like beer |
| 20:45.17 | mjordan | Qwell: indeed! |
| 20:45.33 | russellb | misses working in an office |
| 20:45.52 | mjordan | there's an oatmeal for that |
| 20:46.03 | russellb | ha yeah, it's good |
| 20:46.15 | russellb | http://theoatmeal.com/comics/working_home |
| 20:46.51 | datachomper | russellb: do you work in the wilderness now? |
| 20:46.59 | russellb | yep |
| 20:47.02 | mjordan | loss of regimen seems to be true for us, regardless of working at home or not |
| 20:47.02 | russellb | under a palm tree |
| 20:47.10 | mjordan | sipping mai tais? |
| 20:47.47 | russellb | sometimes |
| 20:47.52 | russellb | i wait until at least 9 AM |
| 20:48.00 | datachomper | russellb: http://media.screened.com/uploads/0/810/238395-cast_away_23.jpg like this? |
| 20:48.12 | russellb | ha |
| 20:48.18 | russellb | i do have a scruffy beard |
| 20:48.45 | russellb | instead of Wilson I talk to my dogs. |
| 20:49.16 | mjordan | dogs are great for that |
| 20:51.25 | datachomper | so are volleyballs, but they don't accidentally get diarrhea all over your walls and carpet yesterday while you were gone |
| 20:51.59 | russellb | O.O |
| 20:52.10 | russellb | ProTip: crate |
| 20:57.22 | datachomper | I don't think a crate would be as good of company as a dog |
| 21:24.36 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-znqdipkdooqaquyn) |
| 22:55.04 | *** part/#asterisk-dev kenhunt (~kenhunt@nat/digium/x-pjvgxuwjmoinnsgt) |
| 23:07.47 | *** join/#asterisk-dev kenhunt (~kenhunt@nat/digium/x-fztyfeqifpdwewdt) |
| 23:38.49 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 23:50.50 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 23:50.50 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
