| 00:14.12 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-jvsgkfjhasnfiqma) |
| 00:51.01 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 01:28.53 | *** join/#asterisk-dev dwayne (~dwayne@c-71-207-208-112.hsd1.al.comcast.net) |
| 01:52.29 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 02:08.57 | *** join/#asterisk-dev serafie1 (~erin@24.96.64.240) |
| 13:44.17 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 13:44.17 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk |
| 14:09.33 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 14:09.34 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 14:12.37 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-qdyzvsziajhjmyjb) |
| 14:29.23 | *** join/#asterisk-dev vlad_starkov (~vlad_star@87.117.139.75) |
| 15:05.00 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 15:10.47 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:10.47 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:06.05 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 16:06.46 | *** join/#asterisk-dev venables (~venablc@31.6.74.138) |
| 16:09.58 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 16:11.05 | *** join/#asterisk-dev italoros_ (~italoross@187.60.66.11) |
| 16:14.48 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 16:17.37 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 16:19.58 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 16:22.39 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 16:27.22 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 16:30.04 | *** join/#asterisk-dev italoros_ (~italoross@187.60.66.11) |
| 16:33.25 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 16:34.20 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 16:57.37 | *** join/#asterisk-dev vlad_starkov (~vlad_star@194.186.53.204) |
| 17:10.17 | *** join/#asterisk-dev vlad_starkov (~vlad_star@194.186.53.204) |
| 17:13.04 | mjordan | leedm777: is https://reviewboard.asterisk.org/r/2693/ ready to go? |
| 17:15.02 | leedm777 | mjordan: no; I need to reconcile it against the sounds media indexer. or buckets. |
| 17:15.32 | mjordan | hm. Do we need to hold anything off for it? Obviously the first release, but is branching going to be problematic? |
| 17:16.08 | leedm777 | mjordan: there won't be any problems with branching. |
| 17:16.13 | mjordan | k |
| 17:16.46 | leedm777 | I've had to 'rebase' enough branches in Subversion the past few months, I'm fairly comfortable with it. |
| 17:16.57 | mjordan | heh |
| 17:17.07 | mjordan | there's a 3 letter word for that |
| 17:17.14 | file | fml? |
| 17:17.20 | mjordan | yes! |
| 17:17.53 | file | leedm777, putnopvut commented on the bucket review about getting away with not having uriparser and "simply" getting only the scheme... thoughts? |
| 17:22.43 | leedm777 | file: I haven't dug back into that review. Are you still trying to parse out names from the URI? |
| 17:23.14 | file | WELL it needs to parse to get the scheme, and I parse out the name as a convenience |
| 17:27.29 | *** join/#asterisk-dev datachomper (~datachomp@nat/digium/x-woxnqglleovobwho) |
| 17:30.23 | leedm777 | file: I'm undecided. I don't want to add the dependency, but I also don't want to do our own URI parsing. I just can't figure out which I don't want more. |
| 17:31.21 | leedm777 | If we can avoid the parsing, then it would be better to drop the dependency. |
| 17:31.21 | leedm777 | Then again, anything that uses the bucket API will need to make sense of a URI. |
| 17:31.27 | leedm777 | So it would pretty much need a URI parser anyways. |
| 17:31.34 | file | to be sane, yes |
| 17:31.49 | leedm777 | I am pro-sanity |
| 17:32.20 | leedm777 | So, yeah, if the dependency is already there, then great. |
| 17:32.40 | file | I sorta have a gut feeling that it may be useful/get used elsewhere too |
| 17:32.50 | leedm777 | I'm sure it will |
| 17:32.56 | leedm777 | LIke maybe in our HTTP server :-) |
| 17:33.05 | file | CRAZY |
| 17:33.13 | mjordan | nah |
| 17:33.18 | mjordan | we should just keep rolling our own. |
| 17:33.25 | mjordan | I WANT SQUARE WHEELS |
| 17:33.35 | Qwell | square ovals! |
| 17:33.48 | Qwell | oh, Leif isn't in here, nevermin |
| 17:33.48 | Qwell | dd |
| 17:39.14 | leedm777 | file: Okay; I'm good with adding the dependency. I'll put a comment on the review. |
| 17:39.23 | file | ack |
| 17:39.26 | mjordan | wow. I really blew up the sorcery unit tests. |
| 17:39.45 | file | mjordan, *gasp* |
| 17:40.13 | mjordan | at least we know that it doesn't like it when you don't provide documentation |
| 17:51.11 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 17:51.11 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 18:24.26 | *** join/#asterisk-dev coolacid (~CoolAcid@unaffiliated/coolacid) |
| 18:25.29 | coolacid | Simple Query: There is a patch here: https://github.com/jcs/payphone -- If it was submitted to dev would it be something possibly included? |
| 18:25.57 | coolacid | The patch adds support to detect ACTS control codes and adds a $ response to getdigits |
| 18:32.17 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-gpotkdsoczcenwsw) |
| 18:32.20 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 18:32.20 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 18:32.27 | jrose_atDigium | https://reviewboard.asterisk.org/r/2794/ - SIP holding bugs |
| 18:33.13 | file | coolacid, 'tis possible |
| 18:34.36 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 18:36.02 | coolacid | Thanks file - I'll see the the coder will submit it. Just didn't want to waste everyones time ;) |
| 18:37.47 | mjordan | coolacid: that's pretty cool |
| 18:38.27 | coolacid | Yeah, I was happy to find it - working on a payphone for the house, and wanted it to "work" as it would have years ago.. |
| 18:38.38 | coolacid | Raised an issue with the coder: https://github.com/jcs/payphone/issues/1 |
| 18:39.02 | coolacid | s/issue/"issue" ;) |
| 18:48.54 | mjordan | file: can you explain the comment on r2794 "I don't think this is really beneficial." |
| 18:49.19 | file | having a function that simply calls another function and does nothing else |
| 18:49.53 | mjordan | Ah, pause/resume? |
| 18:50.02 | file | aye |
| 18:50.11 | mjordan | The start and stop are virtual table callbacks; I thought your comment applied to them |
| 18:50.37 | file | they aren't |
| 18:50.42 | file | (in bridge_native_rtp) |
| 18:50.48 | mjordan | huh |
| 18:50.54 | mjordan | welp. Fair enough then :-) |
| 19:06.49 | jrose_atDigium | mjordan: I had actually thought the same thing for a time, which is why I went with that approach to start with. |
| 19:07.01 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 19:07.02 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 19:07.03 | jrose_atDigium | But yeah, all fixed and committed now. |
| 19:07.13 | jrose_atDigium | Now to fix the test! |
| 19:08.23 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 19:10.18 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 19:17.42 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 19:22.04 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 19:22.05 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 19:24.20 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 19:41.18 | coreyf1513 | i'm working on a bunch of memory cleanup patches, is it annoying to you guys if I post a separate jira ticket for each? so far I have about half a dozen, mostly very simple fixes |
| 19:52.10 | mjordan | coreyf1513: up to you |
| 19:52.10 | mjordan | if you want to throw them all up on one that's fine |
| 20:29.14 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.29) |
| 20:38.00 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.24) |
| 20:43.06 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 20:43.06 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 20:43.15 | *** join/#asterisk-dev datachomper (~datachomp@nat/digium/x-hgobwyuvuggwycha) |
| 20:43.32 | tm1000 | file: didnt even notice your comments on review board... |
| 20:45.32 | file | tm1000, ack |
| 20:46.04 | file | mjordan, documentation + bucket = *cry* |
| 20:46.24 | mjordan | file: heh |
| 20:46.34 | mjordan | at least it's working! |
| 20:46.46 | *** part/#asterisk-dev coolacid (~CoolAcid@unaffiliated/coolacid) |
| 20:46.47 | file | as in making it so my asterisk doesn't start, yes |
| 20:48.30 | mjordan | well, you should document your options then |
| 20:50.24 | *** join/#asterisk-dev datachomper (~datachomp@nat/digium/x-dhrppguzyqnadusb) |
| 20:51.39 | WIMPy | Guy, I still try to figure out why creating sip channels takes a huge amount of time. |
| 20:51.53 | *** join/#asterisk-dev datachomper (~datachomp@nat/digium/x-bcnfgzicalevihvs) |
| 20:52.58 | WIMPy | After Dial is calld I get a delay of between 380 and 460 ms between receiving the newchannel event and the varset sipcallid. |
| 20:53.56 | WIMPy | For the 1st dialled sip channel that is. If I dial another sip channel it's about 45-50ms extra. |
| 20:55.10 | WIMPy | (should be plural up there, off course) |
| 20:55.39 | WIMPy | What happens at that stage? What can I look in to to find out what's taking the time? |
| 20:56.39 | WIMPy | It looks like it's eating 100%cpu for that time. |
| 20:58.35 | leedm777 | I have a… plan… of sorts… for optional api. |
| 20:59.11 | leedm777 | Instead of using weak references, it can use dlsym() to lookup the optional implementation. |
| 20:59.13 | WIMPy | You have funny characters at the end of some words. |
| 20:59.32 | leedm777 | WIMPy: http://www.fileformat.info/info/unicode/char/2026/index.htm |
| 21:00.10 | leedm777 | That's Adium's autocorrect for you |
| 21:01.03 | WIMPy | Autocorrect for the word "a"? |
| 21:01.07 | leedm777 | so, the advantage of dlsym() is that we can re-run it whenever we dlopen() or dlclose() a module, updating any optional api's that have been loaded/unloaded. |
| 21:01.26 | leedm777 | autocorrecting for '...' |
| 21:01.27 | Qwell | leedm777: proceed! |
| 21:01.47 | WIMPy | aye |
| 21:02.02 | mjordan | WIMPy: A lot of things happen at that stage, so the answer is complicated. |
| 21:02.12 | leedm777 | It also gets us away from complier magic for optional api. now we can rely just on library magic. |
| 21:02.16 | Qwell | leedm777: be careful of macros though |
| 21:02.40 | Qwell | leedm777: like, #define ast_foo __ast_foo(__LINE, ...), and such |
| 21:02.41 | coreyf1513 | I wish nonoptreq held a reference to the modules that are required |
| 21:02.48 | mjordan | WIMPy: For one thing, the publishing of AMI events is now occurring through another message bus. That means that it isn't a direct publish from the thread executing the channel creation. |
| 21:03.25 | mjordan | at the end of the day, you'd have to profile to determine where the issue lies |
| 21:03.30 | WIMPy | Are the timestamps correct then? |
| 21:03.44 | mjordan | the timestamps of what? |
| 21:03.49 | mjordan | in the log file? Or in the AMI event? |
| 21:04.01 | WIMPy | In the AMI events. |
| 21:04.18 | mjordan | The timestamp should be when the AMI event is created from the Stasis message |
| 21:04.18 | leedm777 | Qwell: I think it will work out, since dlsym() would be looking up the same symbol resolved by the weak reference. |
| 21:04.32 | Qwell | leedm777: point |
| 21:04.32 | mjordan | but that is not when the Stasis message representing the change in the channel state is processed |
| 21:04.44 | WIMPy | Or could they be delayed somewhere? So that the issue might be at another stage? |
| 21:04.57 | mjordan | I doubt that they're "delayed", per se |
| 21:05.09 | mjordan | Stasis uses a thread pool to deliver the messages to its consumers, of which AMI is one |
| 21:05.32 | mjordan | One possibility is that it is spinning up additional threads to deliver the messages, as all of the threads in its thread pool may be busy |
| 21:06.07 | mjordan | you can actually increase the number of threads in the initial pool in stasis.conf |
| 21:06.17 | mjordan | but it's all very highly dependent on the machine you're running on |
| 21:06.18 | WIMPy | One interesting thing is that the delay only occours when the source channel is sip or iax, when it's lcr, there's no delay. |
| 21:06.37 | mjordan | I don't know anything about LCR, so that's pretty much immaterial |
| 21:07.06 | WIMPy | But at least you know that the source channel type makes a change for whatever reason. |
| 21:07.44 | mjordan | not really |
| 21:07.57 | mjordan | That's one channel driver that is produced by some other party |
| 21:08.04 | mjordan | There's about 10 million variables in there |
| 21:08.30 | WIMPy | Yes, but why does the source channel make a difference when creating outgoing channels? |
| 21:09.14 | *** join/#asterisk-dev datachomper (~datachomp@nat/digium/x-ycdmwjtrosfkmwxt) |
| 21:09.18 | WIMPy | Or how? |
| 21:13.17 | mjordan | From the perspective of the Asterisk core, it shouldn't. |
| 21:13.18 | WIMPy | Hmm. Maybe this is a hint: If I try fast, the 1st channel is also down to like 45ms. So there must be some kind of caching going on. |
| 21:13.42 | mjordan | But again: chan_lcr is a big ol' black hole as far as I'm concerned. It isn't valid for any comparisons that I would look at. |
| 21:14.16 | WIMPy | Well, that's the one that doesn;t create the issue, so that's fine. |
| 21:15.09 | WIMPy | cache, cache ... |
| 21:15.26 | WIMPy | looks in to his neural cahche... |
| 21:15.54 | WIMPy | That must be that dialplan lookup I saw the other time. |
| 21:21.55 | WIMPy | Yes, I'm pretty confident that's it. |
| 21:28.36 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.24) |
| 21:30.17 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 21:30.18 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 21:36.19 | WIMPy | When I look at the full debug, I see that the varset events for the dialled sip channels contain Context: dial-master, Exten:, Priority 1. That's exactely what it tries to find. |
| 21:36.36 | WIMPy | "",1 |
| 21:38.45 | file | mjordan, YOU! |
| 21:38.50 | mjordan | what did I do? |
| 21:39.22 | file | you didn't change ast_sorcery_object_field_register to take into account no_doc |
| 21:39.24 | mjordan | WIMPy: That sounds correct. All AMI events now contain the same set of 'standard' information for a channel, which includes their dialplan location |
| 21:39.26 | file | (ie: it passes no argument for that) |
| 21:39.33 | mjordan | there's another one |
| 21:39.39 | mjordan | ast_sorcery_object_field_register_nodoc |
| 21:39.40 | file | or to be more pedantic it passes argc as no_doc |
| 21:39.45 | mjordan | o |
| 21:39.46 | mjordan | whoops |
| 21:39.47 | mjordan | nm |
| 21:39.49 | mjordan | me |
| 21:39.52 | mjordan | yes. Sorry. |
| 21:39.58 | WIMPy | But that's the dialled channel. |
| 21:40.01 | file | I was wondering why my timeval code was going into weird memory |
| 21:40.35 | mjordan | WIMPy: I'd have to see what you've got there to try and understand that. |
| 21:40.39 | mjordan | file: mea culpa |
| 21:40.51 | mjordan | file: otoh, I did just fix a channel ref leak in ast_pbx_outgoing_exten |
| 21:41.01 | file | mjordan, that makes you... even |
| 21:41.50 | mjordan | yay |
| 21:41.52 | Qwell | mjordan: You could have just unref'ed something in chan_sip instead. It won't miss it. :) |
| 21:42.04 | mjordan | WIMPy: do you have a pb showing the debug around that time? That might explain why it has stack information |
| 21:42.05 | Qwell | as long as it all balances out, ya know? |
| 21:42.12 | mjordan | Qwell: or just unref'd chan_sip.... |
| 21:42.36 | WIMPy | I will clean it from the ANSI stuff. |
| 21:43.49 | mjordan | file: best part, since it was on every single Originated channel, this explains why our core stop gracefully was failing a lot on the test suite |
| 21:44.05 | file | minor detail |
| 21:44.07 | mjordan | so things should run a tad faster now that we don't have to wait 10 seconds to KILL the process |
| 21:46.38 | file | I'm putting bucket in, any objections? (it's self contained so impact will be non-existent anyway) |
| 21:47.46 | mjordan | none |
| 21:48.32 | leedm777 | does not object |
| 21:48.36 | putnopvut | do it |
| 21:50.17 | file | yay. |
| 21:57.33 | WIMPy | mjordan: http://wimpy.yeti.dk/pastebin The Dial starst at line 1161, the 1st sip channel is created at 1300, the mysterious dialplan lookup follows immediately after. |
| 21:59.47 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 21:59.48 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 22:04.02 | WIMPy | The context "dial-master" is not used in that call. It must be the context that's defined as the _called_ peers context as per sip.conf. |
| 22:22.10 | mjordan | WIMPy: I think at this point it's worth taking a closer look. Can you make an issue, attach that debug, and also attach your sip.conf, iax.conf, and relevant dialplan? |
| 22:22.19 | mjordan | I think there's a number of moving parts in there |
| 22:22.41 | mjordan | I will say that for an outbound channel, which has no pbx_thread, the location in the dialplan set on the channel is somewhat immaterial |
| 22:22.58 | mjordan | it only becomes relevant if the channel survives the bridging |
| 22:23.36 | WIMPy | Yes, but it is the location announced in the varset's that beeing looked up. |
| 22:24.02 | WIMPy | And I see no other relation to what it tries to find. |
| 22:24.30 | mjordan | it isn't actually looking up those locations |
| 22:24.46 | mjordan | those are literally the values of the context, exten, and priority that are on the channel at the time of the variable being set |
| 22:25.12 | WIMPy | Yes, but that the location that causes the dundi lookups that follow. |
| 22:25.21 | WIMPy | (and take their time, off course) |
| 22:26.08 | mjordan | I see pbx_dundi looking up IAX2 |
| 22:27.48 | WIMPy | At the beginning of the call, yes. But what about those db accesses after the sip channel is created? From line 1341 |
| 22:28.43 | WIMPy | Apart from the fact that it does more lookups that it should, but that's a different story. |
| 22:28.49 | file | oh... hint... |
| 22:28.55 | mjordan | yup. |
| 22:29.24 | WIMPy | But it says priority 1. |
| 22:29.51 | mjordan | the event information has nothing to do with checking the hint |
| 22:30.20 | mjordan | hints are never "run" from the dialplan. The fact that they exist in the dialplan is sort of just how Asterisk represents extension state - a channel will never execute at the hint priority |
| 22:30.24 | WIMPy | Parsed into + @ dial-canonical priority 1 |
| 22:30.39 | file | is just talking to himself and has nothing to add unless he dives into it |
| 22:31.54 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-qdyzvsziajhjmyjb) |
| 22:32.06 | mjordan | WIMPy: I'd make the issue, cus this feels like more of a deep dive |
| 22:32.09 | WIMPy | It's clearly looking for dial-canonical,,1. Where dial-canonical is switched from dial-master. |
| 22:32.53 | WIMPy | What component do I file that under? chan_sip? |
| 22:35.59 | mjordan | sure |
| 22:36.11 | mjordan | There's so many things going on, you could probably pick a host of them :-D |
| 22:53.29 | WIMPy | I cannot upload the dialplan. It says: Unable to communicate with JIRA. Which seems alive otherwise. |
| 22:54.28 | mjordan | ... |
| 22:54.33 | mjordan | never seen that before |
| 22:55.03 | WIMPy | neither |
| 22:56.41 | WIMPy | I can break everything. |
| 22:56.59 | mjordan | alas, I do have to bounce out |
| 22:57.04 | mjordan | if it won't attach, e-mail it to me and I'll figure it out |
| 22:57.08 | mjordan | mjordan@digium.com |
| 22:57.13 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-fpikfbkwfzoteoco) |
| 23:03.20 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 23:09.38 | WIMPy | Yikes. That's just a misleading error. I didn't have read permissions on that file. |
| 23:11.38 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 23:51.48 | *** join/#asterisk-dev trapito (~trapito@11.43.80.200.host.ifxnw.com.ar) |
| 23:58.36 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |