| 00:04.08 | wedhorn | snuff-work: you around? |
| 00:13.45 | snuff-work | yes |
| 00:14.20 | wedhorn | do you have an issue on reregistration that the device keeps retrying to connect |
| 00:15.36 | snuff-work | i dont see my devices saying anything on screen |
| 00:15.57 | snuff-work | would i see it on screen or only * side? |
| 00:16.08 | wedhorn | the asterisk cli keeps repeating that a new session is being started |
| 00:16.39 | snuff-work | k will have to check mine.. i dont have it up atm |
| 00:17.19 | snuff-work | waits for msgs |
| 00:18.10 | snuff-work | how often should they be coming up? |
| 00:20.13 | wedhorn | when you restart asterisk, do the devices just reconnect once, or do they keep doing it over and over |
| 00:21.38 | snuff-work | k did a restart gracefully.. 2 phones came back 1 never noticed * disappearing |
| 00:22.56 | wedhorn | try stopping waiting a few minutes and then starting |
| 00:24.28 | snuff-work | k they all sitting on 'registering'.. now restarting * |
| 00:25.45 | snuff-work | they all back.. dont seem to be re-regging over atm |
| 00:27.29 | wedhorn | okay, strange. Mine was sending a 0x30 packet that was about 1900 bytes in length, this would cause the session to reset. Rereg proably occured every 2 minutes |
| 00:33.57 | snuff-work | mm.. i will watch for anythin like that |
| 00:34.40 | wedhorn | should have happened by now. Also, if you try to make a call without a session, it will fail |
| 00:35.23 | wedhorn | and the session is killed as soon as the large packet is received |
| 00:37.44 | snuff-work | k |
| 00:47.20 | wedhorn | snuff-work: have you found any issues with the 79x1.5a patch? Does it work for you? |
| 00:49.14 | snuff-work | nope seems just fine |
| 00:58.08 | wedhorn | snuff-work: okay, committed. |
| 00:59.08 | snuff-work | i haven't tried any of the BLF/shared line or similar with the newer phone |
| 01:01.08 | wedhorn | neither have I, but given it's effectively support for a new device, I assume there will be other issues as well |
| 01:04.22 | snuff-work | i will attempt to setup that stuff later this week as a trial.. |
| 01:04.39 | snuff-work | right now i'm in doco hell.. visio etc :( |
| 01:11.57 | wedhorn | just tested a SLA between the 7960 and 7961. All functionality seemed to work, answer, hold, resume, join, end, but needs a bit of love |
| 01:26.08 | snuff-work | k |
| 01:26.34 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 01:26.34 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 02:44.30 | *** join/#asterisk-dev ChrisInSydney (~Chris@49.179.132.29) |
| 03:16.08 | *** join/#asterisk-dev ChrisInSydney (~Chris@203.160.9.116) |
| 04:19.12 | *** join/#asterisk-dev tzanger (tzanger@174.142.65.89) |
| 04:59.47 | *** join/#asterisk-dev irroot (~irroot@197.107.255.18) |
| 05:49.54 | *** join/#asterisk-dev irroot (~irroot@197.109.96.164) |
| 06:12.16 | *** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 06:12.16 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 06:14.10 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 06:14.13 | schmidts | good morning |
| 06:30.11 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 06:30.11 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:49.43 | *** join/#asterisk-dev sgimeno (~kvirc@163.117.206.10) |
| 07:30.08 | *** join/#asterisk-dev mpe (~mpe@office.ipvision.dk) |
| 07:34.25 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 07:35.40 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 07:35.40 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 07:37.55 | wedhorn | leifmadsen: just noticed that app_meetme is still on the deprecated list. Is it meant to be or is it an oversight? |
| 07:38.25 | wedhorn | I vaguely remember a discussion that meetme wouldn't be deprecated, especially given there is no replacement for the SLA functionality. |
| 08:03.28 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 08:03.28 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:03.36 | oej | MOrning folks |
| 08:14.36 | *** join/#asterisk-dev oej (~olle@2001:470:1f15:d79:789a:8f3:16c8:f700) |
| 08:14.36 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:19.45 | *** join/#asterisk-dev merbzt (~benjamin@193.12.106.2) |
| 08:20.17 | merbzt | oej: g723.1 encoder got committed to FFmpeg |
| 08:20.22 | oej | You |
| 08:20.28 | oej | are moving forward! |
| 10:38.25 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:4c81:be6:d57a:5e73) |
| 11:05.41 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:05.41 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:09.06 | oej | Good morning, kpleming! |
| 11:13.26 | kpfleming | well, morning |
| 11:16.38 | schmidts | morning kpfleming |
| 11:17.22 | schmidts | i was wrong about this connected line stuff, it seams to work like it should, it was only my stupid phones. they do the connected line update after a pickup but not after a transfer, but with another phone it works fine :( |
| 11:18.30 | kpfleming | schmidts: glad to hear it, at least on the asterisk side |
| 11:18.56 | kpfleming | are you using UPDATE or re-INVITE for the connected line updates? |
| 11:19.18 | schmidts | it looks like its using UPDATE not re-invites |
| 11:19.50 | schmidts | maybe its a re-invite after a pickup and normally an update |
| 11:20.39 | kpfleming | no, the code uses UPDATE if the UA indicates that it accepts UPDATE, otherwise it uses re-INVITE. there is a config option to force usage of re-INVITE though. |
| 11:21.24 | schmidts | kpfleming i have tested it and it looks like there is a re-invite sent after the pickup, but after a transfer it sents an update |
| 11:21.36 | kpfleming | interesting |
| 11:21.45 | kpfleming | that sounds like a bug then |
| 11:22.11 | schmidts | i will take a deeper look at it, but i have to go now ;) |
| 11:22.15 | schmidts | more infos will come |
| 11:22.28 | kpfleming | unless the phone is inconsistent in what it includes in its Supported header |
| 11:22.42 | kpfleming | or maybe Allow.. can't remember which one it is |
| 12:37.36 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-mwddxwouprjkqzzv) |
| 12:37.36 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 12:49.33 | *** join/#asterisk-dev Marquis42 (~bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 13:00.54 | *** join/#asterisk-dev russellb (~russellb@asterisk/contributor-and-cool-guy/russellb) |
| 13:00.54 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 14:05.20 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 14:05.20 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:08.08 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:08.08 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:13.42 | *** join/#asterisk-dev schmidts (~schmidts@213.235.212.193) |
| 14:32.06 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:32.06 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:34.08 | schmidts | are there any known bugs with 1.8 and blond transfer? i really mean BLOND not blind ;) |
| 14:34.38 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 14:34.38 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 14:39.24 | kpfleming | schmidts: that's a pretty vague question |
| 14:42.33 | *** join/#asterisk-dev chazzam (~chazz@173-24-236-90.client.mchsi.com) |
| 14:45.28 | schmidts | kpfleming ok ;) i have a problem with blond transfer that asterisk 1.8 svn version hangs up the call after i press the transfer button the second time. if i want to transfer an outgoing call, the call is just hung up, if its an incoming call it retries to dial the original incoming destination..? i will post a pastebin of the log |
| 14:46.28 | kpfleming | that sounds quite broken, yes |
| 14:46.44 | kpfleming | but once again, it could be phone behavior... phones implement that sort of thing differently |
| 14:48.23 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-mwddxwouprjkqzzv) |
| 14:48.54 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-mwddxwouprjkqzzv) |
| 14:48.55 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:51.48 | schmidts | kpfleming sounds legal to say this ;) |
| 14:51.53 | schmidts | here is the sip trace of this: |
| 14:51.54 | schmidts | http://pastebin.com/zYVRY1sF |
| 14:52.20 | *** join/#asterisk-dev irroot (~irroot@197.109.154.120) |
| 15:14.06 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:16.42 | kpfleming | schmidts: umm... that's pretty weird. |
| 15:17.38 | schmidts | same for me ;) i will try it with some local users to make sure its not the proxy setup i have and to make it easier to read |
| 15:19.37 | kpfleming | also, note that your phone did a real blind transfer there (REFER), not a semi-attended transfer |
| 15:20.04 | kpfleming | or, at least it appears that way. we'd have to see the entire set of signaling for the original call to be sure. |
| 15:20.51 | schmidts | i have tested a normal attendant transfer and the refer message looks just like the same if the other side answers the call first so i guess its the way how this phones do the transfer |
| 15:20.59 | kpfleming | ahh. ok |
| 15:27.47 | schmidts | looks like the problem is somewhere with my proxy :( i guess i dont have to say that the exactly same setup works fine with 1.2 ;) |
| 15:48.04 | *** join/#asterisk-dev dobby156 (~joe@79.135.102.10) |
| 15:49.35 | dobby156 | hi folks, I was wondering if anyone has got a fix for asterisk (1.6) leaking on sip notifies |
| 15:49.43 | dobby156 | when they are successful |
| 15:50.13 | kpfleming | dobby156: is there a JIRA issue? if so, what is the status of it? |
| 15:50.25 | kpfleming | it's highly doubtful that anyone is going to just 'remember' fixing a problem like that |
| 15:50.43 | kpfleming | russellb: https://code.asterisk.org/code/browse/asterisk/branches/1.8/main/channel.c?hb=true#to1503 |
| 15:50.54 | kpfleming | can you tell me what's wrong with that line of code? I bet you can. |
| 15:52.31 | russellb | kpfleming: neat, writing arbitrary data from the stack to a pipe! |
| 15:52.42 | kpfleming | yeah |
| 15:52.44 | kpfleming | fun times |
| 15:52.47 | russellb | funny thing is, probably still works just fine |
| 15:53.46 | kpfleming | since the content doesn't matter, yeah |
| 15:53.58 | kpfleming | but i bet it generates some valgrind warnings |
| 15:54.28 | russellb | hm, don't know ... can it detect stack errors like that? |
| 15:54.51 | kpfleming | well, the number of new_frames would have to be large enough to run off the end of the stack... so it'd be pretty rare |
| 15:59.15 | dobby156 | kpfleming: thanks, I will look for the JIRA. |
| 16:00.21 | russellb | kpfleming: from coverity? |
| 16:00.41 | kpfleming | russellb: possible... hadn't checked |
| 16:00.53 | russellb | oh, just wondering how you spotted it |
| 16:01.20 | kpfleming | working on a small patch to enable use of eventfd() on systems that have it |
| 16:01.26 | russellb | ah cool |
| 16:01.27 | kpfleming | more efficient than pipes |
| 16:01.37 | russellb | sounds like something I need to google. |
| 16:01.54 | kpfleming | 'man eventfd' |
| 16:01.57 | kpfleming | also 'man signalfd' |
| 16:02.29 | irroot | "man woman" |
| 16:02.43 | russellb | kpfleming: well lookie there, neat. |
| 16:03.06 | schmidts | irroot No manual entry for woman :D |
| 16:03.23 | irroot | indeed thats part of my problem |
| 16:03.25 | schmidts | nice idea but i guess this man page would be larger than any harddisk capacity ;) |
| 16:10.23 | *** join/#asterisk-dev bklang (~bklang@12.130.119.136) |
| 16:21.24 | schmidts | ok this blond transfer problem only exists in 1.8, with 1.6.2 it works fine, also with 1.2 so i guess something has changed which brokes this function :( |
| 16:22.11 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 16:22.11 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 16:50.12 | dobby156 | what c file is ao2_ref implemented in, thanks |
| 16:51.04 | kpfleming | astobj2.h and astobj2.c. |
| 16:51.10 | dobby156 | thank you |
| 17:00.42 | *** join/#asterisk-dev bklang (~bklang@12.130.119.136) |
| 17:34.04 | kpfleming | russellb: ping |
| 17:38.10 | russellb | kpfleming: pong |
| 17:38.57 | kpfleming | russellb: hey there.. .so the eventfd() conversion was pretty easy, now i'm considering signalfd() to use instead of ast_waitfor() assuming that any signal it receives was actually intended to wake up a blocking thread |
| 17:39.30 | kpfleming | but honestly, i can't think of how often that situation actually would be occurring |
| 17:40.26 | *** join/#asterisk-dev citywok (~citywok@67-134-194-33.dia.static.qwest.net) |
| 17:42.50 | russellb | kpfleming: not often ... there used to be, and probably is in a few places, various uses of SIGURG to try to wake up threads |
| 17:43.04 | russellb | but it was slowly replaced with more predictable and reliable mechanisms I think.. |
| 17:43.25 | kpfleming | ok, cool |
| 17:43.27 | kpfleming | then i won't bother |
| 17:43.30 | kpfleming | thanks |
| 17:43.33 | russellb | sure, np |
| 17:43.47 | kpfleming | signalfd() could have some usage in the consolethread i suppose |
| 17:44.01 | kpfleming | but that's not as interesting to me :-) |
| 17:44.07 | russellb | heh, agreed |
| 17:44.17 | russellb | yeah, what's there now is a bit of a hack |
| 17:44.22 | russellb | poll on nothing, wait to get interrupted |
| 17:44.28 | kpfleming | using eventfd will reduce the number of open file descriptors by one for pretty much every real channel that exists |
| 17:44.33 | kpfleming | that's pretty big |
| 17:44.37 | russellb | yes, very nice improvement |
| 17:44.49 | russellb | same technique would improve res_timing_pthread btw.. |
| 17:44.56 | russellb | it uses pipes |
| 17:44.58 | tzafrir_laptop | kpfleming, is the sha1 thing only for trunk? |
| 17:45.10 | kpfleming | tzafrir_laptop: no, go ahead and do 1.8 and 10 as well |
| 17:45.16 | tzafrir_laptop | ok |
| 17:45.26 | russellb | performwance would still suck most likely, but it would at least help |
| 17:46.08 | kpfleming | i'll give it a whirl, should be pretty easy |
| 17:48.09 | russellb | kpfleming: yeah, code is pretty localized I think. The general idea is create a pipe for every timer, and write to it at the interval that is currently set. |
| 17:48.31 | russellb | s/pipe/eventfd/ = win |
| 17:50.35 | kpfleming | well... actually doing the conversion 'right' wouldn't be trivial. using eventfd() it would actually be possible to leverage the built-in counter rather than using it as a semaphore, so the tick_count stuff could be eliminated as well |
| 17:53.11 | kpfleming | actually, that would be pending_ticks |
| 18:00.11 | russellb | i suppose a good question would be, is there anything with eventfd but not timerfd |
| 18:00.18 | russellb | if not, then it's sort of wasted effort |
| 18:00.24 | kpfleming | no |
| 18:00.31 | kpfleming | eventfd appeared in 2.6.27, IIRC |
| 18:00.52 | kpfleming | well... 2.6.22, but it really didn't start working properly until 2.6.27 |
| 18:01.14 | kpfleming | no, that's not quite true. eventfd >= 2.6.22, timerfd >= 2.6.25 |
| 18:01.18 | kpfleming | so there's a small window there |
| 18:01.36 | kpfleming | and res_timing_pthread on non-linux can't use eventfd anyway |
| 18:01.42 | russellb | nods |
| 18:01.47 | russellb | so, meh |
| 18:02.24 | kpfleming | i can see some ways to decrease CPU consumption in res_timing_pthread though |
| 18:03.32 | kpfleming | but without a decent way to measure it, it'd be hard to tell if it helped |
| 18:05.38 | kpfleming | the built-in timing test would need to be enhanced to be able to test a quantity of timers, and also measure CPU consumption during the test |
| 18:09.28 | *** join/#asterisk-dev droemel (~droemel@p4FCACE3F.dip.t-dialin.net) |
| 18:16.37 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 18:19.02 | *** join/#asterisk-dev otherwiseguy (~otherwise@68-70-72-163.static.kc.surewest.net) |
| 18:29.35 | *** join/#asterisk-dev otherwiseguy (~otherwise@68-70-72-163.static.kc.surewest.net) |
| 18:30.08 | otherwiseguy | russellb: got time for an asterisk packaging question? |
| 18:31.24 | otherwiseguy | (or pabelanger or anyone else who knows about how debs/rpms are generated by distros for Asterisk) |
| 18:32.29 | russellb | otherwiseguy: i can try |
| 18:32.32 | otherwiseguy | Basically I just want to make sure that for Asterisk 10, they wouldn't have build scripts set up that bypass menuselect somehow and might disable the default-enabled astdb2sqlite3 utility which is required to upgrade the old astdb db. |
| 18:33.14 | russellb | Fedora includes a menuselect.makeopts file in its build. |
| 18:33.15 | jsmith | otherwiseguy: At least in Fedora, we bypass menuselect, as our builds need to be automated |
| 18:33.22 | jsmith | russellb: You're too fast :-) |
| 18:33.32 | russellb | bypassing menuselect is not required for an automated build |
| 18:33.38 | russellb | menuselect always runs in the background to sanity check things |
| 18:33.44 | russellb | the trick is, if you provide it configs, it won't apply defaults |
| 18:34.02 | otherwiseguy | So, then I suppose we need to make sure that everybody knows not to exclude astdb2sqlite3. |
| 18:34.02 | russellb | basically, in this case, it's something Asterisk 10 packagers need to be aware of and apply to their configs |
| 18:34.09 | russellb | yes :-) |
| 18:34.25 | Qwell | mmm, why let it be disabled then? |
| 18:34.33 | otherwiseguy | That sounds like more work. :-) Although I'm guessing that fedora/centos is now taken care of there. :-p |
| 18:34.36 | jsmith | otherwiseguy: For Fedora, it would be as simple as emailing the package maintainer (jcollie@fedoraproject.org) |
| 18:34.55 | jsmith | otherwiseguy: I'd be happy to drop him a note, if you'd like |
| 18:34.56 | russellb | co-maintains it now |
| 18:35.02 | jsmith | russellb: Oh? Even better! |
| 18:35.04 | pabelanger | Qwell: good question, can a module be forced always to build? |
| 18:35.14 | Qwell | it's not a module |
| 18:35.20 | russellb | asterisk-owner@fedoraproject.org is best |
| 18:35.25 | russellb | then it'll go to both of us |
| 18:36.29 | otherwiseguy | Qwell: but it is close enough to a module for the menuselect discussion, though. |
| 18:36.31 | russellb | but actually, it's already fixed in the Asterisk 10 setup for fedora |
| 18:36.36 | russellb | http://pkgs.fedoraproject.org/gitweb/?p=asterisk.git;a=blob;f=menuselect.makeopts;h=6fed6edd6737918687550b965fd1d74981dbf4b1;hb=master |
| 18:37.38 | otherwiseguy | So, anyone know what debian/ubuntu does? pabelanger do you have anything to do with those packages? It seems like I remember you talking about them at some point. |
| 18:37.44 | otherwiseguy | russellb: coolness. |
| 18:37.53 | Qwell | otherwiseguy: tzafrir |
| 18:38.06 | russellb | pabelanger maintains the asterisk.org versions, which are based on upstream |
| 18:38.08 | Qwell | (but pabelanger should be able to check them) |
| 18:38.11 | pabelanger | otherwiseguy: Debian will patch the source file directly |
| 18:38.22 | pabelanger | so, we just need to make sure it is built by default |
| 18:38.32 | otherwiseguy | pabelanger: it is. |
| 18:38.45 | russellb | it is, as long as you don't include a menuselect.makeopts |
| 18:38.50 | russellb | and if you do, you must update it to include this |
| 18:38.51 | pabelanger | So, should not be an issue then. Just make sure we have the required dependencies |
| 18:38.55 | russellb | if the package doesn't, then we're golden |
| 18:39.03 | russellb | just need to make sure that the new util gets packaged |
| 18:39.21 | pabelanger | However, I don't see Debian changing to asterisk 10 any time soon. Unless people request it. They have no interest in maintaining 2 version of asterisk at once |
| 18:39.34 | otherwiseguy | Yeah. If someone is building it on their own machine, I check and see if they have an astdb but no astdb2sqlite3 and force it to build anyway even if they have physically gone in and disabled it. |
| 18:39.46 | russellb | physically? :-) |
| 18:39.59 | otherwiseguy | Clicks are physical. :-) |
| 18:40.33 | otherwiseguy | But, it occurred to me that wouldn't help packagers. |
| 18:40.51 | russellb | how kind of you to think of the packagers :-) |
| 18:41.18 | otherwiseguy | And I'm not sure forcing it under absolutely all circumstances would be a good idea. I just aimed for a situation where I was pretty sure it would be required. |
| 18:41.26 | russellb | asterisk 10 will be in Fedora 17, roughly 6 months away |
| 18:41.52 | Qwell | Asterisk 10 in Fedora? It's a Beefy Miracle! |
| 18:42.14 | otherwiseguy | mmm, beef. |
| 18:42.16 | russellb | "Nothing says professional like Beefy Miracle" --Qwell |
| 18:42.30 | russellb | did not vote for that name. |
| 18:52.49 | pabelanger | Did that name win? |
| 18:53.03 | russellb | it's not over yet i think |
| 18:53.35 | russellb | will be announced tomorrow |
| 18:53.50 | russellb | https://admin.fedoraproject.org/voting/about/relnamef17 |
| 19:40.28 | kpfleming | what insanity is going in here? actual work? what what? |
| 19:40.56 | russellb | kpfleming: nothing to see here, move along |
| 19:52.39 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.75.202) |
| 19:52.39 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 19:53.52 | kpfleming | oej: two RFC errata posted in one day? you have been busy. |
| 19:55.17 | irroot | chan_lcr clean up and merge ?? or not to bother ?? |
| 19:55.38 | russellb | was it posted to issues.asterisk.org? |
| 19:56.42 | irroot | russellb nope ive just got it to build on 10 as a replacement for chan_misdn |
| 19:56.58 | irroot | its messy real messy |
| 19:57.09 | russellb | then that's a show stopper |
| 19:57.31 | russellb | it can't be merged unless it's officially contributed and covered by a contributor license agreement |
| 19:59.11 | irroot | russellb that can probably be arranged my Q is more should we follow up as chan_misdn is [should be] dying |
| 19:59.30 | kpfleming | chan_misdn works fine |
| 20:00.17 | irroot | kpfleming the confusion is it works fine till 2.6.27 after that its not supported i have a branch working upto lin 3 but there is no support on it at all |
| 20:00.32 | kpfleming | ok |
| 20:00.45 | kpfleming | but a lot of boards that used to be used with it can now be used with chan_dahdi |
| 20:01.01 | kpfleming | and with the zaphfc patches, the single-port boards can be used with chan_dahdi as well |
| 20:01.25 | kpfleming | so i'd say that it would be more useful to ensure that chan_dahdi provides everything that chan_misdn users need, rather than bringing it yet another channel driver for ISDN stuff |
| 20:02.05 | irroot | kpfleming the only lacking bits from my point of view is USB |
| 20:02.33 | irroot | i may stab it sometime good way to get under the hood of dahdi |
| 20:59.20 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.79) |
| 22:04.30 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-mwddxwouprjkqzzv) |
| 23:23.10 | *** part/#asterisk-dev korch (~hogemoge@ec2-204-236-228-187.compute-1.amazonaws.com) |
| 23:53.38 | *** join/#asterisk-dev bklang (~bklang@99-206-247-252.pools.spcsdns.net) |