| 00:14.17 | *** join/#asterisk-dev Dovid (~Dovid@ool-2f113d03.dyn.optonline.net) |
| 01:07.02 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 02:14.39 | *** join/#asterisk-dev Dovid (~Dovid@ool-2f113d03.dyn.optonline.net) |
| 02:18.38 | *** join/#asterisk-dev Dovid (~Dovid@ool-2f113d03.dyn.optonline.net) |
| 03:00.38 | *** join/#asterisk-dev Qwell (north@pdpc/sponsor/digium/Qwell) |
| 03:00.38 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 03:44.25 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 03:44.26 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 08:19.29 | *** join/#asterisk-dev oej (~Adium@62.28.178.18) |
| 08:19.29 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:40.47 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:40.48 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 09:13.02 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 09:17.00 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 09:22.09 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 09:27.41 | *** join/#asterisk-dev danjenkins__ (~dan@nat/digium/x-kiugycbbqryttnsx) |
| 09:48.09 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 10:13.50 | *** join/#asterisk-dev stevePearPear_ (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 10:20.56 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:9c84:7e87:c834:1f53) |
| 10:43.43 | *** join/#asterisk-dev paolo_ (~smuxi@ip-62-143-36-139.unitymediagroup.de) |
| 11:07.04 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 11:07.04 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 11:45.12 | *** join/#asterisk-dev Tim_Toady (~fuzzy@83.212.108.130) |
| 12:11.45 | *** join/#asterisk-dev danjenkins__ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 12:13.15 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:20.59 | *** join/#asterisk-dev Dovid (~Dovid@ool-6bbc29d9.dyn.optonline.net) |
| 12:22.47 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-rrdrspumgatmewqt) |
| 12:22.47 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 12:51.03 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 13:10.08 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 13:12.14 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 13:50.16 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:50.16 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:08.37 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-myowuxbeevuoqrwb) |
| 14:19.09 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 14:22.20 | opticron | would it be reasonable to change the behavior of MoH to not stop/start from the beginning every time ast_moh_start is called and instead just continue if the mohclass hasn't changed? |
| 14:23.19 | opticron | currently, repeated calls to ast_moh_start will cause MoH to stop and then start again |
| 14:23.32 | file | opticron, you mean without a stop? |
| 14:23.37 | opticron | correct |
| 14:23.58 | file | ah - what is doing that? |
| 14:24.40 | opticron | it's possible if a channel driver receives multiple hold control frames |
| 14:25.35 | file | hrm, I wonder if ARI would do the same thing if you called it multiple times to start moh |
| 14:25.46 | file | probably |
| 14:25.53 | opticron | I would also wager probably |
| 14:26.16 | file | in which case yeah - if the mohclass is the same making it a noop sounds fine |
| 14:26.17 | wdoekes | I have a client ticket that complains about MoH restarting whenever a caller is put on hold several times |
| 14:27.30 | mjordan | For some reason, I vaguely recall this issue coming up before. |
| 14:27.50 | opticron | just checked ARI/Stasis, it definitely would do that |
| 14:27.52 | mjordan | but I could be getting mixed up with an issue involving automatically starting/stopping MoH from an AGI |
| 14:29.36 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-bzlbslvgykjvnauh) |
| 14:30.37 | mjordan | Welp, google-foo is failing me |
| 14:30.37 | *** join/#asterisk-dev sgalarneau (~sgalarnea@nat/digium/x-kvxhpkmujometyjt) |
| 14:30.54 | file | mjordan, Google is perfect. |
| 14:30.58 | mjordan | I can't see any benefit to restarting MoH repeatedly if we get duplicate MoH and the class hasn't changed |
| 14:31.18 | opticron | I have a patch that fixes the issue in my testing, but I fear side-effects related to realtime |
| 14:31.44 | file | *gasp* |
| 14:32.39 | mjordan | opticron: how so? |
| 14:33.29 | opticron | there is a LOT of realtime code in the MoH start function and calling ast_moh_start repeatedly could be used as a way to "refresh" things |
| 14:33.54 | opticron | however jarring that would be for the user |
| 14:34.33 | file | I think that's an unintended side effect of calling start multiple times |
| 14:35.55 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 14:36.11 | opticron | I'll post the patch to reviewboard |
| 14:40.01 | rmudgett | opticron: MOH used to resume when MOH was restarted on the same call. It may be an unexpected regression. |
| 14:41.01 | opticron | rmudgett, in this case, ast_moh_stop() is never called in between ast_moh_start() calls |
| 14:47.29 | opticron | posted here: https://reviewboard.asterisk.org/r/3615/ |
| 14:55.04 | file | the realtime code... oh my |
| 14:56.06 | opticron | yeah |
| 15:21.05 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 15:59.53 | pabelanger | Q: what is the difference between ast_manager_event() and manager_event() ? |
| 16:02.18 | mjordan | an ast_? |
| 16:02.20 | mjordan | :-D |
| 16:03.13 | pabelanger | Trying to understand why a Join event in app_queue uses ast_manager_event() but AgentCalled uses manager_event() |
| 16:03.55 | mjordan | pabelanger: what does the manager.h header show for those macros? |
| 16:09.40 | pabelanger | not much, only difference I see in the channel parameter for ast_manager_event(). So, one must be multi-channel events, other just single |
| 16:10.53 | mjordan | well, that's the difference between ast_manager_event and ast_manager_event_multichan |
| 16:10.59 | mjordan | manager_event is not specific to a channel |
| 16:11.25 | mjordan | ast_manager_event should be used when there is a channel involved |
| 16:11.41 | mjordan | True, you can pass NULL (as they all map down to __ast_manager_event_multichan) |
| 16:11.52 | mjordan | But if you're passing NULL as the first argument, you should just use manager_event |
| 16:12.19 | mjordan | or, if you're using Asterisk 12, you shouldn't be calling any of this anyway :-P |
| 16:13.02 | pabelanger | Ya, still hacking on 1.8 right now |
| 16:13.19 | mjordan | four months of life left in the old girl |
| 16:13.44 | pabelanger | but plan to move up to 12 in the coming months, once we test ARI a little more |
| 16:14.03 | mjordan | 6 months of life left in that one... :-P |
| 16:15.02 | pabelanger | Yup, a crap shot right now for ARI stuff. We need to figure out our plan for migrating to it. |
| 16:43.20 | coreyfarrell | so AMI isn't going anywhere right? I mean it will still exist in asterisk 13, 14, 15, etc? |
| 16:43.45 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:46.44 | mjordan | coreyfarrell: correct |
| 16:46.51 | mjordan | in fact, we gave it a lot of love |
| 16:47.18 | mjordan | https://wiki.asterisk.org/wiki/display/AST/AMI+v2+Specification |
| 16:47.40 | coreyfarrell | mjordan: cool, I just misinterpreted your comment "if you're using Asterisk 12, you shouldn't be calling any of this anyway :-P" and had a little panic |
| 16:47.44 | mjordan | You _generally_ shouldn't call manager_event or ast_manager_event unless you are doing so from a stasis subscription thread |
| 16:47.59 | mjordan | as your event may not be ordered with the messages coming from Stasis as you would expect |
| 16:48.26 | mjordan | and there's enough magic sugar in Stasis to make it so that merely defining your message and providing an AMI formatter is generally enough to get it published over AMI as well |
| 16:48.37 | mjordan | so you don't need to manually call the functions that raise the event |
| 16:48.58 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 16:49.31 | mjordan | for example: the events I added for the TALK_DETECT function (coming in 12.4.0) never call manager_event |
| 16:50.25 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 16:56.19 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 17:01.52 | *** join/#asterisk-dev Dovid (~Dovid@static-173-63-105-210.nwrknj.fios.verizon.net) |
| 17:18.02 | leifmadsen | whoever is building 1.8.28.1 right now has rage coming from me towards you! |
| 17:18.14 | leifmadsen | I *just* finished building 1.8.28.0 RPM with our custom patches |
| 17:18.54 | mjordan | ducks and hides |
| 17:19.00 | mjordan | leifmadsen: are you using the HTTP server? |
| 17:19.07 | leifmadsen | I believe not! |
| 17:19.11 | leifmadsen | just AMI |
| 17:19.23 | mjordan | the vulnerability only affects the HTTP server |
| 17:19.29 | leifmadsen | let me see if it is enabled |
| 17:19.39 | leifmadsen | <PROTECTED> |
| 17:19.41 | leifmadsen | sweet |
| 17:19.54 | leifmadsen | it's not *really* that big of a deal, but the timing was impeccable |
| 17:20.13 | mjordan | we aim to please |
| 17:20.18 | Marquis42 | It was perfect, and it made me LOL. :D |
| 17:20.25 | leifmadsen | it sure did... |
| 17:31.07 | coreyfarrell | anyone with the right access to menuselect want to grant me access or just commit https://reviewboard.asterisk.org/r/3599/ ? I don't plan to ever touch that repository again so just a commit would be fine |
| 17:32.14 | mjordan | coreyfarrell: someone here can commit it |
| 17:32.38 | coreyfarrell | mjordan: thanks! |
| 17:43.54 | *** join/#asterisk-dev puzzled (~patrick@puzzled.xs4all.nl) |
| 17:44.04 | puzzled | hi |
| 17:45.15 | puzzled | oej: guess OT for this chan but re your tweet: what did you exactly mean with a phone reregistering? Can't figure out how I could test that. |
| 18:16.42 | *** join/#asterisk-dev Marquis42 (~mrbmw@d149-67-95-208.try.wideopenwest.com) |
| 18:21.58 | *** part/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 18:29.33 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 18:31.33 | *** join/#asterisk-dev sgalarneau (~sgalarnea@nat/digium/x-ofbqjyjuxbtbudzw) |
| 18:35.39 | oej | Hi! |
| 18:36.26 | oej | A phone that sets up a tcp connection needs to tell the server that it has a new connection by registering. If the connection fails and the phone reconnects, but from a different port, the old registration is invalid. The phone thus needs to re-register. |
| 19:03.14 | *** join/#asterisk-dev opticron (~opticron@pianoben.ch) |
| 19:03.14 | *** mode/#asterisk-dev [+o opticron] by ChanServ |
| 19:03.49 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-qqepjfxwmnaboxna) |
| 19:07.33 | *** join/#asterisk-dev moy (~moy@UNVLON55-1176057127.sdsl.bell.ca) |
| 19:20.44 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 19:24.14 | puzzled | oej: got it, thanks. CSipSimple on Android reregisters a ton when I change its config so I'll have a look |
| 20:38.21 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-wqaqkemprczsbbvg) |
| 20:38.21 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 20:59.38 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 21:06.59 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 21:16.44 | gtjoseph | rmudgett: will you have time today to look at https://reviewboard.asterisk.org/r/3593/ |
| 21:32.22 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 21:48.13 | opticron | anyone feel like reviewing a test? https://reviewboard.asterisk.org/r/3560/ |
| 22:01.09 | putnopvut | I've got some really screwy stuff going on in the testsuite right now. I'm trying to write a dead-simple test that makes use of the TestCaseModule to start Asterisk, the Originator module to do a call, and the HangupMonitor module to stop the test. The problem is that AMI seems to be a bit out of sync. |
| 22:01.25 | putnopvut | Here is the full.txt from the previous run I made: http://ur1.ca/hin13 |
| 22:02.49 | putnopvut | Notice on line 14, we see the "Connection Made" message. Then on line 15, we send our login action. On line 16, we receive the "Asterisk Call Manager/2.3.0" message. There's a 30 second gap, and then we see the Success response to the authentication. |
| 22:03.08 | file | weird... |
| 22:03.10 | putnopvut | AFAIK, I'm not doing anything goofy here since I'm just using pre-existing test modules. |
| 22:05.16 | putnopvut | And here's the test-config.yaml, in case you're curious: http://ur1.ca/hin2j |
| 22:06.05 | sgriepentrog | putnopvut: did you just install fresh asterisk? Maybe something in the socket handling is glitching ami? |
| 22:06.25 | putnopvut | sgriepentrog: I updated by 12 branch and installed. It's not a fresh checkout though. |
| 22:07.13 | sgriepentrog | I was thinking that Richard's socket handling changes could have had an affect on ami. |
| 22:07.27 | putnopvut | I can try backing that out and see if it makes a difference. |
| 22:07.37 | putnopvut | I wonder if mjordan's careful write changes made it in, too? |
| 22:08.08 | putnopvut | I don't think they have, though, since I don't think they've been reviewed. |
| 22:13.05 | mjordan | no, and those are websocket only |
| 22:13.14 | putnopvut | okay |
| 22:13.21 | mjordan | the AMI socket already uses careful write |
| 22:13.31 | putnopvut | jus' doin' a recompile after backing out r415896. Trying to see if it makes a difference. |
| 22:27.21 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 22:33.39 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-myowuxbeevuoqrwb) |
| 23:46.28 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 23:46.40 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |