| 00:24.21 | *** join/#asterisk-dev brookshi1e (i=mbrooks@hijacked.us) |
| 00:25.00 | *** join/#asterisk-dev dlynes_laptop (n=dlynes@bas6-hamilton14-1176462822.dsl.bell.ca) [NETSPLIT VICTIM] |
| 00:25.02 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-6-236.dsl.telesp.net.br) |
| 00:25.14 | *** join/#asterisk-dev korihor (n=korihor@190.205.251.97) [NETSPLIT VICTIM] |
| 00:25.20 | *** join/#asterisk-dev Qwell (i=north@pdpc/sponsor/digium/Qwell) |
| 00:25.20 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 00:26.45 | *** join/#asterisk-dev russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb) [NETSPLIT VICTIM] |
| 00:26.45 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 00:30.55 | *** join/#asterisk-dev file (n=file@asterisk/developer-and-muffin-lover/file) |
| 00:30.55 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 00:40.29 | *** join/#asterisk-dev DarkRift (n=dark@65.92.169.12) |
| 03:02.29 | *** part/#asterisk-dev korihor (n=korihor@190.205.251.97) |
| 06:53.40 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 06:53.40 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:50.09 | *** join/#asterisk-dev Tim_Toady (n=moi@188.4.42.84.dsl.dyn.forthnet.gr) |
| 07:51.03 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 07:51.03 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:15.24 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 08:15.24 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:16.33 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 08:16.33 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:17.06 | oej | Morning folks |
| 08:18.14 | snuff-home | ello oej |
| 08:21.56 | Corydon76-dig | oej: your concern on reviewboard licensing has already been considered and avoided properly |
| 08:22.19 | Corydon76-dig | You cannot post a patch unless you already have an active contribution license |
| 08:22.29 | oej | Aha! |
| 08:22.35 | oej | Thanks for letting me know |
| 08:22.50 | oej | Up late or in Europe? |
| 08:22.52 | oej | :-) |
| 08:22.57 | Corydon76-dig | Up late |
| 08:23.12 | Corydon76-dig | Spent the day on bison/flex |
| 08:23.45 | oej | ...and the night... |
| 08:23.56 | oej | I don't understand which problem you where trying to solve with that, sorry |
| 08:23.59 | Corydon76-dig | I hate hate hate "magic" phrases to build certain files |
| 08:24.10 | oej | Agree |
| 08:24.41 | Corydon76-dig | and the rebuild of the flex/bison source files to C source files was one of those |
| 08:24.58 | oej | Ok, then I get it |
| 08:25.06 | Corydon76-dig | Now, after a bit of work, we have an item in menuselect |
| 08:25.29 | Corydon76-dig | and bison detection is against a particular feature, not just a bison version |
| 08:25.49 | Corydon76-dig | which is really the way it should be |
| 08:27.27 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 08:28.14 | Corydon76-dig | and then I spent some time getting MALLOC_HOLD to be module-specific, kind of like REF_DEBUG for astobj2 |
| 08:28.20 | snuff-home | anyone deal with multi parkinglot code? |
| 08:28.47 | Corydon76-dig | snuff-home: you don't sleep, do you? |
| 08:29.04 | snuff-home | i sleep 6hrs or so.. |
| 08:29.11 | snuff-home | its only 730pm here |
| 08:29.26 | oej | snuff: I wrote it at start... Then mvanbaak took over |
| 08:29.29 | snuff-home | basically ur morning.. = my sleep.. |
| 08:29.43 | Corydon76-dig | Ah... |
| 08:30.03 | snuff-home | i'm just tryin to find a clean way for 'parkandannounce' to work with the parkinglots |
| 08:31.09 | *** join/#asterisk-dev vrban (n=chatzill@p50997436.dip0.t-ipconnect.de) |
| 08:32.07 | snuff-home | the only time it checks for the 'parkinglot' variable is against the 'peer' not 'chan' in space_reserve.. |
| 08:33.14 | snuff-home | i made it check 'chan' for the vars if there was no 'peer' in my current 'hack' but i fear that could have bad effects for others using the code |
| 08:33.49 | snuff-home | bb in 5-10 |
| 08:34.03 | *** join/#asterisk-dev Dovid (n=annon@109.160.156.202) |
| 08:35.21 | oej | isn't the parkinglot part of the channel structure? |
| 08:38.02 | Corydon76-dig | You mean the name or the actual structure? |
| 08:38.30 | Corydon76-dig | It would be a datastore, if anything |
| 08:39.14 | Corydon76-dig | snuff-home: that doesn't sound too bad, as the peer is who is doing the parking, if inline |
| 08:40.02 | Corydon76-dig | Chan is who is being parked |
| 08:41.08 | oej | The parkinglot is a stringfield in ast_channel struc |
| 08:41.09 | Corydon76-dig | On trunks, it doesn't make much sense for the parking lot to be on the chan, unless set in the dialplan |
| 08:41.10 | snuff-home | mm i'm almost wondering if you need app_parkandannounce.. some of the code seems very similar to what is in features.c |
| 08:41.45 | oej | Like accountcode and stuff, it's inherited from device configs |
| 08:41.53 | oej | just the name |
| 08:42.09 | Corydon76-dig | oej: yeah, but that only really makes sense for actual devices, not trunks |
| 08:42.13 | snuff-home | yes.. but the incoming call is on a trunk.. |
| 08:42.58 | Corydon76-dig | If you share the trunk with multiple departments or companies, it's really better set after the DID is known |
| 08:43.38 | oej | That's why we do support the channel variable - it overrides whatever is in the ast_channel |
| 08:44.23 | Corydon76-dig | So I think the real question is what is the order for fields that are checked, to determine the PL name |
| 08:44.55 | *** join/#asterisk-dev xpot (n=xpot@70-91-210-233-BusName-Utah.hfc.comcastbusiness.net) |
| 08:45.02 | snuff-home | yes but 'parkandannounce' just takes a channel to park... parkandannounce sends 'null' as peer channel.. |
| 08:45.08 | Corydon76-dig | peer var, chan var, peer struct, chan struct ? |
| 08:45.45 | Corydon76-dig | snuff-home: right, because there is no 'other' channel in that scenario |
| 08:45.52 | snuff-home | mm |
| 08:46.25 | Corydon76-dig | essentially what you'd want to know is who redirected the call to ParkAndAnnounce |
| 08:46.57 | Corydon76-dig | Or maybe that redirect is responsible for setting the chan var |
| 08:47.21 | snuff-home | yes and it seems little extreme to create a dummy chan just so we can look at 'peer' for the parkinglotname |
| 08:47.21 | Corydon76-dig | Does that sound reasonable to you? |
| 08:47.34 | Corydon76-dig | I wasn't suggesting such |
| 08:47.48 | Corydon76-dig | I was only suggesting the order in which we check for the values |
| 08:47.57 | Corydon76-dig | i.e. fallback order |
| 08:48.54 | snuff-home | mmm.. |
| 08:48.54 | Corydon76-dig | Anyway, I need to get to bed, so I can get up in 7 hours |
| 08:49.00 | Corydon76-dig | 'night |
| 08:49.02 | snuff-home | np later Corydon76-dig |
| 08:50.40 | oej | Good night, Corydon! |
| 08:51.37 | snuff-home | still cold over there oej? |
| 08:51.59 | oej | yes, way too cold. |
| 08:53.52 | snuff-home | was 30C here today.. but it is summer.. |
| 08:54.51 | oej | -15C here |
| 08:56.11 | snuff-home | mm that's rather cold indeed |
| 09:44.58 | *** join/#asterisk-dev paravoid (n=paravoid@zebra.cslab.ece.ntua.gr) |
| 10:42.59 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 11:57.37 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 11:57.37 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 12:04.46 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:45.45 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:45.45 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 13:35.19 | *** join/#asterisk-dev mpe (n=mpe@gate.ipvision.dk) |
| 14:20.33 | atis_work | huh, that's not cold.. currently -14, but at night it's -20 :) |
| 14:22.32 | atis_work | tomorrow it's going to be -30 in some areas :) |
| 14:22.40 | kpfleming | ouch |
| 14:22.54 | kpfleming | is that the real temperature, or with wind chill effects? |
| 14:23.04 | atis_work | nope, just temp |
| 14:23.25 | kpfleming | sorrry to hear that |
| 14:23.29 | kpfleming | stay indoors :-) |
| 14:23.32 | atis_work | kids are happy about that if it's -25 they don't have to go to school :D |
| 14:24.19 | atis_work | hah, i just started wearing gloves this week :D |
| 14:24.39 | kpfleming | that's about -15 or -20 fahrenheit... damn cold |
| 14:24.48 | atis_work | umm, it's not fahrenheit |
| 14:24.53 | kpfleming | yes, i know |
| 14:24.56 | atis_work | well, i'm speaking in celsius :) |
| 14:25.02 | kpfleming | -25C is -13F |
| 14:25.05 | kpfleming | approximately |
| 14:25.30 | atis_work | ah, so you have negative values too on fahrenheit :D |
| 14:25.49 | atis_work | i thought they were unsupported :D |
| 14:26.02 | dlynes_laptop | atis_home, -40C = -40F |
| 14:26.22 | dlynes_laptop | atis_home, you're thinking of the Kelvin scale |
| 14:26.40 | dlynes_laptop | atis_home, it doesn't have negative numbers |
| 14:27.42 | atis_work | no, i was just kidding about weird measurment systems :) |
| 14:28.08 | dlynes_laptop | atis_home, ah |
| 14:28.59 | dlynes_laptop | atis_work, anyways...fwiw, -40 is the same on celsius and fahrenheit, 0C = 32F, 25C = 72.5F, 100C = 212F |
| 14:29.34 | dlynes_laptop | atis_work, I'm in Canada...we use both Fahrenheit and Celsius |
| 14:32.13 | *** join/#asterisk-dev tacubo (n=tacvbo@189.146.173.116) |
| 14:32.27 | atis_work | at least you use meters instead of inches :) |
| 14:33.13 | Marquis42 | What good is a system of measurement if it's not based on the width of someone's thumb, or length of foot, etc. ;) |
| 14:44.49 | leifmadsen | Marquis42: :) |
| 14:52.57 | seanbright | kpfleming: i think he gets offended when people imply his email client is horribly broken |
| 14:54.19 | kpfleming | yeah |
| 14:54.33 | kpfleming | he replied directly about it, he's pissed off at his IT department for not fixing it when there is a patch available |
| 14:55.26 | seanbright | ahh |
| 14:55.56 | seanbright | well at least there is relief on the horizon |
| 15:03.48 | russellb | or he could just sign up for gmail ... |
| 15:05.35 | seanbright | there is that, too. |
| 15:06.33 | kpfleming | i mentioned that to him, but he's participating as a representative of his employer |
| 15:08.08 | seanbright | ah well |
| 15:08.34 | russellb | well his employer is about to get banned, heh |
| 15:08.45 | russellb | not really. |
| 15:22.08 | *** join/#asterisk-dev putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 15:22.08 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:35.12 | *** join/#asterisk-dev elguero (n=_miguel3@ns1.nashuacs.com) |
| 15:38.36 | russellb | Corydon76-dig: now I see the same failure I saw on the test box: test_chan_variable: 'reallylongdinosaursoundingthingwithwordsinit' != '' != '' |
| 15:42.19 | russellb | ah ... it's because libcurl isn't installed. |
| 15:52.39 | seanbright | i'm not sure how i feel about thunderbird 3's "smart folders" |
| 15:54.05 | *** join/#asterisk-dev Deeewayne (n=dwayne@c-71-207-214-190.hsd1.al.comcast.net) |
| 15:54.05 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 15:58.15 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 15:58.15 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 16:01.44 | *** join/#asterisk-dev The_Boy_Wonder (n=vossel@asterisk/batman-developer/dvossel) |
| 16:01.44 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 16:05.33 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 16:05.33 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:08.58 | *** join/#asterisk-dev marv (n=timr@router.asteriasgi.com) |
| 16:25.06 | Kobaz | hmm |
| 16:25.21 | Kobaz | it seems there's a limit to the length of exten when creating local channels |
| 16:25.41 | seanbright | 80 characters? |
| 16:26.27 | Kobaz | 61 |
| 16:27.15 | Corydon76-dig | Is your context 18 characters long? |
| 16:28.03 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 16:28.36 | Kobaz | it's 17... plus the @, is 18 |
| 16:28.58 | Kobaz | yeah, that's 79 total |
| 16:29.01 | Corydon76-dig | There you go. 80 characters |
| 16:29.04 | Kobaz | mm |
| 16:29.10 | Corydon76-dig | terminating NULL |
| 16:29.13 | Kobaz | yeah |
| 16:29.19 | Kobaz | i'll have to do this differently then |
| 16:30.14 | Corydon76-dig | Where are you creating the Local channel? |
| 16:30.31 | Kobaz | with an originartew |
| 16:30.33 | Kobaz | originate |
| 16:30.56 | Corydon76-dig | There's at least 3 different originates... which one? |
| 16:31.06 | Kobaz | i send my data to channels with base64encoded data to Originate |
| 16:31.18 | Kobaz | i'm using the ami version |
| 16:31.25 | Kobaz | i just notiuced you can set variables in the originate |
| 16:31.34 | Kobaz | you can't in the dialplan Originate() in 1.6.2 though |
| 16:31.52 | Kobaz | probably should be added |
| 16:31.58 | Kobaz | i'll add that to my todo |
| 16:33.09 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/professional/jeffg) |
| 16:33.21 | Kobaz | and there's no SoftHangup in the manager either |
| 16:33.22 | Kobaz | heh |
| 16:33.25 | Kobaz | something else to add |
| 16:36.31 | Deeewayne | I added a Meetme AMI command to play ad hoc announcements using the channel conference. It works, but now I'm trying to use the conference pseudo channel to call ast_playtones_start(). The ast_activate_generator() call to ast_settimeout is returning 0, but I don't see generator_force() being called. Anyone have any ideas on why this isn't working? |
| 16:37.21 | Kobaz | Deeewayne: no idea... but i would be interested in checking out your patch when you're done |
| 16:38.18 | Corydon76-dig | Deeewayne: If it's serviced by the loop, you may need to start autoservice to get it to go |
| 16:38.22 | Deeewayne | the MeetmeAnnounce AMI works nicely ... I thought this might be something interesting to contribute, but I really need to generate tones |
| 16:38.49 | Corydon76-dig | i.e. the same loop where you're injecting the sound |
| 16:39.46 | Deeewayne | Corydon76-dig, thanks, I'll try that |
| 16:40.51 | seanbright | Kobaz: there is a hangup in the manager |
| 16:40.56 | seanbright | at least in trunk |
| 16:41.16 | Kobaz | Deeewayne: since you're playing with meetme, you may be interested in: https://issues.asterisk.org/view.php?id=16617 https://issues.asterisk.org/view.php?id=16616 |
| 16:41.28 | Kobaz | seanbright: there is ami hangup, but not softhangup |
| 16:41.48 | Kobaz | seanbright: softhangup can do a device hangup, ami hangup as far as i know will only do a single channel |
| 16:42.23 | seanbright | ah |
| 16:42.55 | Kobaz | ie: hang up all channels on a device |
| 16:43.10 | seanbright | correct |
| 16:44.39 | Deeewayne | Corydon76-dig, that was it! |
| 16:44.43 | Deeewayne | hugs Corydon76-dig |
| 16:49.19 | Corydon76-dig | Yay! |
| 16:50.26 | oej | Kobaz - issue 16616 |
| 16:50.37 | oej | I don't like the header "Talking" - can we find another name? |
| 16:52.49 | Kobaz | oej: that's the same value used for the talking events |
| 16:53.05 | oej | You're never talking at the moment you join... |
| 16:53.05 | Kobaz | i tried to keep everything consistant with what was there |
| 16:53.22 | Kobaz | mmm |
| 16:53.29 | oej | Or? |
| 16:53.30 | Kobaz | true |
| 16:53.36 | oej | So it's not really needed then. |
| 16:54.16 | Kobaz | probably not... unless talking status can change before that event is sent |
| 16:54.39 | Kobaz | i don't know that code well enough to say that's completely correct, that talking would always be off |
| 16:54.44 | oej | ok |
| 16:55.02 | oej | I'll try to make a decision about it tomorrow. Have to go do something else tonight. |
| 16:55.03 | Corydon76-dig | Talking status needs several milliseconds to verify |
| 16:55.31 | oej | The join event is sent as soon as you join |
| 16:55.35 | Kobaz | yeah |
| 16:55.44 | Corydon76-dig | If you don't have the time to verify noise levels above a certain level, then no, you cannot be talking when you join |
| 16:59.37 | oej | So the talking header is not useful in that event. |
| 16:59.49 | Kobaz | i suppose not |
| 17:00.01 | oej | I have a meetme list manager action in a branch. Talking makes sense in that. |
| 17:00.12 | oej | But not much though... |
| 17:00.24 | Kobaz | well, if you have a daemon that keeps state |
| 17:00.34 | Kobaz | which we have one |
| 17:00.41 | oej | We have talk events for that |
| 17:00.46 | Kobaz | it needs to be initalized with the current status |
| 17:01.01 | Kobaz | yes... but... you start up asterisk... people join meetme, you start up your daemon |
| 17:01.01 | oej | At join, the status is "no talk" always |
| 17:01.18 | Kobaz | without a talking status on meetme list, the daemon now thinks everyone is silent |
| 17:01.30 | oej | If your daemon goes on line an attaches to a running asterisk, yes, then talk status is needed |
| 17:01.38 | Kobaz | yeap |
| 17:02.34 | oej | have you tested my branch? |
| 17:02.43 | *** join/#asterisk-dev Greek-Boy (n=Monching@41.188.154.137) |
| 17:02.52 | Kobaz | i haven't |
| 17:02.53 | Kobaz | where is it? |
| 17:03.05 | oej | pine<something> :-) |
| 17:03.15 | oej | I'll find it and add a note in the bug tracker for you :-) |
| 17:03.28 | Kobaz | k |
| 17:03.46 | oej | I've been working a lot with meetme, manager and rtcp lately |
| 17:04.10 | oej | Summary: we manage meetme conferences over manager and need control of QoS ;-) |
| 17:04.17 | Kobaz | ah |
| 17:04.38 | Kobaz | my biggest add so far is group variables |
| 17:04.41 | oej | Also added a dialplan command to check if the manager controller was logged in |
| 17:04.45 | Kobaz | which i need for our own conference management |
| 17:05.01 | Kobaz | https://issues.asterisk.org/view.php?id=16614 |
| 17:05.27 | oej | Yes. Lots of code cleanup needed. |
| 17:05.36 | Kobaz | on mine? |
| 17:06.13 | *** join/#asterisk-dev tacubo (n=tacvbo@189.146.188.184) |
| 17:06.19 | oej | Yes, from reading the reviewboard I noticed that the code needed some work, but I don't remember exact. Will give you feedback. Need to think about the concept for a while. It's certainly interesting. |
| 17:06.33 | Kobaz | there's stuff in the reviewboard? |
| 17:06.34 | Kobaz | heh |
| 17:06.38 | Kobaz | i thought i was supposed to get an email |
| 17:07.04 | oej | Check the link in the bug tracker. You have a lot of comments with no doxygen |
| 17:07.07 | Kobaz | oh, i see |
| 17:07.16 | Kobaz | yeah i pasted the reviewboard link |
| 17:07.26 | Kobaz | i thought it notifiys you when you get feedback |
| 17:07.41 | oej | And I do not like the "VariablesStart: Variables will follow\r\n" header at all |
| 17:07.56 | Kobaz | aww |
| 17:08.03 | Kobaz | that's how we do channel variables too |
| 17:08.16 | Kobaz | i tried to think of the most compact way to do it |
| 17:08.25 | Kobaz | otherwise you would need one event per variable, and that's kind of a pain |
| 17:08.36 | oej | That header is totally unneeded for parsing. |
| 17:09.00 | oej | We don't assume that *people* read manager events - only developers ;-) |
| 17:09.03 | Kobaz | yes |
| 17:09.04 | Kobaz | but |
| 17:09.09 | Kobaz | that's why you need the header |
| 17:09.18 | Kobaz | because you may have a group variable called Event: |
| 17:09.43 | Corydon76-dig | That's why we don't name headers after variable names |
| 17:11.18 | Kobaz | so now you have duplicate keys with no boundry as to where the event variables are, and group variables are |
| 17:11.18 | oej | Then we need another syntax. Let me think about it for a while and we'll solve it. |
| 17:11.19 | oej | Corydon is also very good with syntax issues. |
| 17:11.19 | Kobaz | Corydon76-dig: isn't it the opposite? |
| 17:11.19 | Kobaz | that you don't want to name variables after header names |
| 17:11.20 | Corydon76-dig | Eh? Are you talking client-side issues? |
| 17:11.21 | Kobaz | the problem is... to be developer-friendly, it should support any variable name |
| 17:11.21 | Corydon76-dig | I don't deal with client-side issues. They can be dealt with in numerous ways |
| 17:11.22 | Corydon76-dig | ChanVariable(<channame>): varname=value |
| 17:11.25 | Kobaz | that works |
| 17:11.44 | Corydon76-dig | The header may actually be ChannelVar, not sure |
| 17:11.50 | Kobaz | i like that |
| 17:11.58 | Corydon76-dig | It's in trunk. |
| 17:12.02 | Kobaz | nice |
| 17:12.07 | Kobaz | we added that to our own code |
| 17:12.08 | oej | Ok, kobaz, find that code and update your patch :-) |
| 17:12.10 | Kobaz | i was gonna make a patch out of it |
| 17:12.13 | Kobaz | oej: yeap |
| 17:12.20 | Kobaz | oej: i'll do that this week |
| 17:12.36 | oej | Thanks for contributing to Asterisk. I like this work. |
| 17:12.39 | Kobaz | thanks |
| 17:12.42 | Kobaz | there's more coming |
| 17:12.47 | oej | :-) |
| 17:12.54 | Kobaz | ideally the entire group system should be rewritten |
| 17:13.17 | Kobaz | because as someone else mentioned, the internal lists shouldn't be exposed and iterators should be used instead |
| 17:13.21 | oej | If we could merge a new group system and replace the current call/pickupgroups with it I would be happy |
| 17:13.23 | Qwell | the group stuff should have never been done in the channel drivers directly, IMO |
| 17:13.40 | Kobaz | and... my add is a tack-on, and i tried to not disrupt the existing design/functionality |
| 17:13.43 | Qwell | Dial(Group/1) would be far far cooler |
| 17:13.47 | Kobaz | so i have another structure |
| 17:13.54 | Kobaz | Qwell: this is completely different |
| 17:13.54 | Corydon76-dig | works hard to ensure that the code pieces link together nicely |
| 17:14.08 | Qwell | Kobaz: oh. well, my point stands. :p |
| 17:14.09 | Kobaz | Qwell: we're talking about runtime groups of channels |
| 17:14.23 | Kobaz | Qwell: yeah, i like that idea of staticly defined channel groups |
| 17:14.36 | Corydon76-dig | Qwell: to dial all or the first available? |
| 17:14.42 | Kobaz | Dial(Group/foobar) |
| 17:14.48 | Qwell | Corydon76-dig: same syntax as like chan_dahdi |
| 17:14.55 | Corydon76-dig | Ah, first available |
| 17:14.57 | Qwell | Group/R1, however you want |
| 17:15.01 | Kobaz | and foobar could be like, DAHDI/g0 and IAX2/foo |
| 17:15.11 | Corydon76-dig | We can still do that, with a dialplan function |
| 17:15.14 | Kobaz | named dahdi/zap groups would be sweet |
| 17:15.23 | Corydon76-dig | DIALGROUP is the implementation to dial all |
| 17:16.13 | Corydon76-dig | Kobaz: what would be nice, as Qwell pointed out, is the ability to unify DAHDI and SIP lines, such that if all DAHDI trunks are in use, it uses a SIP trunk |
| 17:16.31 | Kobaz | yeah |
| 17:16.37 | Kobaz | i have custom support for that in an agi call router |
| 17:17.09 | Kobaz | but all channel types should be unified for group dialing probably |
| 17:17.58 | Kobaz | what i need to find out though |
| 17:18.04 | Kobaz | is a good way to debug random asterisk crashes |
| 17:18.09 | Qwell | gdb |
| 17:18.10 | Kobaz | local channels are really giving me a hard time in 1.6.0.20 |
| 17:18.18 | Kobaz | yeah, i use gdb |
| 17:18.39 | Kobaz | http://pastebin.ca/1765755 |
| 17:18.49 | Corydon76-dig | I've been thinking I need to revert that chan_local fix |
| 17:19.14 | Corydon76-dig | I think it's actually caused more issues than it solved |
| 17:19.14 | Kobaz | which one? |
| 17:19.23 | Corydon76-dig | 236982 |
| 17:19.39 | seanbright | commit asterisk 236982 |
| 17:19.41 | MuffinMan | [236982] Committed by tilghman on 2009-12-30T21:59:18.377032Z: Merged revisions 236981 via svnmerge from |
| 17:19.41 | MuffinMan | ..https://origsvn.digium.com/svn/asterisk/branches/1.4 |
| 17:19.41 | MuffinMan | .. |
| 17:19.41 | MuffinMan | .......... |
| 17:19.42 | MuffinMan | .. r236981 | tilghman | 2009-12-30 15:57:10 -0600 (Wed, 30 Dec 2009) | 9 lines |
| 17:19.45 | MuffinMan | .. |
| 17:19.47 | MuffinMan | .. Don't queue frames to channels that have no means to process them. |
| 17:19.47 | seanbright | :-) |
| 17:19.50 | MuffinMan | .. (closes issue #15609) |
| 17:19.52 | MuffinMan | .. Reported by: aragon |
| 17:19.54 | MuffinMan | .. Patches: |
| 17:19.57 | MuffinMan | .. 20091230__issue16521__1.4__chan_local_only.diff.txt uploaded by tilghman (license 14) |
| 17:20.00 | MuffinMan | .. Tested by: aragon |
| 17:20.02 | MuffinMan | .. |
| 17:20.04 | MuffinMan | .. Review: https://reviewboard.asterisk.org/r/452/ |
| 17:20.07 | MuffinMan | .......... |
| 17:20.09 | MuffinMan | .. |
| 17:20.11 | MuffinMan | .. http://svn.digium.com/view/asterisk?view=rev&revision=236982 |
| 17:20.21 | Corydon76-dig | Yeah... there was a reason I didn't use that command... |
| 17:20.28 | Kobaz | hah |
| 17:20.58 | seanbright | it's a bit wordy |
| 17:21.26 | Kobaz | i get that warning with iax too |
| 17:21.30 | Kobaz | the Exceptionally long voice queue |
| 17:21.36 | Kobaz | i get that all the time on slow boxes actually |
| 17:22.05 | Corydon76-dig | Yeah, I'm thinking the better way to solve that is to wipe out the old frames |
| 17:22.24 | Kobaz | is my crash related to this same issue? |
| 17:22.30 | Corydon76-dig | since they're likely superfluous if the queue is that long |
| 17:22.44 | Corydon76-dig | Kobaz: please be more specific |
| 17:22.52 | Kobaz | http://pastebin.ca/1765755 |
| 17:23.02 | Kobaz | i really have no more info, other than the full thread bt |
| 17:23.12 | Kobaz | about 20 other calls were going through at the time |
| 17:23.14 | Corydon76-dig | almost certainly not |
| 17:23.16 | Kobaz | lots of local channel processing |
| 17:23.28 | Corydon76-dig | This shouldn't cause any ACTUAL issues |
| 17:23.34 | Kobaz | okay |
| 17:23.41 | Corydon76-dig | well, crashes, anyway |
| 17:23.47 | *** join/#asterisk-dev msetim (n=setim@189.114.186.118) |
| 17:23.50 | Corydon76-dig | It could cause lots of issues, just not crashes |
| 17:23.56 | Kobaz | heh, k |
| 17:24.50 | Kobaz | is there more debugging i can turn on? |
| 17:24.58 | Kobaz | so i/we can figure out crashes better |
| 17:25.14 | Kobaz | there's about 10 core dumps that i just have no idea what caused them |
| 17:25.24 | Kobaz | various machines, various versions of asterisk |
| 17:25.41 | Corydon76-dig | There's lots of debugging options, but you need to have a clue as to what caused the crash to select the right one |
| 17:26.04 | Kobaz | other crashes are obvious... you dial something,, ast crashes... you dial that same something, and it crashes again |
| 17:26.20 | Kobaz | but i see many random ones |
| 17:26.46 | Kobaz | is it useful to just turn them all on |
| 17:26.53 | Kobaz | how bad would it affect performance? |
| 17:30.34 | Corydon76-dig | The issue isn't particularly affecting performance. It's whether irrelevant debugging obscures the actual problem. |
| 17:30.36 | *** join/#asterisk-dev CunningPike (n=CunningP@204.239.8.157) |
| 17:31.40 | Kobaz | yeah that too |
| 17:31.56 | Kobaz | what i like to do in that case is log different debuggint to different files |
| 17:37.10 | Corydon76-dig | You still need to figure out which one is relevant |
| 17:39.59 | Kobaz | yeah |
| 17:47.40 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 17:47.40 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 17:50.56 | Corydon76-dig | Kobaz: just uploaded a new patch to your local channel spy issue |
| 17:51.35 | Corydon76-dig | It reverts the chan_local fix and tries to fix that previous issue in a different way. That should hopefully make your Local channel issues disappear |
| 17:52.12 | Corydon76-dig | And while it won't stop the 'Exceptionally long' messages, it should abbreviate them considerably |
| 17:54.33 | Kobaz | okay |
| 17:54.36 | Kobaz | sounds good |
| 17:54.38 | Kobaz | i'll test |
| 17:55.58 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 17:55.58 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:00.31 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 18:00.31 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 18:00.33 | *** join/#asterisk-dev tacvbo (n=tacvbo@189.146.181.217) |
| 18:16.37 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 18:21.22 | *** join/#asterisk-dev msetim (n=setim@187.59.20.61) |
| 18:21.55 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 18:21.55 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:23.24 | seanbright | i don't know the difference between termination and origination |
| 18:23.25 | seanbright | i fail |
| 18:24.21 | jsmith | seanbright: One means you're sending outbound calls, the other means you're accepting inbound calls... your mission, should you choose to accept it, is to figure out which is which |
| 18:26.00 | Corydon76-dig | Origination means I create you. Termination means I kill you. |
| 18:26.21 | Corydon76-dig | s/kill/KEEL/ |
| 18:27.40 | *** join/#asterisk-dev tacubo (n=tacvbo@189.146.176.217) |
| 18:29.47 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 18:47.50 | *** join/#asterisk-dev korihor (n=korihor@201.210.226.98) |
| 18:59.39 | *** join/#asterisk-dev flohack (n=fhackenb@chello084115131198.3.graz.surfer.at) |
| 19:13.21 | *** join/#asterisk-dev shin-shoryuken_ (n=shin-sho@hephaestus.restechservices.net) |
| 19:17.23 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:27.56 | *** join/#asterisk-dev elguero (n=elguero@ns1.nashuacs.com) |
| 19:45.53 | *** join/#asterisk-dev puzzled (n=foobar@puzzled.xs4all.nl) |
| 20:17.05 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 20:35.08 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 20:35.08 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:57.05 | *** join/#asterisk-dev codefreeze-lap (n=murf@mail.parsetree.com) |
| 20:57.05 | *** mode/#asterisk-dev [+o codefreeze-lap] by ChanServ |
| 21:04.35 | *** join/#asterisk-dev codefreeze-lap (n=murf@mail.parsetree.com) |
| 21:04.35 | *** mode/#asterisk-dev [+o codefreeze-lap] by ChanServ |
| 21:05.33 | codefreeze-lap | grumbles about asnparse |
| 21:10.07 | *** join/#asterisk-dev tacvbo (n=tacvbo@189.146.173.71) |
| 21:16.51 | *** join/#asterisk-dev Deeewayne (n=dwayne@adsl-070-148-053-233.sip.bhm.bellsouth.net) |
| 21:16.51 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 22:10.46 | *** join/#asterisk-dev xpot-mobile (n=xpot@173-14-232-121-Utah.hfc.comcastbusiness.net) |
| 22:11.10 | *** join/#asterisk-dev anthm][ (n=anthm@CPE-72-128-89-126.wi.res.rr.com) |
| 22:20.51 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 22:52.40 | *** join/#asterisk-dev angler (n=angler@pdpc/sponsor/digium/angler) |
| 22:52.49 | *** join/#asterisk-dev mbranca (n=matteo@host139-217-static.224-95-b.business.telecomitalia.it) |
| 22:55.46 | *** join/#asterisk-dev tacvbo (n=tacvbo@189.146.183.84) |
| 23:22.14 | *** join/#asterisk-dev tacubo (n=tacvbo@189.146.191.73) |
| 23:39.33 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 23:39.33 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 23:54.25 | *** join/#asterisk-dev snuff-work (n=aaa@120.19.32.82) |
| 23:54.25 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |