| 01:00.31 | *** join/#asterisk-dev Ta^3 (~tacvbo@189.146.190.221) |
| 01:13.37 | *** join/#asterisk-dev Jacke (jacke@czokopinda.niebanalni.com) |
| 01:13.47 | Jacke | hello |
| 01:23.22 | *** join/#asterisk-dev ZX81 (~Matt_Ridd@121-74-248-216.telstraclear.net) |
| 01:23.46 | *** part/#asterisk-dev ZX81 (~Matt_Ridd@121-74-248-216.telstraclear.net) |
| 01:35.09 | *** join/#asterisk-dev ZX81 (~Matt_Ridd@121-74-248-216.telstraclear.net) |
| 01:35.27 | *** part/#asterisk-dev ZX81 (~Matt_Ridd@121-74-248-216.telstraclear.net) |
| 01:48.30 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 01:52.49 | *** join/#asterisk-dev LauPro (~LauPro@87.233.6.201) |
| 01:53.01 | LauPro | i'm trying to implement a channel in asterisk |
| 01:53.17 | LauPro | this channel has to register itself to an another server (peer) |
| 01:53.33 | LauPro | what is the best way to setup the connection for this registers with the asterisk API? |
| 02:07.22 | russellb | the only thing a channel driver registers is the ast_channel_tech interface |
| 02:07.40 | russellb | the asterisk core doesn't know or care about registrations, that is a technology implementation detail |
| 02:09.31 | *** join/#asterisk-dev xpot-mobile (~xpot@70-91-210-233-BusName-Utah.hfc.comcastbusiness.net) |
| 02:33.32 | *** join/#asterisk-dev pentanol (~Unknown@91.195.60.231) |
| 02:34.09 | pentanol | hi, anyone alive there? |
| 02:35.36 | russellb | nope |
| 02:35.41 | pentanol | I've question relater sip authentication... what from I may receive md5 or just key which sent the client to my asterisk server? |
| 02:35.54 | russellb | eh? |
| 02:35.55 | pentanol | usually it's looks like a token |
| 02:36.22 | pentanol | keys[K_USER].s it's kind of user name |
| 02:36.50 | pentanol | and there keys[K_RESP].s weird data in MD5 |
| 02:37.47 | pentanol | I'm looking for variable where I may receive user passwork in MD5 or not so as to compare it with my database password |
| 02:40.23 | russellb | are you even talking about asterisk? the "keys" thing you referred to is not familiar |
| 02:40.47 | pentanol | of course |
| 02:41.01 | russellb | where did you get "keys[K_USER]" ? |
| 02:41.07 | pentanol | ther channels/chan_sip.c |
| 02:41.10 | pentanol | there |
| 02:41.12 | russellb | orly. |
| 02:41.20 | pentanol | yes |
| 02:41.32 | russellb | oh yeah, sure enough, sorry. |
| 02:41.50 | pentanol | I guess it's room for development? |
| 02:42.31 | russellb | yes. sorry, I just haven't looked at that function in a long time, anyway ... |
| 02:42.31 | russellb | there is no variable that contains what the user thinks their password is |
| 02:42.43 | russellb | that's the whole point of the MD5 auth, not sending the pw in the clear |
| 02:43.57 | pentanol | yep, I knows it, but there kind of hash of hash |
| 02:44.51 | russellb | hash of hash? |
| 02:45.17 | pentanol | i.e. variables md5secret and secret comes from configuration.... and then it do hasheswith them |
| 02:46.24 | pentanol | ast_md5_hash(a2_hash, a2); snprintf(resp, sizeof(resp), "%s:%s:%s", a1_hash, usednonce, a2_hash); ast_md5_hash(resp_hash, resp); |
| 02:46.44 | pentanol | looks liek hash of hash, or it's not? |
| 03:18.48 | jsmith | It's how the SIP digest authentication works |
| 03:18.55 | jsmith | It's very similar to HTTP digest authentication |
| 03:19.30 | jsmith | Alice tries to make a call to Asterisk |
| 03:19.41 | jsmith | Asterisk tells her to authenticate, and gives her a nonce to use |
| 03:20.01 | jsmith | Alice hashes her password and the nonce (and a few other items, like the Request URI), and sends that to Asterisk |
| 03:20.07 | jsmith | Asterisk calculates the same has on its side |
| 03:20.13 | jsmith | (using the nonce it sent to Alice) |
| 03:20.24 | jsmith | If the hashes match, Alice obviously has the right password |
| 03:59.41 | pentanol | jsmith IOW, I should inqure password from some where and then do crypt() aso as to compute digest? |
| 04:00.55 | jsmith | My question is this... why are you worrying about creating your own hash of the password? |
| 04:08.00 | pentanol | jsmith I'm not worrying, I haven't way how I may get password from radius by query |
| 07:15.15 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 07:15.16 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 07:41.53 | pentanol | jsmith haven't any idea |
| 07:45.31 | *** join/#asterisk-dev mpe (~mpe@94.127.49.1) |
| 08:07.25 | *** join/#asterisk-dev fiddur (~fiddur@192.121.104.121) |
| 08:43.12 | *** join/#asterisk-dev mpe (~mpe@gate.ipvision.dk) |
| 09:15.52 | *** join/#asterisk-dev dseeb_ (~Adium@CPE-58-169-81-65.lns1.bat.bigpond.net.au) |
| 09:21.24 | *** join/#asterisk-dev Dovid (~annon@tony09-118-62.inter.net.il) |
| 09:51.36 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 11:10.32 | *** join/#asterisk-dev pentanol (~pentanol@77.35.48.247) |
| 11:10.37 | pentanol | anyone? how I may enquire password from database via radius? I can do just select and checkout sip-account, but so as to do sip authorization I need enquire password and then compute digest.... |
| 11:42.51 | *** join/#asterisk-dev caio1982 (~caio1982@CAcert-br/caio1982) |
| 12:24.43 | *** join/#asterisk-dev m_c_le (~marcello@dslb-088-074-131-094.pools.arcor-ip.net) |
| 12:24.43 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:24.44 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:29.01 | *** join/#asterisk-dev davidded (foobar@dslb-084-059-192-031.pools.arcor-ip.net) |
| 12:29.09 | davidded | hello |
| 12:33.15 | davidded | any of you guys experienced with use of main/bridging.c ? |
| 13:30.32 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 13:33.39 | tzafrir_laptop | davidded, you happen to be "Marcello Ceschia" who asked in the dev list about the bridging API? |
| 13:33.55 | tzafrir_laptop | (If not: just ask a more specific question) |
| 14:33.30 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:33.30 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 14:37.32 | davidded | tzafrir_laptop: No i am not Marcello, but his colleague in the project :) |
| 14:37.51 | davidded | The specific question would be how to properly attach existing bridged channels to a conference bridge: |
| 14:38.09 | davidded | An idea would be to masquerade the channels to newly created channels that are attached to the conference bridge, |
| 14:38.15 | russellb | It's not straight forward, unless the initial bridge is using the bridging API |
| 14:38.24 | davidded | but then these channels lack a pbx or dial thread and cannot be hung up, etc. |
| 14:38.27 | tzafrir_laptop | davidded, I suppose you're aware of apps/app_cofbridge.c , right? |
| 14:38.42 | russellb | you could masquerade them away into a new thread that is bridging them all using the bridging API, but that is much more complicated to get right |
| 14:38.56 | davidded | yes, i am aware of that app, but we would prefer to manage the bridge ourselves, since we want to control the conference via the phone softkeys. |
| 14:39.27 | davidded | you mean to write a custom control thread that takes care of hanging up channels? |
| 14:41.24 | davidded | incidentally, the app_confbridge crashes when i use it just the regular way over the dialplan. What happens is that * segfaults when I hang up one of the participants. |
| 14:48.22 | *** join/#asterisk-dev m_c_le (~marcello@dslb-088-074-131-094.pools.arcor-ip.net) |
| 14:52.36 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:52.36 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:55.53 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:55.53 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:13.39 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:13.39 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:30.17 | jmls | hey guys |
| 15:30.29 | jmls | is perusing the bugs list |
| 15:30.33 | jmls | M16834 |
| 15:30.35 | MuffinMan | [new] [Asterisk] Applications/app_queue 0016834: [patch] [regression][patch] autofill=no always IGNORED. reported by kebl0155 https://issues.asterisk.org/view.php?id=16834 |
| 15:30.46 | jmls | seems if this gets fixed, it fixes 3 issues. |
| 15:30.51 | jmls | gotta be value for money ;) |
| 15:32.25 | atis_work | huh, i always use autofill=yes :P |
| 15:33.37 | jmls | atis_work: :-D |
| 15:35.14 | *** join/#asterisk-dev Deeewayne (~dwayne@75.76.254.162) |
| 15:35.15 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 15:35.37 | atis_work | btw, just set up our clustered queue today.. theoretically several servers should be able to send calls to agents :p |
| 15:35.57 | russellb | nice. |
| 15:36.06 | atis_work | and ugly patches.. |
| 15:36.38 | atis_work | i use curl and http daemon for keeping locks on agents between servers |
| 15:38.50 | Corydon76-dig | You mean CURL() ? |
| 15:39.07 | atis_work | well, i put it inside app_queue wherever i needed to lock agent |
| 15:39.55 | atis_work | as far as i understood distributed devstate wouldn't be useful for that |
| 15:47.09 | *** join/#asterisk-dev Abdou`` (~abdou@41.227.228.124) |
| 15:51.01 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 15:51.01 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 15:51.14 | seanbright | so revision 246546 |
| 15:51.26 | seanbright | the lock the channel during datastore removal change |
| 15:51.37 | The_Boy_Wonder | oh boy |
| 15:51.39 | The_Boy_Wonder | what did i do |
| 15:51.45 | seanbright | heh, nothing, just have a stupid question |
| 15:51.53 | The_Boy_Wonder | about that lock? |
| 15:51.57 | seanbright | no |
| 15:52.00 | seanbright | the one immediately after it |
| 15:52.05 | seanbright | seems unnecessary now? |
| 15:52.14 | The_Boy_Wonder | umm yep, seems that way |
| 15:52.52 | seanbright | ok, cool. |
| 15:52.54 | The_Boy_Wonder | but given that it's been there so long, and I really don't fully understand it, i'm scared to take it away |
| 15:53.03 | seanbright | ah :-) |
| 15:54.38 | seanbright | well now we lock, do something, lock, unlock, lock |
| 15:54.40 | seanbright | err |
| 15:54.55 | seanbright | lock, do something, unlock, lock, unlock |
| 15:56.13 | seanbright | your addition of the lock/unlock around the removal seems to accomplish the same thiing |
| 15:56.17 | seanbright | thing* |
| 15:56.32 | The_Boy_Wonder | right, but what if something is waiting for the lock, and right after we unlock (first lock/unlock) it they grab it and then we free the channel |
| 15:56.47 | The_Boy_Wonder | basically this was before ref counting, and it was a very poor way of doing it |
| 15:57.04 | russellb | is the datastore junk after removing from the channel list? |
| 15:57.06 | seanbright | well i'm saying we skip the first unlock |
| 15:57.22 | seanbright | so they won't get the lock they are waiting on until we are done |
| 15:57.40 | The_Boy_Wonder | right, but what if during the datastore removal, it triggers a thread that has to clean up, and during that clean up it needs to lock the channel |
| 15:57.44 | seanbright | because the channel might not be there? |
| 15:57.58 | seanbright | gotcha |
| 15:57.59 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:58.00 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:58.16 | russellb | the short answer is seanbright is right, the extra lock/unlock is now unnecessary |
| 15:58.36 | russellb | The_Boy_Wonder: and dear god that is just plain evil and not supported |
| 15:58.38 | The_Boy_Wonder | i'm not completely sure if that is the case russell |
| 15:58.47 | The_Boy_Wonder | mixmonitor does something like that i believe |
| 15:58.49 | russellb | that better not be the case, or the code still isn't right |
| 15:58.53 | russellb | :-( |
| 15:58.59 | The_Boy_Wonder | i could be wrong |
| 15:59.00 | *** join/#asterisk-dev mnt_real (~sinan@bas1-montreal43-1177754737.dsl.bell.ca) |
| 15:59.01 | *** join/#asterisk-dev jpeeler (~jpeeler@asterisk/digium-software-dev/jpeeler) |
| 15:59.01 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:59.05 | The_Boy_Wonder | i dunno, i need coffee |
| 15:59.09 | russellb | k, we should look. |
| 15:59.14 | russellb | coffee is good. |
| 15:59.35 | seanbright | i'll let you gents look before i make that change to my production version |
| 15:59.39 | Corydon76-dig | Screw coffee. We just need caffeine IVs installed in our offices. |
| 16:00.17 | russellb | the code that's there isn't going to hurt anything, it just may be technically not necessary |
| 16:00.33 | leifmadsen | i need coffee too... |
| 16:01.22 | seanbright | well we unlock and lock when we might not need to |
| 16:01.24 | seanbright | that takes cycles, right? |
| 16:01.41 | russellb | yeah, but it won't break anything. |
| 16:01.46 | seanbright | right |
| 16:02.00 | seanbright | i just like micro-optimizations |
| 16:02.10 | seanbright | --i |
| 16:02.11 | kpfleming | premature micro-optimizations? |
| 16:02.13 | leifmadsen | micro optimizes seanbright away |
| 16:02.19 | seanbright | i--; |
| 16:02.25 | seanbright | or whatever |
| 16:02.26 | seanbright | heh |
| 16:10.07 | *** join/#asterisk-dev CunningPike (~CunningPi@S01060014bf81366b.vc.shawcable.net) |
| 16:15.50 | *** join/#asterisk-dev marv (~timr@router.asteriasgi.com) |
| 16:16.23 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 16:23.09 | putnopvut | seanbright: --i for life! |
| 16:24.07 | Corydon76-dig | If we keep --seanbright, he'll be negative soon. |
| 16:24.10 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 16:24.10 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 16:24.23 | jsmith | It's all about the "jnz" instruction, right? |
| 16:26.10 | *** join/#asterisk-dev moy (~moy@74.12.129.100) |
| 16:32.23 | kpfleming | jsmith: that's the Jay-Z instruction :-) |
| 16:34.30 | jsmith | kpfleming: No, jz is "Jump if Zero"... jnz would be the opposite... "Jump if Not Zero" |
| 16:34.49 | kpfleming | yes, i know, but i had to make it that way to bring in the pop culture reference |
| 16:35.02 | jsmith | claims to know nothing about pop culture? |
| 16:35.13 | jsmith | (and how does one culture soda pop, anyway?) |
| 16:35.27 | kpfleming | Coca-Cola, now with live active cultures! |
| 16:35.31 | file | carefully. |
| 16:35.45 | Corydon76-dig | jsmith: quite easily, actually |
| 16:36.13 | Corydon76-dig | You just have to release the pressure regularly to ensure it doesn't kill the yeast |
| 16:36.45 | Corydon76-dig | Not that I have any experience brewing alcohol in a soda pop bottle or anything |
| 16:38.37 | Qwell | kpfleming: You might be on to something there. Coca-Cola flavored yogurt |
| 16:38.46 | kpfleming | retches |
| 16:38.48 | Corydon76-dig | (in a dorm room, no less) |
| 16:38.57 | file | Qwell: ugh |
| 16:39.11 | jmls | seanbright == mmichelson ? |
| 16:39.42 | putnopvut | jmls: I wish! |
| 16:39.45 | putnopvut | Wait, no I don't! |
| 16:39.58 | jmls | damn, bad guess :( |
| 16:40.00 | putnopvut | I am mmichelson |
| 16:40.09 | jmls | heh |
| 16:40.34 | jmls | putnopvut: (!) thanks for fixing 16834 |
| 16:40.46 | Corydon76-dig | putnopvut: you wish you were writing a predictive dialer? |
| 16:40.56 | jmls | that's a real nice number, from a dyslexic point of view .. |
| 16:40.57 | *** join/#asterisk-dev MAbbas (~abbas4u@203.215.177.194) |
| 16:41.08 | putnopvut | jmls: Yeah, I saw you mention it, and I figured I caused the problem, so I got right on it. |
| 16:41.08 | *** join/#asterisk-dev Victor_Yure (~victor@unaffiliated/victoryure/x-837844) |
| 16:41.32 | seanbright | i am seanbright |
| 16:41.38 | MAbbas | I am using Dial() to connect a call to an agent. Agent is free but I get following warning says Agent is busy. |
| 16:41.39 | MAbbas | [Feb 17 13:18:29] WARNING[25075]: app_dial.c:1183 dial_exec_full: Unable to create channel of type 'Agent' (cause 17 - User busy) |
| 16:42.01 | jmls | wouldn't be surprised that in "C", == ,means <> ... :) |
| 16:42.39 | jmls | MAbbas: try #asterisk-users |
| 16:54.35 | *** join/#asterisk-dev ccesario (~ccesario@189-19-6-236.dsl.telesp.net.br) |
| 16:55.50 | Qwell | Can you overload <> in c++ (I fully realize it isn't an actual operator)? |
| 16:56.22 | Qwell | I guess my question is.. can you overload arbitrary "operators"? example: x banana y; |
| 16:56.32 | seanbright | no |
| 16:56.37 | Qwell | shame |
| 16:56.44 | seanbright | agreed |
| 16:56.57 | seanbright | that would make for some totally unmaintanable code |
| 16:57.02 | seanbright | shucks! |
| 16:57.02 | seanbright | heh |
| 16:57.11 | Qwell | x banana y; is practically self-describing |
| 17:00.09 | *** join/#asterisk-dev davidbrillert (~aragon125@h216-235-8-130.host.egate.net) |
| 17:01.43 | putnopvut | Qwell: you could always make a method called banana in class x that takes a y as an argument though. x.banana(y); |
| 17:01.47 | Corydon76-dig | Qwell: like bananaguide.com ? NSFW |
| 17:01.53 | Qwell | putnopvut: that's no fun though |
| 17:13.25 | *** join/#asterisk-dev oej_ (~olle@95.209.10.223.bredband.tre.se) |
| 17:13.25 | *** mode/#asterisk-dev [+o oej_] by ChanServ |
| 18:16.47 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 18:17.23 | *** join/#asterisk-dev mnick86 (~mnick86@188-195-89-74-dynip.superkabel.de) |
| 18:17.32 | mnick86 | Hey, how can I enable the test_framework ? |
| 18:18.37 | mnick86 | I can't find the TEST_FRAMEWORK option in "compiler flags" |
| 18:21.00 | *** join/#asterisk-dev oej (~olle@109.58.50.127.bredband.tre.se) |
| 18:21.00 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:48.49 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 18:50.50 | *** join/#asterisk-dev gseven (~g@chello089078232124.chello.pl) |
| 18:58.21 | *** join/#asterisk-dev oej (~olle@109.58.19.225.bredband.tre.se) |
| 18:58.22 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:59.37 | *** join/#asterisk-dev davidded (foobar@dslb-084-059-192-031.pools.arcor-ip.net) |
| 19:02.04 | kpfleming | wow... these unit tests being written are just awesome. |
| 19:10.04 | leifmadsen | I like awesome |
| 19:12.33 | snuff-home | mmm.. an enum test would be nice.. but it depends on dns rather than just a internal function |
| 19:13.51 | snuff-home | we have some 'dialplan' related tests from when we increased the enum options |
| 19:14.06 | snuff-home | (that were uploaded to the bugtraker) |
| 19:15.50 | kpfleming | well... that could either be accomplished by publishing the ENUM "test case" entries in a special zone under asterisk.org, or using a lightweight DNS server on the test slave itself to serve up the entries |
| 19:17.58 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 19:49.24 | *** join/#asterisk-dev Victor_Yure (~victor@unaffiliated/victoryure/x-837844) |
| 20:17.10 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 20:22.21 | putnopvut | Yay, I definitely found a for-real, legitimate bug in the ast_str code! |
| 20:22.30 | putnopvut | dances |
| 20:23.32 | putnopvut | Supposedly, if you pass a max_len of -1 to ast_str_set or ast_str_append, the result is that the max_len should be limited to the current allotted space for the ast_str. However, since the parameter passed around is a size_t, -1 is interpreted ast UINT_MAX, and so the bounding does not happen as it should. |
| 20:23.48 | kpfleming | sounds legit |
| 20:24.15 | putnopvut | yes, all the size_t max_len parameters need to be changed to a signed type. |
| 20:24.34 | putnopvut | I figure I'll change them to ints, since they're pretty fashionable this season. |
| 20:26.34 | file | an int from Gucci? |
| 20:26.41 | putnopvut | Dior |
| 20:26.58 | file | I'd go for the Jimmy Choo over Dior |
| 20:45.31 | *** join/#asterisk-dev d-k-t (~D@112.202.232.46) |
| 20:53.28 | Corydon76-dig | putnopvut: not a ssize_t ? |
| 20:53.45 | kpfleming | that would probably be a better choice |
| 20:54.05 | putnopvut | I'll go with that then, even though it's a bit *snob look* behind the times. |
| 20:54.28 | putnopvut | Might as well throw a slap bracelet and a perm on the code too. |
| 20:54.29 | Corydon76-dig | It is? |
| 20:55.01 | putnopvut | <PROTECTED> |
| 20:56.00 | Corydon76-dig | Code Runway? |
| 20:56.19 | file | grins |
| 20:56.30 | atis_work | is code runaway when you acciently hit ENTER on unfinished script? |
| 20:56.46 | Corydon76-dig | Project Runway? |
| 20:57.43 | Corydon76-dig | notes that it is not Friday |
| 20:58.15 | Corydon76-dig | putnopvut: good catch on the -1/unsigned type, though |
| 20:58.34 | Corydon76-dig | I'm surprised gcc hasn't sputtered a warning about that |
| 20:58.42 | putnopvut | I may have another bug to report in ast_str code in a sec. I'm furthering my research to make sure I'm right though. |
| 20:59.22 | Corydon76-dig | putnopvut: Tell us now, so we can crush your hopes |
| 20:59.45 | putnopvut | I will not have my hopes crushed! Not today at least! |
| 21:00.31 | atis_work | you will wake up at 3am with your hopes crushed then |
| 21:00.50 | putnopvut | Okay, I've definitely found a bug. Now to see to what extent it goes... |
| 21:01.59 | Corydon76-dig | Wait, how did my name wind up as the author of the strings.c file? |
| 21:02.15 | putnopvut | Corydon76-dig: did you move the code out of utils.c in 1.6.1? Maybe that's why? |
| 21:03.19 | Corydon76-dig | Ah, that might be it |
| 21:04.12 | Corydon76-dig | Yep, that's it |
| 21:04.19 | putnopvut | So, let me tell you of the bug I found. In short, we have an off-by-one error. |
| 21:04.55 | Corydon76-dig | Crud |
| 21:05.09 | putnopvut | If I have an ast_str sized at 15 bytes, and I try to write anywhere from a 1-14 byte string to the ast_str, then ast_str_strlen() properly reports the length of the string. If I try to write 15 or more bytes to the string, then 14 bytes are written, plus a null terminator. |
| 21:05.23 | putnopvut | In the latter case, ast_str_strlen reports the length of the string as 15. |
| 21:05.35 | Corydon76-dig | Heh, oops |
| 21:05.46 | putnopvut | ast_str_strlen should be reporting the length as 14 in that case. I'll look into where the problem is. |
| 21:06.37 | putnopvut | Oh, and this is for the case where we do not want the string to expand. I used a stack-allocated ast_str in this test. |
| 21:06.45 | Corydon76-dig | Line 109 |
| 21:07.10 | Kobaz | i think i found a bug when using hangup handlers and agi scripts |
| 21:07.12 | putnopvut | Ah, the true part of the ternary should have a -1 in there. |
| 21:07.16 | Corydon76-dig | add a -1 in the first section of the ternary |
| 21:07.26 | putnopvut | Yes, we think alike! :) |
| 21:07.39 | Kobaz | if you're current executing an AGI... and someone hangs up... 'h' runs... if defined |
| 21:07.45 | putnopvut | Thank you very much, Corydon76-dig. I'll have that and the ssize_t change committed shortly. |
| 21:07.54 | Kobaz | and then if you do a Hangup() from within 'h'... another hangup handler will get called |
| 21:08.00 | Kobaz | this is not the case when not using agi |
| 21:08.24 | putnopvut | Wait, calling Hangup within 'h' calls another hangup handler to be called? That sounds wrong. |
| 21:08.26 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 21:08.26 | Corydon76-dig | Kobaz: yes, it is |
| 21:08.27 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 21:08.36 | Corydon76-dig | Do not call Hangup from within the "h" extension. |
| 21:09.04 | seanbright | undefined behavior ftw! |
| 21:09.17 | Kobaz | Corydon76-dig: what if you want to bail early from an 'h' |
| 21:09.19 | Kobaz | return() ? |
| 21:09.27 | atis_work | so you can hangup telemarketers infinite amount of times? |
| 21:09.34 | atis_work | even if they call you just once? :D |
| 21:09.40 | Corydon76-dig | Kobaz: no, goto the end label, with a noop |
| 21:10.47 | Corydon76-dig | No, the issue is that there are multiple places where "h" is invoked, and it relies on the last invocation not returning error to verify that the "h" extension actually ran |
| 21:11.10 | Corydon76-dig | Otherwise, you can have situations where the "h" extension doesn't run at all |
| 21:11.24 | Kobaz | mm |
| 21:11.38 | Corydon76-dig | And the Hangup application JUST returns -1. That's all it does. Literally. |
| 21:11.45 | Kobaz | oh... interesting |
| 21:11.56 | Kobaz | would it be proper to make Hangup() return 0, if run from 'h' |
| 21:12.32 | Corydon76-dig | Kobaz: how would you know that, exactly, especially if somebody calls Gosub, Goto, or Macro, and you're no longer in the "h" extension when that happens? |
| 21:12.45 | Kobaz | then umm |
| 21:12.48 | Kobaz | hmm |
| 21:12.59 | Qwell | Kobaz: it would just go to the next priority if that happened, anyways |
| 21:13.10 | kpfleming | 'h' could put a flag/datastore on the channel to indicate *dude, we are in the 'h' extension right now" |
| 21:13.15 | Kobaz | yeah |
| 21:13.26 | Kobaz | if you jump out of it, you lose that flag |
| 21:13.39 | seanbright | no |
| 21:13.43 | seanbright | you keep the flag |
| 21:13.49 | seanbright | so you stop calling hangup handlers |
| 21:13.54 | Kobaz | oh yeah true... you don't want to invoke the h again |
| 21:14.05 | Kobaz | you could have recursive h'ing |
| 21:14.15 | atis_work | agreed |
| 21:14.31 | Kobaz | that sounds like it would work |
| 21:14.52 | Kobaz | any error after hitting h, would stop dialplan and kill the channel |
| 21:15.17 | Corydon76-dig | Any error, like "h" doesn't exist in this context? |
| 21:15.39 | Kobaz | and Hangup() from within h... or after h, via gosub, etc... would probably end the call, and have a non-error result |
| 21:16.11 | Kobaz | Corydon76-dig: well, like seanbright said... you stop calling hangup handlers once you hit the first one |
| 21:16.33 | Kobaz | so an 'h' doesn't exist type thing... would just use the normal error handling |
| 21:17.32 | Kobaz | if you haven't hit h yet... and h doesn't exist... it would do the same thing it does now... just hang up |
| 21:17.42 | putnopvut | Yay, my ast_str unit test passes now! |
| 21:17.48 | Kobaz | yay for unit tests |
| 21:17.51 | putnopvut | 1 commit and 1 review request coming up! |
| 21:18.03 | Kobaz | we have over 500 unit tests for our inhouse system |
| 21:18.59 | Kobaz | what would be nice... would be a hangup handler registration hook |
| 21:19.07 | Kobaz | rather than binding hangup handlers to contexts |
| 21:19.28 | Kobaz | so you can do... if i get *here*.. run this hangup handler... if i get *there*, also run this other hangup handler |
| 21:19.50 | Kobaz | so you can cascade them |
| 21:20.19 | atis_work | leifmadsen: huh, you set it ready for testing.. damn.. i don't know anyone who uses realtime meetme :p i just found that by using those lines as sample in my patches :p |
| 21:20.45 | Kobaz | i just use dynamic meetme |
| 21:20.51 | atis_work | me too |
| 21:20.55 | Kobaz | i never saw much of a need for realtime |
| 21:21.59 | Corydon76-dig | kpfleming: we actually use a channel flag to determine whether the "h" extension has run or not |
| 21:22.10 | atis_work | maybe it can go in without testing? ;-) |
| 21:22.37 | Kobaz | nothing should ever go in without testing |
| 21:22.57 | Corydon76-dig | kpfleming: but the logic is fairly complex, and the reasons why it's not set in certain circumstances... well, it's not something that's easily fixable |
| 21:23.14 | Corydon76-dig | kpfleming: it's in main/features.c, if you're curious |
| 21:23.15 | atis_work | then that fix will probably never arrive.. anyway only 1.6.1 and 1.6.0 are affected |
| 21:23.28 | Kobaz | atis_work: what's the bug? |
| 21:23.44 | atis_work | M16853 |
| 21:23.46 | MuffinMan | [ready for testing] [Asterisk] Applications/app_meetme 0016853: [patch] Memory leak in realtime meetme reported by atis https://issues.asterisk.org/view.php?id=16853 |
| 21:28.17 | seanbright | putnopvut: will that fix go into the branches as well? |
| 21:28.24 | putnopvut | seanbright: yes |
| 21:28.34 | putnopvut | I'm doing my test compiles right now. |
| 21:29.03 | seanbright | does a change from size_t to ssize_t change the ABI? |
| 21:29.18 | seanbright | i guess not. they are the same size. |
| 21:29.24 | putnopvut | It shouldn't. They're the same size, just interpreted as either signed or unsigned quanitites. |
| 21:29.27 | seanbright | right. |
| 21:29.33 | Corydon76-dig | Technically, yes, though |
| 21:30.19 | Corydon76-dig | should change the signature |
| 21:30.57 | Corydon76-dig | I don't think we support version linking, though |
| 21:31.20 | Corydon76-dig | Would be cool if we did... |
| 21:32.28 | seanbright | how does that work? |
| 21:32.36 | Corydon76-dig | Make a module that could be loaded against 1.4, 1.6.0, 1.6.1, 1.6.2, trunk... |
| 21:33.08 | Corydon76-dig | seanbright: essentially, it provides different link tables, each with a separate label |
| 21:34.03 | Corydon76-dig | glibc does the same thing. If a binary is linked against glibc 2.0, you can still run it against glibc 2.8, because it chooses a different link table at load time |
| 21:34.56 | Corydon76-dig | older ABIs, and the new APIs aren't available to the binary |
| 21:35.28 | Corydon76-dig | It's actually a pretty nice ELF link feature |
| 21:35.33 | seanbright | cool |
| 21:36.17 | Corydon76-dig | The new APIs not being available is actually a feature, to ensure that there aren't clashes between namespaces |
| 21:37.10 | putnopvut | atis_work: I once tried to go through the Asterisk source and fix all instances of what you fixed in 16853. I either missed that or that code was added after I made my rounds. |
| 21:38.36 | atis_work | putnopvut: so you can guarantee that fix is safe? :D it's actually correct in 1.4 and 1.6.2, don't know why some branches missed that |
| 21:39.05 | putnopvut | That may have been my doing then. I may have missed some branches. |
| 21:39.43 | putnopvut | Yeah, the idea is that you have to keep a pointer to the first ast_variable in the list so that when you call ast_variables_destroy, you destroy all of them, not just the last one (or NULL as it was in your case) |
| 22:44.53 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-155-146.cablep.bezeqint.net) |
| 22:44.53 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 23:00.42 | Kobaz | do de do |
| 23:00.50 | Kobaz | maybe you guys know... |
| 23:01.15 | Kobaz | do the core and channel drivers update DEVICE_STATE? or do i have to set it myself in dialplan |
| 23:05.50 | Kobaz | okay... i figured it out |
| 23:06.03 | Kobaz | if a phone is bridged to dialplan, DEVICE_STATE reports NOT_INUSE |
| 23:06.26 | Kobaz | this is probably a bug? or at the minimum a missing feature |
| 23:06.35 | mvanbaak | The_Boy_Wonder: thanks ! |
| 23:07.00 | kpfleming | a phone cannot be bridged to a dialplan |
| 23:07.08 | kpfleming | there are at least three things wrong with that statement |
| 23:07.10 | Kobaz | well, whatever it's called |
| 23:07.11 | Kobaz | hehe |
| 23:07.33 | Kobaz | when a device is executing dialplan |
| 23:07.38 | mvanbaak | 3 out of 8,.... not bad ;) |
| 23:07.41 | Kobaz | asterisk reports DEVICE_STATE as NOT_INUSE |
| 23:07.51 | mvanbaak | still more then 50% correct ;) |
| 23:08.17 | Kobaz | what am i missing? |
| 23:08.18 | Kobaz | heh |
| 23:08.33 | mvanbaak | 00:09 <@ kpfleming> a phone cannot be bridged to a dialplan |
| 23:08.37 | mvanbaak | 8 words |
| 23:08.41 | mvanbaak | 00:09 <@ kpfleming> there are at least three things wrong with that statement |
| 23:08.45 | mvanbaak | 3 errors |
| 23:09.03 | Kobaz | i gather the errors are: phone, bridge, dialplan |
| 23:09.10 | mvanbaak | yup ! |
| 23:09.15 | Kobaz | so |
| 23:09.20 | Kobaz | if you take them out... you get |
| 23:09.23 | Kobaz | a cannot be to a |
| 23:09.44 | mvanbaak | yup. and that's correct ! |
| 23:09.48 | kpfleming | the correct question would be: if a device's channel is executing an application in the PBX... |
| 23:09.59 | Kobaz | ah yes |
| 23:10.10 | Qwell | the other two were DEVICE_STATE and NOT_INUSE |
| 23:10.15 | mvanbaak | the right answer is: if it blows up, you get the pieces. |
| 23:10.32 | Kobaz | what's wrong with those? |
| 23:11.03 | mvanbaak | Qwell: you involved in the panda-food setup as well eh ? |
| 23:11.10 | Kobaz | SIP/foo dials exten@context... and is listening to something in Playback |
| 23:11.17 | Qwell | mvanbaak: O.o |
| 23:11.29 | mvanbaak | panda's eat bamboo :) |
| 23:11.32 | Kobaz | if, in dialplan you do... NoOp(${DEVICE_STATE(SIP/foo)}) |
| 23:11.37 | Kobaz | then you get... NOT_INUSE |
| 23:11.53 | Kobaz | but it seems to me... the device is very much in use |
| 23:12.15 | mvanbaak | or is it: pandas |
| 23:12.22 | mvanbaak | hides for kpfleming |
| 23:13.02 | Kobaz | i guess it depends upon the meaning of in use |
| 23:13.18 | Kobaz | which should probably be expanded to include, device's channels executing dialplan in asterisk |
| 23:13.43 | seanbright | if only the source code was available for reference... |
| 23:13.52 | mvanbaak | Qwell: I'll have the 32 and 64 bit bamboo buildslaves ready this weekend |
| 23:14.02 | seanbright | kpfleming: can you guys release the source code to asterisk? |
| 23:14.03 | mvanbaak | (OpenBSD that is) |
| 23:14.07 | Qwell | I won't be around this weekend :D |
| 23:14.10 | Qwell | or early next week |
| 23:14.14 | Kobaz | heh |
| 23:14.18 | Kobaz | seanbright: you're killing me :P |
| 23:14.32 | mvanbaak | I'll still have them ready this weekend ;) |
| 23:14.41 | seanbright | Kobaz: you have a very specific question |
| 23:14.50 | Qwell | mvanbaak: I promise I'll try to care when I'm sitting in Vegas. :D |
| 23:14.52 | seanbright | with a few greps you should be able to find the relevant sections of code |
| 23:15.16 | mvanbaak | Qwell: ;) |
| 23:15.17 | Qwell | mvanbaak: we can go over stuff wednesday though, if they are ready |
| 23:15.24 | Kobaz | yeah, perhaps... but i thought a quick specific question might get a quick answer |
| 23:15.34 | Qwell | well, maybe. depends on how much I have to catch up on O.o |
| 23:15.47 | seanbright | Kobaz: it's been 14 minutes |
| 23:15.50 | seanbright | and no answer |
| 23:15.52 | mvanbaak | Qwell: no rush. it's just that I have some time this weekend. So I'll setup two virtual machines with everything |
| 23:16.05 | Kobaz | seanbright: yeap |
| 23:16.38 | mvanbaak | testcompile asterisk with all the modules that can be build on OpenBSD (which is everything cept dahdi related stuff) |
| 23:16.41 | seanbright | i have this guy that comes into my office every now and again, and says something like "hey... when i click on the 'CALL EXTENSION X' button, what is supposed to happen?" |
| 23:17.00 | Kobaz | heh |
| 23:17.01 | Qwell | seanbright: butterfly effect |
| 23:17.22 | seanbright | when he really just means to say "when i click the 'CALL EXTENSION X' button, it doesn't do anything" |
| 23:17.46 | seanbright | or "it murders my puppy" |
| 23:17.55 | mvanbaak | just add "alert('all your base are belong to us');" |
| 23:18.19 | seanbright | i'm sure i had a point going into that mini-tirade |
| 23:18.23 | seanbright | but i've lost it |
| 23:18.31 | mvanbaak | or "alert('mess with the best, die like the rest');" |
| 23:19.54 | seanbright | Kobaz: based on the circumstances you describe, i would say it was a bug. |
| 23:20.05 | seanbright | Kobaz: unless a local channel is involved - then you can just go straight to hell. |
| 23:20.10 | Kobaz | haha |
| 23:21.02 | Kobaz | it's not my fault that local channels are buggy :P |
| 23:21.13 | mvanbaak | jpeeler: thanks for the new cert |
| 23:21.36 | jpeeler | mvanbaak: no problem! |
| 23:21.40 | seanbright | Kobaz: jpeeler commited a fix 7 days ago, 6 hours ago having to do with local channels and channel state |
| 23:21.49 | seanbright | Kobaz: do you have a version newer than 7 days |
| 23:21.50 | seanbright | ? |
| 23:21.52 | Kobaz | nope |
| 23:22.00 | seanbright | k |
| 23:22.08 | jpeeler | yes and apparently it has caused at least one problem |
| 23:22.31 | seanbright | jpeeler: wonderful |
| 23:22.32 | seanbright | you're fired. |
| 23:22.40 | mvanbaak | lol |
| 23:23.07 | mvanbaak | good thing he got fired _after_ getting me a new cert \o/ |
| 23:23.08 | seanbright | jpeeler: what are you basing that on? is there an issue in mantis? |
| 23:23.10 | jpeeler | packs up his stuff |
| 23:23.16 | Kobaz | <PROTECTED> |
| 23:23.21 | jpeeler | seanbright: there is |
| 23:23.24 | Kobaz | <PROTECTED> |
| 23:23.38 | Kobaz | It seems that anything to do with dialplan, doesn't update device state |
| 23:23.47 | Kobaz | i'm still grepping around trying to find some stuff |
| 23:23.52 | seanbright | Kobaz: do you have a version newer than 7 days? |
| 23:24.07 | seanbright | from svn? |
| 23:24.09 | Kobaz | 1.6.0.22 |
| 23:24.15 | seanbright | when was that rolled? |
| 23:24.18 | Kobaz | lemme see |
| 23:24.24 | mvanbaak | that's not a yes/no answer |
| 23:24.45 | Kobaz | BLUE |
| 23:24.46 | jpeeler | the local channel fix i made shouldn't have been put into any release yet |
| 23:24.58 | seanbright | jpeeler: i'm teaching him to fish (i think) |
| 23:25.03 | seanbright | or just annoying him |
| 23:25.10 | mvanbaak | Kobaz: there is no spoon |
| 23:25.10 | Kobaz | 02/02 |
| 23:25.12 | seanbright | either way someone is having fish for dinner |
| 23:25.14 | jpeeler | heh |
| 23:25.21 | Kobaz | it's older than 7 days |
| 23:25.22 | seanbright | Kobaz: test jpeeler's patch |
| 23:25.27 | tzafrir_laptop | jpeeler, it's in latest RCs, though, isn't it? |
| 23:25.35 | Kobaz | but it thought you said it caused problems? |
| 23:25.46 | seanbright | i didn't say that |
| 23:25.47 | seanbright | he did |
| 23:25.51 | jpeeler | i think it was actually intentionally avoided |
| 23:25.56 | Kobaz | mm |
| 23:26.01 | seanbright | doesn't mean it doesn't fix the specific issue you are having |
| 23:26.24 | seanbright | http://svnview.digium.com/svn/asterisk/branches/1.6.0/channels/chan_local.c?r1=244072&r2=246071&view=patch |
| 23:26.25 | Kobaz | yeah |
| 23:26.27 | seanbright | go with god |
| 23:26.45 | mvanbaak | and get screwed |
| 23:26.53 | seanbright | possibly |
| 23:26.55 | tzafrir_laptop | to see the dates: http://svnview.digium.com/svn/asterisk/tags/ |
| 23:26.56 | mvanbaak | god is a moron |
| 23:27.02 | Kobaz | does dialplan use local channels internally? |
| 23:27.17 | Kobaz | god doesn't make me coffee |
| 23:27.19 | mvanbaak | Kobaz: only if you instruct it to |
| 23:27.29 | seanbright | ah, you never denied using local channels |
| 23:27.32 | seanbright | so i assumed you were |
| 23:27.37 | Kobaz | nope. no local channels |
| 23:27.40 | seanbright | so the last 14 minutes were a waste of time |
| 23:27.42 | Kobaz | i don't think this would fix it |
| 23:27.44 | Kobaz | sorry :( |
| 23:27.45 | seanbright | thanks for that |
| 23:27.48 | Kobaz | i never said anything about local channels |
| 23:27.52 | mvanbaak | no you go to hell |
| 23:27.55 | Kobaz | aww |
| 23:27.57 | seanbright | 18:20 <@seanbright> Kobaz: unless a local channel is involved - then you can just go straight to hell. |
| 23:27.59 | seanbright | 18:20 < Kobaz> haha |
| 23:28.02 | seanbright | 18:21 < Kobaz> it's not my fault that local channels are buggy :P |
| 23:28.08 | Kobaz | okay well |
| 23:28.12 | Kobaz | i did say something about local channels |
| 23:28.18 | mvanbaak | seanbright: your clock is all wrong |
| 23:28.19 | Kobaz | but io didn't say this issue was related to local channels |
| 23:28.25 | seanbright | mvanbaak: i made a number up |
| 23:28.30 | seanbright | Kobaz: fair enough |
| 23:28.47 | mvanbaak | 00:22 <@ seanbright> Kobaz: unless a local channel is involved - then you can just go straight to hell. |
| 23:29.11 | Kobaz | Wed Feb 17 18:29:09 EST 2010 |
| 23:29.17 | seanbright | mvanbaak: i couldn't care less |
| 23:29.19 | mvanbaak | Thu Feb 18 00:31:21 CET 2010 |
| 23:29.46 | mvanbaak | seanbright: see my face ? does it look like a face that gives a shit ? |
| 23:30.12 | mvanbaak | ;) |
| 23:30.15 | leifmadsen | wow |
| 23:30.21 | mvanbaak | leifmadsen: !!!!! |
| 23:30.24 | Kobaz | okay, well... i'll play with this probably next week |
| 23:30.28 | leifmadsen | mvanbaak: !!!!!!! |
| 23:30.29 | mvanbaak | opens the chardonnay |
| 23:30.31 | Kobaz | now i have more of an idea what to look for |
| 23:30.32 | leifmadsen | mvanbaak: have some wine for me |
| 23:30.34 | leifmadsen | I'm all out |
| 23:30.53 | Kobaz | seanbright: i'll make some cookies, and it'll be all better |
| 23:30.59 | seanbright | eh? |
| 23:31.01 | mvanbaak | leifmadsen: hhmm, only have 4 bottles left. short stack player here |
| 23:31.17 | Kobaz | seanbright: for your comfort... |
| 23:31.28 | seanbright | not sure what you mean |
| 23:31.40 | Kobaz | to comfort your pain, of the 14 minutes |
| 23:31.41 | seanbright | i'm pretty comfortable |
| 23:31.43 | Kobaz | oh |
| 23:31.45 | Kobaz | okay |
| 23:31.46 | Kobaz | more for me then |
| 23:31.52 | mvanbaak | but I do have a couple of bottles of 'Laphroaigg 18yr old' |
| 23:33.01 | seanbright | Kobaz: also, there have been 87 changes since 1.6.0.22 was tagged |
| 23:33.04 | Corydon76-dig | mvanbaak: I'm not wild about that one |
| 23:33.18 | Kobaz | that's a bunch |
| 23:33.23 | seanbright | 1 more than 86 |
| 23:33.26 | Kobaz | yeah i'll try in trunk, and etc |
| 23:33.36 | seanbright | i would test with the latest svn of 1.6.0 before spending a lot of time debugging |
| 23:33.44 | Kobaz | yeap |
| 23:33.44 | Corydon76-dig | Glen Morangie is a bit more to my tastes |
| 23:35.02 | mvanbaak | Corydon76-dig: I use that for cooking :) |
| 23:35.29 | Kobaz | i got some marsala for cooking |
| 23:36.03 | mvanbaak | Corydon76-dig: I'm a big fan of the islay whiskeys |
| 23:36.11 | mvanbaak | the salty ones |
| 23:36.38 | mvanbaak | laphroaig, bowmore |
| 23:36.47 | mvanbaak | I even named my boat Laphroaig |
| 23:38.15 | leifmadsen | I think you should name it Leif |
| 23:38.20 | mvanbaak | lol |
| 23:38.30 | mvanbaak | then it'll sink |
| 23:38.33 | leifmadsen | I've been trying to get people to name their babies Leif for a couple of years now. No biters. |
| 23:38.37 | leifmadsen | OH BURN |
| 23:38.57 | mvanbaak | but at least it will sink documented ;) |
| 23:39.11 | snuff-work | lmao |
| 23:40.22 | mvanbaak | Appendix A: Dont make holes in your boat |
| 23:43.14 | leifmadsen | Chapter 1: Cruising the high seas on your new boat |
| 23:43.23 | leifmadsen | Chapter 2: Read chapter 1 again |
| 23:43.29 | leifmadsen | Chapter 8: Profit! |
| 23:43.46 | kpfleming | that's a lot of missing chapters |
| 23:46.34 | mvanbaak | but it reflects reality when it comes to leveraging synergy and upping business potential using the corporate turd 2.0 |
| 23:48.23 | mvanbaak | http://www.hekjetoktok.nl/enterprise/enterprise.pdf |
| 23:53.43 | mvanbaak | latero all |