| 00:41.26 | *** join/#asterisk-dev russellb (n=russellb@asterisk/developer-and-stable-maintainer/drumkilla) |
| 00:41.26 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 00:41.38 | *** join/#asterisk-dev bkw_ (n=bkw_@freeswitch/developer/bkw) |
| 00:41.46 | jtodd | FWIW, re: pabelanger's comments - MRCP is supported both by Cepstral and Lumenvox. |
| 00:41.51 | jtodd | among others. |
| 01:02.25 | *** join/#asterisk-dev korihor (n=korihor@190.78.32.60) |
| 01:34.26 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23) |
| 01:57.58 | *** join/#asterisk-dev jameswf-home (n=james@66.18.113.20) |
| 02:48.03 | *** join/#asterisk-dev bkw_ (n=bkw_@freeswitch/developer/bkw) |
| 03:08.04 | *** join/#asterisk-dev obnauticus (n=obnautic@about/windows/regular/obnauticus) |
| 03:20.54 | *** join/#asterisk-dev sucituanbo (n=blah@c-24-21-121-148.hsd1.wa.comcast.net) |
| 03:39.07 | *** join/#asterisk-dev lvl- (n=lvl@101.248.dhcp.lht.hhs.nl) |
| 03:49.02 | *** join/#asterisk-dev jameswf-home (n=james@ip72-223-0-183.ph.ph.cox.net) |
| 05:24.25 | snuff-work | mm falves reports all good on port thing :) |
| 05:53.34 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 05:53.34 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:18.28 | mvanbaak | hey bkruse :) |
| 06:42.25 | *** join/#asterisk-dev obnauticus (n=obnautic@about/windows/regular/obnauticus) |
| 06:43.34 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 06:43.34 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:44.33 | oej | Morning |
| 06:47.16 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 06:47.16 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 06:50.06 | *** join/#asterisk-dev gmaruzz (n=gmaruzz@213-140-6-122.ip.fastwebnet.it) |
| 06:51.33 | snuff-work | ello oej |
| 06:53.13 | *** part/#asterisk-dev gmaruzz (n=gmaruzz@213-140-6-122.ip.fastwebnet.it) |
| 07:42.30 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.137) |
| 07:58.34 | *** join/#asterisk-dev gmaruzz (n=gmaruzz@213-140-6-122.ip.fastwebnet.it) |
| 08:11.38 | *** join/#asterisk-dev speekac (n=alwin@60.51.217.61) |
| 08:11.54 | speekac | hi, does asterisk support utf-8 for variables |
| 08:14.00 | tzafrir_laptop | names or contents? |
| 08:15.13 | speekac | the value |
| 08:22.20 | *** join/#asterisk-dev steliosk (n=Stelios@athedsl-309630.home.otenet.gr) |
| 08:22.36 | tzafrir_laptop | I suppose Asterisk assumes 1 character == 1 byte |
| 08:23.07 | tzafrir_laptop | So if you try to use UTF-8 you may get strange results with string operations that rely on length |
| 08:46.45 | speekac | i was having problem with txfax's LOCALHEADERINFO which set the header without utf-8 chars |
| 09:02.23 | *** part/#asterisk-dev speekac (n=alwin@60.51.217.61) |
| 09:23.29 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 09:23.29 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:25.21 | *** join/#asterisk-dev qdk (n=qdk@85.235.253.139) |
| 10:03.22 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.141) |
| 10:57.35 | seanbright | Qwell: re: 13255 - Thank jeebus! :) |
| 11:24.23 | *** join/#asterisk-dev DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 11:42.21 | *** join/#asterisk-dev eliel (n=eliel@200.61.172.61) |
| 12:03.22 | *** join/#asterisk-dev _ys (i=yuri@91.151.196.254) |
| 12:04.30 | _ys | hello. make menuselect broken in trunk now? |
| 12:04.41 | _ys | mxml: Mismatched close tag </member> under parent <menu>! |
| 12:04.41 | _ys | Error parsing 'menuselect-tree'! |
| 12:34.07 | ctooley | morning |
| 12:37.14 | JunK-Y | hiya |
| 12:51.47 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip68-103-153-140.ks.ok.cox.net) |
| 12:56.07 | *** join/#asterisk-dev Rem| (n=remi@bg-fw2out.monmouth.com) |
| 13:04.45 | Qwell | seanbright: yeah... |
| 13:05.52 | steliosk | tzafrir_laptop : Perfect sync in message replies :) |
| 13:07.20 | tzafrir_laptop | I guess such messages are intended to test who is currently reading his mail |
| 13:10.47 | steliosk | :) |
| 13:24.00 | seanbright | Qwell: his attitude sucks though |
| 13:24.07 | Qwell | *shrug* |
| 13:24.13 | seanbright | indeed. |
| 13:27.19 | *** join/#asterisk-dev moy (n=moy@nat/ibm/x-b872ca95e7124cea) |
| 13:50.01 | snuff-home | Qwell: falves said patch for 13255 works :) |
| 13:50.11 | Qwell | yep, I saw :D |
| 13:50.26 | snuff-home | love comment.. It works fine, please merge before something happens. And thanks. |
| 13:55.53 | *** join/#asterisk-dev nicox (n=nicox@83-64-42-210.prater.xdsl-line.inode.at) |
| 13:56.16 | *** part/#asterisk-dev nicox (n=nicox@83-64-42-210.prater.xdsl-line.inode.at) |
| 13:59.15 | *** join/#asterisk-dev sruffell (n=sruffell@adsl-074-185-078-025.sip.bhm.bellsouth.net) |
| 13:59.15 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:00.11 | snuff-home | i guess if u apply that fix needs to be to trunk/1.6.0/1.6.1 |
| 14:00.23 | Qwell | yep |
| 14:01.06 | seanbright | yikes |
| 14:01.12 | Qwell | trunk>1.6.0, trunk>1.6.1 |
| 14:01.18 | snuff-home | can rc1 of 1.6.0 be redone to inc that fix.. as it could possibly break lot ppl ? |
| 14:01.26 | Qwell | snuff-home: I asked Kevin. we'll see |
| 14:01.31 | snuff-home | ah k |
| 14:01.37 | *** join/#asterisk-dev Schmooze (n=Schmooze@rrcs-67-53-189-178.west.biz.rr.com) |
| 14:02.05 | Qwell | snuff-home: you're right though - it's not just falves. I looked at the issue that caused that patch to go in, and his trace had the :0 |
| 14:02.15 | Qwell | so.. |
| 14:02.57 | Qwell | bbl |
| 14:03.30 | jsmith | rc2! |
| 14:03.32 | jsmith | rc2! |
| 14:03.37 | jsmith | (rc1.1?) |
| 14:03.48 | jsmith | ducks |
| 14:04.08 | snuff-home | jsmith: should be able to get away with rc1 still.. since it hasnt been posted :) |
| 14:04.35 | jsmith | This is why I hate version numbers |
| 14:04.59 | jsmith | Because what happens if someone has already pulled from SVN based on the tag? |
| 14:05.10 | jsmith | Just because the tarball hasn't been posted doesn't mean nobody is using it |
| 14:05.41 | snuff-home | well.. generally ppl would just svn 1.6.0 branch.. or 1.4 branch.. |
| 14:05.44 | jsmith | Version numbers are disposable, anyway... it's not like they cost $500 every time you use another version number |
| 14:06.11 | snuff-home | true true.. |
| 14:06.21 | Corydon76-dig | jsmith: yes, but it raises questions when you have non-continuous version numbers |
| 14:06.28 | snuff-home | hmmms @ 13301 |
| 14:06.42 | Corydon76-dig | jsmith: it's why many places use build numbers, then align a version with a particular build number |
| 14:06.57 | jsmith | Corydon76-dig: Hence the reason for release notes. "We tagged rc1, but then found a small problem, so we've gone straight to rc2" |
| 14:07.04 | snuff-home | valgrind possibility.. ? |
| 14:13.21 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:13.21 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 14:28.56 | seanbright | this doesn't bode well for the timeout checking i am adding to cdr_tds -> http://lists.ibiblio.org/pipermail/freetds/2008q2/023189.html |
| 14:40.44 | jsmith | seanbright: Nope... |
| 14:54.13 | mvanbaak | gheh, dont you just love it when you have a patch for something, and with that patch applied you find a bug in a totally different place ? |
| 14:56.12 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 14:56.12 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:56.44 | mvanbaak | wb oej |
| 14:57.15 | oej | Afternoon |
| 14:59.46 | seanbright | ok, so i need to commit a bug fix to trunk and 1.6.0... i now need to commit it to 1.6.1 as well? |
| 14:59.58 | mvanbaak | seanbright: yes |
| 15:00.01 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 15:00.08 | seanbright | like Qwell said, trunk -> 1.6.0 and trunk -> 1.6.1 |
| 15:00.18 | mvanbaak | yup |
| 15:00.21 | seanbright | m'kay |
| 15:01.38 | Qwell | merging to 1.6.1 is exactly the same as merging to 1.6.0, it's just done from the 1.6.1 checkout instead |
| 15:01.52 | seanbright | mergetrunk6 will still work? |
| 15:01.58 | Qwell | yep |
| 15:02.01 | seanbright | super |
| 15:03.16 | tzafrir_laptop | A137731 |
| 15:03.24 | Qwell | palindrome |
| 15:03.49 | tzafrir_laptop | anyway, regarding that indentation fix (tabs->spaces) |
| 15:04.13 | Qwell | uh huh? |
| 15:04.17 | tzafrir_laptop | I think that there are quite a few places where tabs are used for indentation in the middle of the line |
| 15:04.23 | Qwell | tzafrir_laptop: yeah... |
| 15:04.23 | seanbright | yeah |
| 15:04.28 | Qwell | quite a lot |
| 15:04.31 | seanbright | janitor! |
| 15:04.38 | tzafrir_laptop | whereas the coding guidelines say this is wrong |
| 15:04.46 | Qwell | tzafrir_laptop: yep |
| 15:05.04 | Qwell | it's pretty much always been known, it's just...never really followed |
| 15:05.40 | Qwell | lots of #define blocks are like that too |
| 15:06.34 | Qwell | oh, tzafrir_laptop.. somebody in #asterisk had a question about xpp and timing. wizzy I think was his name |
| 15:07.08 | seanbright | fuzzy wuzzy |
| 15:07.54 | tzafrir_laptop | Wizzy has a B410P IIRC |
| 15:08.13 | Qwell | astribank too |
| 15:09.11 | *** join/#asterisk-dev ariel_ (n=ariel_@74.8.35.6) |
| 15:11.26 | *** join/#asterisk-dev russellb (n=russellb@asterisk/developer-and-stable-maintainer/drumkilla) |
| 15:11.26 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 15:13.33 | tzafrir_laptop | thanks |
| 15:21.42 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 15:21.42 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:25.12 | *** join/#asterisk-dev jameswf-home (n=james@dsl093-157-131.phx1.dsl.speakeasy.net) |
| 16:03.48 | Corydon76-dig | tis quiet, today |
| 16:04.42 | jtodd | shh. Sleeping now. |
| 16:05.28 | Qwell | ~wake jtodd |
| 16:05.29 | jbot | ACTION throws a barrel-full of ice water on jtodd and shouts "GOOD MORNING!!!!" |
| 16:17.20 | jtodd | zzzz. <snort> |
| 16:18.24 | jtodd | security feature question: would it be worthwhile to create an option for chan_sip that refused new registrations on already-registered peers? "singleregister=yes" as an option (globally or per-peer) |
| 16:18.44 | oej | How would we accept re-registrations then? |
| 16:18.46 | jtodd | I've heard of two people in the last week who have been brute-forced with bad SIP passwords. Seems like that would be a solution. |
| 16:18.50 | oej | Or define "new registrations" |
| 16:19.05 | jtodd | When registrations expire, the entity would be allowed to re-register. |
| 16:19.18 | oej | That would break communication. |
| 16:19.22 | jtodd | Or we auto-allow registrations with the same origin IP address if registraton occurs before timers expire. |
| 16:19.25 | oej | You are supposed to re-register before expiry |
| 16:19.30 | *** join/#asterisk-dev Deeewayne (n=Deeewayn@conference/asterisk/x-314a5b5196d6c078) |
| 16:19.30 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 16:19.54 | oej | Well, if a device reboots and gets a new IP, then we would disallow it for a penalty time. |
| 16:19.58 | jtodd | Correct. |
| 16:20.09 | jtodd | Optional, of course. |
| 16:20.14 | oej | Of course |
| 16:20.25 | *** join/#asterisk-dev mvanbaak (n=michiel@vanbaak.xs4all.nl) |
| 16:20.25 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 16:20.29 | jtodd | But would possibly help in the brute-force attack front for those who would like to defend against it. |
| 16:20.38 | oej | What's the state on IAX2 for the same situation? |
| 16:20.43 | jtodd | No idea. |
| 16:20.52 | oej | Who bothers :-) |
| 16:20.58 | jtodd | Hey, hey, now.... |
| 16:21.33 | russellb | IAX2 is in the exact same situation |
| 16:21.43 | oej | I would suggest we don't send "Forbidden", just another auth header - the faked variant we already have |
| 16:21.46 | russellb | re-registrations are done before it expires, same as SIP |
| 16:22.06 | oej | But can the same situation happen if you have two clients for one account? |
| 16:22.11 | oej | Like in SIP |
| 16:22.13 | jtodd | so what would that do in "legitimate" situations where a device has re-IP'ed? |
| 16:22.40 | jtodd | oej: as far as I understand it right now, * only supports one client per "account". Has that changed while I wasn't looking? |
| 16:22.52 | russellb | Nope, it hasn't changed ... |
| 16:23.19 | Juggie | jtodd, perhaps the optimal solution would be to ban an ip based on multiple incorrect passwords |
| 16:23.28 | jtodd | So when we eventually support multiple registrations per "account", this may not need to change. Maybe the idea is that there is an integer limit. |
| 16:23.34 | Juggie | because breaking how registrations work would be bad. |
| 16:23.36 | oej | No, but we will accept a new registration and just use the latest contact. So we'll switch for every authorized reg. |
| 16:23.47 | russellb | nods |
| 16:23.51 | russellb | IAX2 would behave the same way |
| 16:23.53 | jtodd | "mutliplelogins=no" would permit just one, but "multiplelogins=2" would only permit two devices in that distant eventual case. |
| 16:23.57 | oej | We would have to have a limit on the number of contacts. |
| 16:24.12 | oej | A configurable limit |
| 16:24.22 | Juggie | it would be nice to have multiple registrations to one sip username. |
| 16:24.27 | jtodd | Juggie: banning on multiple incorrect passwords would break legitimate users, unless you keep a hash table of IP addresses that are "more" or "less" trusted. |
| 16:24.32 | oej | jtodd: Cool idea. Add it to www.asteriskideas.org :-) |
| 16:24.51 | Juggie | jtodd, i dont think so, if someone tries like 10 times w/ dif passwords same account in a set time peroid |
| 16:24.52 | oej | juggie: Yes, and I know how to do it without breaking architecture |
| 16:24.54 | Juggie | then they are up to something |
| 16:25.03 | Juggie | oej, me too, but i dontk now how to code it :) |
| 16:25.26 | jtodd | Juggie: so that's locking the account or the IP address? |
| 16:25.40 | Juggie | jtodd, the ip address of course |
| 16:25.47 | oej | We already have ACLs |
| 16:26.13 | jtodd | Juggie: bad news is that if you use IP addresses, you don't solve brute force from distributed hacking, which given the size of most botnets, is a valid problem. |
| 16:26.21 | oej | But if you go down that path, you might want to disable registrations totally |
| 16:26.28 | Juggie | jtodd, well banning the user could cut off service. |
| 16:27.06 | jtodd | Juggie: No, not unless your IP address changes before your timers expire on a regular basis. |
| 16:27.28 | jtodd | And again, this is an optional item so for people who for some reason change IP address that frequently can just have it turned off. |
| 16:28.05 | jtodd | More than one way to do it, of course. I'm usually just not in favor of keeping big lists of things around (aka: IP address lists) if it can be helped. Other dragons lurk there. |
| 16:29.53 | Juggie | then the other option is the reverse, to allow using the ACL only the ip or range of ips you know the user connects from |
| 16:30.43 | jtodd | We already have that, but the problem is that it's typically the case that the operator can't easily predict IP address ranges on "the Internet" where users will appear from. |
| 16:31.27 | jtodd | If it's a corporate PBX, that's one thing - this defense mechanism isn't necessary at all, since firewalls and other things stand in the way. But if you're opening a SIP portal to your folks on-the-road, it may be useful. |
| 16:32.04 | jtodd | And certainly to service providers who are not also the network providers (aka: many ISTPs who just sell SIP or IAX single-line services) |
| 16:32.57 | Juggie | if i had a wifi phone (if they even worked) and i moved from one hot spot to another you could potentially ban me because my internet ip changed |
| 16:33.12 | Juggie | there has to be some mechanism to prevent false positives |
| 16:33.36 | jtodd | Reduce the registration interval on your phone to something like 100 seconds and you'd have (on average) a 50 second delay on your re-registrations. Or turn it off for people who are that mobile. |
| 16:34.38 | Juggie | another idea is to provide a hook into asterisk to run a shell command when it detects a dos/password hacking attempt from an ip. |
| 16:34.40 | jtodd | Most phones are not that mobile from an IP perspective at the moment. Let me say again that this is an optional, incremental security fix. |
| 16:34.51 | Juggie | then you could ban the ip on the iptables level |
| 16:35.09 | Juggie | which removes asterisk from having to keep the list |
| 16:35.13 | jtodd | That had been discussed, actually, a long time ago but I don't recall the details of the discussion. Olle, do you remember that? |
| 16:35.18 | Qwell | fail2ban... |
| 16:35.28 | oej | Sorry, was in another window... |
| 16:35.58 | oej | Remember what? |
| 16:35.58 | jtodd | The problem with running "external" programs is that we create yet another area where Asterisk fails to do the right thing, and solutions are build which become platform-dependent. |
| 16:36.07 | oej | Manager is the solution |
| 16:36.20 | jtodd | oej: the discussion about SIP being able to install dynamic firewall rules in pf or something like taht. |
| 16:36.26 | oej | We added in trunk, I don't remember if it's in 1.6.0 |
| 16:36.30 | jtodd | s/SIP/chan_sip |
| 16:36.33 | oej | Oh, that I don't remember |
| 16:36.36 | Juggie | jtodd, to keep 100% service for users sadly there is no right thing... |
| 16:36.41 | Juggie | no perfect solution for sure |
| 16:36.54 | Qwell | that doesn't seem like a great idea to me. apache has nothing like that |
| 16:37.03 | oej | I don't know if I think that's an issue for Asterisk, but in my case I always have another SIP server in the front. |
| 16:37.05 | jtodd | Juggie: indeed, there is not. However, I believe that Asterisk should be as self-contained as possible for easy solutions. |
| 16:37.27 | oej | I want named ACLs to start with |
| 16:37.40 | jtodd | Sure, that sounds like a good start. |
| 16:37.42 | oej | Then we could integrate with pf/iptables. That would propably be useful. |
| 16:37.52 | oej | named ACLs would be wonderful for realtime. |
| 16:38.06 | oej | And make configuration much easier |
| 16:38.19 | oej | Make one ACL for your service providers servers and then enable that for the peer account |
| 16:38.27 | Juggie | there would be no harm in running a external script if a hacking/dossing attempt was detected |
| 16:38.37 | oej | If a customer has 50 accounts, we could have one in-memory ACL instead of 50 |
| 16:38.41 | Juggie | it could send an email, send a sms, add an ip tables rule |
| 16:39.03 | oej | Well, there are false positives that would make that not very useful |
| 16:39.13 | oej | Integration with Nagios over manager or so would be better |
| 16:39.46 | jsmith | oej: Nagios/Asterisk administration is already possible... I've been doing it for more than 5 years now |
| 16:39.46 | oej | We could look into integrating something like Pike, that OpenSER has, to discover abuse and run a script or add to blacklist |
| 16:39.59 | oej | jsmith: Me too. But this adds functionality. |
| 16:40.17 | oej | jsmith: We're old people, remember? |
| 16:40.35 | jsmith | oej: You keep reminding me of that |
| 16:47.45 | *** join/#asterisk-dev mvanbaak (n=michiel@vanbaak.xs4all.nl) |
| 16:47.45 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 16:53.38 | *** join/#asterisk-dev qdk (n=qdk@0x573fe57e.bynqu2.static.dsl.tele.dk) |
| 16:56.10 | JerJer | packt publishing just contacted me to be an author for a freepbx book they want to get written |
| 16:56.33 | Qwell | russellb: |
| 16:56.55 | JerJer | i giggled like a school girl when i read that email |
| 16:57.03 | Qwell | JerJer: You should totally do it. |
| 16:57.28 | JerJer | freepbx is not officially tied to fonality - right ? |
| 16:57.33 | Qwell | no |
| 16:57.43 | Qwell | it isn't unofficially either |
| 16:57.50 | JerJer | yeah - ok |
| 16:58.03 | Qwell | they don't technically even use "freepbx" anymore. They forked it |
| 16:58.15 | JerJer | even better |
| 16:58.46 | jtodd | Issue of some contention there, actually. Search Google for "astroturfing" and "fonality" and "freepbx" for more details. |
| 16:59.11 | JerJer | lol hehehe astroturfing |
| 16:59.24 | *** join/#asterisk-dev mvanbaak_ (n=michiel@vanbaak.xs4all.nl) |
| 16:59.24 | *** mode/#asterisk-dev [+o mvanbaak_] by ChanServ |
| 16:59.27 | jtodd | Of course, what you read on the Internets is subject to various levels of truthiness, so cautious reading there. |
| 16:59.46 | JerJer | boy do i know that |
| 17:00.31 | JerJer | there are people that hate nufone - yet all i have ever done is be honest with people - NO sugar coating |
| 17:00.49 | tzafrir_laptop | Did they really fork it? I faintly recall some patches of their submitted to freepbx recently. |
| 17:01.00 | mvanbaak_ | phew |
| 17:01.52 | jtodd | http://www.freepbx.org/news/2008-05-30/trixbox-forks-freepbx |
| 17:02.16 | jameswf-home | everything posted on the internet is 100% fact... if you find two things you think contradict it is probably because your brin is too weak to understand that they are all right |
| 17:02.30 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 17:14.37 | *** join/#asterisk-dev Schmooze (n=Schmooze@rrcs-67-53-189-178.west.biz.rr.com) |
| 17:18.01 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 17:26.45 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 17:26.45 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:43.11 | eliel | mvanbaak: hello |
| 17:43.28 | mvanbaak | hey eliel |
| 17:44.14 | eliel | I have cleanup the formatting, I will commit in a moment. |
| 17:45.29 | eliel | I would like you to review it if you can |
| 17:48.28 | ctooley | stupid bash question. how do I list just the entries in a directory that are of type directory? |
| 17:48.41 | Qwell | */ ? |
| 17:48.41 | mvanbaak | eliel: sure thing |
| 17:48.46 | ctooley | ls -d only returns "." |
| 17:48.54 | mvanbaak | find . -type d |
| 17:49.00 | Qwell | yeah, */ |
| 17:49.01 | ctooley | mvanbaak, that decends |
| 17:49.02 | Qwell | echo */ |
| 17:49.10 | ctooley | aha, thanks |
| 17:49.21 | mvanbaak | ctooley: find has stuff for recursion depth |
| 17:49.26 | Qwell | never never never parse ls |
| 17:49.27 | Qwell | never |
| 17:49.40 | seanbright | ls -al | grep ^d |
| 17:49.48 | seanbright | bam |
| 17:49.59 | ctooley | Qwell, parsing ls is perfectly fine for somethings. :) |
| 17:50.06 | Qwell | ctooley: NEVER! :D |
| 17:50.19 | ctooley | for i in `echo */`; do cd $i; svn update; cd ..; done |
| 17:50.19 | Qwell | if any of your filenames have a space, you're screwed |
| 17:50.22 | ctooley | that's what I wanted. |
| 17:50.28 | Qwell | nah, don't echo |
| 17:50.32 | Qwell | for i in */; do ... |
| 17:50.46 | ctooley | Qwell, right, but that wasn't an issue, and echo worked alright. |
| 17:50.52 | Qwell | echo will make you run into the same problems as ls |
| 17:50.52 | ctooley | did what I wanted anyway. |
| 17:51.00 | Qwell | specifically, word splitting |
| 17:51.11 | mvanbaak | use read |
| 17:51.19 | mvanbaak | that will take care of it |
| 17:51.33 | eliel | mvanbaak: done |
| 17:51.34 | tzafrir_laptop | find -exec |
| 17:51.55 | ctooley | If only I could get that many answers to a complex asterisk question. :) |
| 17:52.10 | tzafrir_laptop | svn update */ #? |
| 17:52.16 | seanbright | ctooley: "complex" is the keyword there |
| 17:53.18 | ctooley | seanbright, quit arguing with me using facts. It diffuses my nonsense. |
| 17:54.27 | mvanbaak | eliel: I'll have a look at it |
| 17:55.03 | eliel | mvanbaak: great |
| 17:55.28 | russellb | seanbright: you have a bad habit of using logic |
| 17:55.31 | ctooley | I love undocumented, unintended side effects of closed systems |
| 17:55.35 | *** join/#asterisk-dev arturo_era (n=chatzill@189.171.156.125) |
| 17:56.09 | ctooley | It gives irritation ... err.... excitement to my job. |
| 17:57.08 | eliel | mvanbaak: all the output is wrapped to 80 chars... |
| 17:58.17 | eliel | MAX_DIFF is a dispersetion while wrapping the text.. if it can found a space +-XMLDOC_MAX_DIFF, it will print the word with a '-' and continue in the other line... |
| 17:59.02 | mvanbaak | eliel: + *len += sprintf(*buffer + *len, "%s%s: ", tabs, varname); |
| 17:59.06 | ctooley | I have front ended Asterisk with OpenSER to do some trunk group selection magic and ended up beating my head against the table trying to figure out what I was doing wrong. Turned out that by having the Asterisk server that is identified in the SDP defined as a SIP endpoint in our core switch, the switch decided that Asterisk was the TG in question and not the OpenSER server. |
| 17:59.29 | russellb | mvanbaak: that's begging for some ast_strification! |
| 18:00.20 | mvanbaak | my idea |
| 18:01.36 | mvanbaak | food, brb |
| 18:01.58 | jsmith | ctooley: Oh joy... |
| 18:02.37 | seanbright | russellb: yeah, well... yeah. |
| 18:02.43 | ctooley | jsmith, yeah, if the IP in the SDP don't match to a trunk group, it "falls back" to whatever's in the URI |
| 18:03.05 | russellb | seanbright: 1 + 1 = 1 ! |
| 18:03.07 | eliel | mvanbaak: what happen with that line |
| 18:03.14 | seanbright | russellb: for certain values of 1 ;) |
| 18:03.56 | russellb | yes, or if you were to be combining sets of numbers ... the result is a set with just 1 in it... |
| 18:04.08 | seanbright | ^^ dorks |
| 18:04.21 | russellb | that's more like ... { 1 } + { 1 } = { 1 } |
| 18:04.23 | eliel | + = OR :-) |
| 18:05.27 | *** join/#asterisk-dev jtodd (i=hnkhiooo@ns.fox-den.com) |
| 18:05.27 | *** mode/#asterisk-dev [+o jtodd] by ChanServ |
| 18:09.25 | seanbright | so i want to add some notes to trunk/1.6.0/1.6.1 in reference to FreeTDS timeout behavior in it's various incarnations |
| 18:09.33 | russellb | do it! |
| 18:09.43 | russellb | btw, you're the official maintainer of that code now, congrats! :) |
| 18:09.58 | seanbright | i.e. FreeTDS < 0.82 doesn't ever timeout... |
| 18:10.04 | seanbright | where would one add that? |
| 18:10.26 | seanbright | doc? |
| 18:10.28 | russellb | hmm |
| 18:10.28 | seanbright | upgrade.txt? |
| 18:10.29 | russellb | probably not |
| 18:10.36 | russellb | the sample config would be a good start |
| 18:10.41 | seanbright | good call |
| 18:10.47 | russellb | if it relates to differences between versions of asterisk, then UPGRADE.txt, as well\ |
| 18:11.00 | seanbright | ok |
| 18:11.55 | jsmith | Corydon76-dig: Silly question, but were those two commits for #13027 supposed to merge to 1.6.1 as well? |
| 18:12.36 | mvanbaak | eliel: it uses sprintf |
| 18:12.55 | Corydon76-dig | jsmith: maybe |
| 18:12.57 | eliel | a lot :-S |
| 18:13.42 | russellb | sprintf is evil in general |
| 18:13.43 | jsmith | Corydon76-dig: Just curious... as I'm still wrapping my head around the "new development" ways |
| 18:14.04 | mvanbaak | eliel: what russell said |
| 18:14.09 | mvanbaak | 19:59 <@ russellb> mvanbaak: that's begging for some ast_strification! |
| 18:14.42 | eliel | in which scenario can be evil? |
| 18:15.06 | seanbright | when it overruns a buffer |
| 18:15.21 | russellb | what seanbright said |
| 18:15.29 | russellb | when it leads to buffer overflow security vulnerabilities, in the worst case |
| 18:15.48 | seanbright | best case, a puppy dies |
| 18:16.10 | mvanbaak | and even that is something we dont want to happen |
| 18:18.07 | mvanbaak | besides that, I think the implementation is ok |
| 18:18.10 | eliel | Ok, I though using strcpy and sprintf in enviroments that you are allocating the already known needed space it can't be a problem... |
| 18:18.16 | mvanbaak | cant think of a better way right now |
| 18:18.48 | mvanbaak | eliel: if you already know the needed space use snprintf |
| 18:19.45 | eliel | ok |
| 18:20.50 | russellb | yeah, you're right, if you _know_ you have enough space, those functions are ok |
| 18:21.02 | russellb | though I would consider using ast_str() where you can, as it tends to simplify implementation |
| 18:21.47 | russellb | if we need to add another operation to ast_str, then I'd rather do that than end up with some more complicated sprintf/strcpy magic |
| 18:22.11 | eliel | russellb: agree |
| 18:32.32 | JerJer | is there a way to 'unselect' all options in make menuselect ? |
| 18:33.06 | russellb | in the ncurses interface, there is ... |
| 18:33.16 | russellb | looks |
| 18:33.24 | seanbright | f7 |
| 18:33.30 | russellb | yeah. |
| 18:33.30 | russellb | that |
| 18:33.37 | seanbright | same in the newt interface |
| 18:33.42 | JerJer | cool |
| 18:35.14 | JerJer | is this documented somewhere? i didn't look :( |
| 18:35.17 | seanbright | yes |
| 18:35.19 | seanbright | in the help |
| 18:35.45 | seanbright | at least in the ncurses version |
| 18:36.05 | JerJer | ok - how does one force the ncurses version? |
| 18:36.10 | Qwell | make nmenuselect |
| 18:36.14 | Qwell | erm, c |
| 18:36.18 | Qwell | cmenuselect |
| 18:36.18 | seanbright | why would you want to do something silly like that? |
| 18:36.28 | russellb | cmenuselect > nmenuselect :-p |
| 18:36.31 | seanbright | ouch |
| 18:36.32 | russellb | hehe |
| 18:36.37 | seanbright | really? |
| 18:36.40 | russellb | j/k ... nmenuselect is sexy |
| 18:36.41 | Qwell | qmenuselect > *menuselect |
| 18:36.45 | russellb | that's why it's the default! |
| 18:36.46 | Qwell | yeah, I said it |
| 18:36.51 | seanbright | the curses version kinda sucks ass |
| 18:36.52 | seanbright | heh |
| 18:36.54 | JerJer | ok - smells like a blog entry in the making |
| 18:36.56 | seanbright | kids |
| 18:37.10 | seanbright | JerJer: what problem are you having? |
| 18:37.21 | seanbright | specifically with the newt version |
| 18:37.25 | seanbright | because i'd like to fix it |
| 18:37.29 | russellb | seanbright: bitch! |
| 18:38.13 | russellb | seanbright: j/k <3 |
| 18:38.19 | seanbright | heh |
| 18:38.38 | seanbright | JerJer? |
| 18:39.06 | Qwell | seanbright? |
| 18:39.13 | seanbright | russellb? |
| 18:40.03 | eliel | eliel? heh |
| 18:40.27 | seanbright | maybe the newt version is broken or something |
| 18:40.28 | seanbright | checks |
| 18:49.01 | Corydon76-dig | seanbright: hey, I like the curses version... in its simplicity |
| 18:49.13 | tzafrir_laptop | Why can't the dahdi firmware makefile just create /usr/lib/hotplug/firmware if none of the two firmware dirs are in place? |
| 18:49.15 | seanbright | ohhhhh |
| 18:49.17 | seanbright | gotcha |
| 18:49.27 | Qwell | tzafrir_laptop: it can't know which to create, can it? |
| 18:49.40 | tzafrir_laptop | just pick one |
| 18:49.55 | tzafrir_laptop | that works on most systems |
| 18:53.09 | JerJer | seanbright: not really a bug in my case |
| 18:53.51 | JerJer | i like to make real compact systems |
| 18:55.12 | JerJer | in other words it buggs me to no end to see every config file known to man installed on a 4 person PBX system :) |
| 18:55.45 | russellb | we should have a configs/minimal dir or something ... make samples-minimal |
| 18:56.00 | russellb | which installs the absolute minimum that lets asterisk start and modules load |
| 18:57.04 | seanbright | yeah |
| 18:57.32 | russellb | that would be neato |
| 18:57.34 | russellb | that's what i would use ... |
| 19:01.47 | eliel | It would be nice when there is a missing dependency while using menuselect, check wich one is missing. |
| 19:02.40 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:02.59 | tzafrir_laptop | Qwell, the firmware dir is something udev decides |
| 19:03.07 | tzafrir_laptop | On my system I see both are supported |
| 19:05.53 | tzafrir_laptop | centos5 aparantly supports at least /lib/firmware |
| 19:06.35 | tzafrir_laptop | So /lib/firmware sounds like the saner choice |
| 19:14.43 | *** join/#asterisk-dev mvanbaak_ (n=michiel@vanbaak.xs4all.nl) |
| 19:14.43 | *** mode/#asterisk-dev [+o mvanbaak_] by ChanServ |
| 19:19.32 | tzafrir_laptop | The samples are mostly documentation |
| 19:34.03 | tzafrir_laptop | M12160 |
| 19:34.08 | MuffinMan | [assigned] [Asterisk] Channels/chan_zap 0012160: [patch] channel alarm set when a channel is opened reported by tzafrir (Karma: +98.00) http://bugs.digium.com/view.php?id=12160 |
| 19:34.21 | tzafrir_laptop | Any chance of this getting actually resolved in Asterisk? |
| 20:00.11 | *** join/#asterisk-dev JunK-Y (n=junky@modemcable156.137-20-96.mc.videotron.ca) |
| 20:01.15 | *** join/#asterisk-dev korihor (n=korihor@201.211.168.130) |
| 20:01.18 | kpfleming | yes, it's on my plate to handle |
| 20:01.23 | kpfleming | it will be taken care of before -rc2 |
| 20:02.08 | JunK-Y | hiya guys |
| 20:02.31 | JunK-Y | how can some1 stole a car battery! |
| 20:03.15 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 20:03.41 | jpeeler | printk prints immediately right? |
| 20:03.55 | Juggie | JunK-Y, someone stole your car battery? |
| 20:04.06 | JunK-Y | Juggie: yeah! |
| 20:04.07 | *** join/#asterisk-dev Deeewayne (n=Deeewayn@216.207.245.1) |
| 20:04.07 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 20:04.19 | JunK-Y | and put shits in my oil. |
| 20:04.36 | Juggie | and put shit in your oil? |
| 20:04.37 | Juggie | like what |
| 20:04.42 | Juggie | like real shit |
| 20:04.46 | Juggie | or like other stuff |
| 20:04.51 | JunK-Y | sand or soemthing else |
| 20:04.58 | JunK-Y | car's at the garage now. |
| 20:05.02 | kpfleming | jpeeler: yes, immediately |
| 20:05.12 | Juggie | JunK-Y, did you piss someone off? :P |
| 20:05.23 | Juggie | is your gf mad at you :) |
| 20:05.26 | JunK-Y | not that i know. |
| 20:05.50 | Juggie | where was your car parked? |
| 20:06.05 | JunK-Y | in the street, like 2 min from here. |
| 20:07.09 | Juggie | nice :) |
| 20:09.22 | Qwell | JunK-Y: somebody doesn't like you... |
| 20:09.25 | JunK-Y | Juggie: are ya coming with nick to astricon? |
| 20:10.55 | tzafrir_laptop | jpeeler, it writes immediately to the kernel debug buffer |
| 20:11.16 | tzafrir_laptop | klogd gets it from there on each new line, IIRC |
| 20:11.45 | kpfleming | yes, make sure your message ends with \n if you want it to appear right away |
| 20:12.04 | jpeeler | they do... |
| 20:12.56 | jpeeler | i just can't explain dahdi_release being called too slowly after the fds are closed |
| 20:13.24 | jpeeler | and not only that, but it appears that the fds are closed in order, but dahdi_release is not called in the same order |
| 20:13.30 | kpfleming | and your standalone app doesn't exhibit the behavior? |
| 20:13.35 | jpeeler | it does not sadly |
| 20:13.40 | kpfleming | no, there won't be any guarantee they'll be closed in the same order |
| 20:13.57 | kpfleming | some background process in the kernel is handling the release calls after the last user of the fd has closed it |
| 20:15.08 | jpeeler | i don't know how it can be fixed if it is totally up to the kernel to schedule calling the release |
| 20:15.44 | kpfleming | well, the brute force way would be to retry the open calls as long as you keep getting EBUSY back |
| 20:15.51 | kpfleming | that has some downsides, but it would work around the problem |
| 20:16.01 | russellb | eep ... |
| 20:16.07 | kpfleming | or the SPECIFY ioctl, in this case |
| 20:16.26 | jpeeler | right, i might just do that and move on |
| 20:16.32 | russellb | I guess that's a more explicit fix than just a "sleep for a while and hope it was long enough" ... |
| 20:16.53 | kpfleming | yeah |
| 20:19.51 | Qwell | wasn't there some other bug where the guy said he had to do a sleep? |
| 20:20.08 | *** join/#asterisk-dev wedhorn (n=nnnnwedh@123-243-209-34.static.tpgi.com.au) |
| 20:21.03 | jpeeler | Qwell: if you're referring to the original patch for zap restart, then yes |
| 20:21.12 | Qwell | ahh, probably |
| 20:27.31 | Juggie | Qwell, did you figure out the :0 bug? |
| 20:27.38 | Qwell | Juggie: yep |
| 20:27.42 | Juggie | JunK-Y, no *-con this year |
| 20:27.44 | Qwell | it was silly |
| 20:27.47 | Juggie | i have a wedding to go to |
| 20:27.49 | Juggie | what was it |
| 20:27.58 | Qwell | a line of code that got removed |
| 20:28.03 | Qwell | the one that...sets...the port |
| 20:28.11 | Qwell | I was in the right function though! |
| 20:28.35 | jtodd | Juggie: Wedding? That's barely a reason. Send a mannequin in a tuxedo; every wedding needs a mannequin in a tuxedo. Phoenix is where you want to be. |
| 20:28.38 | Juggie | so it wasnt isolated to him it was broken across the board. |
| 20:28.47 | Juggie | jtodd, what would my gf do? :P |
| 20:28.55 | Juggie | no mannequin could replace me :) |
| 20:29.02 | jtodd | Juggie: She can come along. Send another mannequin in her place. |
| 20:29.18 | Juggie | do you have some $$$ in be budget for me? |
| 20:29.25 | Qwell | Juggie: right |
| 20:29.42 | Juggie | Qwell, weird no one else noticed |
| 20:29.58 | seanbright | yeah... thank god for falves |
| 20:29.58 | Qwell | *shrug* |
| 20:30.07 | Qwell | seanbright: don't ever say that again. |
| 20:30.12 | seanbright | heh |
| 20:30.17 | Qwell | :D |
| 20:30.31 | jtodd | Juggie: I'll buy you dinner, if that counts. |
| 20:30.52 | Juggie | digium buys everyone dinner, that doesnt make me feel special :) |
| 20:31.12 | Juggie | unless you pay then maybe.. :P |
| 20:31.19 | jtodd | Juggie: A "better" dinner somewhere else. Digium buys everyone dinner? Well, I guess if the reception thing counts... |
| 20:33.29 | Juggie | well i wish i could but sadly i cant make it... disapointing too because i was on a streak of 3 *-cons in a row. |
| 20:33.53 | Juggie | sadly, besides my personal interest i do very little with * anymore, some of my coworkers do in another department but i'm stuck doing php. |
| 20:34.22 | russellb | request a transfer! |
| 20:35.53 | Juggie | ya, i miss *, but i dont want to write ivrs so that would be danger if i transfered over. |
| 20:36.11 | russellb | picky picky |
| 20:36.20 | Juggie | i think we are rolling out a full fledged CRA IVR on * soon |
| 20:36.33 | Juggie | probally over 1000 ports once its in full swing |
| 21:02.55 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 21:20.58 | *** join/#asterisk-dev obnauticus (n=obnautic@about/windows/regular/obnauticus) |
| 21:46.17 | *** join/#asterisk-dev snuff-home (n=snuffy@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 21:56.12 | *** join/#asterisk-dev jeffspeff (i=jeff@c-68-53-54-229.hsd1.ky.comcast.net) |
| 22:05.17 | jpeeler | would it be acceptable to start all the threads in chan_dahdi with the cancelability attribute to disabled, but enable it in a safe place? |
| 22:07.23 | Corydon76-dig | jpeeler: I think it would probably be better to disable cancels manually within the thread itself when you hit a critical section |
| 22:08.01 | jpeeler | Corydon76-dig: that's fine too... but there is so much code to go through to determine where the critical sections are |
| 22:08.05 | Corydon76-dig | and then reenable cancels briefly once every cycle through |
| 22:08.10 | jpeeler | i was planning on just enabling it in one good known place |
| 22:08.52 | Corydon76-dig | How often do we cancel those threads, though? |
| 22:09.22 | jpeeler | good question, within chan_dahdi only for unloading the module, and of course the dahdi restart i'm working on |
| 22:10.26 | Corydon76-dig | Well, when the thread starts up, once it's in a known good state, you can disable the cancelability then... |
| 22:10.49 | Corydon76-dig | and then pick choice times that you can reenable the cancellability |
| 22:11.36 | Corydon76-dig | That was basically your approach, right? |
| 22:11.44 | Corydon76-dig | except for the startup time? |
| 22:12.24 | jpeeler | sure, the problem is that threads were being canceled but were still holding locks |
| 22:12.35 | jpeeler | i don't think any locks are done right at the beginning |
| 22:14.46 | jpeeler | Corydon76-dig: thanks for the input |
| 22:16.22 | Corydon76-dig | jpeeler: hopefully no thread will get stuck... :-) |
| 22:17.40 | jpeeler | it's painfully obvious when one does |
| 22:18.11 | Corydon76-dig | You know, the other way you could do this is not to use the cancellation routines at all, but a variable within the pvt structure |
| 22:18.26 | Corydon76-dig | if cancellability is screwing you up so badly |
| 22:19.03 | jpeeler | well... the end result would be the same, essentially forcing the thread to exit at one good place |
| 22:19.11 | Corydon76-dig | Check at opportune times and do pthread_exit() if the value is set |
| 22:19.36 | Corydon76-dig | True enough |
| 22:19.41 | jpeeler | or multiple places |
| 22:19.58 | jpeeler | personally i would rather do it without an additional variable, unless you think that approach is better |
| 22:20.15 | Corydon76-dig | Nah |
| 22:20.36 | russellb | (evil hack, please don't seriously do this) Or, we could use pthread_cleanup_push() instead of ast_mtuex_lock() to ensure that if you exit a thread with a lock still held, the cleanup callback will unlock it. |
| 22:20.43 | Corydon76-dig | You might want to do a macro, though, to simplify the enable/testcancel/disable, with a single line of code |
| 22:20.46 | jpeeler | russellb: i thought of that! |
| 22:20.50 | russellb | lol .. |
| 22:21.15 | russellb | nice job of thinking about the possibility :) |
| 22:21.20 | russellb | but please, let's not do that ;) |
| 22:22.02 | jpeeler | although, i would check to make sure the lock was actually held |
| 22:22.07 | jpeeler | but no, not going that way |
| 22:23.10 | Corydon76-dig | Not going there, girlfriend! <snap></snap> |
| 22:23.20 | file | oh no you didn't |
| 22:23.30 | jpeeler | Corydon76-dig: changing the cancel state is one line of code |
| 22:24.00 | russellb | oh snap |
| 22:24.07 | Corydon76-dig | jpeeler: yes, but I assume you only want to set the cancel state to enabled, then test once, then return it to disabled |
| 22:24.25 | jpeeler | oh... hmmm, might need to look closer |
| 22:24.37 | russellb | like, 4 inches from the screen closer? |
| 22:24.39 | jpeeler | in this first case, i'm using the built in cancellation point (poll) |
| 22:24.53 | jpeeler | look at the other threads |
| 22:25.02 | Corydon76-dig | There are no cancellation points when you dissable cancellability |
| 22:25.12 | jpeeler | right, but i was going to enable it there |
| 22:25.12 | Corydon76-dig | s/dissable/disable/ |
| 22:25.30 | Corydon76-dig | jpeeler: ah, okay |
| 22:26.03 | Corydon76-dig | I figured making your own cancellation points at various "safe" places was a way to go there |
| 22:26.46 | Corydon76-dig | but yeah, if you're holding no locks during the poll(), then sure. |
| 22:27.03 | jpeeler | yes, i see what you are getting at |
| 22:30.31 | jpeeler | speaking of which surrounding a call to poll by pthread_testcancel should be unnecessary |
| 22:36.39 | Corydon76-dig | Correct, on modern implementations of pthreads |
| 22:37.01 | jpeeler | not true for older ones? |
| 22:37.11 | Corydon76-dig | For an earlier version of LinuxThreads, it was not always true |
| 22:37.54 | jpeeler | that's interesting, how long ago was that? |
| 22:37.56 | Corydon76-dig | To be clear, the standard always said that kernel API calls were cancellation points, but the implementation was not always that way |
| 22:38.35 | Corydon76-dig | but, adding an explicit pthread_testcancel() is harmless |
| 22:38.51 | Corydon76-dig | Hopefully not something you'll need to worry about |
| 22:39.31 | Corydon76-dig | but something to be aware of, if you get caught in a situation where it doesn't make sense that a cancel isn't processed, it may be helpful |
| 22:39.36 | jpeeler | well i'll add it then since it's already like that in do_monitor |
| 23:03.19 | *** join/#asterisk-dev dlynes (n=dlynes@S01060016b68219f1.vs.shawcable.net) |
| 23:42.17 | *** join/#asterisk-dev obnauticus (n=obnautic@about/windows/regular/obnauticus) |
| 23:45.36 | snuff-work | anyone have ideas on that ami call to updateconfig? |
| 23:47.34 | *** join/#asterisk-dev schmooze (n=schmooze@rrcs-67-52-214-19.west.biz.rr.com) |
| 23:52.41 | dlynes | Anyone familiar with main/channel.c? |
| 23:53.00 | dlynes | The reason I'm asking is because I get the warning regularly about indication 3 not being handled |
| 23:53.29 | dlynes | I'm wondering if it's just an oversight in the code; the code in question handles indication 3 further up the chain, but not further down in the chain |
| 23:53.38 | dlynes | indication 3 is the ringing indication |
| 23:53.53 | dlynes | erm remote end ringing indication |
| 23:58.13 | *** join/#asterisk-dev obnauticus (n=obnautic@about/windows/regular/obnauticus) |