| 00:00.16 | snuff-work | could we easily cater for that? |
| 00:00.38 | Corydon76-lap | theoretically |
| 00:01.03 | Corydon76-lap | We do rounding otherwise |
| 00:01.08 | snuff-work | ${CDR(billsechr)} ? |
| 00:01.29 | Corydon76-lap | Eh? |
| 00:01.32 | snuff-work | or just have a flag in asterisk.conf / cdr.conf that billsec should be reported as float? |
| 00:01.55 | Corydon76-lap | Ick, no |
| 00:02.02 | Corydon76-lap | Use a flag to the CDR() function |
| 00:02.41 | snuff-work | we have any flags currently to that? or it would be new like CDR(field,sec|msec) ? |
| 00:03.04 | Corydon76-lap | We already have flags |
| 00:03.38 | Corydon76-lap | l,r,s,u |
| 00:04.28 | Corydon76-lap | Maybe an 'f' flag, for 'floating point' |
| 00:04.29 | snuff-work | heh shows you how much i really use * now ;) |
| 00:04.40 | snuff-work | 'f' seems reasonable |
| 00:06.01 | snuff-work | i might have a go at making this the 'better' way in 8-10hrs time.. |
| 00:06.49 | Corydon76-lap | It'll take you 8 hours to code this? |
| 00:07.02 | snuff-work | no.. i have to do 'real work' its 11am |
| 00:07.13 | snuff-work | 6pm is when i'm back on the train :) |
| 00:07.17 | snuff-work | for 2 hrs |
| 00:07.59 | Corydon76-lap | Do the calculation directly in func_cdr.c |
| 00:08.16 | Corydon76-lap | We don't need yet another API change to cdr.c |
| 00:09.29 | snuff-work | agreed.. u can criticise my bad patch in 8-10hrs :) |
| 00:09.36 | snuff-work | goes on-site |
| 00:09.58 | Corydon76-lap | In 8-10 hours, I'll be in bed |
| 00:10.07 | snuff-work | well whenver u see it :) |
| 00:24.11 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 00:24.11 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 00:45.19 | *** join/#asterisk-dev snuff-work (n=aaa@120.19.217.82) |
| 00:45.19 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 01:38.06 | *** join/#asterisk-dev ZX81 (n=Matt_Rid@121-74-232-236.telstraclear.net) |
| 01:38.31 | ZX81 | m16531 |
| 01:38.34 | MuffinMan | [closed] [Asterisk] Applications/app_mp3 0016531: [regression] chan_local audio crash reported by john8675309 https://issues.asterisk.org/view.php?id=16531 |
| 01:38.40 | ZX81 | looks only half fixed |
| 01:39.01 | ZX81 | just installing a smoothtorque for a customer and it seems local channels cause only half to work |
| 01:39.17 | ZX81 | Channe: Local/s@simul |
| 01:39.19 | ZX81 | *channel |
| 01:39.23 | ZX81 | Context: bla |
| 01:39.27 | ZX81 | Exten: s |
| 01:39.31 | ZX81 | Priority: 1 |
| 01:39.38 | ZX81 | s@simul does answer |
| 01:39.45 | ZX81 | and call never goes to bla,s,1 |
| 01:40.52 | ZX81 | reverting Asterisk 1.4 to earlier revision |
| 01:41.05 | ZX81 | had a look through commits - didn't notice anything that should kill it |
| 01:43.09 | ZX81 | SVN-branch-1.4-r238915 - fails |
| 01:43.09 | ZX81 | SVN-branch-1.4-r189991 - works |
| 01:43.19 | ZX81 | will try narrow those a bit to find the commit |
| 01:51.40 | ZX81 | SVN-branch-1.4-r229965 - works |
| 01:55.30 | *** join/#asterisk-dev sgimeno (n=santiago@80.33.64.226) |
| 01:58.07 | ZX81 | SVN-branch-1.4-r232268 - works |
| 02:02.20 | ZX81 | SVN-branch-1.4-r232355 - works |
| 02:04.27 | ZX81 | SVN-branch-1.4-r235000 - works |
| 02:04.28 | ZX81 | :D |
| 02:04.34 | ZX81 | fun commentary aye :) |
| 02:15.23 | snuff-work | long as it helps u get to the right point |
| 02:15.33 | ZX81 | :D yep |
| 02:15.36 | ZX81 | found it |
| 02:16.04 | ZX81 | Repository: asterisk |
| 02:16.04 | ZX81 | Revision: 236981 |
| 02:16.04 | ZX81 | U branches/1.4/channels/chan_local.c |
| 02:16.05 | ZX81 | ------------------------------------------------------------------------ |
| 02:16.07 | ZX81 | r236981 | tilghman | 2009-12-30 15:57:10 -0600 (Wed, 30 Dec 2009) | 9 lines |
| 02:16.11 | ZX81 | Don't queue frames to channels that have no means to process them. |
| 02:16.13 | ZX81 | before works after doesn't |
| 02:16.45 | snuff-work | mmm |
| 02:23.12 | seanbright | oh great |
| 02:23.39 | ZX81 | :) writing up bug track entry with exact steps to reproduce - 100% reproducible |
| 02:23.41 | seanbright | that was one of those "too good to be true fixes" that we thought was actually going to work :/ |
| 02:23.58 | ZX81 | heh yeah - maybe just needs wait to be able to receive audio? |
| 02:28.28 | ZX81 | M16581 |
| 02:28.30 | MuffinMan | [new] [Asterisk] Channels/chan_local 0016581: Chan Local Fails to bridge from originate reported by ZX81 https://issues.asterisk.org/view.php?id=16581 |
| 03:04.00 | *** join/#asterisk-dev denon (n=denon@synapse.subneural.net) |
| 03:04.19 | Corydon76-dig | seanbright: Please don't assign issues to me without first talking to either myself or Russell |
| 03:04.53 | Corydon76-dig | seanbright: if you want to take it, that's fine, but Russell gets pissed if I spend time on things when he has assigned other priorities to me |
| 03:06.24 | seanbright | sigh |
| 03:06.46 | seanbright | OK Corydon76-dig, I will not assign issues to you. |
| 03:08.02 | Corydon76-dig | Thank you |
| 03:08.08 | seanbright | You are welcome. |
| 03:09.51 | seanbright | russellb: since Corydon76-dig's recent change caused a regression (see M16581), i would like to assign that issue to him. please let me know. |
| 03:12.11 | Corydon76-dig | seanbright: he's out until Friday |
| 03:12.27 | seanbright | i'm sure he'll see it |
| 03:12.34 | seanbright | and if not there is always copy/paste :) |
| 03:13.06 | Corydon76-dig | seanbright: there's a process that you don't have a view towards that he uses to assign an issue to me |
| 03:13.36 | seanbright | i'm not sure how that is relevant |
| 03:13.51 | seanbright | you said to speak with you or him before assigning an issue to you |
| 03:14.01 | seanbright | so i am doing as you suggested |
| 03:32.16 | Corydon76-dig | I'm sorry; I'm not trying to piss you off; I'm trying to abide by a decision made by my supervisor. I know that's not the helpful self that you've come to expect, but I have to keep my supervisor happy. |
| 03:38.51 | *** join/#asterisk-dev devmod (n=devmod@c-76-100-208-204.hsd1.md.comcast.net) |
| 03:57.38 | *** join/#asterisk-dev sgimeno (n=santiago@226.Red-80-33-64.staticIP.rima-tde.net) |
| 05:55.38 | *** join/#asterisk-dev ZX81 (n=Matt_Rid@121-74-232-236.telstraclear.net) |
| 07:17.19 | *** join/#asterisk-dev infobot (i=ibot@rikers.org) |
| 07:17.19 | *** topic/#asterisk-dev is Topic for #asterisk-dev is: Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- http://www.xkcd.org/664/ |
| 07:22.54 | *** join/#asterisk-dev ayrjola (n=ayrjola@gw.ccxtech.fi) |
| 08:02.34 | *** join/#asterisk-dev sgimeno (n=santiago@226.Red-80-33-64.staticIP.rima-tde.net) |
| 08:04.47 | *** join/#asterisk-dev tzafrir (n=tzafrir@local.xorcom.com) |
| 08:04.47 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:20.59 | *** join/#asterisk-dev jtodd (i=n6qlzbwd@asterisk/community-director-and-tie-dye-shirt-lover/jtodd) |
| 08:20.59 | *** join/#asterisk-dev jetsnoc (n=brian@72.22.242.66) [NETSPLIT VICTIM] |
| 08:20.59 | *** join/#asterisk-dev seanbright (n=sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 08:20.59 | *** join/#asterisk-dev Daviey (n=Daviey@ubuntu/member/pdpc.gold.Daviey) [NETSPLIT VICTIM] |
| 08:20.59 | *** join/#asterisk-dev edguy3 (n=edguy3@c-98-221-27-224.hsd1.nj.comcast.net) |
| 08:21.00 | *** join/#asterisk-dev angler (n=angler@pdpc/sponsor/digium/angler) |
| 08:21.00 | *** join/#asterisk-dev Corydon76-dig (i=indigo@c-69-137-80-31.hsd1.tn.comcast.net) |
| 08:21.00 | *** mode/#asterisk-dev [+ooo jtodd seanbright Corydon76-dig] by irc.freenode.net |
| 08:23.21 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 08:33.15 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 08:33.15 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:33.55 | oej | Morning, folks |
| 08:34.03 | mvanbaak | mornin oej |
| 08:34.31 | oej | Good morning, sir. |
| 08:42.19 | mvanbaak | how are you ? |
| 08:42.25 | mvanbaak | everthing worked out this weekend ? |
| 08:43.55 | oej | Yes, I'm still alive... |
| 08:44.21 | mvanbaak | good |
| 08:44.23 | *** join/#asterisk-dev wildzero-cw (n=chatzill@80.153.116.54) |
| 08:44.51 | mvanbaak | meh, the DNS server they use here is not portable. Cannot compile it on linux by default |
| 08:44.54 | mvanbaak | hurray |
| 08:45.07 | *** join/#asterisk-dev ZX81 (n=Matt_Rid@121-74-232-236.telstraclear.net) |
| 08:45.25 | ZX81 | I'm seeing this in 1.4 too |
| 08:45.34 | ZX81 | M16106 |
| 08:45.37 | MuffinMan | [closed] [Asterisk] Core/General 0016106: [patch] Hangup extension executed twice in 1.6.2 RC2 reported by ajohnson https://issues.asterisk.org/view.php?id=16106 |
| 08:45.46 | ZX81 | h extension executed twice |
| 08:45.56 | oej | Morning ZX81 |
| 08:45.59 | ZX81 | call comes from sip client, goes to outgoing context |
| 08:46.07 | ZX81 | runs get_rate.php - makes call |
| 08:46.26 | ZX81 | h runs agi twice |
| 08:46.29 | ZX81 | same uniqueid |
| 08:46.34 | ZX81 | oej: morning :D |
| 08:47.04 | ZX81 | oej: is there a way to make Asterisk change codec settings in realtime to go with your RTCP stats? |
| 08:47.06 | ZX81 | :) |
| 08:48.23 | oej | zx81: THat would be lovely and has been in my long term plan for ages. But let's first make sure we get the data correctly parsed and handled. |
| 08:48.35 | ZX81 | :D yeah totally |
| 08:48.36 | oej | I want alarms and triggers for bad quality situations |
| 08:48.45 | oej | Also want statistics per SIp device in sip.conf |
| 08:48.45 | ZX81 | yah |
| 08:48.56 | ZX81 | into realtime? |
| 08:48.59 | oej | So you could check with SIPPEER before a call |
| 08:49.10 | ZX81 | right yah |
| 08:49.10 | oej | And into realtime storage too. |
| 08:49.23 | ZX81 | would be good for a large db of providers too |
| 08:49.26 | oej | I want manager alerts saying "This device is suddenly on a poor connection". |
| 08:49.39 | ZX81 | we weight each provider based on previous quality - but it's a manual process |
| 08:49.46 | oej | Have call centers with calls that go on for hours for agents. If the quality disappear, I don't want to send them any calls. |
| 08:49.54 | ZX81 | yah |
| 08:50.01 | oej | So I need it in manager, during the call. |
| 08:50.28 | oej | What I really haven't figured out is how to aggregate it on a peer level. |
| 08:50.51 | ZX81 | right yah |
| 08:51.14 | ZX81 | as in how bad is it to be bad |
| 08:51.17 | ZX81 | and for how long |
| 08:51.28 | ZX81 | is a blip bad or just a continued bad situation |
| 08:51.45 | ZX81 | are lots of blips followed by lots of good, bad :) |
| 08:52.57 | *** join/#asterisk-dev vrban (n=chatzill@p50997436.dip0.t-ipconnect.de) |
| 08:53.50 | oej | Right |
| 08:54.05 | oej | A temporary drop should not affect the overall statistics. |
| 08:54.12 | ZX81 | yah |
| 08:54.13 | oej | But if the drop is the last report we got, there's a warning. |
| 08:54.25 | ZX81 | :D true |
| 08:54.45 | oej | If it's really serious, we still have the OPTIONS stuff. But that doesn't really show packet loss and jitter. |
| 08:54.57 | ZX81 | yah |
| 08:56.33 | *** join/#asterisk-dev ayrjola (n=ayrjola@gw.ccxtech.fi) |
| 08:57.16 | ZX81 | man this is driving me crazy - it's running h exten twice on the same call - same uniqueid etc - can't see why or how to stop it |
| 09:05.02 | mvanbaak | what is driving me crazy is that even if I tell asterisk to bind to a specific ip alias on my system, the outgoing traffic still appears on the default ip address |
| 09:05.39 | ZX81 | really? weird have it bound to an alias on one of the machines here |
| 09:05.45 | ZX81 | before binding it was a problem |
| 09:05.48 | ZX81 | but not after |
| 09:05.57 | ZX81 | version? |
| 09:06.01 | mvanbaak | trunk |
| 09:06.12 | ZX81 | ah |
| 09:06.13 | ZX81 | :) |
| 09:06.19 | ZX81 | hehe |
| 09:06.58 | mvanbaak | bindaddr=192.168.2.4 |
| 09:07.10 | mvanbaak | my firewall has rules to route traffic from .4 out over my DSL line |
| 09:07.30 | mvanbaak | but the other end asterisk box shows it connects with my CABLE line |
| 09:07.36 | *** join/#asterisk-dev sgimeno (n=santiago@226.Red-80-33-64.staticIP.rima-tde.net) |
| 09:07.46 | ZX81 | netstat -lnutp |
| 09:07.54 | ZX81 | is it listening on that address? |
| 09:07.59 | mvanbaak | causing 1-way audio (because incoming rules dont apply on the cable line, only dsl line) |
| 09:08.09 | ZX81 | yah |
| 09:08.14 | tzafrir | http://pastebin.ca/1748035 - asterisk won't hang up on an endless loop |
| 09:08.20 | tzafrir | worth pursuing? |
| 09:08.29 | mvanbaak | udp 0 0 192.168.2.4:4569 0.0.0.0:* 29855/asterisk |
| 09:08.32 | mvanbaak | yup |
| 09:08.44 | ZX81 | :) heh |
| 09:08.46 | ZX81 | weird then |
| 09:08.50 | mvanbaak | yeah |
| 09:15.32 | *** join/#asterisk-dev kaii (n=kai@ciphron.de) |
| 09:18.07 | *** join/#asterisk-dev mpe (n=mpe@217.74.220.92) |
| 09:19.21 | *** join/#asterisk-dev mpe (n=mpe@217.74.220.92) |
| 09:21.11 | *** join/#asterisk-dev mpe_ (n=mpe@217.74.220.92) |
| 09:21.57 | *** join/#asterisk-dev mpe (n=mpe@217.74.220.92) |
| 09:23.33 | mvanbaak | hhmm, found it. |
| 09:23.44 | mvanbaak | but now it wont register anymore ;) |
| 09:23.57 | mvanbaak | [Jan 12 10:17:10] ERROR[30218]: chan_iax2.c:1687 iax2_destroy_helper: FRACK!, Failed assertion s != NULL (0) |
| 09:24.38 | ZX81 | :D |
| 09:25.29 | ZX81 | I found mine too - h gets run on " Bridge stops bridging channels" and as well on " Soft-Hanging up channel 'SIP/6848607-0000000f'" |
| 09:25.35 | ZX81 | dunno why though |
| 09:26.27 | *** part/#asterisk-dev ZX81 (n=Matt_Rid@121-74-232-236.telstraclear.net) |
| 09:26.30 | *** join/#asterisk-dev mpe_ (n=mpe@217.74.220.92) |
| 09:27.53 | *** join/#asterisk-dev mpe (n=mpe@217.74.220.92) |
| 09:29.40 | *** join/#asterisk-dev ZX81 (n=Matt_Rid@121-74-232-236.telstraclear.net) |
| 09:32.40 | ZX81 | mine is exactly the same as this one but for 1.4: |
| 09:32.45 | ZX81 | M16106 |
| 09:32.48 | MuffinMan | [closed] [Asterisk] Core/General 0016106: [patch] Hangup extension executed twice in 1.6.2 RC2 reported by ajohnson https://issues.asterisk.org/view.php?id=16106 |
| 09:32.59 | *** join/#asterisk-dev mpe (n=mpe@217.74.220.92) |
| 09:45.29 | ZX81 | HAH |
| 09:45.31 | ZX81 | got it |
| 09:45.39 | ZX81 | if the priority is 1 when you hang up it happens |
| 09:45.40 | ZX81 | :D |
| 09:45.59 | ZX81 | -if (chan->priority != 1 || !spawn_error) { |
| 09:46.00 | ZX81 | +if (chan->priority >= 1 || !spawn_error) { |
| 09:46.06 | ZX81 | looks like it should be added to 1.4 |
| 09:46.22 | ZX81 | anyway - fixed on my machine by adding NoOp(bla) before AGI(bla) |
| 09:46.23 | ZX81 | :D |
| 09:59.48 | *** join/#asterisk-dev mpe (n=mpe@217.74.220.92) |
| 10:16.32 | *** join/#asterisk-dev mpe_ (n=mpe@217.74.220.92) |
| 10:16.59 | *** part/#asterisk-dev mpe_ (n=mpe@217.74.220.92) |
| 10:17.39 | *** join/#asterisk-dev mpe (n=mpe@217.74.220.92) |
| 10:19.29 | *** part/#asterisk-dev mpe (n=mpe@217.74.220.92) |
| 10:23.11 | *** join/#asterisk-dev mpe (n=mpe@217.74.220.92) |
| 10:23.57 | *** join/#asterisk-dev mpe_ (n=mpe@217.74.220.92) |
| 10:51.58 | *** join/#asterisk-dev sgimeno (n=santiago@226.Red-80-33-64.staticIP.rima-tde.net) |
| 11:02.49 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 11:02.49 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:02.58 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:22.35 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:22.35 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:04.52 | tzafrir | still wonders what shell actually has problems with '[' and what 'test' has problems with '' |
| 12:06.21 | tzafrir | wonders if we ever get patches to make Asterisk compatible compatible to pre-ansi-C CC-s |
| 12:12.00 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 12:17.50 | snuff-home | that be a lot of wondering tzafrir ;) |
| 12:19.18 | sergee | i've caught a deadlock today on 1.6.0 branch, unfortunately i didn't dump a core, all i have is a "core show locks" |
| 12:19.20 | snuff-home | gave up on trying to be 'inteligent' with the modification for billsec.. i could only come up with another dirty hack or 2 |
| 12:19.39 | sergee | http://pastebin.ca/1748174 |
| 12:23.06 | sergee | what is the best way to dump core of a deadlocked asterisk? kill -11 <PID> ? |
| 12:34.21 | *** join/#asterisk-dev eliel (n=eliels@200.61.172.61) |
| 12:34.21 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 12:36.14 | atis_work | sergee: kill -6 |
| 12:36.23 | atis_work | at least that's what i do |
| 12:36.48 | eliel | snuff-home: hello |
| 12:37.05 | *** join/#asterisk-dev bencer (n=bencer@heal.cauterized.net) |
| 12:37.15 | atis_work | sergee: it doesn't look like deadlock |
| 12:37.46 | atis_work | everything is waiting for thread 27806608 chan_sip sip_read |
| 12:38.20 | atis_work | the question is why it doesn't complete |
| 12:38.42 | bencer | hi all, i'm using trunk and asterisk is trying to scape all ',' in the realtime applicationdata fields with a \ slash before the ',' so all the realtime ldap queries fail. has been any recent change about this ? using 1.6.2.0 works, but not with trunk ... |
| 12:44.59 | sergee | atis_work: well, it's blocking whole system, new invites are silently inored |
| 12:45.57 | atis_work | as far as i have experienced deadlocks, it would be deadlock if it would be waiting for last lock (channel.c 2580) |
| 12:46.11 | atis_work | perhaps the function exited and failed to unlock |
| 12:51.47 | sergee | uptime was about a week, and there were more then 395000 calls completed before that lock. |
| 12:54.19 | *** join/#asterisk-dev MrChimpy (n=MrChimpy@193.104.78.200) |
| 12:56.35 | MrChimpy | does patching pbx_spool to provide a callerid-ton: and callerid-pres: field sound sensible to you guys? There doesn't seem to be a means of setting these - varset: does normal dialplan variables not stuff like Set(CALLERPRES()= as far as I can see. |
| 12:57.26 | MrChimpy | i'm part way through doing it but best to check i'm not missing something! |
| 13:05.13 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 13:07.21 | kpfleming | MrChimpy: varset does allow dialplan functions to be set, just like variables |
| 13:10.13 | MrChimpy | eeek :) |
| 13:11.40 | atis_work | sergee: i can only recommend to do nightly restarts if system is not used at night time.. that helps a lot :) |
| 15:14.57 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 15:28.38 | *** join/#asterisk-dev The_Boy_Wonder (n=vossel@asterisk/batman-developer/dvossel) |
| 15:28.38 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 15:49.13 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 15:51.00 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:51.00 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:51.33 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 15:51.33 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:54.59 | *** join/#asterisk-dev putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 15:54.59 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:57.07 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:57.07 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:57.07 | *** join/#asterisk-dev jameswf (n=james@unaffiliated/jameswf-home) |
| 16:17.59 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 16:18.33 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 16:18.33 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:25.25 | *** join/#asterisk-dev elguero (n=elguero@ns1.nashuacs.com) |
| 16:29.01 | *** join/#asterisk-dev CunningPike (n=CunningP@204.239.8.157) |
| 16:34.22 | *** join/#asterisk-dev moy (n=moy@189.162.161.141) |
| 16:52.41 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-6-236.dsl.telesp.net.br) |
| 16:59.06 | *** join/#asterisk-dev marv[work] (n=timr@router.asteriasgi.com) |
| 17:05.23 | *** join/#asterisk-dev Deeewayne (n=dwayne@75.76.254.162) |
| 17:05.23 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 17:06.52 | MrChimpy | looking at trunk/utils/extconf.c what's with all the lines declaring static function prototypes that are immediately followed by the actual function definition? |
| 17:07.07 | MrChimpy | like ast_get_context_name |
| 17:08.07 | MrChimpy | there's loads of them, and I'm not aware of any reason for them in the majority of cases |
| 17:09.04 | kpfleming | people have habits of doing that, even though it's not useful |
| 17:09.20 | putnopvut | Basically, the utils directory is a giant hack that very few people understand. So when the compiler complains about a missing prototype for a function, they add it immediately above the function definition. |
| 17:09.40 | MrChimpy | that's a fairly odd approach :) |
| 17:18.27 | MrChimpy | is it worth submitting a diff? |
| 17:21.31 | kpfleming | no, it's not hurting anything, so it's likely nobody would bother dealing with it soon |
| 17:22.20 | MrChimpy | blimey i'd have been shot less at places i've worked :) |
| 17:23.43 | *** join/#asterisk-dev ghenry (n=ghenry@pdpc/supporter/monthlybyte/ghenry) |
| 17:24.06 | ghenry | thanks seanbright I've been up to my eyes and not had the chance to commit those res_config_ldap.c patches |
| 17:27.47 | seanbright | sure thing |
| 17:28.54 | ghenry | cool, thanks. |
| 17:43.27 | *** join/#asterisk-dev msetim (n=setim@189.114.233.157.dynamic.adsl.gvt.net.br) |
| 17:44.20 | msetim | hello guys |
| 17:44.36 | bencer | ghenry: would you be able to commit my ldap schema updates ? |
| 17:45.32 | bencer | linked in the asterisk-users mail you replayed this week about queues on ldap |
| 18:06.45 | leifmadsen | bencer: it's be best if you could open an issue on the issue tracker and attach your patch there so that it can be committed correctly |
| 18:07.13 | bencer | leifmadsen: ok, going to do that |
| 18:07.17 | leifmadsen | thanks! |
| 18:07.31 | bencer | btw, is there any way to filter res_config_ldap tickets on the tracker ? |
| 18:08.08 | leifmadsen | bencer: yes, select the category you want to look at |
| 18:08.20 | leifmadsen | bencer: click the + button beside Search |
| 18:08.25 | leifmadsen | it's at the top-middle |
| 18:08.47 | bencer | i see, thanks |
| 18:09.44 | bencer | now i still need to figure out why i need to manually add queue members using queue add member to get realtime detect them ... |
| 18:17.15 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 18:17.48 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 18:17.48 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:26.05 | *** join/#asterisk-dev devmod (n=devmod@c-76-100-208-204.hsd1.md.comcast.net) |
| 18:56.34 | leifmadsen | philipp64: ping |
| 18:56.58 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 18:58.26 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/professional/jeffg) |
| 18:58.44 | snuff-home | eliel: ping :) |
| 19:01.27 | eliel | snuff-home: pong |
| 19:01.30 | eliel | M15402 |
| 19:01.32 | MuffinMan | [ready for review] [Asterisk] Core/Portability 0015402: [patch] Cannot find XML documentation under non linux platforms reported by snuffy https://issues.asterisk.org/view.php?id=15402 |
| 19:01.39 | eliel | snuff-home: ^^^ |
| 19:01.56 | eliel | a note was added to this issue |
| 19:03.00 | snuff-home | yes.. i noticed.. i think its fine to have the warnings |
| 19:03.12 | jsmith | eliel: Hey, I haven't seen you here in a while! |
| 19:03.38 | eliel | jsmith: yes, i was busy |
| 19:03.52 | eliel | now i am trying to get the astxml api merged |
| 19:03.55 | eliel | i am working on it |
| 19:07.20 | snuff-home | i think it can be committed as is.. if you want to remove the check he stated makes it go away so be it :) |
| 19:09.50 | eliel | snuff-home: what about removing the GLOB_NOCHECK flag? |
| 19:10.14 | philipp64 | leifmadsen: pong |
| 19:10.22 | jsmith | eliel: Great! I'm sorry to hear you've been so busy, and I'm happy to hear about the astxml api. |
| 19:10.41 | snuff-home | yer |
| 19:10.58 | snuff-home | i have nfi what that is myself :) |
| 19:10.59 | leifmadsen | philipp64: is the 3rd patch in M16090 the one I should be reviewing? |
| 19:15.26 | putnopvut | Protip: Adding a bunch of ast_log calls to ast_xml_find_element will produce an absolute crapton of output when Asterisk is started. It's ridiculous. |
| 19:15.31 | philipp64 | leifmadsen: that's right. I'd have deleted the earlier ones, but there's no "obsolete/replace" checkbox in mantis. |
| 19:15.58 | leifmadsen | philipp64: right, only marshals can delete |
| 19:16.47 | eliel | snuff-home: GLOB_NOCHECK: "If pattern does not match any pathname, then glob() returns a list consisting of only pattern, with the number of total pathnames set to 1, and the number of matched pathnames set to 0. The effect of backslash escaping is present in the pattern returned." |
| 19:23.28 | *** join/#asterisk-dev puzzled (n=foobar@puzzled.xs4all.nl) |
| 19:35.05 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:43.14 | *** join/#asterisk-dev alecdavis (n=sivad@202-78-149-14.cable.telstraclear.net) |
| 19:49.14 | alecdavis | in commit messages, is there a preferred method to provide a link to reviewboard, like there is for issues related to bugtracker. |
| 19:49.21 | kpfleming | yes |
| 19:49.27 | kpfleming | it's in the commit message template |
| 19:50.03 | alecdavis | where is the commit message template? I couldn't find it on bugtracker. |
| 19:50.12 | seanbright | it's on each issue |
| 19:50.21 | seanbright | right above "notes" |
| 19:50.29 | seanbright | it's collapsed by default |
| 19:50.31 | kpfleming | just add "Review: https://...." to your commit message |
| 19:50.39 | kpfleming | with the URL to the specific review |
| 19:51.52 | alecdavis | kpfleming, just did that .. sort of. know for next time. |
| 19:54.42 | alecdavis | re bugtracker commit message template. In advanced view, under 'notes box' all I have is 'add note'. Do I have to be a bug marshal to see it? |
| 19:58.13 | alecdavis | The word 'commit' is nowhere to be found on the advanced view page. |
| 19:59.18 | seanbright | are you logged in? it might just show for managers. |
| 19:59.39 | seanbright | and it is above notes. between 'upload file' and 'notes' |
| 20:00.01 | kpfleming | it does require a certain permission level |
| 20:00.37 | alecdavis | yes am logged in, and yes I realised my typo, under should have been above. |
| 20:01.36 | alecdavis | what permission level, and who do I ask? |
| 20:04.30 | Corydon76-dig | alecdavis: it's fairly easy to miss, as it's a collapsed paragraph |
| 20:04.47 | Corydon76-dig | Do you see the box marked "Relationships"? |
| 20:07.34 | alecdavis | corydon76-dig: see relationships. |
| 20:07.47 | alecdavis | yes I see relationships. |
| 20:07.52 | Corydon76-dig | Just above it |
| 20:08.12 | alecdavis | monitor issue button |
| 20:08.27 | Corydon76-dig | A little plus sign, next to it, it says "Commit message template" |
| 20:08.40 | alecdavis | nope. |
| 20:08.55 | Corydon76-dig | Are you a manager? |
| 20:09.12 | alecdavis | nope. But am a commiter. |
| 20:10.07 | alecdavis | just still a mere 'reporter'. |
| 20:11.12 | Corydon76-dig | Reload |
| 20:11.34 | Corydon76-dig | I elevated you to 'Developer'. You should be able to see it now. |
| 20:12.24 | alecdavis | thanks, now won't have to draft my own. |
| 20:16.40 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 20:17.19 | Corydon76-dig | I have a secondary user that I use to test things out like that on Mantis |
| 20:35.13 | *** join/#asterisk-dev Rem| (n=remi@bg-fw2out.monmouth.com) |
| 21:09.44 | philipp64 | I'm curious about how ./configure handles COPTS, LDOPTS, ASTCFLAGS, and ASTLDFLAGS in 1.6.2.0. |
| 21:11.06 | Corydon76-dig | is curious why people who are perfectly able to test functionality expect others to do it for them |
| 21:11.31 | philipp64 | if you run with ./configure ... LDFLAGS=xxx, that doesn't seem to be passed in "make" |
| 21:12.17 | philipp64 | notes that this is indeed a double-edged sword, and wonders why people don't sufficiently functionally test their changes before committing them. |
| 21:13.19 | Corydon76-dig | That's not really a change... you altered your environment, and you expected configure to automatically apply your environmental changes? |
| 21:13.56 | philipp64 | I expect the semantics of configure to be preserved, yes. |
| 21:14.14 | tzafrir | philipp64, shouldn't you set it in the environment? |
| 21:14.32 | tzafrir | LDFLAGS=xxx ./configure |
| 21:14.44 | philipp64 | I also expect what "./configure --help" says will happen to actually happen. call me gullible. |
| 21:15.12 | philipp64 | <PROTECTED> |
| 21:15.54 | Corydon76-dig | philipp64: that's specifying for configure to FIND things... not for configure to take and reapply those things to the build process |
| 21:17.06 | Corydon76-dig | We can't help it if you read things into the instructions that aren't really there. |
| 21:17.12 | tzafrir | philipp64, in which version did it work properly? |
| 21:18.23 | Corydon76-dig | Yes, is this a regression, or is this a 'I wish it worked the way I wanted it to work'? |
| 21:21.27 | philipp64 | why would it want to figure out how to FIND things, but then promptly FORGET HOW TO USE them after that discovery? |
| 21:21.43 | philipp64 | tzafrir: 1.6.2.0 |
| 21:22.25 | tzafrir | 1.6.2.0 is good or bad? |
| 21:23.00 | philipp64 | The reason automake handles @CFLAGS@ is so that the value passed to ./configure ... CFLAGS="..." will be permanently inherited by Makefile from Makefile.am |
| 21:23.17 | philipp64 | 1.6.2.0 is bad. |
| 21:23.32 | tzafrir | did this work before? |
| 21:24.13 | Corydon76-dig | Yes, but we DON'T USE Automake |
| 21:25.03 | philipp64 | I don't know.... haven't regressed it. doing some changes to the compiler to hopefully stop it from confusing the build-host's header files from the target-host's header files, and this exposed an issue... that maybe the CFLAGS=xxx (in this case, "CFLAGS=--sysroot /xyzzy -isystem /usr/include ...") wasn't being passed into the Makefile. |
| 21:25.10 | Corydon76-dig | You're throwing out assumptions about how configure works. It doesn't do that. |
| 21:25.59 | philipp64 | Corydon76-dig: you don't have to. You can save the values of "./configure ... VAR=VALUE ..." into a file, and then -include it in the Makefile. |
| 21:27.39 | tzafrir | That file is makeopts (see makeopts.in) |
| 21:28.35 | tzafrir | is off |
| 21:29.37 | Corydon76-dig | philipp64: you make it work without breaking other stuff, and we'll include your patch |
| 21:36.45 | *** join/#asterisk-dev malcolmd (n=malcolmd@pdpc/sponsor/digium/malcolmd) |
| 21:36.45 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 21:36.57 | devmod | What are the requirements for a video to be played back by Playback()? |
| 21:38.06 | jsmith | devmod: It has to be in one of the supported file formats |
| 21:38.21 | jsmith | devmod: There are probably other requirements, but I'm not sure what they might be |
| 21:39.22 | devmod | I cant seem to find info on this |
| 21:39.45 | jsmith | You probably won't find much documentation, as there are few people actually doing much with that |
| 21:39.54 | jsmith | You can try asking on the asterisk-video mailing list |
| 21:40.25 | devmod | thx will try that |
| 21:48.00 | philipp64 | Corydon76-dig: where does the final link of asterisk happen? |
| 21:52.45 | Corydon76-dig | At the end of the compile process |
| 21:53.20 | philipp64 | spatially, not temporally. "where", not "when". |
| 21:53.25 | Corydon76-dig | in main/Makefile |
| 21:55.11 | Corydon76-dig | Second to last target |
| 21:55.19 | philipp64 | so how does main/Makefile inherit ASTLDFLAGS? |
| 21:56.10 | seanbright | i would guess one of the includes |
| 21:56.26 | Corydon76-dig | It's passed on the command line |
| 21:56.59 | Corydon76-dig | Can't be included, because it's created on the fly in the top level Makefile |
| 21:57.09 | seanbright | ahh |
| 21:57.18 | seanbright | passed to the sub-make via command line? |
| 21:58.04 | Corydon76-dig | Right |
| 21:58.23 | seanbright | makes sense |
| 22:01.31 | seanbright | philipp64: do you know about 'make NOISY_BUILD=yup' |
| 22:01.32 | seanbright | ? |
| 22:02.51 | Corydon76-dig | philipp64: are you passing ASTCFLAGS to configure or CFLAGS to configure? |
| 22:05.44 | philipp64 | seanbright: yeah, yeah... so it's dropping some flags, but because of the way flags get passed in, it's hard to figure out who is doing the dropping... |
| 22:06.17 | philipp64 | Corydon76-dig: I'm passing CFLAGS, because that's what TFM (or TFS, in this case) says. |
| 22:06.44 | Corydon76-dig | Then it should work fine UNLESS there are detected overrides |
| 22:07.17 | snuff-work | Corydon76-dig: i sucked last night in making a new patch that altered the sql drivers.. (i tried making the change in func_cdr.. then looked that it used ast_get_cdr_variable..) then i made a 'if(raw)' in the function for billsec.. probably still not the best way |
| 22:10.30 | Corydon76-dig | snuff-work: Did you examine cdr_pgsql and determine how IT does it? |
| 22:11.01 | Corydon76-dig | You're already got a perfect model of how to accomplish the goal |
| 22:11.34 | snuff-work | yes.. i wanted to see if i could keep it clean.. using original function of get_cdr_varabile |
| 22:15.00 | snuff-work | oh well.. i might have another go tonight.. i guess its why i'm not a coder by profession ;) |
| 22:15.06 | *** join/#asterisk-dev TheDavidFactor (n=thedavid@nc-71-0-16-133.dhcp.embarqhsd.net) |
| 22:30.27 | *** join/#asterisk-dev TheDavidFactor (n=chatzill@nc-71-0-16-133.dhcp.embarqhsd.net) |
| 22:32.47 | *** join/#asterisk-dev puzzled_ (n=patrick@puzzled.xs4all.nl) |
| 22:35.06 | *** part/#asterisk-dev Rem| (n=remi@bg-fw2out.monmouth.com) |
| 22:37.33 | TheDavidFactor | leifmadsen, ping |
| 22:48.34 | philipp64 | Corydon76-dig: so why does main/Makefile not make use of _ASTLDFLAGS? |
| 22:48.44 | *** join/#asterisk-dev ebroad (n=EB@72.11.213.195) |
| 22:53.16 | Qwell | philipp64: it does |
| 22:54.21 | philipp64 | Qwell: how so? running "grep _ASTLDFLAGS main/Makefile" tells me otherwise. |
| 22:54.46 | Qwell | Makefile.rules |
| 22:58.11 | Qwell | or it doesn't. either way |
| 23:02.42 | Corydon76-dig | probably an oversight |
| 23:03.41 | Corydon76-dig | I hesitate to call it a bug because for platforms which didn't work before, they still don't work, so porting is not yet complete |
| 23:04.37 | Corydon76-dig | Nevertheless, you're going to harangue us for it, which makes us less likely to want to help you in the future... and the cycle continues... |
| 23:10.27 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 23:10.27 | *** join/#asterisk-dev marv[work] (n=timr@router.asteriasgi.com) [NETSPLIT VICTIM] |
| 23:10.27 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-6-236.dsl.telesp.net.br) |
| 23:10.27 | *** join/#asterisk-dev elguero (n=elguero@ns1.nashuacs.com) |
| 23:10.27 | *** join/#asterisk-dev sgimeno (n=santiago@226.Red-80-33-64.staticIP.rima-tde.net) |
| 23:10.27 | *** join/#asterisk-dev ayrjola (n=ayrjola@gw.ccxtech.fi) |
| 23:10.27 | *** join/#asterisk-dev denon (n=denon@synapse.subneural.net) [NETSPLIT VICTIM] |
| 23:10.27 | *** join/#asterisk-dev mnicholson_ (n=mnichols@nat/digium/x-pxmeyohcxqmjzjqv) |
| 23:10.27 | *** join/#asterisk-dev rbd_ (n=rbd@rrcs-98-101-33-14.midsouth.biz.rr.com) [NETSPLIT VICTIM] |
| 23:10.27 | *** mode/#asterisk-dev [+o leifmadsen] by irc.freenode.net |
| 23:11.01 | *** join/#asterisk-dev devmod (n=devmod@c-76-100-208-204.hsd1.md.comcast.net) [NETSPLIT VICTIM] |
| 23:11.01 | *** join/#asterisk-dev vrban (n=chatzill@p50997436.dip0.t-ipconnect.de) [NETSPLIT VICTIM] |
| 23:11.01 | *** join/#asterisk-dev Gugge (n=gugge@vlan2.dlxhosting.dk) [NETSPLIT VICTIM] |
| 23:11.01 | *** join/#asterisk-dev MuffinMan (n=muffinma@asterisk/issue-tracker-bot/muffinman) |
| 23:11.01 | *** join/#asterisk-dev Amorsen (n=Amorsen@94.127.50.7) [NETSPLIT VICTIM] |
| 23:18.43 | kpfleming | anyone on here have IPv6 connectivity from their current system? |
| 23:19.24 | Qwell | depending on complexity, I do have a machine with IPv6 connectivity |
| 23:19.35 | kpfleming | can you use a browser to access a web site? |
| 23:19.45 | Qwell | lynx? |
| 23:19.56 | kpfleming | yes, if it understands IPv6 |
| 23:20.03 | Qwell | should. let's see |
| 23:20.19 | kpfleming | http://[2001:470:eod4::e8] |
| 23:22.30 | Qwell | pub, favicon.iso, page-footer.html |
| 23:22.39 | Qwell | That typo was subtle.. |
| 23:22.47 | Qwell | eod4 :) |
| 23:22.47 | kpfleming | should be downloads.digium.com |
| 23:22.49 | kpfleming | oops |
| 23:22.50 | kpfleming | yeah |
| 23:22.58 | Qwell | it is indeed |
| 23:23.02 | kpfleming | fantastic |
| 23:23.16 | kpfleming | ::e9 is downloads.asterisk.org |
| 23:23.50 | Qwell | mmm, that does appear to be the case |
| 23:24.32 | ebroad | should we be sending a CANCEL when a called group does not pick up i.e. dial(tech/1&tech/2...)? |
| 23:24.48 | ebroad | i noticed this doesn't happen with a single extension |
| 23:25.12 | kpfleming | sending a CANCEL to where? |
| 23:25.16 | ebroad | caller |
| 23:25.26 | ebroad | i.e. inbound call from provider |
| 23:25.27 | kpfleming | no, CANCEL is never sent to callers |
| 23:25.34 | ebroad | hmm |
| 23:25.44 | ebroad | looks like trunk might be |
| 23:25.47 | kpfleming | CANCEL is only used to cancel an INVITE you have sent |
| 23:26.08 | kpfleming | you cannot CANCEL someone else's INVITE |
| 23:26.08 | ebroad | i have a call coming in from a provider |
| 23:26.20 | ebroad | the dial plan then calls several internal extensions |
| 23:26.32 | ebroad | using t/1&t/2&t/3... |
| 23:26.43 | ebroad | timeout is 28 seconds |
| 23:27.05 | ebroad | when dial time's out |
| 23:27.20 | ebroad | it seems we send a 487 to the provider |
| 23:27.24 | kpfleming | sure |
| 23:27.32 | kpfleming | bu 487 != CANCEL |
| 23:27.36 | ebroad | ah |
| 23:27.37 | ebroad | my bad |
| 23:27.59 | ebroad | but not with a single dial(t/1,28) etc |
| 23:28.22 | ebroad | the problem is when i dial a group, if they don't pick up, calls never go to voicemail |
| 23:28.24 | kpfleming | behavior should be the same for one or more than one... that sounds like a bug |
| 23:28.54 | ebroad | thats what i thought |
| 23:29.16 | kpfleming | what gets sent when you only dial one outbound channel? |
| 23:29.55 | ebroad | Answer |
| 23:29.59 | ebroad | then VoicemailMain |
| 23:30.06 | kpfleming | no, if they don't answer |
| 23:30.57 | kpfleming | we shouldn't be sending 487 to the provider unless they sent us a CANCEL |
| 23:31.08 | kpfleming | if we are hanging up the call because nobody answered, it should be a 480 |
| 23:31.53 | ebroad | wierd |
| 23:31.58 | ebroad | it only happens with one provider |
| 23:32.08 | ebroad | viatalk |
| 23:32.20 | kpfleming | then they are probably sending a CANCEL to you |
| 23:32.24 | *** join/#asterisk-dev snuff-work (n=aaa@210.9.82.197) |
| 23:32.24 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:32.33 | ebroad | dialplan is the same for all |
| 23:33.07 | kpfleming | is it possible the provider is timing out the call on their end? |
| 23:33.23 | ebroad | maybe |
| 23:33.23 | ebroad | thats a good point |
| 23:33.23 | ebroad | 1 sec |
| 23:34.17 | *** join/#asterisk-dev securevoip (n=securevo@c-76-123-20-170.hsd1.va.comcast.net) |
| 23:34.19 | ebroad | hehe |
| 23:34.26 | ebroad | theyre sending the cancel |
| 23:34.30 | ebroad | now i feel stupid |
| 23:34.31 | kpfleming | there you go |
| 23:34.32 | ebroad | thanx kp |
| 23:34.50 | kpfleming | sure |