| 00:08.00 | *** join/#asterisk-dev Dovid (~Dovid@ool-2f113961.dyn.optonline.net) |
| 00:20.59 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-kzcikuzeddkpiohu) |
| 02:18.08 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 02:18.08 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 02:33.47 | *** join/#asterisk-dev Marquis42 (~mrbmw@d149-67-95-208.try.wideopenwest.com) |
| 04:19.37 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 04:19.37 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 04:26.09 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 04:26.09 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 07:04.59 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 07:04.59 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:33.51 | *** join/#asterisk-dev michael_work (~michael_w@bzq-82-168-31-134.red.bezeqint.net) |
| 07:33.52 | *** join/#asterisk-dev michael_work_ (~michael_w@bzq-82-168-31-134.red.bezeqint.net) |
| 08:01.28 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 08:01.28 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:11.57 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 08:11.57 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:25.53 | oej | Good morning folks! |
| 08:26.14 | WIMPy | Good morning |
| 08:51.16 | skrusty | good morning |
| 08:51.57 | skrusty | do people in other countries say "morning" or "afternoon" when passing someone they've never met on a walk, or is it just the English? :) |
| 08:53.14 | WIMPy | I think that's a thing in rural areas. |
| 08:54.29 | skrusty | yeah, it doesn't happen in London! |
| 08:54.31 | skrusty | :) |
| 08:57.45 | wdoekes | obviously that depends on how many people you meet on a walk, which has to do with population density => rural areas |
| 09:02.47 | skrusty | ok, this already sounds like it's getting way too complex an answer ;) |
| 09:05.02 | WIMPy | How about: It's rate-limited? |
| 09:11.16 | skrusty | ;) |
| 09:11.37 | skrusty | inversely proportional to density |
| 09:14.14 | wdoekes | not density per se. I think WIMPy's rate-limit comes closest: there's a limited amount of "morning"s you'll use, perhaps saving some for the co-workers you're heading to |
| 09:38.19 | oej | A very complex problem⦠|
| 09:39.08 | hurdman | moring *world |
| 09:39.09 | WIMPy | suggests a token bucket aproach. |
| 09:39.14 | hurdman | +n |
| 12:13.39 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 12:13.39 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:16.50 | oej | Afternoon folks |
| 12:19.43 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 12:19.43 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 12:55.07 | *** join/#asterisk-dev Dovid (~Dovid@ool-2f113961.dyn.optonline.net) |
| 13:01.55 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 13:01.55 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Asterisk 13.0.0 now released. Do the release dance! -=- Follow on Twitter at @AsteriskDev |
| 13:13.28 | jsmith | skrusty: It's a more rural thing here in the USA... |
| 13:13.43 | skrusty | interesting |
| 13:13.52 | jsmith | skrusty: It also depends on the region. If you did that in New York or Boston, people would look at you like you were from Mars. |
| 13:14.09 | jsmith | skrusty: If you did that in the South, they'd smile back and wish you a good morning as well |
| 13:14.09 | skrusty | i live in a city, and as long as you're not in the city centre, it'll happen (Derby is a small city mind you!) |
| 13:14.17 | skrusty | yeah |
| 13:14.58 | jsmith | skrusty: Where I grew up in Wyoming, you'd even greet the driver of cars you passed on the road by raising two fingers from the steering wheel. |
| 13:15.55 | opticron | that happens in rural alabama as well |
| 13:15.55 | jsmith | skrusty: (and it was often "Howdy" instead of "Good Morning", but it was considered impolite not to greet someone) |
| 13:16.26 | skrusty | I bike into work (office is about 6 minutes from my house) and i say hello to about 6-7 people on a regular basis, which is nice |
| 13:18.36 | mjordan | I'm a firm believer in the two finger greeting |
| 13:19.29 | skrusty | lol :) |
| 13:19.57 | skrusty | are two fingers an insult in the states too? or just something the english do to the french? :) |
| 13:20.16 | mjordan | definitely not an insult here. We use the standard one finger for that. |
| 13:20.26 | mjordan | "The New Jersey Hello" |
| 13:20.37 | skrusty | two fingers is an insult here too, our bow fingers. |
| 13:21.29 | mjordan | do you have to do a whole hand wave to be polite? That's a lot of effort |
| 13:21.56 | file | strange strange people |
| 13:21.57 | Marquis42 | That does reek of effort. |
| 13:21.59 | skrusty | drivers will lift all fingers up to thank, or the whole hand |
| 13:22.34 | skrusty | we're english, we're complex people! :) |
| 13:23.02 | mjordan | I'm not sure I have the energy for that, as often as I give the friendly 'oh hey there, we're two people trying to get to work and not kill the idiotic drivers around us, hope you have a good one' |
| 13:23.16 | skrusty | haha :) |
| 13:26.08 | jsmith | See, I was taught to raise all four fingers while driving if you pass someone you know, and two fingers (index and middle finger, together) for strangers... |
| 13:26.51 | skrusty | crazy! |
| 13:29.18 | *** join/#asterisk-dev michael_work (~michael_w@bzq-82-168-31-134.red.bezeqint.net) |
| 13:38.25 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 13:39.04 | mjordan | jsmith: I like that the level of effort increases based on expectations of friendliness |
| 13:39.31 | jsmith | mjordan: It's that same way in much of the south, right?!? |
| 13:39.40 | jsmith | mjordan: (especially in more rural areas) |
| 13:42.07 | mjordan | yup, but at least we give people 2 fingers |
| 13:42.39 | skrusty | haha, i still find that phrase funny |
| 13:43.09 | skrusty | it's not as much of an insult as one finger, but still |
| 14:13.03 | *** join/#asterisk-dev leedm777 (~leedm777@nat/digium/x-zvzqhaffkzkvabnz) |
| 14:26.34 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-ijfgtminqypjcaao) |
| 14:26.34 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:34.22 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-kvtvogkhkarmllpb) |
| 14:42.55 | wdoekes | hah, skrusty, with 50% of all movements by bike here, greeting everyone would be outright impossible |
| 14:47.05 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 14:47.05 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:47.49 | wdoekes | (and greeting with 2 fingers is perfectly acceptable) |
| 14:59.36 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-mqikgrkxsehyqtxn) |
| 15:00.20 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 15:05.23 | Marquis42 | Presumably as long as those 2 fingers aren't the middle ones on each hand? ;) |
| 15:11.38 | skrusty | :] |
| 15:12.25 | skrusty | "Nick has endorsed you for 'Rimjobs'" :/ |
| 15:12.26 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-whjzyduuhzvszmrm) |
| 15:12.26 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 15:12.28 | skrusty | oop |
| 15:12.29 | skrusty | s |
| 15:12.31 | skrusty | wrong chan :/ |
| 15:12.42 | skrusty | sorry :/ |
| 15:15.56 | *** join/#asterisk-dev alami (~ialami@unaffiliated/alami) |
| 15:20.32 | *** join/#asterisk-dev ipengineer_ (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 15:28.53 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:28.53 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:41.07 | *** part/#asterisk-dev alami (~ialami@unaffiliated/alami) |
| 15:52.27 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 15:57.52 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-yrhdoqnigfeaxyzj) |
| 16:05.18 | *** join/#asterisk-dev zerohalo (~zerohalo@2601:6:f80:224:5457:a3bb:e800:c658) |
| 16:30.13 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-xyqlyqowgtbjnalc) |
| 16:30.13 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 16:35.45 | *** join/#asterisk-dev leedm777 (~leedm777@nat/digium/x-cvrrjlaywyaymzdz) |
| 16:36.00 | opticron | do we maintain aliases for variations on codec names used in SDP? |
| 16:36.18 | opticron | we have a snom phone here that presents g726 as g726-32 |
| 16:36.30 | opticron | asterisk isn't happy about it |
| 16:37.04 | mjordan | opticron: I don't think we do anywhere, in any version of Asterisk |
| 16:37.32 | opticron | yeah, I don't remember ever seeing them |
| 16:38.55 | mjordan | well |
| 16:39.06 | mjordan | per RFC 3551, it looks like it should be G726-xx for any flavor |
| 16:39.15 | mjordan | See https://www.ietf.org/rfc/rfc3551.txt, section 4.5.4 |
| 16:40.16 | mjordan | Applications MUST determine the encoding type of packed codewords from the RTP payload identifier. |
| 16:42.13 | opticron | so really, G726-XX should be the primary identifier and g726 should be an alias to g726-32 |
| 16:42.29 | opticron | but that gets complicated |
| 16:42.34 | file | it's in the RTP engine stuff as G726-32 |
| 16:45.41 | opticron | rechecks with the test setup |
| 16:46.19 | mjordan | I'm not sure there should be an alias at all |
| 16:46.29 | mjordan | g726 - without any specifier - isn't enough information to decode the media |
| 16:46.45 | mjordan | (If I'm reading that RFC correctly, at any rate) |
| 16:47.00 | opticron | right, according to the RFC that is the proper way to do things |
| 16:54.34 | mjordan | opticron: so, looking at what we have - we support codec translation for g726-32, and format pass through for all |
| 16:54.41 | mjordan | I would imagine that each of those is a separate builtin codec however |
| 16:55.23 | file | we don't actually do format pass through for the rest |
| 16:56.06 | mjordan | not surprised |
| 16:56.13 | mjordan | so, basically, g726-32 or bust |
| 16:56.17 | file | yes. |
| 16:56.22 | mjordan | fair 'nough |
| 16:56.36 | mjordan | opticron: that should make the code change relatively minor then |
| 16:58.37 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 17:09.38 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-35-215.user.veloxzone.com.br) |
| 17:48.07 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-scjwopazvsqzkbct) |
| 17:48.09 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 17:48.09 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 17:59.43 | gtjoseph | how the hell do you get debug messages to print to the console? Seems like it should be as simple as 'core set debug n' where n is ast_debug(n, ...) but it's not working. |
| 18:06.37 | jsmith | gtjoseph: Do you have "debug" turned on in logger.conf? |
| 18:06.50 | jsmith | gtjoseph: (in the console=> line, as I recall) |
| 18:07.08 | gtjoseph | crap |
| 18:08.06 | gtjoseph | thanks jsmith, that was it. |
| 18:08.17 | jsmith | gtjoseph: :-) |
| 18:13.30 | newtonr | gtjoseph, logging in Asterisk is confusing for everyone. Every other JIRA issue requires me linking to the article on collecting debug. Even then most people can't follow it right |
| 18:13.59 | gtjoseph | Well, add me to that list. :) |
| 18:15.52 | newtonr | :D |
| 18:18.35 | mjordan | newtonr: the vast majority of people don't bother to read the instructions either way |
| 18:19.23 | newtonr | yup, it is very evident from reading any issue tracker, or comments on any open source forum |
| 18:19.42 | newtonr | or working in tech support for a few years |
| 18:20.31 | newtonr | people, O people, why do you do what you do |
| 18:20.46 | mjordan | after looking at a few this morning, I almost wanted to institute a "we close the issue if you didn't read the instructions" policy .. but yeah. Not quite there yet. |
| 18:21.18 | newtonr | we can do the soup nazi |
| 18:21.28 | newtonr | No support for you! |
| 18:21.58 | gtjoseph | what's really funny is that people like me who've been telling people to RTFM for decades forget to RTFM themselves. :) |
| 18:22.16 | newtonr | well we are only human |
| 18:22.51 | *** join/#asterisk-dev hexanol (~bibi@modemcable094.94-70-69.static.videotron.ca) |
| 18:26.14 | mjordan | gtjoseph: I like to be guilty of that often as well |
| 18:26.40 | gtjoseph | :) |
| 18:59.05 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-wrsnceronjihczrk) |
| 18:59.05 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 19:23.17 | putnopvut | Address trickery in PJSIP is confusing me. Situation: I'm bound to wildcard 0.0.0.0 address. SIPp sends an INVITE from 127.0.0.2 to 127.0.0.1. When we create the dialog for the incoming INVITE, we tell the dialog to use sip:10.24.20.249:5060 as the contact URI. Then, when we actually send a 200 OK response, the Contact header of the 200 OK has sip:127.0.0.2:5060 in it. |
| 19:24.13 | putnopvut | Now, I've figured out why we tell the dialog to use 10.24.20.249 as the contact. That's because the transport we created that used the wildcard binding picked that as its published address. |
| 19:24.48 | putnopvut | What I haven't figured out is what the hell happens that results in sip:127.0.0.2:5060 being in the contact header that we send in the 200 OK. I'm looking fore places that modify the dialog's local contact and I'm not finding it anywhere. |
| 19:24.59 | putnopvut | Anyone know off the top of their head what would cause that? |
| 19:25.04 | file | res_pjsip_multihomed |
| 19:25.16 | putnopvut | looks there. |
| 19:35.12 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 19:35.12 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:35.53 | putnopvut | file: yep, thanks! |
| 20:03.09 | ipengineer | I have a couple of backtraces from asterisk deadlocking today. I am curious if it is being caused by realtime? It sounds extremely familiar to this issue: https://issues.asterisk.org/jira/browse/ASTERISK-21228 |
| 20:03.32 | ipengineer | Here are the backtraces: https://gist.github.com/zconkle/569f1f65cbe4024a8348 https://gist.github.com/zconkle/ce636b43084cc5fd66fd |
| 20:10.03 | oej | putnopvut - make sure you bind RTP so you not only can handle ICE but also symmetric RTP |
| 20:11.20 | oej | It happens by "accident" today thanks to the binding |
| 20:14.13 | putnopvut | ipengineer: Not sure about the reported issue you linked to, but your issue looks to be pretty MySQL-specific. The locks being waited on are ones in res_config_mysql.c. It may be that an off-nominal path isn't unlocking a mysql_conn's lock. |
| 20:14.26 | putnopvut | oej: yeah, I'm starting to re-think this hold binding problem. |
| 20:15.59 | ipengineer | putnopvut: What would you suggest? Would moving to res_odbc help? |
| 20:17.10 | mjordan | ipengineer: your second backtrace looks similar to https://issues.asterisk.org/jira/browse/ASTERISK-21387 |
| 20:17.22 | mjordan | If you aren't using pbx_realtime, then you aren't running into ASTERISK-21228 |
| 20:19.38 | mjordan | ipengineer: in the case of ASTERISK-21387, that is res_config_mysql specific. Keep in mind that module has no maintainer. |
| 20:20.07 | mjordan | if you are running into the same problem as ASTERISK-21387, then moving to res_config_odbc would alleviate it |
| 20:20.22 | *** join/#asterisk-dev leedm777 (~leedm777@nat/digium/x-flmdsxuopwxevowg) |
| 20:20.26 | mjordan | ipengineer: also, are you running 13.0.x or 12.x? |
| 20:21.17 | ipengineer | mjordan: Ok. I think on that ticket I posted above I saw your comment about the switch statement in the dialplan, which we do use. https://gist.github.com/zconkle/b2230481628f4cbad162 |
| 20:21.22 | ipengineer | 13.0.1 |
| 20:21.27 | *** part/#asterisk-dev hurdman (~ygcheny@cylon.r0b0t.fr) |
| 20:22.15 | mjordan | hm. |
| 20:22.22 | mjordan | welp. |
| 20:22.30 | mjordan | YEAH. You might be running into both problems then. |
| 20:22.47 | mjordan | The underlying cause of the pbx_realtime issues doesn't care about your backend. It's just going to mess up. |
| 20:22.57 | mjordan | Your second set of threads looks specific to res_config_mysql. |
| 20:23.09 | ipengineer | mjordan: Ok |
| 20:23.18 | ipengineer | So what would be the replacement for the switch statement OR having everything in the context files? AGI? |
| 20:23.24 | mjordan | You may want to also move to 13.1.0-rc2 (JUST RELEASED!) It has some fixes for some thread explosion issues - which your backtrace kinda shows you're hitting |
| 20:23.30 | mjordan | func_odbc |
| 20:24.06 | ipengineer | Is there some documentation that would show me what something like that would look like? |
| 20:24.25 | mjordan | well, that all depends on how you're structuring your dialplan... but... |
| 20:24.41 | mjordan | http://www.asteriskdocs.org/en/3rd_Edition/asterisk-book-html-chunk/getting_funky.html |
| 20:25.00 | mjordan | generally, the idea is that you make the dialplan generic |
| 20:25.14 | mjordan | and use ODBC to pull in the parts that are specific to certain customers |
| 20:25.16 | mjordan | or users |
| 20:25.45 | mjordan | the hotdesking example is a good one, as who gets hot-desked is stored in the db |
| 20:27.34 | ipengineer | mjordan: I updated the gist to give an example of what the dialplan looks like. Basically every resource (group, menu, timeframe, etc) has a context and the data is in the db. https://gist.github.com/zconkle/b2230481628f4cbad162 |
| 20:29.10 | mjordan | looking at that, the only part that probably needs to be extracted is the dial string |
| 20:30.03 | ipengineer | Our thinking on this side initially is to use fastAGI as a drop in replacement for realtime. Let it pull the info from the db. However we may not be coming at this from the right angle. Even if we could do that not sure if it would resolve the problem.. i do not know how much work would go into func_odbc. Looks like we would have to restructure the entire dialplan.. |
| 20:34.23 | mjordan | possibly. You could hack pbx.c to not start autoservice on channels prior to executing a switch statement. Right now, that's a tough problem to solve correctly (hence why the issue has been open for so long) |
| 20:39.18 | ipengineer | mjordan: Ok. I think I understand what you are saying.. To better draw a pic for you this is what we were going to go to work on but not sure if it is worth the effort or if we should focus it elsewhere: https://gist.github.com/zconkle/154656db85cee13a05ea |
| 20:39.38 | ipengineer | Wouldnât that eliviate âpbx_realtimeâ? |
| 20:45.00 | jsmith | ipengineer: If you were going to do it that way, #exec would make more sense than AGI |
| 20:45.19 | jsmith | ipengineer: (I think you have to turn on a setting in asterisk.conf for #exec to work) |
| 20:46.01 | ipengineer | jsmith: You are saying use exec from the AGI script? If so that is what we were planning to do.. If not where else would we use exec? |
| 20:46.36 | jsmith | ipengineer: No, I'm saying use #exec from the dialplan... and have your PHP dynamically generate your dialplan |
| 20:51.33 | kharwell | I'm working on a problem where a race condition occurs between sdp negotiation and native bridging with direct media enabled (chan_pjsip) |
| 20:51.52 | kharwell | would making chan_pjsip_answer synchronous be an okay thing to do? by making it so and by unlocking and then relocking the channel I don't see any diff from the way it currently executes |
| 20:52.36 | kharwell | testing those changes seems to fix the problem, but I am open to other ideas if that is unreasonable |
| 20:53.03 | ipengineer | Ok. Thanks mjordan jsmith I am going to update to rc2, try res_config_odbc and in the meantime try to figure out a way to eliminate pbx_realtime altogether. |
| 20:53.10 | kharwell | I tried notifying the bridge after the sdp negotiation has taken place, but sometimes that resulted in only a single re-invite being sent out |
| 21:09.31 | putnopvut | kharwell: I think that answering synchronously is probably fine. The concern about unlocking the channel is probably not going to be immediately obvious from typical usage. The possible issues it might cause would be if something tried to, for instance, hang up the channel during the time the channel is unlocked. I don't know if there might be some sort of odd race condition tha tmight happen there. |
| 21:10.11 | file | it *should* be okay |
| 21:10.13 | putnopvut | I don't think it would be a problem, but it wouldn't hurt to try to do a visual audit of that sort of situation |
| 21:12.58 | putnopvut | I think the use of serializers on the PJSIP session should at least alleviate the problem of trying to do something like send an error response and a 200 OK to the INVITE simultaneously. |
| 21:13.37 | putnopvut | And that would be the real concern since we don't mess with the channel itself in the answer() serializer callback. |
| 21:37.25 | kharwell | from what I can tell the code currently runs with the channel unlocked (since the answer task runs async), so if I unlock it before calling the synchronous task it should mimic the current behavior |
| 21:38.23 | kharwell | I didn't know too if there could be some potential timing/efficiency problems by not running the answer task in a separate thread |
| 21:38.30 | kharwell | but as you say not immediately obvious |
| 21:42.48 | *** join/#asterisk-dev Corydon76 (~quassel@c-69-137-93-158.hsd1.tn.comcast.net) |
| 21:42.48 | *** mode/#asterisk-dev [+o Corydon76] by ChanServ |
| 22:03.56 | gtjoseph | is there a reason that ast_module_reload isn't exposed in module.h? |
| 22:07.00 | mjordan | gtjoseph: frustration? |
| 22:07.16 | gtjoseph | on my part, yes. :) |
| 22:08.28 | mjordan | welp. |
| 22:08.32 | mjordan | It is exposed in _private.h. |
| 22:08.38 | mjordan | But that'd be a 'bad practice' to use it. |
| 22:09.35 | mjordan | apparently that doesn't stop manager/cli/others from using it |
| 22:09.58 | gtjoseph | yep, I just noticed that. |
| 22:09.58 | gtjoseph | got a suggestion? |
| 22:10.00 | gtjoseph | exactly |
| 22:10.00 | gtjoseph | do you know why it was _private in the first place? |
| 22:10.18 | mjordan | I think that my predate time itself |
| 22:10.20 | mjordan | er, may |
| 22:10.46 | gtjoseph | i can use _private or move it to module.h. which would you prefer? |
| 22:10.50 | *** join/#asterisk-dev zerohalo (~zerohalo@2601:6:f80:224:5457:a3bb:e800:c658) |
| 22:10.58 | *** join/#asterisk-dev tm1000 (sid6728@gateway/web/irccloud.com/x-dbqvzijnycobqblz) |
| 22:11.17 | mjordan | gtjoseph: not surprisingly, we get svn log -c 89465 as an explanation |
| 22:11.57 | mjordan | gtjoseph: I'm fine with it being in module.h. People shouldn't abuse it, but I'm not sure why triggering a reload should be a "omg don't do this" kind of thing. _private.h is supposed to be for things that shouldn't be touched, ever, by loadable modules |
| 22:12.32 | gtjoseph | Cool. Given that load and unload are public it would make sense. |
| 22:12.47 | mjordan | I would actually think that load/unload are more dangerous than reload |
| 22:12.55 | mjordan | unloading some module at will is actually pretty scary |
| 22:14.38 | gtjoseph | maybe i'll just skip it for now. i can do what I want with just a few lines of extra code. |
| 22:14.48 | gtjoseph | that is...reload res_pjsip. |
| 22:15.00 | gtjoseph | which just reloads sorcery |
| 22:26.29 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 22:44.19 | *** join/#asterisk-dev snuff-work (~snuffy@203.87.61.22) |
| 22:44.20 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 22:44.38 | *** join/#asterisk-dev __sen (sid41282@gateway/web/irccloud.com/x-zftsjpxkevaqcpbq) |
| 23:23.53 | __sen | it's been almost a decade since i contributed anything to * so figured I'd bring this up here before sending in any patches :) so confbridge lets you set it up so that users record their name and then that gets announced to the conference, but not so that you can have a pre-recorded name attached to a user. |
| 23:23.55 | __sen | you can work around it with AGI that originates a call to the bridge from a local channel and stuff, but it adds a lot of dialplan complexity and is hard to cover the edge-cases for (at least IME so far) and seems needlessly complicated. would a patch to just add a config option for this likely be accepted or not? |
| 23:26.35 | [TK]D-Fender | Not sure how many people this would benifit, and then again, AGI is not required |
| 23:27.26 | [TK]D-Fender | This requires 3 lines of dialplan to actually accomplish |
| 23:50.25 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-mqikgrkxsehyqtxn) |