| 00:22.58 | *** part/#asterisk-dev kharwell (~kharwell@24.96.171.3) |
| 00:42.06 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-hyjyijyusrvtickr) |
| 00:42.06 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 02:47.35 | *** join/#asterisk-dev snuff-work (~blatus@203.87.61.22) |
| 02:47.35 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 03:35.16 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 04:10.26 | *** join/#asterisk-dev jagruti_ (~root@182.70.116.47) |
| 04:10.32 | *** part/#asterisk-dev jagruti_ (~root@182.70.116.47) |
| 05:23.53 | *** part/#asterisk-dev mjordan (mjordan@nat/digium/x-hyjyijyusrvtickr) |
| 05:44.34 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 05:44.34 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 06:23.52 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 06:23.52 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:14.06 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 07:14.06 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:01.48 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:c1f1:c0fc:a951:7c73) |
| 08:07.19 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:07.20 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:15.04 | oej | Good morning folks |
| 10:03.43 | *** join/#asterisk-dev danjenkins (~anonymous@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 11:02.43 | jsmith | Morning oej |
| 11:02.45 | jsmith | Greetings all |
| 13:14.35 | *** join/#asterisk-dev Synthase_ (uid63346@gateway/web/irccloud.com/x-nosmnqdbsflncpoy) |
| 13:21.08 | *** join/#asterisk-dev Marquis42 (~mrbmw@d14-69-246-193.try.wideopenwest.com) |
| 13:52.10 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 13:56.20 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 13:56.20 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:06.17 | *** join/#asterisk-dev newtonr (~RustyNewt@173-21-90-203.client.mchsi.com) |
| 14:06.17 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:19.26 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 14:19.26 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:23.39 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-cqlfwqiubnnvyrfw) |
| 14:23.39 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:57.55 | *** join/#asterisk-dev kharwell (~kharwell@24.96.171.3) |
| 15:10.07 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 15:13.41 | stefan27 | Still getting a lot of dtls-crashes on ast 13.1.0 using chan_sip, chrome sipml5, wss and openssl-1.0.1-41, each crash is different (2 crashes at http://pastebin.com/HiNSyLMK ). By inserting extra error logs in res_rtp_asterisk.c it looks like crashes always occur on dtls->ssl sessions where asterisk has role sERVER (SSL_set_accept_state(dtls->ssl) has been called.) |
| 15:14.09 | stefan27 | i created a jira for it https://issues.asterisk.org/jira/browse/ASTERISK-24832 including 2 core dumps but its hard to provide enough information... i would really like to log all calls to libssl somehow |
| 15:21.21 | oej | Thank you for fighting hard to find that issue, Stefan27 |
| 15:22.44 | stefan27 | I don't have enough software development knowledge really, but im persistent at least |
| 15:27.52 | newtonr | stefan27, You are providing much more than many issue reporters do. Thank you. :) |
| 15:32.26 | stefan27 | well this is the worst kind of bug - Doesnt always happen, and never sure if Webrtc-client, libssl or asterisk is behaving wrong |
| 15:32.56 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 15:33.20 | stefan27 | and im not sure if im authorized to upload the udp-wireshark-trace containing the handshake messages |
| 15:35.40 | mjordan | the joy of webrtc |
| 15:36.29 | superscrat | I am having an issue with a call not coming off hold. At first, I thought it was due to the omission of the a=sendrecv from the reinvite, but that proved to be an incorrect hypothesis. |
| 15:37.47 | superscrat | I am wondering if anyone in here has a few moments to look at the review for my test to see if you can eyeball the SDPs to help me diagnose what is going on |
| 15:37.55 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:37.55 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:38.12 | superscrat | https://reviewboard.asterisk.org/r/4442/ |
| 15:39.32 | file | let's see |
| 15:40.47 | superscrat | thank you =D |
| 15:41.07 | mjordan | SDP origin version? |
| 15:42.06 | file | looks like it |
| 15:42.16 | superscrat | explain, please |
| 15:44.07 | mjordan | superscat: it's super happy fun times in SDP land. https://www.ietf.org/rfc/rfc2327.txt - see "Origin" in Section 6 |
| 15:44.32 | file | I'll throw in http://www.ietf.org/rfc/rfc3264.txt Section 8 |
| 15:45.11 | mjordan | essentially, when you modify a session, you have to increase the version of the session you are modifying, otherwise we have to assume that it is a 'stale' (or repeated) offer for an existing session |
| 15:45.25 | file | which becomes a no-op |
| 15:45.46 | mjordan | so, in your INVITE request that sends an SDP that takes the call "off hold", the o= line should have the <version> number bumped by at least one |
| 15:46.38 | mjordan | and this is why we have rants about SDP on facebook |
| 15:46.51 | superscrat | I am having nightmares about it |
| 15:46.55 | superscrat | presently |
| 15:47.13 | mjordan | and this is "vanilla" SDPs! |
| 15:47.15 | mjordan | :-)) |
| 15:47.33 | file | I'd show you WebRTC SDP except that might send you over the edge |
| 15:47.39 | superscrat | Awesome! So, the nightmares will become even more interesting as time progresses! |
| 15:48.05 | mjordan | Tim's rant on it is glorious: https://webrtchacks.com/tim-rant/ |
| 15:51.35 | oej | He's good at ranting. |
| 15:51.39 | oej | And coding too. |
| 15:52.53 | superscrat | Nice. "Weâve been burdened with this floppy, ill specified, un paresable mess for the sake of some fictional devices that may in the future be built to function both as traditional SIP endpoint and also as native WebRTC citizens, with no gateway between them and the outside world." |
| 16:19.35 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 16:30.17 | mjordan | file: for the proposed DNS API, are you envisioning having it act as a facade over a particular library? Or having a separate file/module register to the core? |
| 16:30.36 | file | register |
| 16:30.59 | mjordan | the only problem I see with that is we'll have yet another loadable module that can't be unloaded |
| 16:31.00 | file | the end result will be the same but it keeps the two boundaries more separate |
| 16:31.32 | file | we can either have it as a loadable module, or still an internal file that just registers with the core still |
| 16:31.45 | mjordan | I kind of lack the latter |
| 16:31.54 | mjordan | I doubt we'll be looking to hotswap DNS libraries |
| 16:33.02 | file | I'm not so much looking at hot swapping - just swapping if something nicer comes along |
| 16:37.21 | mjordan | true |
| 16:37.55 | mjordan | You may want to think about adding a unit test enabled API only that allows us to add a test resolver |
| 16:38.06 | mjordan | that way you can test out the threading mechanisms/callbacks from unit tests |
| 16:38.28 | file | nods |
| 16:52.24 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 16:52.24 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 16:56.19 | coreyfarrell | if DNS resolvers are done as modules then ast_module_shutdown_ref would probably be appropriate.. once loaded it runs until shutdown. |
| 16:58.50 | file | coreyfarrell, ack |
| 16:58.53 | mjordan | coreyfarrell: True |
| 16:59.06 | coreyfarrell | if there will be multiple options for DNS resolver libraries then modules would probably be slightly better than core (so we avoid loading/initing multiple libs). |
| 16:59.19 | mjordan | I'm not sure there really will be, when all is said and done |
| 16:59.31 | mjordan | theoretically yes, but you'd still have to implement the facade that plus a library into Asterisk |
| 16:59.44 | mjordan | and I'm not sure how much people will want to do that. It's a good practice to have this abstracted out |
| 16:59.52 | mjordan | as that way we aren't 'stuck' if something better does come along |
| 17:00.06 | mjordan | shrugs |
| 17:00.26 | mjordan | at the same time, I'm not against a loadable module so long as we don't have a lot of crashes on shutdown, leaks, and a massive amount of ref counting |
| 17:00.34 | mjordan | ref count on every DNS lookup => bad |
| 17:01.14 | file | that allocates something, so it's not a ref count... but it is something :P |
| 17:05.32 | file | ast_module_shutdown_ref should work nicely for it |
| 17:06.12 | file | won't require a ref bump on usage and manipulation |
| 17:07.03 | coreyfarrell | the only concern I have with using modules is startup order. is normal load or preload early enough for stuff in the core that might use this new DNS API |
| 17:07.28 | file | should be |
| 17:08.09 | stefan27 | res_rtp_asterisk.c function dtls_perform_handshake checks if (SSL_is_init_finished(dtls->ssl)) { } BEFORE doing SSL_do_handshake(dtls->ssl); That condition has evaluated to true for some of my calls (say 1 out of 100), and when that has happend nothing crashed. I'm just wondering what would happen if (SSL_is_init_finished(dtls->ssl)) becomes true after condition is checked but before |
| 17:08.09 | stefan27 | SSL_do_handshake(dtls->ssl) is executed. |
| 17:12.53 | stefan27 | trying to make sense out of http://stackoverflow.com/questions/22753221/openssl-read-write-handshake-data-with-memory-bio |
| 17:18.06 | stefan27 | at the same time im trying to make sense out of the russian guy's patch https://issues.asterisk.org/jira/browse/ASTERISK-24651 |
| 17:18.15 | stefan27 | Any of you been working on that JIRA? |
| 17:23.45 | stefan27 | looks like he tried to mutex-protect everything... |
| 17:37.34 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 17:37.34 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:59.10 | mjordan | stefan27: to be frank, the root cause of whatever issue he was trying to patch is so murky there's no hope of evaluating whether or not the patch is a correct solution. |
| 18:00.16 | mjordan | If it helps people, that's fine. But I don't see it going in as-is, and it looks like it would need substantial work. I commented to that effect, and his reply was "well, but mine is better and fails less". Which doesn't mean he actually solved anything, but merely hid the problem. |
| 18:00.33 | mjordan | "I admit that patch of possible solutions "dirty", but my time is quite expensive" => my time is more valuable than yours |
| 18:00.56 | mjordan | which generally means I'm not going to bother trying to get that patch in. If you can't help me, I'm not going to burn a week trying to help you. |
| 18:08.00 | stefan27 | yeah thats understandable, i hope i can find the root problem for my usercase |
| 18:09.50 | mjordan | I would love to know what is actually causing the issue :-) |
| 18:10.10 | mjordan | I'd say you may want to check the OpenSSL issues, but I know that tracker is notoriously difficult to find information in |
| 18:16.57 | stefan27 | I did try that, I found one issue with similar footprints with no progress from aug 2014 http://rt.openssl.org/Ticket/Display.html?id=3487 and another issue resulting in a patch checking return value of something i forgot, which had no effect on frequency of crash |
| 18:17.28 | stefan27 | it's hard hard search there indeed! |
| 18:18.34 | stefan27 | What might be special about my environment is that I sometimes get 10-30 stun messages within same milliseconds to the ports that are doing the dtls handshake |
| 18:19.08 | stefan27 | I don't know why, i tried both pjprojects 2.2 and 2.3 and sometimes chrome sends all the stun requests |
| 18:22.13 | stefan27 | There's so many unknowns that could be responsible... The fact that the machine is host virtual, the fact that Fedora's SPRM alters some of the source code of openssl-1.0.1e so that it's not identical to one you'd get from building from source urself... |
| 18:22.28 | stefan27 | SRPM* |
| 18:26.50 | stefan27 | but it's all far-fetched, i hope error is somewhere between asterisk and openssl |
| 18:27.16 | stefan27 | rather than that my environent is unique |
| 18:29.51 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-toiwgssieccrwuod) |
| 18:34.05 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 18:34.05 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:44.24 | stefan27 | The last crash http://pastebin.com/TDcd3BYc happend when asterisk processed the first Client Hello and that msg was preceeded by STUN-response spam as shown by wireshark screnshot http://postimg.org/image/btwyy83gt/ (because asterisk spammed asterisk stun-requests). I still don't see why the overflowing of a udp-buffer would cause that kind of crash |
| 18:54.54 | stefan27 | Oh, wait, that core-dump does prove a concurrency issue -- thread 5 which leaves asterisk code at dtls_perform_handshake is performing ssl3_clear(ssl) on the same ssl struct as was sent to ssl_read by __rtp_recvfrom. |
| 18:57.13 | stefan27 | the timing of dtls_perform_handshake called from on_ice_complete callback seems to be the root of most crashes |
| 18:59.55 | stefan27 | gonna add that to the jira |
| 19:00.24 | mjordan | thanks, that's helpful |
| 19:10.58 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 19:10.58 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:21.40 | tm1000 | mjordan: Thought, would you accept a patch to voicemail where I defined exit codes. Example right now if someone calls and leaves a 1 second voicemail but the min length setting is 3 seconds voicemail.c exits with a FAIL. which is totally useless if I need to be able to say âHey guy calling in please speak longer" |
| 19:22.04 | tm1000 | I was thinking of setting some variable I could pickup, like FAILCODE which would == to whatever the problem is |
| 19:22.37 | tm1000 | for now I just have Allison saying âThere was an errorâ because, well there WAS an error, but I have no idea what the error was |
| 19:24.57 | mjordan | tm1000: sure |
| 19:26.14 | mjordan | I'd define which ones you're thinking of first - but so long as you're mostly just updating existing calls of pbx_builtin_setvar_helper, that's not terribly hard or a bad idea |
| 19:26.35 | tm1000 | mjordan: thats exactly it |
| 19:26.41 | tm1000 | a very minimal change |
| 19:26.52 | tm1000 | Iâll come up with someone later today |
| 19:26.57 | mjordan | sounds like a good idea to me :-) |
| 19:26.59 | tm1000 | but I ran into it with minlength |
| 19:27.12 | tm1000 | basically I wanted to say something better than âthere was an error" |
| 19:28.02 | tm1000 | I jsut wasnt sure where we are at with voicemail these days as Iâve heard rumors of an ARI voicemailâ¦.. mjordan ;-) |
| 19:28.13 | mjordan | there is an ARI voicemail! |
| 19:28.16 | tm1000 | as in someone started writing one.. etc |
| 19:28.18 | tm1000 | ah |
| 19:28.19 | tm1000 | ! |
| 19:28.23 | mjordan | it does exist :-) |
| 19:28.26 | mjordan | github.com/asterisk |
| 19:28.31 | tm1000 | mjordan: hmm Tony basically said he wants us to move to that |
| 19:28.37 | mjordan | it's even broken up into individual projects |
| 19:28.41 | mjordan | even has an admin tool! |
| 19:28.47 | mjordan | OTOH, app_voicemail isn't going anywhere |
| 19:28.53 | tm1000 | whoo you did it in node!!! <3 |
| 19:28.55 | mjordan | and if someone wants to improve on it, that's cool. Open Source! |
| 19:29.00 | mjordan | tm1000: yup |
| 19:29.18 | file | we do stuff and things |
| 19:31.57 | tm1000 | file: I knew about the stuff, but you do THINGS now! |
| 19:31.58 | tm1000 | wow |
| 19:32.01 | tm1000 | progressive |
| 19:32.03 | tm1000 | :-) |
| 19:37.32 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 19:37.32 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:52.47 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 20:52.47 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 21:06.00 | mjordan | file: how do you expect data set via ast_dns_resolver_set_data to be free'd? |
| 21:06.56 | file | the resolver implementation has to free it upon invocation of callback or after it is no longer valid |
| 21:06.58 | oej | Never. It will be kept forever and ever. Doomed. |
| 21:07.15 | oej | There's a TTL in every response :-) |
| 21:07.24 | oej | good night! |
| 21:09.23 | mjordan | k |
| 21:09.52 | file | ie: the lifetime and how it is freed is up to that implementation |
| 21:10.51 | mjordan | I'd go so far as to say that if data is set on there by a resolver, that failing to remove it when the query object is destroyed should trigger an assert |
| 21:11.16 | file | yup |
| 21:11.44 | mjordan | I guess I'm trying to figure out how that mechanism will work with the DNS API |
| 21:11.48 | mjordan | i.e. |
| 21:12.03 | mjordan | I call ast_dns_resolve_async |
| 21:12.14 | mjordan | the core finds the registered resolver |
| 21:12.20 | mjordan | and calls the resolve callback on it |
| 21:12.34 | mjordan | that - I suspect - would be the first point in time the resolver has an option of placing data on the ast_dns_query |
| 21:12.39 | file | it is |
| 21:13.03 | mjordan | when it is finished, it returns - having modified the query structure with results |
| 21:13.10 | mjordan | how then does it know to clear its own data? |
| 21:13.13 | file | well, _async doesn't |
| 21:13.34 | file | it returns immediately without results and then the callback is invoked |
| 21:14.09 | mjordan | well, that depends on the threading model. My call to ast_dns_resolve_async will return immediately; however, the resolver may still be called synchronously from a threadpool |
| 21:14.20 | file | the resolver implementation has to signal to the core that the query has been completed, before doing so it can remove the data |
| 21:14.24 | mjordan | unless we aren't providing the threading mechanism but instead leveraging the libraries |
| 21:15.47 | mjordan | well, let me shift slightly then: were you think of having us manage the asynchronous call, or having a library do it and having us just manage the tying of the callbacks together? |
| 21:16.02 | file | library originally |
| 21:16.17 | file | because how else could you cancel a query? |
| 21:16.39 | mjordan | carefully ;-) |
| 21:16.49 | mjordan | I'd prefer that, really |
| 21:16.52 | file | resolvers don't provide a mechanism to cancel a synchronous resolution, unless you can somehow do something to make them fail |
| 21:16.57 | mjordan | right |
| 21:23.03 | file | the only potential thing is depending on how the resolver invokes callbacks it may require a threadpool |
| 21:25.07 | file | also whether the callback is long lived or not... |
| 21:26.34 | mjordan | I'm hopeful that we don't have to do that. |
| 21:26.44 | file | same |
| 21:26.46 | mjordan | I'll defer that to what happens when theory hits implementation |
| 21:33.56 | mjordan | unit testing this will be enjoyable :-P |
| 21:36.06 | Marquis42 | I'm not sure that word means what you think it means, mjordan. ;) |
| 21:39.04 | mjordan | as file can attest to, my definition of enjoyable is skewed |
| 21:39.57 | file | I'm not one to talk |
| 21:40.07 | file | both of our definitions of enjoyable are skewed |
| 21:40.18 | Marquis42 | Oh don't worry, I'm officially the pot calling the kettle black. :D |
| 21:40.44 | mjordan | "A weekend of writing mocks??? WHERE DO I SIGN UP" |
| 21:41.43 | file | it's relaxing! |
| 21:53.55 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 22:22.09 | *** join/#asterisk-dev pchero_travel (~pchero@0x555140b5.adsl.cybercity.dk) |
| 23:13.19 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-fnkxlkrxohabqvwo) |
| 23:13.19 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 23:16.37 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 23:16.38 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 23:45.45 | *** part/#asterisk-dev kharwell (~kharwell@24.96.171.3) |