| 00:48.21 | *** join/#asterisk-dev snuff-work (~snuffy@210.9.82.197) |
| 00:48.21 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 02:01.11 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 04:30.57 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 04:42.38 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 06:21.28 | *** join/#asterisk-dev bulkorok (~bulkorok@85.183.36.36) |
| 06:40.26 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 06:40.27 | schmidts | good morning |
| 08:47.00 | *** join/#asterisk-dev acidfoo (~nib@modemcable094.94-70-69.static.videotron.ca) |
| 09:27.32 | *** join/#asterisk-dev hurdman (~ygcheny@bender.r0b0t.fr) |
| 09:55.51 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 09:55.52 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 10:55.49 | *** join/#asterisk-dev niluje (~niluje@bdv75-4-82-227-67-242.fbx.proxad.net) |
| 13:01.32 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 13:01.32 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Many thanks to kpfleming for 7 years of awesome. |
| 13:10.22 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-aseumcfxofknxlbs) |
| 13:10.22 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:13.35 | *** join/#asterisk-dev sezuan (bouncer@irc.scheff32.de) |
| 13:15.43 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 13:15.43 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 13:23.26 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:fccb:2b07:4267:9df8) |
| 13:31.56 | leifmadsen | newtonr: when you get online, can you triage ASTERISK-20509 for me? |
| 13:32.17 | leifmadsen | if anyone else wants to review it, it's an issue we've run into while documenting A:TDG 4e |
| 13:40.14 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 13:40.14 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 13:49.49 | hurdman | hi, anyone can explain what's the hell do asterisk with frame locking ? |
| 13:53.19 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:53.19 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 13:55.11 | pabelanger | Umm, we are cool with alexdavis changing the functionality to dsp.c mid release? |
| 13:55.21 | pabelanger | specifically how we parse configuration files? |
| 13:56.11 | pabelanger | Also, why all the changes to dtmf detection in 1.8, and not just trunk? |
| 13:56.30 | pabelanger | Seems like are playing with fire |
| 13:56.34 | mjordan | pabelanger: first question - I don't see how he changed how config files are parsed |
| 13:56.40 | mjordan | you might need to explain that one |
| 13:56.55 | mjordan | the second question is a bit easier to answer. He's been working with a number of folks in various countries on DTMF detection problems |
| 13:57.11 | *** join/#asterisk-dev malcolmd_ (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 13:57.11 | *** mode/#asterisk-dev [+o malcolmd_] by ChanServ |
| 13:57.29 | mjordan | there have been several patches in the past 1.8 releases that have 'tweaked' the behavior, but because different countries use different specs, its been impossible to meet everyone's needs |
| 13:57.47 | pabelanger | mjordan: well, we now loop over values in dsp.conf, versus loading the first value. |
| 13:57.48 | pabelanger | http://svnview.digium.com/svn/asterisk/branches/1.8/main/dsp.c?view=diff&r1=374364&r2=374365&pathrev=374365 |
| 13:57.49 | mjordan | rather than continue to tweak and break, this gives people the ability - in those locations - to configure the system so that DTMF is detected properly |
| 13:59.38 | mjordan | pabelanger: I can see doing that commit in the context that multiple config values were now going to be read, as opposed to just one |
| 13:59.41 | pabelanger | mjordan: right, but shouldn't active development happen with trunk only, then once everbody is happy with the changes we can just backport the new features is needed? Then we don;t have to fix these new isses for each release |
| 13:59.50 | mjordan | backporting is rarely a clean operation |
| 14:00.40 | mjordan | pabelanger: and in general, bug fixes - which really, this is, since the current behavior cannot meet the needs of all users - would be oldest branch first |
| 14:01.12 | mjordan | that being said, I don't want to be making this decision in isolation, so if you feel that this does not belong in 1.8, write an e-mail to the -dev list |
| 14:01.18 | mjordan | new release candidates won't be cut until next week |
| 14:03.57 | mjordan | leifmadsen: I'll take a peek |
| 14:04.07 | mjordan | hurdman: what...? |
| 14:04.24 | mjordan | leifmadsen: ack'd |
| 14:05.19 | pabelanger | mjordan: I already raise my objections on the code review, unfortunately they were ignored. |
| 14:06.05 | mjordan | leifmadsen: hm. Knowing app_queue, does this happen if you're the first person waiting in a queue and agents are not available (either ringing and fail to answer, or just not available) and you bounce out of the queue? |
| 14:06.19 | mjordan | leifmadsen: or does it only happen to people waiting in a queue that are in slots 2+? |
| 14:06.40 | pabelanger | Which raises the question, if there is a disagreement with a patch, somebody just needs to give a 'ship it' to resolve it :) |
| 14:08.09 | mjordan | pabelanger: I don't see the objections you just raised. I saw your comments recommending the configuration framework, which would have been a completely separate patch imo |
| 14:08.40 | mjordan | pabelanger: and that's not really true. If someone ships code and someone disagrees with the patch, we have a mailing list to resolve that, and - if we know about the dispute - we won't put it into an RC until there's a resolution |
| 14:09.21 | mjordan | If you feel like this should not go in, send an e-mail and see if other people agree. |
| 14:10.28 | pabelanger | My only question / concern is the risk of regression for DTMF. |
| 14:10.33 | pabelanger | that's about the only issue |
| 14:11.04 | mjordan | pabelanger: interestingly enough, all of this is because of a regression that did occur in dsp.c regarding DTMF. The original patch made DTMF detection unable to handle DTMF with a very short duration. |
| 14:11.26 | pabelanger | OIC |
| 14:11.36 | mjordan | the sequence of patches thereafter have closed the gap while enabling the DTMF detection the original patch was intended to 'fix', but along the way, its become clear that you can't meet everyone's systems without giving the ability to tweak it |
| 14:11.57 | mjordan | For example, someone in Taiwan had to change settings in dsp.c and re-compile in order for their DTMF to be detected |
| 14:12.21 | mjordan | but you don't want those specific settings being made globally available to everyone, as it will negatively impact other locales |
| 14:12.28 | mjordan | hence why alec went for 'make it configurable' |
| 14:15.20 | hurdman | mjordan: i'm talking about "what i have to lock when i create a module that's looking into a frame ?" ( sorry for my very bad english ), i have read something here : https://wiki.asterisk.org/wiki/display/AST/Locking+in+Asterisk ; but i don't understand everything |
| 14:15.38 | pabelanger | Yup, and I appreciate that he is stepping up to fix it. But my concern is, something as core as DTMF detection, I don't think we should go in and make fixes (quick or for compatibility) with out thoroughly testing them. Like you said, the first fix opened up a regression, then a few more changes, to new configuration file parameters. Which, is fine for a development branch, but a hard sell to me for a releas |
| 14:15.38 | pabelanger | e branch |
| 14:16.06 | jgowdy | mjordan: thanks for your input on my DTMF bug on unbridge |
| 14:16.12 | Qwell | pabelanger: It's necessary to fix a bug. What will you have us do? |
| 14:16.16 | mjordan | jgowdy: np. Patch looked pretty good :-) |
| 14:16.18 | jgowdy | We got the patch working completely after digging into masq |
| 14:16.28 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:16.28 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:16.44 | mjordan | jgowdy: yeah, the masquerade isn't something I had thought of in my comment, which definitely complicates the situation |
| 14:16.46 | jgowdy | So frustrating at first, because the original patch did pretty much just what you were suggesting, only worked half the time |
| 14:16.58 | jgowdy | We were like, wtf, why is it working half the time, is it racing? |
| 14:17.01 | jgowdy | Ohhhh zombie |
| 14:17.06 | mjordan | jgowdy: they will eat you |
| 14:17.09 | jgowdy | indeed |
| 14:17.33 | pabelanger | Qwell: assess the impact of the bug, risk of regression and benefit. If minimal, fix in master have the user upgrade |
| 14:17.33 | jgowdy | But yeah, that fix is huge for our company and this product launch in particular, so I can't thank you enough |
| 14:17.36 | mjordan | hurdman: depends on what you mean by looking into a frame. How are you getting the frame? |
| 14:18.07 | mjordan | jgowdy: np. We'll get it on the queue to get fixed asap |
| 14:20.33 | hurdman | mjordan: something like that : fr = ast_read(chan); where fr is struct ast_frame *fr; |
| 14:20.48 | hurdman | and chan struct ast_channel |
| 14:22.56 | mjordan | once you've read it off the channel you own the frame. So there isn't anything you need to do with the frame. The channel should not be locked prior to calling ast_read. |
| 14:25.11 | hurdman | mjordan: ast_read is doing the lock ? |
| 14:27.49 | mjordan | hurdman: yes, ast_read will lock the channel |
| 14:28.40 | hurdman | mjordan: ok thx |
| 14:29.08 | file | one lock to rule them all and in the darkness block them |
| 14:29.25 | hurdman | and your name is file XD |
| 14:29.25 | mjordan | file: but only when DEBUG_THREADS is enabled |
| 14:29.48 | file | mjordan, truth |
| 14:31.06 | leifmadsen | mjordan: well, what happens is that it's not about waiting in the queue, but rather the action that is performed on the Local channel, and when values are available. For example, there are several channel variables that are set (says how long the person was waiting for, number of people in queue, etc...). That data ideally would be available to the Local channel in order evaluate and utilize those values for some logi |
| 14:31.07 | leifmadsen | c. However, the values are only available after the channel has actually answered, but just prior to bridging. |
| 14:32.55 | leifmadsen | e.g. the values are available in the Macro or GoSub that is executed by the M() and U() flags (respectively) via a DumpChan(). But if you execute the DumpChan() on the Local channel (not in the GoSub called by Dial just prior to bridging) the values are not available. |
| 14:33.11 | leifmadsen | The ideal situation is that the values are available prior to answer, not just after |
| 14:33.19 | leifmadsen | hopes he's making some amount of sense |
| 14:33.41 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 14:33.41 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 14:33.46 | mjordan | hm |
| 14:35.02 | mjordan | I think I need to lab this up :-P |
| 14:35.27 | leifmadsen | mjordan: so I guess, think of it like a channel variable that was set with Set(__FOOBAR=baz), that would be available in the Local channel that the Queue() was calling, not just in the GoSub that the Dial (within the Local channel execution) was calling. |
| 14:35.35 | leifmadsen | mjordan: it should be relatively simple to lab up though yes |
| 14:35.46 | mjordan | leifmadsen: is it only with Local channels? |
| 14:36.02 | leifmadsen | mjordan: no, the Local channel really doesn't have anything to do with it -- it's when the values are available that the problem is |
| 14:36.18 | leifmadsen | it's just easiest to see with a Local channel since that's the only time you can execute dialplan :) |
| 14:36.29 | mjordan | leifmadsen: good. I was hoping that it was just a temporal issue, and not a 'local channels can't see this' issue. |
| 14:36.33 | leifmadsen | nope |
| 14:36.41 | leifmadsen | it's just where the values are accessible |
| 14:36.42 | leifmadsen | so for example |
| 14:36.48 | leifmadsen | this is the same thing |
| 14:37.26 | leifmadsen | Queue --> Member --> Local --> Dial(...,U(some_subroutine)) --> [some_subroutine] --> DumpChan() --> Bridge() |
| 14:37.46 | leifmadsen | is the same as just using SIP channel (instead of Local) and the queuemacro functionality |
| 14:37.50 | mjordan | right |
| 14:38.18 | leifmadsen | basically, it would be nice if the channel variables were available when the SIP channel was called, not just prior to bridging |
| 14:38.35 | leifmadsen | so when the values are set, it almost seems like they just need to be moved up the stack |
| 14:39.01 | leifmadsen | and I think the change would be really quite safe since the values would still be available in the same location they are now, but also earlier |
| 14:39.45 | leifmadsen | I think that gives you enough info to understand though |
| 14:39.53 | mjordan | leifmadsen: indeed. |
| 14:40.09 | mjordan | I understand the issue, but I'm not sure of the answer :-) |
| 14:40.10 | leifmadsen | Jim supplied some configuration data, and I'd be happy to explain or help in the lab |
| 14:40.15 | leifmadsen | mjordan: fair enough |
| 14:40.47 | mjordan | leifmadsen: yeah, I saw that. I'd like to at least provide an answer for y'all as to whether or not it was a bug or an improvement as soon as possible - newtonr and I can take a closer look at it |
| 14:40.59 | leifmadsen | maybe a reason why this is useful would help too :) Basically, if you have access to the values at the call to the Local channel, you can do logic evaluation of the values, then decide if you want to just send back Congestion(), which places the caller back into the queue and moves onto another member |
| 14:41.17 | leifmadsen | mjordan: most excellent -- it'll at least let us decide how we're going to document the functionality |
| 14:41.38 | leifmadsen | we wanted to give you guys the ability to change it if you felt that was warranted prior to Asterisk 11 release and book publication |
| 14:42.16 | leifmadsen | "you guys" being the greater you, not the you you :D |
| 14:42.49 | mjordan | I'm down with the "us" |
| 14:44.55 | leifmadsen | +1 |
| 14:45.21 | leifmadsen | definitely wanted to file it so someone with better ability to look at the code and understand what is going on could make a sane evalution |
| 14:45.42 | leifmadsen | so I appreciate your candour and willingness :D |
| 14:45.55 | leifmadsen | goes back to updating a chef cookbook to enable faxing in asterisk |
| 14:50.27 | *** join/#asterisk-dev bananapie (~david@186.94.static.oricom.ca) |
| 14:50.57 | bananapie | I am in channels, I have a struct 'ast_channel', how can I mute the audio in one direction on this channel ? |
| 14:55.38 | hurdman | 16:27 <@mjordan> hurdman: yes, ast_read will lock the channel |
| 14:55.38 | hurdman | 16:28 < hurdman> mjordan: ok thx |
| 14:55.38 | hurdman | 16:29 <@file> one lock to rule them all and in the darkness block them |
| 14:55.38 | hurdman | 16:29 < hurdman> and your name is file XD |
| 14:55.38 | hurdman | 16:29 <@mjordan> file: but only when DEBUG_THREADS is enabled |
| 14:55.47 | hurdman | arf sorry |
| 14:58.24 | mjordan | bananapie: I think that's a much larger topic than a single sentence can answer. You may want to consider looking at functions the modify the audio stream to get an idea on how to manipulate the audio on a channel. func_volume comes to mind. In your case, you wouldn't want to modify the VOICE frame so much as simply squash it, but it should give you an idea on how you should approach the problem. |
| 15:02.29 | *** part/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 15:15.50 | *** join/#asterisk-dev leedm777 (~Adium@user-69-73-1-116.knology.net) |
| 15:17.51 | *** join/#asterisk-dev malcolmd_ (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 15:17.51 | *** mode/#asterisk-dev [+o malcolmd_] by ChanServ |
| 15:21.50 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 15:21.50 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 15:38.50 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 15:38.50 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 15:47.46 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 15:47.52 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 15:57.46 | *** join/#asterisk-dev caio1982 (~caio1982@189.125.242.3) |
| 16:33.06 | *** join/#asterisk-dev ocdcoder (~user@75.76.105.124) |
| 17:42.03 | file | enjoys some OK Go whilst compiling |
| 18:49.41 | *** join/#asterisk-dev w9sh (~chatzilla@64.238.96.125) |
| 18:51.57 | file | mjordan, re: ASTERISK-20515 the referenced format post has them writing their own channel driver |
| 18:52.15 | file | since that isn't documented well they probably don't know it is their responsibility |
| 18:52.40 | mjordan | file: that's fine, but the issue tracker is not the appropriate forum to get help with channel driver semantics |
| 18:52.54 | file | agreed, and you posted what I was going to :P |
| 18:56.21 | file | adds a bit more |
| 19:41.23 | *** join/#asterisk-dev albania-asterisk (~chatzilla@92.60.25.14) |
| 19:41.26 | albania-asterisk | can somebody help me on telling me what is the difference between cli msg "RTP Read too short (x, expecting y) " and "RTP Read too short" |
| 19:42.45 | *** join/#asterisk-dev leedm777 (~Adium@nat/digium/x-vdgdaxppwloqwkki) |
| 19:45.00 | *** join/#asterisk-dev moy (~moy@UNVLON55-1176057127.sdsl.bell.ca) |
| 19:48.39 | albania-asterisk | can somebody help me understanding why you wrote in the code two ways of "RTP Read too short" and "RTP Read too short (x, expecting y )" |
| 19:48.51 | albania-asterisk | what is the difference between them |
| 19:49.38 | jmls1 | one is shorter than the other ? |
| 19:49.40 | jmls1 | ;) |
| 19:55.34 | leifmadsen | albania-asterisk: programmed at different times and didn't check for existing message? |
| 19:55.40 | leifmadsen | it's probably not anything nefarious |
| 20:00.18 | *** join/#asterisk-dev jaxon007_ (~jaxon007_@14.97.231.215) |
| 20:08.22 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 20:32.37 | jmls1 | urgh |
| 20:32.42 | jmls1 | guess this is a bad thing ... |
| 20:32.45 | jmls1 | *** glibc detected *** /usr/lib/gcc/arm-linux-gnueabihf/4.6/cc1: malloc(): corrupted unsorted chunks 2: 0x018b7230 *** |
| 20:48.11 | pabelanger | valgrind time |
| 20:48.56 | jmls1 | should all warnings be reported (chan_skinny.c:5691:6: warning: variable âcallreferenceâ set but not used [-Wunused-but-set-variable]) ? |
| 20:50.48 | pabelanger | jmls1: no, they should likely be fixed |
| 20:51.00 | pabelanger | try ./configure --enable-dev-mode and see what happens |
| 20:51.04 | pabelanger | asterisk should fail to compile |
| 20:52.23 | jmls1 | is _not_ restarting this compile. He will die of old age if he does ... |
| 20:52.50 | jmls1 | gotta learn how to cross-compile properly ;) |
| 20:52.53 | pabelanger | jmls1: what version of asterisk? |
| 20:52.56 | jmls1 | 11 |
| 20:53.05 | jmls1 | latest svn |
| 20:53.07 | pabelanger | distcc FTW |
| 20:53.16 | jmls1 | googles |
| 20:53.26 | pabelanger | distributed GCC |
| 20:53.30 | pabelanger | it is awesome |
| 20:53.45 | pabelanger | used to use it all the time when I had to work on an embedded powerpc system |
| 20:54.44 | jmls1 | ok, but would need several machines of the same architecture, right ? |
| 20:55.35 | jmls1 | has only just figured out cc |
| 21:10.39 | wedhorn | bugger, the skinny unused won't be picked with --enable-dev-mode, because it is used then. |
| 21:11.12 | wedhorn | ... the one jmls1 pointed to above |
| 21:13.05 | pabelanger | jrose_atDigium: So, I'm looking at your IPv6 test using the yaml files |
| 21:13.34 | pabelanger | hence my comment, can you not directly call event from yaml, and pass parameters to the AMI? |
| 21:13.58 | jrose_atDigium | pabelanger: Which test is this? |
| 21:14.09 | jrose_atDigium | It's been a while since I wrote an ipv6 test of any kind. |
| 21:14.25 | pabelanger | jrose_atDigium: opps |
| 21:14.27 | pabelanger | it was opticron |
| 21:14.28 | pabelanger | soory |
| 21:14.30 | pabelanger | sorry* |
| 21:14.36 | jrose_atDigium | ah, I thought that might be the case. |
| 21:14.40 | jrose_atDigium | No problem. |
| 21:14.48 | pabelanger | my bad, proceed with the flogging |
| 21:15.15 | pabelanger | either way, likely questions for mjordan, since he did most of that work |
| 21:15.15 | jrose_atDigium | Better flogged than frogged. |
| 21:19.58 | *** join/#asterisk-dev luckman212 (~luckman21@2001:470:8abb:0:211:32ff:fe10:cdc1) |
| 21:28.27 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-tksyibchcemixhxh) |
| 21:28.27 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 21:30.47 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-tksyibchcemixhxh) |
| 21:48.58 | *** join/#asterisk-dev luckman212 (~luckman21@2001:470:8abb:0:211:32ff:fe10:cdc1) |
| 21:50.53 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-155-170.cablep.bezeqint.net) |
| 21:50.54 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 23:07.30 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 23:34.20 | *** join/#asterisk-dev snuff-work (~snuffy@210.9.82.197) |
| 23:34.20 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |