| 01:29.34 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 01:29.34 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 01:52.02 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 01:52.02 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 01:53.34 | *** part/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 02:17.07 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 02:17.07 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 02:39.28 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 02:39.28 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 02:57.13 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 03:05.49 | *** part/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 03:26.15 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 03:52.16 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 05:00.16 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-ehsabbmltvmdhxcx) |
| 05:10.15 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 05:10.15 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 05:28.28 | *** join/#asterisk-dev mpe (~mpe@109.70.54.56) |
| 05:43.53 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 05:43.54 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 05:48.09 | *** join/#asterisk-dev kenhunt (~kenhunt@nat/digium/x-ylbeekmjbodzmffg) |
| 05:57.26 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-txqehwmhuiksguhq) |
| 06:09.57 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 06:09.59 | schmidts | good morning |
| 06:33.04 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 06:33.04 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:45.00 | oej | morning folks |
| 07:19.17 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 07:19.18 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 07:21.14 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:8961:852c:818e:6c07) |
| 07:41.34 | *** join/#asterisk-dev Tim_Toady (~moi@188.4.93.97.dsl.dyn.forthnet.gr) |
| 07:54.28 | *** join/#asterisk-dev Tim_Toady (~fuzzy@188.4.93.97.dsl.dyn.forthnet.gr) |
| 08:25.23 | *** join/#asterisk-dev mpe (~mpe@109.70.54.56) |
| 10:57.11 | mvanbaak | mornin all |
| 11:14.50 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 11:14.50 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 11:23.12 | mealstrom | good afternoon :D |
| 11:23.29 | mealstrom | dont forget to sleep :D |
| 11:37.46 | mvanbaak | gheh |
| 11:37.52 | *** join/#asterisk-dev hehol (~hehol@217.9.101.222) |
| 11:37.54 | mvanbaak | sleep is overrated and a waste of time |
| 11:43.51 | *** join/#asterisk-dev mpe (~mpe@109.70.54.56) |
| 11:44.12 | *** part/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 11:56.46 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 11:56.46 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 12:01.01 | *** join/#asterisk-dev mpe_ (~mpe@109.70.54.56) |
| 12:22.17 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:22.18 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 13:00.32 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-qcczrrfcpyxswvmh) |
| 13:00.32 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:15.44 | mealstrom | does asterisk now support queue_log via odbc driver "? |
| 13:20.38 | kpfleming | no |
| 13:41.15 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 13:41.15 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 13:44.02 | mealstrom | hah |
| 13:44.08 | mealstrom | it works over odbc :D |
| 13:44.25 | mealstrom | asterisk 1.8.9.3 |
| 13:44.31 | mealstrom | weee :D |
| 13:44.53 | mealstrom | kpfleming: it suppors via extconfig |
| 13:45.14 | kpfleming | ahh |
| 13:45.18 | leifmadsen | aye it does :) |
| 13:45.32 | kpfleming | well, then you had your answer and didn't have to ask here... especially since it wasn't a development question :-) |
| 13:45.45 | leifmadsen | that ^^ :) |
| 13:48.18 | acidfoo | hi folks, when I call, int ast_rtp_instance_destroy(struct ast_rtp_instance *instance) that is doing : ao2_ref(instance, -1); ... when does the callback "instance_destructor" will be called ? |
| 13:48.33 | file | when the reference count reaches zero. |
| 13:48.41 | acidfoo | there is a thread that monitor the counter ? |
| 13:49.01 | acidfoo | or do I need to call the cleaning lady ;P |
| 13:49.13 | file | no, ao2_ref knows when the reference count reaches 0 and calls the destructor |
| 13:49.36 | acidfoo | ok, it beg me the question... how can I print the value of this counter |
| 13:49.40 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 13:49.40 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 13:49.55 | opticron | acidfoo, you probably want to turn on reference debugging |
| 13:51.48 | acidfoo | mmkay |
| 13:52.16 | opticron | doesn't remember if that's in menuselect or just a define to be enabled in the code |
| 13:54.29 | mjordan | acidfoo: in trunk, at least, turning on the TEST_FRAMEWORK will enable reference count debugging |
| 13:54.46 | acidfoo | ok, ill look at it |
| 13:54.51 | mjordan | in other versions, you'll have to do it explicitly |
| 13:54.52 | acidfoo | thank you for the inputs |
| 13:55.33 | opticron | ah, that's what it was |
| 13:55.47 | opticron | attempts to file away that nugget of information |
| 13:59.59 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:59.59 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:15.31 | *** join/#asterisk-dev mpe_ (~mpe@109.70.54.56) |
| 14:16.36 | *** join/#asterisk-dev mpe (~mpe@109.70.54.56) |
| 14:24.35 | mjordan | in regards to ASTERISK-17886 - does anyone know why lastmsgssent was removed in Asterisk 10/trunk? And does anyone have any issue with putting the field back in (assuming of course that the value is actually useful, as opposed to its current state in 1.8)? |
| 14:24.41 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-xmnwxzdufgveebmy) |
| 14:28.44 | Corydon76-home | mjordan: in 1.8, it appears that field is only ever set to -1, nothing else, so it would appear to be useless |
| 14:28.51 | *** part/#asterisk-dev mealstrom (~mealstrom@46.63.71.254) |
| 14:29.25 | mjordan | Corydon76-home: agreed. I have a patch that fixes that, but I don't want to propose fixing the field if we removed it from later versions for a reason |
| 14:29.55 | mjordan | and if we did remove it for a reason, it should have been removed from 1.8, as opposed to its current 'functionality' |
| 14:30.24 | Corydon76-home | Well, another part of it is that the field is a concatenation of 2 different fields for seemingly no reason at all |
| 14:33.51 | mjordan | Corydon76-home: the upper 16 bits are used to represent the new messages, while the lower 16 bits are used for the old messages. They probably should have just been two separate fields. |
| 14:33.54 | Corydon76-home | Oh, here's another good reason. In an older version, we used polling on the mailbox, then checked against that value to know if we needed to send an update to the phone |
| 14:34.18 | Corydon76-home | Now, we use an event-driven model, so knowing the old value really isn't important anymore |
| 14:34.32 | mjordan | yeah, I see this field being used only for informational purposes |
| 14:36.11 | *** join/#asterisk-dev zerohalo (~zerohalo@74-94-141-204-ma.hfc.comcastbusiness.net) |
| 14:37.39 | Corydon76-home | I think the reason we didn't remove it from 1.8 is that AMI depends upon that field being there, and removing it could potentially break external applications. |
| 14:37.56 | mjordan | except of course that the value of the field is meaningless |
| 14:38.00 | mjordan | so they're probably broken anyway :-) |
| 14:38.19 | Corydon76-home | for multiple meanings of 'broken', though |
| 14:38.32 | mjordan | true :-) |
| 14:39.48 | mjordan | A part of me would prefer to put the field back in, simply to maintain backwards compatibility with people who relied on the field being present for some external application. |
| 14:47.56 | *** join/#asterisk-dev sustav (~alfa@nat/digium/x-yljqotbwfisdsfmu) |
| 14:49.52 | leifmadsen | mjordan: maybe put it there, and make it a noop(), then deprecate it in AMI currentversion()+1 |
| 14:49.59 | leifmadsen | s/deprecate/remove |
| 14:50.13 | leifmadsen | we can remove stuff from AMI if we increase the version of it |
| 14:51.38 | mjordan | leifmadsen: true, but if we put the logic back in to make the field useful, I don't see any value in deprecating it in the future either. |
| 14:52.00 | leifmadsen | ya if you want to fix it, then that's fine with me :) |
| 14:52.02 | mjordan | leifmadsen: this feels more like someone felt it was too much of a hassle to make the field useful again, and since it no longer served its original purpose, they just removed it |
| 14:52.07 | leifmadsen | if it does something, I'm ok with that |
| 15:01.30 | leifmadsen | mjordan: you sir, are a gentleman and a scholar |
| 15:19.15 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 15:19.15 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 15:21.05 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:21.06 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:51.30 | *** join/#asterisk-dev mbrevda (u5500@gateway/web/irccloud.com/x-pxohqowzhedlwcfk) |
| 16:04.40 | *** join/#asterisk-dev GameGamer43 (u5533@gateway/web/irccloud.com/x-kvtqtmrmetgskude) |
| 16:31.03 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 16:31.03 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 17:38.47 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 17:55.51 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 17:55.51 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 17:56.08 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 17:56.08 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 17:56.09 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-mlnvgnhbrhefrprh) |
| 17:56.31 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 17:56.31 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 17:56.40 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-nsgseiqastnrpjyl) |
| 17:57.27 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-mhztfrknfiiptknw) |
| 17:57.27 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 19:02.34 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 19:02.35 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 19:20.12 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 19:56.25 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 19:56.26 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 21:10.48 | otherwiseguy | Hmm, so handling multiple config files (ala sip.conf and users.conf), as well as crazy configs like chan_mobile.conf that has multiple identical category names is "fun". |
| 21:11.04 | Qwell | users.conf is also...special |
| 21:11.18 | Qwell | Look at the order it gets parsed in chan_sip |
| 21:11.25 | otherwiseguy | I guess I will add an option to the aco_info stuct: duplicate_handling = ACO_DUP_REJECT, ACO_DUP_ALLOW, or ACO_DUP_MERGE... |
| 21:11.55 | otherwiseguy | Since for some modules, duplicate category names would be an error, some it is just peachy, and if you are doing two files you need to merge the values. |
| 21:12.38 | otherwiseguy | looks |
| 21:14.36 | Qwell | sip.conf [general] and [authentication], users.conf, sip.conf everything else |
| 21:15.04 | otherwiseguy | ugh. |
| 21:15.06 | otherwiseguy | and ugh. |
| 21:15.21 | otherwiseguy | recommends deprecating users.conf in 11 |
| 21:17.59 | otherwiseguy | users.conf was such an incredibly bad idea. |
| 21:39.21 | leifmadsen | +1 |
| 21:50.34 | otherwiseguy | I don't suppose there would be some general support out there for eventually phasing out users.conf altogether... |
| 21:59.19 | kpfleming | otherwiseguy: unfortunately, our current policies don't allow for such an action to occur |
| 22:01.16 | otherwiseguy | kpfleming: The great things about policies are that they are not immutable. |
| 22:01.36 | kpfleming | this policy is immutable, due to its own existence |
| 22:04.24 | otherwiseguy | I'm pretty sure there is a reason that policies are ammendable. Nobody ever gets them right the first time. Hence constitutional ammendments, etc. Not that I necessarily think that there should be ammendment, just that ammendment possibilities are often healthy. |
| 22:04.50 | otherwiseguy | It is mostly a dream. But users.conf is some seriously bad baggage. |
| 22:05.18 | kpfleming | you included an extra 'm' four times in that message. you are consistent, though. |
| 22:05.46 | otherwiseguy | And it sounds like it is bad baggage that isn't even used by most of the types of things it was designed for--Asterisk GUIs, etc. |
| 22:05.59 | kpfleming | in order for users.conf to go away, res_phoneprov would either have to also go away, or be modified to use config hooks to get access to the information it needs. |
| 22:06.31 | kpfleming | i'm not opposed to you throwing the idea out on the mailing lists to gauge the reaction |
| 22:06.32 | otherwiseguy | If only there was someone with intimate knowledge of res_phoneprov who also hated users.conf. :-) |
| 22:06.47 | kpfleming | i wouldn't be surprised if there are quite a few users who use users.conf without using a GUI |
| 22:07.20 | WIMPy | Yes, I've got it in use on one box. |
| 22:07.45 | otherwiseguy | I'll throw the idea out there. I don't expect it to be particularly popular and I'm not convinced that it is truly good policy to remove it. But handling it without behavior change with the new config stuff is going to be a serious pain. |
| 22:07.49 | WIMPy | But I certainly wouldn't mind if it went away. |
| 22:08.40 | otherwiseguy | Maybe if I wrote a script that would take a users.conf and add the appropriate bits to existing .conf files... |
| 22:13.15 | otherwiseguy | if (changed_from_sample_config(users_conf) && !already_processed(users_conf)) {apply_users_conf_to_configs(); mark_users_conf_processed();} |
| 22:14.34 | kpfleming | so how about approaching the API from that point of view? write a preprocessor that specifically understands users.conf, rather than modifying the framework to support merging overlapping config files/ |
| 22:21.22 | otherwiseguy | kpfleming: Can you think of any situation besides users.conf that requires a module reading multiple config files? |
| 22:21.32 | otherwiseguy | If not, then it seems like that could work. |
| 22:21.36 | kpfleming | not off the top of my head... but i wouldn't rule it out |
| 22:21.52 | kpfleming | if you can't find another example in the tree, then yeah, that would be a better approach |
| 22:24.05 | otherwiseguy | I wonder if all modules handle users.conf priority the same way... |
| 22:24.29 | otherwiseguy | i.e. it gets overrided by the "real" config file. |
| 22:27.06 | otherwiseguy | Also, the weird load order in chan_sip isn't that weird, I suppose. It loads [general] [authentication], the global config categories, then users.conf (which I think only contains sip friend-like stuff) and then overwrites it with the peer definitions. I don't think it would matter to just load users.conf then sip.conf. I could be missing something, though. |
| 22:27.25 | kpfleming | yes, it just gets sip friends from users.conf. |
| 22:28.17 | otherwiseguy | So if everything does stuff like that, then processing the two files in order "users.conf" then the real config, shouldn't be a problem… I suppose I need to go through all of the users.conf-supporting modules. |
| 22:28.34 | kpfleming | shudders at app_voicemail |
| 22:28.48 | otherwiseguy | ugh, yeah. I haven't looked at that. |
| 22:29.06 | otherwiseguy | There is also no law that *every* module has to use the new config stuff. :-D |
| 22:29.53 | otherwiseguy | For example, I never even considered extensions.conf and don't plan to. |
| 22:30.09 | kpfleming | it's not really a config file anyway |
| 22:30.32 | kpfleming | but some of the benefits of the config framework would be useful there, and the loading logic already handles 'load new, merge later' |
| 22:35.35 | *** join/#asterisk-dev mpe_ (~mpe@109.70.54.56) |
| 23:48.34 | WIMPy | When a call is diverted by a sip phone, chan_sip sets REDIRECTING(name) to the *username* of the divertig device. Otherwise it doesn't set any sensible information. |
| 23:48.36 | WIMPy | Not knowing what other channels make of that information, could that leak account names? Should I open a bug for that? |