| 00:01.00 | *** part/#asterisk-dev barkbus (~barkbus@89-96-128-52.ip12.fastwebnet.it) |
| 00:41.51 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 00:41.51 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 01:11.47 | *** join/#asterisk-dev dms (~dms@190.7.201.35) |
| 01:11.47 | *** mode/#asterisk-dev [+o dms] by ChanServ |
| 01:50.07 | *** join/#asterisk-dev droemel (~droemel@p4FCACF6A.dip.t-dialin.net) |
| 01:58.21 | *** join/#asterisk-dev GameGamer43 (uid5533@gateway/web/irccloud.com/x-taslwcepupfdqwhx) |
| 02:08.57 | *** join/#asterisk-dev tonyclewis (uid6025@gateway/web/irccloud.com/x-nfdwmaqfadwrtvby) |
| 04:02.07 | WIMPy | Can someone please reopen ASTERISK-199270 |
| 05:12.22 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-speytopbsceryvpd) |
| 05:27.09 | *** join/#asterisk-dev Micc (~Mic@c-24-19-33-189.hsd1.wa.comcast.net) |
| 05:29.06 | Micc | why do blf states change in asterisk 11 so much when nothing is happening? I think its happening when the phone registers. |
| 05:29.20 | Micc | or when it subscribes or something. it never did this in older versions of asterisk. |
| 05:30.12 | WIMPy | The phone being watched, I assume? |
| 05:42.20 | Micc | No, actually they are custom BLFs. |
| 05:42.26 | Micc | custom hints |
| 05:42.54 | Micc | I removed all the device hints, thinking it would stop, but it didnt. |
| 05:43.24 | Micc | which is weird, maybe the message is just showing in the CLI every time it sends the status to the phone. |
| 06:40.03 | *** join/#asterisk-dev latv (~latv@109.238.244.73) |
| 07:26.54 | *** join/#asterisk-dev bulkorok (~bulkorok@85.183.36.36) |
| 09:02.09 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 10:47.32 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 10:47.33 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 10:56.30 | *** join/#asterisk-dev GameGamer43 (uid5533@gateway/web/irccloud.com/x-asxfaswgiubxypae) |
| 11:51.30 | *** join/#asterisk-dev italorossi (~textual@189.124.196.68) |
| 12:23.44 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 12:23.44 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 13:12.36 | *** join/#asterisk-dev blitzrage (~leifmadse@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:12.36 | *** mode/#asterisk-dev [+o blitzrage] by ChanServ |
| 13:34.51 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 13:34.51 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 13:55.26 | *** join/#asterisk-dev bombev (~bombev@PPPoE-Static-40-132.UnicsBG.Net) |
| 14:00.17 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-mccqrjrrcbdlaztw) |
| 14:08.26 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 14:08.26 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 14:21.11 | *** join/#asterisk-dev bombev (~bombev@PPPoE-Static-40-132.UnicsBG.Net) |
| 14:51.15 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-gmyqsqfadhhxpeaz) |
| 14:51.16 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:10.43 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:10.43 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:18.48 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:18.48 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:27.42 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 15:38.54 | file | Tuesday! |
| 15:48.12 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 15:57.10 | mjordan | gotta get down with Tuesday? |
| 15:57.33 | file | only on Wednesday |
| 16:09.52 | blitzrage | Tuesday. Meh. |
| 16:33.04 | WIMPy | I just tried and it looks like there are only two sates. verbose 0 disables verbose and any other number will enable verbose 0 and 1. Higher numbers don't work. |
| 16:34.35 | WIMPy | http://wimpy.yeti.dk/pastebin |
| 16:35.16 | WIMPy | Is that about with what level of verbosity the daemon was started? |
| 16:36.29 | mjordan | hm. This is probably a result of the remote console verbose settings |
| 16:36.47 | WIMPy | To answer myself: Yes. |
| 16:37.07 | mjordan | Each logging destination and console now have an independent notion of the current verbosity level. logger.conf now allows an optional argument to the 'verbose' specifier, indicating the level of verbosity sent to that particular logging destination. Additionally, remote consoles now each have their own verbosity level. The command core set verbose will now set a separate level for each remote console without affecting any other co |
| 16:37.11 | WIMPy | Looks like the daemons verbose level sets the maximum level for the remote console. |
| 16:39.06 | WIMPy | That is rather unintuitive and I question the sense of it. |
| 17:09.52 | WIMPy | Somethign about Confbridge: I found that after setting Set(CONFBRIDGE(user,pin)=1234) you cannot clear it again with Set(CONFBRIDGE(user,pin)=). Only setting a teplate clears the PIN. Do you consider |
| 17:09.57 | WIMPy | that a bug? |
| 17:12.00 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 17:13.48 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 17:13.51 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 17:53.19 | JunK-Y | mjordan: nice! |
| 18:12.45 | *** join/#asterisk-dev Slivka (~Slivka@31.40.53.139) |
| 18:13.45 | JunK-Y | WIMPy: sounds like it, yeah. |
| 19:01.43 | pabelanger | I'm just going to say it.... app_directory is shit! |
| 19:02.34 | russellb | pabelanger: watch your mouth, there are children around (leifmadsen) |
| 19:04.10 | WIMPy | opens another can. Now that there's work in progress to make variables case sensitive, wht do you think about making extensions case sensitive? |
| 19:04.11 | blitzrage | my virgin eyes! |
| 19:04.55 | WIMPy | If you've got names as extensions it can be hard to realise that z, n and X are also being treated as wildcards not matching themselves. |
| 19:05.21 | blitzrage | made a note about that in the book :) |
| 19:05.45 | Qwell | aren't they case sensitive? |
| 19:05.48 | blitzrage | _fra[n]k[z]-XXX,1,NoOp() |
| 19:05.54 | blitzrage | Qwell: no |
| 19:05.55 | WIMPy | nope. |
| 19:05.57 | Qwell | huh |
| 19:05.59 | blitzrage | not the pattern matching at least |
| 19:06.09 | blitzrage | n == N, etc |
| 19:06.23 | blitzrage | putnopvut: ^^^ something to consider in the change? |
| 19:06.26 | Qwell | why did we never add ?? |
| 19:06.32 | putnopvut | wassup? |
| 19:06.33 | Qwell | blitzrage: that would break way more stuff |
| 19:06.36 | blitzrage | because I didn't write it up |
| 19:06.44 | blitzrage | Qwell: what would break way more stuff? |
| 19:07.11 | blitzrage | either way, it would have to be a separate discussion on asterisk-dev |
| 19:07.12 | WIMPy | thinks it would be nice if all lower case letters were safe to use. |
| 19:07.46 | blitzrage | I think a warning that just points out when you use unescaped [nNxXzZ] would also be sufficient |
| 19:08.10 | WIMPy | Sonds impossible to me. |
| 19:08.20 | blitzrage | nothign is impossible |
| 19:08.24 | WIMPy | How do you know if it was intended as a wildcard or not? |
| 19:08.28 | putnopvut | Yeah all I was addressing with case-sensitivity was the evaluation of variable names. As far things like n and x are concerned, well, I have no idea if that should be case-sensitive or not. |
| 19:08.34 | blitzrage | WIMPy: hence just the warning |
| 19:08.38 | blitzrage | a warning makes no changes |
| 19:08.49 | blitzrage | putnopvut: right |
| 19:08.54 | blitzrage | hence my pointer to asterisk-dev ML |
| 19:08.58 | WIMPy | Yes, but you'd get warnigs for all patterns then. |
| 19:09.30 | blitzrage | could make it only when it is included in strings with non-pattern characters |
| 19:09.49 | blitzrage | _frankz could generate a warning when _nxxnxxxxxx didn't |
| 19:09.53 | WIMPy | Might be possible. |
| 19:10.01 | blitzrage | like I said? nothing is impossible |
| 19:10.55 | pabelanger | since we are making requests..... _[N-NNNN]*.,1,NoOp() would be sweet |
| 19:11.15 | WIMPy | Sure, but I find warnings about things that were ment to be the way they are rather annoying. |
| 19:11.35 | blitzrage | shrugs |
| 19:11.42 | Qwell | blitzrage: non-numeric non-patterns |
| 19:11.46 | WIMPy | pabelanger: Meaning what? |
| 19:11.52 | blitzrage | WIMPy: range |
| 19:12.04 | Qwell | meh. regex. |
| 19:12.22 | WIMPy | We have ranges. |
| 19:12.48 | Qwell | WIMPy: limited |
| 19:12.51 | blitzrage | there was a whole discussion on the mailing list like ? 18-24 months ago about additional pattern matches and such |
| 19:13.01 | Qwell | You can do ranges of ^10 |
| 19:13.07 | blitzrage | if that's where this is going? someone should just go re-read it :) |
| 19:13.41 | WIMPy | So you're talking variable length patterns? |
| 19:18.25 | putnopvut | I sometimes wish that I could go back in time and try to talk Mark Spencer out of writing a meta-language for Asterisk dialplan in favor of using an existing programming language. |
| 19:18.58 | WIMPy | AEL? |
| 19:19.01 | WIMPy | LUA? |
| 19:19.03 | Qwell | WIMPy: dialplan |
| 19:19.42 | putnopvut | In other words, we could focus on maintaining Asterisk's core functionality instead of having to worry about programming language features like pattern matching and case sensitivity of variable names. |
| 19:20.02 | putnopvut | But what's done is done. |
| 19:23.21 | file | I wish stuff and things |
| 19:28.43 | blitzrage | putnopvut: agreed |
| 19:28.45 | blitzrage | WIMPy: none of those things replace the dialplan unfortuantely |
| 19:29.06 | blitzrage | things are so directly tied to how dialplan operates, that it's incredibly difficult to just drop dialplan in favor of something else |
| 20:41.27 | *** join/#asterisk-dev Micc (~Mic@199.38.209.68) |
| 20:41.53 | Micc | So it I haven't had another hang/lock since I built debugging and not optimize. |
| 20:42.28 | Micc | But I also removed all device BLFs. I only have custom hints now. |
| 20:43.08 | Micc | I spoke to soon. I think I got a lock right now |
| 20:43.22 | blitzrage | neat |
| 20:44.46 | Micc | http://pastebin.com/tEnZNXt6 |
| 20:44.57 | Micc | not what I expected. |
| 20:47.00 | pabelanger | do_timing() |
| 20:47.49 | Micc | Is this part of the new code that was done to get away form DAHDI timing? |
| 20:48.13 | Qwell | It's hardly new, but yes. |
| 20:48.32 | Micc | I thought it was new in 10 or 11. |
| 20:48.43 | Micc | or some changes were made to it in confbridge anyways. |
| 20:50.08 | mjordan | Micc: that doesn't really show a deadlock so much as something went out and never came back, which is odd |
| 20:50.10 | Micc | I mean to get away from dahdi timing in meetme or confbridge or something. I know I read that somewhere. |
| 20:50.24 | mjordan | Micc: definitely file a bug, but get a bt full from the process as well if you can |
| 20:50.33 | Micc | mjordan, your right, I didn't get a notice that it was rejecting or not accepting connections. |
| 20:50.37 | mjordan | Micc: and yes, timer_pthread is less then ideal |
| 20:50.49 | Micc | mjordan, but it was showing the same lock for about a minute, which I've never seen before. |
| 20:51.15 | Micc | mjordan, I'm happy to build it with some other timing support. what is best? |
| 20:51.19 | mjordan | Micc: res_timing_pthread is very inefficient |
| 20:51.19 | mjordan | https://wiki.asterisk.org/wiki/display/AST/Timing+Interfaces |
| 20:51.41 | mjordan | By default, Asterisk will build and load all of the timing interfaces. These timing interfaces are "ordered" based on a hard-coded priority number defined in each of the modules. As of the time of this writing, the preferences for the modules is the following: res_timing_timerfd.so, res_timing_kqueue.so (where available), res_timing_dahdi.so, res_timing_pthread.so. |
| 20:51.47 | mjordan | res_timing_timerfd |
| 20:52.55 | Micc | ok, I'll see what the dependancies are for timerfd and install them. |
| 20:53.44 | blitzrage | prefers res_timing_dahdi over all |
| 20:53.50 | blitzrage | res_timing_pthread is absolutely awful |
| 20:54.01 | blitzrage | if you DON'T have issues with that one, I'd be surprised |
| 20:54.13 | Micc | hmmm.. it just says timerfd (E) what do I install to make it build with this support? |
| 20:54.31 | blitzrage | it's a kernel thing |
| 20:54.35 | Micc | I've always used dahdi before. |
| 20:54.41 | blitzrage | same |
| 20:54.44 | Micc | I'm running on centos 5.8 xen |
| 20:54.49 | Qwell | too old |
| 20:55.07 | Qwell | It's like 2.6.23 or something. |
| 20:55.19 | Micc | shit, I don't like anything in 6, they took out native support for xen. |
| 20:55.31 | blitzrage | install ubuntu L:) |
| 20:55.48 | Micc | blitzrage, hell no. |
| 20:56.07 | Micc | I'll cut off my left nut before I use ubuntu for a production system. |
| 20:56.17 | pabelanger | o.0 |
| 20:56.19 | blitzrage | good times |
| 20:56.24 | mjordan | Micc: yeah, if you aren't running on a newer kernel and you don't want to use DAHDI as a timing source, then you're more or less stuck with pthread |
| 20:56.24 | blitzrage | isn't even going to bother |
| 20:56.25 | Qwell | Have fun with res_timing_pthread then? |
| 20:56.25 | coreyf1513 | Micc: timerfd requires kernel 2.6.25+ and glibc 2.8+ |
| 20:56.52 | mjordan | Micc: definitely file a bug report, we do try to make sure pthread works (as well as we can make it work) |
| 20:56.52 | blitzrage | you're better off with no timing module than pthread timing :D |
| 20:56.58 | mjordan | blitzrage: harsh |
| 20:57.02 | blitzrage | it's true |
| 20:57.18 | Micc | I've used dahdi on other xen servers. |
| 21:01.55 | Micc | mjordan, why wouldn't I want to use DAHDI? |
| 21:05.41 | mjordan | Micc: DAHDI is fine to use; some people like to not have any dependencies on it |
| 21:06.03 | mjordan | but its fine as a timing source |
| 21:06.05 | Micc | ok, I thought you were saying that because I have an old kernel it would be bad to use dahdi. |
| 21:06.08 | mjordan | nope |
| 21:06.14 | Micc | ok, I think thats my best bet then. |
| 21:06.19 | mjordan | I'd use res_timing_dahdi over res_timing_pthread any day |
| 21:06.37 | rmeyerriecks | I depend on dahdi |
| 21:06.53 | rmeyerriecks | or maybe it's the other way around |
| 21:06.56 | Micc | all my 1.8 and 1.6 production servers all depend on dahdi. |
| 21:07.40 | Micc | haven't had a crash or lock on any of those since I stopped using parking. :) |
| 21:07.52 | Micc | I made my own parking with dialplan. |
| 21:08.33 | pabelanger | Micc: Care to share your code? |
| 21:10.05 | Micc | I would, but I'm a bit affraid of loosing a competitive advantage. |
| 21:10.24 | pabelanger | boo |
| 21:10.52 | Micc | if you can convince me that it makes good business sense to share it, then I would. |
| 21:12.38 | blitzrage | Asterisk shouldn't be shared either |
| 21:13.03 | blitzrage | pabelanger: I've built parking in the dialplan with Bridge() and MusicOnHold() -- we can re-engineer it easy enough. |
| 21:13.30 | Micc | blitzrage, yup, thats the way. |
| 21:13.57 | blitzrage | Bridge() exists due to a request from me for the purposes of parking, so you're welcome from Steve Murphy and myself |
| 21:14.09 | Micc | and you can do it both park into spot, and pick the next available spot like the standard parking. |
| 21:14.17 | Micc | I like the push the spot you want it in. |
| 21:14.19 | blitzrage | this I know |
| 21:14.33 | blitzrage | it was used for multi-tenant parking before multi-tenant parking existed |
| 21:14.36 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 21:14.36 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 21:14.51 | Micc | blitzrage, thank you and Steve then. Without that I don't know if we would still be in business. |
| 21:15.07 | blitzrage | open source ftw then |
| 21:16.00 | Micc | I might be able to share it sometime soon since we might be moving away from that in favor of a ConfBridge version that lets you put multiple people in a spot or room. |
| 21:19.10 | Micc | is that how the bristof stuff works? |
| 21:22.49 | Micc | after looking at the parking code, I think it should be completely removed from the tree. |
| 21:22.50 | Micc | its evil. |
| 21:23.02 | Micc | has its claws in so many parts of asterisk code its rediculous. |
| 21:24.07 | mjordan | Micc: I'd say that I agree that the current parking implementation is not how I would envision it |
| 21:24.31 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 21:24.31 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 21:26.03 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.75.202) |
| 21:26.03 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 23:08.00 | *** join/#asterisk-dev spditner (~simon@206-248-134-173.dsl.teksavvy.com) |
| 23:11.59 | *** join/#asterisk-dev Micc (~Mic@c-174-61-157-8.hsd1.wa.comcast.net) |
| 23:12.07 | Micc | Ok, I got a real lock this time. |
| 23:12.09 | Micc | http://pastebin.com/suNNsjzA |
| 23:12.38 | Micc | looks like its still using pthread, but I built in the dahdi timer. |
| 23:12.50 | Micc | do I need to build it without the pthread? |
| 23:14.15 | mjordan | no, you just have to tell it to load the appropriate timing source in modules.conf |
| 23:14.25 | Micc | ah, ok |
| 23:14.47 | mjordan | but please do file an issue with the output you've got |
| 23:14.56 | mjordan | I'd still like to see if we can fix whatever goofiness res_timing_pthread is doing |
| 23:16.00 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-gmyqsqfadhhxpeaz) |
| 23:25.00 | putnopvut | And so the new chan_sip ball begins to roll... |
| 23:25.16 | jsmith | putnopvut: Oh? |
| 23:25.54 | putnopvut | jsmith: yeah, mailing list post and review board request to evaluate project page just got sent out. |
| 23:27.17 | jsmith | Cool |
| 23:27.22 | jsmith | I'll take a look |
| 23:50.19 | saghul | \o/ |