| 00:03.41 | *** join/#asterisk-dev goddva (~goddva@2a02:fe0:c510:f3a1:ae9e:17ff:fe91:a8c9) |
| 00:12.37 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 01:26.54 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-eeimegvwlrytjkek) |
| 02:15.07 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 02:18.09 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 02:18.09 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 05:02.27 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-oecmpoxploquenpx) |
| 05:25.46 | *** join/#asterisk-dev doome (~doome@82.150.48.146) |
| 06:43.36 | *** join/#asterisk-dev russellb (~rustlebee@redhat/russellb) |
| 06:43.36 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 06:43.38 | *** join/#asterisk-dev TazzNZ (~TazzNZ@office-nat1.ytechops.co.nz) |
| 06:54.02 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 07:32.51 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 07:37.20 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:37.20 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:29.15 | stefan27 | Hello coreyfarrell |
| 08:32.56 | stefan27 | Or Joshua Colp if he uses IRC |
| 08:57.57 | coreyfarrell | hello |
| 09:00.33 | coreyfarrell | stefan27: whats up? |
| 09:01.13 | stefan27 | Within the new gerrit review system. If i have created a commit that was pushed up with 'git review -t ASTERISK-24832 13'. How do i push changes to that commit? is it: <edit file>; git commit --amend; git review -t ASTERISK-24832 13; ? |
| 09:01.46 | coreyfarrell | you got it |
| 09:02.18 | coreyfarrell | obviously assuming you start from your branch that you have the change in |
| 09:03.16 | coreyfarrell | it'll work as long as you don't modify or remove the 'Change-Id' line |
| 09:03.42 | coreyfarrell | that's important for gerrit to know you're updating the existing review instead of creating a new one |
| 09:04.21 | stefan27 | without --amend, git creates new change-id? |
| 09:06.16 | coreyfarrell | without --amend git creates a new commit, so yes. when you --amend the Change-id is already in the commit msg, so as long as you leave it alone you don't get a new one. |
| 09:14.40 | stefan27 | OK, thanks for the git lessons btw. More important question: Who's supposed to make https://gerrit.asterisk.org/#/c/490 ready for real commit (if ever). Me or you? Should the process really be you commenting on the changes and me responding to comments by suggesting new changes? I mean sure most of the comments you made are easy to address but I don't understand what exact change Joshua |
| 09:14.40 | stefan27 | would want done based on his comments on line 1631 |
| 09:16.20 | stefan27 | Moreover, my patch is empirical. I don't know _why_ it works |
| 09:16.55 | stefan27 | except on a very high level |
| 09:20.19 | coreyfarrell | the way review works is people make comments on the change, you update the patch. sometimes it goes back and forth until there is agreement on what should be merged. after you get +1 someone with merge rights will +2 the change, and it becomes part of asterisk. |
| 09:20.28 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 09:20.28 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 09:20.45 | stefan27 | aha |
| 09:21.15 | stefan27 | so i need to ask Joshua what exact code-change he wanted? |
| 09:21.15 | stefan27 | does he use IRC |
| 09:25.40 | coreyfarrell | his alias is file. |
| 09:27.45 | coreyfarrell | something I didn't think of looking at the review the other day, it might be better to fix this from inside dtls_perform_handshake. |
| 09:28.22 | stefan27 | OK, but another question: when ast_rtp_on_ice_complete is called; can (rtp->dtls.dtls_setup == AST_RTP_DTLS_SETUP_ACTPASS) || (rtp->rtcp && rtp->rtcp->dtls.dtls_setup == AST_RTP_DTLS_SETUP_ACTPASS) ever be true? |
| 09:29.18 | stefan27 | in my first version of the patch i checked this in a while loop... I thought there was a race between the calling of this channel and the "chan_sip"-invoked call to dtls_set_setup |
| 09:29.41 | coreyfarrell | I have no idea, I'm not that familiar with the RTP code.. |
| 09:30.01 | stefan27 | in my first version of the patch i checked this in a while loop... I thought there was a race between the calling of this function (ast_rtp_on_ice_complete) and the "chan_sip"-invoked call to dtls_set_setup() which sets the DTLS_setup state? |
| 09:31.23 | stefan27 | I also made the assumption that the rtp->rtcp.dtls_setup can only be passive if and only if the rtp->dtls_setup is passive, is that a bad assumption? |
| 09:33.36 | coreyfarrell | I think it is, that's why I commented that you should check rtp->rtcp.dtls_setup separately |
| 09:34.01 | stefan27 | dtls_perform_handshake is called from two functions in res_rtp_asterisk.c ast_rtp_activate and ast_rtp_on_ice_complete |
| 09:37.40 | stefan27 | if the calling of ast_rtp_on_ice_complete is in no way synchronized with setting the state of either rtp->rtcp->dtls.dtls_setup OR rtp->dtls.dtls_setup , then my code has issues even if we check the state of the rtcp->dtls.dtls_setup in a different if-block? |
| 10:04.28 | file | it should be only passive or active at that time I think |
| 11:20.25 | stefan27 | I can't trace out the process... is the ice candidates gathering process always started (we never know when it completes after it started?) after chan_sip has received sdp and called dtls_set_setup() ? If it's not impossible that the dtls-state is still ACTPASS upon the ice completion, then what should we do in that code if the state indeed is ACTPASS at that point. I thought it should |
| 11:20.25 | stefan27 | sleep until it becomes active or passive. |
| 11:23.07 | file | our ice candidates gathering process is started before we send an INVITE or 200 OK because we don't do trickle |
| 11:23.17 | file | the ICE negotiation completes sometime after SDP negotiation completes |
| 11:23.23 | file | and SDP negotiation is what determines the setup value |
| 11:24.33 | file | so by the time DTLS negotiation begins, the setup should be determined |
| 11:32.31 | file | bbs - dog walk time |
| 11:32.53 | stefan27 | Hmm, but in process_sdp in the loop while ((type = get_sdp_line(&iterator, next - 1, req, &value)) != '\0') { ... } is it not possible that the loop has called 'process_sdp_a_ice()' one or more times before calling process_sdp_a_dtls(). Could that not cause ast_rtp_ice_on_complete to fire before calling process_sdp_a_dtls? |
| 11:33.57 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 11:33.57 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 11:34.24 | stefan27 | what makes you so sure about 'the ICE negotiation completes (ast_rtp_on_ice_complete fires(?)) sometime after SDP negotiation completes' |
| 11:34.56 | stefan27 | and what does it mean for SDP negotation to complete from chan_sip.c's perspective... process_sdp returning? |
| 11:38.17 | stefan27 | i can upload a new patch with some of your requested changes, but I'm still not sure about the possible values of rtp->dtls.dtls_setup and rtp->rtcp->dtls.dtls_setup when we are in the function ast_rtp_on_ice_complete |
| 11:38.49 | stefan27 | wouldn't it be awfully weird if rtp->dtls.dtls_setup was ACTIVE and rtp->rtcp->dtls.dtls_setup was PASSIVE? |
| 11:40.13 | stefan27 | have a nice dog walk btw, i wish we were allowed to have dogs in the office :) |
| 11:47.51 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 11:53.32 | *** join/#asterisk-dev Demon_VoIP (~demon@eoks.ivanovo.ru) |
| 11:56.46 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 11:57.04 | file | and back |
| 11:57.31 | file | they have to be the same, the attribute is negotiated at media stream level which encompasses both RTP and RTCP |
| 11:57.58 | file | and because in order to do ICE negotiation both sides have to exchange their candidates, which is done through the SDP negotiation |
| 12:01.46 | file | so at the point of ICE negotiation starting you should have established what the setup is, same for non-ICE |
| 12:03.35 | stefan27 | can the ICE negotation process not start after asterisk has sent SDP offer and parsed *only half* of the SDP Answer (the part including the ice candidates)? |
| 12:04.40 | file | dunno! pjnath may accept that before we've told it to negotiate, can't remember |
| 12:06.09 | file | our side wouldn't have started negotiating yet, so our negotiation wouldn't have completed though |
| 12:08.20 | stefan27 | the process_sdp function may call process_sdp_a_ice() a bunch of times before ever calling process_sdp_a_dtls(). I'm still not sure if that the code running in process_sdp_a_ice() cannot cause ast_rtp_ice_on_complete to fire? I don't know much about pjnath |
| 12:08.54 | file | it can't |
| 12:09.09 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:09.14 | file | until we tell it to negotiate after processing the SDP it won't do the ICE negotiation |
| 12:15.43 | stefan27 | ok cool |
| 12:28.04 | mjordan | hum. Looks like some of our timing stuff with PJSIP qualifies/registers is still a bit wonky - https://bamboo.asterisk.org/bamboo/artifact/AST-ATSF/C664TE/build-596/Test-Suite-Logs/channels/pjsip/ami/show_registrations_outbound/backtrace_457.txt |
| 12:28.20 | mjordan | ah |
| 12:28.33 | mjordan | that's not quite as bad as I thought. We're unloading PJSIP at the same time. |
| 12:28.39 | mjordan | still a bit disconcerting. |
| 12:29.47 | file | isn't that ASTERISK-24907? |
| 12:30.55 | mjordan | probably |
| 12:31.17 | mjordan | it's amazing how out of the loop you get when you aren't looking at things every day. |
| 12:31.33 | file | the loop loops |
| 12:31.39 | file | it always comes back to... fax |
| 13:02.39 | *** join/#asterisk-dev fish9370 (~Miranda@mbox.fpg.ru) |
| 13:03.51 | fish9370 | по ÑÑÑÑки кÑо-Ñо говоÑиÑ? |
| 13:04.15 | fish9370 | hello! question about cdr in asterisk 13 |
| 13:06.34 | fish9370 | what is finalized CDR? can I write to CDR in h exten? |
| 13:07.33 | fish9370 | 11 version I can, and 13 can not |
| 13:09.08 | fish9370 | whether there is an option that enable the old behavior? |
| 13:10.00 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-qfbheznmtzpwsgfi) |
| 13:10.00 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 13:16.03 | *** join/#asterisk-dev sgriepentrog (sgriepentr@nat/digium/x-tjmyiuctaxtwdhez) |
| 13:20.45 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-fvrmlbseojijaryp) |
| 13:25.43 | *** join/#asterisk-dev malcolmd (malcolmd@pdpc/sponsor/digium/malcolmd) |
| 13:25.43 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 13:36.25 | Demon_VoIP | fish9370, íåò òàêîé âîçìîæíîñòè. Ê ñîæàëåíèþ. |
| 13:36.48 | Demon_VoIP | fish9370, Where is no any options. |
| 13:36.57 | Demon_VoIP | :( |
| 13:37.58 | *** part/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 13:38.18 | Demon_VoIP | it will be perfect to do via something like Hangup+Handlers |
| 13:38.27 | Demon_VoIP | https://wiki.asterisk.org/wiki/display/AST/Hangup+Handlers |
| 13:39.21 | Demon_VoIP | but... it is too late. CDR is finallized. You (and me) are needed other (absent) handler |
| 13:43.27 | fish9370 | Demon_VoIP, why it's finallized? |
| 14:10.47 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-jxlnzazbxdhmhuyp) |
| 14:10.52 | newtonr | Has ASTERISK-21991 (https://reviewboard.asterisk.org/r/3062/) been the only effort to get a systemd service script in? |
| 14:12.29 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:12.29 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:13.45 | *** join/#asterisk-dev sgalarneau (Adium@nat/digium/x-pkbgdjptuvhbmwlq) |
| 14:15.20 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-wajqgortyfjcxpne) |
| 14:15.20 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:19.20 | jsmith | newtonr: No idea if it's the only effort -- Fedora/CentOS obviously have a systemd script in their respective packages. I imagine other operating systems are starting to do the same. |
| 14:20.18 | newtonr | jsmith, thanks |
| 14:21.02 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-qrgvdojggvnggwxc) |
| 14:25.22 | stefan27 | one daemon to rule them all? |
| 14:27.50 | sgalarneau | and in the darkness bind them? |
| 14:46.01 | gtjoseph | file: RE documentation in res_pjsip.h for 492. Where exactly? ast_sip_send_out_of_dialog_request or did you have somewhere else in mind? |
| 14:46.15 | file | ast_sip_send_out_of_dialog_request |
| 14:46.34 | gtjoseph | gotcha |
| 15:25.11 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:439:a001:862b:2bff:fead:2cce) |
| 15:40.42 | *** join/#asterisk-dev superscrat (asanders@nat/digium/x-jrccikiucbqzvyfm) |
| 16:21.46 | *** join/#asterisk-dev superscrat (asanders@nat/digium/x-uozslnbbwsweowjx) |
| 17:25.34 | gtjoseph | anyone know why the AOR_CONTACT* TestEvents aren't real AMI events? |
| 17:32.12 | file | they could be promoted |
| 17:32.33 | gtjoseph | yeah, that's what i'm thinking |
| 17:33.05 | gtjoseph | assuming i change all the tests that rely on them, any issue with them going into 13? |
| 17:33.17 | gtjoseph | seeing as they'r enot public anyway |
| 17:58.54 | mjordan | gtjoseph: none on my end |
| 18:00.37 | gtjoseph | cool |
| 18:06.12 | mjordan | FYI: I might need a rather speedy-ish review of https://gerrit.asterisk.org/#/c/506/ |
| 18:06.29 | mjordan | going to try to make 13.4.0-rc1 today, and realized that I should have bumped the minor version of ARI yesterday |
| 18:10.38 | file | you got it |
| 18:19.21 | superscrat | mjordan, working on it now |
| 18:19.21 | file | here we gooooooooo |
| 18:19.28 | superscrat | file, did you merge it? |
| 18:19.34 | superscrat | if so, I will refrain from the review |
| 18:19.35 | file | superscrat, mjordan merged it |
| 18:19.40 | file | he's doing the release right now |
| 18:19.47 | superscrat | okay, then, my work here is done. |
| 18:29.38 | gtjoseph | file: Assuming I have to use stasis to publish the unsolicited AMI contact events, where's a simple example of doing that? |
| 18:30.29 | file | um, everywhere |
| 18:31.02 | gtjoseph | i said "simple" :) |
| 18:31.28 | gtjoseph | should i use the endpoint framework? |
| 18:32.27 | file | there's tons of usage throughout the tree, nothing immediately springs to mind as an example |
| 18:32.34 | gtjoseph | ok |
| 18:32.40 | file | all of them operate in pretty much the same way |
| 18:33.29 | gtjoseph | yeah, i just don't want to duplicate code or create code i don't actually need. |
| 18:34.03 | *** join/#asterisk-dev doome (~doome@92-249-151-152.pool.digikabel.hu) |
| 18:34.32 | superscrat | gtjoseph, you rock :) |
| 18:34.57 | gtjoseph | for not wanting extra code or extra work?? :) |
| 18:35.09 | superscrat | YES |
| 18:35.32 | superscrat | I just want to sing you a song, "Thank you, thank you, thank you!" |
| 18:35.48 | gtjoseph | HA! |
| 18:36.43 | superscrat | my new theme has become, the best code is the less code. |
| 18:38.12 | superscrat | yes, I am aware that was grammatically incorrect... but, it rhymed better :p |
| 18:40.09 | mjordan | I enjoy how I can test, and test, and test. And things still screw up royally when you do it on a real system. |
| 18:40.11 | mjordan | sighs |
| 18:40.30 | file | mjordan, Rome wasn't built in a day - it was built in 10 minutes. |
| 19:15.04 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-xewvrsbmfkqixmxx) |
| 19:15.04 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 19:29.28 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 19:46.27 | TazzNZ | hey all |
| 19:46.47 | file | hi |
| 20:00.22 | X-Rob | newtonr: btw http://what.thedailywtf.com/t/asterisk-pbx/1235/39?u=xrobau just a heads up |
| 20:01.25 | superscrat | Hey TazzNZ |
| 20:02.40 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-ioqdrbaagatomyey) |
| 20:02.41 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-vdyzuurxfnnwkdyu) |
| 20:02.46 | newtonr | X-Rob, thanks. I'll check it out. |
| 20:03.26 | jameswf | make sure you have an hour or 10... christ |
| 20:04.04 | mjordan | well |
| 20:04.06 | mjordan | that's long |
| 20:04.11 | X-Rob | IT is. |
| 20:04.19 | X-Rob | mjordan: also, my deepest commiserations. |
| 20:05.43 | mjordan | meh |
| 20:05.49 | mjordan | sounds like you answered the entire long post reasonably |
| 20:05.54 | mjordan | shrugs |
| 20:06.26 | Qwell | I'm really tempted to abuse my OP powers on that guy. |
| 20:07.43 | jameswf | is waiting for the movie to come out... or the audio book.... |
| 20:07.49 | mjordan | Honestly, Asterisk does have some kind of weird stuff. |
| 20:07.56 | mjordan | And some of it is clearly inconsistent, and stupid. |
| 20:08.00 | mjordan | shrugs |
| 20:08.18 | mjordan | I'm not going to read his ridiculously long rant |
| 20:08.24 | mjordan | and the business side is laughable |
| 20:08.47 | mjordan | but oh well. |
| 20:09.53 | X-Rob | Actually, removing the warning about | is probably a good idea in 14 |
| 20:10.35 | mjordan | yeah |
| 20:12.03 | jameswf | A contraption marketed as a System.... your marketing people should run with that.... |
| 20:12.37 | jameswf | lets the mac read it to me lol |
| 20:12.56 | superscrat | it sounds like he/she had a bad experience getting started and getting help and spent a lot of time and energy venting about it. caveat: I seriously did not read it in its entirety. just pieces of it. |
| 20:14.18 | X-Rob | superscrat: tl;dr: Was using ancient AsteriskNOW, didn't want to upgrade, wanted everything to work, it didn't. He was butthurt when everyone told him this. |
| 20:20.37 | mjordan | ah crap. I didn't update the release announcer script. |
| 20:28.41 | *** join/#asterisk-dev sgalarneau (~Adium@user-24-96-87-214.knology.net) |
| 20:28.42 | superscrat | X-Rob, he/she also admitted not to being a programmer and having no (or limited) prior linux experience. I think that with those variables stacked up against him/her, it would be irresponsible to automatically assign all the blame to asterisk. |
| 20:28.43 | superscrat | I do have alot of sympathy for this person. This domain itself is hard, in addition to Asterisk, Linux, etc., and it takes a lot of time and patience to cultivate your skills. If you don't know what you're trying to ask and cannot speak the vernacular of the community, then it is very difficult for people to help you, because they do not know what you are asking them for. |
| 20:28.43 | superscrat | I was new to all of this not too long ago myself, so I can definitely attest to it being no cake walk. To that end, it could be that he/she was had become so frustrated with the whole shooting match that it seemed "obvious" to blame asterisk/the community/the asterisk wiki, etc. Again, I do give this person my sympathy because this isn't something that you can pick up in a day, or week, or month even. Six months later, I still have |
| 20:28.43 | superscrat | One final note, though. Everyone in this community has been tremendously courteous and helpful (and patient --- mjordan, thank you) to me so I do not agree with that part of the assessment. But, for me, I do try to do a lot of research before I ask any questions, that way I know how to articulate my thoughts in a way that others will understand. First principle: Seek first to understand, then to be understood. |
| 20:33.01 | newtonr | One of the commentors answered his post appropriately with "Didn't you, at any chance, get the realization that "this is way over my head, I'd better get some real assistance, brush up my related knowledge of networking and Linux, or simply give it up and try something else"? |
| 20:37.19 | superscrat | :) I didn't see that newtonr. that seems like a mostly fair response, though. |
| 20:37.31 | newtonr | I feel like his primary complaint was his perception that Digium advertises Asterisk as an "out of the box" solution (uh no?) and that it ended up being really hard to learn Asterisk, Linux, networking, telephony and programming all at the same time. Sorry.. it isn't easy if you go into it knowing nothing and his claims about our marketing of Asterisk are false. |
| 20:39.42 | superscrat | newtonr, truth. Telephony itself is a difficult domain to master. The tools are complicated because they are solving a complicated problem. Lots and lots and lots of moving parts... If you go in with no prior knowledge, it is going to be an uphill battle and it is going to take signifcant effort/time to get yourself up to speed. Patience/persistence would be very good attributes to have in that scenario. |
| 20:42.53 | mjordan | well. AsteriskNOW is mostly advertised as being out of the box. |
| 20:42.59 | mjordan | And since he picked a bad version... well. Yeah. |
| 20:43.04 | WIMPy | I do remember him. IIRC he was rather impatient if not appearing to be resistant to learning on the search for precise answers instead of accepting pointers. |
| 20:44.33 | WIMPy | But I think the post has a lot of truth baout the whole VOIP market and the fals expectations people get from lots of alledged advantages that are often pretty far away from the truth. |
| 21:00.46 | newtonr | mjordan, the guy repeatededly makes claims against Asterisk and the Asterisk project. He may mean AsteriskNOW, but those reading it may not get that. |
| 21:02.03 | newtonr | i certainly have sympathy for him in learning a difficult topic with a lot of complicated technologies all converging together. |
| 21:07.47 | zerohalo | My word, what a verbose guy... |
| 21:15.39 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 21:43.02 | gtjoseph | file: got a sec for a publish question? |
| 21:43.11 | file | yes |
| 21:43.41 | gtjoseph | every time ast_endpoint_blob_publish gets called, AMI publishes 2 events. This is before I changed anything. Is this normal/expected? |
| 21:43.53 | file | oh that |
| 21:44.01 | file | uh, no clue! |
| 21:44.18 | gtjoseph | hmmm. ok. |
| 22:00.40 | mjordan | Hm. |
| 22:00.45 | mjordan | do the events look the same? :-P |
| 22:01.09 | gtjoseph | oh yes. 2 PeerStatus events with exac tly the same content |
| 22:01.23 | mjordan | that seems wrong |
| 22:01.30 | gtjoseph | yes it does |
| 22:01.32 | gtjoseph | :) |
| 22:01.47 | mjordan | gtjoseph: I would suspect that there are two subscriptions, and something didn't set up a forwarding relationship correctly |
| 22:01.48 | gtjoseph | but i've verified that publish is only called once |
| 22:02.02 | gtjoseph | that was gpoing to be my next step. |
| 22:02.11 | gtjoseph | but since this is a pre-existing issue... |
| 22:02.16 | mjordan | yeah |
| 22:02.22 | gtjoseph | i'm going to document and address later |
| 22:02.28 | mjordan | sounds like a plan to me |
| 22:02.46 | file | file all the issues! |
| 22:03.01 | mjordan | gtjoseph: I will say that endpoints are a bit funky, in that there are some special topic forwardings that occur internally. It may be that's messing with AMI somehow, although it really shouldn't |
| 22:03.13 | gtjoseph | gotcha |
| 22:05.07 | coreyfarrell | speaking of statis subscriptions, if a subscription callback is run after a module is unloaded does this mean that an unsubscribe is missing somewhere or could this be a module unload race since the subscriptions don't use any module references? |
| 22:06.11 | file | either |
| 22:06.18 | mjordan | but generally, it should be the module's fault. |
| 22:06.22 | mjordan | They should unsubscribe and join |
| 22:06.40 | mjordan | which is the purpose of that function. That unsubscribes them, but only after the last message currently in flight is delivered to their subscription |
| 22:07.28 | coreyfarrell | so the unsubscribe is atomic / doesn't return until all in flight msgs are done? |
| 22:07.39 | file | unsubscribe_and_join doesn't |
| 22:08.25 | *** part/#asterisk-dev mjordan (mjordan@nat/digium/x-wajqgortyfjcxpne) |
| 22:08.29 | file | English is weird... |
| 22:08.55 | file | unsubscribe doesn't wait for confirmation that in-flight messages have been delivered, unsubscribe_and_join does |
| 22:09.26 | coreyfarrell | hmmm, is it possible/easy to query a dlopen handle to determine the address range? I'd like to print the address range of code during all module loads, that way when I get this crash again I'll be able to compare the address that stasis attempted to run, figure out which module it was from. |
| 22:52.11 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-qrgvdojggvnggwxc) |
| 23:23.37 | *** join/#asterisk-dev leedm777 (~leedm777@216.186.181.138) |
| 23:45.09 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |