IRC log for #asterisk-dev on 20080328

00:00.00Bourrelleill go there
00:02.04*** join/#asterisk-dev RoyK (n=roy@ip-233-49-149-91.dialup.ice.no)
00:05.40*** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla)
00:05.40*** mode/#asterisk-dev [+o russellb] by ChanServ
00:19.27*** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage)
00:19.27*** mode/#asterisk-dev [+o lmadsen] by ChanServ
00:52.59*** join/#asterisk-dev objective (n=objectiv@ool-43536c3b.dyn.optonline.net)
00:58.01objectiveHello developers -- I have a question regarding how Asterisk behaves in a rare circumstance.  We have an Asterisk box that rarely gets a 408 error from our provider during a SIP REGISTER.  Regardless of the issue on their end, this is a normal SIP occurrence and should be handled gracefully.  However, Asterisk gives up trying to register forever, due to line 14965 in chan_sip.c (p->registry->regattempts = global_regattempts_max+1)
01:24.36objectiveWell, if anyone reads my message later, here's a relevant part of the RFC -- http://pastebin.com/m7ed9141f
01:34.28*** part/#asterisk-dev RoyK (n=roy@ip-233-49-149-91.dialup.ice.no)
02:16.12*** join/#asterisk-dev kamitodo (n=kmt@pool-141-156-248-50.res.east.verizon.net)
02:37.55*** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg)
03:06.50*** join/#asterisk-dev jbot (i=ibot@pdpc/supporter/active/TimRiker/bot/apt)
03:06.50*** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- IAX2/guest@pbx.digium.com/asterisk-dev -=- Asterisk trunk: res_telepathy release tomorrow-=- Tier 2 and Tier 3.14159 support is in #asterisk -=- Lost: Sanity Found: Banana -=- Automated Builds, thx file! - http://buildbot.digium.com
03:25.48*** join/#asterisk-dev kyron (n=kyron@211-217-static-ppp.3menatwork.com)
03:26.08kyronsorry if this is not the place but: Q: I did (for zaptel): `./configure --prefix=/mnt/RAID5/asterisk/ && make && make install` then `./configure --prefix=/mnt/RAID5/asterisk/ --with-zaptel=/mnt/RAID5/asterisk/` for asterisk...problem is, zap_chan options are all XXX in the menu...what am-I doing wrong for *'s config to detect zaptel...?
03:30.32Corydon76-digYou're right.  This is not the place.  Try in #asterisk
03:32.23kyronsorry, tried there already and it seemed to fall through completely. I'll try in main hours then ;)
03:32.27*** part/#asterisk-dev kyron (n=kyron@211-217-static-ppp.3menatwork.com)
04:20.53*** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg)
04:27.24*** join/#asterisk-dev jameswf-home (n=james@ip72-204-221-181.ph.ph.cox.net)
04:29.30*** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla)
04:29.30*** mode/#asterisk-dev [+o russellb] by ChanServ
04:32.19*** join/#asterisk-dev CunningPike (n=arodgers@S010600095b33697f.vc.shawcable.net)
04:43.22*** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23)
04:56.59*** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23)
06:27.54*** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-159.bredband.comhem.se)
07:43.55oejMorning folks
08:13.09mvanbaakmornin
08:15.05IgorGg'day
08:29.08jmls_homemorning
08:57.42*** join/#asterisk-dev qdk (n=qdk@85.235.253.139)
10:03.20*** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23)
10:08.49*** join/#asterisk-dev sergee (n=serg@voip1.west-call.com)
10:35.36*** join/#asterisk-dev pekdon (n=noosnasc@ips-fw-01.ipsoft.no)
10:41.26*** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23)
11:07.35*** join/#asterisk-dev DagMoller (n=aguirre@unaffiliated/dagmoller)
11:09.40*** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg)
11:27.49*** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23)
11:59.52festr_guys, turn off karma on mantis at all, or add positive points too :)
12:12.00*** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982)
12:30.02*** join/#asterisk-dev JunK-Y (n=junky@modemcable153.55-201-24.mc.videotron.ca)
12:36.37jsmithfestr_: They do add positive points...
12:37.23*** join/#asterisk-dev _ys (i=yuri@91.151.196.254)
12:40.42jmlsyes. but not enough ;)
12:42.16*** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg)
12:53.52mvanbaaklol
12:55.33oejjsmith: Sorry but I just had to have a little bit of fun
12:56.11jsmithoej: Sorry about what?  Did I miss something?
12:56.20oejRead asterisk-users
12:56.43oejYou missed that the person asking was using originate
12:56.44jsmithOh, gotcha
12:57.01jsmithYeah... I was simply trying to explain the setvar setting, not show how could use it with an originate
12:57.16jsmithBut yeah, in hindsight I should have covered that too
12:57.20*** join/#asterisk-dev ctooley (n=ctooley@doc-72-47-33-80.maryville.mo.cebridge.net)
12:57.26oejThat was what he asked...
12:57.27oej:-)
12:57.30jsmithYup
12:57.41jsmithcastigates himself
12:57.42oejI need to make that patch to SIPPEER
12:57.56oejThat might be a proper friday afternoon hack
12:58.06jsmithoej: If you're in the mood to make some patches... I've got a whole list of things ;-)
12:58.22oejI'm in the mood to bill too... Be warned. Ha ha
13:02.41jsmithoej: I don't have any real money to pay, but I have a couple boxes of Girl Scout cookies left...
13:06.16oejAhh Cookies. YOu know how to get my attention
13:08.05jsmithI should try to sneak out to your SIP class and bring a box or two
13:08.26atis_workSIP cookies?
13:08.27atis_work:D
13:09.26jsmithatis_work: Yes, but I didn't send you an INVITE, only oej ;-)
13:10.01atis_workyou were broadcasting.. :D
13:13.06*** join/#asterisk-dev RoyK (n=roy@ip-233-49-149-91.dialup.ice.no)
13:20.40festr_jsmith: sometimes...
13:20.44Juggiesend some girlguide cookies
13:25.04oejjsmith: You're very welcome, with or without cookies. I'll be in Huntsville the week after the class too.
13:29.10Juggieoej, you should go to it360 in toronto april7th-9th
13:29.23oejSounds fun
13:29.29Juggietheres a whole asterisk track.
13:30.32Juggiehttp://www.it360.ca/2008/conf_glance_day.cfm?conf=8
13:31.03Juggiejsmith is going :)
13:44.12*** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.122.138)
13:56.23jmlsoej: ping
13:56.34oejPong
13:56.41jmlsyour peer-chanvars branch
13:57.05oejOh, that's just a minute old. Do I really need to support it already?
13:57.16jmlsheh. why don't you just use importvar ?
13:58.08oejjmls: Because there's no channel to import from, just a peer
13:58.16oejI want to extend SIPPEER()
13:58.21jmlsoooohhhh
13:58.31jmlsgoes back into his little hle in the ground
13:58.35jmls(hole)
13:59.06Corydon76-digwhole hole or partial hole?
13:59.06oejJuggie: Sounds like a fun conference. However, I have no funding to go to Canada... Sorry.
13:59.18Corydon76-digor spider hole?
13:59.21jmlsa hle is a small hole
13:59.22jmls;)
13:59.28*** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage)
13:59.28*** mode/#asterisk-dev [+o lmadsen] by ChanServ
13:59.43jmlsor is it a hole with the hole closed ?
14:00.36*** join/#asterisk-dev elguero (n=elguero@ns1.nashuacs.com)
14:02.25*** join/#asterisk-dev sruffell (n=sruffell@adsl-074-185-078-025.sip.bhm.bellsouth.net)
14:02.26*** mode/#asterisk-dev [+o sruffell] by ChanServ
14:18.15*** join/#asterisk-dev VoicePulse (n=contact@unaffiliated/voicepulse)
14:19.58*** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1)
14:19.58*** mode/#asterisk-dev [+o putnopvut] by ChanServ
14:20.43Juggieoej, a nice simple fix sip bug just got posted
14:20.58oejOh dear. I am not sure I agree though.
14:21.14oejWe need a "restart registrations" mechanism.
14:21.48Juggiewell, per the rfc i just looked up once you receive a 408 you may retry at any point in the future no restrictions.
14:21.54Juggiei'm sure you know that :)
14:24.27Juggieyou dont think just retrying is the right thing to do?
14:36.39oejWell, faulty configurations just don't resolve by accident. You will need to reconfigure for most errors with registrations.
14:37.17oejSo I don't see the point in Asterisk continuing registrations. But we might have a CLI and manager command to retry after an error, so you don't have to run "sip reload"
14:38.15Juggiewe could retry and with each failed retry exponentially increase the time until we retry again
14:43.13*** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.pa.comcast.net)
14:43.16ZaVoidhey guys
14:43.37ZaVoidwhat do you think is the best way to go about getting more concurrent calls on my boxes?  more ram? bigger proc?
14:45.00*** join/#asterisk-dev jpeeler (n=jpeeler@216.207.245.1)
14:45.10Corydon76-digWider bus?
14:45.45Corydon76-digYou're going to have to run metrics to figure out what is the bottleneck currently
14:45.48ZaVoidnot a bandwidth issue i dion't thnk
14:46.02ZaVoidi'm htting like 70 load average right now iwht 200 concurrent calls
14:46.29Corydon76-digThen you probably need more CPU
14:46.30fileyour question is flawed, what are these "calls" doing? is transcoding going on? is there file playback?
14:46.34ZaVoidi think its cuz i'm answering 1/2 the calls and keeping the media on tbe box for those calls
14:46.35Corydon76-digAre you doing transcoding?
14:46.39ZaVoidyes file there is
14:46.41ZaVoidno transcoding
14:46.59ZaVoidmy load jumped a ton when i started ansewring the calls and playing balance messages(which i knew it would happen)
14:47.04Corydon76-digSo your files are all in the same format that you play them as?
14:47.11ZaVoidi'm just trying to think if i need bigger procs... or just more ram
14:47.16ZaVoidi got 3gb of ram on each one now
14:47.19ZaVoidno
14:47.21ZaVoidnot at all
14:47.26filemove them to a ramdisk
14:47.30ZaVoidi record all my files in 8bit mono wav
14:47.31Corydon76-digIf you're playing gsm files to ulaw, you're doing transcoding
14:48.02ZaVoidmove the /var/lib/asterisk/sounds to a ram disk file?
14:48.04Corydon76-digThen you're definitely doing transcoding.  wav files are slin, not compressed
14:48.25ZaVoidso change em all to g729 format?
14:48.28Corydon76-digTranscode all your files to the exact format that you're playing to your channels
14:48.35fileyou are using g729?
14:48.38ZaVoidyes
14:48.47Corydon76-digGet a TC400 card
14:48.57ZaVoid95% of the calls are g729.. the others are g711
14:49.01ZaVoidthe tc400b?
14:49.11fileconvert the sounds to all applicable formats, g729 and ulaw
14:49.11ZaVoidthat thing gave me 2 months of problems last summer
14:49.13Corydon76-digThat's going to go the longest way to alleviating CPU load
14:49.13ZaVoidwith g723
14:49.14fileand move to ramdisk
14:49.38Corydon76-digfile: ramdisk won't help him that much
14:49.38ZaVoidi'll try the ramdisk monday and then the transcoding
14:49.47fileCorydon76-dig: you would be surprised...
14:49.50ZaVoidmy boxes are still doing ok wth 70 load though :)
14:49.54Juggieit depends how desperate you are to save bandwidth
14:49.56Corydon76-digOnce the files are loaded once, they pretty much stay in disk cache
14:50.03ZaVoidmy biggest bottleneck i think is the DB(i'm adding more)
14:50.19ZaVoidbut i know i'm gonna top out soon on the concurrent calls
14:50.33ZaVoidthe high load average just bothers me a bit heh
14:50.41Corydon76-digramdisk will only help you out on the very first playback after a restart
14:50.47JuggieZaVoid, its due to all the transcoding
14:51.07Juggieeverything is being converted wav->g729 for all your g729 calls.
14:51.13Corydon76-digYeah, it's the transcoding.  g729 is not exactly a light codec
14:51.36ZaVoidwhas the best way to convert em all to g729?
14:51.42Juggiewhat you need to do is convert the audio files you are using to .g729 files
14:51.50ZaVoidi use soundconverter now onthe mac and it doesn't have g729 option
14:51.51Juggiei believe that is what asterisk will look for
14:51.54Corydon76-digZaVoid: use the Asterisk CLI convert command
14:52.02ZaVoidk let me check that Corydon76-dig
14:52.35ZaVoidhmm not installed
14:52.59ZaVoidthats in 1.4?
14:53.08Juggiei dont see it in trunk either
14:53.35file"file convert"
14:53.45filecomes from the res_convert.so module
14:53.54ZaVoidk one sec
14:54.35ZaVoidyeah thats not in my modules.conf
14:54.35ZaVoidone sec
14:54.47Juggieack how painful, you'll have to do it one at a time
14:55.42ZaVoidhmm guess i sohuld have that in my modules.conf then eh?
14:55.49ZaVoidi got it in /usr/lib/asterisk/modules
14:55.57fileor load it from the CLI.
14:56.09Corydon76-digJuggie: for i in *.wav; do j=${i%%wav} ; asterisk -rx 'file convert $i $j.g729' ; done
14:56.27JuggieCorydon76-dig, touche.
14:56.31Corydon76-digThere's more than one way to skin a cat
14:57.01oejBut there's no room to swing a cat
14:58.07ZaVoidso  file convert *.wav *.g729
14:58.11ZaVoid?
14:58.45Corydon76-digZaVoid: that shell script I gave you should do it
14:58.50ZaVoidok thanks Corydon76-dig
14:58.56ZaVoidpreciate it
14:59.07Corydon76-digmight need to change the single ticks to double quotes
14:59.26ZaVoidyeah
14:59.47JuggieCorydon76-dig, you didnt need to block that revision into 1.6.0 it never got put in when i did mergetrunk6, because i reverted it before i commited to 1.6
15:00.09Corydon76-digJuggie: "svnmerge avail" said I did.
15:00.33Corydon76-digIf svnmerge is unhappy, I fix.
15:00.46Juggieit must of known i only commited part of the revision?
15:00.56Juggiecould it know that?
15:01.06Corydon76-digIt knows numbers
15:01.43Juggiei only intended to change 1 file, but i accidentally changed the make file and i didnt notice because i was running svn diff from inside doc
15:01.49Juggiesaw it when i made the commit so i reverted it.
15:02.10Corydon76-digAnyway, it's fixed now
15:02.54Juggiei thought it already was, but thanks for making 1.6.0 happy.. i just did what someone told me to do did a mergetrunk6 on my 1.6.0 checkout then reverted the makefile, and then commited
15:03.13Juggiei guess it still saw a newer revision of the makefile avail in trunk.
15:03.51fileit doesn't work like that.
15:04.34JuggieCorydon76-dig, there should be 2 revisions to block though? the mistake, and the one to fix?
15:04.59Corydon76-digJuggie: it still doesn't work like that
15:05.18Juggiewhat am i missing?
15:06.48Juggiewhere am i confused?
15:08.10Corydon76-digfor every revision that you commit to trunk, you need to either merge or block in 1.6.0.
15:08.26*** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com)
15:08.26*** mode/#asterisk-dev [+o anthm] by ChanServ
15:08.28Juggieright
15:09.30Corydon76-digDon't think about changes, just think about the actual numbers.  That's it.
15:09.36Juggiebut is it possible to block only part of a revision
15:09.41Corydon76-digNo.
15:09.47Juggiethat was my issue one part of the revision i wanted the other i didnt
15:10.04Corydon76-digA revision is a changeset number, and it's atomic as far as svnmerge is concerned.
15:10.24Corydon76-digAnyway, it's fixed.
15:10.40Juggiething is i bet part of the revision you blocked is commited
15:10.48Juggieto 1.6.0
15:11.03Corydon76-digSo?
15:11.41Corydon76-digThe patch was not needed.  So I blocked it.  That's all.
15:12.17Corydon76-digYou're making this far more complicated than it needs to be
15:14.26Juggienm, i see what you did i thought you blocked the mistake, but you blocked the revert of the mistake, which you are right i forgot to block.
15:22.45*** join/#asterisk-dev ctooley (n=ctooley@doc-72-47-33-80.maryville.mo.cebridge.net)
15:29.49*** join/#asterisk-dev lvl- (n=lvl@101.248.dhcp.lht.hhs.nl)
15:36.24*** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir)
15:37.02putnopvutDoes an ast_str's used field include the null terminator for the string?
15:52.18*** join/#asterisk-dev jmesquita (n=jmesquit@201.7.117.114)
15:53.52*** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla)
15:53.52*** mode/#asterisk-dev [+o russellb] by ChanServ
15:54.25*** join/#asterisk-dev kpfleming (n=kpflemin@216.207.245.1)
15:54.25*** mode/#asterisk-dev [+o kpfleming] by ChanServ
15:55.17putnopvutTo answer my own question, no.
15:56.43*** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.135)
15:56.56*** part/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.135)
15:59.21*** join/#asterisk-dev flujan (n=flujan@internet.nube.com.br)
16:02.18Qwellfixed a bug that was introduced in rev 130
16:02.19Qwell:D
16:02.24Qwell139*
16:10.10putnopvutwow...
16:12.02jmlsif it's that old, perhaps it's a feature ..
16:15.49putnopvutWhen did you do that?
16:15.56Qwellcommitting now
16:16.16tzangerQwell: who are you committing?
16:16.54Corydon76-digA139
16:16.57MuffinMan[139] Committed by markster on 1999-12-16 09:44:30: Version 0.1.1 from FTP
16:19.00jsmithQwell: Which bug was this?  The smoother one, or something else?
16:19.09Qwelljsmith: a different one
16:19.13Qwellthat one was added in 616 :p
16:20.35Qwellpoints to -commits
16:21.40jsmithAh...
16:21.44flujanhi guys...
16:22.31flujanguys, how an I debug the res_snmp module? Having a hard time trying to configure it using a mark spencer tutorial without success. IMHO, the res_snmp is not generating the information. But I need to confirm it.
16:28.00*** join/#asterisk-dev outtolunc (n=me@c-67-174-216-60.hsd1.ca.comcast.net)
16:31.46JerJeri'm looking to change the behavior of parking - instead of hanging up the channel, it would provide a better user experience to play a prompt informing the user there is no more parking spaces
16:32.58*** part/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-159.bredband.comhem.se)
16:33.08JerJeri have found the code that causes the hangup in res_features, but i'm not sure if this is the proper location to tweak
16:34.13jsmith~yawn
16:34.13jbot*YAWN*  I get *YAWN* tired just thinking of large boxes of unknown substances being poured into nooks and crannies and eaten by little monsters that like to kill fluffy bunnies and oh god I'm tired..
16:35.11JerJerapp_parkannounce might be more appropriate, but i'm not sure
16:36.27tzangerI hacked up parkandannounce once for ${PARKEDAT}
16:36.33JerJerbtw, i am doing this on 1.2, but will port it up to trunk / 1.4
16:37.00tzangerit already plays the parking slot #, it would be short work to get it to play "no slots available" I think
16:37.45JerJernot so much - at least from my experience in this area of the code
16:38.21tzangerthe patch I did was for 1.2 and 1.4 and trunk
16:38.35tzangermade it into 1.4 I think, I can dig up what I did for 1.2 but I don't think it applies really
16:38.39JerJerast_masq_park_call doesn't always examine the return result of ast_park_call   (again on 1.2)
16:38.58JerJerer the various calls to ast_park_call doesn't examine the res
16:39.38tzangerI forget if I had to hack that in or not
16:45.50*** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.135)
16:46.59*** part/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.135)
16:50.57*** join/#asterisk-dev RoyK (n=roy@tmi212017138038.mobil.telenor.no)
16:58.37*** join/#asterisk-dev Mw3 (n=mw3@ip59934bd1.rubicom.hu)
16:59.26*** join/#asterisk-dev denon (n=denon@tooth.decay.org)
17:02.04flujanping oej
17:02.22flujanping Corydon76-dig
17:02.27Corydon76-digpong
17:02.37flujanhi Corydon76-dig  :)
17:02.54flujanCorydon76-dig: how do you guys debug a sip or a channel ?
17:03.06JerJerturn on debug
17:03.07Corydon76-dig"sip set debug on"
17:03.17flujannot enough.
17:03.30JerJerngrep -q -W byline port 5060
17:03.53*** join/#asterisk-dev qdk (n=qdk@0x573fe57e.bynqu2.broadband.tele.dk)
17:03.53flujanI use a system that connects do AMI. A SIP peer is always with the ExtensionStatus =1 ... It is always in use to asterisk .
17:04.39Qwellcodefreeze: ping!
17:04.39flujanI alrady logoff an try to log in another machine... Extensionstatus always 1. It happens on random peers now I have one in this situation.
17:05.07flujanthe SIP debug and tcpdump is showing nothing that puts the peer IN USE. So i believe the problem is not on the hardphone.
17:05.41flujanor in the dialplan... Just guessing how to debug it.
17:08.24flujanJerJer: the issue is not with packets. I already run a tcpdump and analyse it.
17:08.33flujanwhen I restart asterisk, the peer back to normal.
17:08.59flujanI have about 300 users on these box. And it happens with some of them at least one per week.
17:13.09codefreezeQwell: pong
17:14.15Qwellcodefreeze: see -bugs :D
17:14.47flujanow. maybe #10165 fixes this issue I am having...
17:48.54*** join/#asterisk-dev jcollie (n=jcollie@161.210.45.126)
17:49.01*** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net)
17:49.01*** mode/#asterisk-dev [+o oej] by ChanServ
17:52.18*** join/#asterisk-dev joetester2 (n=joeteste@216.191.34.13)
17:53.57*** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg)
17:59.43*** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.122.138)
18:03.06bkruseM12317
18:03.07MuffinMan[assigned] [Asterisk-GUI] New/Feature 0012317: Voicemail doesn't recognise a user's voicemail box when callerid is set to an external number reported by dmgeurts  http://bugs.digium.com/view.php?id=12317
18:03.11bkruseQwell: Could you help me out with this one?
18:03.27bkruseQwell: You usually advise me on what would be acceptable, and what is just a hack for a particular user's setup
18:08.20Qwellbkruse: don't know..
18:08.24Qwelldoesn't seem right though
18:08.44Qwellnot all users will want that (I'd bet that a majority *won't* want it)
18:09.06bkruseQwell: So the way of doing voicemail by callerid (the way now) you think is better than this alternative?
18:09.24Qwellhe's removing cruft that only exists in his setup, right?
18:09.34Qwellor is it doing more than that?
18:10.21filewhat about ... setvar?
18:10.23bkrusecorrect
18:10.35bkruseWell, it would take requirements to what the gui writes out, also
18:10.51Qwellbkruse: what does the GUI do now?
18:12.31bkruseQwell: let me doublecheck, but I believe it was an option between VoiceMailMain() and the user entering their extension, or VoiceMailMain(${CALLERID(num)}), which would work for most situations
18:14.27jsmith${If($[${LEN(${CALLERID(num)) > 5]?:${CALLERID(num)})}
18:14.34jsmithThere, how 'bout them apples?
18:14.46jsmithOops, a typo
18:15.06jsmithVoiceMailMain(${IF($[${LEN(${CALLERID(num)) > 5]?:${CALLERID(num)})})
18:15.16jsmithTotally untested, but that should make some people happy
18:15.16Qwelljsmith: that's what it does today?
18:15.27Qwelloh
18:15.30jsmithQwell: No, that's what it *should* do, in my not-so-humble opinion
18:18.23kpflemingi disagree, there shouldn't be any automatic (potentially surprising) behavior like that
18:19.43Qwellwhat about a checkbox (disabled by default)?
18:21.10Qwelleither way - that guys approach is wrong
18:32.21bkrusejsmith: We do that for outbound callerID
18:32.37bkruseif the callerid > 5 digits in length (malcolm) then we use it instead of the trunk callerid
18:48.38*** join/#asterisk-dev asteriskmonkey (n=asterisk@69.77.169.14)
19:07.21asteriskmonkeyanyone work on the realtime files ?
19:08.48jsmithDepends on what you mean by "the realtime files"
19:09.26asteriskmonkeythe source files
19:10.05asteriskmonkeyim readinging the  pbx_realtime.c file, is callerid still not supported in realtime?
19:13.34jsmithasteriskmonkey: I would sure think it's supported.
19:14.09asteriskmonkeythe big fat comment then at the top of that file needs removing :)
19:14.33jsmithWe accept patches
19:16.40asteriskmonkeywoo ill go read the dev pages and ill start working and submitting patches :)
19:16.49asteriskmonkeyi have lots i want to add/mod :)
19:17.02asteriskmonkeyshould i start with 1.6 though and skip 1.4?
19:22.26jsmithYes... any submissions should be based on trunk
19:22.31Corydon76-digjsmith: it's that we don't support callerid filtering in the database
19:22.57jsmithCorydon76-dig: Oh, the exten => 1234/5551212,1,Playback(hello-world) syntax
19:22.59jsmithCorydon76-dig: Gotcha
19:23.00Corydon76-digi.e. exten => 7291035/6155551212,1,DoSomethingDifferent
19:23.37jsmithYeah, the anti-ex-significant-other syntax
19:24.07Corydon76-digRealtime extensions is a really aweful way to get dynamic extensions, anyway
19:24.47jsmithCorydon76-dig: I 100% agree... it's all about res_config_curl!
19:25.49Corydon76-digHonestly, it really should be using something that works more natively in terms of SQL pattern matching
19:25.50jmlscheers
19:26.03jmlsfor config_curl, that is ...
19:26.40Corydon76-digjmls: you saw that I added a companion CGI for that, right?
19:26.57jmlsnope
19:27.04Corydon76-digcontrib/scripts/dbsep.cgi
19:27.16jmlsokies
19:27.23jmlsgoes a'looking
19:28.07jmlsrealtime curl works just great, btw. I put 20,000 calls into a queue with 28 agents and not a single problem
19:28.23Qwellthose agents must've been busy for a while
19:28.40jmlsthey were. Shame they were virtual agents.
19:29.13jmlsi.e "fake" agents. They "talk" for a random period of time, go busy, not ready, lunch break etc
19:29.23jmlsjust to simulate our "real" agents
19:30.05Corydon76-digis having a random lunch break right now
19:30.14jmlssipp fired calls into *, which sent an outbound zap call out of span 1, looped back into span2 and answered by the queue
19:30.22jmlsoh, they were all mixmonitored as well ;)
19:32.41jmlsQwell: did you just do that to flujan ?
19:32.49Qwelldo what?
19:32.55jmlsdisconnected him :)
19:32.56filejmls: no mixmonitor crashes?
19:33.02jmlsfile: nope
19:33.07filethat is nifty
19:33.15jmlsbelieve me, I would have reported them :)
19:33.37filethere is this weird obscure one on Mantis, but I suspect it is being caused by an outside channel driver queueing up large frames
19:33.46jmlsyeah, I actually nearly ran out of disk space when i realised I had nearly 40000 recordings
19:33.54fileyow'sa
19:34.03fileit makes me happy to know it is stable
19:34.03Qwellspeaking of mixmonitor
19:34.06QwellM12047
19:34.07MuffinMan[ready for testing] [Asterisk] Applications/app_mixmonitor 0012047: Mixmonitor crashing asterisk randomly reported by fabianoheringer  http://bugs.digium.com/view.php?id=12047
19:34.08Qwellcommit it!
19:36.09fileQwell: I am... tempted
19:44.57caio1982just completely out of curiosity... is it possible for AEL to compile a bunch of extens using 'n' priorities plus exten labels instead of sequencially numeric ones?
19:45.14QwellAEL doesn't need priorities
19:45.39caio1982i mean when it compile the logic into the dialplan
19:45.54Qwellthere's no such thing as n once it's loaded
19:45.57Qwellafaik
19:45.59caio1982oh
19:46.13QwellI assume it would support labels though...  hmm
19:46.48Qwellokay, yeah
19:46.56Qwellsee configs/extensions.ael.sample, look for context ael-demo
19:47.33Qwellrestart and instructions are both labels there
19:47.54caio1982like 'foobar:', awesome
19:47.57caio1982Qwell: thanks :)
19:53.30*** join/#asterisk-dev jameswf-home (n=james@dsl093-157-131.phx1.dsl.speakeasy.net)
20:03.12*** join/#asterisk-dev hugorebelo (n=hugorebe@200-171-132-124.completo.com.br)
20:33.52*** join/#asterisk-dev iulius (n=iulius@mail1.technologieshq.com)
20:41.25mvanbaakwhat's the thing about being C++ friendly ?
20:42.36mvanbaakA111816
20:42.37MuffinMan[111816] Committed by file on 2008-03-28 16:17:57: Let's be C++ friendly! (pfft not really)
20:42.56mvanbaakIt's a .c file
20:43.06filethe header file.
20:43.43russellbmaking the API itself C++ compatible
20:43.58filerussellb: you aren't supposed to be here, pfft
20:44.11russellbyes, i know
20:44.23russellbbut jpeeler deferred the meeting for a few more minutes!
20:44.56mvanbaakdo we have C++ code in the tree ?
20:45.04russellba couple modules
20:45.13mvanbaakah, then it makes sense
20:45.15mvanbaakthanks
20:51.03*** join/#asterisk-dev philipp64 (n=chatzill@131.107.152.19)
20:52.46*** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com)
20:52.46*** mode/#asterisk-dev [+o anthm] by ChanServ
21:04.55*** part/#asterisk-dev sruffell (n=sruffell@adsl-074-185-078-025.sip.bhm.bellsouth.net)
21:28.38*** join/#asterisk-dev _Vile (n=vile@208.100.152.234)
21:31.57*** part/#asterisk-dev wwalker (n=wwalker@pdpc/supporter/sustaining/wwalker)
22:31.25*** join/#asterisk-dev RoyK (n=roy@ti211110a081-5006.bb.online.no)
23:08.01*** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-159.bredband.comhem.se)
23:08.05*** part/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-159.bredband.comhem.se)
23:17.26*** join/#asterisk-dev RoyK (n=roy@ti211110a081-5006.bb.online.no)
23:34.20jpeelerrussellb: where was that sockaddr_in struct comparison function?
23:37.20jpeelernm, i scanned the tags file

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