| 00:38.54 | *** join/#asterisk-dev droemel (~droemel@p4FCAD198.dip.t-dialin.net) |
| 00:55.32 | *** join/#asterisk-dev zerohalo (~zerohalo@74.60.136.128) |
| 00:55.32 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 00:55.32 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187-28-37-118.poolip.RJO.embratel.net.br) |
| 00:55.32 | *** join/#asterisk-dev sgimeno (~sgimeno@163.117.206.10) |
| 00:55.32 | *** join/#asterisk-dev chazzam (~chazz@173-24-236-90.client.mchsi.com) |
| 00:55.32 | *** join/#asterisk-dev Kobaz (~kobaz@its.kobaz.net) |
| 00:55.32 | *** join/#asterisk-dev wdoekes2 (~walter@wjd.osso.nl) |
| 00:55.32 | *** join/#asterisk-dev jsmith-away (~jsmith@fedora/jsmith) |
| 00:55.32 | *** join/#asterisk-dev Crowb4r (u1012@gateway/web/irccloud.com/x-dmjmcumkujoiypxl) |
| 00:55.33 | *** mode/#asterisk-dev [+oo sruffell jsmith-away] by hubbard.freenode.net |
| 04:52.42 | *** join/#asterisk-dev irroot (~irroot@41.49.212.202) |
| 06:05.32 | *** join/#asterisk-dev Tim_Toady (~fuzzy@77.49.252.192.dsl.dyn.forthnet.gr) |
| 06:08.04 | *** join/#asterisk-dev ChrisInSydney (~Chris@224.30.233.220.static.exetel.com.au) |
| 06:38.48 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 06:38.50 | schmidts | good morning |
| 06:41.43 | irroot | morons stole my dev box last night and tossed the office |
| 06:41.48 | irroot | hi there |
| 07:07.30 | *** join/#asterisk-dev oej (~olle@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 07:07.30 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:19.14 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:d47b:5cd1:d672:4ca6) |
| 07:39.45 | oej | Morning folks |
| 07:41.17 | irroot | morning |
| 08:12.37 | *** join/#asterisk-dev Gugge (~gugge@46.30.120.1) |
| 08:15.35 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 09:19.35 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 09:19.35 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 09:49.57 | schmidts | does anyone know how to handle a connected line reinvite in a SIPP scenario? |
| 10:33.47 | oej | No |
| 10:34.28 | oej | I find it too hard to build advanced SIPP scenarios. I end up with SIPP generating a basic call to Asterisk, then Asterisk does the advanced stuff. |
| 10:48.25 | oej | tzafrir online? |
| 11:26.32 | *** join/#asterisk-dev zerohalo (~zerohalo@74.60.136.128) |
| 11:29.42 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:29.42 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:32.12 | tzafrir_laptop | oej, yes |
| 11:32.25 | tzafrir_laptop | next time ping with my nick |
| 11:32.31 | oej | Have a dahdi issue I don't understand |
| 11:32.40 | oej | Will use nick? |
| 11:32.47 | oej | Do you have time for a question? |
| 11:32.52 | tzafrir_laptop | yes, sure |
| 11:33.19 | oej | We have systems with DAHDI loaded as a kernel module, but no chan_dahdi. Use quite a lot of meetmes with 2-3 participants |
| 11:33.39 | oej | Suddenly we're getting kernel messages about no more dahdi channels and can't start meetme's |
| 11:34.18 | oej | I can not find out why. DAHDI seems to have support for 1024 channels, so it seems like we're not closing something we should in meetme |
| 11:34.45 | oej | Takes a week to get the message, but at that time new meetme's can't be established |
| 11:34.57 | tzafrir_laptop | What version of DAHDI? |
| 11:35.03 | oej | Is there a way to monitor pseudo channels in dahdi? |
| 11:35.06 | oej | I'll check |
| 11:35.23 | tzafrir_laptop | Also: any chance it is out of file descriptors? |
| 11:35.29 | oej | dahdi 2.3.0 |
| 11:35.53 | oej | I would not expect running out of fds, we are using Sip with a very high amount of fds |
| 11:36.07 | oej | From the code, it seems to hit DAHDI_MAX_CHANNELS |
| 11:36.40 | tzafrir_laptop | no, there's no representation of pseudo channels, IIRC |
| 11:36.52 | tzafrir_laptop | what do you get from dahdi_test ? |
| 11:37.22 | tzafrir_laptop | Or from: head -c0 /dev/dahdi/pseudo |
| 11:43.38 | kpfleming | you could also grep the output of 'lsof' to look for open dahdi pseudo channels |
| 11:51.21 | schmidts | could someone help me, i have a strange problem with two apps. one depend on the other but when i try to load this one it works for the first time, but when i unload and load it again it fails cause i got the message that the second app is allready loaded :( |
| 11:51.32 | oej | dahdI_test runs fine. 99.99 |
| 11:51.52 | oej | If there's no representation, why do we hit a max channel limit? |
| 11:52.19 | oej | head -c0 doesn't say anything |
| 11:52.36 | kpfleming | schmidts: your question will need more specifics. what are 'apps'? |
| 11:52.39 | oej | schmidts: that sounds like fun |
| 11:53.13 | schmidts | apps like app_xyz located in the apps folder ;) |
| 11:53.22 | schmidts | i will pastebin the module info and depends i have |
| 11:53.39 | kpfleming | you mean asterisk modules then... it doesn't matter what folder they are located in, the module loader treats them all the same. |
| 11:56.43 | oej | tzafrir_laptop: Where do I see dahdi in lsof? |
| 11:57.04 | tzafrir_laptop | lsof /dev/dahdi/* ? |
| 11:57.18 | oej | Of course... |
| 11:57.24 | schmidts | kpfleming iam sorry for missnaming them ;) yes i mean modules |
| 11:57.31 | schmidts | here is the pastebin of these two modules: http://pastebin.com/Hgfi9Pp4 |
| 11:57.46 | tzafrir_laptop | It seems there's no problem creating a pseudo channel |
| 11:57.55 | tzafrir_laptop | maybe a permissions issue? |
| 11:58.28 | oej | 639 open |
| 11:58.47 | oej | There's a max of 1024 hardcoded in dahdi. Any reason why? |
| 11:59.01 | oej | Seems like I have one timer and one pseudo (mixer) channel per meet me. |
| 11:59.14 | oej | I will probably need more than 1024 then |
| 11:59.31 | schmidts | my problem is when i start asterisk with no special module load order i get the message "Already have an application 'GetContacts'" |
| 12:01.18 | kpfleming | schmidts: what is your 'app' variable set to in the other two modules? |
| 12:01.18 | oej | Only have 108 Meetmes and 639 pseudo/timer. Something is leaking. |
| 12:01.42 | kpfleming | schmidts: also, have you renamed the modules at any point, and possibly have old modules in your modules directory? |
| 12:01.48 | kpfleming | oej: sounds that way, yes |
| 12:02.07 | kpfleming | oej: what version of asterisk? |
| 12:02.12 | oej | Can't find a similar issue in the bug tracker |
| 12:02.17 | oej | Good old 1.4 |
| 12:02.21 | oej | latest |
| 12:02.33 | oej | with my "kill-the-last-man-standing" patch that is in trunk |
| 12:03.36 | schmidts | kpfleming sorry missed the app var to copy its once : static char *app = "Getjabber"; and the other one is also there |
| 12:03.42 | schmidts | in the pastebin i mean |
| 12:04.30 | schmidts | i have deleted all files in my lib/asterisk dir and make install them new but the error stay the same |
| 12:04.49 | kpfleming | oej: nothing apparently obvious... but yeah, something is leaking meetme conference structures, i bet. |
| 12:05.44 | kpfleming | schmidts: don't know what to tell you... those bits of code look OK |
| 12:06.10 | kpfleming | if you load app_getcontacts manually alone and then unload it and do 'core show applications' is GetContacts still listed? |
| 12:07.06 | schmidts | yes its still there |
| 12:09.39 | *** join/#asterisk-dev LeLion (~movezafe@75-144-103-5-Miami.hfc.comcastbusiness.net) |
| 12:09.44 | kpfleming | then it's not getting unregistered properly |
| 12:09.49 | kpfleming | you need to debug why that is happening |
| 12:10.04 | schmidts | kpfleming ok thank you for pointing me in this direction ;) |
| 12:10.26 | LeLion | good morning everyone |
| 12:10.45 | LeLion | schmidts: I was reading the right channel |
| 12:12.24 | LeLion | however, porting my application from 1.4 to 1.8 I had not realized that the way to access the cdr variables has completely changed |
| 12:13.34 | LeLion | was there a function ast_cdr_getvar in 1.4 or is that new to 1.8? |
| 12:13.56 | kpfleming | schmidts: ha! i had note to ask you to check whether we were sending UPDATE out before receiving a Contact in a provisional response (which we shouldn't be doing)... but you've already caught it and fixed it : |
| 12:14.26 | kpfleming | schmidts: you shouldn't re-open the reviewboard request for fixing it though... create a new one. |
| 12:15.38 | oej | I guess we have a leak in the trunk code as well. I'm going leak-hunting. |
| 12:17.35 | kpfleming | it looks like the meetme conf structures were converted to use astobj2 at some point... i suspect someone failed to handle refererences properly. if you enable REF_DEBUG (must be done in the source code), you can get a detailed log of all the astobj2 ref/unref activity in that source file |
| 12:17.58 | oej | But that doesn't apply to 1.4 I think |
| 12:18.02 | kpfleming | there is even a tool in the utils directory to parse that log and show you the activity organized by object |
| 12:18.12 | kpfleming | yes, it does. i saw ao2 stuff in app_meetme there too. |
| 12:18.20 | oej | Ouch |
| 12:18.23 | oej | Thanks for the help then |
| 12:18.26 | oej | :-) |
| 12:20.32 | *** join/#asterisk-dev puzzled (~patrick@puzzled.xs4all.nl) |
| 12:21.50 | puzzled | hi |
| 12:22.27 | oej | Hmm. If we move a user away from the conference using manager, wonder if the refcount still works. |
| 12:23.16 | puzzled | hi oej. how are you these days? |
| 12:23.29 | oej | puzzled: Just fine thank you. And you? |
| 12:24.08 | puzzled | app_osplookup.c compilation fails with osptoolkit 4.0.2 and 1.8.8.0-rc1. wonder if this is a known bug. Could not find it in jira. Error here: http://pastebin.com/VR1nqgWi |
| 12:24.33 | puzzled | oej: doing well. finally upgrading my old trusted 1.4 box to 1.8 to see what the cool kids are playing with :) |
| 12:30.52 | oej | If I transfer a call away from a meet me, what happens from the code's point of view. How does meetme handle the exit? Is it like a hangup in the app itself? |
| 12:31.25 | kpfleming | puzzled: osptoolkit 4.x was released after asterisk 1.8.x was branched. there is no support for osptoolkit 4.x in asterisk 1.8.x. |
| 12:31.48 | kpfleming | oej: yes, the masquerade should cause app_meetme to see the channel it is running on being 'hung up' |
| 12:32.52 | oej | I did not realize that AMI redirect causes a masq, but I realize that's probably the only way. Right. |
| 12:33.22 | puzzled | kpfleming: thanks. I guess the error makes sense then :) Will revert to 3.x. Is there any place where version requirements are documented? |
| 12:34.10 | puzzled | kpfleming: oh wait. what about this commit then? "Updated for OSP Toolkit 4.0.0" http://svnview.digium.com/svn/asterisk?view=revision&revision=338137 |
| 12:34.17 | oej | I don't think it's actually mass, but it does send a hangup |
| 12:35.05 | irroot | puzzled that change for osp toolkit was reverted in 1.8/10 only in trunk |
| 12:35.09 | kpfleming | puzzled: that commit was reverted, because it was a new feature and new features are not allowed in release branches. you can use the patch if you like. |
| 12:35.44 | puzzled | kpfleming, irroot: got it. thanks guys! |
| 12:35.57 | kpfleming | puzzled: we don't maintain the docs for app_osplookup, transnexus does. in any case, though, there's no way the docs could have predicted that osptoolkit 4.x would not be backwards compatible with previous versions. |
| 12:36.24 | kpfleming | i suggest contacting transnexus and asking them to fix their library so that version 4.x is compatible with version 3.x. |
| 12:36.41 | puzzled | kpfleming: ok. thanks for your help |
| 12:36.59 | kpfleming | oej: it does an ast_async_goto(), which creates a new channel at the target context/exten, then masquerades onto it. |
| 12:37.08 | irroot | puzzled you could always apply the patch to your own tree |
| 12:37.23 | puzzled | irroot: at least for a test, that it what I am going to try |
| 12:38.11 | oej | kpfleming: thanks. Now following the hangup :-) |
| 12:44.25 | schmidts | kpfleming ok, i will close the review and open a new one |
| 12:51.15 | oej | the actual conferences doesn't use ao2 - only for users. The conferences has an internal refcount. |
| 12:56.31 | kpfleming | ok |
| 12:56.35 | kpfleming | scary :) |
| 12:59.42 | schmidts | kpfleming i have found the error i had with these modules, but its a very strange error for me :D i have to use static int load_module and unload_module then it works ...? |
| 13:00.33 | kpfleming | yes. those functions must *not* be exported. otherwise every module is using the same load_module() and unload_module() functions |
| 13:00.49 | file | eeeeeeep that would be bad |
| 13:01.08 | schmidts | and that was exactly my problem ;) |
| 13:07.24 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 13:17.54 | tzanger | morning |
| 13:18.07 | tzanger | kpfleming: that sounds like an excellent way to reduce code size at the cost of efficiency |
| 13:18.15 | tzanger | (not working being 0% efficient) |
| 13:20.54 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-ilxtbwrslkrjepre) |
| 13:20.54 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:22.27 | kpfleming | tzanger: eh? what was that in reference to? |
| 13:33.19 | tzanger | 09:00 <@kpfleming> yes. those functions must *not* be exported. otherwise every module is using the same load_module() and unload_module() functions |
| 13:33.44 | kpfleming | ahh |
| 13:34.15 | *** join/#asterisk-dev ChrisInSydney (~Chris@60-242-81-231.tpgi.com.au) |
| 13:47.36 | LeLion | I guess I was happy too quickly. I am trying to get cdr data from a channel but keep getting wrong values. |
| 13:48.50 | LeLion | after calling the Dial application, I call ast_cdr_end(cdr) |
| 13:49.50 | LeLion | then I get the different variables with ast_cdr_getvar for start, answer and end |
| 13:50.59 | LeLion | but for some reason, I cannot get the correct values for cdr->answer.tv_sec or start or end |
| 13:51.26 | LeLion | any help would be appreciated |
| 13:54.05 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:54.05 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:54.23 | LeLion | Would the #asterisk channel be the correct channel to ask this question or would it be here? |
| 13:55.40 | Marquis42 | LeLion: If it's about C code (as it appears it is), this is the right channel. But the right person may not be here at the moment or may not have sufficient time to answer. Be patient. :) |
| 13:57.16 | LeLion | oh, OK. I wasn't sure if this channel was solely limited to the core development of asterisk itself. That's why I asked. Thanks for your reply, Markis |
| 14:13.52 | *** join/#asterisk-dev asadgill (~Infibro@119.152.44.206) |
| 14:15.32 | tzafrir_laptop | LeLion, what do you mean by "cannot get correct values"? What do you actually get? |
| 14:16.24 | LeLion | tzafrir: cdr->answer.tv_sec is always 0 |
| 14:17.26 | LeLion | the values for cdr->start.tv_sec and cdr->end.tv_sec are the same |
| 14:20.18 | LeLion | I start with ast_cdr_reset before trying each route: ast_cdr_reset(chan->cdr, &keepvarsflag) |
| 14:22.53 | LeLion | then I call function I wrote pbx_dial_num(struct ast_channel *chan, void *data) where data is the dialstring |
| 14:24.11 | LeLion | look for the Dial application: app = pbx_findapp("Dial"); |
| 14:25.04 | LeLion | dialres = pbx_exec(chan, app, data); |
| 14:26.08 | LeLion | was I supposed to start a new cdr before dialing? |
| 14:30.25 | LeLion | I then pass the channel cdr information to ast_cdr_end: ast_cdr_end(chan->cdr) |
| 14:31.20 | LeLion | and that's when I try to read the different values for start, answer and end |
| 14:32.06 | LeLion | however, I can't get the correct values and I can't figure out what I am doing wrong. It used to work with asterisk 1.4 |
| 14:33.32 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 14:33.32 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:35.20 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 14:35.20 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:35.42 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 14:35.42 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 14:47.48 | Corydon76-home | LeLion: Given that what you're doing is beyond the scope of what CDR was designed to do, I'd suggest you look into CEL |
| 14:49.19 | LeLion | Corydon, I am not familiar with CEL and will certainly look into it. However, I am not sure why that would be beyond the scope of what cdr was designed to do. |
| 14:50.15 | LeLion | All I am trying to do is get the call disposition, answer and end time to calculate billsec and bill the call correctly |
| 14:50.38 | LeLion | As I said, I had it working before with asterisk 1.4 |
| 14:50.47 | Corydon76-home | The concept of a CDR was designed back when there was only one route possible, and it either worked or it didn't. We've been trying to make CDR work forever for things that just don't work all that well once you get beyond those concepts. |
| 14:51.19 | LeLion | oh, by the way, my app is compiled as module which is loaded with asterisk |
| 14:52.18 | Corydon76-home | We've basically given up work on CDR for everything but what CDR was designed to do. One call, one attempt, one record. For more complicated situations, there's CEL. |
| 14:52.40 | LeLion | Corydon: I understand that. However, the correct values are entered in the Master csv, which means there is a way to get them |
| 14:53.12 | LeLion | does the Master csv work off of CEL? |
| 14:53.26 | Corydon76-home | Not the CDR backend, no |
| 14:53.53 | kpfleming | no part of the CDR system works off or CEL... backend or frontend |
| 14:53.58 | kpfleming | s/or/of/ |
| 14:54.02 | kpfleming | lol |
| 14:54.50 | LeLion | I wish I could figure out where to read the cdr data from |
| 14:55.04 | Corydon76-home | There's a cel_custom module that would give you file-based access to CEL records |
| 14:55.04 | LeLion | thanks, kp...lol |
| 14:56.12 | kpfleming | some of the CDR data you are looking for may not exist until the channel is hung up. that's what Corydon76-home was referring to... it's designed for a single call between two parties, not multiple dial attempts |
| 14:56.24 | LeLion | is there a way to read the data just like CEL or do I need to wait until after the data is written? |
| 14:56.40 | kpfleming | CEL has nothing to do with the data you are trying to read |
| 14:56.50 | kpfleming | it's just an alternative to track every event associated with a call |
| 14:56.56 | LeLion | oic |
| 14:57.01 | kpfleming | sorry, a channel, not a call |
| 14:57.08 | Corydon76-home | CEL will write out to disk on each event, as it occurs, if that's what you mean |
| 14:57.24 | kpfleming | one of the CEL backends will, yes. CEL itself does not write anything. |
| 14:58.06 | LeLion | I thought that ast_cdr_end(cdr) ended the recording of cdr for that particular channel... |
| 14:58.37 | kpfleming | it marks the top entry on the CDR stack as 'ended'. it does not stop CDR entries being created or modified. |
| 14:58.38 | Corydon76-home | No, that just records the end time. |
| 14:58.39 | LeLion | I definitely need to start looking into CEL |
| 14:59.58 | LeLion | so no cdr data is written until the original channel is actually hung up? |
| 15:00.19 | kpfleming | of course not. it can't written until the channel is hung up. |
| 15:02.31 | Corydon76-home | Not quite true. If you ast_cdr_detach() it, it will be posted (or queued, if batch) immediately |
| 15:04.47 | LeLion | call disposition also comes back as NO ANSWER when I do: ast_cdr_disp2str(cdr->disposition). However, I noticed that I was getting different integer values and I wrote a different function which returns the correct disposition strings |
| 15:05.52 | Corydon76-home | LeLion: That's because it's not actually set yet. |
| 15:07.55 | LeLion | Corydon: I understand that. However, there are some values that can be read which give the correct calldisposition strings through a modified version of the ast_cdr_disp2str() |
| 15:08.01 | Corydon76-home | And it won't be set until one of ast_cdr_answer(), ast_cdr_busy(), ast_cdr_failed(), ast_cdr_congestion(), or ast_cdr_end() is called |
| 15:08.44 | LeLion | Corydon: I do call ast_cdr_end before I try to read the values! |
| 15:09.20 | Corydon76-home | _end() only modifies it in certain situations |
| 15:10.09 | Corydon76-home | Like if the start or answer times are zero |
| 15:10.54 | LeLion | Where can I get more info about CEL? |
| 15:12.02 | Corydon76-home | https://wiki.asterisk.org/wiki/display/AST/Channel+Event+Logging+%28CEL%29 |
| 15:13.00 | LeLion | Thanks. I am off to do some reading. Enjoy the rest of your day guys! |
| 16:12.59 | *** part/#asterisk-dev puzzled (~patrick@puzzled.xs4all.nl) |
| 16:24.12 | *** join/#asterisk-dev Tim_Toady (~fuzzy@77.49.252.192) |
| 16:37.27 | *** join/#asterisk-dev irroot (~irroot@41.49.142.108) |
| 17:03.06 | pabelanger | Anybody have an issue commit https://issues.asterisk.org/jira/secure/attachment/41390/chan_gtalk.patch ? |
| 17:03.27 | pabelanger | Fixes google voice by allowing both 'redirect' and 'sta:redirect' |
| 17:07.48 | kpfleming | don't we have a chan_gtalk maintainer now? |
| 17:08.48 | pabelanger | I don't think anybody was selected, but we have 1 person volunteer |
| 17:08.50 | Qwell | was it dcb? I don't know that I've seen any commits from him. |
| 17:09.00 | pabelanger | Dave Bowerman, but I don't know is handle |
| 17:09.19 | pabelanger | s/is/his/ |
| 17:22.12 | kpfleming | yes, it's dcb |
| 17:42.35 | *** join/#asterisk-dev Kobaz (~kobaz@its.kobaz.net) |
| 18:15.47 | *** join/#asterisk-dev snuff-work (~snuffy@210.9.82.197) |
| 18:15.47 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 18:23.52 | *** join/#asterisk-dev JD411 (~JD411@nat/digium/x-fyywanofcrrxihbs) |
| 18:23.59 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 18:23.59 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 18:42.16 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.79) |
| 18:47.45 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 18:47.45 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 19:27.03 | pabelanger | NICE! |
| 19:27.26 | pabelanger | downloading a torrent at 2.34MB/s |
| 19:27.57 | Marquis42 | woot |
| 19:28.52 | file | not bad |
| 19:29.54 | pabelanger | Yar, setting up a new VM for asterisk and needed the latest ubuntu release. |
| 19:30.09 | pabelanger | very happy ever since I replaced DSL with cable |
| 19:55.44 | wedhorn | is there a nightly (or some other) tarball of trunk? |
| 19:56.05 | kpfleming | no |
| 19:56.58 | wedhorn | ok thanks, any ideas for someone to get trunk if they're not allowed to use svn? |
| 19:57.24 | snuff-home | wedhorn: see the lack of ami msg on the -dev list.. maybe something else we could look into :) |
| 19:58.04 | wedhorn | snuff-home: yep, but busy on the conf stuff at the moment |
| 19:58.23 | snuff-home | yer i might try the 'ami' part.. its not too hard to do |
| 19:58.48 | kpfleming | well, he wasn't really asking for ami events, he was asking for actions |
| 19:58.54 | snuff-home | got today off... so might be able to give it a try |
| 19:59.23 | snuff-home | i consider it pretty similar.. but i'm not sure how many 'ami events' skinny has |
| 19:59.32 | wedhorn | kpfleming: yeah, but actions with no events could be difficult |
| 19:59.36 | snuff-home | seems ami cmds are low |
| 19:59.58 | kpfleming | actions like 'hold' and 'unhold' mean changing the state of the channel and also updating the phone to know that the call has been placed on hold |
| 20:00.11 | kpfleming | that is certainly possible with skinny (not so with SIP), but it's not code that already exists |
| 20:00.46 | snuff-home | i noticed that the other channel driver they reference.. chan_sccpb.. is very large |
| 20:01.03 | wedhorn | the hold/unhold is already defined in skinny - setsubstate(sub, SUBSTATE_HOLD) etc, just need the ami to call it |
| 20:01.20 | kpfleming | but then you need to change the phone's display as well |
| 20:01.44 | wedhorn | kpfleming: that's already in the code - skinny display is all pretty controlled from chan_skinny |
| 20:02.20 | kpfleming | ok, cool |
| 20:02.37 | kpfleming | then yeah... it's not so bad |
| 20:03.55 | wedhorn | the setsubstate can handle SUBSTATE_ONHOOK, SUBSTATE_DIAL(ing?), SUBSTATE_HOLD, SUBSTATE_CONNECTED for hangup, call a number, hold and answer/unhold |
| 20:04.07 | wedhorn | code should already do all the handset handling |
| 20:04.24 | snuff-home | wedhorn: we support later fw than sccpb :) |
| 20:04.43 | wedhorn | snuff-home: you sure? |
| 20:05.01 | snuff-home | i remember testing my phone with 8.5.4 and it was hating.. |
| 20:05.13 | snuff-home | though.. they have LOTS n LOTS of config options |
| 20:05.33 | wedhorn | yep, too many things to code, not enough time |
| 20:06.06 | wedhorn | snuff-home: you tried any of the v9 firmware? |
| 20:06.17 | snuff-home | mm.. nope.. i can |
| 20:06.31 | snuff-home | but not today :) |
| 20:06.49 | wedhorn | more out of interest to see how different it is |
| 20:07.24 | snuff-home | well i shall try to satistfy ur curiosity tomorrow :) |
| 20:07.54 | wedhorn | no rush, I won't be trying to add that support for a while |
| 20:08.22 | snuff-home | if i really wanted to hurt myself i could see if IPv6 could work |
| 20:08.51 | snuff-home | with skinny |
| 20:08.58 | wedhorn | snuff-home: I know that won't work, while I updated the address space, the code only looks at the first 4 bytes |
| 20:09.31 | snuff-home | ah |
| 20:11.48 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.79) |
| 20:32.53 | *** join/#asterisk-dev otherwiseguy (~otherwise@cpe-69-76-221-79.kc.res.rr.com) |
| 20:38.30 | LeLion | Thanks guys, I did some reading and now I've got CEL going using a mySQL backend. How do I get the values in <second>.<microseconds>? dateformat is commented out and by default I should get second microseconds values but for some reason that's not happening. |
| 20:45.48 | snuff-home | what's the type of ur mysql datetime field.. maybe its not correct? |
| 20:47.04 | snuff-home | http://stackoverflow.com/questions/2257331/storing-microseconds-in-mysql-which-workaround |
| 20:47.29 | snuff-home | which suggests to me.. that mysql still cannot handle micro seconds.. if ur field is a datetime |
| 20:48.38 | snuff-home | http://dev.mysql.com/doc/refman/5.1/en/datetime.html |
| 20:50.13 | snuff-home | LeLion: makes sense now? |
| 20:50.57 | LeLion | yes snuff! Thanks |
| 20:51.27 | snuff-home | so i guess if u wanted to do some work.. u would store the seconds.microseconds in another column.. then call a trigger when it gets added.. to populate ur own 'microsec' column |
| 20:51.57 | snuff-home | and turf the rest into a datetime so normal ppl can read it :) |
| 20:52.37 | snuff-home | postgres supports keeping the 'microseconds' |
| 20:54.18 | snuff-home | i think.. from my vague reading |
| 20:54.23 | LeLion | I actually wrote that app a while back and it was running on 1.4 with everything done with mySQL. Unless I start from scratch, that would be a lot of work |
| 20:54.39 | snuff-home | i'd take my 1st option then... |
| 20:55.03 | LeLion | yeap, it sounds good to me :) |
| 20:55.17 | Corydon76-home | If you do take that lesson, I'd suggest that you use the ODBC API next time, so if you need to switch databases, it will be a lot less work |
| 20:55.41 | snuff-home | Corydon76-home: there is only odbc for cel.. |
| 20:56.03 | Corydon76-home | That's not true; there's cel_pgsql, too |
| 20:56.13 | snuff-home | i mean for 'mysql' |
| 20:56.23 | snuff-home | only option is to use the cel_odbc |
| 20:57.02 | LeLion | Corydon: performance wise, isn't there any penalty to using odbc as opposed to a native mysql module? |
| 20:57.24 | Corydon76-home | Performance-wise, no |
| 20:58.24 | LeLion | I have to start looking at using odbc more often for my apps then |
| 20:59.28 | Corydon76-home | I mean, sure, there's a negligible amount of extra CPU because you allocate an extra stack frame, but you can't tell the difference between that and an abandoned branch prediction in the CPU core |
| 21:00.11 | LeLion | even with thousands of transactions? |
| 21:00.28 | LeLion | cel is pretty verbose |
| 21:00.45 | Corydon76-home | It's negligible |
| 21:02.00 | snuff-home | the thing with unixODBC is u may need to enable threadedness.. otherwise it trys to channel all data serially to db.. |
| 21:02.02 | LeLion | Yes, you are right, it should not affect system performance much, especially since I have my database running on its own dedicated server |
| 21:02.25 | Corydon76-home | snuff-home: that's a configuration option, sure |
| 21:02.31 | snuff-home | i recall our friend mr falves having issues with perf vs the pgsl module until he fixed it |
| 21:28.40 | *** join/#asterisk-dev festr2 (~festr@nostromo.flh.cz) |
| 22:03.42 | *** join/#asterisk-dev citywok (~citywok@67-134-194-33.dia.static.qwest.net) |
| 22:13.53 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-ilxtbwrslkrjepre) |
| 22:14.25 | *** join/#asterisk-dev citywok (~citywok@67-134-194-33.dia.static.qwest.net) |
| 23:44.06 | *** part/#asterisk-dev LeLion (~movezafe@75-144-103-5-Miami.hfc.comcastbusiness.net) |