IRC log for #asterisk-bugs on 20081119

04:19.45*** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir)
07:11.12*** join/#asterisk-bugs oej (n=olle@ns.webway.se)
10:04.16*** join/#asterisk-bugs mvanbaak (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak)
10:54.01*** join/#asterisk-bugs shazaum (n=shazaum@unaffiliated/shazaum)
10:55.56*** join/#asterisk-bugs shazaum (n=shazaum@unaffiliated/shazaum)
11:11.06Shazaum_workingM13538
11:11.07MuffinMan[assigned] [Asterisk] Applications/app_mixmonitor 0013538: [patch] Recording stops after Transfer when using MixMonitor() reported by mbit (Karma: neutral) http://bugs.digium.com/view.php?id=13538
11:19.52*** join/#asterisk-bugs caio1982 (i=caio1982@CAcert-br/caio1982)
13:11.08*** join/#asterisk-bugs guax (n=guaxinim@unaffiliated/guaxinim)
13:23.20*** join/#asterisk-bugs lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage)
13:23.20*** mode/#asterisk-bugs [+o lmadsen] by ChanServ
13:30.41*** join/#asterisk-bugs lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage)
13:30.41*** mode/#asterisk-bugs [+o lmadsen] by ChanServ
15:07.26*** join/#asterisk-bugs Juggie (n=Juggie@CPE001601df17fb-CM001ceac25ada.cpe.net.cable.rogers.com)
15:07.26*** mode/#asterisk-bugs [+o Juggie] by ChanServ
15:15.55*** join/#asterisk-bugs putnopvut (n=putnopvu@nat/digium/x-f619f6f7b37feb65)
15:15.55*** mode/#asterisk-bugs [+o putnopvut] by ChanServ
15:28.19*** part/#asterisk-bugs am88b (i=siim@uba.linux.ee)
15:40.59*** join/#asterisk-bugs Deeewayne (n=Deeewayn@nat/digium/x-ed9cab03995b843d)
15:40.59*** mode/#asterisk-bugs [+o Deeewayne] by ChanServ
15:41.20*** join/#asterisk-bugs Juggie (n=Juggie@CPE001601df17fb-CM001ceac25ada.cpe.net.cable.rogers.com)
15:41.20*** mode/#asterisk-bugs [+o Juggie] by ChanServ
16:01.15*** join/#asterisk-bugs shazaum (n=shazaum@unaffiliated/shazaum)
16:01.33shazaumputnopvut, yo
16:01.42putnopvuthi shazaum.
16:03.58guaxputnopvut: your patch works, not with MixMonitor, but with Monitor
16:04.05shazaum:)
16:04.22putnopvutokay...except that you shouldn't even need my patch if you use Monitor.;
16:04.32shazaumi put into production
16:05.11bearded_blitzya... my problem with Monitor() is that it DOESN'T stop after the attended transfer
16:05.13shazaumcourage
16:05.41shazaumbearded_blitz,  http://bugs.digium.com/view.php?id=13538
16:06.17shazaumops
16:06.50shazaumbearded_blitz, use b? in monitor()?
16:07.16bearded_blitznope
16:07.24bearded_blitzjust Monitor() with the 'm' option I think
16:07.27bearded_blitzchecks
16:08.08bearded_blitzyep... just 'm'
16:08.44shazaumm for mix
16:09.08bearded_blitzcorrect
16:11.31shazaumif u use b( bridged), the recording will stop
16:12.18guaxif you have luck it will begin
16:12.19guax=P
16:55.53bearded_blitzM13136
16:55.56MuffinMan[new] [Asterisk] Channels/chan_sip/General 0013136: [patch] sip peer qualified failed, asterisk lock. reported by pabelanger (Karma: +34.50) http://bugs.digium.com/view.php?id=13136
16:56.41bearded_blitzputnopvut: let me finish up with 13876 first, then I will delve into your notes
16:57.32putnopvutall righty
16:59.33bearded_blitzshouldn't take more than 30 mins I suspect
17:04.17bearded_blitzjsmith: ping?
17:04.23bearded_blitzM13876
17:04.24MuffinMan[ready for testing] [Asterisk] Applications/app_voicemail 0013876: [patch] Voicemail password does not save properly reported by darrylmc (Karma: neutral) http://bugs.digium.com/view.php?id=13876
17:04.49bearded_blitzI don't get this behaviour in latest 1.4 branch
17:05.11bearded_blitzr157503
17:06.08jsmithbearded_blitz: pong?
17:06.18bearded_blitzsee above
17:06.27jsmithRegarding M13876, I thought it already got checked in.
17:06.30bearded_blitzgoing to retest on 1.4.22 proper, but I don't see that behaviour in latest 1.4
17:06.45jsmithbearded_blitz: I tested on both 1.2 (branch) and 1.6.0 (branch) in class.
17:06.48bearded_blitzhrmm... it may have... but I don't see the issue closed
17:06.58bearded_blitzand it worked there?
17:07.07bearded_blitzCorydon76-dig: ping?
17:07.37bearded_blitzgoing to try reproducing in 1.4.22 proper I think
17:15.52Corydon76-digpong
17:16.10bearded_blitzdid you happen to commit something to fix 13876?
17:16.17bearded_blitzbecause it doesn't seem to happen on latest 1.4 SVN
17:16.29bearded_blitzI'm gonna try reproducing on 1.4.22 though to see if it happens there
17:17.46Corydon76-digbearded_blitz: maybe, by accident?
17:17.51Corydon76-digI don't think so, though
17:18.00bearded_blitzhrmmm... ok
17:18.03bearded_blitzchecking 1.4.22 right now
17:18.35bearded_blitzok... reproduced on 1.4.22
17:18.41bearded_blitzbut it's not an issue in latest 1.4 SVN anymore
17:19.32Corydon76-digAha
17:19.43Corydon76-digputnopvut fixed it without closing the issue
17:19.48bearded_blitzthat bastard!
17:19.51bearded_blitzI'll close it now
17:20.47bearded_blitzCorydon76-dig: happen to know what revision it was closed at?
17:21.06Corydon76-digHeh, he fixed it after I posted the fix to the issue, even
17:21.16Corydon76-dig156816
17:21.18bearded_blitzouch :)
17:21.19bearded_blitzthanks
17:21.46bearded_blitzoh fairly recently then
17:22.10Corydon76-digExcept that his fix introduces a new bug
17:22.21bearded_blitzuh oh!
17:22.30Corydon76-digNo, wait, it's okay
17:22.32bearded_blitzlol
17:23.22Corydon76-digWell, it's somewhat bad.
17:23.34Corydon76-digHis fix allows you to set your password to blank
17:36.11bearded_blitzputnopvut: ok, replied to requests for information 13136
17:36.28putnopvutI'm back, and I'm reading up on what I did wrong...
17:36.44putnopvutoh, the voicemail thing.
17:36.54putnopvutYeah, I didn't even know there was an issue open about it.
17:37.06putnopvutI fixed it based on jsmith finding it in a training class.
17:37.07bearded_blitzheh, well that explains why it wasn't closed :)
17:37.20bearded_blitzand why jsmith thought it was already fixed
17:37.49bearded_blitzCorydon76-dig: would that mean if I just let it time out twice the pass would be set to blank?
17:38.02Corydon76-digbearded_blitz: yes
17:38.07bearded_blitzinteresting
17:38.09bearded_blitzthat could be bad
17:38.18bearded_blitzwould lock a user out of their voicemail I would think
17:38.28bearded_blitzor would that just allow them in without auth?
17:38.30Corydon76-digNo, not really
17:38.38Corydon76-digbut it would confuse someone to no end
17:39.07Corydon76-digIt would still ask them for their password, but if they didn't enter anything, it would let them in
17:39.20Corydon76-digThat was the second part of my patch
17:40.01Corydon76-digWhat I would expect is if they got distracted, the password would not change
17:41.18bearded_blitzaye
17:41.46Corydon76-digI have an easy one for you to close... 13900
17:42.06bearded_blitzM13900
17:42.07MuffinMan[new] [Asterisk] Channels/chan_iax2 0013900: [feature request] Asterisk does not respect DNS TTL in iax.conf reported by ffadaie (Karma: +0.50) http://bugs.digium.com/view.php?id=13900
17:42.41bearded_blitzI don't know anything about DNS or IAX2
17:43.15bearded_blitzI have no idea why I would close that bug
17:48.26Corydon76-digIt's a feature request
17:50.59seanbrightif someone could point me in the right direction i would be happy to write a patch for that one
17:51.58seanbrightseems like a valid problem
17:53.28bearded_blitzpoints west-north-west
17:58.03seanbrightit looks like we save off the ttl, but we don't read it?
18:05.09Corydon76-digseanbright: it's simply the way Asterisk works... after a DNS query has returned, we cache it and don't bother to do another one until restart
18:05.17seanbrighti understand that
18:05.22seanbrightso i'd need to change dnsmgr.c?
18:05.33Corydon76-digNope
18:05.35seanbrighti'm guessing
18:05.39seanbrightpurely guessing
18:05.39seanbrighthe
18:05.41seanbrighth
18:05.46Corydon76-digYou'd need to change chan_sip.c and chan_iax.c and chan_h323.c
18:05.51seanbrightalright, will poke around
18:05.56Corydon76-digand every other driver that caches IPs
18:06.07seanbrightalrighty
18:06.09seanbrightdanke
18:35.00Juggiethe drivers dont use dnsmgr for the cacheing?
18:35.14Juggiethey all do it independantly?
19:03.04Corydon76-digpokes bearded_blitz with 13651
19:07.46bearded_blitzM13651
19:07.48MuffinMan[ready for testing] [Asterisk] Functions/func_realtime 0013651: [patch] Make func_realtime work more like app_realtime reported by Corydon76 (Karma: +444.00) http://bugs.digium.com/view.php?id=13651
19:08.27Corydon76-digIt's ready for you to rerun your identical tests
19:09.20bearded_blitzsweet
19:09.23bearded_blitzwill do soon!
19:23.31*** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir)
20:12.37bearded_blitzCorydon76-dig: test complete, only one small issue now
20:25.27Corydon76-digbearded_blitz: weird, I don't get that.
20:25.45bearded_blitzya... and i don't think the table has an extra column or anything...
20:25.46Corydon76-digbearded_blitz: you sure you didn't add a field on?
20:25.47bearded_blitzlet me double check
20:26.29bearded_blitznope... just 7 fields
20:26.37Corydon76-digI just added another patch that should tell you what the extra field is, when debug is set to 1 or higher
20:26.59bearded_blitzokie
20:27.41putnopvutbearded_blitz: you do realize the extra comma is there because you put it there, right?
20:27.52bearded_blitzeh?
20:27.53putnopvut<PROTECTED>
20:27.56bearded_blitzlooks.....
20:28.05putnopvutUnless that comma before the 105 was inserted some other way...
20:28.07bearded_blitzputnopvut: that is the result of the lookup
20:28.13putnopvutoh, nevermind. poop
20:28.27bearded_blitzeverything after the = is returned via ${REALTIME_HASH(....)}
20:28.41bearded_blitzalthough I better double check my dialplan to make sure
20:29.04bearded_blitzya... looks ok
20:29.04bearded_blitzSet(HASH(realtime_result)=${REALTIME_HASH(sippeers,name,105)})
20:29.21putnopvutOkay, gotcha.
20:29.27bearded_blitzthx though
20:31.53Corydon76-digbearded_blitz: Oh, I see.  You're complaining about HASH() not working correctly, not the realtime module
20:32.08bearded_blitzam I?  I don't think so...
20:32.14bearded_blitzthe realtime module is returning an extra ,
20:32.20bearded_blitzand assigning to HASH
20:32.36bearded_blitzas in the line putnopvut pasted
20:33.14Corydon76-digYeah, but HASH doesn't keep the value isolated.
20:33.52Corydon76-digInstead, it breaks them up and sets individual values
20:34.07Corydon76-digYou're really complaining about how HASHKEYS works, I think
20:34.23bearded_blitzI'm complaining about the data returning showing an extra field...
20:34.55bearded_blitzI'd expect to see:  HASH(realtime_result)=105,dynamic,welcome,start,192.168.128.129,5060,1227024431
20:34.58bearded_blitzand not:  HASH(realtime_result)=,105,dynamic,welcome,start,192.168.128.129,5060,1227024431
20:35.05Corydon76-digTry running HASHKEYS on the same hash name
20:35.51bearded_blitz<PROTECTED>
20:35.56bearded_blitzthere should be no null field at the end
20:36.34bearded_blitzthat trailing comma should not exist, imho
20:36.56Corydon76-digRight
20:38.10Corydon76-digbut it doesn't actually cause undesireable behavior
20:38.24bearded_blitzjust operator confusion
20:38.56bearded_blitzand it could if you're parsing on the comma using CUT()
20:39.05bearded_blitzespecially if you're doing some sort of loop
20:41.41Corydon76-digYeah, here's the thing, though... I am NOT getting the behavior you're seeing.  At all.
20:42.02Corydon76-dig-- Executing [8136@digium:5] NoOp("SIP/103-b72b55f0", "hashkeys: qualify,call-limit,allow,disallow,useragent,fullcontact,defaultuser,regseconds,port,ipaddr,host,context,type,name") in new stack
20:42.12Corydon76-dig-- Executing [8136@digium:6] NoOp("SIP/103-b72b55f0", "hash: no,3,h264,all,Grandstream GXV3000 1.1.3.8,sip:vidphone@192.168.69.71:5060,vidphone,1227127370,5060,192.168.69.71,dynamic,digium,friend,vidphone") in new stack
20:42.31Corydon76-digThere is no extra comma at all in my output
20:42.50bearded_blitzhrmmm... not like I have an empty field or anything in the DB...
20:43.02bearded_blitzand i don't see any issues with the dialplan...
20:43.05Corydon76-digSo I'm having a huge WTF moment here
20:43.09bearded_blitzaye
20:43.20Corydon76-digare you testing against current trunk?
20:43.22bearded_blitzyes
20:43.34bearded_blitzas of like... a few mins ago
20:43.39Corydon76-digHave you been smoking a doobie?
20:43.43bearded_blitzI have not
20:43.53bearded_blitzwater and crystal light... ?
20:44.06bearded_blitz(no, that is not crystal meth)
20:44.31bearded_blitzSVN-trunk-r157820M
20:44.54Corydon76-digAre you using res_config_odbc or res_config_mysql ?
20:45.02bearded_blitzres_config_odbc
20:45.18Corydon76-digAh, there's a difference
20:45.34Corydon76-digI've been testing res_config_mysql recently, and I left it alone
20:45.52bearded_blitzgotcha
20:45.53bearded_blitzmysql-connector-odbc.x86_64              3.51.12-2.2
20:46.01bearded_blitzunixODBC-devel.i386                      2.2.11-7.1
20:47.45Corydon76-digStill no change, even when I switch to ODBC
20:48.42bearded_blitzhrmmm... wtf...
20:48.57bearded_blitzideally someone else will test and maybe it's just my configuration somehow
20:49.28bearded_blitzbut its pretty simple since its just an asterisk testing VM
20:49.56Corydon76-digEw, your packages are intermixing i386 with x86_64?
20:50.16bearded_blitzwell, centos installs both
20:50.19fileCentOS.
20:50.26bearded_blitzthat was just the one I happened to highlight
20:50.42bearded_blitz/etc/odbcinst.ini points at /usr/lib64 though
21:00.52seanbrightyou have to be explicit
21:00.59seanbrightyum install pacakage.x86_64
21:01.39bearded_blitzyum install <package> installs both
21:01.44seanbrighti would just do 'yum remove *.i386 *.i686'
21:01.49seanbrightyes, it's dumb
21:01.59seanbrightyou want both?
21:03.45bearded_blitzits a development box, and I've never had an issue before with that
21:04.02bearded_blitzbut just for fun I'll remove and rebuild asterisk
21:04.29seanbrightyeah, i do that for fun sometimes too
21:04.30seanbright:)
21:21.33bearded_blitzCorydon76-dig: well, since you don't seem to have the issue, and I can't verify where the extra comma is coming from (and since it appears to work) I suppose commit away, unless you have any other ideas
21:58.43*** join/#asterisk-bugs codefreeze-lap (n=murf@72.21.67.40)
21:58.56bearded_blitzM13857
21:58.58MuffinMan[new] [Asterisk] Channels/chan_sip/General 0013857: Periodic and returned: sip_xmit returned -1: Operation not permitted reported by alephlg (Karma: neutral) http://bugs.digium.com/view.php?id=13857
21:59.00bearded_blitz...ummm... huh?
21:59.10putnopvutlet's have a look...
21:59.50putnopvutso something is returning EPERM in sip_xmit...let's see what that could be.
21:59.58putnopvutor is setting errno to EPERM, more likely.
22:01.28putnopvutit's the sendto() that's doing that....time to check the man page.
22:03.19putnopvutactually, it appears errno is set to EACCES and not EPERM, my mistake.
22:04.06bearded_blitzman... trunk changes FAST... I just updated like... an hour ago, and like 20-30 files have been changed since then
22:09.53bearded_blitzhrmm weird... I can't get to it from here
22:25.32putnopvutI left a note on 13857 to be sure that permissions are set properly.
22:25.44bearded_blitzthx!
22:25.49bearded_blitzI was kinda thinking something like that myself
22:29.00putnopvutyeah, hopefully it won't be a huge issue since he says he has another server where things work. I told him to compare the permissions between the two servers and see if anything jumps out at him.
22:29.23putnopvutI wish I knew more specifically why a sendto(2) would fail due to a permission problem, though :-/
22:29.45putnopvutThen I could actually propose a solution. The man page is less than helpful, though.
22:31.22bearded_blitzalways nice
22:31.36bearded_blitzM13764
22:31.37MuffinMan[new] [Asterisk] Applications/app_dial 0013764: 302 Redirect (forward no answer)  to bad extension causes channel to be left up (Ringing) reported by davidw (Karma: +5.75) http://bugs.digium.com/view.php?id=13764
22:31.45bearded_blitzputnopvut: suppose you don't have a second to look at that one?
22:31.53putnopvutI'll take a look.
22:32.20bearded_blitzLocal channel and status updates slow... sounds like something I've seen before
22:33.13*** join/#asterisk-bugs telecos (n=sergio@84.166.219.87.dynamic.jazztel.es)
22:34.44mnicholsonanyone care to comment on http://bugs.digium.com/view.php?id=13790
22:35.25bearded_blitzmnicholson: I believe the latter is better, but might only be able to go into trunk
22:35.42bearded_blitzand then stats should reset on 1.4.x if that was the functionality prior to 1.4.22
22:36.02Corydon76-digmnicholson: I agree with your recommendation
22:36.21Corydon76-digI think it's been a long standing complaint that they were reset on a reload
22:37.19Corydon76-dig"queue reset stats", though
22:37.27Corydon76-digreset is a verb, stats is not
22:38.34bearded_blitzalso agreed
22:39.43putnopvutbefore anyone does anything on 13790, I have a branch called queue_reset which has a bunch of new commands related to reloading/resetting queues.
22:40.04putnopvutI had originally written it because jsmith had requested it, but I had not finalized it.
22:40.40putnopvuthttps://origsvn.digium.com/svn/asterisk/team/mmichelson/queue_reset
22:40.50putnopvuthttps://origsvn.digium.com/svn/asterisk/team/mmichelson/queue-reset
22:40.52putnopvutmy mistake.
22:42.54putnopvutand holy crap is that branch out of date.
22:42.58bearded_blitznote added with a link to the branch (the non-origsvn version)
22:43.01bearded_blitzI can imagine :)
22:44.11putnopvutI'm going to see what conflicts need to be resolved...I imagine it's not going to be pretty.
22:44.45QwellM11502
22:44.47MuffinMan[confirmed] [Asterisk] Core/NewFeature 0011502: [patch] allow multiple skip_ms in waitstream_core() reported by dovidz (Karma: neutral) http://bugs.digium.com/view.php?id=11502
22:44.54putnopvutthat's still open?
22:44.54QwellCan somebody give me a use case?  Why wouldn't you just hit the key a few times?
22:45.29putnopvutQwell: I suppose it's the same reason why there are arrow keys on a keyboard and page up and page down keys.
22:46.02mnicholsonQwell, it could be used for dictation apps
22:46.06putnopvutoh, and on a nice note, the conflicts in the queue-reset branch don't appear to be too bad at all :)
22:46.07QwellThey served different functions. :D
22:46.31Qwellmnicholson: but even then, why not just hit the key a few times?
22:46.54QwellYou're never going to say "that sentence was exactly 5 seconds, I'll hit THIS key instead of THAT key."
22:46.56bearded_blitzmakes sense to me...
22:46.58mnicholsonbecause you could make one skip 1 sec and another 30 secs, that makes a big difference
22:47.05bearded_blitzalso true :)
22:47.33bearded_blitzas long as the differences in time are great enough, I'd say it has a useful function if someone left you a long message
22:47.45Qwellin most cases, this is using the same value for all 3 (why 3?)
22:48.05bearded_blitzthat seems like a lot...
22:48.17Qwelland it's an API change, to boot.
22:48.35QwellAND, there's no implementation of it.
22:50.07putnopvutno implementation?
22:50.10putnopvutThen wtf?
22:50.13Qwellnothing uses it.
22:50.33Qwellit just adds the ability to use it..
22:50.34mnicholsonthis implementation is not very elegant, but i see a use for it, basically only in dictation apps
22:50.53Qwellmnicholson: but then why not just add it to app_dictate, ya know?
22:51.00mnicholson(or anything else that involves reviewing audio files over the phone)
22:51.14mnicholsonQwell, yeah, that's the obvious thing to do
22:52.57Qwellclosed
22:53.35bearded_blitzheh
23:18.48*** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir)
23:42.04putnopvutI left a note on issue 13790.
23:42.24putnopvutI hadn't realized the issue reported was against 1.4 when I brought up that branch of mine.
23:42.39putnopvutSo it may seem like my note contradicts what I had said in here before.

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.