| 00:08.38 | *** join/#asterisk-dev Marquis42 (~bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 00:37.05 | *** join/#asterisk-dev seraphie (~erin@75.76.38.159) |
| 00:37.50 | *** join/#asterisk-dev snuff-work (~snuffy@210.9.82.197) |
| 00:37.50 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 01:37.25 | *** join/#asterisk-dev seraphie (~erin@75.76.38.159) |
| 02:44.51 | *** join/#asterisk-dev otherwiseguy (~otherwise@user1.kumc.edu) |
| 04:19.56 | *** join/#asterisk-dev seraphie (~erin@75.76.38.159) |
| 04:39.44 | *** part/#asterisk-dev joshaidan (~brianj@S0106001c1023e838.tb.shawcable.net) |
| 05:14.20 | *** join/#asterisk-dev irroot (~irroot@197.109.39.170) |
| 05:59.31 | *** join/#asterisk-dev moy (~moy@173.239.155.74) |
| 07:02.04 | *** join/#asterisk-dev hehol (~Adium@2a01:198:71d:0:21f:d0ff:fea1:568e) |
| 07:36.45 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 07:36.47 | schmidts | good morning |
| 07:54.13 | *** join/#asterisk-dev oej (~olle@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 07:54.13 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:54.45 | wdoekes2 | morning |
| 07:54.54 | oej | Morning |
| 07:57.04 | schmidts | morning wdoekes2 and oej |
| 08:07.09 | *** join/#asterisk-dev fish9370 (~Miranda@fpg.ru) |
| 08:07.22 | fish9370 | Hello |
| 08:07.31 | fish9370 | I have problem with receiving fax |
| 08:07.52 | fish9370 | [Nov 10 11:33:45] WARNING[7434] app_fax.c: Error transmitting fax. result=49: The call dropped prematurely. |
| 08:07.52 | fish9370 | [11:51] fish9370: [Nov 10 11:33:45] WARNING[7434] app_fax.c: Transmission error |
| 08:08.14 | fish9370 | what this mean? |
| 08:08.29 | schmidts | fish9370 you should stay in the asterisk channel with this question cause its not a dev question ;) |
| 08:10.03 | fish9370 | only developer can answer on this question.. I think.. |
| 08:10.33 | fish9370 | i need some tools for debug |
| 08:10.56 | irroot | fish9370 how you doing this ? |
| 08:11.16 | fish9370 | sorry, this what? |
| 08:11.18 | irroot | firstly use res_fax not app_fax |
| 08:11.34 | irroot | the faxing what channel it on |
| 08:11.39 | fish9370 | it's developer version? |
| 08:12.01 | irroot | what version ? |
| 08:12.08 | fish9370 | res_fax |
| 08:12.29 | irroot | you using 1.8 or 10 ? |
| 08:12.58 | fish9370 | no, 1.6.2.20 |
| 08:13.02 | irroot | ah ok |
| 08:13.36 | fish9370 | where i can give res_fax? |
| 08:13.59 | irroot | what channel you transmitting on ? |
| 08:14.07 | fish9370 | iax2 |
| 08:14.13 | irroot | so its G711 |
| 08:14.19 | fish9370 | on sip it's work |
| 08:14.51 | irroot | the problem is faxing on a RTP link is not recomended |
| 08:15.13 | irroot | if you have jitterbuffer or any inconsitancy on the link it will fail |
| 08:15.36 | fish9370 | i need link 2 asterisks |
| 08:16.17 | fish9370 | jitterbuffer=no |
| 08:16.38 | irroot | is there any alternative ? |
| 08:16.55 | irroot | faxing over IAX is not advisiable |
| 08:17.15 | irroot | if you use sip you can use T38 and that is supported |
| 08:17.57 | fish9370 | iax2 T38 not supported? |
| 08:18.03 | irroot | no its not |
| 08:18.56 | fish9370 | thanks |
| 08:21.00 | irroot | fish9370 T38 requires UDPTL asterisk does not support T38 RTP |
| 08:22.03 | irroot | IAX does not support UDPTL and in the strict sense IAX superseeds RTP in that it includes the packet |
| 08:22.59 | fish9370 | i need switch my iax2 connection on this mode? |
| 08:23.34 | *** join/#asterisk-dev irroot (~irroot@197.109.39.170) |
| 08:23.44 | fish9370 | i need switch my iax2 connection on this mode? |
| 08:24.24 | irroot | fish9370 you should not use IAX for faxing its ugly at G711 on a ether link it may work some of the time |
| 08:24.42 | irroot | www.soft-switch.org/foip.html <- read this |
| 08:25.31 | fish9370 | thank you.. i try rebuild my schem |
| 08:33.13 | schmidts | irroot thanks thats what i have allready said :P |
| 08:33.47 | irroot | its always worth repeating |
| 08:33.50 | fish9370 | schmidts, thank you too |
| 08:33.59 | irroot | how is your ticklesss server |
| 08:34.43 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:34.43 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:35.02 | schmidts | irroot looks good at the moment, up since 9 hours, 37 concurrent calls, 1800 calls processed and currently a load of 0,6 not so bad at all ;) |
| 08:35.17 | schmidts | but i have to wait until 12 then i really can say more |
| 08:35.31 | schmidts | and no locks at all ;) |
| 08:35.38 | irroot | or blocks |
| 08:35.50 | schmidts | (b)locks :D |
| 08:35.52 | irroot | i got a good deal on a segfault ?? |
| 08:36.00 | irroot | its all bolocks ? |
| 08:36.16 | schmidts | no its one lock and a lot of locks which are blocked from this first lock |
| 08:36.36 | irroot | and they all lived happily ever after |
| 08:38.08 | schmidts | we will see |
| 08:38.42 | schmidts | the biggest problem is, if this works now (what i really hope) i still have to do the full load test where all of my pbxes are routed to this server |
| 08:38.57 | schmidts | but if the server dies again with a kernel panic my customers will kill me |
| 08:40.12 | fish9370 | kernel panic after asterisk die? |
| 08:40.48 | schmidts | fish9370 kernel panic without asterisk dies, just having a very big load |
| 08:41.26 | fish9370 | how much? |
| 08:41.53 | fish9370 | what server configuration? |
| 08:41.55 | schmidts | this virtual machine asterisk was running had a load of 17, atleast thats what my monitoring said |
| 08:42.43 | schmidts | i think there was a big (b)locking issue with asterisk and the limits for this server was just too small and it hits a special limit too often to cause this panic, but i wasnt able to see anything |
| 08:43.01 | schmidts | the server was completly dead, even with a monitor and a keyboard connected it doesnt respond to anything |
| 08:44.10 | fish9370 | host or virtual server only? |
| 08:44.24 | schmidts | both |
| 08:44.31 | fish9370 | hmm |
| 08:44.36 | schmidts | the host machine died with the kernel panic |
| 08:45.30 | fish9370 | i have trouble when i set debug 100 |
| 08:46.41 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 08:47.25 | fish9370 | log file is growing up too fast |
| 08:48.48 | fish9370 | and sometimes i have trouble on server where it use AGI on PHP |
| 09:10.40 | *** join/#asterisk-dev mnicholson (~mnicholso@nat/digium/x-mnsjjuymrbyrncfr) |
| 09:10.40 | *** mode/#asterisk-dev [+o mnicholson] by ChanServ |
| 09:12.25 | schmidts | irroot doesnt look so good again :( |
| 09:12.50 | schmidts | load of 10 with 51 active channels and 2712 calls processed |
| 09:15.48 | schmidts | damn something is killing the performance and i dont know what :( |
| 09:15.59 | schmidts | now a load of 1.29 with 46 concurrent calls :( |
| 09:17.03 | irroot | mmm |
| 09:17.55 | irroot | and the server host not guest |
| 09:18.37 | schmidts | thats another thing i dont understand :D load of 0.1 |
| 09:19.22 | schmidts | right now vz machine has load 12 and host machine 0.03 |
| 09:20.45 | irroot | so not all the host resources available to guest |
| 09:21.32 | schmidts | no but i have some values to compare |
| 09:21.36 | irroot | load average could be 1 if only asterisk was running |
| 09:21.44 | irroot | and never go higher |
| 09:22.24 | schmidts | another vz which is running asterisk 1.2 on the same host machine has now 51 active calls and a load of 0.17 but the limits for this vz are much more strict than the one for the 1.8 machine |
| 09:22.30 | irroot | so what is running and "stealing" resources from it |
| 09:23.02 | schmidts | irroot it would only be 1 if asterisk use only one thread ;) |
| 09:23.24 | irroot | indeed indeed |
| 09:23.38 | irroot | and there was one cpu |
| 09:24.26 | schmidts | ok i see a big difference between 1.2 and 1.8 the 1.2 runs with the option "do not fork (-f)" and 1.8 with "do allways fork" could this be the problem? |
| 09:25.13 | wdoekes2 | that should not matter at all |
| 09:25.23 | irroot | should not forking is couple lines of code where its forked and then the main program exits leaving the fork |
| 09:25.52 | irroot | running in the background |
| 09:26.01 | irroot | wdoekes2 morning there |
| 09:26.10 | schmidts | morning walter ;) |
| 09:26.21 | wdoekes2 | morning :) |
| 09:32.08 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:9c0f:25bd:8070:3d1a) |
| 09:33.01 | schmidts | load of the vz 25, load of host 0.11, concurrent calls 61 |
| 09:37.03 | schmidts | now load is 1.48 with 59 channels ??? |
| 09:41.33 | wdoekes2 | the load can give a skewed image |
| 09:42.20 | wdoekes2 | for example, I have two asterisk boxes and on one a mysqld.. the other box always has a way higher load -- I guess because it always has a couple of threads waiting for sql data over tcp |
| 09:43.02 | wdoekes2 | this does not mean that otherbox has more to do. in fact, it has less to do because it isn't running the mysqld |
| 09:43.29 | schmidts | i see what you mean walter but the load is jumping around like crazy and i dont see a cause for this |
| 09:45.37 | schmidts | ok i have an idea what can cause this high load, asterisk is running with the always fork parameter and as far as i have seen this, it only depends on the console |
| 09:45.56 | schmidts | now i have exited the console and just what the load and call amount |
| 09:46.06 | schmidts | maybe its just the cli which generate this high load |
| 09:48.25 | schmidts | 56 active calls and a load of 0.6 maybe it was the fu..cking cli which cause the high load :( |
| 09:53.06 | irroot | damm its a bad week girlfriend was bit on arse by something and a night adder cant be ruled out [her fingers are still bit num and in pain] and now X has had car accident ... |
| 10:04.30 | schmidts | shit :( |
| 10:08.54 | irroot | but all seem ok |
| 10:09.06 | schmidts | thats the most important thing! |
| 10:26.34 | wdoekes2 | schmidts: if the cli seems to cause the high load, what happens if you clear out all the logging "families" from console=> in logger.conf? |
| 10:27.05 | schmidts | wdoekes2 you mean only this: console => |
| 10:27.15 | wdoekes2 | (if that works) |
| 10:27.57 | schmidts | i still see all verbose, warning and so on messages |
| 10:28.07 | schmidts | but the load stays at the same level |
| 10:28.38 | wdoekes2 | if you still see the messages, then it's not cleared out like expected |
| 10:29.06 | schmidts | i have done logger reload several times but it doesnt change anything |
| 10:29.10 | schmidts | i will try something else |
| 10:29.35 | schmidts | i have changed it to console => error and no change at all |
| 10:29.43 | schmidts | i still see all verbose, warning and error |
| 10:31.16 | schmidts | but it seems like it doesnt change the behavior, i will wiat for the next peak of calls maybe then i will see a difference |
| 10:31.41 | irroot | schmidts set verbose / debug 0 |
| 10:31.57 | irroot | maybe you have some -v when you start ? |
| 10:32.08 | schmidts | nope no -v |
| 10:32.17 | schmidts | ok now the cli stays empty |
| 10:32.25 | irroot | cool |
| 10:32.44 | schmidts | but also the syslog file :P |
| 10:32.47 | irroot | writing to the cli may need to go via the hypervisor and is not nice |
| 10:33.10 | schmidts | i really dont understand whats going wrong here |
| 10:33.15 | irroot | ive had klogd cause massive load in past |
| 10:33.28 | irroot | its the weather |
| 10:33.38 | schmidts | 8?C outside :D |
| 10:33.42 | schmidts | and some fog |
| 10:33.50 | wdoekes2 | 5C and foggy |
| 10:33.51 | schmidts | btw 63 concurrent calls and a load of 0.38 now |
| 10:33.54 | irroot | blame global warming er cooling er um what is the lattest ? |
| 10:34.13 | schmidts | for you it will be warming for us in europe cooling |
| 10:34.31 | wdoekes2 | I need more than 5C so they can connect water+gas+power to my new house |
| 10:34.55 | irroot | our temps can overnight go -3/4 in winter during day in winter ~10 in summer ~25+ |
| 10:35.04 | irroot | atm its 32c |
| 10:35.23 | *** join/#asterisk-dev jmls (~Julian@host217-36-208-155.in-addr.btopenworld.com) |
| 10:35.43 | schmidts | :P |
| 10:35.44 | jmls | grr. what's the amazon ec2 package for gmime and ical ? |
| 10:35.46 | irroot | jmls 0/ |
| 10:35.48 | irroot | o/ |
| 10:35.54 | jmls | irroot: :) |
| 10:50.48 | schmidts | irroot even i dont understand why the load is going up sometimes and i can even see some short blocks but the peaktime is nearly over and it looks not so bad |
| 10:51.46 | schmidts | load is at 0.21 with 54 active calls, 5350 calls processed |
| 10:59.00 | irroot | mmm |
| 11:57.33 | jmls | anyone got an idea on the amazon ec2 package for gmime and ical ? |
| 12:08.46 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187-28-37-118.poolip.RJO.embratel.net.br) |
| 12:14.53 | schmidts | ok i have routet all calls away and removed the fork always flag and also recompile with optimization on and also dont debug threads and now i am really interested how it looks |
| 12:15.01 | schmidts | btw i had around 25 dead calls before |
| 12:24.38 | schmidts | 33 concurrent calls and load of 0.07 :D |
| 12:28.57 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:28.57 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:51.01 | *** join/#asterisk-dev blitzrage (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:51.01 | *** mode/#asterisk-dev [+o blitzrage] by ChanServ |
| 13:56.01 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 14:09.34 | *** join/#asterisk-dev bklang (~bklang@tesla.alkaloid.net) |
| 14:15.55 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-mjeippjnjmqndqqv) |
| 14:15.55 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:19.12 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:19.12 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:10.40 | *** join/#asterisk-dev joshaidan (~brianj@S0106001c1023e838.tb.shawcable.net) |
| 15:18.40 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 15:18.40 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:26.38 | *** join/#asterisk-dev oej (~olle@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 15:26.38 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:27.21 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.79) |
| 15:33.32 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 15:33.32 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 15:38.39 | oej | We still have too many file handles used per meetme... |
| 15:39.38 | oej | otherwiseguy: Around? |
| 15:39.58 | otherwiseguy | oej: yep. on a conference call that should be done in a couple of minutes. |
| 15:40.12 | oej | Ok |
| 15:43.56 | otherwiseguy | oej: back. |
| 15:44.07 | oej | I'm confused with the registration stuff. |
| 15:44.17 | oej | Since when did we match on domain names for peer matching? |
| 15:44.32 | oej | We ahve always cut off domains |
| 15:45.06 | oej | Is this a bug in later versions you are referring to? |
| 15:45.37 | otherwiseguy | It's two different parts. One is registration, and the other is check_user_full. In 1.4 we treated what really would have been a domain-only URI as a username and go ahead and match it. In 1.8, we used the new parse_uri function and no longer did that. |
| 15:46.05 | oej | So it was a bug in 1.4... |
| 15:46.06 | oej | I get it |
| 15:46.21 | otherwiseguy | This would be about matching sip:example.com to [example.com], not matching sip:terry@example.com to [terry@example.com] |
| 15:46.31 | oej | Yes |
| 15:46.42 | oej | That is not good |
| 15:47.17 | oej | so if I have a peer with host=ip and register to that peer name, like sip.myprovider.net |
| 15:47.18 | otherwiseguy | Well, since it is a policy decision I'm not sure it is really a bug. It was just the policy to match domains (really hosts) to a peer if we had no username. |
| 15:47.28 | oej | we would say "no registrations allowed" and expose it as a peer |
| 15:48.06 | otherwiseguy | If you have a peer with host=ip, and try to register to it, we would deny it because you didn't have host=dynamic. |
| 15:48.32 | oej | Yes, but is that denial different from trying to register with any name? |
| 15:52.52 | otherwiseguy | I don't *think* so, but I'm not sure. I have been looking just at whether we match like we used to or not. Since it is perfectly valid to have a Trom: <sip:example.com>, what we did in 1.4 makes sense. The only information we have to match on is the domain and the registration is essentially saying "this is the registration for this domain", so matching to peer [example.com] is a perfectly logical thing to do. There is a comment saying it is a R |
| 15:52.53 | otherwiseguy | violation, but it really isn't. |
| 15:53.19 | oej | It's a valid URI, but doesn't have to be valid for REGISTRATION, Terry. |
| 15:53.20 | otherwiseguy | s/Trom/To/ |
| 15:53.35 | oej | It doesn't feel like it complies with our idea of peers and users at all. |
| 15:53.38 | otherwiseguy | It doesn't *have* to be, but the RFC says it isn't invalid. |
| 15:53.53 | oej | The RFC says that you can register to any uri. |
| 15:54.08 | otherwiseguy | We could reject perfectly valid things if we want to. :-) |
| 15:54.15 | oej | But there is room for implementation specific stuff here. We have to decided ourselves which URI's we support registration for. |
| 15:54.15 | otherwiseguy | It is all policy. |
| 15:54.31 | oej | Yep. We are NOT breaking the RFC is we don't allow registartion to a domain. |
| 15:54.40 | otherwiseguy | Right. And since we accepted that for the first 10 years of the project, I figure it worked out ok. |
| 15:54.51 | otherwiseguy | We probably shouldn't change it. |
| 15:54.59 | oej | I think it's bad and should be deprecated and forgotten as BAD history. |
| 15:55.03 | oej | a mistake. |
| 15:56.35 | otherwiseguy | But why? A registration for a domain could be like saying "this domain is a single user". It makes sense. |
| 15:57.11 | otherwiseguy | I can't think of a single reason that it hurts anything. |
| 15:58.56 | oej | As long as we have peers/users I think we should have a clear matching. This is yet another exception that will be hard to document, educate and explain. It has very limited use for anyone. |
| 16:00.22 | oej | How many times do we have to explain that SIP:myserver.tls hits "s" in the dialplan? |
| 16:01.10 | otherwiseguy | That is a completely aesthetic argument, though. It is not hard to document. "Registrations with no username part will be matched by the domain in the request." We haven't had to explain it ever in 10 years. I don't think it will be a burden. |
| 16:02.04 | otherwiseguy | Dialplan, again, is only for R-URI. I'm not sure why it comes in to play. |
| 16:03.58 | oej | Ok, I won't fight more. I just don't think it's ok to support it. |
| 16:04.05 | oej | Gotta go home for dinner |
| 16:04.21 | otherwiseguy | oej: have something tasty! |
| 16:05.02 | irroot | ok datastore set on picked up channel is most usful |
| 16:06.25 | oej | What worries me more is the dahdi file handles. Gotta continue checking that tomorrow. Reality is not compatible with kpfleming. |
| 16:23.18 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 16:23.19 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:52.40 | Qwell | I'm confused by Danny's response on -users |
| 16:52.48 | Qwell | Isn't that precisely what the rc is? |
| 16:55.55 | kpfleming | umm... yeah. |
| 16:56.17 | kpfleming | it's a bit hard to understand people when they label things by telling you what they are not... |
| 16:56.46 | kpfleming | but last night's south park was funny and somewhat related :-) |
| 17:01.31 | blitzrage | kpfleming: was Canada to blame? |
| 17:02.53 | kpfleming | blitzrage: not this time... the History Channel |
| 17:04.37 | *** join/#asterisk-dev bklang (~bklang@tesla.alkaloid.net) |
| 17:13.28 | irroot | not wanting to be left out of the channel datastore rush added one so that app_queue can detect a pickup before bridging to log and free the user |
| 17:14.40 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.79) |
| 17:16.37 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187-28-37-118.poolip.RJO.embratel.net.br) |
| 17:23.29 | irroot | anonymouz666 lo there will you also be keen in sharing internal usage state of members |
| 17:24.36 | irroot | the queue im working on has a slightly modified state system . it keeps track of members been called and bridged in app_queue |
| 17:28.56 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 17:28.56 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:53.23 | *** join/#asterisk-dev citywok (~citywok@67-134-194-33.dia.static.qwest.net) |
| 17:53.24 | *** join/#asterisk-dev joshaidan (~brianj@216-211-66-197.block.tbaytel.net) |
| 17:56.46 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 17:56.46 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:43.04 | *** join/#asterisk-dev joshaidan_ (~brianj@216-26-202-160.dynamic.tbaytel.net) |
| 19:06.53 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 19:06.53 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 19:25.33 | *** join/#asterisk-dev otherwiseguy (~otherwise@rrcs-173-197-0-67.west.biz.rr.com) |
| 19:28.15 | *** join/#asterisk-dev joshaidan (~brianj@S0106602ad06b3517.tb.shawcable.net) |
| 19:44.56 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 19:44.56 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:09.15 | acidfoo | any one know when the AstriConDev pictures will be online ? ;D |
| 20:13.52 | blitzrage | looks at kpfleming |
| 20:14.01 | blitzrage | kpfleming: if you email me the pics I will put them on the wiki for you :) |
| 20:17.48 | Marquis42 | blitzrage: Didn't you take some pictures too? :P |
| 20:18.07 | blitzrage | Marquis42: sssshhhhh |
| 20:18.10 | blitzrage | (yes) |
| 20:18.21 | Marquis42 | :) |
| 20:18.28 | blitzrage | I need to see if I can stitch together those pics I took into something reasonably decent :) |
| 20:18.50 | Marquis42 | Oh yeah, you did the 360 degree panorama thing too. I forgot about that. |
| 20:19.35 | blitzrage | yep |
| 20:40.31 | *** join/#asterisk-dev spditner (~simon@206-248-134-157.dsl.teksavvy.com) |
| 20:41.49 | spditner | Is ConfBridge ready for general use in 1.8.7.1? I'm seeing it fail to mute users before the marked user arrives, even though the features.mute flag is set to 1 |
| 20:43.00 | spditner | for each non-marked user as they join |
| 20:43.17 | blitzrage | while this isn't really the answer to your question, ConfBridge in 1.8 is totally different from that in Asterisk 10. |
| 20:44.48 | kpfleming | Marquis42: it was actually 372.5 degrees... inflation and all |
| 20:45.08 | Marquis42 | kpfleming: touche! |
| 20:45.21 | spditner | blitzrage: Yes, I noticed that when I tried to see what had changed. |
| 20:45.34 | kpfleming | it was nearly completely rewritten |
| 20:45.37 | blitzrage | spditner: pretty much rewritten |
| 20:45.46 | kpfleming | in 1.8 ConfBridge is semi-experimental, in 10 it's a core feature |
| 20:45.53 | blitzrage | on 1.8, I'd probably suggest you just use MeetMe() |
| 20:46.38 | spditner | I don't have the luxury of kernel modules, so no timing source. |
| 20:46.45 | blitzrage | there probably is, but is there a reason why res_timing_dahdi doesn't have the high preferred weight? |
| 20:46.57 | blitzrage | s/high/highest/ |
| 20:47.36 | kpfleming | i thought it did already |
| 20:47.52 | Qwell | timerfd > kqueue(?!) > dahdi > pthread |
| 20:48.08 | kpfleming | spditner: meetme requires dahdi for mixing, not timing. timing can be provided via other means than just kernel modules, but DAHDI mixing requires DAHDI. |
| 20:48.25 | kpfleming | i'm not really sure why timerfd has a higher preference than dahdi |
| 20:48.29 | kpfleming | did it change at some point? |
| 20:48.52 | blitzrage | no idea |
| 20:48.57 | blitzrage | that's just how it is now though :) |
| 20:49.07 | kpfleming | 'svn blame' on the source files should tell you |
| 20:49.52 | Qwell | priorities don't appear to have ever changed |
| 20:50.00 | Qwell | at least not in dahdi or timerfd |
| 20:50.20 | blitzrage | ya, dahdi hasn't changed that line since 2009 |
| 20:50.26 | spditner | kpfleming: does dahdi mixing still require the kernel modules to be around though it doesn't use them? |
| 20:50.36 | kpfleming | dahdi mixing does use kernel modules |
| 20:50.40 | kpfleming | the mixing is done in DAHDI |
| 20:52.04 | spditner | ok, so asterisk 10 is the short answer if I'm planning on using ConfBridge and avoiding kernel modules |
| 20:52.13 | kpfleming | correct |
| 20:52.14 | blitzrage | aye |
| 20:53.09 | spditner | Are there many RC's planned, or is the next one likely a release-release? |
| 20:53.12 | kpfleming | i suppose it is possible that res_timing_timerfd is less 'costly' than res_timing_dahdi, but i don't remember anyone actually confirming that to be the case, so i don't know why res_timing_timerfd is preferred over res_timing_dahdi |
| 20:54.00 | blitzrage | spditner: hard to say depending on what gets reported |
| 20:54.18 | blitzrage | if nothing is reported that is OMG THAT IS SO BROKEN then 10.0.0-rc1 would probably become 10.0.0 |
| 21:17.41 | *** join/#asterisk-dev Netgeeks (~chris@gw1.netgeeks.net) |
| 23:26.04 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-mjeippjnjmqndqqv) |