| 00:57.11 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-20-153.hsd1.sc.comcast.net) |
| 00:57.11 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 01:11.30 | *** join/#asterisk-dev Deeewayne (n=dwayne@76.29.245.9) |
| 01:11.31 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 02:02.47 | *** join/#asterisk-dev seanbright (n=sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 02:02.47 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 03:08.30 | *** join/#asterisk-dev mog (n=mog@c-68-62-169-246.hsd1.al.comcast.net) |
| 03:08.30 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 04:14.05 | *** join/#asterisk-dev putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 04:14.05 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 04:16.15 | *** join/#asterisk-dev CunningPike (n=CunningP@vpn.dnv.org) |
| 04:42.43 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-20-153.hsd1.sc.comcast.net) |
| 04:42.43 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 05:46.09 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 05:46.09 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:00.51 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 06:28.27 | *** join/#asterisk-dev Jacke (i=jacke@valhalla.bofh.org) |
| 06:28.27 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 06:28.27 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 06:44.29 | *** join/#asterisk-dev oej_ (n=olle@ns.webway.se) |
| 07:05.52 | *** join/#asterisk-dev mvanbaak (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 07:05.52 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 07:19.55 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 07:19.55 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:08.46 | *** join/#asterisk-dev ixremedy (n=ixremedy@193.110.107.130) |
| 08:09.02 | ixremedy | hello everyone |
| 08:34.29 | ixremedy | Is there anyone who wants to earn extra on additional features for *? |
| 08:35.34 | mvanbaak | ixremedy: try the -biz mailinglist |
| 09:46.11 | ixremedy | where is that? |
| 09:49.01 | tzafrir_laptop | http://lists.digium.com/ |
| 09:49.10 | tzafrir_laptop | ixremedy, ==^ |
| 09:50.07 | ixremedy | thanks |
| 09:52.34 | JunK-Y | good morning folks |
| 10:07.27 | *** join/#asterisk-dev kamanashisroy (n=kamanash@119.30.36.21) |
| 10:16.20 | ixremedy | shena |
| 10:39.58 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 11:36.04 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 11:36.04 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 11:49.27 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:58.21 | *** join/#asterisk-dev eliel (n=eliels@200.61.172.61) |
| 11:58.21 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 12:08.59 | *** join/#asterisk-dev DarkRift (n=dark@65.92.167.218) |
| 12:10.53 | eliel | morning! |
| 12:11.19 | leifmadsen | morn! |
| 12:11.22 | leifmadsen | GSoC?! |
| 12:12.03 | eliel | yes! starting |
| 12:12.39 | leifmadsen | nice nice |
| 12:12.43 | leifmadsen | what project are you working on? |
| 12:13.30 | eliel | generic data retrieval API |
| 12:19.03 | leifmadsen | nice nice |
| 12:21.57 | tzanger | eliel: my father was a pioneer in that area |
| 12:22.09 | tzanger | anytime I asked him something he'd angrily reply "Go look it up!" |
| 12:22.38 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:22.38 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:22.47 | eliel | tzanger: hehehe |
| 12:23.21 | tzanger | he used a very generic API :-) |
| 12:24.43 | eliel | kpfleming: I have a problem regarding your code in ast_agi_register(OPTIONAL_API), I have tested app_stack, and for some reason AGI command Gosub it is never being registered, it is running ast_agi_register(dummy) instead of ast_agi_register(real api). |
| 12:25.05 | eliel | tzanger: he |
| 12:25.33 | kpfleming | eliel: that seems odd |
| 12:25.36 | kpfleming | what platform are you running on? |
| 12:25.46 | eliel | debian |
| 12:26.38 | eliel | is there something i could test, i have check for the returning code of the function and is returning what the dummy api is returning... |
| 12:27.51 | kpfleming | no, it just needs to be opened as an issue on the tracker and assigned to me, i guess |
| 12:35.51 | eliel | M15193 |
| 12:35.53 | MuffinMan | [assigned] [Asterisk] Applications/app_stack 0015193: Gosub AGI command is not being registered. reported by eliel (Karma: +184.50) https://issues.asterisk.org/view.php?id=15193 |
| 13:23.59 | *** join/#asterisk-dev philippel (n=p_lindhe@pool-98-111-74-92.sttlwa.fios.verizon.net) |
| 13:32.02 | Corydon76-dig | eliel: load res_agi.so BEFORE app_stack.so |
| 13:33.09 | eliel | Corydon76-dig: i tried unloading app_stack and loading it again when res_agi was loaded and nothing happens |
| 13:53.34 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 13:53.34 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 13:58.19 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 13:58.19 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:02.02 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 14:02.02 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 14:04.03 | *** join/#asterisk-dev Curus (n=Curus@94.127.50.7) |
| 14:04.33 | Curus | I suppose this is more of an svn question... How do I find out whether r169611 is in 1.6.0.9? |
| 14:04.51 | kpfleming | look at the ChangeLog |
| 14:05.06 | Curus | I did, the ChangeLog doesn't mention that revision or the issue it fixes |
| 14:05.12 | kpfleming | then it's not in there |
| 14:05.20 | kpfleming | the ChangeLog includes every revision in the release |
| 14:05.33 | Curus | Thanks |
| 14:06.09 | Curus | Now I just need to find out who to poke about getting it into 1.6.0.10 :) |
| 14:06.32 | seanbright | what issue number was this? |
| 14:06.36 | leifmadsen | Curus: if it is already in the 1.6.0 branch, then it'll be in 1.6.0.10 when it is made |
| 14:06.46 | leifmadsen | i.e. it is already committed to 1.6.0 |
| 14:07.35 | Curus | leifmadsen: It was in 1.6.0 branch around 1.6.0.4, if issues.asterisk.org is to be believed. |
| 14:07.43 | seanbright | what |
| 14:07.44 | seanbright | issue |
| 14:07.45 | Curus | Issue 14014 |
| 14:07.46 | seanbright | number? |
| 14:07.48 | MuffinMan | [closed] [Asterisk] Applications/app_queue 0014014: [patch] DAHDI group dials/members broken with AddQueueMember / queue member add reported by kebl0155 (Karma: +2.00) https://issues.asterisk.org/view.php?id=14014 |
| 14:08.15 | *** join/#asterisk-dev jtodd (i=lokb0tng@ns.fox-den.com) |
| 14:08.15 | *** mode/#asterisk-dev [+o jtodd] by ChanServ |
| 14:08.36 | leifmadsen | it's r169612 |
| 14:08.42 | leifmadsen | not 169611 |
| 14:08.56 | kpfleming | eliel: have you confirmed that res_agi is being loaded before app_stack? |
| 14:09.01 | leifmadsen | Curus: https://issues.asterisk.org/view.php?id=14014#98291 |
| 14:09.21 | Curus | leifmadsen: 169612 isn't mentioned in the ChangeLog either |
| 14:09.43 | eliel | kpfleming: yes, 'agi show commands topic <agi command>' shows the list of agi commands already registered. |
| 14:09.54 | kpfleming | that's not what i askewd |
| 14:10.01 | kpfleming | was it loaded *before* app_stack? |
| 14:10.46 | eliel | 1) manager.conf shows: load=> res_agi.so and then load => app_stack.so |
| 14:10.53 | kpfleming | ok, good |
| 14:11.01 | eliel | 2) i have tested unloading app_stack and the loading it again |
| 14:11.09 | kpfleming | alright, thanks |
| 14:11.11 | eliel | (having res_agi already loaded) |
| 14:11.25 | Curus | Anyway, I RTFS, and that change is in there |
| 14:11.41 | eliel | RTFS? |
| 14:11.48 | seanbright | source |
| 14:11.54 | seanbright | read the eff'n source |
| 14:12.14 | seanbright | and yeah, the ChangeLog looks to have been flubbered around the time of those commits for whatever reason |
| 14:12.25 | seanbright | the referenced change is in that tag. |
| 14:12.28 | eliel | seanbright: thanks |
| 14:12.34 | kpfleming | eliel: can you send me (or attach to the bug) your include/asterisk/autoconfig.h? |
| 14:12.53 | eliel | kpfleming: yes |
| 14:13.24 | Curus | Anyway, that means it isn't that particular bug which causes my agents to go Invalid. Off to debug some more. |
| 14:15.38 | seanbright | Curus: good luck and god speed. |
| 14:16.33 | Curus | Thanks |
| 14:17.03 | eliel | kpfleming: file uploaded |
| 14:17.08 | kpfleming | thanks |
| 14:18.03 | kpfleming | ok, that looks normal |
| 14:18.03 | kpfleming | that's pretty odd indeed |
| 14:18.10 | eliel | you couldn't reproduce it? |
| 14:18.23 | kpfleming | still working on it |
| 14:21.48 | philippel | putnopvut you up/around yet |
| 14:21.56 | putnopvut | philippel: I am! |
| 14:22.11 | putnopvut | I see you've been doing work on that issue we discussed. |
| 14:22.17 | philippel | hey, concerning the queues and hints for devices: https://issues.asterisk.org/view.php?id=15168 |
| 14:22.29 | philippel | I put in a patch that does it (though on 1.4) |
| 14:23.01 | philippel | given how many years of rust there is on my C coding, and minimal in Asterisk, I'm sure there is room for improvment but ... |
| 14:23.15 | putnopvut | philippel: cool. I'll take a look at it as soon as I get a chance. Thanks for taking the time to write it! |
| 14:23.21 | philippel | the initial testing I've been doing seems to work. |
| 14:23.30 | philippel | putnopvut it did uncover a 'bug' in the existing code |
| 14:23.47 | putnopvut | What's that? |
| 14:23.49 | philippel | if you are using the backport of func_devstate.c in 1.4, the queue code ignores the device state changes |
| 14:24.14 | philippel | the current code only accepts devices that are in the forma of technology/nnn |
| 14:24.56 | putnopvut | Ah yes. That was a bug in 1.6 for a little while too. 1.4's code only expects that format for device state since func_devstate isn't actually part of 1.4 |
| 14:25.23 | atis_work | was func_devstate usable for something more than custom device states? |
| 14:25.44 | putnopvut | atis_work: I think you can read the state of real devices with func_devstate. |
| 14:25.47 | philippel | putnopvut understand which is why I said it was a 'bug' - however, if the code is going to be backported, given the large number of users running that backport, it would seem to make sense that the queue code would recognize that |
| 14:25.50 | atis_work | aah |
| 14:26.03 | eliel | kpfleming: my autoconfig.h shows that i don't have weak_import support, maybe that helps... (??) just shooting ideas |
| 14:26.04 | atis_work | i tried playing with it's backport, but it didn't fit me for app_queue :) |
| 14:26.17 | kpfleming | eliel: no, weak_import is only Mac OSX |
| 14:26.58 | atis_work | eliel: Hey, do you mind if i commit my queue_member to per_member_wrapuptime branch? |
| 14:27.23 | atis_work | eliel: it's still work in progres.. i found some more things i have to put in from my patches |
| 14:27.39 | atis_work | putnopvut: btw - a question to you |
| 14:27.56 | atis_work | putnopvut: i hope you wouln't mind |
| 14:28.05 | putnopvut | atis_work: sure, what's up? |
| 14:28.22 | atis_work | I plan to set lastcall upon queue login, so it always shows last activity of agent |
| 14:28.41 | atis_work | queue show would then display "Status changed %d secs ago" |
| 14:28.45 | eliel | atis_work: do it, no problem, one thing i don't like about that patch are all those #define's move them to a struct { enum option_type, char[] option_name } |
| 14:29.16 | kpfleming | eliel: i have reproduced it on my system |
| 14:29.21 | atis_work | eliel: sorry for my C, but how do i access them that way? |
| 14:29.22 | eliel | good |
| 14:29.50 | putnopvut | atis_work: The only problem with setting lastcall on queue login that I can think of is that it could cause some unexpected results for people using the leastrecent strategy. |
| 14:30.37 | atis_work | putnopvut: well, i think it's more fair. if agent A logs in at 12:00 and agent B logs in at 13:00, and call comes in, it will first go to agent A, not treat them equal |
| 14:31.00 | atis_work | that's why i done that :) |
| 14:31.28 | atis_work | or.. it could be left customizable through new QUEUE_MEMBER function |
| 14:31.59 | putnopvut | I think it's not a good idea to make lastcall customizable. |
| 14:32.05 | atis_work | ok :) |
| 14:32.26 | atis_work | didn't thought of that before.. that patch was done before i had QUEUE_MEMBER_PARAM.. |
| 14:33.18 | atis_work | putnopvut: btw, i saw lot of removed add_to_interfaces and remove_from_interfaces in trunk |
| 14:33.44 | putnopvut | Right, that's because the interfaces list has been removed in trunk. |
| 14:33.51 | eliel | atis_work: enum member_option { MEMBER_OPTION_PENALTY = 0, ...}; then ... -> member_option[MEMBER_OPTION_PENALTY] having char const * const member_option[] |
| 14:34.06 | atis_work | putnopvut: how do they work now? just iterate through queue members? |
| 14:34.19 | putnopvut | atis_work: yes, that is generally how it is done now. |
| 14:34.22 | atis_work | eliel: thanks :) |
| 14:35.26 | eliel | atis_work: remember that we can not remove QUEUE_MEMBER_COUNT, QUEUE_MEMBER_PENALTY, etc... we will need to live them, we can change the implementation, but the function needs to be there with the same name... |
| 14:35.42 | atis_work | eliel: sure, it's in place :) |
| 14:36.13 | atis_work | actually QUEUE_MEMBER_COUNT does what it did before, plus the "logged" and "free" stuff.. |
| 14:36.24 | atis_work | and _PENALTY, etc are just wrappers |
| 14:37.13 | atis_work | btw, how is the astdb -> realtime conversion going on? |
| 14:37.20 | atis_work | does oej finished it? |
| 14:37.22 | eliel | ok, don't know why your latest patch doesn't show that (??) hehe |
| 14:38.28 | atis_work | eliel: it does |
| 14:38.35 | atis_work | you just have to look more carefully |
| 14:38.51 | atis_work | -<function name="QUEUE_MEMBER" language="en_US"> +<function name="QUEUE_MEMBER_COUNT" language="en_US"> |
| 14:39.34 | eliel | atis_work: oooh, you are right, sorry |
| 14:39.47 | atis_work | so, regarding that astdb->realtime.. it would be really nice, as currently persistent members are kind of screwed |
| 14:40.15 | atis_work | they lack membername, and everybody tends to forget about them when adding new fields |
| 14:47.23 | *** join/#asterisk-dev |Cybex| (n=John@80.100.126.176) |
| 14:49.38 | *** join/#asterisk-dev CunningPike (n=CunningP@204.239.10.119) |
| 14:51.50 | *** join/#asterisk-dev Deeewayne (n=dwayne@75.76.254.162) |
| 14:51.50 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 14:59.29 | oej | what about me? |
| 14:59.40 | oej | I never finish anything, can't even complete writing invoices this month... |
| 15:00.06 | *** join/#asterisk-dev JunK-Y (n=junky@modemcable206.69-20-96.mc.videotron.ca) |
| 15:00.33 | oej | but the astdb->realtime stuff is in heavy load-testing this week, after that we'll decide where to go with it |
| 15:00.51 | oej | If everything works out fine, I'll complete the stuff and move it through reviewboard |
| 15:06.24 | Juggie | oej, is that multiple registrations per sip peer patch going to go anywhere. |
| 15:07.29 | Juggie | tries to find the bug # |
| 15:07.53 | Juggie | 14514 |
| 15:08.09 | seanbright | issue 14514 |
| 15:08.11 | MuffinMan | [assigned] [Asterisk] Channels/chan_sip/NewFeature 0014514: [patch] SIP Forking Feature reported by Shivaprakash (Karma: neutral) https://issues.asterisk.org/view.php?id=14514 |
| 15:08.35 | kpfleming | i do not see why we would want to support that |
| 15:08.53 | tzanger | everyone likes a good forking |
| 15:08.56 | oej | I was hoping that was closed a long time ago |
| 15:08.57 | seanbright | ba dum dum |
| 15:09.04 | russellb | kpfleming: oej: agreed |
| 15:09.16 | russellb | I assigned to myself to close it out and then never did I guess, heh |
| 15:09.31 | oej | There are ways to do that I can accept, but then we have to push new devices forward all the way to the core and integrate them magically in the dial string |
| 15:09.49 | tzanger | I haven't seen cresl1n around in a long time... what did you guys do to him? |
| 15:09.59 | oej | All tricks to bypass the pbx and the dialplan are BAD and evil. |
| 15:10.19 | Juggie | i like the idea of being able to have multiple active registrations per sip peer. |
| 15:10.30 | Juggie | but it comes with its own set of problems |
| 15:13.58 | oej | Juggie: While it might make life easier, it's also a way to loose some control. And a pbx is about being in control of how many phones we have... |
| 15:15.48 | Juggie | its is a interesting issue |
| 15:16.21 | Juggie | the easy way is definitally to make chan_sip take the peer your dialing on and explode that into all the registered peers |
| 15:16.31 | Juggie | but that as you said puts the logic in a place we dont want it |
| 15:17.11 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 15:50.16 | *** join/#asterisk-dev marv[work] (n=timr@router.asteriasgi.com) |
| 15:50.47 | *** join/#asterisk-dev ajohnson (n=ajohnson@63.147.46.186) |
| 16:00.52 | putnopvut | I was hoping I was wrong, but I have just proven in my testing that at some point, it is possible for a channel to "lose" its cid.cid_name. When the channel is allocated, the name is a non-empty string, and then later on, I test and it is empty. It will be a *joy* to figure out where this problem is occurring. </rant> |
| 16:01.45 | Juggie | :) |
| 16:01.48 | kpfleming | eliel: so i can confirm the behavior you are seeing in asterisk, but in a small test application that does the same things that asterisk does, it does not fail |
| 16:01.52 | kpfleming | this is bizarre |
| 16:07.03 | eliel | kpfleming: hmmm, i tried to look at your optional_api implementation but is too much for me... |
| 16:07.20 | kpfleming | no worries... i'm on the track now |
| 16:26.09 | *** join/#asterisk-dev jsmith (n=jsmith@asterisk/training-and-documentation-guru/jsmith) |
| 16:26.09 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 16:30.49 | putnopvut | Could someone verify something for me? Update your 1.4 branch to the tip and open app_dial.c. Take a look at line 1363. To me, the logic of the ast_test_flag call seems reversed. It seems like if the 'o' option is _not_ specified, then we will set the callerid for the outgoing channel to be the same as what was set on the incoming channel. |
| 16:32.23 | putnopvut | I'm thinking that the ! should be removed from that if statement. |
| 16:33.35 | seanbright | putnopvut: could you verify something for me in the meantime? |
| 16:33.47 | putnopvut | seanbright: I may be able to. What do you need? |
| 16:34.07 | seanbright | handle_statechange in app_queue in trunk |
| 16:34.28 | putnopvut | I'm looking at it right now.. |
| 16:34.29 | seanbright | shouldn't there be a ao2_ref(q, -1); after the ao2_unlock(q) |
| 16:34.30 | seanbright | ? |
| 16:34.44 | seanbright | adding that makes my refcounts be the same before and after a call |
| 16:34.51 | seanbright | otherwise they keep increasing |
| 16:34.53 | putnopvut | Yes, that should be there. Good catch. |
| 16:34.57 | seanbright | k |
| 16:34.59 | seanbright | will commit |
| 16:35.09 | putnopvut | Thanks! |
| 16:35.42 | putnopvut | Going for a walk. I'll check for replies to my comment when I get back. |
| 16:42.17 | tzanger | http://gamesbyemail.com/News/DiceOMatic |
| 16:42.21 | tzanger | that is all kinds of awesome |
| 16:42.30 | tzanger | we should use that for an entropy pool for srtp |
| 16:44.02 | tzanger | .. or as a noise source (the machine noise, not the dice rolls) |
| 16:45.40 | eliel | thinks that it will be a good practice to have the list of OBJS in main/Makefile one per line to avoid many conflicts in branches when adding a new file inside main/ |
| 16:50.03 | *** join/#asterisk-dev anonymouz666 (n=anonymou@189.24.138.206) |
| 17:16.21 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 17:29.14 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 17:49.21 | *** join/#asterisk-dev jetsnoc (n=brian@root.pmt.org) |
| 18:00.43 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 18:00.43 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:01.19 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 18:01.19 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:16.33 | *** join/#asterisk-dev eliel_ (n=eliels@200.61.172.61) |
| 18:23.45 | seanbright | putnopvut: a little late, but your analysis seems correct to me. |
| 18:24.09 | putnopvut | seanbright: Cool, man. |
| 18:24.18 | seanbright | ofcourse, that was done in revision 6955 |
| 18:24.23 | seanbright | and no one has reported it as an issue |
| 18:24.35 | seanbright | so that makes me wary |
| 18:24.35 | seanbright | :) |
| 18:24.37 | putnopvut | Yeah, I did some research and really it may just be that the option is documented extra-crappily. |
| 18:25.04 | seanbright | well, let's be honest... the fact that it is documented at all is a minor miracle :P |
| 18:25.09 | putnopvut | heh |
| 18:30.25 | *** join/#asterisk-dev eliel (n=eliels@200.61.172.61) |
| 18:30.25 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 18:30.49 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 18:33.17 | jsmith | putnopvut: Crappy documentation... surely you jest! |
| 18:33.39 | jsmith | putnopvut: I've been trying to grok the *one true* meaning of that option for years |
| 18:34.29 | putnopvut | jsmith: well, let me tell you what I'm seeing here. |
| 18:34.56 | jsmith | putnopvut: Please do! |
| 18:36.33 | putnopvut | If you do not have that option enabled, then app_dial will write the incoming channel's extension as the CID number and the incoming channel's "app data" as the CID name for the outgoing channel. |
| 18:36.52 | putnopvut | If you DO have the option enabled, then app_dial does not touch the outgoing channel's CID at all. |
| 18:38.17 | russellb | I believe that was the intention of the option. the 'o' version was the old behavior |
| 18:38.29 | russellb | where it left the callerid on the outbound channel to be the cid that was on the inbound channel |
| 18:38.39 | putnopvut | russellb: well, here's the problem, though... |
| 18:39.03 | putnopvut | the CID on the outbound channel is not the CID from the inbound channel if you enable the 'o' option. |
| 18:39.18 | putnopvut | THe CID on the outbound channel is whatever was passed to ast_channel_alloc for the cid name and number. |
| 18:39.34 | putnopvut | In the case of dialing a SIP peer, we fill in the configured callerid name and number for that SIP peer. |
| 18:40.07 | russellb | Well, in the past, it was set to the CID of the inbound channel, IIRC |
| 18:40.14 | russellb | we're going back to 1.0 days here, my memory is very fuzzy |
| 18:40.19 | putnopvut | Yeah, I can understand. |
| 18:40.28 | putnopvut | My memory is a bit fuzzy about 1.6.1 :P |
| 18:40.31 | russellb | :-) |
| 18:41.00 | russellb | We should probably look back at 1.2 to see what that did with respect to this |
| 18:41.09 | russellb | We probably accidentally changed up the behavior at some point |
| 18:41.26 | putnopvut | Basically what I'm finding here is that it is not a good idea to try to rely on an outbound channel's cid to determine what should be sent as connected line info to the inbound channel. |
| 18:41.28 | jsmith | OK, that's what it appears like to me |
| 18:41.55 | russellb | putnopvut: Yeah, that sounds like a reasonable statement. |
| 18:42.16 | russellb | I would think that if the callerid was explicitly configured, then that would be okay |
| 18:42.29 | russellb | but otherwise, the things we make up to put there ... *shrugs* |
| 18:42.41 | russellb | Well, what we make up, the extension that got called, should be reasonable, too |
| 18:43.07 | russellb | Maybe it's not what people expect, but that's the only information available at that point in time |
| 18:57.00 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 18:57.00 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:57.40 | kpfleming | nobody expects the spanish inquisition |
| 19:01.59 | seanbright | your daily quota of monty python references (1 of 1) has been exceeded |
| 19:05.32 | kpfleming | nudge nudge |
| 19:05.53 | file | poke prod |
| 19:06.17 | Juggie | i expect two inquisitions |
| 19:18.13 | kpfleming | ok, menuselect in trunk is now officially broken. i just ran 'make menuselect' and disabled two modules in apps, and 'make' is rebuilding the whole tree |
| 19:18.26 | kpfleming | that seems very wrong |
| 19:19.00 | russellb | blames seanbright |
| 19:22.49 | kpfleming | what is our official policy on header files including the header files they need? is that the right method, or is the user of the header file supposed to do that? |
| 19:23.38 | russellb | I think rizzo added a section to the guidelines regarding headers. I haven't read it in a while, but IMO, they should all include what they need. |
| 19:59.03 | seanbright | i didn't break menuselect. |
| 19:59.07 | seanbright | well. i may have. |
| 19:59.17 | seanbright | speaking of policy... |
| 19:59.26 | kpfleming | it's inconsistent, as well |
| 19:59.29 | seanbright | adding new name/value pairs to manager messages |
| 19:59.34 | kpfleming | i turned off chan_agent, everything was fine |
| 19:59.40 | kpfleming | turned off chan_dahdi, got a whole tree recompile |
| 19:59.50 | seanbright | add them at the end even if it makes more sense to put them elsewhere? |
| 20:00.08 | seanbright | kpfleming: the menuselect code itself hasn't been touched in a while |
| 20:00.31 | seanbright | i think you were the last one to touch it, actually |
| 20:00.32 | seanbright | heh |
| 20:02.19 | seanbright | i will take a look. that code is just hard to debug. |
| 20:02.52 | eliel | autotools hard to debug??? naaah hehe |
| 20:03.34 | Corydon76-dig | He be in a meeting |
| 20:03.58 | seanbright | autotools aren't so bad |
| 20:04.02 | seanbright | menuselect is painful |
| 20:04.07 | seanbright | blames russellb |
| 20:04.20 | Corydon76-dig | He be in a meeting, too |
| 20:04.41 | seanbright | he'll see it :) |
| 20:05.18 | Corydon76-dig | Not if I see it first! |
| 20:05.48 | Corydon76-dig | sees your blame and raises you an annotate |
| 20:06.20 | tzafrir_laptop | menuselect's fault? menuselect touches files? |
| 20:07.50 | tzafrir_laptop | worries Corydon76-dig will start praising soon |
| 20:09.07 | *** join/#asterisk-dev moy (n=moy@74.12.123.90) |
| 20:11.21 | seanbright | so back to my query... |
| 20:11.34 | seanbright | M15001 |
| 20:11.35 | MuffinMan | [new] [Asterisk] Core/ManagerInterface 0015001: [patch] CoreShowChannels Response does not honor actionid reported by sum (Karma: neutral) https://issues.asterisk.org/view.php?id=15001 |
| 20:11.54 | seanbright | is the correct fix for this to just include the ActionID where it "should" be? or for BC we should put it at the end? |
| 20:12.39 | seanbright | i always assumed people threw these things into a hashtable and looked up info by key, but i've been told that people may be relying on name/value pair ordering |
| 20:13.59 | eliel | seanbright: take a look at main/manager.c(astman_send_listack) |
| 20:14.56 | jsmith | seanbright: Pair ordering shouldn't matter... if someone writes an AMI library that depends on certain key/value pairs coming before others, it's their problem, not ours. |
| 20:15.00 | eliel | thought it was up to the API to set the actionid, but now i see it is not... |
| 20:16.22 | eliel | thinks astman_append should be responsable to appending an ActionID |
| 20:17.26 | seanbright | jsmith: works for me. |
| 20:20.47 | jsmith | seanbright: That being said, I haven't looked at the bug to see if it's at all related to that |
| 20:21.11 | jsmith | seanbright: In general, if you set an ActionID on a manager command, you should get that ActionID back in the response, but you already know that |
| 20:23.08 | seanbright | yes indeed. |
| 20:33.17 | seanbright | we're certainly not consistent in the actionid department. another janitor project mayhaps. |
| 20:33.43 | seanbright | hmmm |
| 20:33.49 | seanbright | well here's the thing |
| 20:34.16 | seanbright | Reponse: Success -> Message: ListOfThings Will Follow -> ActionID: 1234 |
| 20:34.22 | seanbright | item1, item2, item3 |
| 20:34.37 | seanbright | Event: WeAreDone -> ActionID: 1234 |
| 20:34.44 | seanbright | do the individual items really need the actionid? |
| 20:35.20 | Juggie | possibly |
| 20:35.37 | eliel | the year in the files copyright, is the year that file was created? |
| 20:35.58 | Juggie | seanbright: depends if when that message is added to the queue of messages to be sent outbound if there is no way for another message to get in the middle |
| 20:36.10 | Juggie | presumabally there is not since thats how AMI operates |
| 20:36.26 | seanbright | another message could get in the middle |
| 20:36.42 | seanbright | you could have two threads running the same command from different threads |
| 20:36.46 | seanbright | i think |
| 20:36.48 | seanbright | :) |
| 20:36.50 | Juggie | i dont think so |
| 20:36.52 | Juggie | but maybe i'm wrong |
| 20:36.55 | seanbright | hmm |
| 20:36.59 | Juggie | the whole message is written to the queue to be sent |
| 20:37.07 | Juggie | not in pieces i dont think |
| 20:37.14 | seanbright | no, it's in pieces |
| 20:37.19 | Juggie | if it was in pieces then that would break the whole model of AMI |
| 20:37.20 | Corydon76-dig | eliel: copyright year is the first year it was published, which may not necessarily correspond to creation date |
| 20:37.34 | seanbright | Juggie: how? |
| 20:37.43 | seanbright | well first... describe the "model" of AMI |
| 20:37.55 | eliel | Corydon76-dig: oh, ok, audiohooks are very old! (1999) ? |
| 20:38.10 | seanbright | eliel: file forgot to update the copyright :) |
| 20:38.29 | Juggie | seanbright, if multiple responses came back mixed togethter that would be a problem |
| 20:39.18 | Juggie | well i guess responses is a bad example since ami would send the response to only the thread that requested it |
| 20:39.30 | Juggie | but it two events occur at once they have to appear on the socket sequentially. |
| 20:40.15 | seanbright | indeed. |
| 20:41.34 | Juggie | so ya so long as only one thread can see the response then it should be ok to not have the actionID |
| 20:41.42 | Juggie | so long as an event would not occur in the middle |
| 20:42.25 | seanbright | well even if an event occurred in the middle, it wouldn't be the same event that you were looking for if you were reading in the response from another command |
| 20:42.40 | seanbright | so i think not including ActionID (in this particular case) is safe |
| 20:42.52 | seanbright | since the response and CoreShowChannelsComplete event have the ActionID |
| 20:43.37 | Juggie | well if the event spit out in between your Message:Listofthings will folllow & Event:WeAreDone |
| 20:43.44 | Juggie | then that would be intrpreted as data to the far end |
| 20:43.51 | Juggie | er, could be. |
| 20:48.07 | eliel | I think if you run multiple actions they will be executed in sequence, so, it won't be a problem, you just need the actionid at the start of the list... |
| 20:49.50 | eliel | if an event occurs in the middle, it will be another event with another event name, not the one you are trying to receive. |
| 20:50.46 | Juggie | ya, the model is in sqeunce |
| 20:50.51 | Juggie | *sequence |
| 20:51.21 | kpfleming | you should always include ActionIDs in every new manager command's responses |
| 20:52.00 | seanbright | even on individual items within a list of items? |
| 20:57.40 | Juggie | seanbright, so long as you call manager_event() once it should be fine |
| 20:57.46 | Juggie | but if your calling it multiple times to print your list |
| 20:57.51 | Juggie | then you'll need it for sure |
| 20:58.09 | seanbright | i'm so confused |
| 20:58.32 | seanbright | let's pretend there is a command ListThings |
| 20:58.41 | seanbright | so i run ListThings and get back: |
| 20:58.54 | seanbright | ListThingsStarted\r\nActionID: whatever |
| 20:58.57 | kpfleming | manager_event() is not how you respond to actions |
| 20:58.58 | seanbright | Thing |
| 20:59.09 | kpfleming | yes, that is fine |
| 20:59.10 | seanbright | ListThingsComplete\r\nActionID: whatever |
| 20:59.15 | kpfleming | that is how other actions work |
| 20:59.22 | seanbright | not all of them, but right. |
| 20:59.24 | kpfleming | the only thing that can intervene with that is events |
| 20:59.36 | seanbright | and you aren't going to get a random "Thing" event |
| 20:59.39 | kpfleming | and in 1.6, even events won't be intermixed |
| 20:59.43 | kpfleming | correct |
| 20:59.47 | seanbright | excellent. |
| 21:00.05 | kpfleming | as long as you astman_append() all your stuff, then it will all be spit out as a single blob |
| 21:00.14 | seanbright | excellent |
| 21:01.26 | Juggie | i tried to say that :P |
| 21:01.43 | seanbright | you didn't do a good job |
| 21:01.44 | Juggie | not sure where it got lost in translation, i said previously if you wrote it to the socket as one message you'd be fine. |
| 21:01.48 | seanbright | you speak canadian |
| 21:01.49 | seanbright | :) |
| 21:02.07 | kpfleming | but we don't write to sockets like that now. because the output could get translated into another form. |
| 21:02.12 | seanbright | because as a user of the manager api you don't write to a socket |
| 21:02.15 | kpfleming | the responses are built up in a buffer |
| 21:02.20 | kpfleming | seanbright: jinx |
| 21:02.25 | Juggie | well ya i know i was simplifying it |
| 21:02.33 | Juggie | as i dont have the function name memorized. |
| 21:02.50 | Juggie | like the rest of you :) |
| 21:03.02 | seanbright | you only have your girlfriend to blame |
| 21:03.07 | Juggie | its so true |
| 21:03.10 | Juggie | i have i think |
| 21:03.22 | Juggie | 2% of the free time i had in my previous bachlor life |
| 21:03.48 | Juggie | shes going out of town for 3 weeks though in a couple of weeks to visit her mom (cancer surgery) |
| 21:03.52 | Juggie | so maybe i'll do something creative |
| 21:16.35 | Corydon76-dig | Creative... like finish testing SRTP? |
| 21:16.57 | Juggie | hmmmmm |
| 21:17.08 | Juggie | i think i have a phone which supports SRTP |
| 21:17.11 | Corydon76-dig | Or creative... like TP'ing your supervisor's house |
| 21:17.36 | Juggie | not sure what SRTP implemention mitel has |
| 21:35.13 | ajohnson | Interesting bug... The console color does not get reset properly on 1.6.2-beta2 when using helps that contain color, like core show function <functionname> |
| 21:36.27 | russellb | ajohnson: aw, and you bring it up just after the guy that wrote the code left :-) |
| 21:36.35 | ajohnson | heh |
| 21:36.44 | ajohnson | Does that go under General on the bug tracker? |
| 21:36.49 | russellb | I guess so |
| 21:36.54 | russellb | Core/General I suppose |
| 21:37.08 | russellb | unless there is a Core/CLI |
| 21:37.22 | jsmith | ajohnson: I've seen it before too, but haven't taken the time to track it down. I think it's related to the XML documentation stuff |
| 21:37.25 | ajohnson | okie dokie, thanks |
| 21:37.43 | russellb | indeed, if you could point out a command that demonstrates it, that would be really helpful |
| 21:37.48 | russellb | and hopefully it happens every time, heh |
| 21:37.57 | seanbright | it leaves the prompt bold |
| 21:38.00 | seanbright | "bright white" for me |
| 21:38.08 | ajohnson | yeah |
| 21:38.17 | ajohnson | severity = text/minor/trivial? |
| 21:38.23 | russellb | text i guess |
| 21:38.25 | ajohnson | I can |
| 21:38.27 | russellb | if it's still readable :-) |
| 21:38.46 | ajohnson | core show function FILTER will do it every time |
| 21:38.51 | russellb | excellent |
| 21:39.36 | russellb | so now the next thing to do is to determine what is special about FILTER |
| 21:39.44 | russellb | It looks like the description ends in a <note></note> |
| 21:40.03 | ajohnson | core show application AddQueueMember does it too |
| 21:40.31 | ajohnson | actually, it looks like any core shore application or core show function does it |
| 21:40.39 | russellb | heh, well then. |
| 21:43.15 | ajohnson | of course it is reset as soon as the next color code is sent |
| 21:44.48 | seanbright | heh... |
| 21:44.52 | seanbright | ast_term_color_code(&colorized, COLOR_BRWHITE, 0); |
| 21:45.04 | seanbright | right at the end of ast_xmldoc_printable |
| 21:45.07 | russellb | :-) |
| 21:45.26 | ajohnson | well thar she be |
| 21:45.51 | seanbright | just needs to be changed to whatever the default fg is |
| 21:45.57 | seanbright | however you figure that out. |
| 21:45.57 | ajohnson | https://issues.asterisk.org/view.php?id=15200 is the ticket I put in |
| 21:47.09 | seanbright | assign to eliel |
| 21:47.11 | seanbright | :) |
| 22:04.20 | seanbright | this term.c code makes my head want to explode |
| 22:05.17 | putnopvut | heh |
| 22:05.24 | putnopvut | I say the same thing about SIP transfers. |
| 22:09.30 | Corydon76-dig | seanbright: I think I wrote a good portion of that term.c code |
| 22:09.46 | Corydon76-dig | Glad to hear it's having the desired effect. ;-) |
| 22:10.31 | seanbright | heh |
| 22:10.36 | seanbright | ajohnson: can you test a patch? |
| 22:11.21 | Corydon76-dig | btw, ajohnson is truly a joy to work with on bugs. He tests patches and returns with results quickly |
| 22:11.31 | Corydon76-dig | nominates him for reporter of the year |
| 22:12.42 | seanbright | Corydon76-dig: could you take a look at the patch i just uploaded for 15200? make sure the ast_term_reset() function is correct? |
| 22:12.45 | seanbright | M15200 |
| 22:12.47 | MuffinMan | [new] [Asterisk] Core/General 0015200: [patch] Certain console helps leaves prompt in bold mode (bright white) reported by ajohnson (Karma: +1.00) https://issues.asterisk.org/view.php?id=15200 |
| 22:14.25 | Corydon76-dig | seanbright: You MAY need the 0; in there in the first case, too |
| 22:14.50 | Corydon76-dig | Otherwise, it might not reset the bright attribute |
| 22:16.08 | Corydon76-dig | assuming the bright attribute was even the last thing set |
| 22:16.50 | seanbright | k |
| 22:17.14 | Corydon76-dig | seanbright: and I wonder why you don't just go with term_end() |
| 22:17.25 | seanbright | does that do the same thing? |
| 22:17.30 | Corydon76-dig | Yes |
| 22:17.35 | seanbright | then i'll use that. |
| 22:17.38 | Corydon76-dig | and deals with all 3 cases |
| 22:19.35 | seanbright | hmmm |
| 22:19.41 | seanbright | i need a version that writes to an ast_str |
| 22:19.55 | seanbright | so i'll just change the new function to write enddata instead of calling term_end() |
| 22:20.16 | Corydon76-dig | term_end just returns a string, that you can ast_str_append |
| 22:20.20 | ajohnson | Corydon76-dig: Will test it out now |
| 22:20.25 | seanbright | heh |
| 22:20.34 | seanbright | ajohnson: hold on a sec |
| 22:20.36 | seanbright | let me update it first |
| 22:20.43 | ajohnson | ok |
| 22:20.53 | Corydon76-dig | seanbright: he's got 2 different bugs that he's testing |
| 22:20.59 | ajohnson | Corydon76-dig: I turned pooling off, hopefully that won't hurt the test |
| 22:21.24 | Corydon76-dig | ajohnson: shouldn't on that test |
| 22:21.32 | Corydon76-dig | ajohnson: you're using transactions, though? |
| 22:21.47 | seanbright | ohh |
| 22:21.48 | ajohnson | Not by my choice |
| 22:22.05 | ajohnson | it must be doing it, I see it sending transactional statements in the MySQL query debugging |
| 22:22.25 | Corydon76-dig | Hrm |
| 22:22.37 | Corydon76-dig | Well, we'll see what comes up in debugging |
| 22:23.12 | Corydon76-dig | delete /tmp/refs first, if you would |
| 22:23.25 | Corydon76-dig | I'm sure it has a ton of messages now |
| 22:23.47 | ajohnson | it does, I will |
| 22:24.15 | seanbright | ajohnson: new (much shorter) patch uploaded for 15200. no rush, just letting you know. |
| 22:24.25 | ajohnson | I'm testing both right now |
| 22:24.57 | seanbright | cool. |
| 22:24.57 | ajohnson | well... as soon as it compiles, which is a lot longer with dev mode turned on in ./configure |
| 22:25.14 | seanbright | you should try it with DONT_OPTIMIZE enabled too |
| 22:25.46 | ajohnson | DONT_OPTIMIZE is turned on. |
| 22:25.49 | seanbright | ahhh |
| 22:25.52 | seanbright | yeah, that sucks. |
| 22:26.05 | ajohnson | double compiling |
| 22:28.17 | ajohnson | Corydon76-dig: Error while compiling |
| 22:40.57 | ajohnson | seanbright: Works great |
| 22:41.35 | seanbright | ajohnson: the new patch or the old? |
| 22:41.39 | seanbright | (new one is a one-liner) |
| 22:41.41 | ajohnson | new patch |
| 22:41.43 | seanbright | cool |
| 22:43.13 | ajohnson | now if only someone could look at the ODBC voicemail storage issue... |
| 22:50.26 | kpfleming | someone could |
| 22:50.32 | kpfleming | but then... well, stuff would happen |
| 22:51.00 | seanbright | bad stuff? good stuff? normal stuff? |
| 22:51.36 | ajohnson | Well... I could, and then it would be bad stuff |
| 22:54.03 | ajohnson | Corydon76-dig: If you're still around, I'll hang out. Otherwise, I'm going to head home to the wife and will look at the ticket tomorrow |
| 23:05.25 | seanbright | putnopvut: holy crap |
| 23:05.45 | seanbright | that just looks like voodoo to me |
| 23:05.49 | putnopvut | lol |
| 23:06.13 | seanbright | so that will conditionally call ast_indicate_data()? |
| 23:06.18 | putnopvut | correct. |
| 23:06.21 | seanbright | oh jeez |
| 23:06.33 | putnopvut | Yeah, I imagine I'll get flamed for that during code review. |
| 23:06.45 | putnopvut | (or right now even) |
| 23:06.47 | russellb | gets a refill on his fuel tank |
| 23:06.53 | seanbright | i've just never seen that kinda thing before |
| 23:07.04 | seanbright | i'm not sure i'd ever think to try it, either :) |
| 23:07.09 | putnopvut | seanbright: ever heard of duff's device? |
| 23:07.33 | putnopvut | http://en.wikipedia.org/wiki/Duff%27s_device |
| 23:07.34 | seanbright | is that the unrolled loop in a switch statement thing? |
| 23:07.42 | seanbright | yes |
| 23:07.45 | putnopvut | yeah |
| 23:07.47 | seanbright | frightening |
| 23:07.48 | seanbright | heh |
| 23:07.52 | kpfleming | i pretty much would hate to see that live much longer :-) |
| 23:08.13 | kpfleming | especially when the alternative is so simple |
| 23:08.19 | russellb | lol |
| 23:08.53 | putnopvut | I didn't know the backlash would be so sudden :) |
| 23:09.05 | kpfleming | hey, at least it wasn't violent |
| 23:09.15 | kpfleming | it violates coding guidelines too :-) |
| 23:09.19 | *** part/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 23:09.22 | seanbright | wow |
| 23:09.25 | russellb | heh |
| 23:09.27 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 23:09.27 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 23:09.30 | seanbright | wrong key? |
| 23:09.31 | seanbright | heh |
| 23:09.32 | russellb | I HATE YOUR CODE *signs off* |
| 23:09.37 | seanbright | lol |
| 23:09.39 | kpfleming | no, wrong window |
| 23:09.41 | russellb | :-p |
| 23:09.51 | seanbright | in all the time i have spent in here |
| 23:09.54 | seanbright | i have never lol'd |
| 23:09.59 | seanbright | that was the firs time. |
| 23:10.00 | russellb | lies |
| 23:10.17 | seanbright | well, the one from the other day was funny too, but it wasn't in here |
| 23:10.43 | seanbright | <@seanbright> does enabling MALLOC_DEBUG get me a CLI command? |
| 23:10.49 | seanbright | <@russellb> it gets you a SHUT THE F%&K UP |
| 23:11.01 | seanbright | that should be on bash.org |
| 23:11.02 | russellb | :-X |
| 23:11.07 | seanbright | i censored it |
| 23:11.12 | seanbright | ok, i'm going away now. |