| 00:23.42 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 00:31.00 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 00:31.56 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 00:31.56 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 00:34.35 | coreyfarrell | sgriepentrog: I'm looking at improving valgrind integration with the testsuite, how would you feel about having it generate valgrind.xml to each asterisk log dir? |
| 00:34.42 | coreyfarrell | XML output is what we'll need to be able to process results, but apparently valgrind won't produce xml and text logs at the same time. |
| 00:36.06 | sgriepentrog | No, it doesn't. And it actually changes slightly how valgrind runs when you put it in xml mode too, which is annoying. |
| 00:36.20 | sgriepentrog | I think that directory choice is optimal. |
| 00:36.33 | coreyfarrell | how does it change it? |
| 00:39.12 | coreyfarrell | for text output I've experimented a little with XSL to produce a plain text summary (leaked bytes, errors). one annoying thing I haven't found a schema for the valgrind output, for example the enum values possible for the <kind> element. |
| 00:45.51 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 00:47.56 | sgriepentrog | there is some subtle differences in what it decides to report in leaks when in xml mode. That or it interprets the parameters differently. |
| 00:50.03 | gtjoseph | mjordan: are you guys going to stick with gitweb or are you going to move cgit or something else? |
| 00:51.00 | coreyfarrell | well that's annoying.. so anyways any objection if we go with XML output? I feel like we eventually want to process the output. maybe we can mark a test failed if it uses uninitialized vars, or other errors like that. we'd need a good suppressions file to even think of failing tests due to memory leaks. |
| 01:01.51 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 01:08.42 | sgriepentrog | The answer is that the xml output is actually, once you start playing with it, the better option. If you run valgrind at all, any sort of access violation should cause a test failure always. But an additional option should be needed to cause memory or fd leaks to fail the test. IMO |
| 01:09.08 | sgriepentrog | It should however always collect and report all the leaks. |
| 01:09.49 | sgriepentrog | Basically, treat each instance in xml as either a warning, or an error, unless all errors are set to be warnings. |
| 01:12.23 | coreyfarrell | great. I think the first revision I do will just generate XML to the right place and log a summary of leaks/errors. look at which results should fail tests for a later revision |
| 01:17.40 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 01:21.25 | sgriepentrog | I think that small incremental improvements is the right approach. |
| 01:21.53 | sgriepentrog | Gives us a chance to digest the change and plan the next step. |
| 01:21.58 | mjordan | gtjoseph: hadn't really made any plans to change that, given that it existed already. cgit is much nicer. |
| 01:26.54 | *** part/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 01:45.58 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-dkrtsuphtywtckpg) |
| 01:45.58 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 03:32.07 | *** join/#asterisk-dev Synthase_ (uid63346@gateway/web/irccloud.com/x-czfcedazkjrufsfq) |
| 03:53.27 | *** join/#asterisk-dev jagruti_ (~root@182.70.116.47) |
| 03:53.59 | *** part/#asterisk-dev jagruti_ (~root@182.70.116.47) |
| 04:19.26 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 04:19.26 | *** 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 |
| 04:42.59 | *** join/#asterisk-dev opticron (~opticron@75.76.209.84) |
| 04:42.59 | *** mode/#asterisk-dev [+o opticron] by ChanServ |
| 05:17.53 | *** join/#asterisk-dev Demon_VoIP (~demon@109.60.135.186) |
| 06:06.14 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 06:06.14 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:29.53 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 07:29.54 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:51.56 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 07:51.57 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:09.10 | *** join/#asterisk-dev zerohalo (~zerohalo@2601:6:f80:224:a09f:7c70:b09b:eb97) |
| 08:23.00 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 08:38.51 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:419b:b631:1fcd:3362) |
| 08:44.36 | oej | Morning folks |
| 09:11.16 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-jdcrzcuyfkcbnzzi) |
| 09:25.34 | *** join/#asterisk-dev stefan27 (~stefan27@212.247.4.149) |
| 09:32.22 | skrusty | morning |
| 09:41.23 | stefan27 | my ast_channel can point to another ast_channel through the linkedid-field. I can get this ID with the function ast_channel_linkedid, but is there any 'reverse-lookup'-function which retrieves the ID(s) of any channels which points to mine (through linkedid) |
| 09:55.42 | oej | Isn't that just built for two party bridges? |
| 09:55.46 | oej | To get the bridged id |
| 09:56.23 | oej | I think I added that a long time ago in order to get the SIP channel ID of the other side of a bridge. |
| 10:15.06 | stefan27 | There's a chain of linkedid pointers: SIP_A->LocalX;1->LocalX;2->LocalY;1->LocalY;2->SIP_B (due to Dials). Given a pointer to Local_Y;2 I can locate SIP_B with above function, but given LocalX, I can't locate SIP_A |
| 10:15.57 | stefan27 | I don't think Im interested in the id of any bridges, just want references to channels and to be able to traverse above chain |
| 10:16.27 | stefan27 | in both directions |
| 10:29.55 | oej | I looked into that years ago, it's an interesting chain to try to track. |
| 10:30.12 | oej | Especially with local bridges |
| 10:36.35 | oej | I wonder if a channel variable will help you as a shortfix. Setting __ORGCHANNEL or something |
| 10:36.46 | oej | That *should* be inherited all the way |
| 11:26.41 | coreyfarrell | apparently the DONT_OPTIMIZE menuselect option can suppress some errors |
| 11:35.57 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 11:35.57 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 11:57.01 | stefan27 | you're early today mjordan |
| 11:57.28 | stefan27 | you get to work at 7 am? |
| 11:58.51 | mjordan | sorta |
| 11:59.06 | mjordan | Typically when I wake up, I review e-mails, project status, JIRA, etc. |
| 11:59.13 | mjordan | I do that for a few hours, eat, then head to work |
| 11:59.37 | skrusty | :) |
| 11:59.43 | stefan27 | i wake up at 9 am |
| 12:00.03 | skrusty | i have kids, i dream of waking up at 9am :) |
| 12:00.49 | stefan27 | nah don't envy me. I have to sleep 9-10 hours every night to function normally it's not optimal |
| 12:02.23 | file | meep |
| 12:02.40 | skrusty | lo |
| 12:03.30 | skrusty | looking at pjsip config... am i right in thinking i can assign different bind interfaces to differnet trunks? |
| 12:04.02 | file | yes. |
| 12:04.05 | skrusty | excellent |
| 12:15.24 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-66-28.user.veloxzone.com.br) |
| 12:15.51 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 12:17.53 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 12:17.54 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:20.29 | stefan27 | now that americans are awake ill ask again for more feedback: I have a chain of ast channels, where the links are given by the 'linkedid' field: SIP_A->LocalX;1->LocalX;2->LocalY;1->LocalY;2->SIP_B (due to Dials). Given a pointer to Local_Y;2 I can locate SIP_B with function ast_channel_linkedid, but given LocalX, I can't locate SIP_A |
| 12:20.44 | stefan27 | how can i traverse chain backwards |
| 12:21.21 | *** join/#asterisk-dev sgriepentrog (sgriepentr@nat/digium/x-iumnzrlfgiqhdpxw) |
| 12:21.32 | stefan27 | from asterisk source code (not through dialplan) |
| 12:22.16 | coreyfarrell | file: unless you object I'm going to commit that fix now. |
| 12:22.28 | file | coreyfarrell, I don't |
| 12:23.33 | skrusty | http://www.asterisk.org/downloads <-- css missing? |
| 12:23.50 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:24.56 | mjordan | stefan27: er |
| 12:25.06 | mjordan | generally, that is a difficult thing to do, and not recommended. |
| 12:25.26 | mjordan | you have to bounce down into the local channel driver and get both sides of the local channel pair |
| 12:25.35 | mjordan | which is super-easy to deadlock on if you're not careful |
| 12:25.44 | mjordan | (see 'awesome_locking' in Asterisk 11) |
| 12:26.40 | mjordan | also, you can't really trust that ast_channel_linkedid will consistently give you the SIP/B channel, as linkedids can update |
| 12:26.56 | mjordan | better question is: what are you trying to do? |
| 12:29.45 | mjordan | skrusty: yes, the CSS is missing, and yes, the responsible people have been informed, and no, I am not thrilled with the turnaround time :-P |
| 12:30.05 | skrusty | ;] |
| 12:30.09 | mjordan | skrusty: er |
| 12:30.12 | mjordan | actually |
| 12:30.13 | coreyfarrell | looks like it's just serving a fragment (<div> is root element) |
| 12:30.32 | mjordan | oh lord. |
| 12:30.35 | mjordan | this one is new. |
| 12:30.40 | file | ugh |
| 12:30.42 | skrusty | heh |
| 12:30.45 | mjordan | sighs |
| 12:30.46 | skrusty | i'd not even noticed that |
| 12:30.47 | file | yeah |
| 12:31.08 | skrusty | nice :) |
| 12:32.34 | file | yup yup |
| 12:32.43 | oej | mjordan: Write a powerpoint, schedule a meeting in exchange and dazzle them with some animated gifs in the slide deck. |
| 12:32.52 | oej | hides |
| 12:32.54 | skrusty | lol |
| 12:33.04 | skrusty | do it all from sharepoint! |
| 12:34.53 | oej | It's Friday. We should be nice to our estimated project leader. |
| 12:34.59 | oej | mjordan: Have a nice day! |
| 12:35.10 | oej | â¦and wear a Funny Hat! |
| 12:35.33 | mjordan | oej: amen |
| 12:35.51 | mjordan | That would probably work |
| 12:36.59 | *** join/#asterisk-dev Marquis42 (~mrbmw@d14-69-246-193.try.wideopenwest.com) |
| 12:37.07 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-nodarszlcyokgenr) |
| 12:38.54 | anonymouz666 | oej: another battery of tests is going to happen with teapot-1.8 and MS LYNC 2013 again. |
| 12:39.06 | anonymouz666 | hopping for the best |
| 12:43.27 | oej | Cool. Keep me posted. |
| 12:43.44 | oej | Seems like I will take it through another certification process soon |
| 12:43.58 | anonymouz666 | GW or SIP Trunk or both |
| 12:44.34 | oej | SIp trunk this time |
| 12:44.46 | oej | Have one gw and multiple sip trunk certifications done. |
| 12:45.26 | anonymouz666 | well, these certifications tests are good because eventually brings some improvements on chan_sip or even new features. |
| 12:46.22 | oej | If we get the improvements in there. |
| 12:46.36 | oej | mjordan and I need to get more time to do that work. |
| 12:46.58 | oej | Unless he's just in meetings working on new plans for sharepoint⦠Scheduling other meetings. |
| 12:47.06 | mjordan | I'm telling ya, the first person that invents a cloning machine... |
| 12:47.08 | oej | Sorry, could not resist. Me bad. |
| 12:47.15 | mjordan | oej: I need a clone for those! |
| 12:47.22 | mjordan | the problem is, my clone would rebel |
| 12:47.27 | oej | he he |
| 12:47.57 | mjordan | http://web.mit.edu/manoli/mood/www/mood12.jpg |
| 12:48.32 | oej | he he |
| 12:48.34 | mjordan | well, that's time travel, but it is about the same issue |
| 12:48.34 | coreyfarrell | sgriepentrog: I just posted a review for valgrind to output xml from testsuite. shouldn't be any big surprises since we talked last night, if you have time to take a look that'd be cool. https://gerrit.asterisk.org/15 |
| 12:48.46 | mjordan | coreyfarrell: cool |
| 12:49.29 | mjordan | ooo XSL to review |
| 12:49.56 | coreyfarrell | mjordan: before I forget, can you make sure the reference checks bamboo job has res_pjsip enabled before it runs this weekend? |
| 12:50.07 | mjordan | coreyfarrell: have you tried a local run yet? |
| 12:50.15 | mjordan | not the whole thing, but just a few PJSIP tests |
| 12:50.15 | coreyfarrell | yeah ugly XSL because it's outputting in text format |
| 12:50.23 | mjordan | coreyfarrell: ew |
| 12:50.38 | coreyfarrell | I did ./run-local -t tests/channels/pjsip .. most tests passed with REF_DEBUG on |
| 12:50.43 | mjordan | ok |
| 12:50.46 | mjordan | in that case, sure |
| 12:55.10 | coreyfarrell | so for the XSL for valgrind summary I'm open to other ideas, that's just what I came up with. |
| 12:55.51 | mjordan | nope, XSL is the way to go |
| 12:56.44 | coreyfarrell | I might see about having XSL generate a summary.xml (in memory) and use DOM to iterate the notes and produce the text |
| 12:57.29 | coreyfarrell | s/notes/nodes/ |
| 13:01.33 | mjordan | file: mechanical keyboards ftw |
| 13:01.44 | file | mjordan, this statement is factual |
| 13:01.46 | mjordan | coreyfarrell: aye |
| 13:02.13 | mjordan | file: and the world now knows that you use windows |
| 13:02.26 | file | I am PERFECTLY fine with that |
| 13:02.34 | file | technical preview version these days even |
| 13:03.35 | mjordan | bleeding edge, yo |
| 13:03.38 | skrusty | using win10 on my laptop |
| 13:03.44 | skrusty | not on main pc though |
| 13:16.23 | skrusty | anyone know why i might be getting "/usr/bin/ld: cannot find -lsrtp" when compiling 13.2 with pjsip ? |
| 13:17.15 | file | something wants libsrtp and it's not there? |
| 13:18.35 | skrusty | hmm, didn't realised that was a dep |
| 13:18.52 | file | it's not |
| 13:19.12 | skrusty | wonder if it's because i used a deb for pjsip |
| 13:19.52 | file | entirely possible |
| 13:19.56 | mjordan | srtp dependencies between pjsip/asterisk are fun |
| 13:20.15 | mjordan | if you configure PJSIP to expect an external SRTP library - which you need to do if you want to use SRTP with Asterisk - then it will really want an external SRTP library |
| 13:21.22 | skrusty | adding libsrtp0-dev seems to have fixed it |
| 13:21.39 | skrusty | first time i've played with pjsip :) |
| 13:21.55 | file | whomever did the deb should have added srtp as a dependency if it's, well, a dependency >_> |
| 13:22.10 | skrusty | true. |
| 13:37.17 | mjordan | goes to work |
| 13:37.23 | *** part/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 13:54.02 | skrusty | hmm, why is my transport not showing up in asterisk :( |
| 14:01.36 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-66-28.user.veloxzone.com.br) |
| 14:02.30 | file | have you looked at what it says when it is loading? |
| 14:02.31 | file | er loaded |
| 14:06.46 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-psalgkowvxumtegp) |
| 14:14.11 | skrusty | jsut looking now.. |
| 14:14.45 | skrusty | ah: sorcery_object_load: Type 'transport' is not reloadable, maintaining previous values |
| 14:15.02 | skrusty | i assume that's not an issue if you're using realtime? |
| 14:15.16 | skrusty | which i intend to once i've had a play |
| 14:15.25 | file | you can't store transports in realtime |
| 14:16.25 | skrusty | oh |
| 14:17.12 | file | transports have state associated with them, and the PJSIP stack doesn't allow you to easily manipulate them after setup - so the implementation enforces no reloads and while I don't think it is currently enforced... it won't work from realtime |
| 14:17.26 | skrusty | shame |
| 14:17.57 | skrusty | that would have been really handy! |
| 14:19.46 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:19.46 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:23.10 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 14:30.35 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-hnmaijiwstpihksv) |
| 14:30.35 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:33.21 | file | high fives putnopvut |
| 14:33.42 | putnopvut | ducks |
| 14:33.50 | putnopvut | Oh, I thought you were trying to hit me |
| 14:35.13 | file | maybe I was |
| 14:36.38 | stefan27 | Q: <@mjordan> better question is: what are you trying to do? A: a colleague asked me this question - I tried to translate his question (not 100% sure exactly what he's doing, but he's trying to write some app), but thanks for the response, i think he's gonna use an approach more in line with oejs answer anyways |
| 14:43.28 | mjordan | no worries. Reaching backwards across a channel chain (or even forwards) can be inherently dangerous, as it doesn't take into account that channel pointers change based on external actions. A redirect, for example, can masquerade out the pointer from underneath you unless you lock everything, and locking a channel chain is dangerous and prone to deadlocking |
| 14:43.55 | mjordan | doing that kind of thing is generally a sign of "you are trying to do something you shouldn't be doing." |
| 14:44.11 | mjordan | if you really need to pass information down a channel chain, using a control frame is a much better approach |
| 14:44.28 | mjordan | as the channel core already knows how to pass that along a channel chain (and through bridges) |
| 14:58.57 | *** part/#asterisk-dev mjordan (mjordan@nat/digium/x-hnmaijiwstpihksv) |
| 15:15.01 | *** join/#asterisk-dev justsomedood (~warren@mail.serverplus.com) |
| 15:15.50 | gtjoseph | putnopvut: do you have a few minutes to clarify some things in pjsip_options? |
| 15:19.46 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-vrcpokjvtztijphe) |
| 15:19.47 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:37.45 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-dtmwlvnciqopdlkk) |
| 15:37.59 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-anhgeafkyuusxfrv) |
| 15:40.14 | putnopvut | gtjoseph: Just got out of a meeting. I'm sort of doing this window and something else at the same time, so I'll do my best to answer you but it might not always be quick. |
| 15:41.41 | gtjoseph | no worries... first question: in init_start_time and update_contact_status a new status structure is allocated to replace the old one. why not use the existing one? |
| 15:44.30 | file | it's being persisted in sorcery, and sorcery objects are immutable if provided to or retrieved from sorcery |
| 15:45.51 | gtjoseph | wait... so you can't call ast_sorcery_update on an object you retrieved from sorcery? |
| 15:46.03 | file | you can't MODIFY an object you get from sorcery |
| 15:46.15 | file | unless you are modifying another object, by association |
| 15:46.58 | gtjoseph | so ast_sorcery_update is really a replace operation? |
| 15:47.31 | file | it may or may not be, it depends on the underlying wizard in use |
| 15:47.54 | gtjoseph | Hmmm. never knew that. |
| 15:48.21 | file | bbs - going for lunch |
| 15:49.03 | file | right now the only time where it's a replace is if the memory wizard is in use |
| 15:49.16 | file | other stuff serializes the object into another format and stores it elsewhere |
| 15:49.48 | gtjoseph | I'll have more questions about that after lunch, :) |
| 15:51.38 | gtjoseph | putnopvut: Ok, second question... For the (hopefully but maybe not) short period of time between the send and receive, the contact is marked as unavailable. Why not use a timeout, say 5 seconds so the callback is always called? |
| 16:00.18 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-mtjxmtvsqbxixqbt) |
| 16:00.18 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 16:10.40 | file | shouldn't need a timer, when the OPTIONS gets no response a callback is invoked |
| 16:13.22 | gtjoseph | Don't think so. |
| 16:13.29 | gtjoseph | based on my experimentation |
| 16:14.14 | gtjoseph | the callback is only called if endpt_send_request is called with a timeout |
| 16:14.22 | gtjoseph | but it's always -1 |
| 16:15.31 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-jjoqmkfjupxuetwb) |
| 16:16.31 | file | the callback should be expected to occur when the timer trips and the OPTIONS fails, if that doesn't happen then fixing that would be the solution |
| 16:17.08 | gtjoseph | There is no timer. A timeout of -1 (no timeout) is always passed. |
| 16:17.25 | gtjoseph | res_pjsip:2945 |
| 16:21.18 | file | yes - fixing that would be the thing to do |
| 16:21.57 | gtjoseph | i'm going to create an ast_sip_send_request_timeout() so you can specify the timeout. Make sense? |
| 16:23.07 | file | are you sure that does anything though? |
| 16:23.12 | file | cause I looked at PJSIP, and it doesn't |
| 16:23.30 | gtjoseph | Really? I'll test it. |
| 16:24.05 | file | since it's stateful I'd expect it to trigger when the underlying transaction completes |
| 16:24.12 | file | not based on a timeout |
| 16:25.02 | gtjoseph | So pjsip_endpt_send_request doesn't do anything with the timeout specified? |
| 16:25.26 | file | the timeout provided to pjsip_endpt_send_request is unused |
| 16:25.39 | gtjoseph | figures. |
| 16:26.16 | file | I'd wager that in the past it was used, but they cleaned it up to use the transaction lifetime instead of an arbitrary timeout |
| 16:28.22 | gtjoseph | Rats. I've been trying to figure out how to trigger an event when a contact fails to qualify but every attempt to qualify changed the status to unavailable. |
| 16:28.42 | gtjoseph | then changes it back to avail if the response is received. |
| 16:52.26 | sgriepentrog | coreyfarrell: ping |
| 17:08.47 | superscrat | for https://reviewboard.asterisk.org/r/4520/, I am having a little bit of trouble testing my 'SUCCESS' cases. I have some code that I didn't push to reviewboard yet, and maybe someone here can walk me to where I am going wrong. |
| 17:09.39 | mjordan | sure |
| 17:10.00 | mjordan | so, ideally, in the SUCCESS case, you want to have the channel variable get set to 'SUCCESS' by Stasis, then have the channel get released to the dialplan right? |
| 17:10.05 | superscrat | My problem is that I can't seem to make stasis end |
| 17:10.19 | mjordan | superscrat: what happens when you use the /continue operation on the channels resource? |
| 17:11.15 | mjordan | https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Channels+REST+API#Asterisk13ChannelsRESTAPI-continueInDialplan |
| 17:11.16 | superscrat | Here are my two succes scenarios (this is straight out of my tests.yaml that is not on reviewboard):For the fourth case (Dizzy), a call is made under |
| 17:11.16 | superscrat | normal conditions and then the channel is hungup. For this case, the |
| 17:11.16 | superscrat | test verifies that Stasis correctly assigns SUCCESS to STASISSTATUS. |
| 17:11.16 | superscrat | - For the fifth and final case (Furrball), a call is made under |
| 17:11.16 | superscrat | normal conditions and then the channel joins a bridge. For this case, |
| 17:11.16 | superscrat | the test verifies that Stasis correctly assigns SUCCESS to |
| 17:11.17 | superscrat | STASISSTATUS. |
| 17:11.33 | superscrat | When I do a continue, mjordan... |
| 17:11.42 | mjordan | I don't think you have to test the fifth case, where someone is put into a bridge, but that's just me |
| 17:11.45 | superscrat | stasis still never ends. Having said that |
| 17:11.56 | superscrat | I was using ARI and not AMI to do the continue, and that may have been the problem |
| 17:12.07 | mjordan | no, ARI continue is what I was referring to |
| 17:12.23 | mjordan | superscrat: when you hang up, the channel won't go back to the dialplan in the same location. It will execute in the 'h' extension, if you have one |
| 17:12.32 | superscrat | Okay, well, I did try that for one of my many test runs. I can put it back in and send you the log if that will help |
| 17:12.37 | mjordan | You *should* still have the variable set in that case |
| 17:12.44 | superscrat | oh, my gosh. you are right, mjordan |
| 17:13.05 | mjordan | superscrat: yeah, I'd try continue, but not on a channel in a bridge. I'd suspect that doing a /continue while a channel is in a bridge may not do what you'd like |
| 17:13.13 | superscrat | I am presently executing a face to the palm right now. |
| 17:13.18 | mjordan | (it's going to move out of Stasis in a somewhat unintuitive way) |
| 17:13.23 | mjordan | np :-P |
| 17:14.02 | superscrat | I got pretty far with the bridge last night, though... I used channelstatechange through ARI to figure out if my channels were up, then I used ami to put them into a bridge |
| 17:14.46 | mjordan | why AMI, and not ARI? |
| 17:15.02 | mjordan | If you use AMI, they will no longer be controlled by ARI |
| 17:15.11 | superscrat | I let the reactor do most of the work for me with a recursive 'wait_for_it' nested function. if I could have gotten that to work, I think it would have been neat - and I did learn a little bit about AMI. Yes, because if I used ARI to do the bridge (that was before AMI) the channel was still in stasis |
| 17:15.13 | mjordan | As the Bridge created through AMI is going to rip them out of your Stasis application |
| 17:15.20 | superscrat | and the point is to get it to leave stasis |
| 17:15.22 | mjordan | ah |
| 17:15.28 | mjordan | I don't think you're going to get your channel variable then |
| 17:15.36 | mjordan | as the channel is no longer leaving through the 'front door' of Stasis |
| 17:15.46 | mjordan | it is getting forcibly ripped, in a somewhat violent fashion, out of the Stasis application |
| 17:16.09 | mjordan | I don't think the channel variable phenomenon has to really account for that. Sure, it'd be nice if it did, but our channel variable statuses for all other dialplan applications don't account for that either |
| 17:17.07 | superscrat | sigh. okay. right! omgosh, another eureka moment - the res_stasis hooks for checking if the channel was snatched from stasis. ah, okay. |
| 17:17.32 | superscrat | okay, so basically, hang it up or continue it |
| 17:17.40 | superscrat | check the h extension |
| 17:17.59 | mjordan | yup |
| 17:18.01 | superscrat | thanks! |
| 17:18.03 | mjordan | np! |
| 17:18.39 | superscrat | btw - all of the review feedback sans one question I have not answered for Kevin Harwell, and one question I had for you, has been addressed. |
| 17:32.35 | mjordan | question answered |
| 17:57.40 | *** part/#asterisk-dev mjordan (mjordan@nat/digium/x-vrcpokjvtztijphe) |
| 18:19.39 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 18:19.39 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:28.24 | *** join/#asterisk-dev JimDickenson (~dickenson@c-24-21-169-89.hsd1.or.comcast.net) |
| 18:38.14 | *** part/#asterisk-dev JimDickenson (~dickenson@c-24-21-169-89.hsd1.or.comcast.net) |
| 18:42.57 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 18:42.57 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:56.09 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 18:56.09 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:09.22 | gtjoseph | anyone got tips on how to resubmit a gerrit review when only the commit message has changed? |
| 19:59.53 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-vrcpokjvtztijphe) |
| 19:59.53 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 20:00.26 | mjordan | back log! |
| 20:00.31 | mjordan | file: want to do it here or #asterisk-bugs? |
| 20:00.38 | putnopvut | he's playing with his dog! |
| 20:00.51 | mjordan | smart man |
| 20:01.00 | putnopvut | And I vote for here. |
| 20:02.30 | mjordan | ASTERISK-15814 |
| 20:03.20 | mjordan | So, that was basically the same as ASTERISK-15452 |
| 20:03.35 | putnopvut | wishes infobot would expand those to links |
| 20:03.50 | mjordan | putnopvut: yeah, I need to resurrect our bots |
| 20:03.57 | mjordan | labs it up real quick |
| 20:04.58 | mjordan | honestly, we do this all the time |
| 20:05.10 | mjordan | we're talking about a CLI originate of a Local channel and having both halves actually just wrok |
| 20:05.11 | mjordan | er, work |
| 20:05.41 | mjordan | sighs |
| 20:05.50 | mjordan | I didn't have Asterisk 11 compiled :-( |
| 20:06.03 | putnopvut | you goofball |
| 20:06.11 | putnopvut | Also, the issue reporter is Kobaz, and he's in here :) |
| 20:06.21 | putnopvut | Kobaz: Is ASTERISK-15814 still a problem? |
| 20:07.01 | mjordan | doh! |
| 20:08.19 | file | this seems like something we'd hear about from others... |
| 20:09.56 | mjordan | ew |
| 20:10.00 | mjordan | I have to use chan-sip |
| 20:10.32 | putnopvut | You'll be fine |
| 20:10.57 | file | just use the proper SIP cable |
| 20:13.06 | mjordan | worked for me :-P |
| 20:13.18 | file | mjordan, yay |
| 20:13.36 | putnopvut | CLOSE IT |
| 20:15.36 | mjordan | ASTERISK-15845 would be interesting to see if it still happens |
| 20:15.42 | mjordan | and quite frankly, even if it does, if we actually care |
| 20:15.56 | mjordan | Not calling WaitEvent is kind of a violation of AJAM |
| 20:16.31 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-dzjqfwfbhqjjtrge) |
| 20:16.31 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 20:16.45 | file | meh |
| 20:17.15 | mjordan | if someone wants another one that is almost certainly fixed, ASTERISK-15973 |
| 20:17.20 | mjordan | I'll see if I can't make AJAM.... work. |
| 20:17.49 | putnopvut | I'm nominating ASTERISK-15442 for closing. |
| 20:18.13 | file | hasn't refconting in MOH been touched in the last year or so? I have a vague recollection |
| 20:18.50 | file | achoo. |
| 20:18.54 | putnopvut | checks the svn log |
| 20:19.56 | file | yeah, revision 410044 - moh: fix a refcount error with realtime MOH |
| 20:21.05 | mjordan | yeah, I haven't gotten Asterisk over 0.3% CPU doing that |
| 20:21.23 | putnopvut | file: is that russellb's fix? |
| 20:21.28 | file | putnopvut, yes |
| 20:21.34 | putnopvut | Okie-dokie |
| 20:22.20 | file | yeah, I think this is fixed |
| 20:22.27 | file | any qualms with closing ASTERISK-15973? |
| 20:22.28 | putnopvut | Agreed. If it's not, then new issue can be opened. |
| 20:22.30 | putnopvut | DO IT |
| 20:23.21 | file | mjordan, neat |
| 20:23.36 | file | putnopvut, hrm! |
| 20:24.27 | mjordan | ooo |
| 20:24.38 | mjordan | ASTERISK-16194 |
| 20:24.39 | russellb | i fixed something? |
| 20:24.55 | file | russellb, yes! realtime! MOH! stuff! |
| 20:24.58 | russellb | neat! |
| 20:25.17 | file | mjordan, CDRs! your most favorite thing |
| 20:25.24 | mjordan | I ENJOY PAIN |
| 20:26.51 | putnopvut | I'm going to take a break from this discussion because I want to get my SIP transaction patch committed. |
| 20:27.27 | file | putnopvut, ok! I'm also 50/50 on 15442 |
| 20:28.43 | file | mjordan, ASTERISK-16475 is another CDR one :P |
| 20:30.27 | mjordan | "Finally, in Asterisk 12, we re-did all of CDRs. Since bridging is now sane, transfers became sane, which lent some semblance of sanity to the insanity that are CDRs. At the very least, they are broken in new and more creative ways. They do, however, have functional userfields in transfer scenarios." |
| 20:31.29 | mjordan | hum |
| 20:32.07 | mjordan | well |
| 20:32.12 | mjordan | that's actually "broken" in 12+. |
| 20:32.15 | mjordan | by design. |
| 20:33.38 | mjordan | luckily, it looks like the issue reporter moved on to CEL anyway. |
| 20:33.46 | file | yay |
| 20:36.31 | mjordan | ASTERISK-16352 |
| 20:36.36 | mjordan | lol |
| 20:36.39 | mjordan | oh yeah, I remember this patch |
| 20:36.51 | mjordan | "Let's just keep executing dialplan even though we had an error in dialplan execution" |
| 20:37.14 | mjordan | ah |
| 20:37.16 | mjordan | it's even worse |
| 20:37.19 | mjordan | the channel can be hung up |
| 20:37.24 | file | huh |
| 20:37.51 | mjordan | little sad he never got an answer on the patch |
| 20:38.03 | mjordan | sometimes we aren't so good at the respondy-ness |
| 20:38.54 | mjordan | FYI: pretty sure we will never do anything with ASTERISK-16535 either |
| 20:39.06 | mjordan | that could probably use a "good idea, huge crazy effort, patches welcome" |
| 20:39.17 | mjordan | goes to lab up ASTERISK-16352 |
| 20:44.07 | mjordan | hold on |
| 20:44.12 | mjordan | "If traced, you can see the after Asterisk receives a SIP BYE message, the dialplan execution is immediately stopped even though there are other priorities to evaluate in the dialplan." |
| 20:44.45 | file | yes - so - I don't understand the issue there... |
| 20:45.18 | mjordan | there isn't one. |
| 20:49.02 | mjordan | file: I'm not sure I want to get in the business of providing prescriptive log messages for the dialplan |
| 20:49.06 | mjordan | re: ASTERISK-16535 |
| 20:50.01 | file | what does it say these days? |
| 20:50.14 | mjordan | is unsure |
| 20:51.09 | mjordan | *CLI> [Mar 27 15:51:03] ERROR[29059]: config.c:1549 process_text_line: The file '"foo.conf' was listed as a #include but it does not exist. |
| 20:51.12 | mjordan | GOOD ENOUGH FOR ME |
| 20:51.26 | file | yeah, at least it's not silent |
| 20:51.28 | mjordan | I wonder when we did that |
| 20:52.52 | mjordan | is curious |
| 20:53.19 | mjordan | ooo |
| 20:53.22 | mjordan | go Tilghman |
| 20:53.30 | mjordan | Corydon76 with the ancient win |
| 20:53.45 | mjordan | lawl |
| 20:53.51 | mjordan | "Add '+=' append operator to configuration files." |
| 20:53.56 | mjordan | r135717 |
| 20:55.10 | file | awhile ago |
| 20:55.34 | mjordan | back in 2008 |
| 20:55.41 | mjordan | so I'm not sure how the issue reporter didn't get that ERROR |
| 20:56.11 | *** join/#asterisk-dev pchero (~pchero@0x555140b5.adsl.cybercity.dk) |
| 20:56.12 | mjordan | this issue shows up a lot |
| 20:56.13 | mjordan | https://issues.asterisk.org/jira/browse/ASTERISK-16572 |
| 20:56.22 | putnopvut | I'm back in this convo |
| 20:56.44 | file | mjordan, erm |
| 20:56.45 | mjordan | that ... dialplan doesn't match the error |
| 21:01.03 | Corydon76 | What's the += operator got to do with this? |
| 21:01.39 | putnopvut | What's the += operator but a second-hand emotion |
| 21:02.41 | Corydon76 | Clearly, it's Friday afternoon. |
| 21:04.29 | mjordan | Corydon76: a Friday afternoon with nothing to do but stare at old issues and ponder |
| 21:04.46 | file | and ponder reality |
| 21:05.58 | mjordan | ah |
| 21:06.16 | mjordan | that Local channel has nothing to do with ASTERISK-16572 |
| 21:06.34 | mjordan | wha |
| 21:06.43 | mjordan | goes to lab this up as well. |
| 21:06.51 | mjordan | hum. |
| 21:06.53 | mjordan | I need more phones. |
| 21:07.11 | file | dangerous words |
| 21:07.14 | file | also: softphones |
| 21:07.27 | mjordan | truth |
| 21:09.00 | putnopvut | I'm nominating https://issues.asterisk.org/jira/browse/ASTERISK-17234 as closable. The info points to FreePBX and FOP as showing incorrect status of unregistered phones due to 1.8 changes. I'm willing to bet that this has been accounted for in those products now. |
| 21:09.38 | mjordan | I was going to blame Grandstream, but I see Linksys in there, so I'm good |
| 21:09.43 | file | ditto |
| 21:11.01 | mjordan | I need a soft phone that works |
| 21:11.48 | file | blink? |
| 21:16.34 | mjordan | yup, that works now. |
| 21:16.37 | mjordan | well, not Ekiga. |
| 21:16.40 | mjordan | Jitsi got it done. |
| 21:16.47 | mjordan | But I really should pay money for one of those things. |
| 21:18.42 | Corydon76 | mjordan: or watch for contests. I once scored a Polycom 335 simply by entering a contest, and they sent it for free. |
| 21:18.52 | mjordan | oh nifty, jsmith updated mmichelson's review. |
| 21:18.57 | mjordan | thanks jsmith :-) |
| 21:19.01 | mjordan | Corydon76: good idea |
| 21:19.31 | jsmith | mjordan: No worries -- just playing around with Gerrit during a boring conference call |
| 21:19.48 | jsmith | mjordan: Figured I might as well try it out, get setup -- and actually start reviewing some code |
| 21:20.03 | mjordan | jsmith: Asterisk is hopefully coming up soon |
| 21:20.05 | jsmith | mjordan: It's *way* too easy to help out now :-p |
| 21:20.15 | mjordan | \o/ |
| 21:20.44 | jsmith | mjordan: Yeah, I'm thrilled to see that... my only concern is that we have *too* many Gerrit posts to the mailing list, and it drowns out any other devel discussions |
| 21:21.06 | jsmith | mjordan: But that's another topic for another day |
| 21:21.16 | jsmith | (no different in that regard than ReviewBoard, really) |
| 21:21.32 | mjordan | yeah, it is a bit trickier to filter on it |
| 21:21.51 | mjordan | or at least I had to work to get the filter set up right, and I'm still not catching them all |
| 21:23.14 | Corydon76 | Just a thought. What if you had a mailing list set up for those to send digest emails for those notifications? |
| 21:23.28 | Corydon76 | i.e. send digest notifications to the -dev list |
| 21:23.37 | mjordan | that'd work - I think my only fear is adding (yet another) mailing list to the ... list |
| 21:23.57 | mjordan | that, and really, other than discussing what we *should* do, most conversations happen in code review |
| 21:24.07 | mjordan | gerrit is going to make that problem much worse |
| 21:24.10 | mjordan | (better?) |
| 21:24.17 | mjordan | you pretty much can't bypass code review with it |
| 21:24.44 | Corydon76 | How about a Facebook feed of Gerrit notifications? ;-) |
| 21:24.53 | mjordan | I seriously thought about a twitter bot for it |
| 21:25.02 | mjordan | someone would subscribe to it |
| 21:25.35 | mjordan | file: I feel like if ASTERISK-16871 were a problem, we'd be getting burned hard on it |
| 21:25.39 | mjordan | but I could be mistaken |
| 21:25.40 | Corydon76 | Essentially, that's what you're doing with the mailing list subscription |
| 21:26.08 | Corydon76 | But the nice thing about social media feeds is you don't have to delete the ones you're not interested in |
| 21:27.00 | file | mjordan, yeah... |
| 21:27.24 | Corydon76 | It would be an interesting social media project to have each one regarded as a separate "topic", and only those topics you're interested in would be shown to you |
| 21:27.45 | mjordan | Corydon76: true. I do know that there are some die-hard e-mail people, so I tend to defer to them. One of them will be back from spring break next week, so I'm sure I'll get some suggestions on improving it... |
| 21:28.43 | Corydon76 | "When all you have is a hammer, everything looks like a nail." We have better tools for notifications, now (maybe not PERFECT). |
| 21:29.41 | mjordan | file: I'm moving to "Close as Can't Reproduce"... because I can't? |
| 21:29.49 | mjordan | we should have a lot of SIP phones failing to do squat |
| 21:29.59 | file | it may be platform specific |
| 21:30.05 | mjordan | maybe. |
| 21:30.12 | mjordan | That function punts it down to MD5Update pretty quick |
| 21:30.20 | mjordan | ah |
| 21:30.21 | mjordan | ARM. |
| 21:30.54 | file | an ARM and a leg |
| 21:31.03 | mjordan | ba dum dum chish |
| 21:31.31 | mjordan | Corydon76: agreed - I'm not super sure I want to encourage project discussions on Facebook any more than they already occur |
| 21:31.38 | mjordan | things tend to get very ... weird. |
| 21:31.49 | mjordan | but I do agree that we don't live in 1974 anymore |
| 21:33.20 | Corydon76 | Speaking of old technologies, how about if the notifications all went to Usenet? |
| 21:33.22 | Corydon76 | ducks |
| 21:33.42 | mjordan | UsenetFL |
| 21:33.43 | Corydon76 | Are you even old enough to remember Usenet? |
| 21:33.53 | mjordan | checks |
| 21:34.06 | mjordan | yes, yes I am |
| 21:34.28 | Corydon76 | It was even more popular back when I started college than mailing lists. |
| 21:35.59 | mjordan | file: ASTERISK-17034. Accepting DTMF before ANSWER? |
| 21:36.20 | mjordan | ew. |
| 21:36.32 | file | ugh don't even. |
| 21:36.44 | file | that's a chan_sipism. |
| 21:36.55 | mjordan | what, that it would even bother to accept it? |
| 21:37.14 | file | no, that it broke |
| 21:37.25 | mjordan | hm. |
| 21:37.38 | mjordan | wonders if it is still broken |
| 21:37.47 | file | hrm |
| 21:37.50 | file | putnopvut, ^^^ |
| 21:38.31 | file | it may be because no response has been sent, thus no tag, thus it goes huh on the incoming INFO message |
| 21:39.31 | putnopvut | reads up |
| 21:40.52 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-psalgkowvxumtegp) |
| 21:41.04 | putnopvut | Yeah, it's because of "pedantic" SIP checking being defeault in 1.8 |
| 21:41.26 | putnopvut | INFO arrives with no to-tag, we don't match it to a dialog, there's no channel, so DTMF doesn't work. |
| 21:41.39 | mjordan | should it have a to-tag? |
| 21:42.00 | putnopvut | The INFO from the phone needs a to-tag in order for us to match it to a dialog. |
| 21:42.15 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-psalgkowvxumtegp) |
| 21:42.34 | putnopvut | The thing is, he has a Progress() in the dialplan before the Read, so presumably, Asterisk has sent a provisional response with a to-tag |
| 21:42.48 | mjordan | correct. And I'm not sure what we would do with DTMF received out of dialog anyway |
| 21:42.56 | putnopvut | But unfortunately, this is another case where the reporter tried to be "helpful" and only include a snippet of the log instead of all of it. |
| 21:43.11 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-psalgkowvxumtegp) |
| 21:43.35 | putnopvut | Actually, I bet the problem is that since he has both Ringing() and Progress() in the dialplan, we didn't send a 183 at all. |
| 21:43.48 | putnopvut | Especially if progressinband is set. |
| 21:43.59 | putnopvut | But there be a lack of information. |
| 21:44.01 | file | basically - dunno |
| 21:44.08 | mjordan | I'll make something up. |
| 21:44.14 | putnopvut | Good enough for me. |
| 21:44.25 | file | I have dog hair in my eye. |
| 21:44.29 | file | That is not the place for dog hair. |
| 21:47.49 | mjordan | ooo |
| 21:47.54 | mjordan | Another local channel / chanspy issue |
| 21:47.59 | mjordan | ASTERISK-16729 |
| 21:48.07 | mjordan | heh |
| 21:48.19 | mjordan | I already cleaned up the text on the issue. That's a sign. |
| 21:48.56 | mjordan | hum. |
| 21:49.03 | mjordan | I wonder if there's a masqueradism lurking in that one. |
| 21:50.25 | putnopvut | Not sure. The fact that the SPYGROUP variable is inheritable should mean that the SIP channel that is dialed will have the value set on it. |
| 21:50.37 | mjordan | yeah |
| 21:50.42 | putnopvut | The SIP channel would be masqueraded into the Local;1 channel, but the variable should still be there. |
| 21:50.47 | *** join/#asterisk-dev Synthase_ (uid63346@gateway/web/irccloud.com/x-cerpksdjjcrhfvih) |
| 21:50.50 | putnopvut | Lots of "shoulds" |
| 21:50.51 | mjordan | there's another issue like this one floating out there where it involves the GROUP function, and that one does have issues |
| 21:51.10 | mjordan | yeah, part of this feels like it won't be a bug just due to the number of issues we had with ChanSpy during that era that have been fixed |
| 21:51.22 | mjordan | goes to Lab. It. Up. |
| 21:51.29 | putnopvut | you do that! |
| 21:51.42 | mjordan | ponders just closing it |
| 21:51.47 | mjordan | But that would be wrong. |
| 21:52.21 | putnopvut | What version are you labbing it on? |
| 21:53.10 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 21:53.51 | mjordan | 11 |
| 21:54.04 | mjordan | if it is still a bug in a supported version, then fair enough |
| 21:54.07 | mjordan | unless it is CDRs. |
| 21:54.11 | mjordan | I don't compromise on CDRs. |
| 21:54.40 | file | don't compromise your integrity! |
| 21:54.52 | putnopvut | lab lab lab lab lab lab lab |
| 21:55.03 | file | mushroom mushroom |
| 21:58.21 | mjordan | hm. |
| 21:58.48 | mjordan | ah |
| 21:58.52 | mjordan | silly dialplan |
| 21:59.45 | mjordan | and it works |
| 22:00.57 | mjordan | and, I think I'll call it for now |
| 22:01.00 | mjordan | the weekend awaits |
| 22:01.05 | mjordan | file: same bat time, same bat channel? |
| 22:01.06 | file | make it so |
| 22:01.14 | file | mjordan, yes! |
| 22:02.17 | mjordan | I leave you with: |
| 22:02.17 | mjordan | https://issues.asterisk.org/jira/browse/ASTERISK-16717 |
| 22:02.45 | *** part/#asterisk-dev mjordan (mjordan@nat/digium/x-vrcpokjvtztijphe) |
| 22:02.58 | putnopvut | I'm leaving too. |
| 22:21.43 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 22:37.21 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 22:46.18 | *** join/#asterisk-dev TazzNZ (~TazzNZ@office-nat1.ytechops.co.nz) |
| 22:51.46 | *** join/#asterisk-dev sgriepentrog (~sgriepent@162-239-32-132.lightspeed.brhmal.sbcglobal.net) |
| 22:51.59 | sgriepentrog | coreyfarrell: ping |
| 22:52.07 | coreyfarrell | sgriepentrog: pong |
| 22:52.17 | sgriepentrog | hey, I have a bit of a problem |
| 22:52.29 | coreyfarrell | uh oh is it my fault? |
| 22:52.32 | sgriepentrog | your ast_log_safe change, while itself wonderful, is breaking dpma |
| 22:52.42 | sgriepentrog | not technically your fault but want to chat with you about it. |
| 22:52.53 | coreyfarrell | ok what is dpma? |
| 22:53.03 | sgriepentrog | digium phone module for asterisk |
| 22:53.57 | sgriepentrog | So abi changes cause trouble for dpma, because it's a module that gets compiled into current asterisk, but may be loaded into any earlier asterisk of same version. |
| 22:54.29 | sgriepentrog | said that wrong. rephrase. Gets compiled against current asterisk, but is then loaded into any version, older, or in some cases newer. |
| 22:54.41 | sgriepentrog | For this reason ABI is critical. |
| 22:55.10 | coreyfarrell | so if it's compiled against 13.1.0 and loaded on 13.5.0 that's ok, but the other way around is a problem |
| 22:56.04 | sgriepentrog | Right. If you make a change, the abi has to be compatible. In the case of ast_module_ref I was able to #undef ast_module_ref in the dpma module, so it insists on using the ABI compatible version always. |
| 22:56.44 | sgriepentrog | That fixed it, but now I'm hitting the same thing on ast_log_safe, but since it's a more substantial change, I'm not sure I can use the same trick. |
| 22:57.48 | sgriepentrog | Basically, the error I'm getting when I try to module load res_digium_phone.so into 13.1 cert is that ast_log_safe() isn't found. |
| 22:58.29 | sgriepentrog | But because the ast_log_safe vs ast_log is different functionality, I'm not sure I can get away with just mapping dpma always to use the older function. |
| 22:59.05 | sgriepentrog | So what I'm wanting to do is see if we can come up with a way to workaround the problem without loosing the feature. |
| 23:00.02 | coreyfarrell | it would actually be safe to remap it from any module. a malloc failure from dpma would call ast_log, and if that had a malloc failure it would call ast_log_safe (breaking the loop) |
| 23:00.58 | sgriepentrog | Ah. okay. Is it being mapped with a #define then? I don't recall that being the case. |
| 23:01.26 | coreyfarrell | the problem is that the #define is immediately used by a static function in the same header (utils.h) |
| 23:01.43 | sgriepentrog | yup. That's a problem. |
| 23:03.19 | sgriepentrog | Assuming that dpma module gets loaded into an older version of asterisk, ast_log() is still checking the stack size - but I don't have a way of forcing ast_log_safe() back to it. |
| 23:03.32 | coreyfarrell | I have "#if !defined(STANDALONE)" in utils.h to allow utils/*.c to keep using ast_log. The easiest solution would be to make this "#if !defined(STANDALONE) && !defined(STRICTABI_AST_LOG_SAFE)" or something |
| 23:04.44 | sgriepentrog | Hm. that actually sounds very do-able. What about having a #define AST_STRICT_ABI or something that could then be used for any such module, and continue to avoid this sort of thing ongoing? |
| 23:05.06 | coreyfarrell | generic sounds like a good idea to me |
| 23:05.36 | sgriepentrog | Okay, i'll be happy to review any such improvement ;-) |
| 23:06.06 | sgriepentrog | And of course test it first on my dpma build to make sure it's doing what I need. Thanks. |
| 23:06.53 | coreyfarrell | so this should be for 11+? |
| 23:08.10 | coreyfarrell | well excluding trunk that is.. |
| 23:08.37 | sgriepentrog | Yea, that's probably a good idea. And yes, always dropped on trunk. |
| 23:09.27 | coreyfarrell | doing up a review now |
| 23:10.36 | coreyfarrell | have a ticket? |
| 23:11.44 | sgriepentrog | No, I mean, I have a issue depending on this but it's an internal one and not really related. |
| 23:11.46 | rmudgett | Wasn't the original OOM recursion more a theoretical problem anyway? |
| 23:13.12 | coreyfarrell | rmudgett: yes, the change I'm making won't allow the new function to be disabled for the core, only for a module with that define in the source.. so if DPMA has an allocation failure it will loop once |
| 23:14.45 | coreyfarrell | oh sorry I misread |
| 23:16.17 | rmudgett | The recursion problem is only when the logging_thread tries to do an OOM or ao2 failure log. Sounds like only the core needs to do the ast_log_safe while everything else can continue to use ast_log. |
| 23:17.43 | coreyfarrell | hmm, yes it's also a problem if ast_log_* has an OOM/AO2 error, but in that case the allocation failure from the logger would use ast_log_safe |
| 23:18.39 | coreyfarrell | I like that idea better than the ABI compatibility flag that must be set in the module, but I'm unsure how to '#if IN_A_MODULE'. |
| 23:19.34 | rmudgett | AST_MODULE is the module name for a core module it should be CORE |
| 23:19.56 | rmudgett | Or something like that. |
| 23:22.36 | rmudgett | AST_MODULE is defined as "core" in the main/Makefile |
| 23:23.52 | coreyfarrell | yup I see that, is it even possible to do a strcmp from a macro |
| 23:23.54 | coreyfarrell | ? |
| 23:27.25 | rmudgett | Unfortunately no. But you could change main/Makefile to define an IN_CORE to test. |
| 23:28.30 | coreyfarrell | will do.. I'm thinking I'll prefix so AST_IN_CORE.. |
| 23:29.56 | coreyfarrell | hmmm that would mean I could get replace '#if !defined(STANDALONE)' with '#if defined(AST_IN_CORE)" |
| 23:30.50 | coreyfarrell | sgriepentrog: thanks for pointing this out to me... I never really considered this kind of ABI issue. |
| 23:31.16 | sgriepentrog | Neither had I until I took over dpma builds. Has been educational. |
| 23:32.03 | sgriepentrog | It won't be long before I have some ci checking this sort of thing so we know if anything gets broken. |
| 23:43.33 | coreyfarrell | review published |
| 23:49.28 | sgriepentrog | It'll take me some time to run it through the build process. Thanks!! |
| 23:50.17 | rmudgett | Wow that change is almost trivial. |
| 23:51.12 | coreyfarrell | rmudgett: thanks for the idea on restricting to core... that's a lot better than having to set a define for binary modules |
| 23:52.16 | rmudgett | I'll let sgriepentrog ship-it after he tests it. Looks fine to me. |
| 23:52.49 | coreyfarrell | rmudgett: so I've been meaning to pester you about r4108 (weak proxy objects). |
| 23:53.21 | rmudgett | I've been avoiding it. :) |
| 23:53.28 | coreyfarrell | ha, I can understand that |
| 23:54.55 | coreyfarrell | I think I've got it thread safe. I'm not 100% happy with the ABI, specifically the callback list being published / part of user_data. |
| 23:55.50 | rmudgett | I'll have to look at it again next week. It's one of only two email's that I have marked as unread. |
