| 00:00.04 | Corydon76-dig | $21 before next Tuesday or $25 at the door |
| 00:00.21 | putnopvut | That's not bad at all. |
| 00:00.42 | putnopvut | Plus I guess a hotel room, too. |
| 00:00.45 | Corydon76-dig | For a con, it's one of the least expensive in the nation |
| 00:00.53 | Corydon76-dig | Right... $80/night including tax |
| 00:01.03 | putnopvut | Per person or per room? |
| 00:01.07 | Corydon76-dig | per room |
| 00:01.16 | putnopvut | Ooh. So I could share and save! |
| 00:01.22 | Corydon76-dig | Indeed |
| 00:01.35 | putnopvut | Wow. So that won't break the bank at all. |
| 00:01.40 | Corydon76-dig | mog might go, as well |
| 00:02.32 | Corydon76-dig | brimstone and I-MOD have both preregistered, so I know they're going... but I only talked to mog yesterday about it. |
| 00:03.15 | Juggie | mog missed out on *-con |
| 00:04.17 | JunK-Y | Juggie: nick too, since he was drunk like hell :) |
| 00:04.48 | putnopvut | JunK-Y: nick put up a picture of me on the astricon flickr page titled "Digium at it's best" |
| 00:04.54 | putnopvut | What does that mean? |
| 00:04.55 | mog | im going |
| 00:05.00 | mog | if i can convince the wife |
| 00:05.18 | putnopvut | mog: the back of your hand is always a convincing argument ;) |
| 00:05.47 | mog | woah |
| 00:06.09 | Corydon76-dig | mog: bring her with you... we can watch yaoi... |
| 00:06.20 | putnopvut | oh jeez |
| 00:06.24 | JunK-Y | putnopvut: probably cause ur vodka bottle! |
| 00:06.42 | Corydon76-dig | Hey, wow, putnopvut knows what yaoi is, too |
| 00:06.44 | mog | hah Corydon76-dig |
| 00:06.55 | putnopvut | Corydon76-dig, you explained to me at astridevcon. |
| 00:06.59 | Corydon76-dig | Oh, heh |
| 00:07.08 | Corydon76-dig | Good memory. ;-) |
| 00:08.52 | Corydon76-dig | Well, I should go eat something before House comes on |
| 00:09.55 | putnopvut | I'm getting the hunger bug too |
| 00:16.54 | JunK-Y | back to reality, homeworks! |
| 00:37.14 | *** join/#asterisk-dev Qwell_ (n=north@pdpc/sponsor/digium/Qwell) |
| 00:37.14 | *** mode/#asterisk-dev [+o Qwell_] by ChanServ |
| 00:51.55 | *** join/#asterisk-dev fakhir (n=Fakhir@unaffiliated/fakhir) |
| 00:57.58 | *** join/#asterisk-dev ManxPower (n=manxpowe@64.246.207.186) |
| 01:07.48 | blitzrage | hrmmm.... House? I should get the TV setup then |
| 01:24.28 | OzyWebMaster | hello, anyone interested in developing an "Email to Fax" solution and "SMS" solution |
| 01:24.35 | OzyWebMaster | It is paid work for the contract |
| 01:24.58 | OzyWebMaster | the email to fax must look at mysql for user authentication, and bill accordingly into the cdr table |
| 01:25.29 | OzyWebMaster | very much like the AsterFax solution, however it would not be limited to one channel like their unlicensed ver |
| 01:27.26 | tzanger | woot |
| 01:29.03 | OzyWebMaster | ? |
| 01:32.39 | Damin | Well, the DTMF testing has verified that the issue is not within Asterisk, but somewhere between the PRI and the Switch.. |
| 01:33.05 | Damin | I.E. we are generating the correct DTMF tones out of the PRI.. |
| 01:33.27 | Damin | Is there a way to snarf the actual ULAW audio being generated by the DTMF encoders on the PRI? |
| 01:33.38 | Damin | Like some sort of "tcpdump" for Zaptel? |
| 01:34.02 | ManxPower | Damin: Monitor and MixMonitor is not good enough? |
| 01:37.39 | Damin | ManxPower: Yeah.. that will work.. |
| 01:38.32 | Damin | ManxPower: Thanks.. |
| 01:40.31 | tzanger | Damin: I have a util like that |
| 01:40.36 | tzanger | it's for TDMOE though :-) |
| 01:40.48 | tzanger | oh wait, it's called wireshark :-) |
| 01:43.27 | *** part/#asterisk-dev mog (n=mog@c-71-207-200-130.hsd1.al.comcast.net) |
| 01:49.40 | *** join/#asterisk-dev putnopvut (n=putnopvu@user-24-214-112-81.knology.net) |
| 01:49.40 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 02:31.07 | ManxPower | Is there any chance of changing this message "[Oct 2 22:47:49] WARNING[10473]: chan_zap.c:11117 process_zap: Ignoring switchtype" to something like "[Oct 2 22:47:49] NOTICE[10473]: chan_zap.c:11117 process_zap: Changing switchtype not supported on a reload, ignoring any changes to switchtype" |
| 02:31.22 | ManxPower | change from a warning to a notice and have a clearer message |
| 02:36.27 | *** join/#asterisk-dev Qwell_ (n=north@pdpc/sponsor/digium/Qwell) |
| 02:36.27 | *** mode/#asterisk-dev [+o Qwell_] by ChanServ |
| 02:40.40 | *** part/#asterisk-dev putnopvut (n=putnopvu@user-24-214-112-81.knology.net) |
| 02:42.19 | tzanger | indeed |
| 02:42.32 | tzanger | I always liked "Oh Canada, wheeze tendon guard for thee!" |
| 02:45.05 | Juggie | he doesnt make fun of canadians anymore |
| 02:48.52 | Juggie | we fixed him |
| 02:48.59 | Juggie | now he can only make fun of french canadians |
| 02:49.43 | Qwell_ | no, but I can :D |
| 02:52.44 | tzanger | heh |
| 02:56.26 | *** join/#asterisk-dev IgorG (n=FeedomPa@195.162.32.126) |
| 03:07.28 | *** join/#asterisk-dev IgorG (n=FeedomPa@195.162.32.126) |
| 03:13.58 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 03:13.58 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 03:14.08 | russellb | any problems come up with 1.4.12? |
| 03:17.08 | Juggie | russellb, will roll it out tomorow probally to our prod servers. |
| 03:17.24 | russellb | awesome |
| 03:17.32 | russellb | just making sure nothing blew up so far .. |
| 03:17.47 | russellb | guess we'll see tomorrow when more people start installing it |
| 03:17.53 | russellb | should be fine, though :) |
| 03:22.15 | *** join/#asterisk-dev CunningPike (n=CunningP@S010600095b33697f.vc.shawcable.net) |
| 03:28.39 | *** join/#asterisk-dev fakhir (n=Fakhir@unaffiliated/fakhir) |
| 03:30.36 | *** join/#asterisk-dev ZX81 (n=matt@202.49.106.158) |
| 05:23.14 | *** join/#asterisk-dev outtolunc (n=me@c-67-174-216-60.hsd1.ca.comcast.net) |
| 05:30.32 | snuff-work | tzafrir: with zaptel... if you install completely fresh, do make/make install/make config .. it doesn't seem to also copy over 'zaptel.conf' if there is none existing |
| 05:34.15 | snuff-work | or could we add warnings to the init script saying 'telephony=yes' not found.. 'etc/zaptel.conf' not found.. so people know what's wrong other than the script just quitting early |
| 05:53.30 | *** join/#asterisk-dev Corydon76-home (i=black@pdpc/supporter/bronze/Corydon76-home) |
| 05:53.30 | *** mode/#asterisk-dev [+o Corydon76-home] by ChanServ |
| 06:04.37 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 06:04.37 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:05.06 | oej | Morning folks |
| 06:11.36 | blitzrage | oej: !!! |
| 06:12.09 | oej | Hello there Leif. |
| 06:12.30 | oej | ...or good night :-) |
| 06:16.53 | *** join/#asterisk-dev Corydon76-dig (n=tilghman@pdpc/supporter/bronze/Corydon76-home) |
| 06:16.53 | *** mode/#asterisk-dev [+o Corydon76-dig] by ChanServ |
| 06:20.45 | blitzrage | oej: oh I'm on Pacific time, so I'll be up for a couple more hours |
| 06:20.59 | oej | California? |
| 06:21.01 | blitzrage | indeed |
| 06:21.06 | blitzrage | although I'm in Toronto |
| 06:21.11 | oej | Or have you just migrated in a personal time zone? |
| 06:21.12 | blitzrage | I just got back from a month of driving across N.A. |
| 06:21.22 | oej | That sounds like a lot of fun |
| 06:21.24 | oej | Bike? |
| 06:21.39 | blitzrage | Toronto -> Vancouver -> San Francisco -> Las Vegas -> Phoenix (AstriCon) -> Toronto |
| 06:21.47 | blitzrage | drove with my friend Paula in my parents van |
| 06:22.38 | oej | Sounds like a great drive |
| 06:24.11 | blitzrage | ya, 12,000 km's or so |
| 06:24.14 | blitzrage | it was super fun |
| 06:24.18 | blitzrage | just got back yesterday |
| 06:51.31 | oej | Cool |
| 06:51.40 | oej | I just got back from Norway yesterday. |
| 06:51.47 | oej | Trying to get used to airplanes again |
| 06:51.56 | oej | Still working part time, trying to recover |
| 07:10.28 | blitzrage | ya I heard your back was really bothering you |
| 07:37.06 | *** join/#asterisk-dev jmls (n=jmls@62.49.235.130) |
| 07:48.28 | *** join/#asterisk-dev Corydon76-dig (i=beige@pdpc/supporter/bronze/Corydon76-home) |
| 07:48.28 | *** mode/#asterisk-dev [+o Corydon76-dig] by ChanServ |
| 07:48.44 | *** join/#asterisk-dev Corydon76-home (i=gold@pdpc/supporter/bronze/Corydon76-home) |
| 07:48.44 | *** mode/#asterisk-dev [+o Corydon76-home] by ChanServ |
| 08:27.31 | *** join/#asterisk-dev qdk_ (n=qdk@85.235.253.139) |
| 08:30.58 | jmls | yay! adsl connection was down for 14 hours :( |
| 08:31.10 | jmls | so, what did I miss ?? |
| 08:49.18 | *** join/#asterisk-dev kay2 (n=two@gob75-7-82-247-113-230.fbx.proxad.net) |
| 09:15.44 | *** join/#asterisk-dev wyoming (n=steve_mu@216.166.159.235) |
| 09:25.13 | *** join/#asterisk-dev qdk (n=qdk@85.235.253.139) |
| 09:32.54 | snuff-away | jmls.. 1.4.12 |
| 09:33.01 | snuff-away | rls :) |
| 09:33.26 | *** join/#asterisk-dev codefreeze (n=steve_mu@216.166.159.235) |
| 09:33.26 | *** mode/#asterisk-dev [+o codefreeze] by ChanServ |
| 09:44.23 | jmls | hah |
| 10:12.18 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-12-187.bredband.comhem.se) |
| 11:40.35 | *** join/#asterisk-dev tsurko (n=tsurko@78.90.100.214) |
| 11:41.50 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:53.35 | *** join/#asterisk-dev tsurko (n=tsurko@78.90.100.214) |
| 12:47.17 | *** join/#asterisk-dev jsmith (n=jsmith@000-249-242.area3.spcsdns.net) |
| 12:47.17 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 12:58.22 | *** join/#asterisk-dev lbow (n=lbow@dsl-146-5-201.telkomadsl.co.za) |
| 13:07.16 | *** join/#asterisk-dev Laureano (n=chatzill@200.59.172.38) |
| 13:18.33 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.157.180) |
| 13:35.08 | *** join/#asterisk-dev putnopvut (i=putnopvu@nat/digium/x-aedda85069469ecb) |
| 13:35.08 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:35.57 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 13:35.57 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 13:47.30 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 13:47.30 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:48.01 | oej | Afternoon, folks |
| 13:50.10 | file | how is oej? |
| 13:50.58 | oej | slowly getting better |
| 13:51.01 | oej | And you, sir? |
| 13:51.41 | file | I am... well rested |
| 13:53.06 | oej | Good for you. Please start hacking then :-) |
| 13:53.14 | *** join/#asterisk-dev ctooley (n=ctooley@209.33.109.249) |
| 13:55.36 | file | yes sir! |
| 13:56.42 | jsmith | oej: How's your back doing? |
| 13:57.00 | oej | Still hurting, need to get some new needles inserted :-) |
| 13:57.05 | oej | But it's getting better slowly |
| 13:57.16 | oej | I've been able to fly to Norway (one hour) so it |
| 13:57.21 | oej | is an improvement... |
| 13:58.08 | jsmith | oej: I'm glad to hear it's getting better... we've been worried about you |
| 13:58.29 | jsmith | oej: Everyone at AstriCon missed you, and was sad to hear you're in pain |
| 13:59.08 | oej | Thank you |
| 13:59.14 | oej | I really wanted to be there |
| 13:59.25 | oej | My goal now is to train a lot so I can attend Von Boston |
| 13:59.42 | jsmith | Yeah... I hope you can make it |
| 13:59.45 | ctooley | oej, see my PM, I might be able to help you with that. |
| 14:00.40 | oej | ...and maybe visit the new Empire office in Huntsville... :-) |
| 14:15.11 | oej | Hmm. Gotta re-configure my IP phones and re-install video phones. |
| 14:15.13 | putnopvut | All right. oej and file are both in the room. This is a good opportunity to do some chan_sip talk. I'm looking at issue 10868 (related to 9921 and 9431). The basic idea is to get Asterisk to respond per rfc 3261 to a 491 response on a reinvite. |
| 14:15.19 | *** join/#asterisk-dev tsurko (n=tsurko@213.91.216.130) |
| 14:15.44 | putnopvut | If you check out the end of section 14.1, it describes what a UAC should do when it receives a 491. |
| 14:16.27 | putnopvut | Now, the first issue that comes up from this is that we're supposed to set a timer based on who "owns" the call-id of the dialog. Is there a way in chan_sip currently to tell who owns the call-id? |
| 14:17.00 | putnopvut | Or more simply, is there a way of telling that we generated the call-id? |
| 14:17.36 | oej | The general policy is that file owns all SPIT calls and I own the rest, world-wide. |
| 14:17.41 | oej | We're in control and beware of us. |
| 14:17.43 | file | :D |
| 14:17.43 | oej | :-) |
| 14:17.49 | file | putnopvut: there is a flag to know whether the call is outgoing or not |
| 14:18.08 | De_Mon | I found out that those numbers I can't call from asterisk are outsourced to M5net, a full service voip provider |
| 14:18.19 | oej | Update please: 491 is what? please hold? |
| 14:18.36 | file | oej: Request Pending |
| 14:19.12 | oej | There's another one we need to solve in the same hack then. Hmmm. |
| 14:19.29 | oej | I tried hacking support for that, but it turned out to be way too ugly and did not work |
| 14:20.20 | oej | Let's say you have a dial string in the dial plan with a 10 second timer. I couldn't reach that timer and see whether I had time to stay put. If a device sends a retry-after: 15 it means that we have to wait 15 seconds |
| 14:20.40 | oej | So all of those are connected, retry-after and 491 with retry-after |
| 14:21.45 | putnopvut | file: so how do I interpret that flag? |
| 14:22.00 | putnopvut | If it's outgoing, does that mean we generated the call-id or not? |
| 14:22.02 | oej | That flag keeps changing, it's really bad |
| 14:22.07 | putnopvut | oi |
| 14:22.09 | oej | Unless that has been fixed. |
| 14:22.13 | file | oej: I fixed it |
| 14:22.18 | oej | THanks then |
| 14:22.39 | oej | Re-invites used to change direction of the call |
| 14:22.55 | Qwell | speaking of the new empire office... |
| 14:22.56 | file | putnopvut: if the flag is set we created the call-id |
| 14:23.03 | oej | Right |
| 14:23.03 | Qwell | I need to figure out how to get there O.o |
| 14:23.13 | file | SIP_PAGE2_OUTGOING_CALL |
| 14:23.34 | oej | If we get 491, we sent the invite and then we created the call ID if the outbound flag is set. Otherwise if we get a 491, we get it on a re-invite and we're in hell. |
| 14:23.41 | oej | We have to cancel the call, basically |
| 14:24.33 | putnopvut | Canceling the call is what's in the code already. I'm trying to avoid that scenario. |
| 14:25.20 | oej | Well, if we get a 491 on the *first*invite and get a retry after you have to check the dial timeouts to see if there's any chance of a retry. |
| 14:25.34 | oej | And I don't really know what status to set for the channel and the dialog |
| 14:25.40 | putnopvut | I need to look into what you mean by retry after. |
| 14:26.10 | oej | A lot of error messages add a retry-after header indicating that you should not even bother with trying again before that. |
| 14:26.24 | putnopvut | Ah, okay. |
| 14:26.25 | oej | Could be "internal server error" because of overload |
| 14:26.32 | oej | And you need to solve them all with one hack |
| 14:27.53 | putnopvut | So this has suddenly gotten more complicated. |
| 14:28.25 | file | unsurprising. |
| 14:29.23 | oej | Welcome to the SIP club! |
| 14:29.28 | putnopvut | yay |
| 14:29.48 | ctooley | YEAH SIP ROCKS! |
| 14:29.50 | De_Mon | oej, have you had a chance to look at the new notes on 8078? |
| 14:29.51 | file | please leave your sanity at the door |
| 14:29.59 | putnopvut | Okay, so this whole "retry after" thing. Can this be sent with any final response or is it only on 5xx responses? |
| 14:30.35 | oej | It gets messy with the timers for retransmit, since you have to cancel retransmits, put the dialog on hold while waiting so that the monitor thread doesn't do anything ugly and then start all over again. I guess you have to change call ID since you got a final response, but that has to be checked properly. |
| 14:30.53 | oej | Oh, you can get it on REGISTER, INVITE, SUBSCRIBE... |
| 14:31.07 | oej | And with a lot of the 4xx, 5xx and 6xx responses. |
| 14:31.10 | oej | Congratulations! |
| 14:33.06 | ctooley | See oej, by comparison my 300 Multiple Choice might be simple. :) |
| 14:33.29 | De_Mon | the more I stare, the more I think i should have opened a new ticket... |
| 14:34.47 | putnopvut | In the case of a 491, I don't believe you have to change the call-id. It sounds like you send the exact same packet as you did previously. |
| 14:37.41 | oej | Remember you got a final reply. At least you have to change Cseq to start a new transaction. The question here is if the dialog state is still there or if the dialog is done and should be killed... |
| 14:38.39 | putnopvut | RIght |
| 14:45.59 | oej | And the big issue I failed to sort out, and reverted my earlier patches, was how to get it properly integrated into the channel timers and the dial() timers... |
| 14:48.49 | Juggie | oej! |
| 14:53.12 | oej | Yes, it's me and not a proxy! |
| 14:53.32 | Corydon76-dig | It's you and not a B2BUA! |
| 14:53.43 | Juggie | oej, how is the back? |
| 14:54.05 | oej | Still there, hanging around, making itself noticed... |
| 14:54.13 | oej | Getting better though, thanks for asking. |
| 14:54.19 | Juggie | would have liked to see you @ astricon! :( |
| 14:54.51 | oej | The same! |
| 14:54.54 | Juggie | the code zone was in desperate need of oej & redbull. |
| 14:56.57 | oej | I saw some notes from jtodd that indicated that :-) |
| 14:57.18 | Juggie | meh, it was mostly distance. |
| 14:57.25 | Juggie | everyone was far far from it |
| 14:59.17 | ctooley | I wasn't far from it. Neither were jsmith or blitz. It was right down the road. :) |
| 14:59.26 | ctooley | There just wasn't much happening. |
| 14:59.56 | Juggie | that isnt everyone |
| 15:00.03 | Juggie | alot of people were @ the main building |
| 15:00.10 | ctooley | right, but not "everyone". :) |
| 15:00.28 | ctooley | The Villas were nice, but if you weren't in one, it was a hell of a haul down to the code zone |
| 15:01.54 | ctooley | I think that resort would have been a much better place to take my wife on vacation than it was for the conference. But, we all know the coordinators were kind of stuck when the Renaissance didn't get done. |
| 15:02.18 | Juggie | yah |
| 15:02.31 | Juggie | it was even far if you were in one |
| 15:02.32 | file | what's done is done, the past is the past |
| 15:05.14 | *** join/#asterisk-dev _mihai_ (n=_mihai_@x42073b02.ip.e-nt.net) |
| 15:05.42 | ctooley | file, you got something done? |
| 15:05.45 | De_Mon | those who do not remember the past are dooomed to repeat it |
| 15:05.47 | *** join/#asterisk-dev qdk (n=qdk@0x573fe57e.bynqu2.broadband.tele.dk) |
| 15:05.51 | _mihai_ | Hi all |
| 15:06.00 | Juggie | _mihai_, more bugs? :P |
| 15:06.36 | _mihai_ | nah, just hanging out... :) |
| 15:06.59 | Juggie | we get scared when you come in here yo know |
| 15:07.09 | Juggie | *you |
| 15:07.37 | *** join/#asterisk-dev nicchap (n=nicchap@www.trn.ca) |
| 15:07.53 | _mihai_ | why, I thought I'm such a nice person .... :) |
| 15:08.02 | oej | I had a bottle of Red Bull here, just to get the code zone feeling |
| 15:08.08 | Qwell | oej: bottle? |
| 15:08.28 | Qwell | like, glass bottle? |
| 15:08.42 | oej | sorry, a can |
| 15:08.46 | Qwell | oh |
| 15:08.53 | oej | We don't get it in proper bottles here either |
| 15:08.54 | Qwell | I was gonna say - I want one |
| 15:09.22 | _mihai_ | Juggie: anyways, happy to say that 1.4.12 behaves... so far at least |
| 15:09.35 | *** join/#asterisk-dev dlynes (n=dlynes@d154-20-9-152.bchsia.telus.net) |
| 15:11.42 | putnopvut | _mihai_: yay! |
| 15:16.10 | *** join/#asterisk-dev miguel3239 (n=elguerom@h-68-167-124-171.cmbrmaor.covad.net) |
| 15:16.12 | *** join/#asterisk-dev fakhir (n=Fakhir@unaffiliated/fakhir) |
| 15:16.24 | oej | I just got a facebook drink. I won't be responsible for anything I say any more today. Blame file :-) |
| 15:23.05 | Juggie | where is cresl1n when you needh im |
| 15:38.04 | *** join/#asterisk-dev SimonPerreault (n=SimonPer@ringo.viagenie.ca) |
| 15:38.29 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 15:39.05 | *** join/#asterisk-dev joetester (n=joeteste@216.191.34.13) |
| 15:39.31 | SimonPerreault | anyone know what's causing this gdb error? |
| 15:39.32 | SimonPerreault | Breakpoint 2, 0x00002aaaaab377c8 in sip_poke_peer (peer=0x3753d4c960) |
| 15:39.32 | SimonPerreault | <PROTECTED> |
| 15:39.32 | SimonPerreault | (gdb) n |
| 15:39.32 | SimonPerreault | Single stepping until exit from function sip_poke_peer, |
| 15:39.32 | SimonPerreault | which has no line number information. |
| 15:39.45 | SimonPerreault | i did compile with DONT_OPTIMIZE |
| 15:39.56 | SimonPerreault | also I verified with NOISY_BUILD that -g3 is enabled |
| 15:40.27 | joetester | Hi all |
| 15:40.35 | SimonPerreault | another thing: when I use the "info sources" command in gdb, I don't see the chan_sip.c file |
| 15:40.53 | SimonPerreault | it worked before! (before what, I don't know) |
| 15:41.26 | SimonPerreault | could memory corruption be causing this? like, writing all over gdb's structures? |
| 15:43.38 | Juggie | Simon! |
| 15:44.19 | SimonPerreault | ! |
| 15:44.32 | SimonPerreault | who,s that? |
| 15:44.47 | Juggie | Donny, nic's friend. |
| 15:44.52 | Juggie | claude's friend. |
| 15:44.52 | SimonPerreault | ah, donny! |
| 15:44.54 | SimonPerreault | hey |
| 15:45.08 | Juggie | bonjour! |
| 15:45.33 | *** join/#asterisk-dev flujan (n=flujan@200-160-115-020.static.spo.ctbc.com.br) |
| 15:46.11 | SimonPerreault | i have memory corruption all over the place and can't do anything aboutit |
| 15:46.25 | Juggie | SimonPerreault, did you try running memtest86 on the system? |
| 15:46.31 | Juggie | to make sure the ram isnt bad |
| 15:46.33 | SimonPerreault | ha, the system is fine |
| 15:46.38 | *** join/#asterisk-dev tsurko (n=tsurko@213.91.216.130) |
| 15:46.59 | SimonPerreault | see, I played a lot with the code so chances are something is broken |
| 15:47.04 | De_Mon | classic denial |
| 15:47.20 | Juggie | did you try a full make clean, and a rebuild? |
| 15:47.27 | SimonPerreault | yup |
| 15:47.40 | SimonPerreault | De_Mon, you know Occam and his razor? |
| 15:47.42 | Juggie | i get weird errors sometimes that go away after a make clean; make. |
| 15:48.57 | flujan | hi guys, I already set it on the asterisk channel... I am coming here to specify this behavior and maybe fill a wish report or something like that. :) |
| 15:48.59 | flujan | I need to implement this behavior on asterisk: if the queue agent is on a call do not try to place a second call to it. When I set the call-limit to 1 it works flawless... I had have the incoming calls delivered in less than one second. |
| 15:49.37 | flujan | Now, I have a problem. People from the first level, answers the call and tries to solve the problem. If then do not know how to solve the caller problem, they put the call on hold and call the second level for help. The issue is that if I set the call-limit to 1 I lost this behavior. |
| 15:49.52 | flujan | Does asterisk 1.4.12 and the changes in app_queue.c solve this issue? Or how can I avoid this issue? I was checking the app_queue.c code and see some places where they change a bit of code... At least in the try_calling function. If it is not support in asterisk now, I can use some help to develop a patch and address this "issue" of mine. |
| 15:50.46 | putnopvut | flujan: that is not something that has been addressed in app_queue at this point. |
| 15:50.49 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.12.183) |
| 15:50.59 | flujan | I am fighting with this issue for a long time... I am also considering to ask people from counterpath do develop a incoming and outgoing call-limit on the softphone I am using in order to solve this issue. |
| 15:51.28 | flujan | putnopvut: do you think it can come as a option to queues? |
| 15:51.49 | De_Mon | putnopvut could you translate for me? I don't get it |
| 15:51.53 | Juggie | simon, if you are looking for a new computer, dell has a awesome deal on today: http://click.linksynergy.com/fs-bin/click?id=CAqD7bLWUPI&offerid=130350.612269084&type=10&subid= |
| 15:52.01 | putnopvut | It may be possible. |
| 15:52.16 | putnopvut | De_Mon: translate? you mean what the issue is? |
| 15:52.26 | De_Mon | oh, if you put someone on hold, you can'd dial out because you're limited to 1 call? |
| 15:52.35 | SimonPerreault | Juggie, cheap, but that would actually be a downgrade ;) |
| 15:52.46 | Juggie | SimonPerreault, nice :) |
| 15:52.59 | putnopvut | De_Mon: yes, that's it. |
| 15:53.04 | Juggie | i've yet to use a core2duo. |
| 15:53.10 | Juggie | still using all 3ghz p4's |
| 15:53.13 | flujan | De_Mon: yes... it is it... But the issue is that if I leave a call-limit up to 2 asterisk take at least 10 seconds to deliver a call... |
| 15:53.30 | flujan | De_Mon: it tries to deliver the call to agents that is already on a call. |
| 15:54.03 | flujan | flujan: I someone is capable of developing it... My company can spent some money on this feature. |
| 15:54.06 | De_Mon | in your soft phone, you could always register multiple extensions |
| 15:54.16 | De_Mon | accounts, whatever they call them |
| 15:54.40 | De_Mon | you want to set a inbound call limit and a separate outbout call limit |
| 15:54.42 | putnopvut | flujan: I would think this would be doable in app_queue. the problem is that this would not be something available for 1.4 since it definitely qualifies as a new feature. |
| 15:55.09 | flujan | De_Mon: yeap... but I do not want to have this behavior. On the legacy pbx we have this issue working. |
| 15:56.32 | De_Mon | have you messed with busy-limit? |
| 15:56.52 | *** join/#asterisk-dev bkruse_home (n=bkruse@69.73.127.92) |
| 15:56.58 | De_Mon | I haven't really used anything other than call-limit myself |
| 15:58.40 | De_Mon | setting call-limit to 2 and busy-limit to 1 seems like it would do just what you describe |
| 15:59.26 | De_Mon | for lack of a better source, http://lists.digium.com/pipermail/asterisk-commits/2007-February/011119.html |
| 16:07.53 | SimonPerreault | I RULE! |
| 16:08.10 | SimonPerreault | i'm a lean, mean, bug-fixing machine |
| 16:08.31 | *** join/#asterisk-dev elixer (i=elixer@65.207.74.18) |
| 16:08.56 | *** join/#asterisk-dev HarryR (n=harryr@77.240.56.17) |
| 16:09.21 | HarryR | Asterisk is disconnecting my FastAGI script (via DeadAGI) after a Dial() when either party hangs up |
| 16:10.22 | Juggie | 1.4 or trunk |
| 16:10.58 | HarryR | oh stupid me, i'll try 1.4 first |
| 16:11.06 | flujan | De_Mon: thanks for the tip,. I will check it. |
| 16:11.12 | Juggie | none the less, answer my question? |
| 16:11.25 | De_Mon | does deadagi exist in 1.4? |
| 16:11.25 | HarryR | 1.2.17 :\ |
| 16:11.32 | Juggie | De_Mon, yes. |
| 16:11.45 | HarryR | Sorry, I thought my dev box was 1.4 trunk, but obviously not |
| 16:11.49 | Juggie | HarryR, eugh :) |
| 16:11.58 | Juggie | try dialing w/ the g option |
| 16:12.09 | HarryR | it behaves the same, disconnects fastagi |
| 16:12.23 | Juggie | there was a fix in 1.4 for this i think |
| 16:12.50 | SimonPerreault | Juggie, btw, why didn't you come to the grand canyon with us? |
| 16:13.22 | Juggie | i dunno... i didnt really feel like a really long car ride |
| 16:13.38 | SimonPerreault | you missed something |
| 16:13.53 | SimonPerreault | it was only like 3½ hours |
| 16:14.13 | *** part/#asterisk-dev lbow (n=lbow@dsl-146-5-201.telkomadsl.co.za) |
| 16:24.59 | Juggie | is it possible to fix this, http://bugs.digium.com/view.php?id=10847 |
| 16:25.10 | Juggie | given the current cli design, i dont think that it is. |
| 16:25.35 | flujan | De_Mon: I tryed to use the busy-limit and the call-limit but appean that it is not solving the issue... |
| 16:25.56 | flujan | De_Mon: maybe it could be a problem in the channel status ? |
| 16:26.38 | De_Mon | flujan are you using agents or dynamic queue members? |
| 16:27.11 | De_Mon | try calling the peer directly and not using the queue and see if it behaves as exepcted |
| 16:27.18 | De_Mon | (only one call in, 2nd call is busy) |
| 16:27.34 | De_Mon | s/is/gets/ |
| 16:33.11 | flujan | dynamic and realtime... it appear to work just to users who receive calls... In this call-center the users also place calls to the clients... |
| 16:33.29 | flujan | I will analyse it a bit more to come with a more information.. . |
| 16:33.52 | De_Mon | thats right, calls going into the peer count against the busy limit, calls going out only count toward the total call limit |
| 16:34.36 | De_Mon | You could come up with a local channel that calls the queue and the member so, the local channel is making the call and not the agent.. but that would be, not fun. |
| 16:36.40 | De_Mon | sorry, client and queue |
| 16:38.04 | flujan | hum... here is the output from the queue: http://pastie.caboo.se/103371 |
| 16:38.22 | De_Mon | wait a sec... I take that all back, the busy-limit should be based on total calls not just calls to. |
| 16:38.44 | flujan | putnopvut: It is not possible to add this feature, but is it possible to add a strategy that does not count the In Use members to deliver calls? |
| 16:39.41 | putnopvut | Adding anything new will make it a trunk-only feature. |
| 16:40.03 | flujan | putnopvut: :( |
| 16:40.12 | flujan | De_Mon: so it will not solve the issue right? |
| 16:41.48 | putnopvut | flujan: Another issue to consider in this regard is whether this should be a queue feature or sip feature. Sip just has a call limit setting right now, but it might be worth it to have an incoming and outgoing call limit there. |
| 16:41.58 | putnopvut | Just thinking out loud here. |
| 16:42.17 | flujan | putnopvut: for sure the old way WILL solve this ISSUE... |
| 16:42.19 | flujan | ops |
| 16:42.23 | putnopvut | Right. |
| 16:42.26 | flujan | sorry for the uppercase. |
| 16:42.42 | flujan | putnopvut: wonderfulll... it will be also a feature for 1.6 not for 1.4 right? |
| 16:42.59 | putnopvut | Yeah. The policy is that any sort of new feature can't go in 1.4 |
| 16:43.02 | De_Mon | putnopvut why isn't busy-limit doing this? |
| 16:43.17 | flujan | putnopvut: alas, as I said I was trying to add this call-limits to the softphone, so IMHO it is a sip feature... |
| 16:43.19 | putnopvut | I'm not familiar with busy-limit. |
| 16:43.27 | flujan | what did you guys suggest? |
| 16:44.00 | flujan | old versions of asterisk I think 1.0 have such feature... I dunno why It was dropped in favor of the call-limit. |
| 16:44.05 | putnopvut | flujan: could this be handled in your dialplan? |
| 16:44.22 | flujan | putnopvut: dunno how... :( |
| 16:44.37 | De_Mon | http://lists.digium.com/pipermail/asterisk-commits/2007-February/011119.html |
| 16:44.43 | De_Mon | look at that and tell me what you see |
| 16:45.20 | putnopvut | Ah, it's a trunk feature. |
| 16:45.44 | putnopvut | It sounds exactly like what would work for flujan. |
| 16:45.51 | putnopvut | Set a busy limit of 1 and a call-limit of 2. |
| 16:46.04 | De_Mon | eh, I swore I read somewhere it was in 1.4 |
| 16:46.25 | putnopvut | Well, it may be, but you linked me to the trunk commit. |
| 16:47.25 | putnopvut | Ah, it's called "busy-level" |
| 16:47.48 | putnopvut | and... |
| 16:48.03 | putnopvut | it's not in 1.4 :( |
| 16:48.21 | putnopvut | Wait... |
| 16:48.50 | putnopvut | I haven't updated svn in a while, it may be in 1.4. |
| 16:48.57 | putnopvut | And busy-level and busy-limit are different, sorry. |
| 16:49.51 | De_Mon | neither busy-limit or busy-level are in 1.4, it looks like trunk changed busy-limit to busy-level |
| 16:49.53 | flujan | putnopvut: De_Mon I already tried it... does not work... It set the channel as in-use not as Busy. |
| 16:50.28 | De_Mon | flujan I was wrong, busy-limit/busy-level arn't in 1.4, but they are comming and should do exactly what you want. |
| 16:50.54 | flujan | De_Mon: comming to.... :D |
| 16:51.38 | flujan | De_Mon: do you have idea when It will be commited? |
| 16:51.50 | flujan | 1.4.13 or ??? |
| 16:52.03 | putnopvut | flujan: busy-level is already in trunk, and I don't think it will be in any 1.4 branches. |
| 16:52.17 | flujan | putnopvut: :( |
| 16:53.14 | flujan | do you have idea when next version of asterisk should be released? |
| 16:53.14 | putnopvut | flujan: Looking at the commit oej made to add the busy-limit/level, it looks pretty simple. I'd be willing to bet it wouldn't be a huge task to backport it. |
| 16:53.49 | putnopvut | flujan: the release date of next asterisk is up in the air at this point, unfortunately. We're trying to iron out the details of our release cycles for the next version. |
| 16:53.53 | flujan | hum... I am not familiar with it but I can download the 1.4.12 and patch it with the code oej send? |
| 16:54.32 | putnopvut | flujan: Possibly. The problem is that the commit from oej is rather old, and so it may not apply cleanly. Also, differences between trunk and 1.4 may mean that it won't apply cleanly as well. |
| 16:54.57 | flujan | oej: are you here? :D |
| 16:55.01 | putnopvut | But the thing is, there weren't many lines changed in the code, so that's why I was thinking that it may not be a difficult task to backport. |
| 16:55.17 | flujan | putnopvut: let see if the authour could help me. :D |
| 16:56.21 | putnopvut | oej's not here right now. He lives in Sweden, so his hours may not align well with someone from the western hemisphere. |
| 16:56.41 | De_Mon | oej was here an hour ago |
| 16:57.08 | De_Mon | ok, 2 hours ago |
| 17:17.40 | oej | No, I'm not here... |
| 17:17.43 | oej | Going away again |
| 17:17.48 | key2 | :) |
| 17:17.51 | oej | Sweden is gmt+1 |
| 17:22.26 | De_Mon | burn |
| 17:30.37 | *** join/#asterisk-dev blitzrage (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 17:32.26 | HarryR | right, just installed asterisk 1.4.12, but if I do a Dial() within a FastAGI script, when either end hangsup wht FastAGI connection is disconnected |
| 17:33.12 | HarryR | however - I need to do important processing after the call has hungup, but without going back to asterisk and doing another agi connection |
| 17:33.18 | Corydon76-dig | HarryR: that seems like the expected behavior |
| 17:33.29 | blitzrage | indeed |
| 17:33.33 | Corydon76-dig | HarryR: it's been changed in trunk, though |
| 17:33.37 | blitzrage | should be calling it from the 'h' extension |
| 17:33.50 | HarryR | yah that's what it was doing previously |
| 17:34.16 | HarryR | agi then back to astiersk, dial, then a DeadAGI in the h extension |
| 17:34.18 | blitzrage | in trunk, like Corydon76-dig said, Juggie and a couple other people went through and made it so DeadAGI() and AGI() were essentially merged |
| 17:34.28 | Corydon76-dig | In trunk, AGI transitions seamlessly to dead mode |
| 17:35.44 | key2 | Corydon76-dig: is it better to have the HDLC framing done by hardware or software |
| 17:36.08 | HarryR | ah cool, I mean all I really want to do is be able to be notified of the DIALSTATUS after the Dial() finishes |
| 17:36.41 | HarryR | I can just trap the socket disconnect and perform cleanup, but without DIALSTATUS it's ... not possible |
| 17:36.52 | Corydon76-dig | key2: doesn't matter |
| 17:37.04 | Corydon76-dig | key2: probably better to do it in software, really |
| 17:37.18 | key2 | Corydon76-dig: why ? |
| 17:37.23 | Corydon76-dig | unless your machine is so loaded that you need every CPU cycle for something else |
| 17:37.31 | De_Mon | HarryR $DIALSTATUS doesn't work? |
| 17:37.39 | De_Mon | with {}'s of course |
| 17:37.40 | Corydon76-dig | but then, you'd be better off moving to multiple machines |
| 17:37.55 | HarryR | De_Mon: Dial() terminates my FastAGI connection so I can't get DIALSTATUS after Dial() finishes |
| 17:38.16 | De_Mon | oh right, agi. duh |
| 17:38.21 | key2 | Corydon76-home: well, the thing is that I get a lot of bad FCS when it's done in software... so I was wondering if that would help to make it in hardware |
| 17:38.22 | Corydon76-dig | key2: because HDLC encoding isn't that complex. It's already extremely fast in software, so you're not saving yourself much |
| 17:39.00 | Corydon76-dig | key2: that points to noise on the line, not a software problem |
| 17:39.46 | key2 | Corydon76-dig: thats what I thought, but I dont really have a solution :) |
| 17:40.16 | Corydon76-dig | key2: why are you asking these questions in here instead of in #asterisk ? |
| 17:40.58 | key2 | Corydon76-dig: cuz beside you, not much people really know about the low layers of PRI ;) |
| 17:41.07 | key2 | s/many |
| 17:41.10 | Corydon76-dig | That's not PRI |
| 17:41.14 | Corydon76-dig | That's Zaptel |
| 17:41.20 | key2 | of zaptel then ;) |
| 17:41.38 | Corydon76-dig | Doesn't matter, if it's not about development, then it's off topic here |
| 17:42.05 | Corydon76-dig | for any problems at all, unless you're directly involved in the code, the discussion belongs in #asterisk |
| 17:42.31 | Corydon76-dig | If you're reporting a bug, do so on the bugtracker and discuss in #asterisk-bugs |
| 17:43.48 | Corydon76-dig | I seem to remember telling you this exact thing yesterday, too. If I have to do it again, I might have to take a different action. |
| 17:43.56 | ctooley | Juggie now it is clear to me why you'd want to transition cleanly in AGI from live to dead mode without having a separate app. That same logic can't be applied to ExternalIVR. |
| 17:44.02 | *** join/#asterisk-dev jcmoore (n=jcmoore@unaffiliated/tgrman) |
| 17:44.19 | ctooley | There is no call control in ExternalIVR, only queue control. So you'd never "dial" from ExternalIVR |
| 17:45.05 | Corydon76-dig | ctooley: why can't you call ExternalIVR from the 'h' extension? |
| 17:46.15 | ctooley | you 'can' but it's logically going to require a second connection. It can't seemlessly transition from live to dead state when the call is hung up. |
| 17:46.44 | Corydon76-dig | Okay, why not? |
| 17:47.47 | Corydon76-dig | or more precisely, why shouldn't it? |
| 17:48.13 | ctooley | If you're forced to make a second connection the logic reads much cleaner if there's a different name that can be used when calling it on a channel that's explicitly got no audio. it makes coming back to later easier to understand. |
| 17:48.31 | Corydon76-dig | So it's in name only? |
| 17:48.38 | ctooley | Functionally it doesn't have to be a separate application (which is how I hacked it together for the interim). |
| 17:49.16 | Corydon76-dig | Then add a comment to the dialplan. I don't see a reason for two different app names for exactly the same functionality |
| 17:49.39 | ctooley | Corydon76-dig, well, it would definitely function differently. ie If you call the "Dead" version on a channel that hasn't been answered yet, you don't want it answering the channel. |
| 17:49.43 | ctooley | It restricts function. |
| 17:50.06 | Corydon76-dig | Create a runtime option for that, possibly |
| 17:50.34 | Corydon76-dig | We already have flags to other applications to tell them not to answer the channel, why not for ExternalIVR? |
| 17:51.15 | ctooley | Which is what Juggie suggested. But, why create an optional behavior when that just makes it more difficult to read. Someone would have to know what the application does and what the option means to decipher what it's doing. |
| 17:51.37 | Corydon76-dig | You have to do that, anyway. If you're concerned about reading it, add a comment |
| 17:52.32 | Corydon76-dig | I hear your argument, I understand it, we aren't receptive to the argument. Adding a comment will work just as well. |
| 17:52.44 | ctooley | Not necessarily. If the naming is clear enough it is pretty self explanatory. ExternalIVR() is a connection to an IVR that is outside the system. DeadExternalIVR() is a connection to an IVR but the audio is Dead. |
| 17:53.05 | Corydon76-dig | The answer is still No. |
| 17:54.49 | Corydon76-dig | Unless you can demonstrate a FUNCTIONAL reason why it needs to be a different app, you're going to get the same answer from the other developers, as well. |
| 17:58.48 | mvanbaak | ello all |
| 17:59.16 | *** join/#asterisk-dev ctooley (n=ctooley@209.33.109.249) |
| 17:59.22 | ctooley | #simplfied |
| 17:59.24 | ctooley | doh |
| 18:08.37 | blitzrage | and you spelled simplified wrong too :) |
| 18:08.58 | ctooley | I know |
| 18:10.33 | anonymouz666 | Corydon76-dig: since 1.2.24 release it was fixed many deadlocks? I am seeing some specific issue while involving chan_local and transferred calls. So I am think to move to 1.4. |
| 18:11.42 | blitzrage | so I do have to admit I may have been wrong about OS X |
| 18:12.57 | blitzrage | tastes like chicken! |
| 18:18.29 | *** join/#asterisk-dev angler (i=angler@pdpc/sponsor/digium/angler) |
| 18:21.56 | Corydon76-dig | angler!!! |
| 18:22.26 | angler | Corydon76-dig!! |
| 18:22.37 | putnopvut | Crap, flujan left... |
| 18:22.46 | angler | I made it to the new office on ups! |
| 18:22.50 | file | angler: sweet! |
| 18:22.53 | Corydon76-dig | Heh |
| 18:23.06 | Corydon76-dig | How many stop lights did you run? |
| 18:23.27 | angler | haha, didn't hit any. Just 1 stop sign |
| 18:24.24 | Corydon76-dig | angler: you planning to make it up to PhreakNIC this time around? |
| 18:28.12 | Qwell | angler: how many stop signs did you run? ;) |
| 18:28.44 | *** join/#asterisk-dev russellb (i=russellb@asterisk/developer-and-stable-maintainer/drumkilla) |
| 18:28.44 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 18:32.52 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 18:32.52 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:39.43 | *** join/#asterisk-dev bweschke (n=bweschke@204.13.233.213) |
| 18:39.43 | *** mode/#asterisk-dev [+o bweschke] by ChanServ |
| 18:48.51 | jmls | putnopvut: could not flujan have fixed his problem by using local channels and groups ? |
| 18:49.57 | bweschke | /me waves back to file |
| 18:53.14 | putnopvut | jmls: possibly. I can't say for sure though. |
| 18:53.40 | putnopvut | I'm pretty sure it could be taken care of with dialplan logic. |
| 18:53.48 | jmls | just check the group count on the local channel, and busy it if it's > 1 |
| 18:56.12 | russellb | ah yes, that's how most people handle that today .. |
| 18:56.21 | russellb | that's how we have it in our config, too |
| 18:56.49 | angler | Corydon76-dig, nope not planning on it. The talks the last few years haven't been that great. Also really don't have the $ to go |
| 19:00.49 | codefreeze | I see 9785; is it ready to commit? (Add 'e' extension to handle application errors) |
| 19:19.42 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 19:19.42 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:25.49 | Corydon76-dig | codefreeze: I just revised the code a few times |
| 19:27.30 | putnopvut | Sayonara. Packing time! |
| 19:28.37 | *** join/#asterisk-dev wwalker (n=wwalker@pdpc/supporter/sustaining/wwalker) |
| 19:35.47 | *** join/#asterisk-dev joetester (n=joeteste@216.191.34.13) |
| 19:43.52 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 19:43.52 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:45.19 | *** join/#asterisk-dev russellb (i=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 19:45.20 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 19:45.44 | russellb | moving is lammmmmmmmmmmme |
| 19:45.58 | ctooley | russellb, moving homes or offices? |
| 19:46.19 | codefreeze | If you're not sweating, you're not working hard enough!!! ;) |
| 19:47.41 | russellb | offices |
| 19:47.46 | joetester | He's sweating from all the supervising he was doing |
| 19:47.49 | russellb | ha |
| 19:47.53 | russellb | we're moving into the new digium building |
| 19:47.53 | mvanbaak | lol |
| 19:48.09 | mvanbaak | you guys get a sane connection there ? |
| 19:48.13 | joetester | Hey mvanbaak |
| 19:48.30 | russellb | sane connection? heh, should be good |
| 19:48.39 | denon | russellb: is it shaped like an asterisk, wings out from the hub? |
| 19:48.52 | denon | though I dunno about a bright orange headquarters.. |
| 19:48.56 | russellb | heh, i wish |
| 19:49.06 | russellb | we have room for 2 more buildings on the land |
| 19:49.13 | russellb | and if we build all 3, i think they might make an asterisk |
| 19:49.14 | russellb | i'm not sure ... |
| 19:49.19 | denon | hehe |
| 19:49.22 | russellb | right now it's more like ... an L |
| 19:49.52 | denon | coo |
| 19:50.10 | joetester | Build a pyramid! |
| 19:50.17 | joetester | Pyramids are cool! |
| 19:50.18 | russellb | i have no say in the architecture :) |
| 19:50.20 | russellb | i just get to work there |
| 19:50.26 | russellb | pyramids are pretty l33t ... |
| 19:50.40 | joetester | Your office could be at the top! |
| 19:51.55 | denon | I thought programmer offices were in the basement, with no windows? |
| 19:52.12 | denon | just redbull and a fast compile cluster |
| 19:54.14 | russellb | heh, we don't have any distcc action going on here |
| 19:54.21 | russellb | asterisk doesn't take that long to build |
| 19:54.26 | joetester | The pyramid could be built upon russellb! |
| 19:54.43 | joetester | It could be an upside down pyramid! |
| 19:54.43 | russellb | i'm not strong enough :( |
| 19:55.16 | joetester | But you would be remembered by all |
| 19:55.29 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 19:55.29 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:55.44 | denon | until the pyramid got demo'd to put up a new casino, anyway |
| 19:55.46 | russellb | helping to maintain asterisk isn't worth remembering? :( |
| 19:56.26 | file | >_< |
| 19:56.29 | russellb | so ... go help people? or code .... |
| 19:56.33 | joetester | Sure it is! Especially app_voicemail.c cough! |
| 19:56.46 | russellb | heh, i don't touch that beast |
| 19:57.04 | russellb | we have new guys that are silly enough to do it! |
| 19:57.10 | denon | hehe |
| 19:57.12 | joetester | lmao! |
| 19:57.14 | denon | you could always work on skinny |
| 19:57.22 | denon | now there's a nice fun project ;) |
| 19:57.33 | file | right... nice fun project |
| 19:57.41 | russellb | or i could work on res_monkeys, some more |
| 19:57.46 | russellb | hard to decide which would be more beneficial |
| 19:57.56 | denon | and while you're doing that, file is going to make h.323 run on a single udp port |
| 19:58.14 | denon | and not break compatibility with h.323 devices from the 1990s |
| 19:58.15 | russellb | i have chan_iax2 running on 0 udp ports |
| 19:58.22 | joetester | I hate to intervene but my chan_sip is deadlocking like the mad over here. |
| 19:58.23 | russellb | all calls to all servers have to share the same tcp connection |
| 19:58.37 | russellb | joetester: build with DEBUG_THREADS, get the "core show locks" output |
| 19:58.38 | russellb | NOW |
| 19:59.00 | russellb | and then show file, because it's his fault |
| 19:59.08 | joetester | It was built with core show locks. |
| 19:59.14 | file | it is... it is... |
| 19:59.28 | joetester | I mean debug_threads |
| 19:59.28 | Juggie | russellb, is it possible to fix the asterisk -rx "blah command" given the current cli architecture? |
| 19:59.35 | Juggie | my assumption is no... |
| 19:59.58 | joetester | file: can I show you the two lines that matter in what was logged? |
| 20:00.07 | russellb | Juggie: yes |
| 20:00.09 | russellb | it's only software |
| 20:00.37 | joetester | you could make it make toast if you wanted (you once told me that a while ago) |
| 20:00.55 | Juggie | russellb, not without a cli redesign though, the cli is all the same stream of information, so how do you make -rx see only the command its executing when all its doing is attaching temporarily to asterisk and displaying the output |
| 20:01.10 | file | joetester: just pastebin the core show locks output... |
| 20:01.26 | russellb | Juggie: it's possible |
| 20:01.36 | Juggie | russellb, what would need to be done? |
| 20:01.48 | Juggie | its an issue i keep hearing over and over that -rx doesnt behave as they expect |
| 20:01.55 | russellb | i can't really pull up the code right now |
| 20:01.56 | joetester | file: Don't have it unfortunately, couldn't get it it was sort of infinite looping. |
| 20:02.11 | russellb | but basically ... every console is registered into a list of "verbosers" |
| 20:02.20 | russellb | when it's -rx, it needs to _not_ go in that list |
| 20:02.39 | russellb | and the "verbosers" are what receive that big stream of console output |
| 20:03.16 | joetester | file: but I do have the message that it printed out about (sip_show_peers) waiting for (do_monitor). |
| 20:03.49 | Juggie | russellb, ok, i'll try and see if i can dig into that. |
| 20:04.08 | russellb | that would r0x0r |
| 20:04.18 | russellb | i don't know how trivial it will be |
| 20:04.30 | russellb | but that's the general idea for how to fix it |
| 20:04.42 | joetester | file: useless? |
| 20:04.57 | russellb | joetester: why didn't you paste it in here |
| 20:05.36 | joetester | russellb: ? |
| 20:07.03 | joetester | From now on I run it with all the debug I can get, DEBUG_THREADS, DETECT_LOCKS and DONT_OPTIMIZE... the machine is powerful and it doesn't have all that much stress. |
| 20:08.11 | joetester | Actually it's already running like that. |
| 20:09.04 | Juggie | russellb: i *think* this is an easy fix |
| 20:09.40 | Juggie | the code is already trying to not register for -rx but the if statement looks wrong. |
| 20:09.50 | Juggie | if (ast_opt_console || option_verbose || (ast_opt_remote && !ast_opt_exec)) { |
| 20:10.14 | Juggie | option_verbose is going to be >0 so its going to be true allways |
| 20:10.44 | russellb | ah, so i guess that's not it them |
| 20:10.45 | russellb | then* |
| 20:10.54 | russellb | because the WELCOME_MESSAGE does not get printed |
| 20:12.47 | Juggie | ya, true. |
| 20:13.46 | russellb | ooh |
| 20:13.53 | russellb | i think it's the network_verboser i was talking about |
| 20:14.08 | Juggie | ya i saw that too. |
| 20:14.18 | russellb | that's the one |
| 20:15.02 | elixer | russellb: fyi, in your commit for r84547 in your events branch, you somehow munged the $Revision:$ tag |
| 20:15.03 | russellb | so maybe we can put a flag in the struct console to note that it is -x |
| 20:15.09 | russellb | elixer: nice. |
| 20:15.30 | elixer | russellb: just letting you know :) |
| 20:15.50 | Juggie | russellb, yeah, because its calling function has no idea what your params were. |
| 20:17.39 | russellb | rargh ... |
| 20:17.42 | russellb | that's not going to work |
| 20:17.57 | russellb | there is no way for the console server side to know if the client connecting is connecting for -x or not |
| 20:18.04 | russellb | it will have to be in the client part of the code |
| 20:18.04 | joetester | russellb: Can I paste the two lines? |
| 20:18.09 | russellb | ugh, this is harsh |
| 20:18.12 | russellb | joetester: HELL NO |
| 20:18.16 | russellb | sure |
| 20:18.26 | russellb | ... but i won't see them, as i have to go load stuff into a truck |
| 20:18.42 | joetester | russellb: SO I pastebin the two lines? |
| 20:18.54 | russellb | for 2 lines, just paste here |
| 20:19.03 | joetester | [Oct 3 13:09:48] ERROR[21249] /usr/src/asterisk-1.4-svn/include/asterisk/lock.h: chan_sip.c line 9810 (_sip_show_peers): Deadlock? waited 5 sec for mutex '&(iterator)->_lock'? |
| 20:19.05 | joetester | [Oct 3 13:09:48] ERROR[21249] /usr/src/asterisk-1.4-svn/include/asterisk/lock.h: chan_sip.c line 15406 (do_monitor): '&(iterator)->_lock' was locked here. |
| 20:19.08 | joetester | There we go |
| 20:19.29 | joetester | Is this any use or pointless garbage? |
| 20:19.49 | Corydon76-dig | 'core show locks' would probably be more useful. |
| 20:20.12 | Juggie | russellb, the flag is set in ast_options |
| 20:21.02 | joetester | Yeah I know I'm sorry couldn't do it at the time... could we arrange that typing in 'core show locks' writes the output to the "messages" file too, because I can't manage when it's infinitely looping like this. |
| 20:21.46 | russellb | joetester: that part is of no use other than indicating that something broke |
| 20:21.53 | russellb | "core show locks" will show exactly what broke |
| 20:22.30 | joetester | Crap sorry... but the way it's been going it's not gonna take long for it to deadlock again. The way it's been going it deadlocks everyday. |
| 20:22.58 | mvanbaak | meh |
| 20:23.16 | mvanbaak | this dude in .nl (teacher at uni) proposed 'internetless day' |
| 20:23.45 | mvanbaak | he wants to find out how much energy we will save on a day without internet/computers |
| 20:24.05 | mvanbaak | so, we simply powerdown every single computer/server for a day |
| 20:24.14 | mvanbaak | and the next day we poweron stuff all at once |
| 20:24.16 | Corydon76-dig | He might as well propose a day without using gasoline |
| 20:24.29 | mvanbaak | yeah, the powergrid will survive that _NOT_ |
| 20:24.37 | Corydon76-dig | Not going to happen |
| 20:24.48 | mvanbaak | duh |
| 20:24.54 | mvanbaak | but this guy is serious |
| 20:25.01 | mvanbaak | wrote a huge report to the goverment |
| 20:25.20 | Corydon76-dig | mvanbaak: he can be as serious as he likes. 99.9% of the population is going to ignore him |
| 20:25.58 | elixer | and "computer" is a pretty broad term |
| 20:26.08 | Corydon76-dig | I doubt anybody in the government is stupid enough to try it |
| 20:26.32 | mvanbaak | elixer: his exact wording is: every device that participates in the internet |
| 20:26.45 | mvanbaak | Corydon76-dig: then you clearly dont know our goverment |
| 20:27.17 | Corydon76-dig | mvanbaak: oh, there are people within who might get interested, but the government as a whole won't let it happen |
| 20:27.42 | Corydon76-dig | There's too much infrastructure in place |
| 20:27.56 | Juggie | did 10875 get fixed? |
| 20:28.06 | Corydon76-dig | m10875 |
| 20:28.07 | MuffinMan | [new] [Asterisk] Channels/General 0010875: Asterisk 1.4.12 crashes in channel.c reported by callguy http://bugs.digium.com/view.php?id=10875 |
| 20:28.26 | Corydon76-dig | Guess not |
| 20:31.48 | *** join/#asterisk-dev ctooley (n=ctooley@209.33.109.249) |
| 20:35.26 | joetester | I require baby sitting again, I want to log whatever core show locks shows in messages or whatever, any ideas? |
| 20:42.36 | Juggie | 'asterisk -rx "core show locks" > mycorelockslog' |
| 20:54.15 | joetester | Will it append or overwrite? |
| 20:58.40 | joetester | I can't believe I f-ed up like this, I cost us the opportunity of fixing this. |
| 20:59.38 | outtolunc | http://www.cpqlinux.com/redirect.html |
| 21:00.27 | joetester | Bookmarked. |
| 21:00.36 | mvanbaak | 32 |
| 21:03.10 | joetester | I panicked too cause it was the first time I saw a deadlock. It won't happen again. |
| 21:18.46 | *** join/#asterisk-dev tsurko (n=tsurko@78.90.100.214) |
| 21:26.36 | *** join/#asterisk-dev blitzrage (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 22:03.08 | *** join/#asterisk-dev miguel3239 (n=elguerom@ns1.nashuacs.com) |
| 22:10.35 | *** part/#asterisk-dev bweschke (n=bweschke@204.13.233.213) |
| 22:29.58 | *** join/#asterisk-dev anthm (n=anthm@mb60736d0.tmodns.net) |
| 22:29.58 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 22:56.15 | *** join/#asterisk-dev qdk (n=qdk@0x573fe57e.bynqu2.broadband.tele.dk) |