| 00:02.15 | *** join/#asterisk-dev moy (n=moyhu@189.169.69.205) |
| 01:15.51 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177585113.dsl.bell.ca) |
| 01:18.43 | *** join/#asterisk-dev schmooze (n=schmooze@rrcs-67-52-210-195.west.biz.rr.com) |
| 01:22.42 | *** join/#asterisk-dev schmooze (n=schmooze@rrcs-67-52-210-195.west.biz.rr.com) |
| 01:29.25 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.pa.comcast.net) |
| 01:40.51 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23) |
| 02:00.09 | *** join/#asterisk-dev jameswf-home (n=james@166.128.16.65) |
| 02:16.54 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.pa.comcast.net) |
| 03:16.39 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.131) |
| 03:22.18 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177583467.dsl.bell.ca) |
| 03:30.03 | *** join/#asterisk-dev jameswf-home (n=james@166.128.143.73) |
| 03:46.50 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177581963.dsl.bell.ca) |
| 04:08.35 | *** join/#asterisk-dev techie (n=techie@adsl-76-214-30-46.dsl.lsan03.sbcglobal.net) |
| 04:11.24 | *** part/#asterisk-dev sruffell (n=sruffell@adsl-074-185-078-025.sip.bhm.bellsouth.net) |
| 04:23.51 | *** join/#asterisk-dev CunningPike (n=arodgers@S010600095b33697f.vc.shawcable.net) |
| 05:35.36 | *** join/#asterisk-dev jameswf-home (n=james@ip72-223-0-183.ph.ph.cox.net) |
| 07:54.29 | *** join/#asterisk-dev Mavvie (n=edwin@ppp121-44-7-156.lns10.syd7.internode.on.net) |
| 08:12.58 | *** part/#asterisk-dev gmaruzz (n=gmaruzz@213-140-6-122.ip.fastwebnet.it) |
| 08:50.32 | *** join/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 09:12.10 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23) |
| 09:21.13 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 09:38.17 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 09:44.59 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 09:49.48 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 10:05.59 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 10:07.59 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 10:10.43 | *** join/#asterisk-dev michael-i (n=michael-@141.41.40.55) |
| 10:12.43 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 10:17.37 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 10:29.47 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.pa.comcast.net) |
| 10:42.01 | *** join/#asterisk-dev DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 10:50.38 | *** join/#asterisk-dev techie (n=techie@adsl-76-214-30-46.dsl.lsan03.sbcglobal.net) |
| 11:34.46 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.pa.comcast.net) |
| 11:52.14 | *** join/#asterisk-dev ctooley (n=ctooley@209.33.106.165) |
| 11:52.14 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 11:54.02 | *** mode/#asterisk-dev [-o ctooley] by ChanServ |
| 12:09.19 | *** join/#asterisk-dev shido6 (n=shido6@209.114.208.192) |
| 12:14.41 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-69-141-238-214.hsd1.nj.comcast.net) |
| 12:16.09 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 12:16.09 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 12:17.32 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:19.20 | russellb | good morning -dev! |
| 12:21.34 | caio1982 | friday, yeah :D |
| 12:39.39 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.137) |
| 12:59.20 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177581963.dsl.bell.ca) |
| 12:59.53 | ctooley | Alright Josh, calm down, you're getting pretty uppity aren't you. |
| 13:00.13 | ctooley | From file to partition in 2 days? What are you, swap space? |
| 13:00.29 | partition | :D |
| 13:00.33 | ctooley | russellb, morning |
| 13:00.38 | russellb | weaves |
| 13:00.44 | russellb | ... a basket |
| 13:00.51 | russellb | s/weaves/waves/ |
| 13:01.00 | ctooley | I thought maybe you'd started hitting the bottle early |
| 13:01.06 | russellb | heh |
| 13:01.13 | russellb | the orange juice bottle, maybe |
| 13:01.18 | russellb | and then the coffee ... bottle |
| 13:01.21 | ctooley | As the saying goes, "It's five o'clock somewhere" |
| 13:01.54 | ctooley | mmmmm coffee.... |
| 13:02.04 | ctooley | goes to get water for brewing another pot of coffee. |
| 13:03.26 | russellb | drinks his expensive mocha from the in building coffee shop |
| 13:07.33 | ctooley | is drinking home brewed coffee, and is sad |
| 13:08.05 | ctooley | At the first office building Unwired Buyer was in we had a very nice coffee bar area that was all complimentary. |
| 13:08.09 | ctooley | I miss it. |
| 13:10.13 | *** join/#asterisk-dev DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 13:31.19 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 13:40.10 | *** join/#asterisk-dev jeffg (i=AHIHQSwp@pdpc/supporter/active/jeffg) |
| 13:46.33 | *** join/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 13:50.05 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.207.130) |
| 13:53.51 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:53.51 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 13:59.00 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 13:59.00 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:12.26 | *** part/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 14:15.29 | *** join/#asterisk-dev Qwell (i=north@pdpc/sponsor/digium/Qwell) |
| 14:15.29 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 14:34.14 | seanbright | a mocha does not count as "coffee" |
| 14:34.26 | seanbright | unless you are wearing a sundress and pigtails |
| 14:35.10 | ctooley | attempts to purge that mental image from his brain |
| 14:35.57 | russellb | dances around |
| 14:36.32 | partition | stares at russellb |
| 14:36.43 | jsmith | seanbright: And now you're gonna tell me that cold pizza doesn't count as breakfast? |
| 14:36.52 | russellb | don't you like my hair?! |
| 14:37.01 | seanbright | jsmith: now that is just crazy talk. |
| 14:38.05 | snuff-home | mm cold pizza sooo does |
| 14:40.05 | ctooley | I know this isn't a -dev question but going into #asterisk scares me. chan_sip either does 2833 or inband for a particular peer, not both, correct? |
| 14:40.22 | Corydon76-dig | or sip info |
| 14:40.30 | russellb | or muffinDTMF |
| 14:40.44 | ctooley | right, but it's an "or" not an "and" |
| 14:40.46 | russellb | or dtmf over XML under voice over swiss cheese |
| 14:40.55 | russellb | correct, they are mutually exclusive. |
| 14:41.01 | russellb | as far as asterisk sends. |
| 14:41.04 | Corydon76-dig | Clearly, it's Friday |
| 14:41.12 | russellb | some other endpoints are stupid and send multiple methods |
| 14:41.18 | russellb | inband and info, for example |
| 14:41.20 | russellb | silly gooses |
| 14:41.29 | russellb | Corydon76-dig: clearly. |
| 14:41.32 | ctooley | but, does it parse all formats inbound? |
| 14:41.46 | russellb | i don't ... think so |
| 14:42.34 | partition | it would not... |
| 14:44.11 | russellb | unless it was friday the 1eth |
| 14:44.18 | russellb | s/eth/3th/ |
| 14:44.20 | tzanger | partition today, eh? |
| 14:44.30 | partition | yup |
| 14:45.03 | ctooley | tzanger, as I said earlier, Josh is just swap space, he can either be a file or a partition, but the system doesn't really care. |
| 14:45.26 | ctooley | although, I would expect him to be much more efficient as a partition than as a file. :) |
| 14:45.31 | Corydon76-dig | dd if=partition of=/home/tilghman/my.iso |
| 14:45.43 | partition | Permission Denied. |
| 14:46.04 | partition | is formatted as ZFS |
| 14:46.41 | ctooley | dd if=/dev/null of=partition |
| 14:46.43 | snuff-home | compresses the partition and makes into raid2z |
| 14:46.45 | ctooley | that oughtta shut him up |
| 14:46.51 | Corydon76-dig | partition: think of what you normally do to paritions... |
| 14:47.19 | partition | that depends on the filesystem :P |
| 14:47.31 | Corydon76-dig | mount -a -t zfs |
| 14:48.04 | partition | I thought you meant something else lol |
| 14:48.13 | partition | moving right along |
| 14:50.00 | putnopvut | is now known as getnopvut |
| 14:50.13 | symlink | I should move on to Linux system calls! |
| 14:52.54 | ctooley | Here's a handy nick reference then: http://64.233.167.104/search?q=cache:SueyhM7mgZgJ:www.digilife.be/quickreferences/QRC/LINUX%2520System%2520Call%2520Quick%2520Reference.pdf+Linux+system+call+reference&hl=en&ct=clnk&cd=1&gl=us&client=firefox-a |
| 14:54.13 | ctooley | #189 is a good one |
| 15:21.35 | *** join/#asterisk-dev sruffell (n=sruffell@216.207.245.1) |
| 15:21.35 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:28.06 | *** join/#asterisk-dev steliosk (n=Stelios@athedsl-27224.home.otenet.gr) |
| 15:28.45 | *** join/#asterisk-dev outtolunc (n=me@c-67-170-211-86.hsd1.ca.comcast.net) |
| 15:41.34 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.8.157) |
| 15:45.43 | *** join/#asterisk-dev joetester2 (n=joeteste@216.191.34.13) |
| 15:49.12 | *** join/#asterisk-dev tzafrir_home (n=tzafrir@bzq-179-75-202.static.bezeqint.net) |
| 15:49.12 | *** mode/#asterisk-dev [+o tzafrir_home] by ChanServ |
| 15:49.48 | tzafrir_home | hmm... that comment in the mailing list about how DOS things don't change... |
| 15:50.13 | tzafrir_home | just some news from that front, for those of you who want some nostalgia: |
| 15:50.17 | tzafrir_home | http://www.unet.univie.ac.at/~a0503736/php/drdoswiki/index.php?n=Main.HotNews |
| 15:50.19 | tzafrir_home | :-) |
| 15:51.02 | jsmith | tzafrir_home: Uh, yeah... Don't forget FreeDOS! |
| 15:51.23 | jsmith | I'll bet we have more lines of code in Asterisk than are in all of DOS though |
| 15:52.19 | tzafrir_home | asks agian: anybody got git-svn or bzr-svn working with client-side certificates authentication? |
| 15:55.13 | *** join/#asterisk-dev jtodd (n=jtodd@blob.fox-den.com) |
| 15:55.13 | *** mode/#asterisk-dev [+o jtodd] by ChanServ |
| 15:55.40 | jsmith | tzafrir_home To be honest though, I've had the conversation many times with Ward Mundy regarding API changes in general (and the ast_config_load change in particular), but he either doesn't want to listen or doesn't seem to understand |
| 15:56.49 | russellb | be careful what you say, it'll get quoted on the list |
| 15:56.55 | russellb | rolls his eyes |
| 15:57.02 | Corydon76-dig | jsmith: not really comparable, as a good number more lines of DOS need to be written in assembly |
| 15:57.07 | outtolunc | says 'shizzammmm' |
| 15:57.17 | Corydon76-dig | It is, after all, an OS, not a userspace application |
| 15:58.00 | jsmith | Corydon76-dig: I realize it's not an apples-to-apples comparison |
| 16:00.04 | symlink | my roommate was trying to play a DOS based game a few weeks ago... it didn't work on XP or Vista and I did not have anything older |
| 16:00.26 | tzafrir_home | symlink, have you tried dosbox? |
| 16:01.06 | tzafrir_home | Usually better than dosemu for games |
| 16:02.03 | ctooley | wonders if it would be possible for the FreeDOS folks to implement the necessary hooks to get it to run as a Xen installation. |
| 16:02.17 | ctooley | It's not like Xen is "tied" to linux virtualization |
| 16:02.23 | symlink | tzafrir_home: I have not |
| 16:03.32 | tzafrir_home | and it's not like DOS is a real OS |
| 16:06.19 | Corydon76-dig | notes that it's difficult to write CHANGES notes while listening to Sweeney Todd |
| 16:06.35 | symlink | Corydon76-dig: wait! what's your rush what's your hurry |
| 16:14.48 | *** join/#asterisk-dev mcargile (n=mcargile@mail.in-florida.net) |
| 16:25.04 | mvanbaak | Qwell: you here ? |
| 16:25.15 | Qwell | yes, but possibly only for a second |
| 16:25.23 | mvanbaak | ok |
| 16:25.32 | mvanbaak | can I take 12687 from you ? |
| 16:25.34 | mvanbaak | M12687 |
| 16:25.43 | MuffinMan | [assigned] [Asterisk] General 0012687: [patch] rc.debian.asterisk ubuntu 8.04 hardy reported by loloski (Karma: +3.25) http://bugs.digium.com/view.php?id=12687 |
| 16:25.47 | Qwell | go for it |
| 16:25.51 | mvanbaak | k |
| 16:26.09 | mvanbaak | it was assigned to you, so I wanted to ask before I took it ;) |
| 16:28.52 | tzafrir_home | mvanbaak, as I wrote there , I don't like the whole approach |
| 16:29.03 | tzafrir_home | But we've been through this before |
| 16:29.04 | ctooley | now understands why he wasn't getting any emails from bugs.digium.com |
| 16:29.17 | jsmith | ctooley: Why's that? |
| 16:29.42 | ctooley | because ctooley@ntrc.net isn't a valid email address for me. |
| 16:29.49 | mvanbaak | tzafrir_home: did you see my last patch ? |
| 16:30.00 | ctooley | it was 3 jobs ago when I first got my bugs.digium.com account, but no longer. |
| 16:30.05 | jsmith | ctooley: Gotcha! |
| 16:30.48 | ctooley | well, 3 jobs and about 5 companies ago. one of those companies went through 3 different names, just in the 18 months I was there. |
| 16:30.50 | tzafrir_home | mvanbaak, my issue is with the fact that we ask Asterisk rather than look for the PID file and such |
| 16:31.16 | mvanbaak | ah |
| 16:31.45 | tzafrir_home | hmm.. in 1.4 ZT_ is replaced with DAHDI_ ? I thought 1.4 should still b buildable vs. zaptel |
| 16:33.10 | tzafrir_home | jpeeler, ==^ |
| 16:33.11 | jpeeler | yeah i am wondering how that is going to work |
| 16:33.40 | russellb | using a compatible header |
| 16:33.44 | russellb | if zaptel is found and not dahdi |
| 16:33.50 | russellb | there will be a header with a bunch of #defines |
| 16:33.59 | Qwell | #define DAHDI_blah ZT_blah ? |
| 16:34.01 | russellb | from DAHDI_ to ZT_ |
| 16:34.04 | russellb | basically. |
| 16:34.21 | *** join/#asterisk-dev C4colo (n=C4colo@serenity.livewirenet.com) |
| 16:35.31 | C4colo | hello people, I'm willing to test t.38 under 1.6 anyone have any prelimenary documentation on setup, requirements, howtos, anything? |
| 16:35.31 | tzafrir_home | what about cases of '#ifdef' to check if a feature exists? |
| 16:35.32 | ctooley | have configure kick off a sed script if it finds zaptel instead of DAHDI. :) |
| 16:36.06 | Qwell | ctooley: mmm, no ;p |
| 16:36.14 | C4colo | just finished installing and configuring beta9 |
| 16:36.20 | ctooley | "hold on a minute, we're going to go hose all your headers, there's a good possibility they might even work afterwards" |
| 16:55.39 | jpeeler | why is the config file in chan_zap stored in a variable anyway? |
| 16:57.11 | putnopvut | jpeeler: I guess so that if someone wanted to store their config somewhere else, they'd have just one place in the code to change instead of potentially many. |
| 16:57.29 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 16:57.29 | jpeeler | but it's only referenced like 3 times in the same code block |
| 16:58.25 | *** join/#asterisk-dev UnixDog (n=UnixDog@254.69.118.70.cfl.res.rr.com) |
| 16:59.55 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.141) |
| 17:00.45 | jpeeler | i would think this is one thing we would really try to hard code, especially since it's done everywhere else |
| 17:00.45 | jpeeler | or at least is done frequently |
| 17:03.09 | putnopvut | jpeeler: my personal opinion is that nothing should ever be hard-coded. |
| 17:03.15 | putnopvut | Okay, not "nothing" |
| 17:04.16 | jpeeler | that just doesn't seem to be the case at least for file operations in asterisk |
| 17:04.42 | putnopvut | jpeeler: right, but that's because I wasn't consulted when those were originally written ;) |
| 17:04.49 | jpeeler | heh |
| 17:05.20 | Qwell | putnopvut: 60L |
| 17:05.32 | putnopvut | Qwell: lol |
| 17:05.34 | Qwell | just saying :P |
| 17:06.07 | putnopvut | Qwell: touche |
| 17:09.58 | tzafrir_home | Qwell, are you saying that putnopvut was consulted when Fortran was originally written? |
| 17:10.21 | putnopvut | tzafrir_home: he's referring to an ugly ugly ugly line of code in app_voicemail that I wrote. |
| 17:10.42 | Qwell | mail_parameters(NIL, SET_READTIMEOUT, (void *) 60L); |
| 17:48.37 | *** join/#asterisk-dev joetester2 (n=joeteste@216.191.34.13) |
| 17:50.09 | *** join/#asterisk-dev xrg_ (n=panos@77.83.37.53) |
| 18:02.15 | *** join/#asterisk-dev ctooley (n=ctooley@209.33.106.165) |
| 18:02.15 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 18:07.34 | *** mode/#asterisk-dev [-o ctooley] by ChanServ |
| 18:42.34 | *** join/#asterisk-dev JerJer (n=PhatJ@pdpc/supporter/bronze/jerjer) |
| 18:42.34 | *** mode/#asterisk-dev [+o JerJer] by ChanServ |
| 18:44.20 | JerJer | someone please remind me how I can determine why a load average would jump up to around 20 and stay there - yet the only thing that top (or ps aux) shows is mysql and http popping up and down with very minimal % cpu or memory usage |
| 18:45.01 | Corydon76-dig | JerJer: Linux also takes disk usage into account for load average |
| 18:45.24 | JerJer | hmm - lets see what kind of b/w is getting used |
| 18:45.26 | ctooley | Also it works on the number of processes that are waiting for the processor. |
| 18:45.34 | Corydon76-dig | It's a technical violation of the POSIX spec for load average |
| 18:45.54 | ctooley | So, just because there are tasks for the processor to do does not mean that they are tasks that can be completed. |
| 18:46.01 | Corydon76-dig | ctooley: that's load average in general |
| 18:46.26 | Corydon76-dig | It's officially defined as the average number of processes in a short wait state. |
| 18:46.31 | ctooley | Corydon76-dig, right, meaning that a load average can "spike" when the processor is actually available to handle things. |
| 18:47.08 | ctooley | Another problem with load average reporting is that it works on time slices which can be reported incorrectly. |
| 18:47.11 | Corydon76-dig | ctooley: I especially enjoy when somebody suggests that a CPU is getting more than 100% utilization... ;-) |
| 18:47.56 | Corydon76-dig | ctooley: right, it assumes that each process is using 100% of the time slot allocation |
| 18:48.21 | ctooley | Our heavily loaded prepaid servers commonly see load averages of 100 with no performance impact because the processing of RTP doesn't actually take the amount of time that the slice accounts for. |
| 18:48.27 | Corydon76-dig | See http://asterisk.drunkcoder.com/hacks/noload.c for a program which abuses that |
| 18:48.38 | ctooley | right |
| 18:48.47 | ctooley | JerJer, Those good enough reasons? |
| 18:48.49 | Corydon76-dig | I can spike a load average to 330 or so |
| 18:49.04 | ctooley | Corydon76-dig, right, with no actual performance impact |
| 18:49.10 | Corydon76-dig | Did that on one guy's machine and he freaked out |
| 18:49.45 | Corydon76-dig | "What the hell are you doing to my machine?!!" |
| 18:49.45 | ctooley | Well, I tell you what, the first time I saw one of our call servers climb over 20 I started to freak out a bit. |
| 18:50.06 | Corydon76-dig | ctooley: That was Jeremy that I did that to, actually. |
| 18:50.20 | JerJer | this particular box is a virtual server - could the 'host' limit my CPU time, which would cause a jump my load average? |
| 18:50.24 | ctooley | When we figured out there was no actual issue with that, we started doing load tests (with product calls no less :) ) and found that we could go to around 100 with no impact to the audio quality. |
| 18:50.48 | ctooley | JerJer, depends on what virtualization technology you're using. |
| 18:50.53 | Corydon76-dig | I don't know how virtual servers rate load average |
| 18:51.00 | JerJer | i think its Virtuoso |
| 18:51.11 | ctooley | doesn't know anything about Virtuoso |
| 18:51.16 | JerJer | duno for sure though - was just brought in to look at this |
| 18:51.27 | JerJer | i think its a commercial version of like openvz or xen |
| 18:51.32 | Corydon76-dig | unless it translated the host load, I can't imagine that any measurement would be at all helpful |
| 18:51.53 | ctooley | VMWare for instance has multiple different methods of "virtualizing" CPU access, some of which don't even virtualize it, they just provide direct access. |
| 18:52.14 | JerJer | well this guy got an 'abuse' report from his hosting company |
| 18:52.36 | JerJer | he was running a forum that had gotten xss attacked |
| 18:53.31 | JerJer | he killed apache - then called me... We have since had the system reloaded from a known good backup, but now the load average that is being reported is way higher than it was before |
| 18:54.06 | JerJer | so i am thinkin this virtual server is now being throttled by his provider - but i cannot prove that |
| 18:54.13 | ctooley | if it's a webserver running apache and not some "realtime" kind of application that uses small slices it's probably either excessive disk i/o or a "hidden" process that isn't being reported correctly. |
| 18:56.09 | JerJer | its a plain jane apache 2 with some php based forum running on it |
| 18:56.21 | ctooley | probably disk i/o. |
| 18:56.31 | ctooley | Or there's something else on the host that's causing the issue. |
| 18:57.00 | JerJer | and my load average is seeing it - instead of a virtualized load average |
| 18:57.02 | JerJer | ok |
| 18:57.04 | ctooley | But with it being a virtual machine the provider that has access to the host box is going to be the only source of semi-reliable information. |
| 18:57.39 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 18:59.16 | JerJer | yeah - true |
| 18:59.41 | JerJer | oh well.. i won't sweat over this then... and tell em to go get a dedicated server |
| 19:03.05 | *** part/#asterisk-dev mcargile (n=mcargile@mail.in-florida.net) |
| 19:15.32 | jpeeler | is there anywhere that is using a channel type alias already? |
| 19:16.17 | Corydon76-dig | jpeeler: there's something like that, yes |
| 19:16.32 | Corydon76-dig | in chan_sip, there are two different pvt structs |
| 19:16.56 | Corydon76-dig | for sip_info vs rfc2833 |
| 19:17.40 | Corydon76-dig | jpeeler: also see func_odbc, which registers the same routines multiple times |
| 19:26.02 | *** join/#asterisk-dev UnixDog (n=UnixDog@254.69.118.70.cfl.res.rr.com) |
| 19:29.24 | *** join/#asterisk-dev joetester2 (n=joeteste@216.191.34.13) |
| 19:31.13 | Corydon76-dig | symlink: ping |
| 19:31.19 | symlink | Corydon76-dig: pong |
| 19:31.32 | Corydon76-dig | Could you take a look at 12499 please? |
| 19:31.52 | symlink | looksees |
| 19:31.52 | Corydon76-dig | Apparently I don't know how to kill a bridge properly |
| 19:33.53 | symlink | so Aleg has a PBX structure... so it would modify the values, and then send a frame... |
| 19:34.08 | Corydon76-dig | Right |
| 19:34.29 | Corydon76-dig | So then it should kill the bridge and continue to the next place in the dialplan, right? |
| 19:35.44 | Corydon76-dig | Unless I should be using _ASYNCGOTO instead of _UNBRIDGE |
| 19:35.57 | symlink | it wouldn't... exactly... be in the bridge |
| 19:37.34 | symlink | the bridge would be broken because it is executing a feature |
| 19:38.03 | Corydon76-dig | I thought that just interrupted the bridge and then it goes back... |
| 19:38.23 | Corydon76-dig | Or, hrm, maybe it is the wrong bit to set |
| 19:38.35 | symlink | the DTMF frame gets passed up from the bridge, and the bridge ends |
| 19:39.17 | Corydon76-dig | How does it work when you e.g. monitor a conversation by feature? |
| 19:39.26 | *** join/#asterisk-dev Mw3 (n=mw3@ip59934bd1.rubicom.hu) |
| 19:39.33 | symlink | what'cha mean? |
| 19:39.41 | Corydon76-dig | It reestablishes the bridge after the feature code is called? |
| 19:39.48 | symlink | yes |
| 19:41.16 | Corydon76-dig | What I'm wondering is if the feature code uses the UNBRIDGE bit for itself |
| 19:41.29 | Corydon76-dig | and then clears it after the feature code is complete |
| 19:41.47 | symlink | I doubt it |
| 19:42.01 | symlink | ponders |
| 19:42.02 | symlink | brb |
| 19:42.13 | putnopvut | being right back is forbidden |
| 19:46.18 | symlink | fixes a bug under 1.4 he found while testing it |
| 19:52.10 | symlink | I can't actually get the issue to creep up |
| 19:52.35 | symlink | across 1.4/1.6.0/trunk both sides can activate a feature that does a Macro to ChannelRedirect the other channel to a simple Playback |
| 19:52.37 | symlink | on my system |
| 19:53.32 | symlink | unless... |
| 19:53.33 | Corydon76-dig | Maybe it's particular to the type of Zaptel channels he's using |
| 19:53.48 | symlink | look at what else they are doing in that macro |
| 19:54.05 | symlink | I see. |
| 19:54.51 | symlink | that is a bad bad thing to do |
| 19:55.05 | Corydon76-dig | which? |
| 19:55.27 | symlink | when the feature is executed the other side goes into autoservice |
| 19:55.43 | symlink | ChannelRedirect executes, but nothing happens yet as they are just sitting there |
| 19:55.53 | symlink | then the person executing the feature dials yet another destination |
| 19:56.01 | symlink | so the other side continues in autoservice |
| 19:56.40 | symlink | then once the person executing the feature hangs up the other side is taken out of autoservice and is goes on back to executing dialplan logic with the new extension/context |
| 19:56.58 | Corydon76-dig | Ah |
| 19:57.20 | symlink | doing a Dial inside of a feature like this is... ungood |
| 19:58.16 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:59.09 | Corydon76-dig | Oh... so because they're never actually exiting the feature code, the other side can't continue... |
| 19:59.16 | symlink | nods |
| 19:59.49 | symlink | now... ast_async_goto does have the capability to create a new channel, masquerade another into it, and execute a PBX on it... |
| 20:00.02 | symlink | that coulddddd possibly work |
| 20:00.17 | Corydon76-dig | but it would need to kill the autoservice first? |
| 20:00.34 | symlink | nope |
| 20:00.53 | symlink | there would just be a zombie there instead |
| 20:01.15 | symlink | I don't know how well the above would work... never thought about it |
| 20:02.31 | symlink | might be as easy as stealing the pbx pointer from the channel before calling ast_async_parseable_goto on it and then setting it back afterwards |
| 20:04.12 | Corydon76-dig | Why would the structure matter there? |
| 20:04.33 | Corydon76-dig | Doesn't that only matter if you're calling ast_pbx_run ? |
| 20:04.53 | Corydon76-dig | or the main loop, in any case? |
| 20:04.59 | symlink | ast_async_goto directly sets the extension/context/priority if chan->pbx exists because a PBX is running |
| 20:05.04 | symlink | it doesn't use the masquerade logic in that case |
| 20:05.12 | Corydon76-dig | Oh, okay |
| 20:05.19 | symlink | (as it is overkill) |
| 20:06.27 | symlink | it looks like it works... |
| 20:07.02 | *** join/#asterisk-dev smth (n=chatzill@CPE000d48380389-CM00195eda2522.cpe.net.cable.rogers.com) |
| 20:07.22 | symlink | could be an option for an instant channelredirect |
| 20:11.01 | smth | hi |
| 20:11.36 | symlink | hello |
| 20:13.17 | smth | build voicemail with IMAP . when entered voicemail box through phone call, forwarding the new message after listened it got failed. from cli, you would find 'Unable to open /var/spool/asterisk/voicemail/default/202//msg0000.txt in read-only mode' ,any idea? |
| 20:14.10 | putnopvut | smth: does that file exist when you attempt to forward the message? |
| 20:16.37 | smth | definitely .not. that I am not sure how have it be there. since when did listenning , the imap client fetch the way file from server there/tmp then it can be played. but forwarding dose seem different. |
| 20:22.41 | putnopvut | smth: that sounds like a bug to me. If you could, please file a bug on bugs.digium.com explaining what's going wrong. Thanks. |
| 20:23.03 | smth | I dont know exactly how imap works. when look into the code of voicemail.c. you will find this forwarding issue happened at copy_plain_file(xxxx) of forward_message(xxx). anybody any idea? |
| 20:23.30 | smth | ok , I will report it |
| 20:56.40 | *** join/#asterisk-dev outtolunc (n=me@c-67-170-211-86.hsd1.ca.comcast.net) |
| 20:58.49 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 20:59.10 | UnixDog | bbl |
| 21:01.21 | smth | 0putnopvut , 012764. |
| 21:02.37 | putnopvut | M12764 |
| 21:02.38 | MuffinMan | [new] [Asterisk] Applications/app_voicemail 0012764: build app_voicemail with IMAP_STORAGE .voicemessage forwording failed. reported by balsamcn (Karma: neutral) http://bugs.digium.com/view.php?id=12764 |
| 21:19.47 | CunningPike | How much of the Contact: header in a 302 message does Asterisk look at? |
| 21:21.34 | putnopvut | CunningPike: I'm looking... |
| 21:21.53 | putnopvut | The short answer is everything before the first ',' |
| 21:22.20 | CunningPike | putnopvut: Thanks - the scenario is where asterisk issues an invite to a SIP host on port 5060 and the host replies with 302, and the contact header changes only the port |
| 21:23.10 | CunningPike | So the Contact: header would be 9999@foo.com:5067, where the original invite was to 9999@foo.com:5060 |
| 21:23.23 | outtolunc | wishes dahdi_chan_name were a define somewhere <G> |
| 21:23.35 | CunningPike | When asterisk gets the 302, it dials Local/9999 |
| 21:23.58 | CunningPike | I might have to do some SER foo |
| 21:25.18 | putnopvut | CunningPike: I'm still looking to see what's actually done with the port. I see where the Contact: header is parsed and dialplan variables SIPREDIRECTURI and SIPDOMAIN are set... |
| 21:25.31 | outtolunc | nevermind.. i'm blind |
| 21:25.37 | CunningPike | putnopvut: OK - thanks! |
| 21:29.21 | CunningPike | putnopvut: I think promiscredir is the answer |
| 21:29.47 | putnopvut | CunningPike: perhaps. I'm starting to get a bit bogged down trying to trace what happens with the port in the Contact: header. |
| 21:30.53 | CunningPike | putnopvut: OK - thanks for your efforts - I think promiscredir will sort out the issue for me |
| 21:31.00 | putnopvut | Okay, cool. |
| 21:31.57 | *** join/#asterisk-dev jdjurici (n=jdjurici@78-1-168-199.adsl.net.t-com.hr) |
| 21:32.02 | jdjurici | greetings |
| 21:32.27 | jdjurici | I am doing few modifications on mgcp stack to make it fully support mgcp ncs |
| 21:32.41 | jdjurici | was wondering about one thing though |
| 21:33.05 | jdjurici | what exactly this defines: MGCP_MAX_HEADERS |
| 21:33.53 | russellb | it's the length of an array that holds the headers of a parsed incoming mgcp message |
| 21:34.41 | jdjurici | ok basically how much endpoints can mgcp stack handle? |
| 21:35.02 | jdjurici | I hope it's not related with this value |
| 21:35.05 | russellb | no |
| 21:35.11 | russellb | it has nothing to do with that |
| 21:35.51 | jdjurici | anyone has any scaling numbers on current mgcp stack? |
| 21:36.04 | russellb | not that i know of |
| 21:36.24 | jdjurici | also when I finish this implementation, and for know the signalling part works perfect |
| 21:36.39 | jdjurici | would you include it in future releases? |
| 21:36.51 | russellb | i can't promise that |
| 21:36.58 | russellb | but i can promise that it will be reviewed and considered :) |
| 21:37.03 | russellb | just post it on http://bugs.digium.com |
| 21:37.07 | jdjurici | great :p |
| 21:37.42 | jdjurici | yeah well need to finish few more things first, definetely add digit map part to it... |
| 21:38.32 | Qwell | jpeeler: the change in app_chanspy may not be quite correct |
| 21:38.56 | Qwell | it's still doing an strncmp of 10 chars |
| 21:39.09 | jpeeler | yeah i noticed that |
| 21:39.34 | jdjurici | russelb: great, talk with you soon |
| 21:39.40 | russellb | waves |
| 21:39.40 | jdjurici | enoy eveyone |
| 21:39.49 | *** part/#asterisk-dev jdjurici (n=jdjurici@78-1-168-199.adsl.net.t-com.hr) |
| 21:40.03 | jpeeler | Qwell: i was hoping the remaning 4 characters would still be enough to make a confident match |
| 21:40.13 | Qwell | should be |
| 21:40.23 | Qwell | until somebody tries to use DAHDIISAWESOME/pseudo |
| 21:40.54 | jpeeler | well, the channel name is only going to DAHDI or Zap |
| 21:48.42 | russellb | Corydon76-dig: ping |
| 21:48.55 | *** part/#asterisk-dev hubguruJR (n=hubguruJ@mail.ntegratedsolutions.com) |
| 21:48.57 | CunningPike | putnopvut: Yup - promiscredir did it |
| 21:49.00 | CunningPike | Thanks for checking |
| 21:49.09 | putnopvut | CunningPike: heh, I didn't really do anything :) |
| 21:49.19 | CunningPike | Moral support ;) |
| 21:49.36 | Corydon76-dig | pong |
| 21:50.05 | Corydon76-dig | russellb: pong |
| 21:50.12 | russellb | nm, fixed it :-p |
| 21:50.20 | Corydon76-dig | Mmm? |
| 21:50.28 | russellb | had trouble with your merge of the lock tracking changes |
| 21:50.34 | russellb | linkage error |
| 21:50.36 | russellb | got it though |
| 21:50.39 | Corydon76-dig | Ah |
| 21:59.07 | ctooley | It's Friday, it's an absolutely beautiful day, I'm sitting on the deck, and I just cracked open the first beer, later guys |
| 21:59.47 | russellb | cya |
| 22:01.00 | jsmith | ctooley: I hope you start laughing and beer comes out your nose |
| 22:01.13 | jsmith | ctooley: Have a great weekend! |
| 22:04.54 | *** join/#asterisk-dev RoyK (n=Roy@91.149.43.201) |
| 22:04.57 | Corydon76-dig | beer snot? |
| 22:14.59 | jsmith | ~entertain Corydon76-dig |
| 22:15.00 | jbot | ACTION shows Corydon76-dig a real live elephant while tap dancing |
| 22:16.27 | smth | nice weekend all ;) |
| 23:20.36 | *** join/#asterisk-dev russellb (n=russellb@asterisk/developer-and-stable-maintainer/drumkilla) |
| 23:20.38 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 23:29.55 | lmadsen | ~entertain jsmith-away |
| 23:29.56 | jbot | ACTION shows jsmith-away a pink elephant while scuba diving on black and white movie reels |
| 23:49.27 | *** join/#asterisk-dev jameswf-home (n=james@ip72-223-0-183.ph.ph.cox.net) |