| 00:58.47 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 02:10.48 | *** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 02:10.48 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 04:03.41 | snuff-work | mm.. pretty cool.. http://www.youtube.com/watch?v=L2w-XqW7bF4&feature=share |
| 04:07.22 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 04:25.23 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 04:59.06 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 05:10.58 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1001) |
| 05:10.59 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 05:26.50 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1001) |
| 05:26.50 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:08.29 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1001) |
| 07:08.30 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:31.41 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1001) |
| 07:31.42 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:37.50 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:208b:1c9d:6721:842) |
| 08:22.23 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 09:17.44 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.36.36) |
| 09:36.49 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 09:47.11 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 09:53.27 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 09:53.27 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 11:24.51 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 11:24.55 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 11:31.05 | *** join/#asterisk-dev tm1000 (tm1000@2600:3c01::f03c:91ff:fe70:fce6) |
| 11:38.53 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 12:16.33 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 12:20.23 | *** part/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 12:55.38 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-hnyjdtrqgpfmbitg) |
| 12:58.14 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 12:58.14 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:03.04 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 13:03.04 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 13:03.05 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1005) |
| 13:03.05 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:08.56 | Kobaz | [2013-04-30 09:08:37] WARNING[23042]: chan_sip.c:3874 __sip_autodestruct: Autodestruct on dialog '268fd00-0-13c4-1586e9-943eba26-1586e9@192.168.51.20' with owner in place (Method: BYE) |
| 13:09.02 | Kobaz | mmmm what do those mean? |
| 13:09.59 | opticron | sounds like the ast_channel that was associated with the SIP pvt is still around when the pvt gets destroyed |
| 13:10.13 | opticron | which is kind of weird |
| 13:17.08 | Kobaz | i'm getting a lot of them |
| 13:19.31 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-edfdqvbfwgvmlobk) |
| 13:19.31 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:24.30 | Kobaz | would it be safe to assume that recording files in their native channel codec would be the fastest/least load |
| 13:24.38 | Kobaz | both channels are on ulaw, and record to ulaw |
| 13:25.07 | file | if they are mixed then it is transcoded to signed linear |
| 13:25.32 | Kobaz | ah |
| 13:25.34 | Kobaz | yeah mixed |
| 13:26.16 | Kobaz | slin? |
| 13:26.24 | file | yes. |
| 13:27.53 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:27.53 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:54.05 | Kobaz | wooooooooooow |
| 13:54.09 | Kobaz | you guys are so awesome |
| 13:54.23 | leifmadsen | thx |
| 13:54.25 | leifmadsen | :) |
| 13:54.46 | Kobaz | so i read the vicidial presentation that one of you pasted on call recording |
| 13:54.52 | Kobaz | i switched to recording to a ramfs |
| 13:54.53 | Kobaz | oh man |
| 13:55.06 | file | yes, it is good |
| 13:56.06 | Kobaz | it like |
| 13:56.13 | Kobaz | took my iowait down from 30% to 2% |
| 13:56.25 | Kobaz | insanity |
| 13:58.44 | snuff-home | well ram is a 'tad' more responsive :) |
| 13:59.34 | Kobaz | a little |
| 13:59.37 | snuff-home | file: what u think of my idea i posted yest.. about some sort of diagram for res_sip endpoint relationships.. |
| 14:00.21 | snuff-home | aka endpoint linked to aor's via a m-m / transports via m-1.. etc |
| 14:00.28 | file | sure |
| 14:00.37 | Kobaz | it's all the random disk io that really kills |
| 14:00.45 | Kobaz | like 50 channels all writing to disk in different places |
| 14:00.51 | Kobaz | fragmenting like crazy |
| 14:01.13 | jsmith | Kobaz: For the record, I asked you the other day if you were writing to ramdisk :-p |
| 14:01.32 | Kobaz | yeah |
| 14:01.33 | Kobaz | well |
| 14:01.36 | Kobaz | that's what got me going |
| 14:01.42 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-ztrgysugviinwnmi) |
| 14:01.43 | snuff-home | so how u do it Kobaz.. 2gb ram disk.. with a rsync every x minutes or when hit high watermark |
| 14:02.00 | Kobaz | jsmith: so, my customer is going to love you by the end of the day |
| 14:02.10 | jsmith | It's too bad the "ramback" ramdisk never made it into the kernel (as far as I know) |
| 14:02.13 | Kobaz | i made it the same size as my disto default tmpfs |
| 14:02.20 | Kobaz | 768mb |
| 14:02.31 | Kobaz | and i run my make_mp3 every 5 minutes |
| 14:02.32 | jsmith | Kobaz: If you're not familiar with it, go google for "ramback ramdisk" |
| 14:02.33 | snuff-home | mm tmpfs thought so. |
| 14:02.42 | Kobaz | yeah i saw ramback |
| 14:02.43 | Kobaz | looks awesomely |
| 14:02.57 | Kobaz | hell i would write everything to ramback |
| 14:03.02 | Kobaz | asterisk logs |
| 14:03.05 | Kobaz | voicemail |
| 14:04.38 | Kobaz | when i saw in the slides that native mixmonitor can handle like a max of 50 channels |
| 14:04.51 | Kobaz | and that writing to ramdisk can do 250+ |
| 14:04.52 | jsmith | Well, we were doing more than 50 channels -- but we have beefy hardware |
| 14:04.58 | Kobaz | i wasl ike omfg i have to do this RIGHT NOW |
| 14:05.13 | Kobaz | i have beefy hardware but not beefy disks |
| 14:05.27 | Kobaz | quad core i7 but regular server sata drives |
| 14:05.32 | Kobaz | not like 15k sas or anything |
| 14:06.56 | snuff-home | hopes to get time this week to rejig that res_sip doco.. been tad too busy.. have questions about my other 'chan_gulp readability stuff but need zz's |
| 14:07.18 | Kobaz | what's gulp again? is that the new pjsip? |
| 14:07.37 | jsmith | Kobaz: Correct |
| 14:08.07 | Kobaz | the current code name? or that'll be the driver name forrrever? |
| 14:08.18 | jsmith | Kobaz: That's being discussed on the -dev mailing list |
| 14:08.29 | jsmith | Kobaz: But I have a funny feeling it's going to be around for a while |
| 14:08.40 | Kobaz | hehe |
| 14:08.45 | jsmith | ("a gulp is more than a sip") |
| 14:08.47 | Kobaz | i haven't gotten on the list in forever |
| 14:08.49 | Kobaz | ooooh |
| 14:08.59 | Kobaz | i've been too busy fighting this one asterisk install |
| 14:09.07 | Kobaz | which i think i just fixed as of 10am |
| 14:09.08 | jsmith | I'm holding out for "guzzle" and "chug" |
| 14:09.24 | jsmith | is fighting reporting on a third-party system this morning |
| 14:09.38 | Kobaz | asterisk readme should have a requirement that recording be done to a ramdisk |
| 14:10.08 | jsmith | It's not a requirement -- it just helps |
| 14:10.26 | jsmith | And that's not really even an Asterisk thing, per se |
| 14:10.41 | jsmith | It's a systems administration issue |
| 14:10.41 | snuff-home | if ur doing ALOT of recordings.. might be a 'suggestion' |
| 14:10.49 | jsmith | Suggestion is fine, requirement is not |
| 14:11.57 | snuff-home | mm.. is there any implementation of memcache in * atm.. i forget.. looking at my old branch.. |
| 14:12.04 | snuff-home | for a 'func_memcache' |
| 14:12.07 | Kobaz | yeah true |
| 14:14.49 | snuff-home | anyway.. zzz's.. later ppl |
| 14:15.23 | *** join/#asterisk-dev hehol (~hehol@217.9.101.222) |
| 14:26.19 | *** join/#asterisk-dev tm1000 (tm1000@2600:3c01::f03c:91ff:fe70:fce6) |
| 14:38.49 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:38.50 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:46.19 | pnlarsson | This is not a really a bug, but without libuuid res_rtp_asterisk.so is not being built and it's kind of difficult to make a call. Should not configure die and require libuuid? (happend after http://svnview.digium.com/svn/asterisk?view=revision&revision=385356) on asterisk 11 |
| 14:47.43 | Qwell | pnlarsson: Is this on CentOS 5 or something? If so, that's a bug in the distro. The module does still get built, with a proper version of gcc. |
| 14:48.03 | Qwell | wait, I lied. |
| 14:48.47 | mjordan | pnlarsson: it should. I know we added libuuid dependency checking to trunk; I thought we had added it to 11 as well |
| 14:48.54 | mjordan | pjproject uses libuuid |
| 14:48.56 | Qwell | mjordan: The dep is there. That's what he linked to. |
| 14:49.01 | mjordan | oic |
| 14:49.12 | mjordan | wacky |
| 14:49.12 | Qwell | res_rtp_asterisk now depends on uuid (since pjproject needs it) |
| 14:49.27 | Qwell | which means it just doesn't get built, rather than the compile fail before. |
| 14:49.46 | pnlarsson | Qwell: it compiles nicely |
| 14:49.54 | pnlarsson | but fails to make calls |
| 14:51.00 | pnlarsson | On centos 5 you need to yum install e2fsprogs-devel - took i while to find that one... |
| 14:51.07 | Qwell | I would say that we really can't make it a hard dependency, since there are systems that don't use any channel driver with RTP. |
| 14:51.16 | Qwell | IAX2, DAHDI, etc |
| 14:51.43 | pnlarsson | Qwell: fair enough |
| 14:56.29 | coreyf1513 | pnlarsson, to force configure to fail if uuid not found: ./configure --with-uuid=y |
| 14:56.51 | Qwell | coreyf1513: pretty sure you can just do --with-uuid |
| 15:00.28 | coreyf1513 | true... i had misread what would happen with no parameter |
| 15:17.42 | Kobaz | maaaan |
| 15:17.56 | Kobaz | still like, mind=blown about how much better this ramdisk recording is |
| 15:18.06 | leifmadsen | w00t :) |
| 15:18.11 | Kobaz | my iowait went from 35% down to 1.2% |
| 15:19.12 | leifmadsen | yeppers |
| 15:20.19 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 15:20.19 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 16:24.19 | *** part/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 17:08.30 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 18:15.25 | *** join/#asterisk-dev tzafrir (~tzafrir@212.179.75.202) |
| 18:15.25 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 19:04.00 | Qwell | putnopvut: That AMI event is fantastic. |
| 19:05.23 | putnopvut | heh |
| 19:14.12 | mjordan | which one? |
| 19:20.43 | tm1000 | file: ping. you avalible |
| 19:20.48 | file | yes |
| 19:20.59 | tm1000 | available* |
| 19:21.16 | tm1000 | file: so I think I discovered the issue they were having in res_xmpp. But im still doing some checking |
| 19:21.24 | file | k |
| 19:21.29 | tm1000 | it seems that res_xmpp is using port blocking? |
| 19:21.44 | file | I don't know what you mean by that |
| 19:22.03 | tm1000 | file: http://www.scottklement.com/rpg/socktut/nonblocking.html |
| 19:22.06 | tm1000 | socket blocking. |
| 19:23.01 | tm1000 | what im noticing is that sometimes google sends a blank response, which locks up the xmpp_io_recv function as it's waiting for more data but the data never comes (unless google sends out some more data, on say a presense change) |
| 19:23.39 | file | interestin' |
| 19:23.44 | tm1000 | the way Im fixing it right now is if I detect blank data I immediately send out a ping, this ends up breaking the blocking |
| 19:23.55 | tm1000 | because google then is forced to send a reply |
| 19:24.10 | tm1000 | alternatively I was going to start looking into setting a socket option to define socket timeout |
| 19:24.16 | tm1000 | to say 5 seconds, which would also fix it |
| 19:24.32 | tm1000 | it always pauses on recv or SSL_Read |
| 19:24.39 | tm1000 | so I set the option before that |
| 19:26.16 | tm1000 | I havent really noticed it before because I have 10 buddies in my gmail client and their presence is always changing so the socket cant block because it eventually gets data, but if people have no buddies in their list then it will never unblock and will continously wait for data, which kills your old keep alive which makes google eventually drop the connection |
| 19:26.34 | tm1000 | file: ^ |
| 19:26.45 | tm1000 | all prelim…still trying to figure out if that IS the issue |
| 19:32.00 | *** join/#asterisk-dev kpfleming (4173e21c@gateway/web/freenode/ip.65.115.226.28) |
| 19:38.52 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 20:12.50 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:100b) |
| 20:12.51 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 21:01.22 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:100b) |
| 21:01.23 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 22:52.23 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-edfdqvbfwgvmlobk) |
| 23:46.41 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 23:46.42 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |