| 00:13.14 | *** join/#asterisk-dev superscrat (~asanders@173-21-89-217.client.mchsi.com) |
| 00:23.05 | *** join/#asterisk-dev superscrat (~asanders@173-21-89-217.client.mchsi.com) |
| 01:15.49 | *** join/#asterisk-dev superscrat (~asanders@173-21-89-217.client.mchsi.com) |
| 01:26.49 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 02:42.17 | *** join/#asterisk-dev mjordan (~mjordan@12.228.221.130) |
| 02:42.17 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 03:04.34 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 03:09.10 | *** join/#asterisk-dev WEBudo (c806db3e@gateway/web/freenode/ip.200.6.219.62) |
| 03:10.23 | WEBudo | hello everyone. I'm not a developer, but trying to modify source code to get rid of a problem with some very short dtmf not being handled correctly |
| 03:11.14 | WEBudo | I need to know where should I modify things first: channel.c or dsp.c ? |
| 03:22.16 | *** join/#asterisk-dev snuff-work (~blatus@1.152.96.145) |
| 03:22.16 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 03:34.15 | *** join/#asterisk-dev mjordan (~mjordan@12.228.221.130) |
| 03:34.15 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 03:48.43 | coreyfarrell | WEBudo: you'd have to trace the issue first. you should join #asterisk, start by figuring out if your issue can be dealt with in a config file. |
| 05:04.03 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip70-162-146-39.ph.ph.cox.net) |
| 05:18.17 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-lswbyvjaehycrxqe) |
| 05:42.54 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 05:42.55 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:47.18 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 06:51.23 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 06:51.24 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:51.30 | oej | Good morning folks! |
| 07:12.44 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 07:35.38 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:35.39 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:36.58 | *** join/#asterisk-dev snuff-work (~blatus@1.152.97.40) |
| 07:36.59 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 09:05.36 | *** join/#asterisk-dev tuxd00d_ (~tuxd00d@ip70-162-146-39.ph.ph.cox.net) |
| 11:52.26 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 11:52.26 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:54.30 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216.191.106.163) |
| 13:02.02 | *** join/#asterisk-dev mcargile (~mikec@office1.vicidial.com) |
| 13:11.04 | *** join/#asterisk-dev mjordan (~mjordan@12.228.221.130) |
| 13:11.04 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:12.37 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 13:23.33 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:23.33 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:42.21 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-mwnfahlmiqrojvbl) |
| 13:58.02 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-wuunvzhhckuqijaf) |
| 13:58.02 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:07.29 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-hynsqmgvfoxyobxo) |
| 14:18.16 | *** part/#asterisk-dev mcargile (~mikec@office1.vicidial.com) |
| 14:56.22 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-vulqgpcbsvytjhvh) |
| 15:15.36 | *** join/#asterisk-dev mjordan (~mjordan@173.227.23.8) |
| 15:15.36 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:17.48 | file | the hills are alive... |
| 15:30.41 | *** join/#asterisk-dev sgriepentrog (sgriepentr@nat/digium/x-hbzvkuslohdmodwf) |
| 15:59.46 | jsmith | file: .... with the sounds of ringing! |
| 16:06.55 | file | jsmith, yes! |
| 16:38.01 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 16:38.01 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:03.10 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-qbnblwcuthwqpcqg) |
| 17:17.50 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 17:17.51 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:25.22 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-gdwcmmoztcjxvmxb) |
| 18:20.31 | *** join/#asterisk-dev superscrat (asanders@nat/digium/x-txehbzgqvkrjixce) |
| 18:24.28 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 18:24.28 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:00.59 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 19:00.59 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:35.11 | *** join/#asterisk-dev DivideBy0 (~DivideBy0@unaffiliated/divideby0x0) |
| 20:28.24 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 20:28.25 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:34.03 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 20:34.03 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:39.03 | *** join/#asterisk-dev jayka (9edeee1e@gateway/web/freenode/ip.158.222.238.30) |
| 20:39.26 | jayka | <PROTECTED> |
| 20:39.31 | jayka | wanted to make sure I understand what's going on correctly prior to submitting it |
| 20:39.38 | jayka | can anyone advise? |
| 20:43.10 | *** join/#asterisk-dev superscrat (asanders@nat/digium/x-hkxyickjuewdfgyy) |
| 20:50.41 | wdoekes | jayka: if you're more specific, you may get answers. or you could start by filing a bug report with your observed behaviour, the expected behaviour and the culprit (r4132) and possibly a fix (if you can provide one) |
| 21:24.24 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 22:02.31 | *** join/#asterisk-dev superscrat (~asanders@173-21-89-217.client.mchsi.com) |
| 22:24.20 | putnopvut | rmudgett: superscrat just messaged me saying you guys had had a discussion about the system resolver implementation. |
| 22:24.46 | putnopvut | She said you had said that a taskprocessor might be too heavyweight of a solution for doing the asynchronous lookup. I'm curious what you had in mind instead. |
| 22:24.48 | rmudgett | putnopvut: some |
| 22:25.09 | superscrat | ah, hey there you are |
| 22:25.35 | rmudgett | A task processor only works on a queue of tasks. A threadpool would allow more parallelism |
| 22:26.57 | putnopvut | Is that a real problem for DNS results, though? PJSIP immediately takes the results of the DNS lookup and throws them into its threadpool, for instance. |
| 22:27.47 | file | the system API functions block while getting the results |
| 22:27.48 | putnopvut | I mean, I guess if you're constantly hammering a remote DNS server, then parallelizing the load could result in some good-ness. |
| 22:28.20 | file | so - you either block the async function, or dispatch |
| 22:28.46 | putnopvut | Yeah, dispatching is definitely going to happen. |
| 22:29.06 | file | ah you mean serializing it in a single handler thread? |
| 22:29.11 | putnopvut | The difference is that I had suggested a taskprocessor, and I had misunderstood what superscrat told me to be that rmudgett was thinking that a taskprocessor was too heavyweight |
| 22:29.24 | rmudgett | Though the system DNS resolver shouldn't be a full blown all bells and whistles supported version. That's what the unbound resolver is for right? |
| 22:29.27 | putnopvut | As it turns out, what rmudgett is desribing using a threadpool instead of a taskprocessor. |
| 22:29.44 | putnopvut | rmudgett: most bells and whistles are outside of the resolver implementation. |
| 22:30.12 | putnopvut | The bells and whistles of libunbound are that it automatically separates answers in a DNS response for you, and it also does things like DNSSEC |
| 22:30.17 | superscrat | putnopvut, rmudgett, file, there are two issues at hand here |
| 22:30.18 | rmudgett | Another way would be to spin up a thread for each query |
| 22:30.26 | putnopvut | rmudgett: that's a bit ridick |
| 22:30.27 | superscrat | 1. the threadpool v taskprocessor approach |
| 22:30.41 | superscrat | 2. the robustness of the resolver itself |
| 22:31.02 | putnopvut | Let's start with 2. |
| 22:31.34 | superscrat | that works. |
| 22:31.42 | putnopvut | rmudgett is correct in that it doesn't need to do much of anything. Basically, it needs to get a DNS response, locate the RRs in the response, and add those as records to the query. |
| 22:32.01 | putnopvut | Any sort of record-specific processing is outside the realm of the resolver. |
| 22:32.21 | file | (which is great for plugging in different resolvers) |
| 22:33.50 | putnopvut | And as for 1, I'm of the opinion that a threadpool is overkill. Luckily the APIs for threadpool and taskprocessor are close enough that we can switch from one to the other if it turns out that parallelizing the queries is a good thing. |
| 22:34.11 | superscrat | right now, i have it set up to use the taskprocessor approach |
| 22:34.15 | file | it would help the PJSIP resolver, but it's certainly not required |
| 22:35.16 | superscrat | file, are you referencing the point about parallelization? |
| 22:35.22 | file | yes |
| 22:35.33 | file | I'm fine with a taskprocessor |
| 22:35.39 | file | kiss |
| 22:36.00 | rmudgett | The default system resolver should be basic. |
| 22:36.07 | superscrat | rmudgett, i agree with that |
| 22:36.14 | putnopvut | I'm reminded of mjordan's off-hand idea of having a "system" level threadpool that unrelated things can use when they want. |
| 22:36.15 | rmudgett | Use another resolver for more features |
| 22:36.25 | putnopvut | rmudgett: what features in particular are you thinking of? |
| 22:36.40 | superscrat | i think it should do the bare minimum required. and putnopvut, rmudgett and i were just discussing that point, too, earlier, the system-wide threadpool conversation |
| 22:36.44 | rmudgett | The basic resolver would just handle simple DNS queries |
| 22:37.01 | rmudgett | The more featured resolver would add SRV NAPTR etc |
| 22:37.10 | file | that's not a resolver thing |
| 22:37.14 | file | a resolver just passes back DNS records |
| 22:37.17 | putnopvut | See, here's the thing. The actual resolver has no idea what type of record is benig looked up. |
| 22:37.30 | file | putnopvut, well - it knows the type and class, it doesn't know what the contents are :D |
| 22:37.44 | putnopvut | Well it "knows" but it doesn't care. |
| 22:38.17 | putnopvut | Whether it's A, AAAA, SRV, NAPTR, etc. doesn't matter. It should do the exact same thing with all record types. |
| 22:38.37 | putnopvut | And what's nice is that we already have an API call in dns.c that will do a majority of the work for us. |
| 22:38.46 | superscrat | I was thinking that it is just going to be a passthrough to some extent |
| 22:38.54 | putnopvut | It will perform the DNS lookup, locate the individual RRs and call back with each individual one. |
| 22:39.59 | putnopvut | superscrat: yes, that is correct. I don't imagine that the actual resolver implementation is going to be very large at all. |
| 22:40.15 | *** join/#asterisk-dev chazzam (~chazz@donutokyo.info) |
| 22:40.37 | file | quite |
| 22:41.52 | superscrat | so, basically, a call is made to the resolver -> 'resolver, go resolve this query'. the resolver pushes a task to its taskprocessor to do the work for this request in a callback |
| 22:42.01 | putnopvut | Correct |
| 22:42.15 | superscrat | the callback does the bare minimum, searches the dns for the record, and calls back for each result that it finds, if any |
| 22:43.08 | superscrat | there is the final part of this, though, in that there is no sentinal value to tell the resolver, 'stop resolving!' |
| 22:43.12 | file | the resolver adds the records to the query and then calls a function to say it's finished, but yes |
| 22:43.36 | putnopvut | Almost. The task processor callback will search DNS, will be called back by the API in dns.c for each record found. Once all records are found, you will need to tell the DNS core, "Here are all the records I found" |
| 22:43.38 | superscrat | okay, so that final part i just stated was a bit off - |
| 22:43.45 | putnopvut | Right |
| 22:44.16 | superscrat | but, the thing that invoked this whole chain of activity has no way to know if the resolver is still working or if he is done |
| 22:44.55 | putnopvut | Correct. The dns.c API will tell you each record it finds, but it won't tell you that it has finished going through all the records in a DNS response. |
| 22:45.03 | putnopvut | Which is silly |
| 22:45.14 | file | yeah - when I took an approach on this I had to just not use it |
| 22:45.21 | putnopvut | Actually, you know what... |
| 22:45.24 | putnopvut | It's synchronous. |
| 22:45.24 | superscrat | so, putnopvut, is this where an extension of dns.h may be needed - so that there can be something to allow the caller to be notified when the process is done? |
| 22:45.40 | putnopvut | I just had a monkey-touch-the-monolith moment. |
| 22:45.47 | putnopvut | I don't think you'll need to modify dns.h |
| 22:46.14 | superscrat | good deal. i was just reviewing the notes you provided to verify that i covered all the big '?' marks that I had notated |
| 22:46.15 | file | there was another reason I didn't use it... I think because it wouldn't give me the record details completely... |
| 22:46.20 | putnopvut | Basically, you call ast_search_dns(). While it's executing, it will call into a function you provide for each record it finds. When ast_search_dns() returns, you know it's done with all records it found. |
| 22:46.43 | superscrat | okay |
| 22:46.45 | putnopvut | file: any idea what in particular was missing? |
| 22:46.53 | file | ttl maybe? |
| 22:47.11 | file | I dunno |
| 22:47.20 | putnopvut | Hrm |
| 22:47.31 | file | I'm sure if it's a problem superscrat will run into it |
| 22:47.34 | putnopvut | Well, do we actually do anything useful with the TTL right now? |
| 22:47.48 | file | we pass it back, and it gets used in the recurring API |
| 22:47.48 | putnopvut | recurring queries? |
| 22:47.53 | putnopvut | right |
| 22:48.03 | superscrat | so, file, you are saying that if i do a basic dns search using our api, there is a type of record that will not be returned? |
| 22:48.11 | file | no |
| 22:49.36 | superscrat | would you mind, file, repeating the context, because I must have missed something up the chain in this conversation |
| 22:50.51 | file | the records have additional data before the record-specific data, if I remember correctly that information is not passed to the callback |
| 22:50.58 | file | only the record-specific data is |
| 22:51.20 | file | so you don't get the name, type, class, or ttl |
| 22:51.37 | putnopvut | Technically, the full DNS answer is passed back in the callback, so you *could* extract it |
| 22:51.52 | file | yeah, it's a little bit of extra work but shouldddd be doable |
| 22:51.55 | file | it'd be nice |
| 22:52.02 | superscrat | ahhh |
| 22:52.03 | superscrat | okay |
| 22:52.13 | superscrat | extend the existing api to allow for the inclusion of that extra data |
| 22:52.35 | file | well - you can extend it, or you can do as putnopvut mentioned and find it in the full DNS answer |
| 22:53.32 | superscrat | so, parse the full dns answer to obtain the meta data for the record? |
| 22:54.02 | superscrat | that seems a bit weighty, maybe, for a simple resolver, and maybe like something that all the resolvers would want to take advantage of |
| 22:54.08 | putnopvut | That's an option. Some of that may already be done in dns.c and just not passed to its callback. |
| 22:54.39 | superscrat | in other words, can you guys think of a case where that data would not be nice to have? |
| 22:54.40 | putnopvut | For the type and class, you could just use the same type and class that was passed in the initial query. The TTL on the other hand can't be guessed. |
| 22:57.06 | superscrat | so, my question is this, if this is not presently in dns.c, wouldn't it make sense for it to be added? |
| 22:58.42 | superscrat | putnopvut, file, rmudgett, can we continue this in the morning? I have to go tend to a small child. Thanks for the help! |
| 22:59.08 | file | sure |
| 22:59.22 | putnopvut | So here's the thing: I'm not sure whether the TTL/class/type are already being extracted in dns.c and just not passed to callers of ast_search_dns() or if dns.c is just skipping over it on purpose saying "here's the whole answer, find it if you want." In either case, though, I suspect that you'll probably have to add some sort of function call to extract the type/class/ttl from the DNS response. Whether it's internal to dn |
| 22:59.22 | putnopvut | s.c or an API call is something we can discuss further when we get to that point. |
| 22:59.29 | putnopvut | And I'm fine with stopping for tonight :) |
| 22:59.32 | file | dns.c extracts it |
| 22:59.33 | putnopvut | It's Jeopardy time. |
| 22:59.35 | putnopvut | okay |
| 22:59.49 | file | it just skips over it and passes back only the record specific data in the callback |
| 22:59.59 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-adgjdoxhgftlkfsu) |
| 22:59.59 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 23:08.00 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-byrnbssmcehvioyx) |
| 23:10.24 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-byrnbssmcehvioyx) |
| 23:17.00 | file | thunderrrrrr |
| 23:28.43 | mjordan | file: Lion-O? |
| 23:56.44 | file | mjordan, 490 may as well get abandoned |
| 23:57.10 | mjordan | yeah |
| 23:57.33 | mjordan | I just officially smacked it though, so it's probably best to leave it for a bit in case he responds |
| 23:58.11 | file | I'm fine with that |