| 01:02.53 | Kobaz | JunK-Y: heh yeah the tatoo girl |
| 01:21.31 | *** join/#asterisk-dev Gugge (~gugge@46.30.120.1) |
| 05:19.07 | JunK-Y | :) |
| 06:43.50 | *** part/#asterisk-dev jmls (~Julian@host217-36-208-155.in-addr.btopenworld.com) |
| 07:18.45 | *** join/#asterisk-dev irroot (~irroot@pbx.distrotech.co.za) |
| 08:06.51 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 08:06.51 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:25.03 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 08:25.04 | schmidts | good morning |
| 08:25.40 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:bd2d:c3c:81d:b47e) |
| 08:27.13 | irroot | hi there |
| 08:27.54 | *** join/#asterisk-dev sgimeno (~sgimeno@163.117.206.10) |
| 08:28.27 | *** join/#asterisk-dev SparFux (~raoul@rl2-1-pt.tunnel.tserv5.lon1.ipv6.he.net) |
| 08:28.52 | SparFux | Hi all. In https://sourceforge.net/projects/dahdi-hfcs/ can anybody tell me about the proc handling? |
| 08:33.44 | schmidts | irroot my kernel panic from friday wasnt a network problem so maybe asterisk could be the source of this panic :( |
| 08:33.56 | irroot | buggee |
| 08:34.00 | irroot | bugger |
| 08:34.09 | irroot | asterisk should not be able to break the kernel |
| 08:38.53 | schmidts | atleast not when its running in its own virtual openvz machine |
| 08:40.31 | irroot | indeed |
| 08:42.51 | schmidts | the problem i have is that asterisk also sometimes generate a high load, normally with around 30 to 50 concurrent calls i dont have more than a load of 1 but sometimes i explodes to 5 or last friday to even 17 for a short period |
| 08:43.15 | schmidts | not that there are so many calls or atleast not more than i suspect but something goes crazy and eat cpu power |
| 08:44.04 | irroot | you have a watchdog running checking load ? |
| 08:45.50 | schmidts | nagios with check_mk client |
| 08:46.48 | tzafrir_laptop | SparFux, what about it? |
| 08:47.59 | tzafrir_laptop | Also: SysFS is often nicer and (more importantly) safer |
| 08:49.14 | schmidts | irroot for example right now i have a load of 1.17 and 42 concurrent calls but 10 minutes ago i had a load of 4 with around 45 concurrent calls |
| 08:49.41 | *** join/#asterisk-dev irroot (~irroot@pbx.distrotech.co.za) |
| 08:49.56 | tzafrir_laptop | schmidts, openvz is a separate userspace, but shares the same kernel |
| 08:50.06 | schmidts | the problem is, the load is a 1 minute average and the calls if i am not in the cli is only a 5 minute average |
| 08:50.32 | schmidts | tzafrir yes i know but normally it still shouldnt be able to generate a kernel panic |
| 08:51.36 | SparFux | tzafrir_laptop: Indeed sysfs seems to be the right thing for dahdi, but it uses proc, too, at least if it enabled in the kernel. I added COFNIG_PROC_FS to the dahdi_hfcs fka zaphfc and in former days I removed several lines in order to make the dahdi not crash with zaphfc enabled: |
| 08:51.48 | irroot | schmidts if a kernel panics there is almost always a driver / hardware issue asterisk could come into the mix with TDM cards DHADI/Wanpipe/mISDN[v1/2]/CAPI/.... |
| 08:52.07 | schmidts | there is no hardware which asterisk uses, only the network interface |
| 08:52.08 | SparFux | struct proc_dir_entry *proc_info; struct proc_dir_entry *proc_fifos; struct proc_dir_entry *proc_bufs; I wonder wether these are needed in older kernels. |
| 08:53.15 | tzafrir_laptop | SparFux, xpp has mor eextensive use of procfs, including subdirectories |
| 08:53.28 | tzafrir_laptop | dahdi has merely a single directory |
| 08:53.55 | tzafrir_laptop | But the code there is slightly simpler |
| 08:54.01 | SparFux | tzafrir_laptop: But shouldn't only process info go to procfs? And dahdi is a driver after all which should use sysfs? |
| 08:54.47 | tzafrir_laptop | We already have unstructured information in a single procfs file. Moving it to sysfs will break an established userspace interface |
| 08:55.15 | tzafrir_laptop | We moved lots of stuff in xpp from procfs to sysfs, |
| 08:55.36 | tzafrir_laptop | but this is because we actually used them at startup, and this is inherently racy |
| 08:55.39 | SparFux | Ah, ok. Then it's for the userspace programs. |
| 08:56.17 | tzafrir_laptop | (yeah, those nasty userspace programs. Who needs them?) |
| 08:57.16 | tzafrir_laptop | One other thing for you all: any idea what the recent Asterisk security fix actually fixes? |
| 08:57.27 | SparFux | I guess the proc info, fifos and bufs stuff is from older zaphfc versions? |
| 08:57.37 | tzafrir_laptop | http://downloads.asterisk.org/pub/security/AST-2011-012.html |
| 08:58.46 | SparFux | Won't dahdi core remove the proc stuff on dahdi_device_unregister anyways? |
| 08:58.47 | tzafrir_laptop | SparFux, you want just a read-only procfs file? |
| 08:59.20 | tzafrir_laptop | Is it your own private file (under /proc/dahdi ? elsewhere?) |
| 08:59.21 | SparFux | tzafrir_laptop: why? no. |
| 08:59.39 | tzafrir_laptop | So you want a read-write file? |
| 09:00.15 | SparFux | No. The bufs, fifos, info was in there. It's not used any place. So I am asking myself wether I can savely remove it. :-) |
| 09:00.32 | tzafrir_laptop | a fifo? |
| 09:00.53 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 09:00.53 | SparFux | no, the proc entry only. |
| 09:01.35 | SparFux | I guess it would be better if the fka zaphfc wouldn't use any proc stuff, but if needed sysfs instead? |
| 09:02.35 | SparFux | I mean, everything is working, and all I have is /proc/dahdi which is created by dahdi core I think, and /proc/dahdi_hfcs/0 which is an empty dir. |
| 09:03.04 | schmidts | irroot damn something is wrong with 1.8 :( right now i had a load of 14 with only 47 concurrent calls :( |
| 09:03.23 | irroot | locks/threads ?? |
| 09:03.38 | schmidts | 69 threads no locks |
| 09:04.07 | schmidts | sometimes i see some locks but these are just normal ones which goes away after a second |
| 09:05.17 | SparFux | tzafrir_laptop: so only in the hfcs subdir, I would set #undef CONFIG_PROC_FS perhaps. |
| 09:09.22 | tzafrir_laptop | SparFux, what is currently procfs used for? |
| 09:12.45 | tzafrir_laptop | btw: proc_mkdir can fail (normally: -EEXISTS - failed start) |
| 09:15.25 | tzafrir_laptop | Well, id does seem pointless to have this empty stub |
| 09:21.35 | schmidts | irroot ok it could be a locking problem :( |
| 09:21.51 | irroot | any idea where ? |
| 09:22.05 | schmidts | not now but look here |
| 09:22.06 | schmidts | http://pastebin.com/0gxCgZie |
| 09:22.22 | schmidts | load of 18 with areound 54 concurrent calls |
| 09:23.03 | irroot | nope not a lock but a "block" |
| 09:23.11 | irroot | its blocking on __ast_read |
| 09:23.49 | schmidts | hmm and app_queue is also involved, didnt you solved a lot of locking stuff with queues lately? |
| 09:24.08 | irroot | timing issues ? |
| 09:24.44 | schmidts | what kind of do you mean? |
| 09:27.04 | irroot | there was problems with with timing_fg |
| 09:27.07 | irroot | fd |
| 09:27.44 | schmidts | is this allready resolved in 1.8 branch? |
| 09:28.05 | schmidts | btw there is another paste : http://pastebin.com/cHAe1bDZ |
| 09:43.37 | irroot | yes the problem is that it would block on ast_read |
| 09:46.36 | schmidts | you mean a problem with causes also ast_io_wait to be locked |
| 09:47.46 | schmidts | but i am using my dev branch which is started after this timerfd should allready be fixed, so i guess its something else |
| 10:22.38 | tzafrir_laptop | asks again: |
| 10:22.52 | tzafrir_laptop | One other thing for you all: any idea what the recent Asterisk security fix actually fixes? |
| 10:22.58 | tzafrir_laptop | http://downloads.asterisk.org/pub/security/AST-2011-012.html |
| 10:24.25 | tzafrir_laptop | The only thing I see there is that if curi ends up being empty, domain ends up being a pointer to some random junk |
| 10:24.35 | tzafrir_laptop | But this was not fixed directly |
| 10:29.27 | tzafrir_laptop | Sorry: s/domain/transport/ |
| 10:32.58 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 10:32.58 | *** join/#asterisk-dev Gugge (~gugge@46.30.120.1) |
| 10:32.58 | *** join/#asterisk-dev chazzam (~chazz@173-24-236-90.client.mchsi.com) |
| 10:32.58 | *** join/#asterisk-dev mnicholson (~mnicholso@nat/digium/x-dpmldxfufntpzwvv) |
| 10:32.58 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-wriptwiwzxfudjbo) |
| 10:32.58 | *** join/#asterisk-dev hardwire (~spencersr@2610:100:4fff:23::2) |
| 10:32.58 | *** join/#asterisk-dev jrose_atDigium (~jon@nat/digium/x-egrxfdxqkmjejjar) |
| 10:32.58 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 10:32.58 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 10:32.58 | *** join/#asterisk-dev byronc (~byron@byron.theclarkfamily.name) |
| 10:32.58 | *** join/#asterisk-dev wedhorn (~wedhorn@123-243-209-34.static.tpgi.com.au) |
| 10:32.58 | *** join/#asterisk-dev dwayne (~dwayne@c-76-29-230-45.hsd1.al.comcast.net) |
| 10:32.58 | *** join/#asterisk-dev jdoe (jdoe@falseprophet.ca) |
| 10:32.58 | *** mode/#asterisk-dev [+ooo mnicholson file seanbright] by calvino.freenode.net |
| 10:33.12 | *** join/#asterisk-dev Kobaz (~kobaz@its.kobaz.net) |
| 10:33.12 | *** join/#asterisk-dev Micc (~Micc@c-24-17-253-27.hsd1.wa.comcast.net) |
| 10:33.12 | *** join/#asterisk-dev Tim_Toady (~fuzzy@178.128.37.149) |
| 10:35.25 | schmidts | tzafrir_laptop sorry no idea |
| 10:36.00 | schmidts | irroot just had a load of 25 right now with the same locks :( and it also looks like sip is getting a little bit slow by these locks :( |
| 10:36.26 | irroot | yip its not "locked" only blocking |
| 10:37.04 | schmidts | ok, but its still bad |
| 10:38.13 | schmidts | but i dont see why :( |
| 10:38.22 | schmidts | what i see a lot in these locks is this function ast_extension_state_del |
| 10:49.17 | schmidts | ok i think i have sound something :( |
| 10:49.34 | schmidts | i have around 2500 sip dialogs objects but only 200 active sip dialogs (from sip show channels) |
| 10:49.56 | schmidts | maybe someone of them are leaking around |
| 10:51.47 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 10:51.47 | *** mode/#asterisk-dev [+o ChanServ] by calvino.freenode.net |
| 10:58.40 | schmidts | it looks like my dev branch didnt automerge anymore correctly :( |
| 10:59.15 | irroot | schmidts you having a bad day overall |
| 10:59.46 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 10:59.46 | *** join/#asterisk-dev snuff-work (~snuffy@210.9.82.197) |
| 10:59.46 | *** mode/#asterisk-dev [+oo snuff-home snuff-work] by calvino.freenode.net |
| 11:01.31 | schmidts | lets call it a bad year but hey, only 2 months left :D |
| 11:02.15 | schmidts | i dont know how automerge really works but should be changes from the orginal branch also be imported to my dev branch? |
| 11:05.08 | irroot | schmidts run svn up in your checkout |
| 11:05.27 | irroot | then run svnmerge merge |
| 11:05.36 | irroot | fix any conflicts |
| 11:05.45 | irroot | then svn commit |
| 11:06.08 | irroot | in the root folder there will be a commit msg you can use |
| 11:09.33 | schmidts | irroot thx ;) |
| 11:10.19 | irroot | oh "svn ps automerge '*' . " will reenable if done b4 commit |
| 11:10.22 | irroot | pleasure |
| 11:10.55 | schmidts | it should be enabled but i will try to fix all conflicts first ;) |
| 11:12.15 | irroot | schmidts you must re enable it |
| 11:17.17 | *** join/#asterisk-dev SparFux (~raoul@e182022216.adsl.alicedsl.de) |
| 11:17.43 | SparFux | Oh dear! my procfs modification crashed my system when I turned procfs off in fka zaphfc ;-P |
| 11:21.13 | irroot | hehe SparFux thx for the testing :P |
| 11:23.40 | SparFux | :-P |
| 11:23.49 | tzafrir_laptop | SparFux, you really should use a separate build system. That's why we have 'live_dahdi rsync' |
| 11:23.52 | SparFux | better not deactivate the procfs stuff in fka zaphfc ;-P |
| 11:24.09 | SparFux | tzafrir_laptop: oh, aha. Didn't know ;-P |
| 11:24.17 | schmidts | does anyone else have a problem with origsvn.digium.com? i got an Certificate is expired message |
| 11:24.29 | schmidts | is it my cert or the one of digium? |
| 11:24.33 | tzafrir_laptop | schmidts, your certificate expired, maybe? |
| 11:24.45 | SparFux | tzafrir_laptop: a friend has a system, I could use remotely :-) |
| 11:25.17 | SparFux | how do I use live_dahdi rsync? |
| 11:25.46 | tzafrir_laptop | http://docs.tzafrir.org.il/dahdi-linux/#_live_install_remote |
| 11:28.36 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:28.36 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:31.12 | schmidts | how can i check if my cert is expired? |
| 11:31.28 | kpfleming | schmidts: your cert for origsvn? |
| 11:32.30 | schmidts | yes |
| 11:34.11 | SparFux | However, I guess the drivers have to use PROC_FS, if it's built into the kernel. |
| 11:34.11 | irroot | schmidts openssl x509 -text -nout -in ..... |
| 11:35.13 | irroot | kpfleming the quack queue branch is up ... could not come up with name asked the gf to name it |
| 11:35.47 | irroot | for my sins ill add some doxygen frills |
| 11:36.22 | kpfleming | irroot: quack is fine |
| 11:36.44 | kpfleming | schmidts: it's highly unlikely your cert has expired... every cert we've issued in the last year (or longer) has had a 5 year expiration |
| 11:38.09 | irroot | question folks how expensive is a calloc / memcpy ?? |
| 11:38.37 | schmidts | kpfleming ok, thanks for the info. i have allready checked when i get this cert and i was 1 year ago, so it coult be expired if it was only a one year period |
| 11:38.58 | schmidts | the problem is i get an error with openssl for this cert file so i cant see what expire date is in there |
| 11:39.10 | schmidts | routines:PEM_read_bio:no start line:/SourceCache/OpenSSL098/OpenSSL098-27/src/crypto/pem/pem_lib.c:650:Expecting: TRUSTED CERTIFICATE |
| 11:39.40 | kpfleming | what is the name of the cert file you have? |
| 11:39.50 | SparFux | in the googlecode zaphfc they use remove_proc_entry("bufs", card->proc_dir); on hfc_remove. It gave me oops so I removed and things work. But why did they do the remove_proc_entry for bufs, fifos and info? |
| 11:39.51 | schmidts | kpfleming schmidts-cert.p12 |
| 11:40.20 | kpfleming | schmidts: that's not an x.509 cert file, it's a PKCS#12 container with multiple x.509 certs in it |
| 11:40.34 | kpfleming | so you have to use the openssl pkcs12 command first to extract the certs in order to look at them |
| 11:40.51 | schmidts | ok ;) never done anything like this before but i will try it |
| 11:40.51 | irroot | schmidts you need to extract them think of p12 like a secure zip file |
| 11:40.58 | schmidts | ok got it |
| 11:42.56 | wdoekes2 | irroot: in relation to what? memcpy is cheaper than doing the copy byte by byte. as for the calloc: if you can avoid unnecessary heap allocations, it's better, but you don't have to bend over backwards to avoid them |
| 11:44.01 | schmidts | kpleming Not After : Oct 19 19:41:33 2011 GMT i guess its expired ;) |
| 11:44.03 | irroot | passing the pointer between threads wdoekes2 |
| 11:44.38 | irroot | schmidts and setting the clock back wont help :P |
| 11:44.40 | wdoekes2 | if you're passing a pointer, you'll probably have locking to worry about instead |
| 11:44.59 | schmidts | irroot not a good idea i think ;) |
| 11:45.15 | schmidts | i will write a mail to jeff peeler for a new cert |
| 11:45.23 | kpfleming | schmidts: yep... email jason parker, he can renew it for you |
| 11:45.39 | schmidts | ok will do it, thx kpfleming |
| 11:45.59 | irroot | wdoekes2 locking is not the issue either as its a ao2 object the problem is its pased to a task processor to send ami events the data can change in between [devstates] so trying to avoid inconsistancy |
| 11:47.33 | irroot | wdoekes2 there can be duplicates sent i can eliminate this too easily enough but some events could get skiped ie if answer comes before ringing is emited then it will send the answer never the ring |
| 11:48.52 | irroot | Data retrieval API <- seems like some cool magic i need to look into this more |
| 11:53.25 | irroot | catch you all l8r im heading home early today |
| 12:13.19 | *** join/#asterisk-dev BlackBishop (~dexter@ipv6.d3xt3r01.tk) |
| 12:27.24 | *** join/#asterisk-dev irroot (~irroot@197.170.25.120) |
| 12:31.34 | *** part/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 12:34.20 | *** join/#asterisk-dev oej (~olle@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 12:34.20 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:47.30 | snuff-home | mm kpfleming.. u know much bout 'cel' |
| 12:47.45 | kpfleming | snuff-home: nope |
| 12:48.01 | snuff-home | mm.. well ur no good then ;) |
| 12:48.15 | kpfleming | that's right... no use at all ;-) |
| 12:48.58 | snuff-home | basically the 'chan_start' event doesn't contain all useful info.. because it gets created pretty 'blank' at the chan driver |
| 12:49.46 | snuff-home | but i shall play with chan_skinny since its much easier to pick over than big sip :) |
| 12:57.39 | snuff-home | gets some zzz's |
| 13:00.34 | schmidts | i have a question about the latest 1.8 branch, is it really usefull to bring this message: [Nov 2 14:00:06] WARNING[4016]: chan_sip.c:4888 realtime_peer: Cannot Determine peer name ip= several times for a call? |
| 13:01.13 | schmidts | 3 times for a call, when i have a static configured peer with static ip pointing to my proxy ip |
| 13:02.03 | schmidts | btw i dont use realtime peers at all |
| 13:05.56 | irroot | each one set up for a config |
| 13:06.07 | irroot | wrong window sorry |
| 13:06.22 | schmidts | ;) |
| 13:06.25 | kpfleming | schmidts: no... that's probably a change from wdoekes2's recent patch |
| 13:09.51 | schmidts | ok i will take a look |
| 13:16.46 | tzanger | morning |
| 13:17.43 | schmidts | i have just tested it with the normal 1.8 branch just to make sure and the warning exists there too |
| 13:20.37 | schmidts | btw this warning also comes when loading hints into the dialplan |
| 13:22.50 | irroot | is there a handy doxy cheat sheet ? |
| 13:23.02 | *** join/#asterisk-dev asterisk-Tester (~RAMYT@193.227.170.247) |
| 13:23.05 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-bcomktnczqqxuovd) |
| 13:23.05 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:23.14 | mnicholson | irroot: for doxygen? |
| 13:23.29 | irroot | yeah specifically for asterisk |
| 13:23.49 | oej | Afternoon folks |
| 13:23.57 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-bcomktnczqqxuovd) |
| 13:24.08 | irroot | mnicholson ran some load on queues today the change from calloc/memcpy introduced some issues iorned out |
| 13:24.25 | irroot | yo o/ ole |
| 13:24.29 | irroot | yo o/ oej |
| 13:25.29 | mnicholson | irroot: there is a list of doxygen commands here http://www.stack.nl/~dimitri/doxygen/commands.html |
| 13:25.41 | mnicholson | irroot: i don't know if there is any quick reference related to asterisk |
| 13:25.49 | irroot | shot i may use them more now :P |
| 13:26.13 | mnicholson | irroot: I'll run a test with your branch today |
| 13:27.51 | irroot | thx im using you as a yardstick the test you doing is a fire hose test so its valuable |
| 13:28.11 | oej | What's the difference between running meetme with chan_dahdi and without? |
| 13:35.29 | schmidts | hi oej |
| 13:35.42 | oej | Hi |
| 13:35.57 | oej | Seems like no one knows why meetme asks for chan_dahdi |
| 13:36.05 | oej | It's an Asterisk mystery |
| 13:36.18 | kpfleming | i bet there are people that know, or could figure it out... they're just busy :-) |
| 13:36.57 | kpfleming | in fact, i'll go take a few minutes right now and attempt to figure it out, but only if you promise never to send me any pickled fish to eat |
| 13:37.00 | irroot | oej kpfleming they sworn to secrecy |
| 13:38.30 | kpfleming | ok, first clue: the application help for app_meetme says that chan_dahdi is required for the i/I/r options to work |
| 13:38.39 | kpfleming | those are for doing announcements and recording |
| 13:39.14 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-bcomktnczqqxuovd) |
| 13:39.14 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:40.26 | oej | So meetme should not complain over lack of chan_dahdi unless these options are used |
| 13:41.45 | kpfleming | and that does appear to be the only usage of chan_dahdi in app_meetme... in order to be able to play audio into the conference, or record audio from the conference, the asterisk APIs that handle such things require an Asterisk channel, not just a raw fd |
| 13:42.05 | oej | Isn't the AST_2011-012 a bit to unspecified in what was affected. The commit message is more clear. |
| 13:42.18 | kpfleming | oej: do you see a warning from app_meetme if chan_dahdi is not loaded? |
| 13:42.19 | oej | Thanks, kpfleming. |
| 13:42.31 | oej | Yes, every time we start a meetme there's a warning. |
| 13:42.53 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 13:44.51 | schmidts | interesting logical loop with build_peer, realtime_peer and find_peer i have found |
| 13:44.53 | kpfleming | can you post that warning here? |
| 13:52.25 | schmidts | why is find_peer mostly called with the realtime option set to true even if there is not realtime used |
| 13:53.54 | *** join/#asterisk-dev Mackes (~mm@208.69.84.122) |
| 13:59.15 | kpfleming | is it possible for the callers of find_peer to know whether realtime is in use or not? i think that flag is just telling find_peer whether realtime should be consulted for the peer or not |
| 13:59.31 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:59.31 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:00.50 | kpfleming | the warnings in app_meetme about chan_dahdi not being available are only emitted if the intro/recording options are specified on the conference, so any warning that oej is seeing is coming from something at a lower level than app_meetme itself |
| 14:03.15 | schmidts | kpfleming the realtime options is allways set to true only when a call from a cli function or from the sip_devicestate when a peer autoexpire and its state should be set to unavailable |
| 14:03.46 | schmidts | so i guess mostly there is no way to find out for the calling function if realtime is used or not |
| 14:04.09 | kpfleming | that is correct |
| 14:04.58 | schmidts | i guess the note from the function sip_peer says everything important allready: void using this function in new functions if there is a way to avoid it, since it might cause a database lookup |
| 14:05.07 | schmidts | s/void/avoid/ |
| 14:08.01 | oej | I'll try to catch the warning |
| 14:08.44 | oej | I'll remove chan_dahdi tonight, since it has the 1024 limit that hits us. |
| 14:08.52 | oej | And it seems like we don't need it after all. |
| 14:09.12 | kpfleming | oej: i suspect it's a warning from ast_request() about the requested channel type not being available. if that's the case, the only way to fix it would be to add a parameter to ast_request() to tell it that the channel being requested is not mandatory |
| 14:09.12 | Kobaz | oh man, that was a bunch of driving |
| 14:09.29 | oej | ok |
| 14:09.30 | JunK-Y | Kobaz: back to NY ? |
| 14:09.35 | Kobaz | yeah |
| 14:09.40 | JunK-Y | yay |
| 14:09.46 | kpfleming | we might be able to have app_meetme check to see if chan_dahdi is loaded before calling ast_request()... it wouldn't be perfect, but it would help a lot |
| 14:10.02 | Kobaz | module dependencies would be awesome |
| 14:10.04 | JunK-Y | thx digium for this astricon! once again, this is been real fun. |
| 14:10.05 | schmidts | wdoekes2 are you there? |
| 14:10.09 | oej | schmidts: For some time, I tried hard to get people to avoid callind find_peer for everything, since it generated sql queries. |
| 14:10.27 | oej | kpfleming: yes. Warnings make people worried. |
| 14:10.35 | wdoekes2 | schmidts: just logged in |
| 14:10.44 | schmidts | it also likes it can cause a deadlock when using the cli auto expand for sip qualify peer "TAB" |
| 14:10.51 | oej | And the documentation on meetme relationships to dahdi and chan_dahdi is confusing or lacking |
| 14:11.27 | schmidts | tested with normal 1.8 branch deadlock after sip qualify peer "TAB" |
| 14:11.40 | kpfleming | it didn't seem so to me... i just made a small change to remove the reference to dahdi_dummy, but the rest of the app_meetme documentation about dahdi seems fine |
| 14:11.45 | schmidts | or maybe its only a very very long lock ;) |
| 14:12.28 | schmidts | http://pastebin.com/AV4WAba3 < this is the lock |
| 14:13.13 | *** join/#asterisk-dev frawd (~francois@189.Red-81-38-88.dynamicIP.rima-tde.net) |
| 14:13.53 | schmidts | wdoekes2 i get a warning from realtime_peer when using only static peers without any realtime and it looks like this comes from your commit |
| 14:13.58 | Kobaz | schmidts: doesn't lock for me |
| 14:14.07 | Kobaz | but i'm not using realtime |
| 14:14.15 | schmidts | same for me |
| 14:14.27 | schmidts | i only have static configured peers but around 4400 of them |
| 14:14.31 | wdoekes2 | which warning? |
| 14:14.32 | Kobaz | ah |
| 14:14.54 | schmidts | wdoekes2 [Nov 2 15:00:02] WARNING[28828]: chan_sip.c:4888 realtime_peer: Cannot Determine peer name ip= |
| 14:15.29 | schmidts | i get this for outgoing calls and also when loading hints |
| 14:15.38 | wdoekes2 | interesting.. |
| 14:16.50 | wdoekes2 | but that would mean that realtime_peer is called without newpeername and without addr |
| 14:17.23 | wdoekes2 | no wait |
| 14:17.37 | wdoekes2 | I'll go see what I did wrong |
| 14:18.02 | schmidts | what i have seen is for example this: Dial(SIP/1234@213.235.x.x.) and the newpeername is 213.235.x.x and addr is empty |
| 14:19.02 | kpfleming | that's not a static peer... that's no peer at all, a direct dial |
| 14:20.11 | schmidts | it is a peer but i dont use it for dialing |
| 14:20.39 | kpfleming | so in this case the peer defined in sip.conf is totally unrelated |
| 14:20.50 | kpfleming | it wouldn't matter if you hadn't even defined it |
| 14:21.10 | schmidts | yes |
| 14:23.44 | oej | kpfleming: thanks for the long explanation in e-mail :-) |
| 14:23.59 | schmidts | ok if i dial the peer not the ip directly i didnt get this waring |
| 14:24.06 | schmidts | s/waring/warning/ |
| 14:24.18 | kpfleming | oej: just ensure you don't send me any pickled fish and it'll all be good :-) |
| 14:24.44 | oej | cancels the shipment |
| 14:26.57 | wdoekes2 | schmidts: I see, that warning is not supposed to be there |
| 14:27.10 | schmidts | wdoekes2 ok ;) |
| 14:27.35 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 14:27.35 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:28.07 | wdoekes2 | it was meant for when something was found, but then was nameless (no name column was found.. which is probably impossible) |
| 14:30.12 | *** join/#asterisk-dev otherwiseguy (~otherwise@cpe-69-76-221-79.kc.res.rr.com) |
| 14:30.30 | wdoekes2 | otherwiseguy: schmidts has found the first bug ;) |
| 14:31.59 | otherwiseguy | wdoekes2: it was bound to happen. |
| 14:34.53 | otherwiseguy | wdoekes2: is there a jira issue about it? |
| 14:35.00 | kpfleming | this problem didn't cause the call to fail though, right? |
| 14:36.02 | wdoekes2 | it's not severe.. only a warning which you shouldn't get |
| 14:36.25 | wdoekes2 | typing up something now |
| 14:39.10 | wdoekes2 | terry: http://pastebin.com/YcMVp7m4 |
| 14:40.10 | wdoekes2 | an SQL NULL is treated as empty, right? |
| 14:40.45 | schmidts | kpfleming no the call works fine |
| 14:40.52 | kpfleming | ok, was just curious if there had been a test in the testsuite whether it would have caught this... but the answer is no, because right now the test suite doesn't check for unexpected warnings |
| 14:43.28 | schmidts | wdoekes2 its not a bug at all ;) btw welcome to the dev community with commit rights |
| 14:47.36 | wdoekes2 | so, if I can just prove that get_name_from_variable() cannot return NULL then the warning can be removed completely.. |
| 14:47.51 | otherwiseguy | that reminds me, I can commit my realtime SIP tests now that the patch is committed. |
| 14:48.51 | otherwiseguy | wdoekes2: I seem to remember there are two different lookup realtime functions one for returning results with NULL and one that doesn't. |
| 14:48.55 | wdoekes2 | but if it can return NULL, I'm calling ast_load_realtime with a null pointer as lookup value, which could explode.. (haven't checked) |
| 14:53.16 | schmidts | kpfleming any idea why i get the following error with my new svn cert? SSL negotiation failed: SSL error: Key usage violation in certificate has been detected. |
| 15:02.31 | oej | Ahh. Key usage violation. If you do that, you don't deserve a cert. That's evil, Stefan. |
| 15:02.59 | Qwell | schmidts: You need the updated PEM |
| 15:03.19 | Qwell | See 1.1 on https://wiki.asterisk.org/wiki/display/AST/Subversion+Usage |
| 15:06.21 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 15:06.30 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 15:07.02 | Qwell | subversion (newt?) is a bit silly with how it reads the certs. If I'm not mistaken, some versions are unable to read the PEM that we embed into the cert. it's there, and it should work without any config, but...it doesn't. |
| 15:08.09 | oej | "the PEM that we embed into the cert". Isn't it the other way around. The CERT is encoded using PEM encoding? |
| 15:09.03 | Qwell | oej: both. the p12 is a combined cert. It contains the cert, the PEM, and something else, I believe |
| 15:09.21 | Qwell | or something. |
| 15:09.29 | irroot | Qwell the server CA chain should be in the p12 |
| 15:09.37 | oej | pkcs12 includes the private key (PEM-encoded) and the cert (Pem-encoded). |
| 15:09.41 | Qwell | irroot: yeah I think that's the other thing |
| 15:09.42 | oej | "the PEM" doesn't exist :-) |
| 15:10.18 | Qwell | oej: whatever it is. the equiv of a .pem file :p |
| 15:10.31 | schmidts | Qwell i allready use this since one year :( jason parker just sent me a new cert file cause mine expired and now i get the above error |
| 15:10.35 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 15:10.35 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 15:10.39 | irroot | the file can be exported der or pem |
| 15:10.56 | Qwell | schmidts: That Jason guy is a jerk. I bet he messed it up somehow. :) |
| 15:11.14 | irroot | Qwell mmm fire his ass ?? |
| 15:11.25 | Qwell | schmidts: Is your .subversion/servers file pointing to the right .pem file? It's got the "-sha1" in the filename. |
| 15:12.26 | Qwell | also, hopefully you're using a somewhat recent version of svn. I've seen a similar problem (I don't recall if it was the same error or not) on some older version |
| 15:12.41 | schmidts | i just upgrade it before i said something about this error ;) |
| 15:12.55 | schmidts | this is the global part of my subversion config file: [global] |
| 15:12.55 | schmidts | ssl-authority-files = /home/sil-users/ss/.subversion/Digium_SVN-cacert-sha1.pem |
| 15:13.10 | kpfleming | just remove that |
| 15:13.14 | kpfleming | you don't really need it any more |
| 15:13.31 | kpfleming | as long as you are telling svn to use the .p12 file that has your personal cert and the CA cert in it, everything should work |
| 15:13.53 | schmidts | kpfleming doesnt help still the same error |
| 15:14.33 | Qwell | seanbright: Was it you that had this issue recently? |
| 15:14.35 | kpfleming | that's pretty bizarre... we had a problem like that a couple of years ago and resolved it by changing some key usage bits in our certs |
| 15:14.55 | schmidts | :( |
| 15:15.18 | Qwell | kpfleming: In one case (I believe it was seanbright), I recall having to export the cert *without* the CA cert in it. |
| 15:15.22 | kpfleming | svn uses libneon for its TLS/SSL handling... on some distros, libneon is built against GnuTLS instead of OpenSSL, and GnuTLS is very, very strict about cert elements |
| 15:15.54 | schmidts | i use debian lenny on this server |
| 15:17.09 | wdoekes2 | interesting: name=null does work and is different from empty, at least with res_config_sqlite |
| 15:21.25 | schmidts | i am looking at the decrypted content of the pem file and the only difference i can see is the serial number, validity date and of course the sha1 key at the end |
| 15:26.55 | Qwell | schmidts: Give me a bit and I'll re-export your cert without the CA cert in it. See the bottom of http://old.nabble.com/Key-usage-violation-in-certificate-td20256921.html |
| 15:28.05 | irroot | schmidts you got openssl ?? you can mess with it export the key/cert and re add it without the ca ?? |
| 15:28.19 | schmidts | irroot i can try it |
| 15:28.41 | irroot | yeah openssl is your friend but not mon-sun |
| 15:35.11 | schmidts | irroot THANK YOU |
| 15:35.19 | schmidts | Qwell i have fixed it |
| 15:36.10 | schmidts | openssl pkcs12 -in schmidts-cert.p12 -out schmidts-cert.cl.pem -clcerts to get out the client cert, and then openssl pkcs12 -export -out schmidts-cert.test.p12 -in schmidts-cert.cl.pem and with this p12 file it works |
| 15:44.03 | *** join/#asterisk-dev moy_ (~moy@64.231.55.213) |
| 15:50.18 | Qwell | So, I had a random thought the other day. Why don't we automatically set localnet to include RFC1918 addresses? |
| 15:51.24 | otherwiseguy | Qwell: Because. |
| 15:51.32 | Qwell | You've convinced me. |
| 15:51.45 | otherwiseguy | I have a gift. |
| 15:51.51 | Qwell | Is it cookies? |
| 15:51.57 | otherwiseguy | It used to be. |
| 15:52.01 | Qwell | eww |
| 15:52.03 | otherwiseguy | :-) |
| 15:58.45 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:58.45 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:00.54 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 16:00.54 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:12.08 | hardwire | it is quite strange reading peoples email on asterisk-dev list in their voices now. |
| 16:13.00 | kpfleming | indeed |
| 16:13.35 | hardwire | you're the one that made me think that today. |
| 16:13.35 | hardwire | heh |
| 16:13.41 | hardwire | reading up on meetme dahdi interaction |
| 16:16.17 | kpfleming | that was all speculation :-) |
| 16:16.30 | hardwire | crap |
| 16:22.28 | *** part/#asterisk-dev asterisk-Tester (~RAMYT@193.227.170.247) |
| 16:24.16 | tzafrir_laptop | what happens if a meetme conference starts with DAHDI user that later leavs the conference? |
| 16:24.29 | tzafrir_laptop | Its (dahdi-level) channel is still used? |
| 16:24.30 | hardwire | worm/black hole |
| 16:25.46 | tzafrir_laptop | worm holes around the meetme room? The DAHDI user can't leave? |
| 16:25.46 | hardwire | dahdi is just the mixin right? I don't know much about it but it appears to just be a time synced audio channel post-decoding. So I'd guess the dahdi channel is released |
| 16:26.47 | hardwire | heh.. if they leave their audio just goes to another multiverse. |
| 16:38.29 | kpfleming | tzafrir_laptop: no... if a chan_dahdi channel runs app_meetme, when that channel exits app_meetme, it's dahdi channel is no longer part of the conference |
| 16:44.52 | seanbright | Qwell: i believe so, yes. |
| 17:00.00 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 17:01.39 | mnicholson | irroot: still a performance regression with the latest changes in your branch |
| 17:02.01 | irroot | mnicholson any better than yesterday ? |
| 17:02.06 | mnicholson | irroot: nope |
| 17:02.32 | irroot | thx ill bang head a bit more |
| 17:02.48 | mnicholson | irroot: ok |
| 17:03.45 | irroot | you create a queue with 380 members and throw 380 calls at it right ? |
| 17:04.04 | irroot | is the member creation or call handling hang up |
| 17:10.21 | *** join/#asterisk-dev citywok (~citywok@67-134-194-33.dia.static.qwest.net) |
| 17:31.16 | *** join/#asterisk-dev oron_laptop (~oron_lapt@local.xorcom.com) |
| 17:33.18 | tzafrir_laptop | sruffell, We have most of our changes commited. |
| 17:33.37 | tzafrir_laptop | One or two minor things left regarding the firmware downloading. |
| 17:33.50 | sruffell | which direction do you think you're going to go? |
| 17:34.08 | tzafrir_laptop | Anyway, I'm trying to see how to move forward with dahdi_cfg for pinned-spans |
| 17:36.03 | sruffell | for the 2.7 release? |
| 17:37.24 | sruffell | My understanding is just the firmware and possibly the dahdi_cfg flags to handle gaps in span numbers for 2.6….all other changes to config files, etc.. would be off in 2.7. |
| 18:13.56 | leifmadsen | ok so I've removed and re-checked out my 1.8, 10, and trunk directories from origsvn, made sure I updated repotools to the latest, ran 'make' for repotools and reinstalled them, but I still get deleted properties when I merge from 10 to trunk (but not 1.8 to 10). Perhaps I'm doing this wrong... |
| 18:14.00 | leifmadsen | property 'branch-10-merged' deleted from '.'. |
| 18:14.01 | leifmadsen | property 'branch-10-blocked' deleted from '.'. |
| 18:15.08 | leifmadsen | I do: svn commit (on 1.8), then merge810 <rev committed in 1.8> in the 10 branch, then merge10trunk <rev committed in 10> in trunk. |
| 18:18.31 | Qwell | it should be deleting those, but then it will add them back |
| 18:19.00 | Qwell | or maybe not |
| 18:30.27 | irroot | leifmadsen yip it deletes them and puts them back with the new action |
| 18:31.02 | leifmadsen | Qwell: ya I don't think it puts them back because rmudgett continually complains that I keep removing properties |
| 18:32.19 | irroot | leifmadsen a svn diff or svn pl -v . will show you what it will do |
| 19:05.04 | tzafrir_laptop | notes that svn 1.7 can properly display a diff of svn properties |
| 19:10.36 | *** join/#asterisk-dev moy_ (~moy@209.226.201.250) |
| 19:12.51 | *** join/#asterisk-dev ClintGoudie-Nice (~clint@smtp.callware.com) |
| 19:15.20 | tzafrir_laptop | sruffell, regarding the firmware, we'd like to add our octasic firmware to the ones in drivers/dahdi/firmwares |
| 19:15.52 | tzafrir_laptop | We replaced much of the Makefile there with a short table and a script to read it |
| 19:17.01 | ClintGoudie-Nice | Greetings. Back in Feb, I submitted an issue with patch ( https://issues.asterisk.org/jira/browse/ASTERISK-17362 ) to the bug tracker. When I did so, it prompted me to accept a contributor license before submitting the patch, which I did. |
| 19:17.31 | ClintGoudie-Nice | Richard Mudgett is saying: Must have a signed contributor license. |
| 19:18.10 | ClintGoudie-Nice | What next step do I need to take? |
| 19:19.00 | leifmadsen | I just marked it as a Contribution, and it says there is no license on file. |
| 19:19.21 | leifmadsen | Not sure why that is... all I can suggest is re-signing the contribution license and uploading the file after it is accepted. |
| 19:19.46 | leifmadsen | it looks like you may have uploaded it prior to signing the contributor license |
| 19:20.05 | leifmadsen | files uploaded prior to signing are not retroactively accepted |
| 19:20.12 | ClintGoudie-Nice | heh, now I cant download the patch. |
| 19:20.44 | leifmadsen | right |
| 19:20.54 | leifmadsen | because I marked it as a contribution, and there is no license associated with it |
| 19:20.57 | leifmadsen | so it gets locked out |
| 19:21.41 | ClintGoudie-Nice | The link in Richard's post still works, I'll just download and reupload it that way |
| 19:21.56 | leifmadsen | that is a bug... |
| 19:22.04 | leifmadsen | you shouldn't be able ot |
| 19:22.56 | ClintGoudie-Nice | heh, bug leveraged. :) |
| 19:25.56 | ClintGoudie-Nice | Is there anything else I can do to get this submission to move forward? From the comments on the issue, we've had numerous people try it on an assortment of platforms. |
| 19:40.10 | sruffell | tzafrir_laptop: ok….I just got word that I'll need to do the rc1 today…but we can sort that out before the 2.6.0 final. |
| 19:41.38 | tzafrir_laptop | ok. |
| 19:42.00 | tzafrir_laptop | So, commit the dahdi_cfg ? |
| 19:42.20 | sruffell | yes….it's only a change if those new flags are used..right? |
| 19:42.27 | tzafrir_laptop | Yes |
| 19:42.45 | sruffell | yeah…then I think we should do it…I'll smoke it…and then tag. |
| 19:48.49 | tzafrir_laptop | oh, and those annoying gcc-4.6 warnings |
| 19:50.06 | sruffell | :? I thought I got all those... |
| 19:50.09 | sruffell | hmm.... |
| 19:50.13 | sruffell | goes to check |
| 19:52.56 | sruffell | gcc 4.6.1 just built clean for me with the current trunk |
| 19:54.30 | sruffell | ahh..but not tools |
| 19:54.58 | sruffell | tzafrir_laptop: are you going to patch dahdi_cfg or do you want me to? |
| 19:55.15 | tzafrir_laptop | In a minute. Fixing the man page |
| 19:55.21 | sruffell | kk |
| 20:10.27 | tzafrir_laptop | Done |
| 20:10.44 | tzafrir_laptop | I also have in my working copy a fix for those gcc warnings. |
| 20:10.57 | tzafrir_laptop | There was one in dahdi_maint.c - sflag |
| 20:11.15 | tzafrir_laptop | Which made me notice that 'span' there is initialized to 1 |
| 20:11.44 | tzafrir_laptop | Either someone meant to test sflag but didn't do it, |
| 20:11.54 | tzafrir_laptop | Or span should be initialized to an illegal span number |
| 20:12.41 | sruffell | ok |
| 20:18.00 | wdoekes2 | otherwiseguy: ok, that was non-trivial.. again. I have a review up for a fix |
| 20:37.37 | tzafrir_laptop | One last call: Anybody here understands what http://downloads.asterisk.org/pub/security/AST-2011-012.html actually fixed? |
| 20:40.31 | tzafrir_laptop | If the contact header was "empty", 'transport' got to be a pointer to garbage? But what about other calls to parse_uri() |
| 20:40.41 | tzafrir_laptop | ? |
| 20:52.57 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 20:52.58 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:53.54 | wdoekes2 | tzafrir_laptop: haven't had the time to look, sorry. I will when I get some time |
| 20:57.37 | tzafrir_laptop | domain and transport were initialized to NULL, rather than to "", as they were before that fix |
| 21:03.32 | tzafrir_laptop | But this shouldn't matter |
| 21:51.04 | sruffell | tzafrir_laptop: yes…I think sflag can be dropped…otherwise, are you going to commit the changes for gcc-4.6? |
| 21:55.23 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-bcomktnczqqxuovd) |
| 21:56.53 | sruffell | well..that can go in after rc1 too so I'll go ahead and tag now. |
| 21:58.06 | tzafrir_laptop | done |
| 21:58.18 | sruffell | thanks |
| 22:23.15 | *** join/#asterisk-dev schmidts (~sst@86.59.31.4) |
| 22:23.19 | schmidts | good evening folks |
| 22:24.36 | schmidts | is there a know bug with 1.8, confbridge and an asterisk dying with a memory corruption? |
| 22:25.27 | otherwiseguy | review, review, review. lots of reviews today. |
| 22:25.48 | otherwiseguy | schmidts: I don't know of one, but that doesn't mean much. |
| 22:28.10 | otherwiseguy | Also, I am out of coffee. Bad things are about to happen. |
| 22:28.21 | schmidts | hehe lets bring in some new code to have fun with ;) |
| 22:28.33 | schmidts | i can reproduce this easily with sipp |
| 22:28.55 | otherwiseguy | Although, now() > 5pm and beer > coffee. |
| 22:29.29 | schmidts | what should i say, its nearly 11:30 pm here ;) |
| 22:29.29 | otherwiseguy | schmidts: how are we ever going to get caught up if people keep finding bugs? shame on you. |
| 22:30.05 | schmidts | atleast i mostly write my own patches for the bugs i find :P |
| 22:30.52 | otherwiseguy | There is that, I suppose. |
| 22:35.16 | schmidts | looks like something to start with: bridge_softmix.c line 153 (softmix_bridge_leave): Error: attempt to destroy invalid mutex '&sc->lock'. |
| 22:35.16 | schmidts | bridge_softmix.c line 153 (softmix_bridge_leave): Error destroying mutex &sc->lock: Device or resource busy |
| 22:35.16 | schmidts | *** glibc detected *** asterisk: double free or corruption (!prev): 0x0000000002f579f0 *** |
| 22:36.04 | snuff-work | mm.. that has nothing to do with the reviewboard code about making small changes to the ao2 containers? |
| 22:37.02 | schmidts | snuff-work i dont think so, i just tried some load tests with sipp and recognized asterisk dies when i didnt wait for sipp to finish |
| 22:37.39 | snuff-work | only reason is because i was reading the digests and it mentioned about locks :) |
| 22:40.02 | schmidts | ;) |
| 22:46.27 | *** join/#asterisk-dev jmspeex (~jm@mf4-xiph.osuosl.org) |
| 22:47.19 | jmspeex | kpfleming: Hi! What's the status of Opus in asterisk? |
| 22:48.19 | jmspeex | We just went into the second WGLC and it'd be useful if you or some other dev could post to the mailing list about whether you think it's ready to publish and give any feedback you may have. |
| 22:58.23 | kpfleming | jmspeex: not much has changed yet... we have a not-yet-published branch with a translator module that uses the original release of opus. it hasn't been updated in a while because david has been working on another project. |
| 22:58.42 | kpfleming | however, i saw the draft updates the last couple of days and was planning on seeing if we could update our branch and get it out there. |
| 23:01.58 | jmspeex | kpfleming: In any case, would be good if you could comment for the last call |
| 23:02.05 | kpfleming | yes, i plan to do so |
| 23:03.17 | kpfleming | i only have a small amount of time i can devote to ietf mailing lists right now though, and the rtcweb list is consuming all of it :-) |
| 23:04.52 | jmspeex | Yeah, I gave up on following all the stuff on rtcweb |
| 23:07.07 | kpfleming | wdoekes2: ping |
| 23:35.05 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-155-148.cablep.bezeqint.net) |
| 23:35.05 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 23:40.18 | schmidts | it looks like the bug i have found only happens with a confbridge with 3 or more bridged channels when they all hang up at the same time |
| 23:43.18 | *** part/#asterisk-dev ClintGoudie-Nice (~clint@smtp.callware.com) |