| 01:23.07 | *** join/#asterisk-dev grimsy (n=chatzill@203-206-220-214.perm.iinet.net.au) |
| 01:34.58 | *** join/#asterisk-dev file (n=file@asterisk/developer-and-muffin-lover/file) |
| 01:34.58 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 01:47.45 | *** join/#asterisk-dev file (n=file@asterisk/developer-and-muffin-lover/file) |
| 01:47.45 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 02:42.46 | *** join/#asterisk-dev Qwell (i=north@pdpc/sponsor/digium/Qwell) |
| 02:42.46 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 02:47.33 | *** join/#asterisk-dev file (n=file@asterisk/developer-and-muffin-lover/file) |
| 02:47.33 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 02:47.38 | *** join/#asterisk-dev ctooley (n=ctooley@doc-72-47-33-80.maryville.mo.cebridge.net) |
| 03:01.43 | *** join/#asterisk-dev Laureano (n=chatzill@92-237-114-200.fibertel.com.ar) |
| 05:03.56 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 05:04.24 | *** join/#asterisk-dev grimsy (n=chatzill@203-206-220-214.perm.iinet.net.au) |
| 05:04.59 | *** part/#asterisk-dev grimsy (n=chatzill@203-206-220-214.perm.iinet.net.au) |
| 05:10.48 | tzanger | fun, I think I have to write a channel driver |
| 05:11.00 | tzanger | kind of like zaptel, but without all the crazy signaling |
| 05:12.31 | Corydon76-dig | Oh, so like a protocol that no application in the real world? |
| 05:12.48 | tzanger | haha well it's for specialized hardware |
| 05:13.22 | tzanger | I've come to the conclusion that TDMoE was never ever meant to handle 576 channels reliably |
| 05:13.25 | Corydon76-dig | So, you think you're going to hide the wackiness in the firmware... |
| 05:13.37 | tzanger | oh, no no no |
| 05:13.55 | tzanger | the driver is a kernel module, it was originally a zaptel-compatible driver |
| 05:14.00 | tzanger | but zaptel just *sucks* on blackfin |
| 05:14.09 | tzanger | so I ripped all of it out and made the driver emit TDMoE frames directly |
| 05:14.11 | tzanger | and that worked |
| 05:14.14 | tzanger | and worked very well |
| 05:14.41 | tzanger | but now we're seeing on the PC side that zaptel just isn't able to handle high channel counts even on what I would consider decent hardware |
| 05:14.46 | Corydon76-dig | Hmmm, 576 channels should be fine on 100BT switched |
| 05:14.53 | tzanger | the network's not the problem |
| 05:14.56 | tzanger | it's zaptel |
| 05:15.30 | Corydon76-dig | Ah |
| 05:15.30 | tzanger | even with only one or two channels offhook, vast wodges of time are spent fucking around checking signaling it seems |
| 05:15.30 | Corydon76-dig | Too many channels? |
| 05:15.30 | tzanger | which was the problem on the blackfin |
| 05:15.30 | tzanger | 40ish channels caused it pain |
| 05:15.39 | tzanger | after ripping out the zaptel stuff, it worked great at 288 channels |
| 05:16.40 | tzanger | so now, instead of trying to shuttle all those channels over |
| 05:16.55 | tzanger | I'm just going to write a simple (I hope!) zaptel-ish channel driver for blackfin asterisk |
| 05:17.03 | tzanger | and IAX2 trunk the active channels |
| 05:17.26 | tzanger | the blackfin has enough balls to do the DTMF and minor echo can needed |
| 05:17.40 | tzanger | see if I can't get oslec to like my zaptel-ish driver |
| 06:15.19 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 06:15.19 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:23.39 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-159.bredband.comhem.se) |
| 10:28.51 | *** join/#asterisk-dev RoyK (n=roy@80.239.107.70) |
| 10:29.59 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 10:29.59 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 10:33.20 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 10:33.20 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:03.49 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:19.07 | *** join/#asterisk-dev flujan (n=flujan@200-160-115-020.static.spo.ctbc.com.br) |
| 11:19.37 | flujan | hi guys... I updated my asterisk to version 1.4.14 and now I am having serious problems with the machine's load. |
| 11:19.58 | flujan | Some action is triggering a event that makes asterisk to use 500% of CPU. I am using top to see it. |
| 11:20.30 | flujan | how can I debug it? |
| 11:27.08 | flujan | I already have valgrind installed... |
| 11:27.56 | oej | Ouch |
| 11:28.03 | oej | Valgrind is a good bet |
| 11:28.37 | flujan | oej, I am switching back to version 89260 from the svn... which fix the memory problems I was having... |
| 11:28.57 | flujan | oej, do you want ssh access to the machine? |
| 11:32.53 | *** join/#asterisk-dev _ys (i=ys@91.151.196.254) |
| 11:33.59 | oej | No time right now, sorry. |
| 11:34.28 | flujan | oej: ok thanks anyway... I will switch back and see. |
| 11:38.46 | flujan | This is strange since asterisk works fine and from nothing the load starts... |
| 11:38.47 | flujan | :( |
| 11:57.49 | *** join/#asterisk-dev rati (n=rati@124.125.255.24) |
| 12:15.56 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) |
| 12:19.23 | *** join/#asterisk-dev Laureano (n=Laureano@host172038.metrored.net.ar) |
| 12:19.33 | Laureano | Hi guys |
| 12:38.52 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 12:38.53 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:40.55 | *** join/#asterisk-dev flujan (n=flujan@200-160-115-020.static.spo.ctbc.com.br) |
| 12:40.55 | *** join/#asterisk-dev De_Mon (i=de_mon@fl-71-52-101-157.dhcp.embarqhsd.net) |
| 12:40.55 | *** join/#asterisk-dev lvl- (n=lvl@101.248.dhcp.lht.hhs.nl) |
| 12:40.55 | *** join/#asterisk-dev phearless (n=phear@host217-34-75-65.in-addr.btopenworld.com) |
| 12:40.55 | *** join/#asterisk-dev JackEStorm (n=no@ip68-225-77-136.no.no.cox.net) |
| 12:40.58 | *** join/#asterisk-dev Corydon76-dig (i=blue@pdpc/supporter/bronze/Corydon76-home) |
| 12:40.58 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177583123.dsl.bell.ca) |
| 12:40.58 | *** mode/#asterisk-dev [+o Corydon76-dig] by irc.freenode.net |
| 12:41.05 | *** join/#asterisk-dev Qwell (i=north@pdpc/sponsor/digium/Qwell) |
| 12:41.05 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) [NETSPLIT VICTIM] |
| 12:41.05 | *** join/#asterisk-dev rati (n=rati@124.125.255.24) |
| 12:41.05 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:41.05 | *** join/#asterisk-dev mashroom_ (n=tasty@89-138-132-186.bb.netvision.net.il) [NETSPLIT VICTIM] |
| 12:41.05 | *** join/#asterisk-dev qdk (n=qdk@0x573fe57e.bynqu2.broadband.tele.dk) |
| 12:41.05 | *** join/#asterisk-dev davevg-btwtech (n=davevg-b@nj-67-76-177-147.sta.embarqhsd.net) |
| 12:41.06 | *** join/#asterisk-dev Deeewayne (i=dwayne@nat/digium/x-574b9a75e6d08d56) |
| 12:41.06 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip68-103-153-140.ks.ok.cox.net) |
| 12:41.06 | *** join/#asterisk-dev bmd (n=bmd@72.54.252.34) |
| 12:41.06 | *** join/#asterisk-dev tzanger (n=tzanger@gromit.mixdown.ca) |
| 12:41.06 | *** join/#asterisk-dev denon (n=denon@tooth.decay.org) |
| 12:41.06 | *** join/#asterisk-dev d3wayne (n=deeewayn@76.29.245.9) |
| 12:41.06 | *** join/#asterisk-dev Corydon76-vcch (n=tilghman@pdpc/supporter/bronze/Corydon76-home) |
| 12:41.06 | *** mode/#asterisk-dev [+oooo Qwell Deeewayne d3wayne Corydon76-vcch] by irc.freenode.net |
| 12:41.57 | *** join/#asterisk-dev MuffinMan (n=muffins@neutrino.joshua-colp.com) |
| 12:51.21 | *** join/#asterisk-dev agx (n=AGX@88.34.216.63) |
| 12:52.37 | *** join/#asterisk-dev zerohalo (n=zeroHalo@pool-71-162-97-18.bstnma.east.verizon.net) |
| 12:55.50 | *** join/#asterisk-dev ivanfm (n=ivanfm@c906b486.virtua.com.br) |
| 13:02.11 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.134.26) |
| 13:11.15 | *** join/#asterisk-dev _charly_ (i=kroseneg@sunrise.schmidham.net) |
| 13:11.53 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@62.90.10.53) |
| 13:11.53 | *** join/#asterisk-dev Laureano (n=Laureano@host172038.metrored.net.ar) [NETSPLIT VICTIM] |
| 13:11.53 | *** join/#asterisk-dev ctooley (n=ctooley@doc-72-47-33-80.maryville.mo.cebridge.net) |
| 13:11.53 | *** join/#asterisk-dev jmls (n=jmls@62.49.235.130) |
| 13:11.53 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 13:11.54 | *** join/#asterisk-dev angler (i=angler@pdpc/sponsor/digium/angler) |
| 13:11.54 | *** join/#asterisk-dev Juggie (n=Juggie@CPE001601df17fb-CM001a6682d7b6.cpe.net.cable.rogers.com) |
| 13:11.54 | *** join/#asterisk-dev codefreeze (n=steve_mu@216.166.159.235) |
| 13:11.54 | *** join/#asterisk-dev mvanbaak (n=mafkees@vanbaak.xs4all.nl) |
| 13:11.54 | *** join/#asterisk-dev VoicePulse (n=contact@unaffiliated/voicepulse) |
| 13:11.54 | *** join/#asterisk-dev citats (n=james@mrplow.gnuinternet.com) |
| 13:11.54 | *** join/#asterisk-dev JT (n=j@unaffiliated/jt) |
| 13:11.55 | *** join/#asterisk-dev Corydon76-home (i=six@pdpc/supporter/bronze/Corydon76-home) |
| 13:11.55 | *** mode/#asterisk-dev [+ooo tzafrir_laptop codefreeze Corydon76-home] by irc.freenode.net |
| 13:13.00 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 13:13.00 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 13:43.28 | *** join/#asterisk-dev ctooley (n=ctooley@doc-72-47-33-80.maryville.mo.cebridge.net) |
| 13:45.27 | *** join/#asterisk-dev _ys (i=yuri@91.151.196.254) |
| 13:48.16 | *** join/#asterisk-dev Lasse123 (n=Lasse@int-gw.algitech.com) |
| 14:01.34 | *** join/#asterisk-dev _ys (i=yuri@91.151.196.254) |
| 14:45.19 | *** join/#asterisk-dev putnopvut (i=putnopvu@nat/digium/x-2450276ed395e944) |
| 14:45.19 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:47.06 | *** join/#asterisk-dev jsbach (n=jsbach@fokus6148.fokus.fraunhofer.de) |
| 14:48.07 | jsbach | hei, is there any way to modify/ build up my own sdp in asterisk?.. |
| 14:50.01 | file | no, not really |
| 14:52.40 | jsbach | file, is it a clear no. ? |
| 14:53.06 | file | sure |
| 14:53.29 | jsbach | ok, can i tell the client to open up a port to a -certain- port for rtp at least? |
| 14:54.11 | file | what client? the SIP client? it sends RTP to the given port in the SDP. |
| 14:54.38 | JerJer | smells like someone has a firewall / nat problem |
| 14:55.07 | file | but you have the source code so technically your first question could be accomplished |
| 14:55.21 | jsbach | yes, a sip client. i want to send a specific port info from asterisk in OK. so that client accepts my port , not his. |
| 14:55.38 | jsbach | file, yes, i am looking now to chan_sip.c ;) |
| 14:55.58 | file | there is directrtpsetup which aims to try to do that, but depending on circumstances/codecs/NAT/etc it may not work... |
| 14:56.50 | JerJer | plus, why hack? |
| 14:57.39 | jsbach | JerJer, not that i intend -now- to hack the code, but i think it would be a powerful feature to form your own sdp's. |
| 14:58.25 | JerJer | like direct where the audio goes? |
| 14:58.31 | JerJer | and video for that matter |
| 14:59.25 | jsbach | yes |
| 14:59.58 | JerJer | might be useful - although for something like that I would want to use OpenSER |
| 15:03.42 | JerJer | hmm - ya know, I wonder if it would make any sense to take the RTP and codec components of Asterisk and create an application that just proxied the RTP - didn't deal with any call setup or bridging - just processing RTP and transcoding |
| 15:03.46 | JerJer | hmmmmmm |
| 15:05.15 | jsbach | you mean as a media processor? sure, it'd make sense |
| 15:05.22 | JerJer | yeah |
| 15:05.50 | JerJer | i hate to even attempt to make a comparison, but it could be like the openser mediaproxy |
| 15:06.22 | *** join/#asterisk-dev blitzrage (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:06.22 | *** mode/#asterisk-dev [+o blitzrage] by ChanServ |
| 15:06.24 | JerJer | not sure if it would really make things any better though - we have some pretty high levels of scale with openser+asterisk |
| 15:07.08 | jsbach | the point is, you should also have a beautiful controller, which is also aware of load-balancing,dependability etc.. |
| 15:08.15 | file | hrm? |
| 15:08.35 | JerJer | that's what got me thinkin about taking the RTP and codec components of asterisk and making them 'external' |
| 15:09.06 | jsbach | controller, take it as a proxy but extended |
| 15:11.32 | jsbach | ok, another question, can i configure the order of codecs for a sip session -somewhere in the confs-? |
| 15:11.35 | blitzrage | morning all |
| 15:13.42 | De_Mon | jsbach sure, the config for sip is sip.conf |
| 15:13.51 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 15:13.51 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 15:15.52 | JerJer | i believe the order of the allow statements determines the order of the codecs in the sdp |
| 15:18.11 | jsbach | is it? have to test it.. see if i can INVITE a user from the asterisk console... ;) |
| 15:18.47 | blitzrage | jsbach: I'm pretty sure JerJer is right since the codec order matters |
| 15:27.11 | *** join/#asterisk-dev jameswf (n=james@dsl093-157-131.phx1.dsl.speakeasy.net) |
| 15:36.34 | anonymouz666 | JerJer: it is that way. the order of the allow determine the order of the codecs in the sdp. for sure. |
| 15:36.34 | *** join/#asterisk-dev moy (i=moyhu@nat/ibm/x-b0f0802a18980c74) |
| 15:37.09 | anonymouz666 | JerJer: and mediaproxy sucks :) |
| 15:37.14 | anonymouz666 | hard. |
| 15:37.37 | JerJer | big floppy donkey dick |
| 15:38.03 | putnopvut | no, he said "hard" not "floppy" |
| 15:38.19 | anonymouz666 | blitzrage: 12 is the best chapter of TFOT2. :) |
| 15:38.20 | JerJer | oh |
| 15:38.33 | JerJer | i spoze i should get me a copy of TFOT2 |
| 15:39.00 | blitzrage | anonymouz666: is that the relational database chapter? |
| 15:39.27 | anonymouz666 | yes. |
| 15:39.48 | anonymouz666 | func_odbc |
| 15:41.50 | De_Mon | ~TFOT |
| 15:41.50 | jbot | Asterisk: The Future of Telephony 2nd Edition (ISBN 0-596-51048-9) --- Order yours at http://www.oreilly.com/catalog/9780596510480/ --- Downloadable PDF http://downloads.oreilly.com/books/9780596510480.pdf |
| 15:42.35 | De_Mon | where do procedes from the book go? |
| 15:43.07 | file | some of it goes to feed the authors |
| 15:45.11 | blitzrage | De_Mon: mostly O'Reilly, a small percentage goes to the authors, that then gets divided by 3 (3 authors) |
| 15:50.46 | De_Mon | oo |
| 15:51.19 | *** join/#asterisk-dev kpfleming (i=kpflemin@nat/digium/x-581d095c30e0be35) |
| 15:51.19 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:52.07 | file | kpfleming: welcome to our insanity! |
| 15:52.19 | kpfleming | is this the jungle? |
| 15:52.24 | blitzrage | welcome to the jungle |
| 15:52.39 | file | no, it's The Social |
| 15:52.47 | kpfleming | that must be the somewhat-less-censored Canadian version |
| 15:52.52 | blitzrage | :) |
| 15:53.00 | blitzrage | something like that |
| 15:53.32 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 15:54.12 | *** join/#asterisk-dev RoyK (n=roy@62.92.9.241) |
| 15:54.31 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 15:54.56 | *** join/#asterisk-dev jmesquita (n=jmesquit@201.7.117.114) |
| 15:55.08 | kpfleming | Family Guy rocks, btw |
| 15:55.13 | blitzrage | indeed it does |
| 15:55.29 | De_Mon | CALLERID(number) and CALLERID(num) do the same thing, but only 'num' is in the app description... Are they both here to stay? |
| 15:56.13 | De_Mon | both are used throughout the examples |
| 15:57.14 | kpfleming | the code currently checks only that the string begins with 'num'... I suspect CALLERID(numblitzragerocks) would work too |
| 15:58.11 | blitzrage | kpfleming: I thought I read that it checked for 'num' and 'number' ? |
| 15:58.25 | kpfleming | that would be rather silly |
| 15:58.37 | blitzrage | if you're right kpfleming, then I might start using numblitzragerocks in my CALLERID()'s :) |
| 15:59.50 | kpfleming | i am wrong |
| 15:59.54 | file | checking for num and number is silly and needless! checking to make sure the string blitzrage is not used in it though... that is NOT silly |
| 16:00.10 | file | kpfleming: quickly change it |
| 16:00.34 | kpfleming | the documentation does not say that 'number' works, we should find out when that was added and either change the docs or elminate it |
| 16:00.56 | blitzrage | kpfleming: I tend to use 'number', so I'll make a documentation patch :) |
| 16:01.24 | De_Mon | <PROTECTED> |
| 16:01.24 | De_Mon | <PROTECTED> |
| 16:01.24 | De_Mon | <PROTECTED> |
| 16:03.48 | De_Mon | stragely enough it checks for both, AND only cares about the first 3 characters :) |
| 16:04.18 | kpfleming | right. so 'numblitzragerocks' and 'numberfiledoesnot' would both work :-) |
| 16:04.39 | file | lame. |
| 16:04.41 | *** join/#asterisk-dev Corydon76-lap (i=Corydon7@pdpc/supporter/bronze/Corydon76-home) |
| 16:04.41 | *** mode/#asterisk-dev [+o Corydon76-lap] by ChanServ |
| 16:05.30 | De_Mon | I would prefer the length was checked too, but somehow that seems silly at this point |
| 16:10.14 | *** join/#asterisk-dev yannj_fr (n=yannj_fr@APuteaux-152-1-30-204.w82-120.abo.wanadoo.fr) |
| 16:11.06 | De_Mon | <PROTECTED> |
| 16:11.09 | De_Mon | <PROTECTED> |
| 16:11.39 | De_Mon | blame isn't as helpful as I always imagined it to be... |
| 16:14.14 | De_Mon | figures, the desc use to include num and number as both valid, so I guess the desc got updated to match the logic, but the logic never got unredundantified |
| 16:17.26 | *** join/#asterisk-dev russellb (i=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 16:17.27 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 16:18.51 | blitzrage | ok, 11378 has the doc changes to the CALLERID() description |
| 16:21.45 | *** join/#asterisk-dev ManxPower (n=manxpowe@225.sub-70-220-92.myvzw.com) |
| 16:25.37 | De_Mon | wana run this against trunk to update the examles |
| 16:25.39 | De_Mon | perl -pi -e 's/CALLERID\(number\)/CALLERID(num)/gi' `find . ! -path '*svn*' -type f` |
| 16:26.19 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 16:26.23 | ManxPower | De_Mon: as far as I know, CALLERID(number) is not and was not ever valid. Is that correct? |
| 16:28.24 | blitzrage | ManxPower: it IS valid in code |
| 16:28.56 | outtolunc | er thinking |
| 16:29.09 | blitzrage | and now it is "valid" in documentation (once the patch goes in) |
| 16:32.43 | Corydon76-lap | You can do CALLERID(numthispartdoesntmatter) and it will work fine |
| 16:33.01 | blitzrage | which makes it even stranger to check for 'number' :) |
| 16:33.04 | JerJer | just don't transpose numbers :P |
| 16:33.22 | Corydon76-lap | blitzrage: that's been removed in trunk |
| 16:33.27 | blitzrage | oh? |
| 16:33.37 | Corydon76-lap | yeah, it made no sense |
| 16:33.40 | blitzrage | did that just happen... like... now? |
| 16:33.52 | Corydon76-lap | No, awhile ago |
| 16:34.09 | Corydon76-lap | It's considered an optimization, which is why we didn't touch 1.4 |
| 16:34.26 | blitzrage | oh gotcha |
| 16:34.43 | blitzrage | then I'm closing the patch I just made since it's useless |
| 16:35.37 | De_Mon | ManxPower it's always been valid, it use to check for num and number (only the first 3 and first 6 characters respectively) |
| 16:35.41 | *** join/#asterisk-dev RoyK (n=roy@gprs-ggsn5-nat.mobil.telenor.no) |
| 16:36.02 | De_Mon | trunk fixed the redundant check, but the examples still use both |
| 16:36.18 | De_Mon | and while 'number' still works, nobody is supposed to know :) |
| 16:36.22 | Corydon76-lap | De_Mon: the second one can only ever fail |
| 16:36.55 | De_Mon | Corydon76-lap ever fail? never fail maybe? |
| 16:37.29 | Corydon76-lap | De_Mon: Nope, if it COULD succeed, then the expression is matched on the first and the second is never evaluated at all |
| 16:37.59 | De_Mon | I'll agree with that |
| 16:40.56 | *** join/#asterisk-dev jtodd (n=jtodd@204.11.231.198.static.etheric.net) |
| 16:42.09 | *** join/#asterisk-dev jmesquita (n=jmesquit@201.7.117.114) |
| 16:44.49 | De_Mon | at any rate, the examples and desc should just use 'num' |
| 16:47.45 | *** join/#asterisk-dev yannj_fr (n=yannj_fr@APuteaux-152-1-34-103.w82-120.abo.wanadoo.fr) |
| 16:58.58 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.12.183) |
| 17:10.06 | *** join/#asterisk-dev bkruse (i=bkruse@nat/digium/x-18a44cfe9f3f40af) |
| 17:23.44 | *** join/#asterisk-dev dlynes (n=chatzill@d154-20-45-103.bchsia.telus.net) |
| 17:23.52 | *** join/#asterisk-dev flujan_ (n=flujan@200-160-115-020.static.spo.ctbc.com.br) |
| 17:29.09 | *** join/#asterisk-dev mog (n=mog@c-68-62-172-83.hsd1.al.comcast.net) |
| 17:29.09 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 17:34.12 | flujan_ | Hi Corydon76-lap a time ago we spoke about memory corruption problem with asterisk. |
| 17:34.37 | flujan_ | I installed the svn version and it is working fine. So I didn't send you the output... |
| 17:34.49 | flujan_ | or the bug information used with valgrind... |
| 17:37.29 | De_Mon | but... that means 1.4 is still broken |
| 17:37.38 | De_Mon | or is it svn 1.4? |
| 17:38.59 | Corydon76-lap | flujan_: please send the output anyway |
| 17:39.30 | Corydon76-lap | Frequently the speed of valgrind prevents the crash, but it also provides the information necessary to find what caused the crash in the first place |
| 17:39.47 | flujan_ | Corydon76-lap: No... I run it outside valgrind... |
| 17:40.07 | flujan_ | When I tried to run it inside valgrind The calls become muted... dunno way. :( |
| 17:40.35 | flujan_ | I upgrade to version 1.4.14 this week and I also switch the machine to a new one... |
| 17:40.45 | flujan_ | The new one are having problems with load |
| 17:40.49 | flujan_ | asterisk works fines |
| 17:41.04 | Corydon76-lap | 1.4.14 solved a whole bunch of memory corruption issues |
| 17:41.12 | flujan_ | but sometimes during the day it starts to consume all the cpu putting the machine a load average of 65 |
| 17:41.26 | flujan_ | I does not crash the system but I have to reboot it myself... |
| 17:41.39 | flujan_ | do you have a idea of what can cause it? |
| 17:41.47 | flujan_ | I spoke with oej in this morning... |
| 17:41.55 | flujan_ | He could not ssh to the server... |
| 17:42.07 | flujan_ | I return the old machine to its place and now everything is fine... |
| 17:42.23 | flujan_ | Tomorrow morning I will put the new machine online again ... |
| 17:42.35 | flujan_ | do you recommend me to run it inside valgrind ? |
| 17:43.08 | flujan_ | Valgrind could help to grab information about this issue or it just works for memory corruption problems ? |
| 17:43.11 | Corydon76-lap | I recommend that you run without the realtime priority flag |
| 17:43.38 | file | M11350 |
| 17:43.39 | MuffinMan | [feedback] [Asterisk] Core-General 0011350: Crash on calls AST_LIST_REMOVE_HEAD Macro reported by arnd http://bugs.digium.com/view.php?id=11350 |
| 17:43.44 | *** join/#asterisk-dev jameswf (n=james@dsl093-157-131.phx1.dsl.speakeasy.net) |
| 17:43.59 | file | Corydon76-lap: they are using an old trunk... pretty sure both have been fixed |
| 17:44.25 | Corydon76-lap | file: oh. probably |
| 17:45.59 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 17:45.59 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:46.24 | file | yay oej! |
| 17:50.45 | oej | There is a life after thanksgiving - welcome back! |
| 17:50.58 | *** join/#asterisk-dev JerJer (n=PhatJ@pdpc/supporter/bronze/jerjer) |
| 17:50.58 | *** mode/#asterisk-dev [+o JerJer] by ChanServ |
| 17:51.23 | file | meh, it was just plain ol' time off for me! which was most welcome |
| 17:51.33 | file | oej: and how are you on this fabulous Monday? |
| 17:52.10 | oej | file: I'm fine - and you? |
| 17:52.22 | file | I'm great! |
| 17:58.56 | oej | Cool |
| 17:59.05 | flujan_ | Corydon76-lap: hum... without the priority but I am using the safe_asterisk script... I am not starting it by hand. :( |
| 17:59.20 | flujan_ | oej: I saw a patch of busy-limit... does it works with the 1.4.14? |
| 17:59.32 | flujan_ | I really need the busy-limit feature... It is just cool. |
| 17:59.35 | oej | Only with trunk |
| 17:59.42 | Corydon76-lap | flujan_: are you sure the safe_asterisk script isn't setting the -p flag? |
| 17:59.44 | oej | It's been in trunk for a while |
| 18:00.10 | Corydon76-lap | flujan_: because the machine becoming unuseable is often the problem when things get out of hand on realtime priority |
| 18:03.53 | flujan_ | Corydon76-lap: http://pastie.caboo.se/122165 |
| 18:04.00 | flujan_ | Corydon76-lap: I found a core dump... |
| 18:04.14 | flujan_ | It helps nothing... at least for me... but maybe you can make use of it. :d |
| 18:07.46 | flujan_ | I just reinstalled the version enabling the malloc-debug... |
| 18:07.58 | flujan_ | tomorrow I will valgrind this and see what happens... :D |
| 18:10.53 | Corydon76-lap | Ugh, you're still using external processes for MOH? |
| 18:11.12 | Corydon76-lap | Native files works much better and doesn't waste CPU |
| 18:11.19 | *** join/#asterisk-dev twilson (n=twilson@CPE-65-30-30-20.kc.res.rr.com) |
| 18:17.17 | *** join/#asterisk-dev key2 (n=Ritual@193.33.36.20) |
| 18:17.29 | key2 | no creslin around ? |
| 18:18.05 | file | nope. |
| 18:27.19 | key2 | :P |
| 18:44.06 | Qwell | Is there any reason we continue playing ringing tone (dial with option r) when we start receiving media? |
| 18:45.06 | blitzrage | o.O |
| 18:45.06 | Qwell | it appears we stop playing music when we start getting media - why wouldn't ringing act the same way? |
| 18:45.06 | blitzrage | that seems odd |
| 18:45.12 | Qwell | M10934 |
| 18:45.13 | MuffinMan | [feedback] [Asterisk] Applications/app_dial 0010934: Option r with early files reported by gasparz http://bugs.digium.com/view.php?id=10934 |
| 18:45.31 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 18:45.31 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:45.34 | Qwell | I think his fix is right (I haven't tested it), but what I proposed would "change" existing behavior, if put into 1.4 |
| 18:45.55 | blitzrage | russellb: thoughts? |
| 18:46.02 | blitzrage | that's easy enough to find out :) |
| 18:46.31 | blitzrage | my thought would be if you DID put it in, that it be clearly defined in the release notes |
| 18:46.52 | Qwell | well, the way he did the patch, he added a dialplan variable to keep the old behavior |
| 18:46.55 | oej | file: how do you get license number when you commit? |
| 18:47.07 | Qwell | oej: there is a commit message template on the bug |
| 18:47.15 | Qwell | right between user list, and add note |
| 18:48.41 | oej | qwell: Thanks, didn't see that |
| 18:48.57 | file | oej: It's a good thing(tm) |
| 18:49.12 | oej | Do I get Karma for using it? |
| 18:49.26 | Qwell | no, but you don't get negative karma either |
| 18:49.30 | file | no, but you get negative karma for not using it |
| 18:49.57 | oej | Negative or positive - karma is karma ;-) |
| 18:50.28 | blitzrage | Qwell: hrmmmm.... this might be tricky and bad for deprecation of dialplans... but what about default in 1.4 being old behavior with a flag for new, and vice-versa for trunk? |
| 18:51.00 | Qwell | well, I'm just trying to figure out if there's any reason for it at all, first |
| 18:51.16 | blitzrage | true |
| 18:56.34 | *** join/#asterisk-dev BlaclSlik (n=jamesmar@77.246.64.134) |
| 18:56.51 | BlaclSlik | anybody in here |
| 18:57.58 | blitzrage | nope |
| 18:58.04 | BlaclSlik | heheheh |
| 18:58.05 | BlaclSlik | man |
| 18:58.10 | BlaclSlik | i saltu |
| 18:58.16 | BlaclSlik | i need help |
| 18:58.20 | blitzrage | see #asterisk pls |
| 18:59.45 | flujan_ | Corydon76-lap: ok... Well, I will start tomorrow the machine and see what I get... |
| 18:59.51 | flujan_ | Thanks for the help. :D |
| 19:00.55 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 19:03.55 | *** join/#asterisk-dev iamthelostboy (n=nathan@125-236-212-46.adsl.xtra.co.nz) |
| 19:09.57 | Laureano | "res_features_v2.c.patch uploaded by Laureano (license 265)". Am I the person number 265 who signed the disclaimer? |
| 19:20.37 | De_Mon | sure |
| 19:21.34 | De_Mon | whats the final tally on CALLERID(number)? Should I post the diff from that perl commandlet that updates all the examples to useing CALLERID(num) |
| 19:21.53 | De_Mon | s/ei/i/ |
| 19:22.03 | blitzrage | De_Mon: I already posted a patch for that, and closed it because 'number' isn't standard usage, even though it may or may not work |
| 19:22.29 | blitzrage | what examples don't use CALLERID(num) ? |
| 19:22.35 | De_Mon | a lot |
| 19:22.37 | De_Mon | ael mostly |
| 19:22.41 | blitzrage | ah |
| 19:22.51 | blitzrage | then ya, I guess that would be a useful patch :) |
| 19:23.34 | oej | the number can be a text string |
| 19:23.35 | De_Mon | I thought you committed something, though the number didn't look right |
| 19:23.44 | oej | I was just thinking about that when working with caller ID utf8 |
| 19:23.59 | oej | So "number" is bad terminology |
| 19:24.13 | De_Mon | its still the number portion of the cid tho isnt it? |
| 19:24.16 | oej | We have something you dial and something that is a display name |
| 19:24.16 | blitzrage | De_Mon: no commits from me |
| 19:24.26 | oej | De_mon: what's the number in sip:oej@edvina.net |
| 19:24.36 | blitzrage | whatever RPID contains :) |
| 19:24.37 | oej | "oej" is used as the extension in the dialplan |
| 19:24.53 | oej | Or the caller ID "number" if this is the caller ID |
| 19:25.00 | De_Mon | oej does that really work if you sent it to the POTS? |
| 19:25.22 | oej | No, but POTS is something a lot of Asterisk users don't use. |
| 19:25.35 | oej | Internally in Asterisk, this is a valid Caller ID |
| 19:25.38 | De_Mon | my ITSP requires +1<nu> |
| 19:25.50 | oej | That's why I'm adding CallerIDe164 |
| 19:25.58 | oej | Which is always a numeric |
| 19:26.03 | oej | This is messy |
| 19:26.08 | oej | For Zap, we prefer a number |
| 19:26.09 | De_Mon | I think number is fair, because thats what you dial |
| 19:26.17 | oej | For sip or xmpp, we prefer a string+domain |
| 19:26.25 | oej | I dial text strings a lot |
| 19:26.41 | oej | You're thinking old telephony, de_mon |
| 19:26.56 | oej | And since we're multiprotocol, we have to live with all variants |
| 19:27.08 | De_Mon | my phone number is de_mon@mydomain.com :) |
| 19:27.41 | De_Mon | It does seem silly, but people still know what you're talking about... sort of |
| 19:27.59 | oej | Right |
| 19:28.09 | oej | so CallerID(number) is not correct syntax at all any more |
| 19:28.46 | oej | kpfleming was working on an architecture for this many years ago |
| 19:29.08 | De_Mon | maybe address is more appropriate CID name and address |
| 19:29.27 | oej | Well, various channel drivers has different requirements |
| 19:29.38 | oej | zap prefers numbers and ascii display names |
| 19:29.51 | oej | sip prefers text strings and utf8 display names |
| 19:30.07 | De_Mon | I'd be more in favor of setting name and number and letting the channel driver complain if its set incorrectly for that technology |
| 19:30.33 | oej | So a SIP device needs configuration for utf8 and ascii caller ID display names, and numeric(e164) and utf8 caller ID "numbers" |
| 19:30.48 | De_Mon | convert the utf8 (or whatever) to numbers or ascii as needed and complaining if it cant be converted |
| 19:30.58 | oej | So when the SIP device calls a ZAP line, the zap driver can use numeric number and ASCII caller ID name |
| 19:31.11 | oej | You can't properly convert utf8 to ascii |
| 19:31.35 | De_Mon | not even for the characters that also exist in ascii? |
| 19:31.36 | oej | How do you convert ancient runes to ascii? Or asian scripts? |
| 19:31.49 | De_Mon | with *'s |
| 19:31.57 | oej | Well, that's very lossy and users don't want that. That's last resort. |
| 19:32.24 | De_Mon | so you'd rather set 4 different callerid variables on the off chance that it will use one or the other? |
| 19:32.24 | oej | You need to be able to configure names in Ascii and configure various conversion tables for various languages |
| 19:32.58 | oej | Oh, here in Sweden we're used to handle various name combinations |
| 19:33.11 | file | back! |
| 19:33.23 | De_Mon | yeah.. and you use the metric system too I bet </sarcasm> |
| 19:33.25 | oej | And it should not be our decision, it has to be the AstAdmins decision |
| 19:33.39 | oej | De_Mon: Oh thy ancient people |
| 19:33.43 | De_Mon | :) |
| 19:33.51 | oej | De_mon, you're slowly getting here, inch by inch. |
| 19:34.05 | De_Mon | you said inch |
| 19:34.36 | oej | Oh no, not again! |
| 19:43.01 | Qwell | oej: 100 yards is only like 3600 inches |
| 19:43.24 | tzanger | 3600 inches is over a half mile |
| 19:43.30 | tzanger | er no |
| 19:43.31 | tzanger | that's feet |
| 19:43.32 | tzanger | haha |
| 19:43.33 | Qwell | not even close |
| 19:43.45 | oej | Pls convert to metric. This is a multi-cultural channel. |
| 19:43.56 | Qwell | oej: yard ~= meter |
| 19:43.56 | putnopvut | 100 yards is less than 100 meters |
| 19:44.03 | putnopvut | or metres. |
| 19:44.14 | Qwell | or metouers |
| 19:48.12 | blitzrage | 100 yards == 109.36 meters |
| 19:49.15 | De_Mon | lastlog blitzrage 50 |
| 19:53.00 | wedhorn | Qwell: pj is pushing to get the skinny inband tones into trunk (M9077). Is there anything we can do to help you to speed it up such as asking some people to test? (DEA and mvanbaak?) |
| 19:53.23 | Qwell | I'm not sure that one is even about testing. I'm still just a bit bothered by replacing the sounds |
| 19:54.02 | wedhorn | OK, maybe we can discuss at some stage. |
| 19:55.23 | wedhorn | Before Christmas??? ;) |
| 19:55.26 | Qwell | s/sounds/indication tones/ |
| 19:56.11 | Qwell | that patch isn't really even about early media anymore |
| 19:56.44 | wedhorn | how so? |
| 19:56.53 | Qwell | I mean...the phones have locale support - why would we make asterisk need to care? |
| 19:58.26 | wedhorn | I think the thing is that if asterisk wants to play a tone, it should be able to. In order to do this, we need to start the RTP, after which we need to play the tones inband. If we use the device tones, asterisk can't play sounds until the call is connected. |
| 19:58.55 | Qwell | why not? |
| 19:59.17 | Qwell | we can signal the phone to play indications after rtp is going |
| 19:59.31 | wedhorn | because RTP has not started. |
| 19:59.45 | Qwell | my initial patch started rtp early, which fixed the original issue |
| 20:00.06 | wedhorn | No we can't. Well yes we can, but from memory (transfer stuff), the tones don't actually play. |
| 20:00.37 | De_Mon | M11379 |
| 20:00.37 | MuffinMan | [assigned] [Asterisk] CDR/General 0011379: 1.4.14 breaks cdr posting reported by cmaj http://bugs.digium.com/view.php?id=11379 |
| 20:00.41 | De_Mon | Agree!! |
| 20:00.42 | Qwell | the phones are dumb - they don't care if rtp is started |
| 20:01.03 | De_Mon | oops, I should have just added that to the bug, silly me |
| 20:01.03 | wedhorn | Maybe I should do some more testing. I'll try starting up RTP and see if I can play the device tones. |
| 20:01.13 | Qwell | wedhorn: look at my original patch |
| 20:01.41 | Qwell | that starts it as soon as we set the device to ringing - before we even run the pbx |
| 20:02.23 | wedhorn | OK, I'll have a look. If it does work, then I agree that my patches are going way overboard. |
| 20:03.27 | De_Mon | is there a special way to reference other bugs so mantis can link them up? |
| 20:03.39 | Qwell | De_Mon: #1234 |
| 20:03.50 | Qwell | or bug:1234, or like 5-6 other different ways |
| 20:04.11 | Qwell | it doesn't make them related, but it'll create a link in the note |
| 20:04.13 | De_Mon | hrm, I thought I tried the #, but looking at it again I see that there wasn't one.. |
| 20:04.45 | De_Mon | oh thats right, I removed the leading 0's and got the # sign too. dang |
| 20:04.57 | Qwell | no need to remove the 0s |
| 20:05.05 | Qwell | M009077 |
| 20:05.05 | MuffinMan | [assigned] [Asterisk] Channels/chan_skinny 0009077: Playback(<file>|noanswer) and in-band info are not working with chan_skinny reported by pj http://bugs.digium.com/view.php?id=009077 |
| 20:05.07 | Qwell | see? :D |
| 20:16.22 | De_Mon | I know, but it looks silly |
| 20:16.34 | De_Mon | I just got carried away and stripped the # too |
| 20:17.16 | Corydon76-lap | Madness |
| 20:18.22 | De_Mon | yay the govt gave me my money back from all those silly taxes today |
| 20:18.52 | Corydon76-lap | Are you sure they gave you back your own money and not someone else's money? |
| 20:19.45 | De_Mon | let me think about that and get back to you |
| 20:25.58 | wedhorn | Qwell: just tried your patch to M9077 and there is an issue that I don't get a ringing tone, but I do get a dialtone. Looks like it isn't RTP that stuffs around with the indications, maybe callstate? |
| 20:26.37 | Qwell | wedhorn: quite possibly. the phones are rather picky about it |
| 20:27.15 | wedhorn | Unfortunately they're not that dumb, just smart enough to be a PITA. |
| 20:27.24 | Qwell | they are too dumb |
| 20:27.33 | Qwell | too dumb for their own good, methinks |
| 20:27.45 | Qwell | and it really bothers me that xchat didn't highlight "methinks" |
| 20:27.59 | Qwell | it surprises sometimes me with the stuff it thinks are real words... |
| 20:28.14 | wedhorn | If they were competely dumb, they would be a lot easier to control |
| 20:28.18 | Qwell | heh |
| 20:29.16 | wedhorn | I'll have more of a play with it and see if I can find out whats killing the indication tones. |
| 20:39.41 | snuff-work | codefreeze: thanks :) |
| 20:41.14 | codefreeze | snuff-work: my pleasure, but, really, you are due some thanks yourself!!! Thanks! |
| 20:41.38 | snuff-work | ;) |
| 20:42.21 | De_Mon | Qwell why should it highlight methinks? |
| 20:43.25 | Corydon76-lap | Shakespeare thought it was a word |
| 20:43.45 | Qwell | xchat != Shakespeare |
| 20:43.56 | file | how can you be sure? |
| 20:44.19 | Corydon76-lap | Well, it's still in the dictionary |
| 20:44.29 | ctooley | There's no way to get the asterisk config directory out of asterisk for a SIP channel is there? |
| 20:45.04 | Corydon76-lap | ctooley: do what? |
| 20:45.26 | ctooley | I'd like to get the path to the configuration directory on a call by call basis. |
| 20:45.53 | Corydon76-lap | It isn't always /etc/asterisk ? |
| 20:46.05 | ctooley | Corydon76-lap, nope |
| 20:46.24 | ctooley | depending on which instance of asterisk takes the call it's different |
| 20:46.43 | ctooley | We're running 4 instances per server now, we might have to move to 8. |
| 20:47.50 | Corydon76-lap | Okay, how does knowing the path help? |
| 20:49.21 | Corydon76-lap | Perhaps you just want to do a setvar= in each of the sip.conf entries for a server |
| 20:49.45 | Corydon76-lap | You can do that with a template, even... save yourself some typing |
| 20:50.45 | ctooley | Corydon76-lap, I'm doing this to try to avoid making host specific config entries |
| 20:53.24 | Corydon76-lap | That's why I suggested a template |
| 20:54.08 | ctooley | I don't mean "host" as in SIP peer host, I mean "host" as in call servers. |
| 20:54.33 | Corydon76-lap | oh, hrm |
| 20:54.44 | ctooley | We've got 40-50 call servers with 4-8 instances of asterisk per server, so far all those configurations are identical |
| 20:55.52 | Corydon76-lap | One closer area would be to set an environmental variable in your startup scripts, but that's still per instance |
| 20:55.53 | ctooley | Managing 200+ instances of asterisk is tough enough without having the config files of each one being different. |
| 20:56.09 | Corydon76-lap | you can access ${ENV(foo)} |
| 20:56.40 | Corydon76-lap | That's about the closest I can think of |
| 20:58.11 | Laureano | Bye guys |
| 20:58.31 | ctooley | Corydon76-lap, hmmm I think I might just mod chan_sip again. |
| 20:59.41 | De_Mon | sounds hacky |
| 20:59.43 | Corydon76-lap | ctooley: does it need to be a constant per instance or just unique per instance? |
| 21:00.00 | ctooley | ? |
| 21:00.17 | Corydon76-lap | because you could put a call to ${CURL()} in your global variables, and have that URL return a monotonically incrementing identifier |
| 21:00.34 | De_Mon | ctooley how do you specify which config directory to use for each instance without modifying a startup script? |
| 21:00.38 | Corydon76-lap | on each reload, the number would change, but it would always be unique amongst all your instances |
| 21:00.51 | De_Mon | modify the same startup script to set an enviroment variable and access that var thru your dialplan |
| 21:01.07 | oej | what's the latest verdict? Can ast_calloc return an error? |
| 21:01.27 | Corydon76-lap | oej: On Linux, no. On BSD, it can return NULL. |
| 21:01.49 | ctooley | De_Mon, you "specify" it with ./configure --sysconfigdir= |
| 21:01.55 | oej | Ok, so we still need to check the return value on each ast_calloc then. |
| 21:01.55 | kpfleming | it can too return an error on linux |
| 21:01.58 | Corydon76-lap | oej: but ast_calloc already indicates the error, so all you need to do is release memory and exit |
| 21:02.18 | Corydon76-lap | kpfleming: only if the malloc strategy is not the default |
| 21:02.19 | De_Mon | youre recompiling asterisk for each instance? |
| 21:02.27 | De_Mon | wow, just.. okay. |
| 21:02.58 | kpfleming | Corydon76-lap: can you point me to a reference for that? |
| 21:03.03 | Corydon76-lap | kpfleming: the default memory allocation strategy on Linux is optimistic. It always returns a pointer, whether or not it has the space to represent it. |
| 21:03.10 | ctooley | De_Mon, we're compiling X number of references, they're the same on every server |
| 21:03.20 | kpfleming | but there are other errors besides lack of memory |
| 21:03.21 | Corydon76-lap | The memory page is allocated on access |
| 21:03.29 | kpfleming | if there is heap corruption, for example |
| 21:03.43 | oej | which thread reads RTP? |
| 21:03.46 | Corydon76-lap | Yeah, but heap corruption never returns... it calls abort(3) |
| 21:03.52 | oej | in sip |
| 21:04.07 | kpfleming | only if MALLOC_CHECK is set to force it to do that |
| 21:04.07 | file | oej: channel thread |
| 21:04.15 | oej | not the monitor? |
| 21:04.20 | file | oej: correct |
| 21:04.23 | Corydon76-lap | kpfleming: that's the default behavior, I think |
| 21:04.32 | file | oej: unless my super super experimental going to crash logic is enabled, which it isn't unless you go in and enable it |
| 21:04.42 | oej | file: So why do I see us occupying 100% of one core in dual core systems running only SIP calls |
| 21:05.09 | oej | Could it be a bug in the threads implementation for dual core? |
| 21:05.16 | file | unknown |
| 21:05.46 | Qwell | processor affinity, maybe? no idea |
| 21:10.06 | ctooley | hmmm I think knowing the SIP port the call came "to" (not from) would work too. |
| 21:10.42 | oej | ctooley: What are you trying to do? |
| 21:17.33 | oej | Good night, friends. |
| 21:19.30 | *** join/#asterisk-dev jbot (i=ibot@pdpc/supporter/active/TimRiker/bot/apt) |
| 21:19.30 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- IAX2/guest@misery.digium.com/asterisk-dev -=- Asterisk trunk: res_telepathy release tomorrow-=- Tier 2 and Tier 3.14159 support is in #asterisk -=- New Digium Building: http://flickr.com/photos/kpfleming/sets/72157602339837221/ -=- Bug campaigning automatically moves your bug to the bottom of the queue. Current hold time: 3-6 weeks. |
| 21:19.43 | tzafrir_home | well, I think you can safely leave now |
| 21:20.11 | oej | Thanks jbot for coming back. Sitting up waiting would have been bad for my tomorrow... :-) |
| 21:21.40 | codefreeze | ~murf |
| 21:21.41 | jbot | somebody said codefreeze was the most wonderful guy you'd ever like to meet!, or an alias for Steve Murphy |
| 21:21.57 | codefreeze | It lives! |
| 21:31.08 | blitzrage | ~blitzrage |
| 21:31.08 | jbot | hmm... blitzrage is a super cool fellow |
| 21:31.15 | blitzrage | oh neat |
| 21:31.44 | kpfleming | ~kpfleming |
| 21:31.52 | kpfleming | burn! |
| 21:31.54 | blitzrage | burn |
| 21:32.24 | blitzrage | hrmmm..... jbot: kpfleming is the reason Asterisk is they way it is :) |
| 21:32.30 | blitzrage | s/they/the |
| 21:33.07 | kpfleming | full of bugs and instability? :-) |
| 21:34.05 | file | kpfleming: madness! |
| 21:34.10 | file | they are just undocumented features |
| 21:34.32 | Corydon76-lap | jbot: kpfleming keeps the stiff necks out of our hair. |
| 21:35.11 | Corydon76-lap | There shouldn't be any echo on misdn lines, should there? |
| 21:35.23 | Corydon76-lap | being a digital circuit, not analog? |
| 21:35.31 | Qwell | Corydon76-lap: PRI has echo, right? |
| 21:35.44 | Corydon76-lap | Qwell: not the circuit itself, no |
| 21:35.49 | kpfleming | correct |
| 21:35.53 | Qwell | oh |
| 21:36.17 | Corydon76-lap | Qwell: you could get echo from a remote analog line introducing it, but that's analog, not the PRI itself |
| 21:36.31 | Qwell | would the same not be true for BRI/misdn? |
| 21:36.40 | Corydon76-lap | That's what I'm thinking |
| 21:36.57 | Corydon76-lap | which is why I'm wondering about that -users post |
| 21:38.15 | kpfleming | it happens, which is why we have echo cancelers available on our digital cars |
| 21:38.18 | kpfleming | or... cards |
| 21:38.31 | file | kpfleming: you have an analog car? |
| 21:40.16 | kpfleming | yes, it is based on vacuum tubes |
| 21:40.28 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177583123.dsl.bell.ca) |
| 21:42.22 | De_Mon | huh? |
| 21:42.56 | De_Mon | oh, vacuum tube cars... |
| 21:43.10 | Qwell | my car runs on punchcards |
| 21:43.12 | outtolunc | think fred flintstone with flip-flops |
| 21:43.30 | De_Mon | Yea i was imagining someone jogging in flopflops at first |
| 21:44.08 | De_Mon | whos idea was it to add PARKINGEXTEN? |
| 21:44.56 | De_Mon | I've added a feature to Park() so it doesn't saydigits if parkingexten is set, but the more I think about it, the more I think it needs to be set via option instead |
| 22:20.37 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 22:40.31 | putnopvut | chan_zap in trunk is b0rked :( |
| 22:45.51 | russellb | define borked |
| 22:46.20 | putnopvut | undefined reference to function pri_new_bri |
| 22:46.32 | putnopvut | grep shows that function not defined anywhere. |
| 22:46.49 | russellb | mattf keeps changing chan_zap without changing the configure script ... |
| 22:46.54 | Corydon76-lap | putnopvut: did you upgrade libpri? |
| 22:47.00 | putnopvut | I don't have libpri. |
| 22:47.06 | Corydon76-lap | That be why |
| 22:47.27 | putnopvut | I shouldn't need libpri though... |
| 22:47.56 | tzafrir_home | if you don't have libpri, that code should not be used in the first place |
| 22:48.09 | russellb | putnopvut: you do have libpri, or that code wouldn't be compiled in |
| 22:48.11 | tzafrir_home | that should be a bug |
| 22:49.20 | russellb | putnopvut: ls /usr/include/libpri.h |
| 22:49.45 | putnopvut | Ah, I apparently do have libpri, I just must have installed it a LONG time ago. |
| 22:49.50 | Corydon76-lap | libpri hasn't changed in forever until recently |
| 22:50.06 | Corydon76-lap | Hence why you may have missed it |
| 22:50.24 | putnopvut | I'll upgrade it and retry. |
| 22:53.02 | *** part/#asterisk-dev zerohalo (n=zeroHalo@pool-71-162-97-18.bstnma.east.verizon.net) |
| 22:54.55 | putnopvut | All clear! :) |
| 22:56.11 | tzafrir_home | actually libpri has changed earlier in the 1.6 cycle |
| 22:56.25 | tzafrir_home | anyway, has its soname been bumped? |
| 23:08.28 | *** join/#asterisk-dev RoyK (n=roy@ip-29-2-149-91.dialup.ice.no) |
| 23:10.49 | *** join/#asterisk-dev Laureano (n=chatzill@92-237-114-200.fibertel.com.ar) |
| 23:14.27 | *** join/#asterisk-dev twilson (n=twilson@CPE-65-30-30-20.kc.res.rr.com) |
| 23:43.23 | *** join/#asterisk-dev grimsy (n=chatzill@203-206-220-214.perm.iinet.net.au) |
| 23:51.03 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 23:51.03 | *** mode/#asterisk-dev [+o anthm] by ChanServ |