| 00:04.26 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@mail.redfish-solutions.com) |
| 00:37.18 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 00:37.30 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 00:55.12 | JunK-Y | wdoekes2: ping? |
| 01:04.53 | JunK-Y | Corydon76-home: you said: "Add braces while you're here." , but where? on ast_say_digits() ? |
| 01:05.15 | Corydon76-home | JunK-Y: around the action clause of the if |
| 01:05.30 | Corydon76-home | if (cond) { action here; } |
| 01:05.46 | JunK-Y | ha k, fixed |
| 01:29.08 | *** join/#asterisk-dev otherwiseguy (~otherwise@cpe-69-76-221-79.kc.res.rr.com) |
| 05:02.52 | *** join/#asterisk-dev coreyf1513 (~cfarrell@75-130-93-234.dhcp.wlmn.ct.charter.com) |
| 06:37.32 | *** join/#asterisk-dev oej (~olle@87.96.134.129) |
| 06:37.32 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:15.29 | *** join/#asterisk-dev snuff-work (~kvirc@210.9.82.197) |
| 07:15.29 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 07:56.20 | *** join/#asterisk-dev lftsy (~lftsy@194.38.160.113) |
| 07:58.15 | *** join/#asterisk-dev oej (~olle@87.96.134.129) |
| 07:58.15 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:02.11 | wdoekes2 | pong JunK-Y |
| 08:41.14 | *** join/#asterisk-dev oej (~olle@87.96.134.129) |
| 08:41.15 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:41.42 | oej | Hello folks |
| 08:56.40 | merbanan | hello |
| 09:08.14 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:758d:9be3:921d:eb94) |
| 09:21.14 | *** join/#asterisk-dev sgimeno (~sgimeno@163.117.206.10) |
| 09:23.03 | *** join/#asterisk-dev oej (~olle@87.96.134.129) |
| 09:23.03 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:53.11 | *** join/#asterisk-dev irroot (~gregory@196-215-57-38.dynamic.isadsl.co.za) |
| 10:19.37 | *** join/#asterisk-dev ccesario (~ccesario@189.29.54.144) |
| 10:54.51 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 10:54.56 | schmidts | hello |
| 11:34.24 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:34.24 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:57.52 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 11:57.52 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 12:19.41 | *** join/#asterisk-dev irroot (~gregory@196-215-57-38.dynamic.isadsl.co.za) |
| 12:20.13 | *** part/#asterisk-dev irroot (~gregory@196-215-57-38.dynamic.isadsl.co.za) |
| 12:37.35 | schmidts | could someone maybe take a short look at this review: https://reviewboard.asterisk.org/r/1652/ ;) |
| 12:59.00 | mjordan | schmidts: I'll take a look when I get in |
| 13:03.02 | schmidts | mjordan thank you, its imho very short and easy ;) |
| 13:04.35 | *** part/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 13:19.47 | *** join/#asterisk-dev cVsup (~cVsup@189.105.181.124) |
| 13:23.16 | Marquis42 | schmidts: Looks good to me FWIW. Although get rid of the two red spots. :) |
| 14:05.39 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-zldejnqbxjwqygdf) |
| 14:12.39 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 14:12.39 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 14:15.35 | *** join/#asterisk-dev dwayne (~dwayne@c-76-29-230-45.hsd1.al.comcast.net) |
| 14:16.33 | *** join/#asterisk-dev Deeewayne (~dwayne@c-76-29-230-45.hsd1.al.comcast.net) |
| 14:16.33 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 14:17.27 | schmidts | Marquis42 thanks ;) i will do |
| 14:19.31 | *** join/#asterisk-dev tamiel (~tamiel@85-171-170-252.rev.numericable.fr) |
| 14:21.26 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-gzntpadneguoaaht) |
| 14:21.26 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:22.16 | *** join/#asterisk-dev otherwiseguy (~otherwise@rrcs-173-197-0-67.west.biz.rr.com) |
| 14:50.31 | Marquis42 | schmidts: No problem. That was a nice easy one to review. |
| 14:50.59 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:50.59 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 14:53.31 | schmidts | thats why i asked for it ;) |
| 14:54.13 | schmidts | mjordan i dont understand exactly what you mean with this: (keeping the qualifyfreq as the maximum range however, which - in my opinion - does make more sense the hardcoded 5 seconds) |
| 14:55.29 | wdoekes2 | i.e. keep the first hunk of the change and only use the option for the second one |
| 14:55.42 | mjordan | wdoekes2: exactly |
| 14:56.39 | mjordan | changing the behavior to use the peer's qualifyfreq, instead of 5 seconds, as the range of time possible to schedule the poke makes sense - and should probably be kept regardless of whether or not we provide an option to use the existing behavior (schedule all pokes immediately during a reload) or schedule pokes over a range during a reload |
| 14:57.19 | schmidts | mjordan ok got it ;) |
| 14:57.29 | wdoekes2 | however, that does have drawbacks too. upon startup I could imagine a scenario when I want to know availability of all peers immediately (max 5 seconds). |
| 14:57.51 | wdoekes2 | esp. if I'm doing the nat keepalive and my asterisk has been down for a couple of seconds already |
| 14:58.15 | wdoekes2 | (playing advocate of the devil here) |
| 14:58.31 | schmidts | wdoekes2 on startup the peers are poked pending to the qualifypeers option multiples by 100 ms each |
| 14:59.28 | mjordan | schmidts: are you sure? It looks like they'd be scheduled to go randomly between 1 ms and qualifyfreq |
| 15:00.54 | schmidts | mjordan i am looking at the code cause i am not 100% sure, maybe i have mixed this with the poke_all_peers which also happens on a sip_reload |
| 15:02.59 | mjordan | ugh. So that's a problem - we have two behaviors, one for realtime peers and one for others |
| 15:03.21 | schmidts | mjordan its the same as on reload, peers which are in the astdb will be poked from the reg_source_db the others from poke_all_peers |
| 15:05.41 | mjordan | yes, but the way in which their pokes are scheduled is different. Ideally they'd have the same behavior. |
| 15:06.04 | *** join/#asterisk-dev irroot (~gregory@196-215-57-38.dynamic.isadsl.co.za) |
| 15:06.07 | mjordan | in fact, we already have a parameter controlling the rate of scheduling - qualifygap |
| 15:06.09 | schmidts | realtime peers will be poked directly |
| 15:07.28 | schmidts | the question is, if we even should start poking directly after loading a peer at startup/reload of the module or just use poke_all_peers |
| 15:08.05 | schmidts | imho this will happend after the static peers and realtime peers are loaded, so all of the will get poked pending to the qualify_gap value |
| 15:09.30 | mjordan | hm. Actually, reg_source_db doesn't imply that the peer is realtime, just that we're getting the settings from the Asterisk DB. It can still be a non-rt peer. |
| 15:11.06 | mjordan | I'm not sure reg_source_db should be poking a peer. The purpose of the method seems to be getting the peer information from the Asterisk DB - whether or not that should also schedule a poking of the peer may or may not be needed. I'd have to look through the rest of chan_sip to know for sure, but - since this is called from build_peer - it seems like we could end up in situations where we'd double-poke a peer |
| 15:13.45 | schmidts | mjordan that was also my thought about this part |
| 15:15.43 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:15.43 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:24.02 | *** join/#asterisk-dev cVsup (~cVsup@189.105.181.124) |
| 15:24.36 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:24.36 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:33.47 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 15:34.38 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 15:34.38 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 15:34.56 | *** join/#asterisk-dev otherwiseguy (~otherwise@rrcs-173-197-0-67.west.biz.rr.com) |
| 15:35.15 | oej | mjordan: Another issue is reg expire times. If you have peers in astdb taht expire whiel asterisk is not running, we still try to poke them. We do not save expiry time. Or did not in older versions. Don't know if it's changed. |
| 15:38.00 | schmidts | oej imho you are right, reg_source_db only schedule an expire event but didnt check if the peers has allready been expired and this expire function dont check if this peer is poked or not |
| 15:38.32 | oej | I get a lot of failed transmissions when I restart Asterisk on my laptop. Asteirsk there is only used for testing... |
| 15:38.50 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:38.50 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 15:39.04 | otherwiseguy | oej: it looks like we store an "expiry_str" and parse it, but don't use it to determine whether we should poke. |
| 15:39.33 | schmidts | oej but when the next schedule poke will happen it will notice that the peer has gone and shouldnt poke it anymore |
| 15:39.39 | otherwiseguy | But, I haven't done more than just glance at the code. |
| 15:41.19 | oej | If it's expired, we should not load it... |
| 15:41.40 | otherwiseguy | although the expiry_str might be an interval, so after a restart it wouldn't give any info as to whether or not it was valid. |
| 15:41.58 | oej | I vaguely remember that it was not a real timestamp. |
| 15:44.37 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 15:44.37 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:46.25 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:18.25 | acidfoo | does the AstriConDev 2011 pictures will be online soon? :P |
| 16:18.36 | acidfoo | https://wiki.asterisk.org/wiki/display/AST/AstriDevCon+2011 |
| 16:18.36 | leifmadsen | looks at kpfleming :) |
| 16:18.46 | leifmadsen | they are on his camera |
| 16:18.55 | leifmadsen | I have a couple as well that I haven't posted |
| 16:19.01 | kpfleming | leifmadsen: ahh yes... sorry about that |
| 16:19.10 | leifmadsen | kpfleming: if you send me a copy I can post them :) |
| 16:19.11 | kpfleming | someone needs to shoot me an email to remind me to upload hem |
| 16:19.16 | leifmadsen | kpfleming: I can handle that |
| 16:19.24 | leifmadsen | kpfleming: to your digium or personal? |
| 16:20.33 | kpfleming | either is fine |
| 16:20.51 | kpfleming | i just need something i'll see in the morning while i'm at home |
| 16:21.32 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 16:21.35 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 16:24.58 | otherwiseguy | mjordan: I think we need set accessors for everything in the internal struct, even if we don't necessarily make them globally public. I don't want the functions of the rest of the channel api screwing around with internal channel stuff either. |
| 16:25.15 | otherwiseguy | mjordan: also, I'm really beginning to hate stringfields in general. |
| 16:25.27 | kpfleming | what? say it ain't so. |
| 16:25.47 | mjordan | otherwiseguy: having set accessors that are globally available exposes the now opaque'd fields - unless I'm reading your statement wrong |
| 16:26.40 | otherwiseguy | It doesn't expose the underlying structure at all the way I've done it. It just happens to be kind of ugly looking. |
| 16:27.02 | mjordan | I'm missing how that's the case, since channel.h defined the set accessors |
| 16:27.20 | mjordan | say I have a uniqueid on the channel - can, say, app_voicemail change that? |
| 16:27.36 | otherwiseguy | It just builds the functions, it doesn't require access to the opaque struct from outside. |
| 16:27.50 | otherwiseguy | (access to the internals of the opaque struct) |
| 16:28.02 | mjordan | true, but then your macro in the internal API does that anyway |
| 16:28.18 | otherwiseguy | I don't think so. |
| 16:28.28 | otherwiseguy | Otherwise it wouldn't have compiled. |
| 16:28.39 | otherwiseguy | unless I messed something up. |
| 16:28.42 | otherwiseguy | which I may have done. |
| 16:28.48 | mjordan | or I'm reading it wrong, which is highly possible |
| 16:29.00 | file | I side with mjordan |
| 16:29.47 | otherwiseguy | How do the declarations in channel.h require usage of the internals of the opaque struct? |
| 16:30.35 | mjordan | they don't require it, but they imply it. You define a function that says "you can change the unqiueid". Whether or not that's implemented is immaterial - if I'm an app writer, I'd expect it to be implemented somewhere, and, that when I call it, the uniqueid is changed |
| 16:30.44 | mjordan | but that's a bad thing - I shouldn't be changing the uniqueid (most likely) |
| 16:31.46 | otherwiseguy | andyet, main/cel.c does. |
| 16:31.53 | mjordan | doesn't mean that was a good decision |
| 16:32.04 | otherwiseguy | right, but are we fixing all of those decisions now? |
| 16:32.15 | mjordan | I think so, yes |
| 16:32.16 | file | wait... CEL changes the uniqueid? |
| 16:32.28 | putnopvut | Yeah that seems weird... |
| 16:32.42 | otherwiseguy | struct ast_channel *ast_cel_fabricate_channel_from_event(const struct ast_event *event) |
| 16:32.50 | file | blinks |
| 16:32.53 | mjordan | if we're going to go through the hurculean effort of providing a good level of encapsulation on the object, we should do it right :-) |
| 16:33.21 | otherwiseguy | mjordan: I agree, I would just probably do it in more steps. |
| 16:33.43 | mjordan | I'm okay with that - but it probably means we should branch this off of trunk if we expect to go back and change some of our design decisions |
| 16:33.50 | putnopvut | Ah it's not changing the uniqueid of an existing channel, just creating a dummy channel for an event. At least it's not as bad as it originally sounded. |
| 16:34.09 | otherwiseguy | right, and there are lots of places that do things with tmp channels like that. |
| 16:34.14 | putnopvut | But as mjordan has said, there should be some fields that should be read-only in a channel. |
| 16:34.14 | mjordan | putnopvut: in which case, don't expose the setter of the uniqueid, and provide a method that creates a dummy channel for people that want them |
| 16:34.22 | putnopvut | Yep, exactly |
| 16:34.31 | kpfleming | or make the setters one-shot, although that doesn't help at compile-time |
| 16:34.50 | putnopvut | Hopefully we can avoid the slippery slope of having 1000 different channel creation functions based on what fields you need set. |
| 16:34.57 | otherwiseguy | I'm just afraid of actually introducing bugs in the middle of a huge 10k line patch. I'd rather make actual logic changes separately. |
| 16:35.10 | kpfleming | +1 |
| 16:35.11 | mjordan | you should be able to ask for a dummy channel that comes with the bare minimum of things that you shouldn't be allowed to set yourself |
| 16:35.12 | putnopvut | Yeah, I'm with otherwiseguy in this regard |
| 16:35.29 | mjordan | agreed - but then we should probably create a branch off of trunk for this work |
| 16:35.30 | putnopvut | Right, that can be a change for later, if you ask me |
| 16:35.55 | otherwiseguy | I would prefer not to create a branch because maintaining it would be an f'ing nightmare. |
| 16:35.59 | putnopvut | For right now, making the channel opaque is the first step into a long set of other more beneficial changes. |
| 16:36.13 | otherwiseguy | It completely removes the benefit of being able to do a little at a time. |
| 16:36.14 | mjordan | otherwiseguy: yes it is :-) |
| 16:36.48 | putnopvut | I think otherwiseguy should proceed as he is, but be sure to make notes about these sorts of things as they come up, possibly filing JIRA issues for them. We don't want to forget about this. |
| 16:37.20 | mjordan | this probably should be an issue in JIRA anyway, even though you've probably been doing this in the evenings "in your spare time" |
| 16:37.40 | otherwiseguy | yeah, I need to put some design docs up one the wiki anyway. I'll add a note of things that will need to be changed afterwards. |
| 16:38.11 | otherwiseguy | Yes. Primarily evenings and weekends. Hopefully there will be some time in the next sprint to actually devote to it. :-) |
| 16:38.51 | file | time waits for noone |
| 16:39.19 | mjordan | unless you're a black hole. |
| 16:39.24 | otherwiseguy | file: it waits for people traveling at the speed of light. |
| 16:39.30 | otherwiseguy | sort of. |
| 16:39.40 | putnopvut | file: you misspelled noon |
| 16:40.03 | file | putnopvut, I changed the speeling off iit |
| 16:42.00 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-sdniywfctjfxbwzb) |
| 16:44.28 | otherwiseguy | ooh, I had no idea the GCC "cleanup" attribute existed... |
| 16:44.40 | otherwiseguy | RAII for C. :- |
| 16:44.41 | otherwiseguy | :-) |
| 16:46.22 | otherwiseguy | example: http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization#C_example_using_GCC_extensions |
| 16:46.38 | mjordan | huh |
| 16:46.42 | mjordan | didn't know about that either |
| 16:47.02 | file | the SCF in me is screaming "NOOOOOO! COMPILER SPECIFIC! NOOOOOOOOOOOOOOOOOOO!" |
| 16:47.17 | otherwiseguy | It would be nice to have locks take care of themselves. :-) |
| 16:47.39 | mjordan | file: but the C++ programmer in you thinks "good" |
| 16:47.39 | otherwiseguy | file: the Asterisk part of you should scream "GCC IS THE ONLY COMPILER IN EXISTENCE!" |
| 16:47.44 | kpfleming | heh... that's yet another case where the GCC team has been using the fact that the compiler has the infrastructure in place for C++ to expose these things in C too |
| 16:48.26 | file | mjordan, no comment |
| 16:48.34 | *** join/#asterisk-dev sustav (~alfa@nat/digium/x-mhtbcnuacudbefxz) |
| 16:49.01 | mjordan | otherwiseguy: could be really useful for a lot of our stuff that relies on cleanup blocks |
| 16:49.15 | otherwiseguy | and automatically handling references/locsk. |
| 16:49.19 | otherwiseguy | and locks |
| 16:49.45 | file | added as of 3.3 |
| 16:49.48 | otherwiseguy | With the accessor functions I've been trying to think of the best way to eventually handle references, etc. |
| 16:50.08 | otherwiseguy | Since you are still handing out an internal pointer in many cases, which irritates me. |
| 16:50.11 | *** join/#asterisk-dev Corydon76-work (pink@c-69-137-80-31.hsd1.tn.comcast.net) |
| 16:50.12 | *** mode/#asterisk-dev [+o Corydon76-work] by ChanServ |
| 16:50.38 | otherwiseguy | but making "copy functions" for all the types doesn't seem practical, etc. |
| 16:51.11 | mjordan | file: so it will work even with rmudgetts compiler |
| 16:51.16 | otherwiseguy | hehe |
| 17:10.04 | putnopvut | barfs at "100 Trying -- Your call is important to us" |
| 17:11.38 | pabelanger | putnopvut: where did you see that? |
| 17:12.00 | putnopvut | pabelanger: in the pcap file on ASTERISK-17929 |
| 17:12.12 | pabelanger | o.0 |
| 17:12.41 | oej | That's a heritage from the GOod Old SIP Express ROuter. |
| 17:13.04 | otherwiseguy | putnopvut: I've read chan_sip. My stomach can handle anything. |
| 17:13.11 | putnopvut | hah |
| 17:13.16 | oej | otherwiseguy: :-) |
| 17:13.22 | file | otherwiseguy, if you had truly read chan_sip you would be crying in a corner |
| 17:13.33 | otherwiseguy | file: I have no more tears. |
| 17:13.36 | oej | file: We're beyond crying. |
| 17:13.40 | putnopvut | You can cry dust |
| 17:13.46 | file | or blood |
| 17:13.59 | putnopvut | That would be cool |
| 17:14.07 | putnopvut | I mean, not really, but it would look neat. |
| 17:14.20 | otherwiseguy | I tried to restructure chan_sip to have a transaction layer and a transmission layer in my free time. |
| 17:14.30 | otherwiseguy | I finally gave up. |
| 17:14.32 | oej | You brave man |
| 17:14.33 | putnopvut | Yeah, not worth it for one |
| 17:14.44 | putnopvut | It would be a lot easier to just use an existing SIP stack. |
| 17:15.05 | otherwiseguy | putnopvut: That was my determination after a month of weekends. |
| 17:15.32 | otherwiseguy | (4 weekends, not 15) |
| 17:15.54 | putnopvut | ha, I kind of figured that's what you meant. |
| 17:17.07 | otherwiseguy | I like to be explicit, but not in the "explicit lyrics" kind of way. |
| 17:17.45 | otherwiseguy | Ok, so maybe in that way too. |
| 17:18.34 | *** join/#asterisk-dev Deeewayne (~dwayne@c-76-29-230-45.hsd1.al.comcast.net) |
| 17:18.34 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 17:20.38 | otherwiseguy | menuselect is kind of screwy on "Test Modules". On a fresh 1.8 checkout, all of them show checked, but under compiler flags TEST_FRAMEWORK is not checked. Checking TEST_FRAMEWORK and saving and going back into menuselect shows none of the test modules checked. |
| 17:22.52 | mjordan | otherwiseguy: huh, I've never seen that |
| 17:23.07 | mjordan | none of them should be checked in a fresh checkout |
| 17:23.11 | mjordan | in my opinion, anyway |
| 17:23.39 | otherwiseguy | Yeah, it doesn't seem like they are really enabled, they just show up as checked. Weird. |
| 17:23.42 | mjordan | I guess if you go by module support state, that would be what would happen |
| 17:24.08 | mjordan | are they built but just not registered? |
| 17:24.49 | otherwiseguy | I'll test. |
| 17:25.29 | *** join/#asterisk-dev moy (~moy@216.172.42.74) |
| 17:27.36 | *** join/#asterisk-dev oej (~olle@2001:16d8:cc57:1000:1def:bacd:1428:792b) |
| 17:27.36 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:30.03 | otherwiseguy | nope. they show up in menuselect.makeopts under MENUSELECT_TESTS, but don't get built. |
| 17:30.38 | otherwiseguy | and re-running menuselect shows them unchecked. |
| 17:31.40 | pabelanger | --enable-dev-mode? |
| 17:31.45 | otherwiseguy | yes |
| 17:31.53 | otherwiseguy | There are other ways to compile?! |
| 17:31.58 | otherwiseguy | configure, that is. |
| 17:34.59 | otherwiseguy | Huh, menuselect.makeopts lists modules that *aren't* to be built? I did not know that. |
| 17:35.12 | putnopvut | yep, highly intuitive |
| 17:35.31 | otherwiseguy | but the MENUSELECT_FLAGS shows the flags that should be used. |
| 17:35.31 | kpfleming | well, part of that file is negative output, and part of it is positive output. |
| 17:35.46 | kpfleming | that was originally to keep the file size down |
| 17:35.56 | otherwiseguy | bits are expensive. |
| 17:37.24 | otherwiseguy | so yeah, they are disabled but just happen to show up as though they aren't on first running of menuselect. |
| 17:37.47 | file | kpfleming, positive and negative reinforcement! |
| 17:45.07 | *** join/#asterisk-dev oej (~olle@87.96.134.129) |
| 17:45.07 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:20.08 | *** join/#asterisk-dev tamiel (~tamiel@85-171-170-252.rev.numericable.fr) |
| 18:34.57 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 18:34.57 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 18:36.12 | *** join/#asterisk-dev oej (~olle@87.96.134.129) |
| 18:36.13 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:59.41 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 19:30.22 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:528:6b19:5ff:e5a9) |
| 20:15.38 | *** join/#asterisk-dev tzafrir (~tzafrir@212.179.75.202) |
| 20:15.38 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 21:18.08 | putnopvut | Does anyone have a recommended softphone they like to use for making SIP TLS calls to Asterisk? I tried to use the Windows version of Blink and followed the instructions here https://wiki.asterisk.org/wiki/display/AST/Secure+Calling+Tutorial but they did not work properly for me. Whenever I try to place a call with blink I see an error message saying "unsupported transport: tls" It makes me think that either there is some |
| 21:18.09 | putnopvut | dependency I don't know about or the Windows blink client does not support TLS. |
| 21:42.19 | jdoe | putnopvut: I've used bria (iphone), I imagine x-lite's windows client can't be that bad either. |
| 21:42.42 | jdoe | but I haven't tried it in years. |
| 21:43.10 | jdoe | er... x-lite, I meant counterpath's windows client. |
| 21:43.20 | putnopvut | jdoe: thanks |
| 21:51.45 | kpfleming | is jitsi available for windows? |
| 21:55.43 | putnopvut | I may have gotten things working on a SNOM hardphone in the meantime. No idea of the availability of jitsi for windows. |
| 21:56.13 | putnopvut | Looks like it though from their website. All the screencaps are windows. |
| 21:57.31 | WIMPy | Does it work for you? |
| 21:58.23 | putnopvut | It appears I've gotten the SNOM device working properly. I just had to change the outbound proxy to have TLS transport specified and upload the certificate file Asterisk was expecting. |
| 22:00.03 | WIMPy | Last time I tried it was a one-way ting for me. |
| 22:10.13 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 22:10.13 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 22:30.06 | luckman212 | I was going to make some comments on https://issues.asterisk.org/jira/browse/ASTERISK-17929 is there a reason I cannot? |
| 22:30.26 | luckman212 | whoops |
| 22:30.28 | luckman212 | nevermind |
| 22:30.57 | luckman212 | it was https://issues.asterisk.org/jira/browse/ASTERISK-19173 that I was trying to comment on |
| 22:31.06 | luckman212 | that seems to be locked for some reason |
| 22:31.40 | Qwell | It's in waiting for feedback, and only the assignee can comment. It's a known strangeness. |
| 22:31.40 | leifmadsen | luckman212: because it is assigned to Ross Beer, and is in Waiting For Feedback |
| 22:32.13 | luckman212 | ah. I see. Well I've got the same issue and was going to submit some logs, pcap files against it |
| 22:32.26 | luckman212 | I don't want to open a duplicate issue -- but I thought the logs might be useful |
| 22:33.01 | kpfleming | wdoekes2: otherwiseguy: thanks for fixing up that 'core stop...' stuff. it's been annoying for a very long time. |
| 22:34.13 | otherwiseguy | yeah, thanks wdoekes2. :-) I kept getting sidetracked with opaquification stuff in my free time. |
| 22:36.18 | otherwiseguy | kpfleming: I still get a blasted segfault occasionally in dlclose() which I haven't taken the time to track down. |
| 22:36.42 | kpfleming | yes, it's been a problem for a long time as well. it depends on what libraries you have loaded via modules, they trigger it. |
| 22:37.05 | otherwiseguy | seems to happen with different modules be unloaded. I've seen it with calendar modules and cel_sqlite3 lately. |
| 22:37.21 | otherwiseguy | s/be/being/ |
| 22:38.02 | otherwiseguy | But I can reproduce it easily now by having asterisk running in a while loop, then doing asterisk -rx "core stop gracefully" in another while loop. |
| 22:40.02 | kpfleming | well sure... but that's not a supported use case :-) |
| 22:40.57 | Qwell | otherwiseguy: that's a different issue |
| 22:41.07 | otherwiseguy | yes. |
| 22:41.08 | Qwell | asterisk; asterisk -rx "core stop now" |
| 22:41.15 | Qwell | that will hang in some cases |
| 22:42.18 | otherwiseguy | well, the loop (after fixing things with wdoekes patch) ends up reproducing the dlcose() issue. |
| 22:42.27 | otherwiseguy | I could use core stop now as well. |
| 22:42.56 | otherwiseguy | the one wdoekes fixed caused a crash other than the dlclose. |
| 22:43.19 | otherwiseguy | for me it was usually because of cleaning up after libxml |
| 22:46.22 | *** part/#asterisk-dev sustav (~alfa@nat/digium/x-mhtbcnuacudbefxz) |
| 22:51.17 | mjordan | otherwiseguy: if you look at the asterisk testsuite failures, the vast majority are due to the dlclose problem |
| 22:51.36 | otherwiseguy | mjordan: not on my machine. :-) |
| 22:51.39 | mjordan | typically happening when the loader looks to see what has global symbols and closes the shared object |
| 22:51.44 | otherwiseguy | and it is the one I care most about. |
| 22:51.51 | otherwiseguy | because I'm a bastard. |
| 22:52.06 | mjordan | well, if you'd like to fix the testsuite's little red wagon while you're at it, I'd be all about it. |
| 22:52.32 | otherwiseguy | mjordan: don't tempt me…I have a bad habit of getting sidetracked. :-) |
| 22:53.11 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-gzntpadneguoaaht) |
| 22:53.19 | otherwiseguy | wow, didn't mean he had to leave. |
| 23:03.17 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 23:03.17 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 23:56.31 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 23:56.31 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |