| 00:00.46 | *** join/#asterisk-dev felipe_ (~felipe@my.nada.kth.se) |
| 00:08.16 | *** join/#asterisk-dev philipp64 (~chatzilla@mail.redfish-solutions.com) |
| 00:53.18 | leifmadsen | snuff-work: morning! |
| 00:53.32 | snuff-work | ello leifmadsen |
| 00:54.54 | snuff-work | what is new over there.. heard of big floods in nashville area |
| 00:55.06 | leifmadsen | ya that's what I hear too -- no floods here though |
| 00:55.12 | leifmadsen | (Toronto, Canada) |
| 00:55.19 | leifmadsen | just hot air and blue skies |
| 00:56.21 | snuff-work | yer its getting little colder |
| 00:56.48 | leifmadsen | warmer here :) |
| 00:56.55 | leifmadsen | ok, I'm done being on the computer.. been here since 7:30am |
| 00:57.00 | leifmadsen | (it's nearly 9pm now) |
| 00:57.46 | snuff-work | mm have a good night :) |
| 01:34.19 | *** join/#asterisk-dev pabelanger (~pabelange@CPE0013f7abc09a-CM0013f7abc096.cpe.net.cable.rogers.com) |
| 01:35.41 | pabelanger | Anybody have a good resource site for autoconf? I'm trying to add some switches into Asterisk, but only hacking away at this point. |
| 01:36.06 | seanbright | http://www.gnu.org/software/autoconf/manual/autoconf.html |
| 01:38.18 | pabelanger | seanbright: Ya, reading ATM. |
| 01:38.40 | snuff-work | runs far from autoconf |
| 01:48.53 | pabelanger | Well, I managed to figure it out. Seems to work, but I don't believe it is pretty. Will need to be reviewed for sure. |
| 01:58.49 | *** join/#asterisk-dev diegomad (~mad@190.158.77.2) |
| 02:01.50 | seanbright | pabelanger: fwiw, when i see uid i think numeric |
| 02:42.44 | *** join/#asterisk-dev diegomad (~mad@190.158.77.2) |
| 02:49.20 | pabelanger | seanbright: agree, wording to be changed. |
| 03:04.06 | *** join/#asterisk-dev Ta^3 (~tacvbo@189.146.181.250) |
| 05:38.07 | *** join/#asterisk-dev Milad (~milad@unaffiliated/slackark) |
| 05:39.25 | Milad | is there anyway to different hangup from 2 SIP channel ? I want to know which channel hangups the call but seems in AMI I don't have this data. is it possible on source code ? |
| 07:28.06 | tzafrir_laptop | will hopefully not try again to commit from the read-only tree (or at least complain here when it fails) |
| 07:52.23 | *** join/#asterisk-dev mnick86 (~Matthias@whhem00016.cip.uni-regensburg.de) |
| 07:58.51 | *** part/#asterisk-dev mnick86 (~Matthias@whhem00016.cip.uni-regensburg.de) |
| 08:11.58 | tzafrir_laptop | curses post-review again, and falls back to manually copying diffs |
| 08:47.49 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 09:17.09 | *** join/#asterisk-dev frawd (~francois@135.Red-88-27-74.staticIP.rima-tde.net) |
| 10:15.16 | *** join/#asterisk-dev Samodelkin (~mkhon@91.204.27.30) |
| 10:55.19 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 10:55.19 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:15.54 | *** join/#asterisk-dev frawd (~francois@83.34.101.6) |
| 11:16.49 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 11:16.49 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 11:31.35 | *** join/#asterisk-dev ccesario (~ccesario@189-19-6-236.dsl.telesp.net.br) |
| 11:50.27 | *** join/#asterisk-dev frawd (~francois@83.34.101.6) |
| 12:10.07 | *** join/#asterisk-dev rrb3942 (~rbullock@208.34.105.161) |
| 12:11.23 | *** join/#asterisk-dev frawd (~francois@135.Red-88-27-74.staticIP.rima-tde.net) |
| 12:13.25 | *** join/#asterisk-dev caio1982 (~caio1982@CAcert-br/caio1982) |
| 12:36.48 | pabelanger | morning |
| 12:37.04 | rrb3942 | morning |
| 12:38.51 | jsmith | Morning! |
| 12:43.18 | leifmadsen | MORNING! |
| 12:44.10 | atis_work | afternoon |
| 13:04.01 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 13:04.02 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 13:12.52 | *** join/#asterisk-dev gelo (~gelo@209.138.60.213.dynamic.mundo-r.com) |
| 13:34.01 | *** join/#asterisk-dev bklang (~bklang@tesla.alkaloid.net) |
| 13:54.24 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 13:54.24 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:01.30 | jsmith | leifmadsen and I are having problems trying to get the ENUMQUERY function to work... Anybody feel like giving us a quick sanity check? |
| 14:01.49 | leifmadsen | working with 'dig' returns fine, but in the asterisk dialplan we get no results |
| 14:02.48 | kpfleming | can you post your exact queries? |
| 14:03.03 | jsmith | dig -t NAPTR 1.1.0.1.0.1.0.0.2.7.3.4.e164.arpa |
| 14:03.35 | jsmith | exten => 106,1,Set(ENUMID=${ENUMQUERY(437200101011,sip,e164.arpa)}) |
| 14:04.27 | leifmadsen | full dialplan and result: http://pastebin.com/dJDuDcrM |
| 14:04.49 | kpfleming | that is not the syntax that is documented for ENUMQUERY |
| 14:05.05 | leifmadsen | huh? |
| 14:05.11 | leifmadsen | ENUMQUERY(number[,method-type[,zone-suffix]]) |
| 14:05.11 | kpfleming | the docs say it takes two parameters, one being the number to look up and the other the zone to look it up in |
| 14:05.18 | leifmadsen | 3 params |
| 14:05.23 | leifmadsen | number is required |
| 14:05.24 | kpfleming | oh, i'm reading wrong |
| 14:05.25 | jsmith | kpfleming: Which docs are you looking at? |
| 14:05.34 | leifmadsen | there is an argument missing in the docs ;) |
| 14:05.57 | kpfleming | no, in my brain |
| 14:06.01 | kpfleming | does ENUMLOOKUP work? |
| 14:06.01 | leifmadsen | or that ) |
| 14:06.03 | leifmadsen | nope |
| 14:06.15 | jsmith | kpfleming: No, ENUMLOOKUP fails (sometimes) as well |
| 14:06.43 | jsmith | kpfleming: It appears that ENUNLOOKUP is able to parse other NAPTR records (xmpp, etc.) but not sip records |
| 14:06.49 | leifmadsen | actually... it seems to work *sometimes* |
| 14:07.07 | leifmadsen | ya, I got a mailto record back there when doing ALL |
| 14:07.59 | leifmadsen | huh, this number works differently for me than another record I was trying. I got a sip response back from ENUMLOOKUP() |
| 14:08.30 | leifmadsen | this one worked for me: exten => 103,1,Set(RESULT=${ENUMLOOKUP(437200101011,sip)}) |
| 14:08.55 | leifmadsen | ENUMQUERY() worked for me on a number that ENUMLOOKUP() didn't work on, but vice-versa on that number above..... |
| 14:09.58 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 14:09.58 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:10.46 | kpfleming | i see nothing obviously wrong with the code... it hasn't changed in a long time |
| 14:15.49 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:15.49 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:17.44 | snuff-home | goes for some zzz's |
| 14:28.06 | *** join/#asterisk-dev moy (~moy@bas1-unionville55-1177733627.dsl.bell.ca) |
| 14:31.15 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 14:31.15 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 14:37.11 | *** join/#asterisk-dev marv (~timr@router.asteriasgi.com) |
| 14:49.19 | *** join/#asterisk-dev hugorebelo (~hugo@p5B277A47.dip.t-dialin.net) |
| 14:49.54 | *** join/#asterisk-dev kerframil (~kerframil@gentoo/user/kerframil) |
| 14:50.11 | *** join/#asterisk-dev megalomano (~klonstein@38.124.169.126) |
| 14:55.04 | megalomano | hi people , i have some doubts about the variables to manipulate the asterisk behavior with bash , are there some book that describes this variables? |
| 14:55.41 | russellb | eh? |
| 14:55.45 | russellb | you might want to try #asterisk |
| 14:56.20 | *** join/#asterisk-dev jpeeler (~jpeeler@asterisk/digium-software-dev/jpeeler) |
| 14:56.20 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 14:58.05 | *** join/#asterisk-dev eliel (~eliels@201.234.94.226) |
| 14:58.05 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 15:12.59 | *** part/#asterisk-dev gelo (~gelo@209.138.60.213.dynamic.mundo-r.com) |
| 15:14.43 | megalomano | i want to make a trigger calls from txt file |
| 15:15.08 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:30.34 | *** join/#asterisk-dev Deeewayne (~dwayne@75-150-14-49-Atlanta.hfc.comcastbusiness.net) |
| 15:30.34 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 15:35.29 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 15:38.35 | *** join/#asterisk-dev Pazzo (~ugelt@reserved-225136.rol.raiffeisen.net) |
| 15:56.01 | *** join/#asterisk-dev jmls (~jmls@host217-36-208-155.in-addr.btopenworld.com) |
| 16:02.06 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187-28-37-118.poolip.RJO.embratel.net.br) |
| 16:09.38 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 16:20.47 | *** join/#asterisk-dev frawd (~francois@83.34.101.6) |
| 16:37.12 | jsmith | kpfleming: Have a quick second for a sanity check on the DNS/ENUM stuff? |
| 16:38.46 | jsmith | The ast_search_dns function (in main/dns.c) returns -1 on an error, 0 if there is no match, and 1 if there's a match |
| 16:39.45 | jmls | ok, planning on a new version of asterisk in a couple of months - do I go for 1.4 trunk, 1.6.2 or trunk ? We can test the bejesus out of the version , if that helps ... ;) |
| 16:40.09 | jsmith | The ast_get_enum function (in main/enum.c) only treats a result of 0 as being OK. Any reason that shouldn't be >= 0 instead of == 0? |
| 16:40.35 | jsmith | jmls: 1.4 is LTS, or trunk *will* be LTS... 1.6.2 will be going into security-only mode before too long |
| 16:43.06 | leifmadsen | jmls: 1.6.0 and 1.6.1 will go into security only mode after this set of release candidates (just released now). 1.4 and 1.6.2 is planned to go into security only mode around December of 2010 (although that will likely be extended). 1.8 will become the next LTS sometime later this year. |
| 16:43.38 | atis_work | jmls: were you the one using res_config_curl for SIP registrations? |
| 16:44.03 | jmls | atis_work: not yet - we use res_config_curl for almost everything else |
| 16:44.15 | leifmadsen | 1.4 and 1.6.2 maintenance will likely be extended beyond the dates listed here: http://www.asterisk.org/asterisk-versions |
| 16:44.29 | atis_work | jmls: are you planning to? |
| 16:44.35 | jmls | yup |
| 16:44.45 | jmls | once I worked out what fields / data is required |
| 16:45.02 | atis_work | jmls: we found some issues with it and rfc |
| 16:45.15 | atis_work | jmls: according to rfc, response should come within 320ms |
| 16:45.16 | jmls | dodged that bullet, then |
| 16:45.32 | atis_work | jmls: well, we're pretty much around everything now |
| 16:45.41 | Qwell | russellb: ping! |
| 16:45.52 | russellb | PONG!!!!!!!!!!!!!!!!!!!! |
| 16:45.58 | jmls | atis_work: can you time the calls to curl ? |
| 16:46.21 | atis_work | jmls: well, we're doing curl requests across the ocean, so it's pretty much ~200ms |
| 16:46.33 | jmls | cool. |
| 16:46.39 | Qwell | russellb: need a judgment call. yesterday we were talking about how the MOH tarballs were now versioned, and how Asterisk wasn't taking advantage of it. I fixed up the sounds tree, so that it can do so now easily |
| 16:46.43 | atis_work | jmls: but you could have slow webserver, etc.. |
| 16:46.56 | Qwell | russellb: question is - 1.4+, or trunk only? the sounds/Makefile patch is pretty small |
| 16:47.11 | jmls | atis_work: would you send me the info I need to use curl for realtime sip ? |
| 16:47.13 | atis_work | jmls: so, what needs to be done - rtcachefriends=yes so that first REGISTER does curl request and then caches it |
| 16:47.25 | russellb | versioned, for the purposes of detecting when a new one is available so you download it and such? |
| 16:47.43 | Qwell | no, no, like how core-sounds is, where it just has a set version # in the Makefile, and downloads that. |
| 16:47.44 | atis_work | jmls: and second - send 200 OK on REGISTER before updating realtime data |
| 16:47.57 | Qwell | right now it's just always downloading asterisk-moh-opsound.-${fmt}-tar.gz |
| 16:48.01 | russellb | what prompted this, those files never change ... |
| 16:48.09 | russellb | sounds like a waste of time :-p |
| 16:48.18 | Qwell | they've changed 3 times :p |
| 16:48.27 | Qwell | it's at 2.03 |
| 16:48.28 | russellb | if the work is done, trunk only |
| 16:48.47 | russellb | i don't really consider it a "bug fix" ... |
| 16:48.58 | russellb | unless you want to try to convince me otherwise |
| 16:50.18 | Qwell | <philipp64> in the interests of reproducibility, having versioned MOH files makes sense to me. |
| 16:50.18 | Qwell | <kpfleming> agreed |
| 16:50.19 | Qwell | <philipp64> automated builds should be deterministic. |
| 16:50.35 | russellb | meh, fine, 1.4 too |
| 16:50.37 | Qwell | whether you'd consider that a bug fix, I dunno |
| 16:50.38 | russellb | i really don't care that much |
| 16:50.47 | russellb | thanks for taking care of it, though |
| 16:50.56 | russellb | that's a valid point ^^^ |
| 16:51.05 | russellb | so we should just do it everywhere |
| 16:51.09 | atis_work | jmls: patch would be in chan_sip - exchange places of transmit_response_with_date with update_peer |
| 16:51.10 | Qwell | k |
| 16:51.23 | atis_work | jmls: we'll probably submit patch to mantis soon |
| 16:51.33 | jmls | great |
| 16:51.56 | atis_work | jmls: i was just wondering if you have had discovered this |
| 16:52.07 | jmls | no. afraid not |
| 16:56.24 | jmls | trunk is a lot better for doing stuff like "blinky lights" and voice-mail following, right ? |
| 16:56.40 | jmls | (than 1.4, that is) |
| 16:57.45 | oej | atis_work: Sorry for bursting in mid-debate, but why confirm an operation before we attempt it? Isn't that BAD? |
| 16:59.08 | oej | re: "sending 200 OK on register before updating realtime data" |
| 17:00.04 | atis_work | oej: because you can get huge delays on database/curl operations, and send 200 OK too late |
| 17:00.48 | atis_work | jmls: i don't think that original blinkenlights.de was done on asterisk at all :p |
| 17:01.33 | oej | atis_work: But if you fail, then you've confirmed something that is wrong and you cause other issues |
| 17:02.07 | oej | atis_work: If you wait, then the client will just retransmit, so there's really no "too late" - unless you wait over 32 secs or 64*T1 |
| 17:02.26 | oej | That's why we send 100 trying to say "we're doing something, have patience" |
| 17:02.37 | oej | After a 100 trying we have much more time |
| 17:02.45 | atis_work | umm, but there's no 100 Trying on REGISTER |
| 17:02.55 | oej | Have someone removed that? |
| 17:03.08 | oej | Course there is. YOu are allowed to do that on any method |
| 17:03.19 | atis_work | i mean - not in 1.6.1.6 |
| 17:03.21 | oej | SIP proxys do it |
| 17:03.38 | oej | Someone implemented an option to remove it, but it should be disabled by default |
| 17:03.48 | oej | We should propably only do it with realtime devices |
| 17:04.03 | atis_work | oej: probably yes, i can check if that works |
| 17:04.20 | oej | Anyway, I strongly oppose sending a result code before we know the result. |
| 17:04.29 | oej | That would stop a lot of failover functionality in the protocol |
| 17:04.37 | atis_work | oej: thanks, i'll check it |
| 17:04.41 | oej | If we fail, we should be able to send a 5xx message so the phone go to another server |
| 17:04.51 | oej | Good! |
| 17:05.08 | oej | goes looking for family, fun and food |
| 17:28.21 | *** join/#asterisk-dev diegomad (~mad@190.146.200.120) |
| 17:34.15 | *** join/#asterisk-dev CunningPike (~CunningPi@204.239.8.157) |
| 18:16.00 | *** join/#asterisk-dev mnick86 (~Matthias@whhem00016.cip.uni-regensburg.de) |
| 18:40.43 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 18:44.07 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 18:47.01 | *** join/#asterisk-dev chazzam (~chazz@173-24-238-25.client.mchsi.com) |
| 19:02.35 | *** join/#asterisk-dev FlaPer87 (~FlaPer87@unaffiliated/flaper87) |
| 19:03.06 | FlaPer87 | hey guys, is there some link to the asterisk coding styles? I'm fixing some of the things pointed here https://issues.asterisk.org/view.php?id=17170 |
| 19:05.44 | putnopvut | FlaPer87: in the source, there's a document called CODING-GUIDELINES in the doc directory. |
| 19:06.49 | putnopvut | http://svnview.digium.com/svn/asterisk/trunk/doc/CODING-GUIDELINES?view=log |
| 19:06.52 | putnopvut | oops |
| 19:06.57 | putnopvut | http://svnview.digium.com/svn/asterisk/trunk/doc/CODING-GUIDELINES?view=markup |
| 19:07.01 | putnopvut | that should be better |
| 19:07.34 | FlaPer87 | putnopvut: thanks a lot |
| 19:07.36 | FlaPer87 | ;) |
| 19:13.21 | FlaPer87 | putnopvut: does tilghman uses the same nick in irc? I need to ask him some things |
| 19:13.22 | FlaPer87 | =) |
| 19:13.47 | Corydon76-dig | Nope |
| 19:13.58 | Corydon76-dig | Just ask the channel |
| 19:14.29 | FlaPer87 | Corydon76-dig: ok, he says "I would prefer if your CDR driver scanned the structure of the database and created an insertion statement to match, instead of relying upon a static structure. Most of the CDR drivers are done this way in trunk." |
| 19:14.56 | FlaPer87 | the thing is that mongodb is schemeless and it doesn't have a structure, so I just get the fields passed and insert them into the collections |
| 19:15.03 | FlaPer87 | collection* |
| 19:15.41 | FlaPer87 | when The cdr is used for the first time the collection might not exist so I just can't scan it to know what attrs should I save there |
| 19:15.58 | FlaPer87 | did he meant that? or I just missunderstood point 4? |
| 19:16.31 | Corydon76-dig | Wow, that's... strange... |
| 19:17.10 | seanbright | FlaPer87: Corydon76-dig is tilghman |
| 19:17.12 | seanbright | just fyi |
| 19:17.41 | FlaPer87 | seanbright: oh, thanks =) |
| 19:17.51 | FlaPer87 | didn't know that XD |
| 19:17.53 | FlaPer87 | sorry |
| 19:17.59 | FlaPer87 | Corydon76-dig: hi, thanks for reviewing the code |
| 19:18.03 | Corydon76-dig | In that case, you should probably insert everything |
| 19:18.32 | Corydon76-dig | All CDR standard fields, + all arbitrary variables stored in the CDR varlist |
| 19:19.09 | FlaPer87 | yeap, you're right, I just wanted to make users decide on uniqueid and userfield because the might not want those |
| 19:19.21 | Corydon76-dig | Why? |
| 19:19.41 | FlaPer87 | I should add the ones stored in the CDR varlist |
| 19:20.16 | Corydon76-dig | The whole point of those was that they were not there originally, and for dumb interfaces, the insert needs to match the structure. You just told me there is no defined structure, so there's no need to exclude any fields |
| 19:20.17 | FlaPer87 | Corydon76-dig: maybe users are not interested on those and that would use more space |
| 19:20.44 | Corydon76-dig | At worst, userfield is blank and should use zero space |
| 19:21.02 | FlaPer87 | Corydon76-dig: got it, I will add them |
| 19:21.08 | FlaPer87 | thanks for the advise |
| 19:21.10 | FlaPer87 | ;) |
| 19:21.44 | FlaPer87 | btw, I added the unregister call in the unload function, but I didn't find any extra unallocated memory |
| 19:22.11 | Corydon76-dig | Everywhere you're doing either a malloc or a calloc in the load routine... |
| 19:22.28 | Corydon76-dig | i.e. most of the database parameters are in allocated space |
| 19:22.37 | Corydon76-dig | ast_str_create, for example |
| 19:23.02 | FlaPer87 | ok, I'll check that |
| 19:27.31 | Corydon76-dig | Now, if you are going to allow disabling fields in your config, I'd want the field names to be completely arbitrary... [fields] disable=foo disable=disposition etc. |
| 19:29.48 | Corydon76-dig | Or if you can come up with another syntax that allows for arbitrary fieldnames, I'd be open to that |
| 19:30.34 | FlaPer87 | uoks, I think that I'm going to save all fields for now, If anyone asks for that feature then I'll work on that |
| 19:31.26 | Corydon76-dig | Another feature that people like is the "static" field feature, which associates a static value with every record entered... |
| 19:32.04 | Corydon76-dig | That allows you to log multiple machines to one database, yet still maintain information on which machine entered which rows, without altering the generation of the uniqueid field |
| 19:33.24 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 19:33.31 | FlaPer87 | hmmm interesting, never used that before, I can add that.... as soon as I free all memory lol |
| 19:39.42 | Corydon76-dig | If you enable MALLOC_DEBUG, you'll get "memory show allocations cdr_mongodb.c", which you can use to verify allocations |
| 19:40.51 | FlaPer87 | Corydon76-dig: wow, that's really usefule |
| 19:44.18 | FlaPer87 | useful* |
| 20:05.53 | seanbright | tzafrir_laptop: just used live-ast for the first time - awesome |
| 20:07.14 | *** join/#asterisk-dev caio1982 (~caio1982@CAcert-br/caio1982) |
| 20:12.10 | leifmadsen | what is live_ast? |
| 20:12.18 | pabelanger | the bomb! |
| 20:12.29 | pabelanger | contrib/scripts/live_ast |
| 20:12.31 | leifmadsen | runs from times square |
| 20:14.08 | seanbright | live_ast let's you 'install' and run asterisk inside your source directory |
| 20:15.28 | pabelanger | Its great if you need to test something between different Asterisk revisions, or even a patch. |
| 20:45.10 | jmls | yuk! |
| 20:46.02 | jmls | I have an inbound skype (callmefrank) and an inbound DDI (01702444999) and I want both to be handled by the same exten => |
| 20:46.20 | jmls | i can't use _X. coz it doesn't match callmefrank |
| 20:46.33 | jmls | if I use _. asterisk bitches like hell |
| 20:47.56 | jmls | suppose I could goto(1${exten}) for the callmefrank |
| 20:48.07 | jmls | yuk! |
| 20:48.20 | kpfleming | umm... this is simple |
| 20:48.24 | leifmadsen | jmls: _[0-9A-Za-z]. |
| 20:48.31 | jmls | in 1.4 ? |
| 20:48.34 | kpfleming | exten => callmefrank,1,NoOp() |
| 20:48.45 | kpfleming | exten => 01702444999,1,NoOp() |
| 20:48.52 | kpfleming | wait... no it's not |
| 20:48.53 | kpfleming | never mind |
| 20:48.59 | jmls | heh |
| 20:49.20 | leifmadsen | jmls: pretty sure that works in 1.4... |
| 20:49.25 | leifmadsen | been years since I used 1.4 though :D |
| 20:49.29 | seanbright | it should |
| 20:49.31 | kpfleming | yes, that should work in 1.4 |
| 20:49.31 | jmls | _cool_ :P |
| 20:49.50 | jmls | I've been hunting everywhere for that, never found it |
| 20:49.56 | jmls | thx |
| 20:50.15 | leifmadsen | I usually just match on the extensions you want to match on, then Goto(realHandler,1) |
| 20:50.43 | jmls | uses lots of ${EXTEN}. Naughty, I know .. |
| 20:50.44 | leifmadsen | you're going to hate typing out _[0-9a-zA-Z].,n,AnotherLine() |
| 20:50.54 | jmls | searchandreplace |
| 20:50.56 | jmls | ;) |
| 20:50.56 | leifmadsen | which is why same => n is niiiiice |
| 20:51.11 | jmls | .me uses n all over |
| 20:51.14 | leifmadsen | right |
| 20:51.15 | leifmadsen | same => |
| 20:51.20 | leifmadsen | is like 'n', but for extensions |
| 20:51.22 | leifmadsen | (not in 1.4) |
| 20:51.27 | jmls | bugger |
| 20:51.33 | seanbright | waits for except => |
| 20:51.34 | leifmadsen | but that's why I just do: |
| 20:51.55 | leifmadsen | exten => _[0-9a-zA-Z].,1,Set(savedExten=${EXTEN}) |
| 20:52.07 | leifmadsen | exten => _[0-9a-zA-Z].,n,Goto(handler,1) |
| 20:52.13 | leifmadsen | then you only need to type it twice :) |
| 20:52.16 | jmls | leifmadsen: hindsight is a wonderful thing |
| 20:52.23 | jmls | has a task to clean up like that |
| 20:55.59 | kpfleming | leifmadsen: except that has a flaw... for any patterns that you actually don't want match, it will match and then have to hangup or something |
| 20:56.21 | *** join/#asterisk-dev alecdavis (~alec@202.36.76.21) |
| 21:00.51 | *** part/#asterisk-dev rrb3942 (~rbullock@208.34.105.161) |
| 21:32.55 | moy | russellb: is the asterisk rtp stuff multithreaded? as in I can do ast_rtp_read() in one thread and ast_rtp_write() in another on the same rtp session? or is that looking for trouble? :P |
| 21:33.22 | kpfleming | he's not here at the moment |
| 21:33.25 | kpfleming | but yes, that should be safe |
| 21:33.33 | moy | oh thanks |
| 21:33.47 | kpfleming | but that's 'thread-safe', not 'multithreaded' :-) |
| 21:33.53 | moy | ah |
| 21:33.57 | moy | yes indeed |
| 21:47.29 | russellb | why do you ask? |
| 22:11.06 | moy | russellb: I'm seeing a crash, in ast_smoother_read() which is called by ast_rtp_write() ... which points to possibly 2 threads modifying the same smoother |
| 22:11.21 | russellb | hm, interesting |
| 22:11.34 | moy | but in the code I see only ast_rtp_write uses the smoother, so I guess should be safe |
| 22:27.17 | Kobaz | hmm |
| 22:27.28 | Kobaz | i'm getting all kinds of xml errors in 1.6.2.7 |
| 22:27.44 | Kobaz | that it can't find basically everything in the xml... but yet everything is there |
| 22:28.01 | Kobaz | [May 6 18:26:58] WARNING[3113]: xmldoc.c:1720 xmldoc_build_field: Couldn't find application PlayTones in XML documentation |
| 22:28.12 | Kobaz | <PROTECTED> |
| 22:28.18 | Kobaz | it's very much there |
| 22:28.38 | Kobaz | strace shows the file being opened successfully |
| 22:30.24 | putnopvut | Kobaz: try running make validate-docs to see if there is some sort of xml error somewhere else. |
| 22:31.15 | Kobaz | k |
| 22:33.02 | Kobaz | oh |
| 22:33.04 | Kobaz | yeah |
| 22:33.06 | Kobaz | all kinds of errors |
| 22:33.11 | Kobaz | it's my own stuff : |
| 22:33.13 | Kobaz | :P |
| 22:35.31 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 22:36.04 | leifmadsen | Kobaz: but not in vanilla asterisk right? bamboo is supposed to pick up on that... |
| 22:39.37 | russellb | leifmadsen: 1.6.2 branch is still happy |
| 22:39.44 | leifmadsen | yay! |
| 22:39.53 | leifmadsen | must be a loca change then :) |
| 22:40.48 | russellb | happy in the tag, too |
| 22:41.02 | Marquis42 | Now that there is both a framework for unit tests and an external test suite for Asterisk, I've been thinking about the AEL tests that reside pbx/ael/ael-tests in the source. Does anybody think there is value in converting those to be unit and/or functional tests? |
| 22:41.56 | russellb | Yeah. I don't remember how they work, so I'm not sure the best place for them |
| 22:42.01 | russellb | probably the test suite |
| 22:42.30 | leifmadsen | I think it makes sense if there are existing tests for them to be merged into one of the testing frameworks ya |
| 22:42.33 | Kobaz | leifmadsen: yeah it's not a problem in vanilla, i had docs i had ported from trunk |
| 22:42.38 | leifmadsen | gotcha |
| 22:42.40 | Kobaz | 1.6.2 doesn't have <manager> xml |
| 22:42.42 | Marquis42 | At the moment they run aelparse to output an extensions.conf-style file and just diffs the two. |
| 22:42.44 | leifmadsen | ahh |
| 22:46.02 | Kobaz | okay much better |
| 22:46.04 | Kobaz | no more xml errors |
| 22:49.34 | Kobaz | wow |
| 22:49.36 | Kobaz | i dont know what i did |
| 22:49.41 | Kobaz | but i broke 1.6.2.7 |
| 22:49.42 | Kobaz | [May 6 18:47:46] ERROR[3380]: utils.c:529 lock_info_destroy: Thread 'handle_tcptls_connection started at [ 276] tcptls.c ast_tcptls_server_root()' still has a lock! - '&c->lock_dont_use' (0xb7fa6e0) from 'channel_find_locked' in channel.c:1238! |
| 22:50.47 | jpeeler | alecdavis: think you have a chance to commit your voicemail escape review? i might do it for you just to get rid of one open review... |
| 22:52.23 | Kobaz | so umm |
| 22:52.26 | Kobaz | i broke it |
| 22:52.30 | Kobaz | points |
| 22:52.32 | Kobaz | it's dead |
| 22:52.36 | Kobaz | gone |
| 23:06.24 | Kobaz | i did it again |
| 23:06.30 | Kobaz | well at least it's reproducable |
| 23:07.08 | Kobaz | there's something horribly wrong |
| 23:11.46 | Kobaz | well, i'll play with it tomorrow |
| 23:11.49 | Kobaz | gym time |
| 23:22.06 | *** join/#asterisk-dev Netgeeks (~chris@173.11.68.155) |