| 00:20.10 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 00:20.10 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Check out our blog! blogs.asterisk.org -=- Follow on Twitter at @AsteriskDev |
| 00:31.24 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 00:31.25 | *** mode/#asterisk-dev [+o gtjoseph] by ChanServ |
| 00:43.10 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 00:43.10 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 05:22.40 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net) |
| 05:22.41 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:42.46 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 06:44.08 | *** join/#asterisk-dev aiksa[LV] (5f822365@gateway/web/freenode/ip.95.130.35.101) |
| 06:44.47 | aiksa[LV] | Hi, as this is the first time reporting asterisk crashes, can you tell if I have put everything needed here: https://issues.asterisk.org/jira/browse/ASTERISK-26935 ? |
| 06:58.14 | *** join/#asterisk-dev tuxian (~tuxian@igilmour.plus.com) |
| 06:58.22 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 07:03.33 | *** join/#asterisk-dev jkroon (~jkroon@165.255.160.221) |
| 07:07.18 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 07:27.09 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 07:59.15 | *** join/#asterisk-dev tzafrir_ (~tzafrir@bzq-84-109-18-138.cablep.bezeqint.net) |
| 07:59.15 | *** mode/#asterisk-dev [+o tzafrir_] by ChanServ |
| 08:39.11 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 09:23.32 | *** join/#asterisk-dev tuxian (~tuxian@194.12.3.78) |
| 10:05.40 | *** join/#asterisk-dev tzafrir_ (~tzafrir@bzq-84-109-18-138.cablep.bezeqint.net) |
| 10:05.40 | *** mode/#asterisk-dev [+o tzafrir_] by ChanServ |
| 11:22.48 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-136-39.dialup.adsl.anteldata.net.uy) |
| 12:03.06 | *** join/#asterisk-dev leedm777 (~textual@173-16-52-28.client.mchsi.com) |
| 12:03.06 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 12:28.17 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-136-39.dialup.adsl.anteldata.net.uy) |
| 12:32.28 | *** join/#asterisk-dev scgm11__ (~scgm11@r179-28-184-178.dialup.mobile.ancel.net.uy) |
| 12:36.10 | tsearle | good afternoon ast land! |
| 12:38.24 | file | moo |
| 12:42.34 | tsearle | oom! |
| 12:43.33 | tsearle | quick question ref realtime endpoints, & odbc |
| 12:44.08 | tsearle | will things collapse if not all colums are present in the db, or will it work like chan_sip's realtime peers where you only need to have the columns whose values you care about |
| 12:46.34 | file | if the columns aren't present the default values will be used |
| 12:46.40 | file | and if there are extra columns they are ignored |
| 12:48.59 | tsearle | excelent! |
| 12:49.08 | tsearle | that should really cut down on the db size then |
| 12:54.31 | gtjoseph | tsearle: there's 1 exception to that rule though... ps_contacts. Since we write to that table, if a column isn't there that we expect, the INSERT or UPDATE will fail. |
| 12:56.28 | tsearle | ok |
| 12:58.20 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-50-29-172.dialup.adsl.anteldata.net.uy) |
| 13:00.29 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 13:05.31 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-mcjforisteqelyrl) |
| 13:05.31 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 13:44.27 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 13:44.27 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 13:54.31 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:54.31 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:10.36 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-tfbfezsudtqnllnm) |
| 14:10.36 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:15.13 | *** join/#asterisk-dev joshelson (~joshelson@206.81.147.110) |
| 14:40.43 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:40.58 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:46.01 | *** join/#asterisk-dev aiksa[LV] (5f822365@gateway/web/freenode/ip.95.130.35.101) |
| 14:48.32 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-sbfbygwuhlhyihiy) |
| 14:48.32 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 15:45.09 | rmudgett | gtjoseph: Re: https://gerrit.asterisk.org/#/c/5447/ Do you think it would loop? |
| 15:47.05 | gtjoseph | If we're out of FDs and there's still data in the buffer we will but i guess we'll only be in that tight loop until more FDs are available. |
| 15:47.24 | gtjoseph | actually... |
| 15:47.38 | gtjoseph | not data, |
| 15:48.08 | gtjoseph | looks again |
| 15:49.19 | gtjoseph | if we're out of FDs, what happens to the connection? Do we send a reject or nack back to the client or is the connection still there waiting for us to cal laccept again? |
| 15:49.34 | file | good question |
| 15:51.11 | gtjoseph | the docs for accept aren't clear on what happens |
| 15:53.22 | rmudgett | I suppose I should put a usleep() there just to be safe. |
| 15:53.31 | gtjoseph | probably |
| 15:53.40 | rmudgett | a yeild won't reduce CPU usage. |
| 15:55.38 | gtjoseph | true. as long as you're there, i wonder if adding a usleep if ast_wait_for_input fails might be a good idea. |
| 15:59.16 | rmudgett | considering that ast_wait_for_input() is a wrapper around poll it probably is a good idea. |
| 15:59.22 | gtjoseph | yep |
| 16:37.13 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-jdpceqjdvanrdeyr) |
| 16:37.13 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 16:43.07 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 16:43.07 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 17:28.14 | kharwell | file: streams & bridging - thinking of adding a flag to bridge's feature_flags that when set marks that bridge as a streaming bridge. Then when writing the frame it can be check whether or not to do a regular write or a stream_write. thoughts? |
| 17:29.05 | file | Is that a feature of the bridge, or a property of the technology in use? |
| 17:29.24 | kharwell | it'd be a feature of the bridge |
| 17:29.51 | file | That a consumer of the API explicitly requests? |
| 17:29.57 | kharwell | a particular bridge tech though would probably be the one to turn it on |
| 17:30.39 | file | Feature flags, if I remember right, are what consumers of the API use - not techs |
| 17:31.16 | kharwell | some of those look that way yeah. |
| 17:31.53 | file | If it's a detail of the tech I'd be mehish about overloading feature flags for that |
| 17:32.24 | kharwell | I can add a new flag if that's the case. |
| 17:32.35 | kharwell | eerm I new field on the bridge struct that is |
| 17:33.23 | file | Any reason it can't exist on the tech? |
| 17:33.52 | file | That is: it's presence indicates the bridge tech is multistream capable and the bridging core should behave as such |
| 17:34.11 | file | Or are you imagining that a tech may or may not want to operate in that manner |
| 17:34.43 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-zwrdblqmusjfbshv) |
| 17:34.44 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 17:35.15 | rmudgett | gtjoseph: How did you manage to get that cherry-picked from line in the FAILURE reviews? I thought that only happened when the review you cherry picked from was already mereged. |
| 17:35.44 | kharwell | file: I'm not sure. I was thinking the latter. But maybe just setting it on the tech itself would work |
| 17:36.05 | kharwell | for instance could the bridge simple always just be a streaming bridge then? |
| 17:36.21 | file | I think so |
| 17:36.55 | file | You are guaranteed a set behavior even when a channel isn't multistream capable, so always doing streams is fine |
| 17:37.20 | kharwell | true. I think that should work then |
| 17:37.40 | file | I like guarantees |
| 17:38.52 | kharwell | does that mean bridge_simple even cares then if/when a topology change indication comes in? (I was initially thinking the bridge would switch to streaming once it saw that frame) |
| 17:40.34 | rmudgett | I thought everything was doing streaming. The older channel drivers would only use the default stream. |
| 17:42.06 | file | It has to forward a request and act on a result |
| 17:42.39 | file | And on initial join when streams are not the same you have to match up best you can to figure out which stream connects to which |
| 17:42.42 | kharwell | rmudgett: they do |
| 17:43.16 | file | Because we can get an external request to add or remove streams, and on join before we try to get them to be the same |
| 17:43.37 | file | They will be different but we should still match up best we can |
| 17:45.39 | kharwell | file: so on join I just do a call to ast_channel_request_stream_topology_change, so hopefully that part is taken care of. But what do you mean by forward and act? In the simple bridge any frames are already forwarded on. What would I need to act on? |
| 17:46.20 | file | You might get a topology change on both at any point |
| 17:46.48 | file | Externally initiated, provided your code is still triggered then it should be fine |
| 17:48.12 | file | Dog walk time |
| 17:49.01 | kharwell | I think I still don't understand. why would the bridge care about a topology changing? I understand why you want to ask for a change when joining |
| 17:49.43 | kharwell | oh wait or are you saying once two channels are joined and the topologies have been appropriately changed then don't allow any other topo changes through? |
| 17:51.39 | file | No, you have to allow topology changes |
| 17:51.49 | file | For example we might be talking audio and then I add video |
| 17:52.13 | file | That has to be forwarded and if accepted we have to forward the media frames between the streams |
| 17:54.59 | *** join/#asterisk-dev sduthil (~sduthil@modemcable094.94-70-69.static.videotron.ca) |
| 17:55.18 | kharwell | ah in bridge_simple all frames are just allowed through as the default. I believe leaving it should be fine as the channel code takes care of if writing to a particular stream is allowed or not. If writing to a stream the bridge channel code will just call ast_write_stream with the given frame's steam_num |
| 18:07.54 | gtjoseph | @rmudgett: git review -X <gerrit_id> (upper case X) |
| 18:08.22 | gtjoseph | i had to do those locally since there are modules in 14 not in 13. |
| 18:11.23 | rmudgett | gtjoseph: I just cherry-pick to another branch locally. Then put up for review instead. |
| 18:11.36 | rmudgett | I then don't get those cherry-pick lines. |
| 18:11.52 | gtjoseph | you don't get them if oyu use a lower case x either |
| 18:13.36 | rmudgett | My reviews have been updated. :) |
| 18:13.40 | file | power outages for all! |
| 18:14.15 | file | kharwell: on initial join when both sides don't match streams - you can't be guaranteed that stream 1 on channel A should go to stream 1 on channel B |
| 18:14.58 | file | that'd be my concern |
| 18:15.57 | rmudgett | file: Wouldn't that be the same for a reinive that adds streams? |
| 18:16.31 | file | rmudgett: that request would get forwarded |
| 18:16.48 | file | and the remote side would then accept/refuse streams |
| 18:17.05 | file | which would then go back in a response to the incoming reinvite |
| 18:17.26 | *** join/#asterisk-dev jkroon (~jkroon@197.168.246.67) |
| 18:18.05 | kharwell | file: so block a/v frames until bridge_simple receives that the topology changed? |
| 18:18.20 | file | I don't think that's a good user experience |
| 18:18.31 | file | you have to match them up best you can |
| 18:22.41 | kharwell | hrm should a bridge care about that though? Or should that be handled when a stream is being written to? Meaning if the incoming frame does not match the stream type then try another stream (which sounds really bad too for various reasons) |
| 18:23.11 | file | the purpose of bridge is to connect channels and exchange frames |
| 18:23.30 | file | I think it should be up to the bridge to figure out how best to connect and exchange |
| 18:25.03 | file | imo |
| 18:25.13 | kharwell | how does the bridge know what the best stream to pick then? Unless it is assumed to be a one-to-one match. Which we'll get after the bridge knows the topology has successfully changed. But what if it fails to change, or what to do in the meantime while waiting to change? |
| 18:26.57 | file | that is the question - I think for now the easiest option is to take the channel with the smallest number of streams, go through the list, and find the first unpaired stream on the other channel |
| 18:28.14 | file | will we change that in the future? maybe! |
| 18:28.51 | kharwell | what constitutes a pair? |
| 18:29.15 | file | if stream 1 is connected to stream 2... |
| 18:29.23 | file | you can't connect stream 3 to stream 2 |
| 18:29.31 | file | because stream 2 is already paired |
| 18:29.58 | kharwell | where does this pairing take place? |
| 18:30.06 | file | nowhere right now :P |
| 18:30.16 | file | that'd be the responsibility of bridging |
| 18:31.39 | kharwell | oh man! how would a stream initially match with another stream then? |
| 18:31.52 | file | what'cha mean? |
| 18:32.33 | kharwell | for instance: how does the bridge determine if stream 1 on channel A should match with stream 3 on channel B |
| 18:33.03 | file | the best we can do right now is based on ordering and if a stream has not been matched already |
| 18:33.18 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 18:33.19 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 18:34.01 | file | iterate, iterate, iterate |
| 18:35.06 | kharwell | correct, but how do we get there to start? If we don't have an order yet what is the initial way to match streams so other streams when attempting to match can discount already matched streams? |
| 18:35.33 | file | streams are on a channel in order |
| 18:36.01 | file | that's what I was referring to |
| 18:37.58 | kharwell | so then always assume channel A stream 1 pairs with channel B stream 1? |
| 18:38.12 | file | no, because the types might be different |
| 18:38.24 | file | you have to find the first unpaired stream of the same type |
| 18:39.01 | kharwell | okay ya so match on type then order |
| 18:39.25 | file | yeah |
| 18:59.48 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-fmcgyyrpbijflwqf) |
| 18:59.49 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 19:21.29 | gtjoseph | rmudgett: were you actually able to test the stun blacklist stuff? It's take me a while to set up to test it myself. |
| 19:23.06 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-vjsarptwcdpflrwc) |
| 19:23.06 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 19:24.56 | rmudgett | gtjoseph: I faked it. I used my test box with the eth0 and local interfaces. It blacklisted when I expected. |
| 19:25.06 | gtjoseph | ok cool. |
| 19:25.37 | gtjoseph | if i had to test it for real i'd be out of action for the rest of the day. |
| 19:38.02 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d003c794db97bbb5bd2.ipv6.abo.wanadoo.fr) |
| 19:59.56 | rmudgett | gtjoseph: I don't think it is as simple as replacing LOAD_FAILURE with LOAD_DECLINE. Some modules may not clean up to allow a reload attempt. |
| 20:08.42 | kharwell | file: working on a mapping between two topologies. Is it safe to assume if t1[0]->t2[3] then t2[3]->t1[0]? Or could there be one way only mappings? |
| 20:09.45 | file | that's safe |
| 20:41.47 | *** join/#asterisk-dev pchero (~pchero@109.70.54.56) |
| 20:51.32 | gtjoseph | rmudgett: i'll go through them but i didn't see any that raised an alarm. Did you see any specific ones? |
| 20:51.48 | gtjoseph | I did change a bunch with a script |
| 20:52.04 | gtjoseph | so i may have missed a few. |
| 20:52.24 | rmudgett | I only looked at the cdr_mysql.c (the first one) and it doesn't clean up after itself. |
| 20:52.42 | gtjoseph | still better than causing asterisk to exit. |
| 20:52.46 | gtjoseph | ok i'll look |
| 20:53.39 | gtjoseph | many of the modules had mixed declines an failures |
| 20:53.41 | rmudgett | That is an addons module and also very old. So it being less than cleanly exiting is almost guaranteed. |
| 20:53.48 | gtjoseph | yep |
| 20:55.32 | rmudgett | You'll have to take them on a case by case basis. |
| 20:59.10 | rmudgett | Oh. By the way "It's a trap!" |
| 21:00.00 | seanbright | i can look at extended modules if you prefer |
| 21:00.05 | seanbright | separation of concerns and all that. |
| 21:00.22 | gtjoseph | well, cdr_mysql leaks like a sieve even if it succeeds. |
| 21:00.29 | seanbright | naturally |
| 21:00.34 | gtjoseph | nah i got em. thanks seanbright |
| 21:00.42 | seanbright | sure sure |
| 21:04.48 | seanbright | let's encrypt is pretty fancy |
| 21:04.59 | seanbright | literally took me 30 seconds to get a cert |
| 21:05.13 | seanbright | and that includes the time it took to install their tooling |
| 21:05.50 | gtjoseph | is allowing "just anyone" to get a cert in 30 seconds a good thing? :) |
| 21:06.08 | seanbright | if they control the domain, i think the answer is yes |
| 21:06.32 | file | yes. |
| 21:06.43 | seanbright | needless to say, this highly advanced site (https://seanbright.com/) is now secure |
| 21:06.46 | file | you can't just get a certificate without verification |
| 21:07.02 | seanbright | (with an A+ on ssllabs) |
| 21:07.08 | gtjoseph | I remember getting my first cert way back when. it took a week to get through the verification process. |
| 21:07.14 | seanbright | yeah |
| 21:07.28 | file | an EV cert would take that long |
| 21:07.30 | file | or more. |
| 21:07.44 | seanbright | yeah, those are a pain in the ass |
| 21:07.49 | gtjoseph | back then it was every cert. |
| 21:10.29 | gtjoseph | I thought we squashed all the [-Werror=misleading-indentation] errors. apparently we missed app_meetme |
| 21:10.59 | seanbright | saw some interesting errors with clang on freebsd 11 the other day |
| 21:11.17 | gtjoseph | with asterisk or something else? |
| 21:11.19 | seanbright | asterisk |
| 21:11.25 | gtjoseph | hmmm |
| 21:11.29 | seanbright | we're left shifting negative numbers somewhere in main/invert.c |
| 21:11.33 | gtjoseph | not surprised i guess |
| 21:11.39 | seanbright | unsigned/signed weirdness in res_fax.c |
| 21:11.43 | seanbright | that's about all i saw |
| 21:46.28 | *** join/#asterisk-dev scgm11__ (~scgm11@r186-52-77-98.dialup.adsl.anteldata.net.uy) |
| 22:16.24 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8065:c0f4:2d01:6740:c072) |
| 22:16.25 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 22:47.48 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8065:654a:ff37:5289:a867) |
| 22:47.48 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 23:01.56 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8065:11b7:79e4:2ab8:60f6) |
| 23:01.56 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 23:04.07 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-tfbfezsudtqnllnm) |