| 01:26.30 | *** join/#asterisk-dev snuff-work (~aaa@210.9.82.197) |
| 01:26.30 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 03:06.24 | *** join/#asterisk-dev wdbl (~not@ool-44c0619d.dyn.optonline.net) |
| 04:04.22 | *** join/#asterisk-dev tzafrir (~tzafrir@212.179.75.202) |
| 04:04.22 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 04:48.07 | *** join/#asterisk-dev Dovid (Dovid@213.8.121.90) |
| 05:43.25 | *** join/#asterisk-dev oej (~olle@2001:470:1f15:d79:225:ff:fe44:74ec) |
| 05:43.25 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 05:44.44 | *** join/#asterisk-dev oej (~olle@2001:470:1f15:d79:225:ff:fe44:74ec) |
| 05:44.44 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:33.13 | *** join/#asterisk-dev schmidts (~schmidts@lmlo.sil.at) |
| 06:33.20 | schmidts | good morning all |
| 07:02.12 | Dovid | morning |
| 07:12.14 | *** join/#asterisk-dev sgimeno (~chatzilla@163.117.211.10) |
| 07:14.13 | *** join/#asterisk-dev oej (~olle@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 07:14.13 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:14.33 | schmidts | morning olle |
| 07:17.21 | oej | Morning |
| 07:45.10 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 07:46.35 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 07:54.19 | schmidts | i have taken a short look at your changes of db.c but there would still be the problem i have expected |
| 07:54.41 | schmidts | but russelb send me a patch yesterday which just do the astdb sync in a own thread. |
| 07:55.18 | schmidts | i will start to bring both solutions together, using a thread to store data to disk or in a realtime db without blocking the caller of astdb functions |
| 08:12.34 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:12.34 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:38.32 | *** join/#asterisk-dev heath (~quassel@unaffiliated/ybit) |
| 08:46.04 | *** join/#asterisk-dev schmidts (~schmidts@lmlo.sil.at) |
| 09:41.40 | *** join/#asterisk-dev oej_ (~olle@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 09:41.40 | *** mode/#asterisk-dev [+o oej_] by ChanServ |
| 10:40.25 | schmidts | is russelb allready on ? |
| 10:43.43 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 10:43.43 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 10:52.33 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 10:52.33 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:18.34 | oej | schmidts: If you don't use db.c why would there be a problem? |
| 11:18.37 | oej | LIke if you're using mysql? |
| 11:28.03 | schmidts | cause i dont know how long it would take to write data into the mysql db and wait for this transmission to success |
| 11:32.40 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:32.40 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:49.45 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 12:11.46 | *** join/#asterisk-dev rrb3942 (~rbullock@208.34.105.161) |
| 12:35.47 | *** join/#asterisk-dev crowb4r (~JKLOBUCAR@12.2.84.2) |
| 12:36.14 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 12:39.27 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 12:39.27 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 12:43.41 | *** join/#asterisk-dev frawd (~francois@81.38.142.65) |
| 12:57.23 | schmidts | @russellb do you had time to look at my review request? |
| 13:03.25 | russellb | not since your last update |
| 13:03.34 | russellb | i'll try to do it today |
| 13:03.42 | schmidts | dont hurry ;) |
| 13:29.35 | *** join/#asterisk-dev bklang (~bklang@tesla.alkaloid.net) |
| 13:38.54 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 13:38.54 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:06.35 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:06.35 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:40.16 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:40.16 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:46.03 | *** join/#asterisk-dev jpeeler (~jpeeler@asterisk/developer/jpeeler) |
| 14:46.03 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 14:52.49 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:52.49 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:02.16 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 15:02.16 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 15:03.22 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:03.22 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 15:49.54 | *** join/#asterisk-dev bklang (~bklang@tesla.alkaloid.net) |
| 15:50.11 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:50.17 | *** join/#asterisk-dev marv (~timr@24.214.206.254) |
| 15:51.39 | *** join/#asterisk-dev pabelanger (~pabelange@2607:f2c0:a000:166:218:f3ff:fe51:c71) |
| 15:54.51 | *** join/#asterisk-dev CunningPike (~CunningPi@204.239.12.183) |
| 16:10.53 | *** join/#asterisk-dev bklang (~bklang@tesla.alkaloid.net) |
| 16:12.00 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 17:00.03 | *** join/#asterisk-dev bbryant (~brett@c-76-26-221-79.hsd1.sc.comcast.net) |
| 17:00.03 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 17:22.28 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 17:22.28 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 17:24.24 | *** join/#asterisk-dev sarg (~sarg@89.169.19.145) |
| 17:38.19 | Kobaz | hey |
| 17:38.28 | Kobaz | in ast_autoservice_stop |
| 17:38.49 | Kobaz | shouldn't ast_check_hangup be used? instead of checking just chan->_softhangup directly ? |
| 17:39.27 | Kobaz | and the channel might be hanging up in other ways, besides softhangup... so autoservice stop wouldn't know about them |
| 17:43.19 | *** join/#asterisk-dev Deeewayne (~dwayne@75-150-14-49-Atlanta.hfc.comcastbusiness.net) |
| 17:43.19 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 17:53.18 | *** join/#asterisk-dev oej (~olle@2001:470:1f15:d79:225:ff:fe44:74ec) |
| 17:53.18 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:04.53 | *** join/#asterisk-dev rrb3942 (~rbullock@208.34.105.161) |
| 18:16.28 | Gugge | shouldn't asterisk send a 'Reason: SIP;cause=200;text="Call completed elsewhere"' to the other leg of a call if it receives it from the other? |
| 18:20.12 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@63.64.154.89) |
| 18:34.10 | kpfleming | Gugge: maybe... maybe not |
| 18:34.15 | kpfleming | they are separate call legs |
| 18:36.18 | Gugge | yes ... |
| 18:36.57 | Gugge | i cant really figure out if it think it should or not :) |
| 18:37.32 | Gugge | but with my setup: device1 -> ast1 -> queue with C flag -> local channel -> ast2 -> device2 |
| 18:37.49 | kpfleming | the information should be available to the dialplan writer, and they should be able to cause that to be sent when Hangup() is called. i don't know if either of those are true today, although i do know that chan_sip does parse that header and the inforamtion is passed to app_dial |
| 18:38.15 | kpfleming | you can't be connecting 'local channel' to 'ast2'... there must be some other kind of channel in there |
| 18:38.43 | Gugge | sure, the local channel is dialing ast2 over sip :) |
| 18:39.03 | kpfleming | right... so that would also require chan_local to pass this information |
| 18:39.08 | Gugge | it does |
| 18:39.18 | Gugge | the reason is sent to ast2 |
| 18:39.22 | Gugge | bit not to device2 |
| 18:39.32 | kpfleming | ahh |
| 18:40.54 | Gugge | but i dont know if the right sollution is to set the AST_FLAG_ANSWERED_ELSEWHERE when we receive CANCEL with that reason ..... |
| 18:41.31 | kpfleming | no, because it's not an outgoing call, it's an incoming call |
| 18:41.48 | kpfleming | so that's not an area that's been talked about much yet, i think |
| 18:42.24 | seanbright | russellb: your review looks... weird |
| 18:42.51 | russellb | yeah, that's not right. |
| 18:42.54 | russellb | huh. |
| 18:42.56 | Gugge | but, if we receive a CANCEL, telling us the call was answered elsewhere, wouldn't it be logical if we send that reason to the other endpoint ? |
| 18:43.26 | kpfleming | maybe. it's worth bringing up on the -dev list. |
| 18:43.46 | Gugge | super, i just wanted to know if i was totally wrong first :) |
| 18:44.16 | kpfleming | nope, i don't think so |
| 18:44.23 | russellb | seanbright: fixed i think |
| 18:44.23 | kpfleming | there should be some method to accomplish what you want, it's logical |
| 18:44.48 | seanbright | russellb: looks right |
| 18:45.39 | Kobaz | ah... you guys are awake |
| 18:45.47 | russellb | untrue |
| 18:45.52 | Kobaz | in ast_autoservice_stop. shouldn't ast_check_hangup be used? instead of checking just chan->_softhangup directly ? |
| 18:46.10 | Kobaz | and the channel might be hanging up in other ways, besides softhangup... so autoservice stop wouldn't know about them |
| 18:46.14 | russellb | the other option is a time based scheduled hangup |
| 18:46.21 | russellb | which will just get caught when it leaves autoservice |
| 18:46.32 | Kobaz | but what about if autoservice fails to stop |
| 18:46.38 | russellb | why would it not stop? |
| 18:46.52 | russellb | oh, this is _in_ ast_autoservice_stop() |
| 18:47.08 | Kobaz | [Sep 7 08:46:07] ERROR[8424] app_dial.c: Could not stop autoservice on calling channel |
| 18:47.21 | Kobaz | yes... inside ast_autoserice_stop |
| 18:48.08 | russellb | so, a return value of -1 is not necessarily that it failed |
| 18:48.17 | Kobaz | russellb: autoservice fails to stop.. and then proceeds to suck up 100% cpu |
| 18:48.26 | russellb | if a channel has been hung up, it will also be -1 |
| 18:48.39 | russellb | 100% CPU where |
| 18:48.44 | Kobaz | in the autoservice thread |
| 18:49.39 | Kobaz | 0xb69b2b70 13425 autoservice_run started at [ 233] autoservice.c ast_autoservice_start() |
| 18:49.46 | Kobaz | 13425 pbx 20 0 535m 512m 7180 R 94.4 25.3 490:46.60 /usr/sbin/asterisk -U pbx -g |
| 18:50.31 | Kobaz | it will chew 90-100% cpu until all related channels are hung up |
| 18:50.37 | russellb | well i don't know ... but that error message is not actually an indication that it wasn't removed |
| 18:52.04 | Kobaz | <PROTECTED> |
| 18:52.04 | Kobaz | <PROTECTED> |
| 18:52.08 | Kobaz | it's probably somewhere like that |
| 18:52.23 | Kobaz | it's probably returning immediatly and doing a continue |
| 18:52.58 | russellb | it should only return on either a timeout (wouldn't be a busy loop), or if an event occurred on a channel (in which case chan would be non-NULL) |
| 18:53.18 | Kobaz | yeah... should |
| 18:53.21 | russellb | :-) |
| 18:53.24 | Kobaz | somewhere it's not waiting... heh |
| 18:53.28 | russellb | well instrument the code and find out |
| 18:53.32 | Kobaz | yeah... working on it |
| 18:53.46 | kpfleming | i suppose there could be signals that cause it to return... but that would only happen once |
| 18:54.19 | russellb | true |
| 18:54.20 | Kobaz | the channels where autoservice failed to stop are now gone... cpu is back to normal |
| 18:54.37 | russellb | so perhaps app_dial is doing something screwy in that code path |
| 18:54.52 | russellb | like i said before, that message (contrary to what it says) does _not_ indicate that the channel was not removed |
| 18:54.57 | Kobaz | k |
| 18:54.57 | kpfleming | if channel is closed, its fds will be closed, and poll() will return with an error immediately (most likely) |
| 18:55.17 | Kobaz | this is (of course, you know me), involving a bunch of dials and local channels |
| 18:56.18 | russellb | hmm.... |
| 18:56.29 | Kobaz | so, i wouldn't be surprised if there's something odd going on in dial... since i tend to use and abuse local channels up the wazoo and always find a bug or two |
| 18:57.13 | Kobaz | i'mm try and get a small test case this week |
| 18:57.19 | Gugge | Always nice to find bugs (and get then fixed) :) |
| 18:57.24 | Kobaz | yeap |
| 18:57.36 | russellb | i'd rather they just not exist |
| 18:57.42 | russellb | they cause me much grief |
| 18:57.49 | Kobaz | bugs? |
| 18:57.51 | Kobaz | or local channels? |
| 18:57.52 | russellb | yes |
| 18:57.58 | russellb | just bugs |
| 18:57.59 | Kobaz | hehe |
| 18:58.01 | russellb | local channels are cool. |
| 18:58.04 | Kobaz | yeah |
| 18:58.09 | russellb | bugs are going to give me gray hair in my 20s |
| 18:58.24 | Gugge | bugs allready did that to me :P |
| 18:59.41 | espiceland | russellb, take a look at mspiceland for a preview of coming attractions. ;) |
| 19:00.16 | russellb | espiceland: heh. he has the added bonus of kids on his stress plate. |
| 19:00.34 | espiceland | and wife and dog... oh, wait... |
| 19:01.10 | Kobaz | oh whoops... i replied to -dev with the wrong email |
| 19:01.32 | Kobaz | it'll get bounced? if the from address is not a list subscriber? |
| 19:01.56 | kpfleming | yes |
| 19:02.01 | kpfleming | actually, just dropped |
| 19:02.14 | russellb | espiceland: yeah, those wives... |
| 19:02.28 | putnopvut | how many wives does he have? |
| 19:02.35 | espiceland | Better just be one! |
| 19:02.41 | Kobaz | allrightey |
| 19:03.06 | putnopvut | I officially declare it illegal for bugs to exist in Asterisk. |
| 19:03.12 | putnopvut | That should fix it! |
| 19:03.14 | russellb | putnopvut: +1 |
| 19:03.21 | russellb | shuts down issues.asterisk.org |
| 19:03.23 | Qwell | assigns all bugs to putnopvut |
| 19:03.28 | espiceland | Doesn't that make you all criminals? |
| 19:03.29 | russellb | actually, maybe we should only have reviewboard |
| 19:03.33 | Kobaz | heh |
| 19:03.35 | russellb | bug reports can only be submitted with patches, heh |
| 19:03.38 | Kobaz | haha |
| 19:03.49 | Qwell | forget that. make the svn repo rw |
| 19:03.57 | Qwell | (anon commit) |
| 19:03.58 | putnopvut | espiceland: no, it's the bugs themselves that are illegal, not the creators of them. |
| 19:03.59 | Kobaz | oh yay |
| 19:04.05 | Kobaz | i have all kinds of stuff i would want to commit |
| 19:04.07 | Qwell | then we won't need issues or RB! |
| 19:04.11 | Kobaz | let me know when it's open |
| 19:04.23 | Gugge | Qwell: didnt you want fewer bugs? :P |
| 19:04.45 | Qwell | it's only a bug if it's reported |
| 19:04.49 | russellb | Kobaz: feel free to get commit access, I don't mind ... as long as you get sign off on reviewboard for each patch |
| 19:04.54 | espiceland | putnopvut: Oh, I see. That's why drug cooks get such light treatment. |
| 19:04.57 | espiceland | :) |
| 19:05.02 | Kobaz | russellb: oh... interesting |
| 19:05.24 | Kobaz | russellb: i'll have to get my stuff back together for fixing up group vars |
| 19:05.34 | Kobaz | i did most of the changes except for the public api |
| 19:05.41 | Kobaz | just been busy... |
| 19:09.35 | Kobaz | having commit access would be a good excuse to get that stuff finished |
| 19:09.50 | russellb | nods |
| 19:09.58 | russellb | email jpeeler@digium.com to get set up. |
| 19:10.05 | Kobaz | k |
| 19:10.07 | russellb | like I said, just use reviewboard to get sign off, and you're good to go |
| 19:10.37 | Kobaz | yeah |
| 19:13.01 | Kobaz | should autoservice itself check for hung up channels? |
| 19:13.12 | Kobaz | oh wait, it does |
| 19:14.22 | Kobaz | but it doesn't remove the channel from the list on a hung up condition though |
| 19:17.00 | oej | russellb: Time for a quick question? |
| 19:17.41 | oej | In ast_openstream_full() channel.c we ignore the result of ast_set_write_format - is there a reason for that? |
| 19:18.53 | russellb | not a good reason |
| 19:19.11 | oej | I guess we should fail if we get -1 on that call. |
| 19:19.31 | russellb | probably so, yes. |
| 19:19.53 | russellb | otherwise, it's going to be streaming a file onto a channel in a format it can't handle |
| 19:19.56 | russellb | which is broken. |
| 19:20.02 | oej | I thought so. |
| 19:20.14 | oej | I'll try to get a patch up on reviewboard |
| 19:21.19 | oej | I'll just return NULL |
| 19:29.07 | Gugge | i keep finding strange things tonight :P |
| 19:29.20 | Gugge | with rtautoclear set, if i unregister a phone, the peer is never cleared from mem, but if i pull the power, its cleared on expire |
| 19:43.36 | *** join/#asterisk-dev citrus2 (~citrus2@72.215.183.28) |
| 19:52.31 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 19:52.31 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:53.03 | oej | Ok, something happened and I was gone for a while. If someone replied, please retransmit |
| 19:56.01 | *** join/#asterisk-dev schmidts (563b1f02@gateway/web/freenode/ip.86.59.31.2) |
| 19:56.06 | schmidts | hello all |
| 19:56.45 | schmidts | @russell real nice work!!! but i am still testing ;) |
| 19:56.55 | russellb | thanks, post your results up on the review |
| 19:56.59 | russellb | disappears to a meeting |
| 21:01.50 | schmidts | bad news for you russell :D the 20k peers register taste brakes down after 15k peers registered |
| 21:04.39 | Kobaz | schmidts: what about delaying writes to astdb in a whole nother thread |
| 21:11.29 | schmidts | thats the patch russell has written today or atleast it is |
| 21:17.44 | russellb | schmidts: and it didn't break down before? |
| 21:22.40 | Kobaz | sweet |
| 21:22.42 | Kobaz | my patch went in |
| 21:23.56 | Kobaz | mmm |
| 21:24.22 | Kobaz | https://issues.asterisk.org/view.php?id=17652 is it a big deal that it uses lock/check/unlock versus just calling ast_check_hangup_locked |
| 21:24.45 | Kobaz | i'm a fan of less code if possible |
| 21:30.53 | schmidts | sorry if you understand me not right ;) without your patch 1.6.2 brakes down at around 8 k peer. with your patch it brakes down at around 15k peers, and with fsync turned completyl off, it handles 20k without any problems |
| 21:31.10 | russellb | well we can't turn it off completely |
| 21:31.19 | schmidts | i know |
| 21:31.38 | russellb | want to see if moving to 1 second makes it better? |
| 21:31.54 | schmidts | give me half a hour ;) |
| 21:32.01 | russellb | don't use usleep(), though |
| 21:32.05 | russellb | just make it sleep(1) |
| 21:33.06 | russellb | usleep()'s behavior is undefined when the time is >= 1 second |
| 21:34.35 | schmidts | ok running with sleep(1) |
| 21:34.53 | schmidts | <= away for a smoke this will take 10 to 15 mins atleast ;) |
| 21:38.20 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 21:38.20 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 21:41.34 | schmidts | back |
| 21:41.42 | schmidts | 5k registered still running |
| 21:43.06 | schmidts | i have seen on the last test, the reachable time starts to jump around a lot after 10k peers. first its around 3ms, then i see more and more values > 15ms |
| 21:50.28 | schmidts | ok forget it i have missed a patch |
| 21:50.51 | schmidts | the ao2_callback of dialog needdestroy this could burn down everything too |
| 21:53.24 | kpfleming | then the right way to handle that is to create another container that holds pointers to the pvts that are in the 'needdestroy' state |
| 21:53.34 | russellb | yes, there is an expression called "comparing apples to apples" :-) |
| 21:54.30 | kpfleming | any time the thing you are searching for repeatedly is likely to be in the minority of the list you are searching, you need another list. don't look for needles in haystacks, create a separate list of the needles :-) |
| 21:54.47 | russellb | indeed |
| 21:55.03 | kpfleming | you can quote me on that if you like |
| 21:55.09 | kpfleming | talk to my publicist about fees |
| 21:55.17 | schmidts | much better now ;) Reachable time 1ms on all peer |
| 21:55.21 | Qwell | $19.99 per usage, payable directly to me. |
| 21:55.42 | kpfleming | Qwell: has my publicist subcontracted to you? |
| 21:55.53 | Qwell | let's go with yes. |
| 21:55.58 | kpfleming | rofl |
| 21:58.53 | russellb | Qwell: can I quote you on that? |
| 22:00.32 | Qwell | russellb: See above. |
| 22:04.46 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-155-170.cablep.bezeqint.net) |
| 22:04.46 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 22:05.48 | schmidts | with my patch from issue 17912 its running real nice |
| 22:05.50 | MuffinMan | [confirmed] [Asterisk] Channels/chan_sip/General 0017912: ao2_t_callback of dialog_needdestroy is called every loop of do_monitor reported by schmidts https://issues.asterisk.org/view.php?id=17912 |
| 22:06.20 | schmidts | 7500 peers registered, load 0,07 looks good so far |
| 22:09.48 | russellb | i'm out for a while, post results on reviewboard :-) |
| 22:16.54 | schmidts | btw 14k peers online still 1ms away ;) |
| 22:30.12 | schmidts | 20015 sip peers [Monitored: 20000 online, 0 offline Unmonitored: 15 online, 0 offline] w 22:28:14 up 12 days, 7:23, 2 users, load average: 0,27, 0,18, 0,16 |
| 22:30.35 | schmidts | looks really good now, i will try it again with the usleep of 500ms |
| 22:56.18 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 23:04.50 | *** join/#asterisk-dev moy (~moy@UNVLON55-1176057127.sdsl.bell.ca) |
| 23:23.35 | schmidts | and again, turning off the registering server first is a bad idea :( |
| 23:23.49 | schmidts | 73mbit of options packages *grrr* |
| 23:28.18 | *** join/#asterisk-dev rrb3942 (~rbullock@cpe-67-242-215-62.rochester.res.rr.com) |
| 23:42.15 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.75.202) |
| 23:42.15 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 23:46.04 | schmidts | gn8 all |