IRC log for #asterisk-dev on 20120928

00:23.29*** join/#asterisk-dev sustav (~vpp@76.73.166.16)
00:39.31*** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com)
02:47.24*** join/#asterisk-dev jgowdy (jgowdy@jgowdy.net)
02:50.17*** join/#asterisk-dev mjordan (~mjordan@user-24-214-136-35.knology.net)
02:50.17*** mode/#asterisk-dev [+o mjordan] by ChanServ
02:50.34jgowdyI'm trying to track down a pretty significant issue in which if we're bridged and we start DTMF just before an external AMI executes ChannelRedirect on the two bridge participants (unbridge/hold based on DTMF in our IVR system) the channel redirect happening during DTMF causes one of the legs to permenantly generate the DTMF to the caller via dsp.c, I'm guessing because the state copy doesn't include sharing the later DTMF end
02:51.35jgowdyI'm wondering if anyone has any insight on this issue, I'm trying to figure out a good fix for it, but it's tricky because I don't want to patch 10.7/10.8 when DTMF was significantly changed in 10.9
04:11.10*** join/#asterisk-dev youjelly (~bwahahaha@39.47.83.167)
06:23.04*** join/#asterisk-dev kochmashev (~kochmashe@162.2.17.81.nexcom.ru)
06:23.26kochmashevhello!
06:24.57kochmashevExcuse me, please tell me what must happen (or what should I do) to have this issue (https://issues.asterisk.org/jira/browse/ASTERISK-20465) had been assigned to somebody?
06:36.57*** join/#asterisk-dev bulkorok (~bulkorok@85.183.36.36)
06:46.13*** join/#asterisk-dev wedhorn (~wedhorn@123-243-209-34.static.tpgi.com.au)
07:01.52*** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at)
07:01.54schmidtsgood morning
07:05.09wdoekeskochmashev: create a reviewboard item, that'll increase its visibility (reviewboard.asterisk.org)
08:38.25kochmashevwdoekes: I've been asked there to use "standard username and password". Does that mean using username and password from issues.asterisk.org?
08:38.42wdoekesdo they work?
08:51.31kochmashevno
08:52.02kochmashevI mean that they do not work at reviewboard not at issues
09:02.07wdoekesmm.. I think the issues creds should work for the reviewboard.. but perhaps it's not synchronised immediately (or something went wrong)
09:02.30wdoekespoke Qwell or serafie when they get online
09:54.43jmlsmorning
09:54.57jmlswhere does "manager set debug on" data show ?
09:55.19jmlsI have a failing originate and have no idea what's happening
09:57.52*** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:79a4:a7d5:51bd:61f1)
11:10.41*** join/#asterisk-dev grohne (~grohne@vortex.stw-bonn.de)
11:11.27*** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage)
11:11.27*** mode/#asterisk-dev [+o leifmadsen] by ChanServ
11:24.29grohnehi. can someone tell me what the libpri/trunk branch is for? it is not officially listed, but contains a lot of changes diverging from 1.4
11:26.08grohneso if I want to change libpri in a way that will break API (not only ABI), would I base that work on 1.4 or trunk?
11:29.39*** join/#asterisk-dev italorossi (~textual@201.76.151.245)
11:40.43grohnein related news I updated the existing libpri patch for PRI-106 to address all outstanding complaints I saw. (it still breaks and has to break ABI)
12:07.02*** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236)
13:00.11*** join/#asterisk-dev serafie (~erin@nat/digium/x-usrrwyhqybopfgat)
13:16.01*** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger)
13:16.01*** mode/#asterisk-dev [+o pabelanger] by ChanServ
13:18.39*** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-qwqtlygebpwawtbz)
13:18.39*** mode/#asterisk-dev [+o mjordan] by ChanServ
13:19.59*** join/#asterisk-dev dwayne (~dwayne@c-76-29-230-45.hsd1.al.comcast.net)
13:34.20filepushes tzanger over
13:53.15snuff-homeso that's what ppl do these days.. cow tipping became too passe.. tzanger tipping all the rage? ;)
13:54.30tzangerlol
13:55.51*** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson)
13:55.51*** mode/#asterisk-dev [+o putnopvut] by ChanServ
14:01.01*** join/#asterisk-dev serafie (~erin@nat/digium/x-ujifrlkkjgbrjtzy)
14:55.03*** join/#asterisk-dev marv (~Adium@173-14-206-193-huntsville.hfc.comcastbusiness.net)
15:07.00*** join/#asterisk-dev malcolmd_ (~malcolmd@pdpc/sponsor/digium/malcolmd)
15:07.00*** mode/#asterisk-dev [+o malcolmd_] by ChanServ
15:10.29*** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com)
15:10.34*** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com)
15:17.27*** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell)
15:17.28*** mode/#asterisk-dev [+o sruffell] by ChanServ
15:35.49tzangerhm, interesting
15:35.57tzangerwcfxo looks at audio samples to determine ringiing
15:36.09tzangeris that because the si3050 ring detection is so goofy?
15:37.50leifmadsenotherwiseguy: ping
15:38.11leifmadsenotherwiseguy: per #asterisk:   <Greenlight> Hiya all. Just noticed some errors appearing - "WARNING[3696]: app_queue.c:5319 dump_queue_members: Could not create persistent member string, out of space". Getting this about 20 times a minute. My thinking is that its an issue related to the Asterisk sqllite database, is this correct?
15:38.49russellbout of space?
15:38.56leifmadsenya... seems weird
15:38.59russellbweird.
15:39.01leifmadsenhe said there are plenty of resources on the server
15:39.11russellbthat was my next question
15:39.14Qwellhe didn't specify what kind of resources, other than disk
15:39.33QwellI'm sure it's a stringfield or something it's allocing
15:39.55russellbi wonder if app_queue shoves a huge pile of data in a single entry and is hitting a max
15:40.13leifmadsenperhaps
15:40.18Qwellheh
15:40.22Qwellthat's exactly what it's doing
15:40.25leifmadsenseems like a since line max length issue?
15:40.27Qwellthat's a seriously fuckey snprintf
15:40.29seanbright8192
15:40.45Qwell<PROTECTED>
15:40.51russellbexceeding PM_MAX_LEN
15:40.55leifmadsenaye
15:41.00QwellThat's terrible.
15:41.03seanbrightpipe delimited list of semi delimted lists
15:41.07seanbrightbig deal
15:41.07seanbrightheh
15:41.14sruffellheh
15:41.30russellbeasy to fix with a malloc'd ast_str conversion
15:41.34russellbif someone cared enough
15:41.41seanbrightdelegates
15:41.56russellbrequires a sponsor
15:42.02seanbrightzing
15:42.02mjordanI was waiting for that
15:42.09Qwell129684?
15:42.15filerussellb, I offer you... beer
15:42.25russellbfile: how much beer
15:42.30leifmadsenheh
15:42.31filerussellb, half a cup.
15:42.34Qwelloh, nope, earlier than that
15:42.39russellbmy hourly rate in beer would be a lot of beer
15:42.44mjordanfile: are we talking slightly used beer, or fresh beer?
15:42.49filedon't I get a discount?!?
15:42.56russellbfile: no.
15:43.04filelet me guess, I have to pay a premium
15:43.12*** join/#asterisk-dev Greenlight (~email@client-86-31-251-6.oxfd.adsl.virginmedia.com)
15:43.12russellbno!
15:43.17leifmadsenhow many cases per hour?
15:43.27leifmadsen"What is your rate?"
15:43.27russellbat least ... a lot
15:43.28Greenlight20+ minute
15:43.31leifmadsen"I'm 12 cases per hour"
15:43.53seanbrightast_db_get throws a monkey in the wrench
15:43.55leifmadsenit's like saying your weight in stones
15:43.56seanbrightit takes a length
15:44.20Qwellr5130
15:44.30Qwellthat's been there since ever.
15:44.30seanbrightR5130
15:44.34GreenlightI beleive I'm hitting a length limit in app_queue.c: dump_queue_members. I've queues with over 100 members. Would that make sense?
15:44.37Qwellit's actually before that too
15:44.39seanbrightwheres my awesome bot?
15:44.43QwellGreenlight: yes, we know the problem
15:44.44russellbGreenlight: yes, you are.
15:44.50russellbGreenlight: it's fixable, but will require a code change
15:45.02russellbGreenlight: and now we're debating how much beer it would take as payment to fix it.
15:45.09Greenlightlol
15:45.15russellbvery productive, i know
15:45.22QwellI'd do it for 6
15:45.24GreenlightSO... off to the offlicence I go ?
15:45.52QwellGreenlight: Reporting it at https://issues.asterisk.org/ would be a good start.
15:45.56GreenlightJust to check, the only negative effect is that i lose persistant queue memberships between restarts?
15:46.03russellbhm, i guess you could just edit PM_MAX_LEN and recompile as a short term hack
15:46.07QwellGreenlight: lose, and get screwy ones
15:46.16GreenlightOk, screwy ones sounds bad
15:46.17russellbdouble the value
15:46.40russellbGreenlight: ^^^
15:47.00russellb#define PM_MAX_LEN 8192
15:47.01russellbdouble that, recompile, reinstall
15:47.35GreenlightGotcha, that'll give me say up to 250 or so then?
15:47.41GreenlightIf I'm capping at around 120 now
15:47.43russellbmaybe?  :-)
15:47.47GreenlightHehe
15:47.53GreenlightI like your optimism
15:48.06russellbwell, it's a short sighted change, really
15:48.10russellbit just increases the current limit you're hitting
15:48.15russellbyou may hit a different one after that little change
15:48.39russellbbut it won't hurt^D^D^D^D^D^D^D^Dshouldn't hurt
15:48.46GreenlightIt's the while loop inside dump_queue_members, right?
15:49.09seanbrightit's a fixed sized buffer
15:49.14seanbrightthat's the "problem"
15:49.26russellbwhat seanbright said ... it's a loop filling in some space with a fixed size
15:49.30russellbit fills up and then you get the error message
15:49.31Qwellit would be rather simple to actually fix
15:49.37seanbrightQwell: not so sure
15:49.48GreenlightCouldnt we flush regularly though?
15:49.50Qwelljust ast_str_append it
15:49.59seanbrightwell yeah, _put would be easy
15:50.04russellbseanbright knows what's up ... more to it
15:50.06seanbrightwe'd need a new _get
15:50.16russellbGreenlight: nope
15:50.29russellbGreenlight: puts all this data in there and then puts it in astdb as one giant entry
15:50.40russellbkinda silly, but oh well
15:50.41russellbthat's astdb for you
15:50.46seanbrightvery relational
15:50.53russellbheh
15:51.04russellbit's more of a very basic key/value store
15:51.12GreenlightAhh so you can't dump more data on top of existsing
15:51.13seanbrightright
15:51.37seanbrightwhat version are you using?
15:51.39seanbrightof asterisk
15:51.54Greenlight< 10.6.1
15:52.07GreenlightAhh, I see: ast_db_put(pm_family, pm_queue->name, value) - overrites it
15:52.08seanbright*CLI> core show version
15:52.12russellbclearly we should back it with Riak
15:52.24Greenlightasterisk*CLI> core show version
15:52.24GreenlightAsterisk 10.6.1 built by root @ asterisk.sbm.local on a x86_64 running Linux on 2012-07-29 17:52:24 UTC
15:52.30seanbrightgot it
15:52.44seanbrightgoing to take a crack at it unless someone else has started?
15:53.00GreenlightIs there a limit at the db side, of the size of "value" ?
15:53.16seanbrightGreenlight: probably a bazillion GB
15:53.22Greenlight:)
15:53.38GreenlightWell - crack away - I'll happily recompile and test
15:53.39*** join/#asterisk-dev caio1982 (~caio1982@189.125.242.3)
15:54.21seanbright2147483647 bytes
15:54.25seanbrightaccording to the sqlite docs
15:54.28seanbrighthttp://sqlite.org/limits.html#max_length
15:54.50GreenlightIf I have that many queue members I suspect I'll be facing other issues
15:55.04russellbyes.
15:55.35seanbrightugh... so in 1.8 we still used bdb
15:55.56GreenlightSorry for noob question, I mainly work in C#. Why do we need to have a fixed length array, cant we use something more dynamic for it?
15:56.04seanbrightGreenlight: that's the plan
15:56.05russellbGreenlight: that's the fix
15:56.08GreenlightOh :)
15:56.33seanbrightso since 1.8 goes security only on 10/21/2014...
15:56.39seanbrightthat is when i will have a patch for you
15:56.59Greenlightbdb has other limits?
15:57.12seanbrighti can only assume
15:57.12GreenlightAs in it's not possible to patch both versions?
15:57.21seanbrightchecking.
15:57.23russellb1.8 is the old and busted anyway
15:57.47russellbseanbright: good luck checking ... we bundled some random version and probably hacked on it too
15:57.47GreenlightI guess if bdb had a limit, that would expalin the fixed length array used
15:59.34russellbcoding the feature quickly and not thinking about large scale usage is more likely to explain it :)
16:00.04Qwellit was written before rev 4000
16:00.05Qwellheh
16:00.09russellbright
16:00.10QwellI stopped the blame when I got that far
16:00.10GreenlightKinda like the whole y2k thing... "pfft we'll never need more than 4096 bytes"
16:00.11seanbrightthe dark ages
16:00.35seanbrightGreenlight: the idea of 100 queue members would have been outrageous a few years ago
16:00.39russellbmuch of the early early code is like that ... make it work, not necessarily optimizing
16:01.08GreenlightYea Asterisk has got a lot more slick, and server power has increased too
16:01.53GreenlightI reckon I'll be pushing 1000 channels soon, with recording and all
16:02.00seanbrightwell... data_len is a size_t
16:02.52QwellHA
16:02.59seanbrightGreenlight: for the time being, just double PM_MAX_LEN
16:03.12Qwellrussellb: see PM :)
16:03.21seanbright#define PM_MAX_LEN 16384
16:03.35seanbrightmake ; make install ; /etc/asterisk/init.d restart
16:03.50seanbrightthat should get you over the hump today
16:03.51Qwell2048 should be plenty.
16:04.17GreenlightSure, will do. Well thanks for taking the time to help me out, the hard work you all put in is much appricaited, and it's a great product.
16:05.13seanbrightwe should just use pascal strings everywhere
16:05.39seanbright<insert joke about re-writing in bash>
16:06.01sruffelldoes Asterisk have something like asprintf?
16:06.11GreenlightHmm.. my PM_MAX_LEN is already 8192, how can 2048 be plenty?
16:06.16sruffell(or as I like to use kasprintf :) )
16:06.26QwellGreenlight: t'was a joke. :)
16:06.32GreenlightOh
16:06.33Greenlight:)
16:06.46Qwellsorry, you had to have seen the link to get the joke
16:07.05*** join/#asterisk-dev caio1982 (~caio1982@189.125.242.3)
16:08.26GreenlightOk, recompoling now. Thanks again. Take it easy
16:14.02seanbrightsruffell: it does... ast_asprintf i think
16:14.40sruffellseanbright:  ahh...there it is cool. thanks.
16:22.41*** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm)
16:28.17jgowdyI'm trying to track down a pretty significant issue in which if we're bridged and we start DTMF just before an external AMI executes ChannelRedirect on the two bridge participants (unbridge/hold based on DTMF in our IVR system) the channel redirect happening during DTMF causes one of the legs to permenantly generate the DTMF to the caller via dsp.c, I'm guessing because the state copy doesn't include sharing the later DTMF end
16:38.42seanbrightanyone here a PRI expert?
16:39.43jgowdyD channel and B channel, 1.544Mhz
16:39.44jgowdyhehe
16:39.52jgowdy<PROTECTED>
16:41.20pabelangerrichards the man, but never hangs out in irc
16:43.52Corydon76-homeYeah, you basically have to twist his arm to get him to show here.
16:44.12sruffellHas he ever showed here?
16:44.29sruffellseanbright: might as well just ask your question...someone might know even if they aren't an expert.
16:44.43Corydon76-homeYes, I've seen him once or twice
16:44.55sruffellwhat's his handle?
16:45.00Corydon76-homermudgett
16:45.05sruffelloriginal. :)
16:45.49seanbrighta transfer partner says "If your Service Provider for your PRI is AT&T (I believe it might be), then your Trunk Group option need to be set for PSID and not just ANI."
16:45.56Corydon76-homeHey, I remember when markster used to hang out in #asterisk, too
16:46.00seanbrighti don't know what PSID is
16:47.32pabelangerSPID? Service Profile Identifier?
16:52.45seanbrightyeah i dunno
16:56.56sruffellhuh....yeah...don't know.  Googling only turned up two references for me. https://supportforums.cisco.com/message/3042528#3042528 and  http://www.bellsouth.com/residential/glossaryP.html
16:57.10sruffellbut no idea what it actually means.
17:00.41seanbrightyeah
17:12.18*** join/#asterisk-dev Tim_Toady (~fuzzy@130.43.35.150.dsl.dyn.forthnet.gr)
17:19.58elgueroseanbright: I found some doc talking about LNP and ATT... mentions SPID meaning Service Provider ID... definition: A code-set developed by the NPAC administrator that
17:20.01elguero<PROTECTED>
17:20.04elguero<PROTECTED>
17:21.01seanbrightelguero: nice.  thanks i'll take a look.
17:22.22elgueroseanbright: http://www.scribd.com/doc/9436919/CCNA-640801-5-Minutes-Study-Guides ... talks about it being "a numerical string of 14 characters assigned by TELCO to EACH B CHANNEL on an ISDN link"
17:22.28elguerohope that helps
17:24.05sruffellSo are you thinking that they wrote PSID when they meant to write SPID?  That it's just a typo?
17:24.39seanbrightthey mentioned PSID a couple times
17:24.48seanbrighti know approximately squat about ISDN
17:25.15elguerosruffell: ah... saw pabelanger's comment and that was stuck in my head...
17:25.15fileseanbright, drink?
17:25.31seanbrighti think PSID means "prefer SID"
17:25.34seanbrighti think
17:25.40seanbrightSID being station ID
17:25.44sruffellMy guess was "Physical System Identifier"
17:26.04seanbrightlooked at the libpri source a bit and saw
17:26.16seanbrightPRI_NSF_SID_PREFERRED and PRI_NSF_ANI_PREFERRED
17:26.30sruffellhmm....
17:26.36sruffell...that's a good clue.
17:26.57seanbrightbut we already have nsf set to SDN and we needed to set that to make the thing work in the first place
17:27.04seanbrighti'm hesitant to change it
17:27.13sruffellCan't you call ATT?
17:27.16seanbrighti guess
17:27.18seanbrightheh
17:27.28sruffellalthough...you have to let us know what they say. :)
17:27.30filequiet little voices... creep into my head...
17:28.09seanbrighti think i'm going to just go a different route
17:28.34seanbrightso we may never know
17:28.37elguerofile: its the headsets... its coming from the headsets :)
17:29.14fileelguero, ^_^
17:37.57*** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd)
17:37.57*** mode/#asterisk-dev [+o malcolmd] by ChanServ
17:55.22*** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd)
17:55.22*** mode/#asterisk-dev [+o malcolmd] by ChanServ
18:30.49*** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-43-209.user.veloxzone.com.br)
18:38.30*** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com)
19:11.32jgowdyanyone know the "standard" value for interdigit delay (T302)?
19:34.41pabelangersruffell: I like your style!  Keep those patches for git support coming :D
19:35.01leifmadsen+1
19:37.11sruffellheh
19:50.22*** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd)
19:50.23*** mode/#asterisk-dev [+o malcolmd] by ChanServ
20:20.00JunK-Yjgowdy: 15s i think
20:28.59jgowdythanks
21:56.59*** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd)
21:56.59*** mode/#asterisk-dev [+o malcolmd] by ChanServ
23:35.17*** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com)

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