| 00:26.35 | snuff-work | minor win.. no errors for missing doc from res_sip.. now to make it have 'real doco' later on |
| 02:46.52 | *** part/#asterisk-dev TysonBrooks (~TysonBroo@c-76-23-24-235.hsd1.ut.comcast.net) |
| 05:52.05 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 05:52.06 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:09.23 | wedhorn | snuff-work: not much on the skinny front this week |
| 07:23.12 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.36.36) |
| 08:49.23 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:9561:f3b7:eedc:79bd) |
| 09:07.37 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:9561:f3b7:eedc:79bd) |
| 11:37.13 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 11:48.06 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 11:48.07 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:34.54 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-riqmhfeljhlxcxbd) |
| 12:34.54 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 12:54.14 | snuff-home | wedhorn: nope.. busy busy on stuff with our mail migration to gmail apps.. sick on monday/tuesday with gastro bug |
| 12:55.12 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-dhgzfunznjujoukl) |
| 13:45.17 | *** join/#asterisk-dev dwayne (~dwayne@c-71-207-208-112.hsd1.al.comcast.net) |
| 13:48.57 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 13:51.02 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 13:51.02 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 13:55.27 | wdoekes | leedm777, Qwell: https://reviewboard.asterisk.org/r/2304/ |
| 13:55.40 | leedm777 | looking |
| 13:55.54 | wdoekes | tnx |
| 14:12.14 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 14:12.15 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:18.29 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.36.36) |
| 14:30.46 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:30.46 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:22.21 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 15:45.14 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 15:45.14 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:55.12 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 15:55.13 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:22.50 | mjordan | opticron: leedm777: in an ast_channel_snapshot, we only convey the context/exten of the channel in the dialplan. Should that also convey the macro context/exten? |
| 17:22.59 | mjordan | or do we want to bite the bullet and simply say "macros are deprecated"? |
| 17:24.58 | opticron | that's the direction I was leaning by not including them in the snapshot |
| 17:25.43 | leifmadsen | +1 |
| 17:25.53 | leifmadsen | GoSub ftw |
| 17:26.06 | leifmadsen | unless you're talking internal C code macros :) |
| 17:26.23 | mjordan | I'm not :-) |
| 17:26.33 | leifmadsen | ya, using GoSub() in 1.8 a bunch now |
| 17:26.49 | leifmadsen | don't even bother with Macro() any more, and haven't for a couple years now |
| 17:27.15 | leifmadsen | except for where the parts still existed that didn't provide the GoSub() method in addition to Macro, but that has been cleared up as of at least Asterisk 11 or something I believe. |
| 17:27.21 | mjordan | it has. |
| 17:27.25 | mjordan | Except for AEL. |
| 17:27.26 | leifmadsen | I think that was the only reason we hadn't deprecated it prior to that |
| 17:27.30 | leifmadsen | pffft. AEL. |
| 17:27.32 | leifmadsen | Deprecate AEL too. |
| 17:27.37 | leifmadsen | problem solved! :) |
| 17:27.45 | mjordan | well, it kind of is-ish. |
| 17:27.47 | leifmadsen | it's not maintained right? |
| 17:27.53 | leifmadsen | like not on the core list? |
| 17:27.53 | mjordan | define "maintained" |
| 17:27.57 | mjordan | it is not on the core list |
| 17:28.09 | leifmadsen | extended right? |
| 17:28.25 | leifmadsen | well I guess so if it's not officially on the deprecated list :) |
| 17:28.34 | leifmadsen | deprecated in favour of pbx_config.so? :) |
| 17:31.48 | mjordan | heh. Probably just maintain on extended |
| 17:32.01 | mjordan | the real 'problem' is that things built on stasis-core are not going to convey macro context/extensions |
| 17:32.14 | mjordan | so ... AMI won't report in a NewExten event that a channel is in a macro context/exten |
| 17:32.16 | mjordan | or CDRs |
| 17:32.25 | mjordan | they'll report the original dialplan location |
| 17:32.39 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 17:32.39 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 17:33.43 | WIMPy | So you get NewExtens with the same location for all priorities in the macro? |
| 17:33.53 | mjordan | possibly |
| 17:34.21 | WIMPy | Could even be usefull to know the original extension :-) |
| 17:34.57 | WIMPy | doesn't really care. Just being curious. |
| 17:54.24 | opticron | actually, you just wouldn't get newextens |
| 17:54.57 | opticron | since they're based exclusively on the context/exten/priority changing |
| 17:56.07 | WIMPy | A comparison? Not being done when the next priority is found/executed? |
| 17:56.58 | opticron | reworked to be generated from channel state messages, it can only see the difference between messages |
| 17:57.09 | opticron | if there is no difference in CEP, there will be no message sent |
| 18:00.04 | opticron | there are a few messages that get their own type like you're thinking, but those are the exception rather than the rule |
| 18:06.24 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 18:06.24 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 18:31.57 | leedm777 | is back |
| 18:32.13 | opticron | \o/ |
| 18:36.21 | leedm777 | mjordan: so I've looked at exactly 0 lines of the macro code. So as the macro executes, the context/exten/priority of the channel doesn't change? In 11, would you still get NewExten events? |
| 18:48.50 | mjordan | leedm777: correct about macros. There's a separate set of context/exten fields on a channel that tracks the location of the channel in a macro |
| 18:49.19 | mjordan | Asterisk in many places will determine whether or not the channel is in a macro by first looking at the macrocontext/exten and only use the dialplan locations if those are empty |
| 18:49.32 | leedm777 | funness |
| 18:49.37 | mjordan | not really :-) |
| 18:50.03 | mjordan | Not sure whether or not the NewExten event fires when a channel changes its location in a macro; however, CDRs attempt to record the location of a channel based on the macro location |
| 18:52.08 | leedm777 | Okay; is it important to know that you're in a macro? Shouldn't the CEP in the snapshot be the location in the current macro? |
| 18:56.42 | opticron | I just looked through asterisk 11 code and it doesn't appear that macroexten is ever used when generating Newexten events |
| 18:57.17 | opticron | so it probably saves off the current CEP and then restores it later |
| 18:58.45 | opticron | looking at app_macro, that's exactly what it does |
| 18:59.36 | opticron | so it'll probably generate Newexten events just fine for macro calls |
| 19:00.13 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 19:00.13 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 19:09.04 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 19:09.07 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 19:10.15 | mjordan | hm. |
| 19:11.21 | mjordan | This feels like a "we'll see". There's a lot of places that do a lot of checking for the presence of the macrocontext/macroexten, and I have a feeling you aren't guaranteed that those two values equal a context/exten on a channel. It's possible that was changed at some point, but that's a bit surprising |
| 19:27.49 | mjordan | opticron: how blocked are you on needing the Stasis dial messages? |
| 19:28.07 | opticron | not that blocked for the dial stuff |
| 19:28.20 | opticron | for me it's more the stasis-app branch |
| 19:28.35 | mjordan | the multi channel blob? |
| 19:28.45 | opticron | though I do need to get the stasis-channel_events-take2 branch up for review |
| 19:29.07 | mjordan | well, I'd prefer to wait until Saturday to commit - 24 hours and what not |
| 19:29.19 | opticron | yeah, that's fine for the dial stuff |
| 19:29.22 | mjordan | so I guess unless you need it this afternoon, I'll hold off |
| 19:29.22 | mjordan | kk |
| 19:30.02 | opticron | and when that goes in, I'll have to do a little more work on stasis-channel_events-take2 |
| 19:30.26 | opticron | shouldn't be much, though |
| 19:31.13 | *** join/#asterisk-dev moy_ (~moy@173.239.155.74) |
| 19:39.36 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 19:47.05 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 19:47.10 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 21:01.32 | sruffell | leedm777: lol 'Allowing anonymous reviews would be… well, let's just say there's a reason why we can't have nice things on the Internet.' |
| 21:03.02 | leifmadsen | :) |
| 21:04.05 | leedm777 | All true. |
| 21:59.14 | *** join/#asterisk-dev Greenlight (~email@cpc1-dund9-0-0-cust142.16-4.cable.virginmedia.com) |
| 22:24.43 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-riqmhfeljhlxcxbd) |
| 22:45.21 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-tfkyjpcqduoxdftz) |