| 00:21.50 | *** join/#asterisk-dev italorossi (~italoross@189.124.198.166) |
| 00:36.51 | seanbright | so some carrier out there is sending audio describing a disconnected number without ever answering |
| 00:37.25 | seanbright | so our calls keep getting dispositioned as no answer, even though the number is clearly bad |
| 00:37.39 | seanbright | is there a built in way to detech this situation or do i have to write something? |
| 00:37.55 | jsmith-away | seanbright: Good luck w/ that |
| 00:38.06 | seanbright | crap |
| 00:43.33 | seanbright | i could throw a dsp on the there... we already do fax detect |
| 00:43.43 | seanbright | why can't i just check for a talk frame and just bail? |
| 00:43.56 | seanbright | hmmm |
| 00:44.05 | seanbright | i'm feeling more optimistic now |
| 00:52.16 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 00:52.17 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 01:37.24 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 01:37.24 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 02:26.41 | alecdavis | argh channel glare again! This time 2 inbound calls, from what I can tell, previous call hadn't freed it self fast enough!! |
| 02:32.16 | alecdavis | corydon76-???: Inbound calls from switch are using linear channel assignment like G (descending order), feels chan_dahdi needs throw away the previous call, and accept the new one, much more study i think. |
| 02:33.34 | alecdavis | to finish off, no calls were accepted into the company until I was made aware of the problem, and had to issue 'dahdi restart'. |
| 02:33.45 | alecdavis | M16755 |
| 02:33.47 | MuffinMan | [acknowledged] [Asterisk] Channels/chan_dahdi 0016755: E1 PRI channel 'glare', where asterisk hangups up the inbound call from network. reported by alecdavis https://issues.asterisk.org/view.php?id=16755 |
| 02:41.06 | Kobaz | what's glare? |
| 02:41.33 | Kobaz | www.kobaz.net/misc/t1_port1_device_interupts-day.png |
| 02:41.37 | Kobaz | er |
| 02:42.01 | seanbright | ok so dsp via g729 is a no-go |
| 02:42.02 | seanbright | noted. |
| 02:42.46 | Kobaz | any idea why a t1 card would randomly swap around inturrupts like that? |
| 02:56.09 | russellb | should probably talk to the vendor for that question. |
| 02:58.32 | seanbright | i have a question |
| 02:58.35 | seanbright | if i may |
| 02:58.53 | seanbright | i feel i am most of the way there |
| 02:59.03 | russellb | ~ask |
| 02:59.04 | infobot | Questions in the channel should be specific, informative, complete, concise, and on-topic. Don't ask if you can ask a question first. Don't ask if a person is there; just ask what you intended to ask them. Better questions more frequently yield better answers. We are all here voluntarily or against our will. |
| 02:59.06 | russellb | :-p |
| 02:59.07 | seanbright | heh |
| 02:59.24 | seanbright | provider <- g729 -> asterisk |
| 02:59.30 | russellb | yes, you have earned a lot of question credits, so you may redeem one. |
| 02:59.51 | seanbright | this is sip |
| 03:00.02 | russellb | how do you encode SIP with g729? |
| 03:00.09 | seanbright | rtp, jackass. |
| 03:00.10 | russellb | sorry, continue. |
| 03:00.46 | seanbright | i want to use the dsp routines on the audio coming in from the provider |
| 03:00.57 | russellb | yeahhhh .... |
| 03:01.03 | file | on g729? yeahhhhhhh |
| 03:01.06 | seanbright | heh |
| 03:01.07 | russellb | here's the thing, that's not going to work worth a crap |
| 03:01.25 | russellb | DTMF, one of the most well defined things to detect, can't be detected worth a damn in g729 |
| 03:01.34 | seanbright | that's not what i am trying to detect |
| 03:01.43 | russellb | what is it that you are trying to detect, kind sir? |
| 03:02.18 | seanbright | some numbers that we are dialing don't answer immediately |
| 03:02.38 | seanbright | but instead give us "this number is not in service" |
| 03:03.03 | russellb | nods |
| 03:03.03 | seanbright | so from our perspective, it's a no answer |
| 03:03.20 | file | youcanhazearlymedia |
| 03:03.21 | russellb | but you're getting early audio that indicates the truth. |
| 03:03.27 | seanbright | and we really want to say "hey... there is audio (that isn't ringing) coming from this channel before we got an answer... this is bogus" |
| 03:03.46 | russellb | it's not always bogus, though :-( |
| 03:03.54 | seanbright | ah. |
| 03:04.01 | seanbright | well that is problematic. |
| 03:04.09 | seanbright | fucking phones. |
| 03:04.35 | russellb | yes. |
| 03:04.55 | russellb | I really don't know what to offer on this one. Surely people have figured out creative ways to deal with this, but I don't know what they are. |
| 03:05.41 | seanbright | well if your contention is that you can get legit (i.e. good number) early media, i'm not sure there is a good way of handling it |
| 03:06.10 | russellb | yeah, some companies are evil and present their IVRs as early media |
| 03:06.37 | russellb | and of course, there is early media that is ringing |
| 03:06.37 | seanbright | well... let's pretend for arguments sake that all early media is evil |
| 03:06.38 | snuff-work | have some voice sample to compare against when the answered time is < x seconds when hangup ? |
| 03:07.00 | seanbright | early media = bad number |
| 03:07.15 | seanbright | i see that in app_amd, the read format is manually set to slin to make the dsp routines work |
| 03:07.28 | russellb | mhm |
| 03:07.39 | file | plus early media can actually happen when a destination is ringing |
| 03:07.58 | seanbright | ok |
| 03:08.09 | seanbright | well then it's not even worth speaking hypothetically |
| 03:08.11 | russellb | we could pretend it's all evil, but it isn't .. |
| 03:08.44 | seanbright | yeah |
| 03:09.06 | seanbright | well then. |
| 03:09.20 | seanbright | 'svn revert's |
| 03:09.23 | seanbright | :-( |
| 03:09.59 | seanbright | ok, well how about this |
| 03:10.01 | seanbright | heh |
| 03:10.09 | seanbright | SIT (?) tones |
| 03:10.15 | seanbright | that might be wrong |
| 03:11.02 | russellb | M16749 |
| 03:11.04 | MuffinMan | [ready for testing] [Asterisk] Core/General 0016749: [patch] DSP progress detection unable to detect SIT reported by dant https://issues.asterisk.org/view.php?id=16749 |
| 03:11.09 | seanbright | heh |
| 03:11.40 | russellb | call progress detection is hard, and mostly because everyone has to do it differently ... |
| 03:11.41 | seanbright | that's good timing |
| 03:11.49 | russellb | so it's hard to even know what you're supposed to be watching for |
| 03:12.16 | seanbright | does that patch look legit? |
| 03:14.01 | russellb | haven't looked really |
| 03:14.08 | russellb | i just remembered that the issue existed |
| 03:14.13 | seanbright | and this will only really help in the case that SITs are used |
| 03:14.19 | seanbright | but i guess it's a start |
| 03:16.25 | russellb | and i seem to remember that there is another SIT related issue in there somewhere but i'm having trouble finding it |
| 03:17.39 | seanbright | in order to do any dsp, i need to get the read format in slinear |
| 03:17.57 | russellb | correct |
| 03:18.33 | seanbright | and that is |
| 03:18.45 | seanbright | ... an incomplete though |
| 03:18.48 | seanbright | thought* |
| 03:21.30 | seanbright | thank you for taking the time to answer my question |
| 03:21.56 | russellb | sure, no problem. Sorry we had nothing but negativity to offer. :-p |
| 03:21.56 | seanbright | you may return to downloading the porno |
| 03:22.26 | seanbright | just sucks to dial the same number 15 times when there is no chance it will ever answer |
| 03:22.31 | russellb | i hear ya |
| 03:22.34 | seanbright | and you have no way of knowing it |
| 03:22.59 | russellb | you could record all early media and ahve people go through and review it |
| 03:23.00 | russellb | :-p |
| 03:23.18 | seanbright | i was already considering it |
| 05:17.15 | *** join/#asterisk-dev lmsteffan (~laurent@reef.ac-noumea.nc) |
| 05:20.35 | alecdavis | cdr recording and PRI channel 'glare': Theory only so far. But asterisk sends RELEASE, then takes some time to update the CDR, meanwhile the RELEASE COMPLETE comes in, which should free up the channel, but before we get to process the RELEASE COMPLETE a new SETUP has come in demanding the same channel (far enough we've said RELEASE), asterisk promptly sends RELEASE to the new call, and then finally clears down the previous call. |
| 05:23.00 | alecdavis | M16755 has more. Time to go... |
| 05:23.40 | *** part/#asterisk-dev alecdavis (~alec@202.36.76.21) |
| 06:25.18 | *** join/#asterisk-dev fiddur (~fiddur@192.121.104.121) |
| 07:19.53 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 07:19.53 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:20.11 | oej | Morning, folks! |
| 07:24.37 | jmls | morning |
| 07:25.24 | fiddur | Morning |
| 07:37.21 | *** join/#asterisk-dev snuff-work (~aaa@ARD146588-1.gw.connect.com.au) |
| 07:37.21 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 07:41.34 | *** join/#asterisk-dev oej_ (~olle@ns.webway.se) |
| 07:41.34 | *** mode/#asterisk-dev [+o oej_] by ChanServ |
| 08:02.28 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 08:02.28 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:18.48 | *** join/#asterisk-dev mpe (~mpe@217.74.220.92) |
| 08:20.32 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 08:31.16 | *** join/#asterisk-dev vrban (~chatzilla@p50997436.dip0.t-ipconnect.de) |
| 08:44.50 | *** join/#asterisk-dev vrban (~chatzilla@p50997436.dip0.t-ipconnect.de) |
| 09:00.38 | *** join/#asterisk-dev dseeb_ (~Adium@CPE-58-169-81-65.lns1.bat.bigpond.net.au) |
| 10:23.10 | *** join/#asterisk-dev obnauticus (~obnauticu@about/windows/regular/obnauticus) |
| 10:38.53 | *** join/#asterisk-dev micols (~mio@rlogin.dk) |
| 10:55.41 | *** join/#asterisk-dev ccesario (~ccesario@189-19-6-236.dsl.telesp.net.br) |
| 11:28.37 | *** join/#asterisk-dev caio1982 (~caio1982@CAcert-br/caio1982) |
| 12:23.33 | *** join/#asterisk-dev Victor_Yure (~victor@unaffiliated/victoryure/x-837844) |
| 12:38.11 | *** join/#asterisk-dev sgimeno (~chatzilla@226.Red-80-33-64.staticIP.rima-tde.net) |
| 13:05.55 | *** join/#asterisk-dev Omorika (~omorika@193.198.31.85) |
| 13:05.59 | Omorika | hey guys |
| 13:06.15 | Omorika | question: i'm wrote an asterisk module |
| 13:06.26 | Omorika | which implements a function |
| 13:06.34 | Omorika | that i want to use from chan_dahdi |
| 13:07.05 | Omorika | how can i do that? asterisk always crashes coz function pointer is 0 |
| 13:07.06 | Omorika | :D |
| 13:20.26 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 13:20.26 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 13:28.04 | Omorika | anyone? |
| 13:28.14 | Omorika | hey, kpfleming |
| 13:28.22 | Omorika | can u pls help? :D |
| 13:28.32 | kpfleming | with what? |
| 13:28.45 | Omorika | i wrote an asterisk module |
| 13:28.51 | Omorika | which implements a function |
| 13:28.56 | Omorika | that i want to use from chan_dahdi |
| 13:29.01 | Omorika | how can i do that? asterisk always crashes coz function pointer is 0 |
| 13:29.14 | Omorika | and i can see chan_dahdi using res_smdi successfuly |
| 13:29.20 | Omorika | so... what's the catch? :) |
| 13:29.27 | kpfleming | look at the .exports file for res_smdi |
| 13:29.39 | kpfleming | that will show you how to get the symbol you need exported from your module |
| 13:29.53 | Omorika | where is that file?? |
| 13:30.53 | Omorika | i cant find it anywhere :) |
| 13:31.30 | kpfleming | in the res subdirectory, right next to res_smdi.c |
| 13:31.53 | Omorika | Oo |
| 13:32.05 | Omorika | what is the name of the file?? |
| 13:32.21 | kpfleming | can you look at the file listing? it's incredibly obvious |
| 13:32.48 | Omorika | i see "res_smdi.c res_smdi.o res_smdi.so" |
| 13:32.57 | kpfleming | what version of asterisk are you using? |
| 13:33.02 | Omorika | 1.6.2 |
| 13:33.23 | Omorika | i have |
| 13:33.30 | Omorika | .res_smdi.makeopts |
| 13:33.41 | kpfleming | oh... 1.6.2 doesn't have the export files apparently |
| 13:33.42 | Omorika | and |
| 13:33.45 | Omorika | .res_smdi.moduleinfo |
| 13:33.48 | kpfleming | so that was a red herring |
| 13:33.50 | Omorika | :) |
| 13:33.59 | Omorika | ok, now what? :D |
| 13:34.08 | kpfleming | what does your AST_MODULE_INFO block look like at the end of your module? |
| 13:35.03 | Omorika | AST_MODULE_INFO_STANDARD(ASTERISK_GPL_KEY, "My module"); |
| 13:35.13 | Omorika | ok |
| 13:35.14 | Omorika | i get it |
| 13:35.21 | Omorika | AST_MODULE_INFO(ASTERISK_GPL_KEY, AST_MODFLAG_GLOBAL_SYMBOLS |
| 13:35.22 | Omorika | :) |
| 13:35.27 | Omorika | global symbols is the key :D |
| 13:36.13 | kpfleming | indeed |
| 13:36.35 | Omorika | thank you very much |
| 13:36.36 | Omorika | :) |
| 13:46.29 | Kobaz | a crashing we will go..... a crashing we will go |
| 13:46.32 | Kobaz | time for breakfast |
| 13:47.23 | Kobaz | yeah |
| 13:47.25 | Kobaz | er |
| 13:58.06 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 14:23.50 | *** join/#asterisk-dev xpot-mobile (~xpot@70-91-210-233-BusName-Utah.hfc.comcastbusiness.net) |
| 14:25.12 | leifmadsen | breakfast was so 1 hour ago |
| 14:56.03 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:56.03 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:35.42 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:52.29 | *** join/#asterisk-dev jpeeler (~jpeeler@asterisk/digium-software-dev/jpeeler) |
| 15:52.29 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:53.26 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:53.26 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 15:54.49 | jmls | what is breakfast ? |
| 15:54.59 | jmls | or lunch ? |
| 15:55.11 | jmls | mutters "or dinner, for that matter" |
| 15:55.43 | jmls | no-one else has commented on my review. Don't know if that's a good thing or bad thing ;) |
| 15:55.47 | leifmadsen | jmls: shoosh you! |
| 15:58.44 | seanbright | looks |
| 15:59.09 | *** join/#asterisk-dev Deeewayne (~dwayne@75.76.254.162) |
| 15:59.10 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 15:59.40 | leifmadsen | jmls: awww, I didn't mean it :) |
| 16:03.51 | russellb | jmls: just takes a while, million things to do, you know how it is. |
| 16:04.34 | *** join/#asterisk-dev jsmith-away (~jsmith@asterisk/training-and-documentation-guru/jsmith) |
| 16:04.35 | *** mode/#asterisk-dev [+o jsmith-away] by ChanServ |
| 16:05.10 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 16:05.10 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:15.25 | seanbright | jmls: reviewed. |
| 16:17.00 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 16:17.57 | *** join/#asterisk-dev moy (~moy@74.12.123.169) |
| 16:38.11 | *** join/#asterisk-dev jsmith-away (~jsmith@asterisk/training-and-documentation-guru/jsmith) |
| 16:38.12 | *** mode/#asterisk-dev [+o jsmith-away] by ChanServ |
| 16:49.46 | jmls | seanbright: thanks. |
| 16:50.05 | *** join/#asterisk-dev CunningPike (~CunningPi@204.239.8.157) |
| 16:50.14 | jmls | is upset - he was *told* to use RESULT_SUCCESS et al instead of his return 0; |
| 16:50.17 | jmls | :( |
| 16:50.38 | jmls | heh |
| 16:59.37 | *** join/#asterisk-dev marv (~timr@24.214.206.254) |
| 17:11.39 | *** join/#asterisk-dev yahh (~root@122.169.77.74) |
| 17:11.41 | *** join/#asterisk-dev jameswf (~james@unaffiliated/jameswf-home) |
| 17:11.56 | yahh | hello guys.. |
| 17:12.05 | yahh | i have a query |
| 17:12.30 | yahh | i am using 2 quad processor |
| 17:12.35 | yahh | asterisk is running on that |
| 17:12.52 | jsmith-away | yahh: Does your question involve the Asterisk source code? If not, you'd be better off asking in #asterisk |
| 17:13.22 | yahh | okay |
| 17:13.30 | yahh | thanks |
| 17:29.02 | seanbright | jmls: who *told* you to use that? |
| 17:29.09 | *** join/#asterisk-dev Victor_Yure (~victor@unaffiliated/victoryure/x-837844) |
| 17:54.30 | *** join/#asterisk-dev xpot-mobile (~xpot@173-14-232-121-Utah.hfc.comcastbusiness.net) |
| 17:55.35 | *** join/#asterisk-dev mnick86 (~mnick86@95-90-246-116-dynip.superkabel.de) |
| 18:14.05 | jmls | now blames someone. |
| 18:14.15 | jmls | (11:14:33 PM) Corydon76-dig: return RESULT_SUCCESS |
| 18:14.25 | seanbright | he must have thought it was a cli handler |
| 18:14.31 | jmls | good recovery |
| 18:14.39 | jmls | I like that. Support for a fellow coder |
| 18:14.41 | jmls | :) |
| 18:15.19 | jmls | I've already changed it back to return 0; |
| 18:15.19 | jmls | ... |
| 18:15.48 | jmls | seanbright: http://pastebin.com/m6343eb88 |
| 18:16.05 | jmls | is that what you mean by not needing the _BOTH flag ? |
| 18:16.30 | seanbright | that last test shouldn't be n ecessary |
| 18:16.56 | seanbright | let me look at the diff again |
| 18:17.42 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 18:17.59 | jmls | is back to his z80 assembler days, xoring away |
| 18:19.32 | seanbright | what you have should work |
| 18:19.40 | seanbright | the change you made, that is. |
| 18:19.45 | jmls | Excellent! |
| 18:19.51 | jmls | is amazed |
| 18:19.53 | seanbright | but you should test it, obviously. |
| 18:20.14 | jmls | right. |
| 18:25.54 | *** join/#asterisk-dev jsmith (~jsmith@asterisk/training-and-documentation-guru/jsmith) |
| 18:25.54 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 18:29.29 | Corydon76-dig | seanbright: cli handlers return CLI_SUCCESS |
| 18:33.17 | seanbright | ah |
| 18:33.19 | seanbright | well whatever |
| 18:33.25 | seanbright | manager actions don't return those |
| 18:34.26 | seanbright | oddly, they are defined in cli.h |
| 18:37.02 | seanbright | hmm. 'core show calls' returns RESULT_SUCCESS. hopefully that doens't cause a crash. |
| 18:38.23 | Corydon76-dig | We really should start using macro constant returns for AMI |
| 18:39.29 | seanbright | well from what i was able to determine, 0 is returned unless we want to stop event processing |
| 18:39.34 | Corydon76-dig | Or define another set of return values |
| 18:39.50 | seanbright | so we'd just need to create 2 |
| 18:40.13 | Corydon76-dig | AMI_SUCCESS and AMI_DESTROY, perhaps? |
| 18:40.49 | Corydon76-dig | or ASTMAN_SUCCESS, I think, since AMI is not actually used anywhere |
| 18:41.09 | seanbright | success is a bit deceiving, since we return that even if we are reporting an error. |
| 18:41.36 | seanbright | i'm indifferent, so i'll leave the choice to whoever wants to code it up |
| 18:42.50 | jmls | abdicates from that responsibility |
| 18:43.14 | jmls | it's been hard enough getting this simple patch up to scratch |
| 18:44.55 | Corydon76-dig | jmls: In time, it'll become second nature |
| 18:46.25 | Corydon76-dig | There! Constant return values |
| 18:48.55 | *** join/#asterisk-dev Victor_Yure (~victor@unaffiliated/victoryure/x-837844) |
| 18:49.25 | jmls | now wonders if the coding guidelines now demand you use constant return values for AMI commands ... |
| 18:49.36 | jmls | stabs himslef with a pointy stick |
| 18:50.31 | jmls | those priests who self-flagellate should just become asterisk developers. The pain is much worse |
| 18:52.54 | Corydon76-dig | jmls: Don't underestimate your talents. Let us do that for you. |
| 18:54.10 | jmls | now I feel all warm and contented |
| 18:54.22 | jmls | oh, wait .. that wasn't nice, was it ? |
| 18:54.24 | jmls | ;) |
| 18:56.21 | jmls | this isn't good, right ? |
| 18:56.25 | jmls | contrib/scripts/live_ast: line 173: 32108 Segmentation fault $AST_BIN -C $AST_CONF "$@" |
| 18:56.59 | Corydon76-dig | Usually not |
| 18:59.21 | |Rain| | certainly not if there were calls active :) |
| 19:09.02 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 19:09.02 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 19:17.26 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 19:18.20 | jmls | interesting. A plain "make install" followed by asterisk -vvvvvvc works just fine |
| 19:27.06 | *** join/#asterisk-dev Ta^3 (~tacvbo@189.146.190.22) |
| 20:00.20 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 20:00.20 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:06.46 | *** join/#asterisk-dev Victor_Yure_ (~victor@unaffiliated/victoryure/x-837844) |
| 20:07.21 | jmls | meh |
| 20:07.26 | jmls | that didn't seem to work |
| 20:07.48 | jmls | I can mute using read, and both, but write seems to do both as well |
| 20:08.39 | jmls | the read flag is 16, write is 32 and both is 48 |
| 20:09.15 | jmls | so they seem right |
| 20:09.23 | seanbright | can you create a pastebin from the diff? |
| 20:09.32 | seanbright | svn diff | paste2pastebin.pl |
| 20:09.47 | seanbright | or whatever your favorite util is |
| 20:10.32 | Corydon76-dig | svn diff | tattooonseanbrightsback.pl |
| 20:11.23 | jmls | http://pastebin.com/m6cd3e54e |
| 20:11.27 | seanbright | except for paste2pastebin.pl is an actual pastebin utility |
| 20:11.33 | jmls | that's the lines that have been changed |
| 20:11.52 | seanbright | can you create a pastebin from the diff? |
| 20:12.28 | Corydon76-dig | Is there no room left on your back? |
| 20:12.32 | jmls | coming right up |
| 20:12.38 | Corydon76-dig | disposes of the new utility script |
| 20:13.33 | Corydon76-dig | Scriptable laser etching is such a cool tool, though... |
| 20:13.46 | jmls | http://pastebin.com/m22070b0f |
| 20:14.30 | jmls | the diagnostics from |
| 20:14.31 | jmls | ast_verb(2, "MixMonitor: mute variable: name:%s | direction:%s | muted: %i | flag: %i\n",name,direction,muteflag,flag); |
| 20:14.35 | jmls | seem fine |
| 20:15.03 | jmls | MixMonitor: mute variable: name:SIP/5999-00000001 | direction:write | muted: 0 | flag: 32 |
| 20:16.10 | jmls | the last test in audiohook.c doesn't feel right to me |
| 20:16.11 | jmls | (ast_test_flag(audiohook, AST_AUDIOHOOK_MUTE_WRITE | AST_AUDIOHOOK_DIRECTION_READ) |
| 20:16.24 | seanbright | you need to check the return value of that i think |
| 20:16.39 | seanbright | oh |
| 20:16.41 | seanbright | it's wrong |
| 20:16.44 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 20:16.44 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 20:16.47 | jmls | hah |
| 20:16.58 | seanbright | MUTE_READ and MUTE_WRITE |
| 20:17.10 | seanbright | AST_AUDIOHOOK_MUTE_READ | AST_AUDIOHOOK_MUTE_WRITE |
| 20:17.20 | seanbright | not MUTE_WRITE and DIRECTION_READ |
| 20:17.26 | jmls | ypu |
| 20:17.28 | jmls | yup |
| 20:17.34 | jmls | obvious when you see it :) |
| 20:17.36 | seanbright | yeah |
| 20:17.42 | jmls | thanks |
| 20:18.00 | Corydon76-dig | jmls: reviewboard is a good reason for that |
| 20:18.18 | Corydon76-dig | One of our guys even posts to RB to make a self-review |
| 20:19.03 | Corydon76-dig | because it aids him in ensuring that his code quality is up to his own standards |
| 20:19.26 | *** join/#asterisk-dev italorossi (~italoross@201.76.154.123.intranet.digi.com.br) |
| 20:19.50 | jmls | yeah, it was funny. I knew that line was wrong, but couldn't see it |
| 20:20.16 | jmls | I was testing the changes before I reviewboarded it :( |
| 20:23.01 | seanbright | i feel like you still need to check the return value of that second ast_test_flag call |
| 20:23.08 | seanbright | err |
| 20:23.11 | seanbright | last ast_test_flag call |
| 20:23.29 | seanbright | ast_test_flag(audiohook, AST_AUDIOHOOK_MUTE_WRITE | AST_AUDIOHOOK_DIRECTION_READ) == (AST_AUDIOHOOK_MUTE_WRITE | AST_AUDIOHOOK_DIRECTION_READ) |
| 20:23.33 | seanbright | but that is probably wrong |
| 20:24.56 | jmls | in about 30s I should tell you |
| 20:25.02 | jmls | is reviewing a recording |
| 20:26.25 | jmls | seems I was right with my misgivings |
| 20:26.39 | jmls | any flag now mutes both sides :( |
| 20:26.43 | seanbright | gah... my most recent paste was wrong |
| 20:26.45 | seanbright | right |
| 20:26.48 | seanbright | try this |
| 20:27.01 | jmls | turns blue |
| 20:27.09 | jmls | *gasp |
| 20:27.24 | seanbright | ast_test_flag(audiohook, AST_AUDIOHOOK_MUTE_READ | AST_AUDIOHOOK_MUTE_WRITE) == (AST_AUDIOHOOK_MUTE_READ | AST_AUDIOHOOK_MUTE_WRITE) |
| 20:27.56 | jmls | ta |
| 20:28.04 | jmls | shamelessly steals the code |
| 20:28.25 | seanbright | you could shorten that with a #define, too if you wanna |
| 20:29.02 | seanbright | #define AUDIOHOOK_MUTE_BOTH (AST_AUDIOHOOK_MUTE_READ | AST_AUDIOHOOK_MUTE_WRITE) |
| 20:29.05 | seanbright | ast_test_flag(audiohook, AUDIOHOOK_MUTE_BOTH) == AUDIOHOOK_MUTE_BOTH |
| 20:31.20 | jmls | where would that #define go ? In include/asterisk/audiohook.h ? |
| 20:31.53 | seanbright | no |
| 20:31.59 | seanbright | you don't have to use it |
| 20:32.13 | jmls | shrugs |
| 20:32.14 | jmls | ok |
| 20:32.26 | jmls | here we go. Test #4 |
| 20:32.36 | seanbright | you could just throw it in app_mixmonitor.c |
| 20:32.40 | seanbright | k |
| 20:33.43 | *** join/#asterisk-dev Amorsen (~Amorsen@94.127.50.7) |
| 20:35.07 | jmls | read: ok |
| 20:35.23 | jmls | write: ok |
| 20:35.36 | jmls | both: ok |
| 20:35.40 | seanbright | ok |
| 20:35.41 | jmls | yay yay ya |
| 20:35.47 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 20:35.50 | seanbright | do you understand why that fixed it? |
| 20:36.16 | jmls | nope :) |
| 20:36.28 | jmls | thinks back to xor, or and and |
| 20:36.53 | jmls | the original test returned a true or false |
| 20:37.14 | jmls | needed to check that the flag was the sum of both flags |
| 20:37.19 | seanbright | i'm a bit lagged. otherwise i'd explain :-) |
| 20:37.25 | jmls | nice! |
| 20:37.28 | seanbright | that is correct |
| 20:37.37 | jmls | holy cow |
| 20:37.41 | seanbright | well, no |
| 20:37.45 | seanbright | err |
| 20:37.49 | seanbright | yes. |
| 20:37.50 | seanbright | heh |
| 20:38.32 | jmls | "Well I've always said, There's nothing an agnostic can't do if he really doesn't know whether he believes in anything or not" |
| 20:39.33 | *** join/#asterisk-dev alecdavis (~alec@210.48.127.227) |
| 20:44.13 | jmls | Corydon76-dig: so, I should use AMI_SUCCESS if all is ok with the AMI command, and AMI_DESTROY otherwise ? |
| 20:53.58 | Corydon76-dig | AMI_DESTROY only if you want the AMI session to end |
| 20:54.28 | oej | AMI_DESTRUCT if you want to kill the tcp/ip stack on the remote end |
| 20:54.44 | oej | AMI_ATTACK ... well, pretty self-explanatory |
| 20:55.22 | oej | Sorry for the interruption... Tired. |
| 20:55.48 | *** join/#asterisk-dev jsmith (~jsmith@asterisk/training-and-documentation-guru/jsmith) |
| 20:55.48 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 20:57.52 | jmls | so, AMI_SUCCESS even if someone hasn't supplied the right parameters ? |
| 20:57.55 | jmls | cool |
| 20:58.08 | jmls | whistles to himself |
| 21:05.27 | oej | You report error message successfully in that case. |
| 21:07.56 | *** join/#asterisk-dev jsmith-away (~jsmith@asterisk/training-and-documentation-guru/jsmith) |
| 21:07.56 | *** mode/#asterisk-dev [+o jsmith-away] by ChanServ |
| 21:10.19 | *** join/#asterisk-dev jsmith-away (~jsmith@asterisk/training-and-documentation-guru/jsmith) |
| 21:10.19 | *** mode/#asterisk-dev [+o jsmith-away] by ChanServ |
| 21:23.39 | alecdavis | corydon76-dig: did you reconsider my comments on the app_directory review. It's ready to go? |
| 21:26.00 | Corydon76-dig | I have not reviewed it, no. |
| 21:26.45 | *** join/#asterisk-dev jsmith-away (~jsmith@asterisk/training-and-documentation-guru/jsmith) |
| 21:26.45 | *** mode/#asterisk-dev [+o jsmith-away] by ChanServ |
| 21:27.12 | Corydon76-dig | The reason why I'd prefer it preparsed is that one my pet peeves is creating a string that matches some option set to pass down, when an application is called internally |
| 21:27.26 | *** join/#asterisk-dev jsmith-away (~jsmith@asterisk/training-and-documentation-guru/jsmith) |
| 21:27.26 | *** mode/#asterisk-dev [+o jsmith-away] by ChanServ |
| 21:27.47 | Corydon76-dig | I'd much rather have a clear API defined where you parse stuff like that in advance and then pass the value |
| 21:27.52 | *** join/#asterisk-dev jsmith-away (~jsmith@asterisk/training-and-documentation-guru/jsmith) |
| 21:27.52 | *** mode/#asterisk-dev [+o jsmith-away] by ChanServ |
| 21:28.14 | jmls | latest diff applied to MuteMixmonitor review |
| 21:28.20 | jmls | ready to rumble ;) |
| 21:29.01 | Corydon76-dig | alecdavis: while it's not necessary in the current iteration, it makes adding internal API calls in the future much more clear |
| 21:30.00 | Corydon76-dig | e.g. we currently call pbx_exec in VoicemailMain in order to execute Directory. |
| 21:30.03 | *** join/#asterisk-dev jsmith-away (~jsmith@asterisk/training-and-documentation-guru/jsmith) |
| 21:30.03 | *** mode/#asterisk-dev [+o jsmith-away] by ChanServ |
| 21:30.33 | Corydon76-dig | I'd much rather we start using optional API and not have to construct option/argument strings |
| 21:31.22 | *** join/#asterisk-dev jsmith-away (~jsmith@asterisk/training-and-documentation-guru/jsmith) |
| 21:31.22 | *** mode/#asterisk-dev [+o jsmith-away] by ChanServ |
| 21:31.36 | Corydon76-dig | alecdavis: does that make sense? |
| 21:32.01 | *** join/#asterisk-dev jsmith-away (~jsmith@asterisk/training-and-documentation-guru/jsmith) |
| 21:32.01 | *** mode/#asterisk-dev [+o jsmith-away] by ChanServ |
| 21:34.53 | *** join/#asterisk-dev jsmith-away (~jsmith@asterisk/training-and-documentation-guru/jsmith) |
| 21:34.53 | *** mode/#asterisk-dev [+o jsmith-away] by ChanServ |
| 21:34.59 | alecdavis | corydon76: sort of. But a new API for do_directory might become do_directory_pause, is that what your saying? |
| 21:35.36 | Corydon76-dig | Actually, the name is likely to be along the lines of ast_app_directory() |
| 21:36.34 | Corydon76-dig | with weak linking, so we can check the value of the function pointer |
| 21:36.58 | Corydon76-dig | There's some pretty neat stuff we can do with weak symbols |
| 21:39.04 | *** join/#asterisk-dev jsmith-away (~jsmith@asterisk/training-and-documentation-guru/jsmith) |
| 21:39.04 | *** mode/#asterisk-dev [+o jsmith-away] by ChanServ |
| 21:41.42 | *** join/#asterisk-dev Greek-Boy (~Monching@41.188.154.137) |
| 21:43.40 | *** join/#asterisk-dev jsmith-away (~jsmith@asterisk/training-and-documentation-guru/jsmith) |
| 21:43.40 | *** mode/#asterisk-dev [+o jsmith-away] by ChanServ |
| 21:48.38 | alecdavis | corydon76-dig: a penny just dropped, you want 'the Directory' available to more than just the dialplan application app_directory, I follow. |
| 22:04.27 | Corydon76-dig | alecdavis: At some point, it will be invoked directly from VoicemailMain (and potentially from other places, as well), instead of through the PBX interface. |
| 22:05.26 | Corydon76-dig | So coming through the PBX interface, options are natural, but the textual strings should be specific to that interface, not passed down into the guts |
| 22:31.51 | alecdavis | corydon76-dig: VoicemailMain needs a option to return to the 'a' priority, like VoiceMail does. |
| 22:32.57 | jsmith | alecdavis: I concur. |
| 22:37.21 | *** join/#asterisk-dev mnt_real (~sinan@bas1-montreal43-1177754708.dsl.bell.ca) |
| 22:55.46 | *** join/#asterisk-dev obnauticus (~obnauticu@about/windows/regular/obnauticus) |
| 23:01.31 | *** join/#asterisk-dev snuff-work (~aaa@210.9.82.197) |
| 23:01.31 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:17.25 | *** join/#asterisk-dev dseeb_ (~Adium@CPE-124-177-30-127.lns2.dav.bigpond.net.au) |