| 00:17.11 | *** join/#asterisk-dev dms1 (~dms1@ip-64-134-185-38.public.wayport.net) |
| 00:22.47 | *** join/#asterisk-dev leifmadsen (~free-mads@asterisk/documenteur-extraordinaire/blitzrage) |
| 00:22.47 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 00:51.07 | *** join/#asterisk-dev GameGamer43 (sid5533@gateway/web/irccloud.com/x-drvsitxhuwhhpnbt) |
| 00:55.35 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 02:36.33 | *** join/#asterisk-dev stevePearPear (~stevePear@202.166.82.164) |
| 03:05.31 | *** join/#asterisk-dev tzafrir (~tzafrir@host-201-37.pubnet.pdx.edu) |
| 03:05.31 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 04:01.33 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 04:02.41 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 05:03.05 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 05:03.27 | *** join/#asterisk-dev stevePearPear (~stevePear@203.126.171.206) |
| 05:17.30 | *** join/#asterisk-dev tzafrir (~tzafrir@host-201-37.pubnet.pdx.edu) |
| 05:17.30 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 05:51.19 | *** join/#asterisk-dev tzafrir (~tzafrir@host-201-37.pubnet.pdx.edu) |
| 05:51.19 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 06:02.17 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 06:12.46 | *** join/#asterisk-dev stevePearPear (~stevePear@202.166.82.164) |
| 06:18.24 | *** join/#asterisk-dev Sjors (~sgielen@foo.kassala.de) |
| 06:55.10 | wdoekes | pabelanger: "bind RTP listen sock [...] is *disabled*" ? my emphasis |
| 07:13.20 | *** join/#asterisk-dev stevePearPear (~stevePear@202.166.82.164) |
| 07:16.05 | *** join/#asterisk-dev oej (~Adium@h217-27-188-82.cust.tyfon.se) |
| 07:16.06 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:48.54 | skrusty | good news on the unimrcp front! |
| 07:54.54 | oej | Yes, really! |
| 09:17.07 | *** join/#asterisk-dev tzafrir (~tzafrir@host-201-37.pubnet.pdx.edu) |
| 09:17.07 | *** join/#asterisk-dev hexanol (~bibi@modemcable094.94-70-69.static.videotron.ca) |
| 09:17.07 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 09:17.07 | *** mode/#asterisk-dev [+o tzafrir] by weber.freenode.net |
| 09:26.11 | *** join/#asterisk-dev Qwell (north@asterisk/developer/Qwell) |
| 09:26.11 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 09:30.16 | *** join/#asterisk-dev oej (~Adium@h217-27-188-82.cust.tyfon.se) |
| 09:30.16 | *** join/#asterisk-dev jrose_atDigium (~jrose@nat/digium/x-swsqftqnlsqoagnp) |
| 09:30.16 | *** join/#asterisk-dev mbowie (~mbowie@162.212.36.9) |
| 09:30.16 | *** join/#asterisk-dev moy (~moy@198.199.91.192) |
| 09:30.16 | *** join/#asterisk-dev datachomper (~russ@nat/digium/x-ldwofqimvvzbrxev) |
| 09:30.16 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 09:30.16 | *** mode/#asterisk-dev [+oo oej malcolmd] by weber.freenode.net |
| 09:51.34 | *** join/#asterisk-dev coreyfarrell (~coreyfarr@2001:4830:117f:2:4567:b608:7895:d1b0) |
| 09:51.36 | *** join/#asterisk-dev russellb (~russellb@redhat/russellb) |
| 09:51.36 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 10:14.24 | *** join/#asterisk-dev ivan` (~ivan@unaffiliated/ivan/x-000001) |
| 10:16.49 | *** join/#asterisk-dev stevePearPear (~stevePear@202.166.82.164) |
| 10:26.32 | *** join/#asterisk-dev seanbrig1t (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 10:26.32 | *** mode/#asterisk-dev [+o seanbrig1t] by ChanServ |
| 10:27.00 | *** join/#asterisk-dev dms1 (~dms1@ip-64-134-185-38.public.wayport.net) |
| 10:48.38 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 10:48.38 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 10:56.04 | *** join/#asterisk-dev zerohalo (~zerohalo@2601:6:f80:224:6b:72f1:84e4:14a5) |
| 10:56.49 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 10:58.15 | *** join/#asterisk-dev dwayne (~dwayne@c-71-207-208-112.hsd1.al.comcast.net) |
| 11:02.29 | *** join/#asterisk-dev wdoekes (~walter@wjd.osso.nl) |
| 11:03.34 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 11:03.34 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 11:13.18 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 11:13.29 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 11:14.40 | *** join/#asterisk-dev skrusty (~skrusty@168.63.14.171) |
| 15:50.43 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 15:50.43 | *** 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-beta1 now released. Do the (beta) release dance! -=- Follow on Twitter at @AsteriskDev |
| 16:18.11 | mjordan | gtjoseph: ignoring the heresy of users.conf, I'd say making it pull its SIP settings from either sip.conf or pjsip sorcery is probably appropriate |
| 16:18.41 | mjordan | gtjoseph: you could always put the "SIP source" in phoneprov.conf, and default to sip.conf in order not to break people |
| 16:18.49 | gtjoseph | yep. i'm writing something up for the mailing list. |
| 16:27.28 | *** join/#asterisk-dev tzafrir (~tzafrir@host-200-120.pubnet.pdx.edu) |
| 16:27.28 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 17:32.18 | mjordan | rmudgett: remember how we were talking about CDRs and needing to know when they were in a macro or subroutine? |
| 17:32.28 | mjordan | or rather, a macro or subroutine that was executing from within an application? |
| 17:32.39 | rmudgett | mjordan: yes |
| 17:32.46 | mjordan | rmudgett: it's worse than I feared |
| 17:33.04 | mjordan | when I looked at the CDR code, I had already put in a hack that prevented updates mid-Dial from screwing up the records |
| 17:33.18 | mjordan | so the reason why people are getting CDRs that look ugly have nothing to do with the U/M/b/B options |
| 17:33.28 | mjordan | it's that they are executing the Dial from within a GoSub or Macro |
| 17:33.41 | mjordan | and they don't want that extension to show up in the record, they want the "real" PBX extension to be in the record |
| 17:34.21 | mjordan | I can still fix that (not super hard, just more annoying) - but given the previous 'options', I'm not sure a channel flag is the best way still. It probably is, just wondered if you had any other thoughts on it |
| 17:36.22 | rmudgett | Well how many nesting levels of macro/gosub would they consider a "real" PBX extension or should it only be the top dialplan level regardless of nesting level. |
| 17:37.33 | mjordan | rmudgett: as long as you are in a subroutine/macro, you count |
| 17:37.46 | mjordan | rmudgett: right now, I'm caching the original value and restoring it as it pops back out of the stack |
| 17:38.21 | rmudgett | They want the DNID value instead? That value is supposed to be what was dialed by the caller on an inbound channel. |
| 17:38.44 | mjordan | nope |
| 17:38.52 | mjordan | it literally is the extension from the dialplan that they want |
| 17:39.20 | rmudgett | The initial extension and no other. |
| 17:40.45 | rmudgett | Start executing dialplan at c/e/p. CDR only remembers the initial c/e/p. |
| 17:41.01 | mjordan | yup |
| 17:41.21 | mjordan | but we have to know in the CDR engine - based on a channel snapshot - whether or not we are lurking in a Macro or GoSub (regardless of how they were invoked) |
| 17:41.36 | mjordan | since the functions in app.c end up calling into the implementations, it pretty much has to be handled in app_stack and app_macro |
| 17:42.51 | rmudgett | How does that come into play when the CDR only needs to remember the first exten seen. |
| 17:46.51 | mjordan | a GoTo would not be subject to that idea |
| 17:47.01 | mjordan | if I start off in 1000, and Goto 2000, we need to update |
| 17:47.12 | mjordan | if I start off in 1000, but subroutine to dial_this_thing, I need to not update |
| 17:47.31 | mjordan | CDRs: making the world shitty since 1999 |
| 17:47.37 | file | the position within the dialplan has not changed, the fact that dialplan is used to implement such a thing is a detail of that |
| 17:47.49 | file | (to an outside observer) |
| 17:47.51 | mjordan | file: pretty much |
| 17:48.13 | mjordan | I did discover that there was CDR code in 1.8/11 to handle this in Macros, but not GoSubs |
| 17:48.23 | mjordan | but I am not going to attempt to "fix" this there |
| 17:48.52 | rmudgett | Heck no. CDRs pre 12 are no touchy |
| 17:49.59 | mjordan | I'll see what the channel flag buys me |
| 17:50.06 | mjordan | I can't think of a better way to inform the engine |
| 17:50.11 | mjordan | more Stasis messages just feels bad |
| 17:50.34 | mjordan | Particularly when we are already publishing the crap out of the channel at this point in the code anyway |
| 18:07.17 | mjordan | wow. That was way too easy. |
| 18:07.29 | mjordan | is concerned when things with CDRs work on the first try |
| 18:09.40 | blitzrage | must be broken for an edge case |
| 18:14.13 | mjordan | it *has* to, right? |
| 18:14.23 | mjordan | is checking hangup handlers now |
| 18:14.25 | blitzrage | people still use CDR? |
| 18:14.30 | mjordan | blitzrage: I know, right? |
| 18:14.55 | blitzrage | seriously though, I would be interested in discussing at astridevcon a much scaled back Asterisk in the future that didn't use the "old and busted" |
| 18:15.16 | blitzrage | almost like a divide where asterisk decides to get serious :) |
| 18:15.20 | mjordan | blitzrage: it's always what constitutes "old and busted" to people |
| 18:15.32 | blitzrage | things that are not new |
| 18:15.34 | blitzrage | :) |
| 18:15.37 | Marquis42 | haha |
| 18:15.53 | mjordan | we've shed a lot of cruft.. but as someone who had to re-write CDRs, yes. |
| 18:16.06 | mjordan | At the same time, it's more about: what is holding us back? |
| 18:16.17 | blitzrage | but basically anything that isn't the "preferred" way to handle things. For example, you want call information? Use CEL. That's all you get. CDRs were removed. |
| 18:16.22 | blitzrage | that is true |
| 18:16.22 | mjordan | if we spend very little time in Macro, or CDRs (in the future), or Monitor, then I'm kind of ambivalent |
| 18:16.39 | mjordan | eyes chan_sip |
| 18:16.42 | blitzrage | pretty much |
| 18:17.12 | blitzrage | I would be almost of the opinion that there is a version of Asterisk that contains what is there now, and a version that continues forward with a much scaled back code base |
| 18:17.22 | mjordan | I think that's called a "fork" |
| 18:17.43 | blitzrage | I just built a new RPM of Asterisk 13 that removed almost everything except stasis, dial, ami, agi, and dialplan parsing |
| 18:18.01 | Marquis42 | Why did you need dial? :P |
| 18:18.02 | mjordan | I had this discussion the other day with someone else as well: a large part of the problem is not conveying what the "right" way to deploy Asterisk is |
| 18:18.43 | blitzrage | I'd prefer to see this "core" version of asterisk that had very little packaged with it other than the "engine" then provide as much third party applications as possible (community driven or otherwise) that tied into asterisk via API land |
| 18:18.46 | blitzrage | Marquis42: I don't know! :) |
| 18:18.52 | blitzrage | I thought we needed it, maybe we don't |
| 18:19.07 | Marquis42 | Nope |
| 18:19.14 | blitzrage | fuck, I added too much code :) |
| 18:19.27 | Marquis42 | Not that it's a big deal, we're still learning what the minimalist setup is for using Asterisk purely with ARI apps. But yeah. |
| 18:19.33 | blitzrage | yep for sure |
| 18:19.41 | blitzrage | it's easy enough to build a new RPM |
| 18:19.48 | Marquis42 | yup |
| 18:19.49 | mjordan | blitzrage: I don't disagree |
| 18:19.50 | blitzrage | <3 mock |
| 18:20.18 | blitzrage | anyways, I'm mostly just thinking out loud on Friday of a long weekend while drinking this adult beverage |
| 18:20.34 | file | yeah you can't replace Dial in ARI, yet |
| 18:20.35 | Marquis42 | You're doing it right. |
| 18:20.39 | blitzrage | I would certainly love to see a build of asterisk that was pretty much solely pjsip + ARI |
| 18:20.48 | blitzrage | Marquis42: a ha! |
| 18:20.48 | Marquis42 | file: What's missing in ARI? |
| 18:20.57 | mjordan | early bridge |
| 18:20.57 | Marquis42 | stops talking so file can teach |
| 18:20.59 | file | originating blocks until answer, so you can't bridge early and exchange early media |
| 18:21.05 | Marquis42 | oic |
| 18:21.09 | blitzrage | what could go wrong? |
| 18:22.07 | blitzrage | well Marquis42 and I are playing around right now with a stripped down Asterisk 13 and Go to determine what "minimal" means, and what we need to primarily control Asterisk and write applications entirely outside of Asterisk itself |
| 18:22.21 | blitzrage | so maybe by astricon we'll have a better idea of what that means |
| 18:22.30 | Marquis42 | One hopes :) |
| 18:22.35 | blitzrage | we don't have any of those pesky customers to get in the way right now |
| 18:22.43 | Marquis42 | We have like two months, we'll be experts by then right? :D |
| 18:23.06 | blitzrage | Marquis42: I assume we'll have rebuilt all the apps we care about by then |
| 18:23.07 | blitzrage | :D |
| 18:23.17 | blitzrage | keeps drinking this beer |
| 18:23.30 | blitzrage | looks at pabelanger |
| 18:23.33 | mjordan | blitzrage: as you run into oddities, please toss them at us |
| 18:23.43 | blitzrage | mjordan: for sure will do |
| 18:23.53 | mjordan | sgalarneau (who isn't in here, nuts) and I have been writing some simplistic apps, and we've hit a few minor bugs along the way |
| 18:24.16 | blitzrage | it's good you're writing some apps, even just to understand what you've done wrong :) |
| 18:24.17 | Marquis42 | Wait, are you implying there's bugs in Asterisk? |
| 18:24.18 | mjordan | should have it all flushed out for 13, but definitely wouldn't want you blocked or working around something that was a little broken |
| 18:24.27 | mjordan | Marquis42: careful now, VicKilla may be in here. |
| 18:24.30 | Marquis42 | :D |
| 18:24.38 | blitzrage | mjordan: we'll let you know when we run into some :) |
| 18:24.39 | pabelanger | blitzrage, huh? |
| 18:24.51 | blitzrage | pabelanger: oh I was commenting on having all the asterisk apps we care about written by astricon |
| 18:24.56 | Marquis42 | One thing I do wish is that the JSON formats were slightly different. But they're not awful, and you can't really change them now (at least in 13). |
| 18:25.00 | blitzrage | I was kind of trolling you |
| 18:25.08 | pabelanger | blitzrage, sounds about right |
| 18:25.13 | mjordan | There's a number of small inconsistencies. |
| 18:25.23 | mjordan | I'm all for creating a list of what should be changed in a major rev bump |
| 18:25.27 | blitzrage | pabelanger: re-writing app_queue in ARI while it is being developed? How hard could it be?! |
| 18:25.33 | mjordan | I just don't want to do a small change, have to bump the major rev in 14, then miss something else |
| 18:25.39 | blitzrage | mjordan: I'll just provide you the output of menuselect.makeopts |
| 18:25.44 | pabelanger | blitzrage, trivial |
| 18:25.48 | Marquis42 | IMHO there should be an outer "event" format and then a "body" that contains the event-specific infoz. |
| 18:26.04 | blitzrage | Marquis42: so that Message.JSON will work in Go? :) |
| 18:26.15 | Marquis42 | :D |
| 18:36.53 | putnopvut | Here's a fun race-condition-like thing that I've just diagnosed. http://ur1.ca/i2vuf The tl;dr version is that some intermediary device state changes don't end up reaching extension state watchers. |
| 18:49.09 | blitzrage | booooo |
| 18:49.17 | blitzrage | I never like bugs in event state stuff |
| 19:00.14 | mjordan | yeah, I think it's a bug, but not one that we can point to and say "it breaks this". Generally, things want the aggregate state (which will be correct), even if they miss a few updates in between. So it's a fix it, but probably not scramble crazy on it |
| 19:06.20 | rmudgett | It looks like the cure is worse than the problem. |
| 19:07.51 | mjordan | maybe |
| 19:08.18 | mjordan | I think the pbx core is a little nutty in calling ast_device_state for all other devices when it gets a device state change. |
| 19:08.33 | mjordan | So long as it actually receives all device state changes via events (from Stasis), there's no reason to re-query the other states |
| 19:09.00 | mjordan | the hints in the pbx core would have to be changed to store more than the aggregate |
| 19:09.31 | mjordan | so there's some shifting of logic here and there, and a bit more work in pbx. But it is a bit scary, because if for some reason a device state change *didn't* update Stasis, we'd end up with the wrong state |
| 19:09.43 | mjordan | so it's probably not worth touching right now until we can deep dive into it |
| 19:48.35 | *** join/#asterisk-dev tzafrir (~tzafrir@host-200-120.pubnet.pdx.edu) |
| 19:48.35 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:24.26 | file | SO I just did the biggest hurdle for Dial in ARI - the ability to have an originated channel execute despite not being answered |
| 20:24.35 | Marquis42 | \m/ |
| 20:25.45 | blitzrage | oic! |
| 20:25.56 | blitzrage | file: you were being bothered by this weren't you? :) |
| 20:26.02 | file | blitzrage, it's been on my list |
| 20:26.12 | blitzrage | always good to have a list |
| 20:26.29 | file | needs more cilantro, though |
| 20:26.41 | blitzrage | I like cilantro, but you can easily over do it |
| 20:27.35 | Marquis42 | lol |
| 20:27.43 | mjordan | it is the dark side of flavors |
| 20:30.48 | file | and it seems as though early bridging by just throwing things in a bridge works, indications pass... media passes... answer occurs |
| 20:31.34 | Marquis42 | oooh, nice |
| 20:46.58 | file | tone detection was the last thing on the list I kept from awhile ago for ARI, but meh |
| 20:48.58 | *** join/#asterisk-dev tzafrir (~tzafrir@host-200-120.pubnet.pdx.edu) |
| 20:48.58 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 21:13.08 | skrusty | evening all |
| 21:35.28 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 21:44.33 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 21:49.18 | *** join/#asterisk-dev terryw (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 21:51.55 | *** join/#asterisk-dev moy_ (~moy@198.199.91.192) |
| 22:02.55 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 22:02.55 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 22:03.01 | gtjoseph | rmudgett: or anyone can you give quick reviews to r3955 and r3958? They're only a few lines each and I want to clean them out of my working copy. |
| 22:03.03 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-zymcdvsmjlfrbees) |
| 22:03.03 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 22:03.05 | *** join/#asterisk-dev datachomper (~russ@nat/digium/x-rgrnemlhdlkgetcf) |
| 22:07.26 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 22:11.28 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 22:11.28 | *** join/#asterisk-dev dwayne (~dwayne@c-71-207-208-112.hsd1.al.comcast.net) |
| 22:14.11 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 22:20.24 | gtjoseph | rmudgett: AnswerTime implies it's an absolute time. It really is a duration since answered. |
| 22:22.04 | rmudgett | gtjoseph: Dial and FollowMe set the channel variable ANSWEREDTIME with that value. |
| 22:22.16 | rmudgett | So AnsweredTime |
| 22:22.44 | gtjoseph | meaning "how long it's been since it was answered"? Ok. |
| 22:24.02 | rmudgett | Duration just doesn't make sense as how long a call has been in the confbridge when it is since the channel was answered. |
| 22:26.10 | gtjoseph | rmudgett: Maybe but AnsweredTime implies an absolute time not the number of seconds since the channel was answered. But ok. I'm changing it. |
| 22:27.49 | rmudgett | I'm just going by precedence. The only two callers of ast_channel_get_up_time() are app_dial and app_followme and they both set the channel variable ANSWEREDTIME with that value. |
| 22:28.39 | gtjoseph | nuff said. :) |
| 22:40.48 | gtjoseph | rmudgett: thanks for looking at those review on a Friday afternoon! |
| 22:41.09 | rmudgett | :) |
| 22:48.35 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 22:53.58 | *** join/#asterisk-dev tzafrir (~tzafrir@host-200-120.pubnet.pdx.edu) |
| 22:53.58 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 23:16.36 | *** join/#asterisk-dev dms1 (~dms1@2601:0:5480:e4::1008) |