| 01:39.39 | *** join/#asterisk-dev bklang (~bklang@2001:470:8:5de:225:ff:fe49:f8cd) |
| 02:37.07 | *** part/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 04:32.20 | *** join/#asterisk-dev irroot (~irroot@197.173.27.193) |
| 05:02.46 | *** join/#asterisk-dev DocAwesome (~DocAwesom@asterisk/documenteur-extraordinaire/blitzrage) |
| 05:02.46 | *** mode/#asterisk-dev [+o DocAwesome] by ChanServ |
| 06:14.57 | irroot | morning folks |
| 06:15.20 | jsmith | Howdy irroot |
| 06:15.29 | jsmith | How are you? |
| 06:15.42 | irroot | jsmith im well despite the monday thing :P |
| 06:15.48 | irroot | how goes with you |
| 06:15.50 | jsmith | I hear you there :-) |
| 06:16.00 | jsmith | Going well -- hanging out in Pune, India today before I fly back home tonight |
| 06:16.04 | jsmith | (and all day tomorrow) |
| 06:17.08 | irroot | direct flight ?? |
| 06:18.34 | jsmith | I wish :-/ |
| 06:19.02 | jsmith | five or six hour cab ride to Mumbai, ten hour flight to Amsterdam, five hour layover, nine hour flight to USA |
| 06:19.07 | irroot | yeah that is the bugger ... dealing with airport stupidity [security] |
| 06:19.51 | irroot | you could have come via johannesburg and grabed a beer and some sun on the way :P |
| 06:20.18 | jsmith | Security doesn't bother me -- if they really want to see what I look like naked, so be it |
| 06:20.56 | jsmith | I think I handle travel better than most -- I can usually sleep on the planes quite well |
| 06:22.56 | irroot | just dont eat too much of the local street cuisine b4 flight |
| 06:47.47 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 06:47.47 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:48.09 | jsmith | Morning oej |
| 06:48.25 | oej | Morning. Which part of the world are you in? |
| 06:56.29 | jsmith | oej: Pune, India for a few more hours |
| 06:58.43 | jsmith | oej: And you? |
| 07:12.54 | oej | I am actually home |
| 07:13.05 | oej | FLying to Buenos Aires in two weeks |
| 07:31.51 | *** join/#asterisk-dev schmidts (~schmidts@2001:858:4:0:66b9:e8ff:fec3:ae88) |
| 07:31.52 | schmidts | good morning |
| 07:46.15 | *** join/#asterisk-dev kaii (~kh@ciphron.de) |
| 07:47.22 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 08:15.45 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 08:15.45 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:33.21 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:1974:b215:3080:d515) |
| 08:36.33 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:36.34 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:45.38 | *** join/#asterisk-dev sgimeno (~sgimeno@163.117.206.10) |
| 08:46.53 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 09:00.54 | irroot | schmidts hi there |
| 09:08.52 | wdoekes2 | tzafrir: about the sparc thing: right, the mcpu shouldn't be *needed*, but it looks like it was put there for extra optimization |
| 09:10.01 | tzafrir | That part should be removed from the Makefile, for starters |
| 09:11.49 | tzafrir | And if it is only for optimization, why not use mtune? |
| 09:12.18 | tzafrir | Isn't it good enough on a recent enough gcc? |
| 09:14.05 | wdoekes2 | I don't know.. don't you get an i386 binary by default on x86 unless you use -mcpu=native? |
| 09:15.44 | wdoekes2 | I'd think that'd be suboptimal, but I wouldn't know how much setting a more advanced cpu would help either |
| 09:24.03 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 09:24.03 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:31.31 | schmidts | hi irroot |
| 09:33.53 | tzafrir | wdoekes2, I don't suppose so. Even Debian build for i486 with an FPU nowadays |
| 09:34.48 | tzafrir | I suppose most others build for i586 or i686 |
| 09:38.00 | schmidts | irroot i guess i know allready why even my branch cant take the load :( i have started to get back to time measurements and sipsock_read for example is 10 times slower than it was in 1.2 (avg 128usec against 1347 usec) :( |
| 09:39.29 | irroot | schmidts that is a big jump |
| 09:40.05 | irroot | the tcp and tls code came in since then perhaps that accounts for some of it |
| 09:40.17 | schmidts | ok there are around 10 years of development in between so i guess its ok :D |
| 09:40.43 | schmidts | i havent tried anything with tcp or tls now, but i guess its not that big impact |
| 09:43.30 | tzafrir | wdoekes2, most of the sparc2 code was added on r3693 . A bit before Asterisk 1.0 |
| 09:44.15 | wdoekes2 | lol |
| 09:45.56 | wdoekes2 | and yes.. debian might build for i486 or higher.. but it doesn't make gcc to default to that, right? making the setting of mcpu/mtune/mwhatever still worthwhile |
| 10:15.54 | schmidts | is there a special reason to use string compares to find the right rtp engine? |
| 10:16.07 | schmidts | and a link list with normally only 2 entries? |
| 10:20.10 | schmidts | as far as i can see here, there are in 1.8 only 4 engines used, rtp, multicast, srtp and the test_engine .... :( |
| 10:27.47 | tzafrir | wdoekes2, Do you actually build it for sparc64? |
| 10:30.39 | wdoekes2 | no, I don't have any sparcs. all non-x86 is exotic to me |
| 10:57.21 | snuff-home | jmls: ping ? |
| 11:16.26 | jmls | snuff-home: pong |
| 11:16.42 | snuff-home | u still need some account code lovin? |
| 11:17.08 | jmls | would make life easier , that's for sure ;) |
| 11:17.20 | snuff-home | i has the solution :) |
| 11:17.25 | jmls | whooop! |
| 11:17.34 | jmls | and that is .... |
| 11:17.55 | snuff-home | it only works for manager initiated ones.. since seems to be the only one that sets it |
| 11:18.04 | snuff-home | i shall send ye a patch |
| 11:18.12 | jmls | that's fine - I don't use call files |
| 11:18.24 | snuff-home | its based on trunk.. but this should work anywhere.. |
| 11:18.43 | snuff-home | its 'intel atom netbook tested' |
| 11:19.08 | jmls | I'll add "virtualbox tested" then ... |
| 11:19.19 | snuff-home | msg me with email addr or somethin and the patch is urs |
| 11:19.58 | jmls | I would consider it a bug though , so could it be patched in 1.8 / 10 / trunk ? |
| 11:20.32 | snuff-home | u could patch it.. to any.. now if ppl consider it bug fix.. that's another story :) |
| 11:20.38 | snuff-home | since it has never worked |
| 11:20.56 | jmls | wonders why it has to be him that finds these things |
| 11:37.56 | *** join/#asterisk-dev wdoekes2 (~walter@wjd.osso.nl) |
| 11:38.33 | *** join/#asterisk-dev micols (~ident@rlogin.dk) |
| 11:53.54 | tzafrir | wdoekes2, v8 allows support for old 32bit sparc systems. |
| 11:54.21 | tzafrir | v9 only allows 64bit ultrasparc. I beleive noawadays everybody only use those. |
| 11:54.49 | tzafrir | Debian dropped support for 32bit kernels in Etch (3.1 . 2 releases ago) |
| 11:55.45 | tzafrir | So I would vote to remove that and see if anybody actually cares |
| 12:00.01 | *** join/#asterisk-dev Marquis42 (~bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 12:10.28 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 12:21.24 | wdoekes2 | tzafrir: you mean s/v8/v9/ or remove the whole mcpu option? |
| 12:21.32 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:21.32 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:27.43 | tzafrir | wdoekes2, remove the whole option |
| 12:28.12 | wdoekes2 | you get my vote |
| 12:33.55 | *** join/#asterisk-dev irroot (~irroot@197.108.152.74) |
| 12:35.33 | schmidts | wdoekes2 you have done a lot about the find_peer function, maybe you can give me a hint. if i have a type=peer client in my sip config, AFAIK this peer is used for incoming calls or am i wrong? |
| 12:36.24 | wdoekes2 | as far as I understand it (but my knowledgde may be outdated because I use mostly 1.4 and 1.6.2), peer matching is done by ip+port only, user matching is done by name |
| 12:36.57 | schmidts | ok and the difference between peer and user? |
| 12:36.58 | wdoekes2 | and.. outgoing calls to users are impossible, because they have no ip+port |
| 12:37.11 | schmidts | ok got it |
| 12:37.24 | schmidts | so incoming are users and outgoing are peers |
| 12:37.28 | wdoekes2 | no |
| 12:37.40 | kpfleming | well... in 1.8 and later peers can be used for everything |
| 12:37.53 | kpfleming | peers can be matched by name in those versions as well |
| 12:37.53 | schmidts | not really thats my problem ;) |
| 12:37.58 | schmidts | nope |
| 12:38.07 | schmidts | <PROTECTED> |
| 12:38.07 | schmidts | <PROTECTED> |
| 12:38.27 | schmidts | thats from the check_peer_ok function |
| 12:39.01 | schmidts | the important part here is the FINDUSERS flag which avoid peers |
| 12:39.06 | kpfleming | 'first'... there is another check done later, unless i'm misremembering |
| 12:39.25 | wdoekes2 | I suppose that would be a check with NULL name and ipaddr |
| 12:39.31 | schmidts | yes |
| 12:40.25 | wdoekes2 | but re: your "incoming are users": incoming is both/either, but matching mode differs, as you can see |
| 12:41.15 | schmidts | the problem is these function (check_peer_ok) needs up to 1100 usecs and i try to find out why its so slow |
| 12:43.08 | wdoekes2 | mm.. device matching is indeed slow (it's especially horrendous for uncached realtime) |
| 12:43.43 | schmidts | i have disabled realtime calls here, i dont use them and i have to find a way how i could tell asterisk not even try to check it ;) |
| 12:43.44 | wdoekes2 | but making it smarter without altering lookup order/behaviour might be difficult |
| 12:43.55 | schmidts | btw this saves around 100 usec ;) |
| 12:44.44 | *** join/#asterisk-dev oej (~olle@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 12:44.44 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:46.20 | wdoekes2 | schmidts: if you add "if (!ast_check_realtime("sippeers")) { return NULL; }" at the top of realtime_peer() |
| 12:46.39 | schmidts | i will try this |
| 12:53.55 | *** join/#asterisk-dev irroot (~irroot@197.174.40.102) |
| 12:55.16 | *** join/#asterisk-dev irroot (~irroot@197.175.12.11) |
| 13:00.40 | *** join/#asterisk-dev cVsup (~cVsup@201.78.47.2) |
| 13:01.02 | schmidts | wdoekes2 thanks thats much better ;) |
| 13:02.45 | wdoekes2 | good :) |
| 13:03.19 | *** join/#asterisk-dev Juggie (~Juggie@2001:470:1d:566:92fb:a6ff:fee3:5d08) |
| 13:03.35 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 13:11.31 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 13:11.55 | schmidts | but it looks like the biggest problem is dialog_initialize_rtp this takes sometimes up to 600 usec :( |
| 13:12.29 | schmidts | normal its around 100 to 200 usec |
| 13:17.01 | cVsup | somebody can say when this bug was fixed? |
| 13:17.03 | cVsup | https://issues.asterisk.org/view.php?id=18676#133835 |
| 13:17.52 | irroot | schmidts is the new profiler :P |
| 13:18.23 | wdoekes2 | schmidts: could be ast_rtp_new for(;;) block that "sometimes" takes longer |
| 13:19.20 | schmidts | no i have allready traced it down a little bit, and it looks like adding the refcounter for res_rtp_asterisk.so needs some time and also setting the qos value |
| 13:19.28 | kpfleming | cVsup: check the new issue in JIRA to see if it has been fixed |
| 13:19.31 | schmidts | but i will take a look at this for loop |
| 13:20.00 | wdoekes2 | (depends on whether the ports are already used) |
| 13:21.38 | irroot | kpfleming cVsup https://issues.asterisk.org/view.php?id=18676#133835 The issue is resolved in asterisk 1.8.3.2 and 1.8.4-rc2 |
| 13:22.03 | irroot | as per the comments on the bug |
| 13:22.12 | schmidts | irroot if you mean this with profiling : http://pastebin.com/WdVnALUH :D |
| 13:23.08 | irroot | better than using printf :P |
| 13:23.21 | schmidts | its just ast_verbose :P |
| 13:27.20 | irroot | kpfleming ive followed up on discussion and split the queue struct into a mutable and non mutable structs the one only contains the call lists and stats the other the settings from the .conf / RT when a caller joins a queue a ref is grabbed to it and if its reconfigured this will be unlinked and new structure spawned so no setting changes will affect the active calls |
| 13:27.21 | cVsup | irroot: not solved |
| 13:27.40 | irroot | cVsup buzz #asterisk-bugs to get it reopened in jira |
| 13:28.38 | kpfleming | irroot: well, that's a good performance imeprovement, but it's also a behavior chang |
| 13:28.42 | kpfleming | s/chang/change/ |
| 13:35.14 | irroot | kpfleming the problem is at the moment the possibility is not taken into account properly there could be a middle ground that the config is checked at the end of each attempt the way new members are checked .... im also putting in a rt_cache_time to only load config on this timeout or via AMI/CLI |
| 13:48.33 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 13:50.20 | *** join/#asterisk-dev leifmadsen (~leifmadse@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:50.20 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 14:01.18 | irroot | leifmadsen o/ |
| 14:05.12 | leifmadsen | irroot: ohai! |
| 16:34.36 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 16:34.36 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk |
| 16:37.03 | Kobaz | heh, what? |
| 16:37.16 | Kobaz | you're not making any sense :P |
| 16:38.25 | Qwell | it really just depends what's stored in it. If you've only got a couple things in the list, then sure, use a linked list. |
| 16:38.38 | Qwell | But, when you've got hundreds of things, it's a lot cheaper to not have to traverse the entire list. |
| 16:38.55 | file | well, and how you access it... |
| 16:38.58 | file | or use it |
| 16:42.10 | Corydon76-home | Kobaz: An ao2 container with a single bucket is the same efficiency (slightly more memory) as a linked list |
| 16:49.17 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:50.37 | *** join/#asterisk-dev jrose_atDigium (~jon@nat/digium/x-czlkptnmsskoxohe) |
| 16:56.16 | Kobaz | ah okay |
| 16:56.39 | Kobaz | the thing is it's going to have public access |
| 16:56.45 | Kobaz | so i'm thinking it should be ao2 to be modern |
| 16:56.54 | Kobaz | i'm rewriting all the GROUP stuff |
| 16:57.28 | Corydon76-home | There's one reason still to use linked list over ao2 containers, and that's if you want to maintain a specifically-ordered list. |
| 16:57.30 | Kobaz | but there's no double linked lists for ao2 yet. or did that get added |
| 16:57.39 | Corydon76-home | ao2 containers have unordered lists |
| 16:57.41 | Kobaz | don't need ordering |
| 16:58.11 | Kobaz | is removal from an ao2 O(1) ? |
| 16:58.29 | Corydon76-home | Only if each bucket has a single item |
| 16:59.06 | Corydon76-home | otherwise the removal is O(log(n)) |
| 16:59.26 | Corydon76-home | Where the log base is the number of buckets |
| 17:00.20 | Kobaz | ah |
| 17:01.08 | Kobaz | what if you have a pointer to the item in question, that you want to remove |
| 17:01.15 | Kobaz | it's already found |
| 17:01.52 | *** join/#asterisk-dev mpe (~mpe@31.25.23.177) |
| 17:02.06 | Corydon76-home | Doesn't matter. It still has to iterate through the LL at the bucket |
| 17:02.24 | mjordan | Corydon-76-home: I think removal is O(n) in the worst case. If all items collide into a single bucket, then removing any item requires traversal of the underlying list |
| 17:02.45 | mjordan | unless we change the underlying data structure in ao2 to use something other than an unsorted linked list |
| 17:03.00 | Kobaz | i'm a fan of double linked lists for that reason |
| 17:03.25 | Corydon76-home | mjordan: worst case, yes. Best case is O(1), and the average case is O(log(n)) |
| 17:04.54 | Kobaz | basically i have a master double linked list of pointers to channel group datastores |
| 17:05.00 | mjordan | I wouldn't guarantee an average case of O(log(n)) without knowing the items you're hashing or the hash function. Nothing says that you'll have an equatable distribution of collisions. |
| 17:05.09 | Kobaz | and in each channel group datastore is the groups that the channel is assigned to |
| 17:05.37 | Kobaz | which makes it much faster than the current implementation of finding group assignments by traversing the entire list of all group assignments for all channels |
| 17:05.39 | Corydon76-home | mjordan: fair enough |
| 17:06.25 | Kobaz | so you can get all the group assignments by traversing the maser list into the channel lists |
| 17:06.40 | Corydon76-home | mjordan: would be interesting to collect statistics, perhaps, on the various ao2 containers in use in various scenarios |
| 17:06.41 | Kobaz | and you can access specific channel assignments by just going to that datastore |
| 17:08.21 | Kobaz | and then, my favorite byproduct of this design, is hooking into fixup to preserve group assignment across transfers |
| 17:08.40 | Kobaz | and removing special case code from channel hangup and etc for group cleanups |
| 17:09.27 | Corydon76-home | My favorite byproduct of any design is not needing to use fixup, but that's just me... :-P |
| 17:09.36 | Kobaz | haha |
| 17:09.43 | Kobaz | well, once masquerades go away... |
| 17:09.50 | Qwell | patches welcome |
| 17:10.01 | Kobaz | i wouldn't even know where to begin |
| 17:10.34 | Corydon76-home | Having to do code in fixup/masq is usually my least favorite part of any design, more accurately. |
| 17:11.36 | Kobaz | yeah |
| 17:11.44 | Kobaz | but it's awesome that the hooks are in there |
| 17:32.04 | *** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 17:32.04 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 17:32.57 | Kobaz | how would masquerades go away anyway |
| 17:33.10 | Kobaz | would you not rename/replace channels |
| 17:33.19 | Kobaz | you would need like a link/unlink type of thing |
| 17:37.24 | *** join/#asterisk-dev citywok (~citywok@67-134-194-33.dia.static.qwest.net) |
| 17:38.36 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 17:38.36 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:47.35 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-ilvcviyruvyxdnek) |
| 17:47.43 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-ilvcviyruvyxdnek) |
| 17:47.43 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 18:14.10 | *** join/#asterisk-dev mnicholson (~mnicholso@nat/digium/x-vzjwolrlszpcycdo) |
| 18:14.10 | *** mode/#asterisk-dev [+o mnicholson] by ChanServ |
| 18:31.52 | *** join/#asterisk-dev bklang (~bklang@2001:470:8:5de:225:ff:fe49:f8cd) |
| 18:47.09 | irroot | <PROTECTED> |
| 18:48.06 | irroot | mnicholson hi there still banging away ... officially dont like queues anymore :P o/ |
| 18:48.16 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 18:48.16 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 18:48.18 | mnicholson | irroot: heh |
| 18:49.05 | irroot | mnicholson its driving me batty but getting there |
| 18:50.01 | mnicholson | irroot: hang in there |
| 18:50.54 | Marquis42 | irroot: Yeah, hang in there. You're doing yeoman's work. Plus I don't want to have to do it. ;) |
| 18:51.35 | irroot | yeah am ps got rid of all but 2 linked lists and moved all to the linkedlists api the dialedinterfaces list is shared with Dial the queue head all thats left internal |
| 18:51.40 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 18:51.41 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 18:52.04 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 18:52.05 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 18:52.07 | irroot | also split the queue struct into mutable/non mutable bits the stats and the config from .conf/rt |
| 18:53.02 | Marquis42 | sheds tear. :) |
| 18:53.20 | jsmith | irroot: Mumbai, getting ready to hop on a flight to Amsterdam |
| 18:53.37 | mvanbaak | Amsterdam \o/ |
| 18:53.46 | irroot | Marquis42 lol indeed always that too ... got rid of penalty rules linked list by novel use of ao2_callback_data as a bubble search so no need to be linear |
| 18:54.35 | irroot | jsmith fly well watch out for the dutch :P mvanbaak \o/ |
| 18:54.47 | Marquis42 | irroot: Excellent. I'm going to have to sit down for a little bit later this week and see where you're at. It certainly sounds like, based on what I've seen so far and what you've talked about, you're making some very nice improvements to app_queue. |
| 18:55.30 | irroot | Marquis42 step 1 get it into shape and updated the way it should be |
| 18:56.45 | Kobaz | hmm |
| 18:57.02 | Marquis42 | And what's step 2-N? You have a particular roadmap/set of features you'd like to add? |
| 18:57.14 | mvanbaak | irroot: we will show jsmith the good parts of Holland ;-) sex drugs and alcohol, and then some more of that ;-) |
| 18:57.23 | Kobaz | it's gonna be hard to add options to GROUP().. you can pass in commas and it'll use commas in a category name |
| 18:57.36 | Marquis42 | irroot: Just cursious, BTW, I'm not intending to pin you down to specific things. :) |
| 18:57.39 | irroot | Marquis42 the one thing that i think is the right way to do it is that the call_queue cannot change while on call it refs the Q and if it reconfigs it unlinks and links new one the old one dies when calls end |
| 18:57.40 | Kobaz | and i don't really want to add a new function... like GROUP_WITH_OPTIONS |
| 18:57.42 | Kobaz | or something |
| 18:58.01 | Marquis42 | irroot: I like that idea for sure. |
| 18:58.34 | Kobaz | what's a good approach? |
| 18:59.07 | irroot | Marquis42 that is done :P when spliting the queue works for realtime now ... mostly skills based routing and the ability to run a macro on timeout in the queue before loosing place |
| 18:59.07 | Kobaz | Set(GROUP(,i)=foo) will set the group to be foo@,i |
| 18:59.32 | irroot | would also like a "originate" capability where the system will call when agent is ready |
| 18:59.58 | irroot | been able to inject calls to make it outbound |
| 19:00.43 | Marquis42 | irroot: Heh, well then good job! :) Some proper skills-based routing and the macro are both good improvements. The originate piece is interesting, although I can't think of a direct use of it for my company. Still cool, though. |
| 19:01.21 | Kobaz | noone cares about groups :( |
| 19:01.30 | irroot | hooking it up the idea will be press 9 for us to call you when your turn .... |
| 19:01.42 | irroot | Kobaz :P we love groups .... |
| 19:02.02 | Kobaz | yay |
| 19:02.36 | Kobaz | i'm trying to add some way to pass an attribute when setting a group |
| 19:02.43 | Kobaz | without breaking existing functionality |
| 19:03.49 | Kobaz | there's the asterisk.cfg method |
| 19:04.00 | Kobaz | add a keep_groups_on_transfer=1 |
| 19:04.26 | Kobaz | but then every group would be affected, maybe there are conditions where you dont want to keep the group assignment |
| 19:07.13 | irroot | Kobaz trying to make sense of your request |
| 19:07.17 | Kobaz | heh |
| 19:07.19 | Kobaz | okay, so |
| 19:07.38 | Kobaz | say SIP/a is running in dialplan and does a GROUP()=foo@bar |
| 19:07.46 | Kobaz | and then Dial(SIP/b) |
| 19:08.09 | Kobaz | SIP/b picks up and then sip refer transfers to SIP/c... SIP/a is now talking to SIP/c |
| 19:08.46 | Kobaz | when SIP/b was in dialplan, it ran GROUP(baz@bar) before Dial()ing SIP/c |
| 19:08.58 | Kobaz | so... before the transfer you have... |
| 19:09.14 | Kobaz | SIP/a is in group foo@bar SIP/b is in group baz@bar |
| 19:09.39 | Kobaz | after the transfer you have SIP/a is in group foo@bar |
| 19:10.01 | Kobaz | i want an option that will make it so after the trasfer... SIP/a is in group baz@bar (the second group) |
| 19:10.19 | Kobaz | i call it "keep group assignment on transfer" |
| 19:10.34 | Kobaz | i already wrote the code... trying to figure a nice way to pass in an option to GROUP() |
| 19:11.13 | irroot | with you now something like what i did for pickup where a macro is run based on a datastore |
| 19:11.26 | Kobaz | for me, can't be done on pickup |
| 19:11.46 | irroot | yeah but the idea would be to do it as a datastore ? |
| 19:12.03 | irroot | transfers can happen all over the place |
| 19:12.23 | irroot | the dialplan will be tricky but possible ? |
| 19:12.50 | Kobaz | yeah |
| 19:12.55 | Kobaz | i rewrote groups to use datastores |
| 19:13.23 | file | datastores, the API that keeps on giving |
| 19:14.26 | irroot | file regular swiss army knife :P |
| 19:16.13 | Kobaz | yeah |
| 19:16.16 | Kobaz | i love datastores |
| 19:16.26 | Kobaz | so that i could hook into fixup |
| 19:27.16 | Kobaz | i guess in UPGRADE i'll add a note saying you shouldn't use commas in group names/categories |
| 19:27.27 | leifmadsen | Kobaz: hmmm, I'm thinking in that case it should be in both foo@bar and baz@bar |
| 19:27.33 | leifmadsen | (SIP/a that is) |
| 19:27.43 | Kobaz | leifmadsen: can't if you want to preserve existing behavior |
| 19:27.50 | Kobaz | which is only one group per category |
| 19:28.02 | Kobaz | if you set foo@bar and then set baz@bar... it will clobber |
| 19:28.05 | leifmadsen | you can only have one group per category per channel? |
| 19:28.09 | leifmadsen | oic |
| 19:28.11 | Kobaz | yeap |
| 19:28.32 | Kobaz | so if you want more groups.. you do 1@cat1 2@cat2 3@cat3 |
| 19:28.44 | leifmadsen | I see |
| 19:29.04 | leifmadsen | Set(GROUP(bar,t)=baz) I guess |
| 19:29.08 | leifmadsen | something like that |
| 19:29.43 | Kobaz | yeah |
| 19:29.47 | Kobaz | but currently |
| 19:29.50 | Kobaz | GROUp(bar,t)=baz |
| 19:29.51 | leifmadsen | I suppose there is no reason it needs to be a single letter either, so s/t/keepgroup/ |
| 19:29.55 | Kobaz | will set the group baz@bar,t |
| 19:30.09 | Kobaz | so adding options will break that |
| 19:30.12 | leifmadsen | gotcha -- I would not have expect that to work in the first place to be honest |
| 19:30.14 | leifmadsen | I consider that a bug :) |
| 19:30.17 | Kobaz | hehe |
| 19:30.36 | leifmadsen | other functions like ARRAY() can accept multiple argument |
| 19:30.37 | Kobaz | well it's more like keepgroupontransfer |
| 19:30.42 | leifmadsen | GROUP() should too |
| 19:30.47 | leifmadsen | Kobaz: +1 |
| 19:30.47 | Kobaz | yeah |
| 19:30.52 | Kobaz | haha |
| 19:30.58 | Kobaz | +1 for reallylongoptionnameshorray |
| 19:31.21 | leifmadsen | I would consider that lack of argument parsing a bug, and that it be fixed separate (and prior to) your feature changes |
| 19:32.45 | Kobaz | k |
| 19:32.48 | Kobaz | ah okay |
| 19:33.49 | Kobaz | so what's your thoughts on single letter options vs multi letter |
| 19:34.11 | Kobaz | if i do a multi letter then that would be the first one, probably need a whole new options api |
| 19:36.38 | irroot | girlfriend not impressed with my "top" app on desktop called hot-babe |
| 19:37.20 | Kobaz | hah |
| 19:37.37 | irroot | its a resource meter .... |
| 19:37.40 | Kobaz | my brother wrote a traffic monitor called natalie port-mon |
| 19:37.58 | irroot | ok im outta here LOL @kobaz |
| 19:38.02 | Kobaz | have fun |
| 19:38.21 | Kobaz | monitors natalie's ports |
| 19:43.07 | Kobaz | the GROUP stuff is actually kinda weird |
| 19:43.11 | Kobaz | you can set the category two ways |
| 19:43.24 | Kobaz | you can do GROUP(cat)=groupname or GROUP()=group@cat |
| 20:19.36 | *** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 20:19.36 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 20:25.09 | jmls | wouldn't a lot of the GROUP problems be solved by allowing a channel to be in more than one group ? |
| 20:26.07 | jmls | and then allow that to be transferred along with the __ variables |
| 20:26.24 | jmls | group()=__foo |
| 20:26.58 | jmls | has had too much beer, so if he doesn't make sense, then forgive him ... ;) |
| 20:27.14 | jmls | I know what I mean, just can't express it too well |
| 20:29.57 | Kobaz | ah |
| 20:29.59 | Kobaz | i like that |
| 20:30.01 | Kobaz | __ perfect |
| 20:30.07 | leifmadsen | ya, but I don't think __ works like that |
| 20:30.12 | Kobaz | it doesn't |
| 20:30.12 | leifmadsen | only channel variables I'm pretty sure... |
| 20:30.17 | Kobaz | but i will make it work like that |
| 20:30.21 | leifmadsen | :) |
| 20:30.40 | jmls | wow. this must be good beer ;) |
| 20:30.41 | Kobaz | jmls: you can put a channel in more than one group |
| 20:30.46 | Kobaz | if it's in a different categoery |
| 20:30.59 | jmls | Kobaz: that's what makes it bloody confusing |
| 20:31.06 | jmls | hates that format |
| 20:31.09 | Kobaz | oh |
| 20:31.15 | Kobaz | well, it serves my purpose well |
| 20:31.24 | Kobaz | because i want the category to be overwritten |
| 20:34.01 | jmls | I just think that it would be simpler to allow |
| 20:34.08 | jmls | GROUP()=inbound |
| 20:34.16 | jmls | GROUP()=queue |
| 20:34.28 | jmls | and have the channel in the inbound and queue groupds |
| 20:34.33 | jmls | (groups) |
| 20:35.05 | jmls | and then have GROUP()=__foo |
| 20:35.35 | jmls | this would mean any other channel would be automatically added to the same group (foo) |
| 20:39.27 | *** join/#asterisk-dev oej (~oej@ns.webway.se) |
| 20:39.28 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:41.46 | Kobaz | well |
| 20:41.50 | Kobaz | yeah it would be simpler |
| 20:42.14 | Kobaz | but you can accomplish the same thing by doing GROUP()=me@inbound GROUP()=me@queue |
| 20:42.19 | Kobaz | and you'll have memberships in both groups |
| 20:43.17 | Kobaz | and the other problem with allowing multiple groups in the same category is it will break anything that depends on assuming that there's only one group per cat |
| 20:43.57 | jmls | yeah, I know why we can't change it now |
| 20:48.35 | mvanbaak | we can |
| 20:48.41 | mvanbaak | but we will upset a lot of users ;-) |
| 20:48.44 | Kobaz | heh |
| 20:49.08 | Kobaz | i can hear the adhearsion group quivering |
| 20:49.16 | mvanbaak | whehehe |
| 21:06.53 | hardwire | mvanbaak: missed you this year at *con (even though I hadn't been since 2008) |
| 21:09.21 | mvanbaak | hardwire: something with money |
| 21:09.53 | mvanbaak | hardwire: I got devorced, have a new girl living in brazil |
| 21:10.07 | mvanbaak | hardwire: expensive year ..... |
| 21:10.19 | hardwire | ouch.. suck.. and yay! |
| 21:10.41 | hardwire | are you gonna move? |
| 21:10.42 | citywok | be happy you weren't there to get body slammed by leifmadsen |
| 21:10.53 | hardwire | who got slammed? |
| 21:10.59 | citywok | me :( |
| 21:11.06 | hardwire | like in an epic rap battle? |
| 21:11.15 | citywok | snowball fight turned in to try and throw each other in to the snow |
| 21:11.19 | citywok | we missed and landed on the sidewalk |
| 21:11.26 | leifmadsen | :) |
| 21:11.28 | hardwire | citywok: did we meet there? I'd talked with you in the past on lots of stuff |
| 21:12.05 | citywok | idk, i met lots of people haha. were you in the hottub? |
| 21:12.13 | citywok | http://www.facebook.com/profile.php?id=10707627 |
| 21:12.15 | hardwire | I wasn't invited to anything digium related |
| 21:12.18 | hardwire | stares @ file |
| 21:12.23 | mvanbaak | hardwire: yes, thinking about moving |
| 21:12.30 | citywok | it wasn't digium related, a couple of us went to the liquor store, bought beer, and went to the tub. |
| 21:12.34 | hardwire | apparently there were lots of private parties and I had to yuk it up with the peons :) |
| 21:12.39 | citywok | i think the only digium person that showed up was mark |
| 21:12.50 | hardwire | haha |
| 21:12.52 | hardwire | k |
| 21:13.00 | hardwire | I felt like I was missing out on a lot while I was there. |
| 21:13.02 | hardwire | kinda irked me |
| 21:13.15 | mvanbaak | somewhere in the start of next year maybe |
| 21:13.16 | citywok | we paved our own path :P |
| 21:13.27 | citywok | straight to the hottub haha |
| 21:13.28 | hardwire | mvanbaak: well good luck.. I hear it's like hot and stuff. |
| 21:13.36 | mvanbaak | uhhuh, it is |
| 21:13.42 | mvanbaak | but I like that |
| 21:13.47 | hardwire | -> alaska because he liked cold |
| 21:13.54 | Kobaz | what about the hottie tub |
| 21:14.13 | hardwire | citywok: I was staying nowhere near the Westin tho |
| 21:14.15 | hardwire | that didn't help |
| 21:14.24 | hardwire | I think if I were at the Westin I would have been around more fun stuff |
| 21:14.25 | citywok | oh, yea, that def wouldn't help much |
| 21:14.33 | citywok | where did you stay? |
| 21:14.48 | hardwire | I had a few hours on most people there since I was from the past (or future.. whatever) |
| 21:14.58 | hardwire | I stayed at Comfort Suites on 120th |
| 21:15.06 | hardwire | Westin was on 104th |
| 21:15.32 | citywok | ah okay. well what'd ya do that for?!!? :P |
| 21:15.42 | hardwire | I didn't have much choice |
| 21:15.52 | hardwire | my boss liked to dangle *con in front of me until the last minute. |
| 21:16.02 | hardwire | and by that time hotel rates were unapproachable. |
| 21:17.11 | citywok | ah, sad panda |
| 21:17.18 | hardwire | heh |
| 21:17.47 | hardwire | my boss was being a dick |
| 21:17.51 | hardwire | oh well |
| 21:18.04 | hardwire | I got a lot out of the conference however |
| 21:18.12 | citywok | yea... the best part of *con is the social stuff too |
| 21:18.17 | hardwire | and I'm going to be implementing some managed network service ideas up here thanks to it |
| 21:19.21 | citywok | facebook just notified me of the astricon event... fail... http://www.facebook.com/event.php?eid=224897747539342 |
| 21:26.57 | mvanbaak | time for some more programming |
| 21:27.01 | mvanbaak | latero all |
| 21:28.00 | leifmadsen | hardwire: yay managed services! :) |
| 21:28.45 | hardwire | leifmadsen: sorta :) |
| 21:28.55 | leifmadsen | :) |
| 21:29.02 | hardwire | more like helping the telephone companies not suck |
| 21:29.09 | hardwire | and increasing reliability.. services |
| 21:29.21 | hardwire | 'managed' works better |
| 21:29.34 | hardwire | and we'll be putting more fiber in the ground as it happens.. so yay. |
| 21:30.44 | file | I likez me some fiber |
| 21:36.57 | leifmadsen | file: cloud fiber! |
| 21:37.03 | file | nooooo |
| 21:48.51 | citywok | think of the cloudlets |
| 21:51.31 | file | la la la I can't hear you la la la |
| 21:52.10 | *** join/#asterisk-dev otherwiseguy (~otherwise@rrcs-74-62-114-22.west.biz.rr.com) |
| 21:53.40 | Kobaz | cloudlets? |
| 21:54.09 | citywok | yea, the baby clouds :P |
| 22:17.08 | Kobaz | hehe |
| 23:00.21 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-ilvcviyruvyxdnek) |
| 23:36.11 | hardwire | file: I'm making cloud fiber |
| 23:38.05 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 23:38.06 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 23:39.29 | hardwire | supruff?! |
| 23:48.23 | sruffell | blinks |
| 23:53.11 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.79) |