FreePBX 2.10 plans – what we are thinking

WIth 2.9 solidly behind us and one of the most feature rich releases ever, we are really pumped to keep up the momentum and brining you more great things! Several of [i]us[/i] (active developers) spent some time last week to map out what we want to try and accomplish in the next release, when it should come out, and tackle the hard problem of what we will need to move out of the 2.10 wish list so that we can get a release out before the end of 2012! Since it’s really important for us to bounce off such plans on all of you, I wanted to share a summary of what is on our mind.

Because the last release cycle was just shy of a year and incorporated some substantial architectural changes, we thought we would take a bit of a breather and shoot for a target date of Astricon 2011 for our next cycle, which means right around Nov 1. Since 2.9 has been out for about a month, this means we have about a 6 month cycle, or 5 months from now. That will gauge what we can and can’t get in.

So what are we planning in that time frame? I will be updating the [url=/trac/milestone/2.10]2.10 Milestone[/url] to reflect more details of our current thoughts, but in a nutshell this is what we have in mind. First, what are the big things going into the release that people have currently signed up for:

[list] [*] Call Recording functionality. This is the one [i]”big ticket item”[/i] that we want to try and tackle in this next release. For those long timers who care about call recording, you are probably aware of the limitations and issues with getting calls recorded. Our plan is to revisit the call recordings ability system wide and try to come up with an overall call recording capability that deals with policy constraints such as call recording between extensions if one allows and one doesn’t, etc. More to come on what we have in mind once we sit down and really start to design this out.
[*] [url=/forum/freepbx/general-help/rfc-backup-restore-renovations]Backup Module.[/url] Schmooze has stepped up to the plate and is planning on doing a rewrite of this module that has been long plagued with various challenges. Although this module often works fine for many, there continues to be a background ‘buzz’ of various issues that continue to be encountered and no one likes to find out that their backups failed at the time of restoring. Add your thoughts/comments/feature requests to [url=/forum/freepbx/general-help/rfc-backup-restore-renovations]this thread[/url]!
[*] IVR Module. Schmooze has also stepped up to the plate with a plan to rewrite this module. Details of what this means for features will be forth coming, but many of the changes are more internal coding changes that will facilitate our ability for other modules to “hook” into this. (This allows new functionality to be introduced, for example, a speech recognition module that could add the ability to speech enable an IVR).
[*] New Features. This is always the one we have a lot of fun with and where we can best engage the community! We have yet to dig through the hundreds of tickets or hear your feedback to blogs like this one in determining what we can squeeze into this release so that will all be forth coming. There are lots of ideas and I’m sure plenty of you will take this opportunity to add more! We will do our best to listen to all the input, read through all the tickets, and see what we can realistically get into the release given the time schedule and other “big” changes we are working towards! For now though, feel free to toss out your ideas!
[/list]

Outside of these major points, there are other decisions we have made going forward. Here is a summary and there will be more to come on some of these.

[list] [*] Asterisk release support: This topic is always sensitive and there has been a lot of discussion about this for quite some time. The challenge we always face is how far back to support an Asterisk release, in conjunction with their own support life commitments, and at the same time try to innovate and come out with new features and capabilities. In the timeframe of this release, 1.8 will have been out for a year and its stability is anticipated to be quite solid (it’s already looking pretty good now). Asterisk 1.10 will be coming out at the same time and as always we want to support the newest release. Both 1.4 and 1.6.x have already had their [i]end of life[/i] announced and by the time 2.10 is really mature, will no longer be supported by the Asterisk team. Given all that, we’ve decided to take the approach for 2.10 that we will focus on 1.8 and 1.10 support. This does NOT mean that it will not support 1.4 and 1.6, it means that we won’t go out of our way to support those and it’s unknown until we get a bit further down the road if there will be support issues for these releases. We will evaluate the situation further down the road and if it turns out that these release will be affected, we will make sure that 2.9 has a long enough support life to cover the requirements of those in the community who need to stay on older Asterisk releases, even to the extent that the Asterisk team is no longer supporting these.
[*] PHP Support: We will no longer support PHP4, which should not be an issue as PHP4 has been obsoleted now for multiple years and the measurable FreePBX population still on PHP4 is almost insignificant. We will be coding against PHP 5.3 and even though current releases of popular Linux distributions are not yet on 5.3, FreePBX already comes with a compatibility library that includes the missing pieces such that these will all be fine.
[*] A few things we will be deferring because of the release schedule is a rewrite of the User Portal (ARI) and the replacement of the current CDR Reports. However, due to the Call Recordings re-architecting mentioned above, the ARI will be maintained so as to tie into those changes.
[*] FOP: This one is a challenge we have been wrestling with for quite some time. The current FOP is not being maintained given the FOP2 that asternic has had out for quite some time. FOP2 is an excellent product and will be available in our Market Place, but the free version is quite lacking in its inability to have any control as to what gets displayed in the 15 free icons, thus making it very difficult to evaluate if it’s worth the purchase. (For you big sites, that’s not really an issue, but for all the small guys and hobbyists out there, it matters a bit more.) However, as it stands FOP does not really work and is plagued with issues which are not being addressed and we feel our hands are a bit forced in that it probably needs to be removed. That means outside of FOP2 (free and commercial) and the iSymphony solutions that will also be available in the marketplace, we are left without a good “free” replacement for FOP. We are happy to hear your thoughts and ideas around this as we really feel it’s something that is not in our control.
[/list]

Well, there’s a pretty good overview of what is going on and where our collective thoughts are at. We really look forward to hearing from you as we continue to move forward on this and will make sure to keep you up to date and incorporate your feedback into our planning process!

[b]Philippe[/b] – On behalf of the FreePBX Team!

32 thoughts on “FreePBX 2.10 plans – what we are thinking

  1. thanks peter, forgot to check the links 🙁

    and thanks mbrevda for fixing that!

    Now I just need to go update it so it doesn’t contradict what is written here…

    In the meantime, we welcome comments and discussion on the above, we value your input!

  2. We spend a lot of time in the CDR for situation diagnosis. I customize the asterisk-stat-v2 to suit the needs of each of our groups. I’m actually curious if others use it, don’t use it, or use it a lot like we do. We just don’t use it as part of the FPBX distro.

    Could there be an option to enable the recording of each call from the beginning of the call and then only save the call if the user requests prior to terminating the call? Suppose they do *1 at the beginning of the call or at the very end. The call would be recorded in it’s completion either way. (Other vendor’s schemes come to mind, but just keeping the whole call makes the most sense to me.)

    We have many users who will call into a conference or many external calls into the a conference. Each of these channels end up recording the same call. It seems like a small issue with just a handful of callers, but when there are 60+ in a single conference it seems odd to record each uniquely. If there were a way for the logic to only record one copy starting when the first caller enters a meetme and the rest of the caller’s CDR link back to the same file?

    I don’t know how common this would be, but it would be nice to be able to email some calls immediately after the call much like what happens with voicemail. At that point it could delete the file too.

    Lastly, more an issue of bundling asterisk in a distro, including the option to transcode voicemail and call recordings into mp3 files without having to massage the system would be nice.

    FOP has been useless for us. If it went away altogether we’d not notice.

  3. Peter,

    on the call recording suggestions there are some good ideas and as soon as we strike up a separate thread (or likely a page on the trac wiki) we will start to consolidate some of that.

    Things like the Conference rooms with each channel also being recorded is a great observation that would be nice to avoid replicating.

    The on demand recording saving the whole conversation is probably possible with some application feature codes that we could investigate. The downside is it implies that we would actually record every call and then disregard the recording if they didn’t ask for it and that would put quite a load on the system. However, the feature is a great idea and on a system that can handle all that recording, would be valuable to some. I guess another angle on this which we should think about is how we could design the system such that external call recording packages could be used and tied into the same controls/permissions/etc. that we are designing in…

  4. I like a lot of Peter’s ideas there, to build on that, CDRs reallllly need help, I think it is terrible that you cannot track a call from end to end – for instance you can see channel info, but if it came in on a SIP trunk that has more than 1 DID, you cannot see the DID, this is something basic that should be logged. The CDRs give a lot of info, but at the same time are still lacking a lot.

    To build even more – it would be nice to have a tick box in the IVR section that says “Log this selection to the CDR”, so if someone presses 1 on the IVR, it gets logged on the CDR.

  5. totalimpact,

    concerning the CDR fields, we do plan on adding additional fields where possible since one of the benefits of 1.8 (and I believe it was introduced in 1.6) is to have additional arbitrary CDR fields.

    So DIDs is one example of what we will look at adding. This does not “fix” many of the fundamental problems of CDRs but it does help improve what is already there. There will also probably be limited modifications to the CDR reports page, though something like DID fields is probably something we would want to try to expose.

    As far as your IVR type requests, this is something more suited for CEL and something that is very much of interest but is unlikely to make it into 2.10. That doesn’t mean we can’t start putting in some CEL logging features already but there won’t be any infrastructure to set it up or run reports on though an interested user could obviously do that manually in Asterisk. One of the things we had in mind wrt to CEL was to add “user level” logging at every step such as when running through a call flow module by module, and adding extra info such as IVR selections as a CEL event, assuming it is something that can be done. (And I suggest with such specific ideas that you file trac tickets so when we eventually work on this the ideas don’t get overlooked.)

  6. I’ve been doing this for a few years.

    (We don’t otherwise use [b]accountcode[/b].)

    [code][from-pstn-custom]
    exten => _+1.,1,Set(DID=${EXTEN:2}) ; Remove +1 from DID
    exten => _+1.,n,Set(CALLERID(num)=${CALLERID(num):2}) ; Remove +1 from CID
    exten => _+1.,n,Set(CDR(accountcode)=${DID})
    exten => _+1.,n,Goto(from-trunk,${DID},1) ; Go to from-trunk
    exten => _X.,1,Set(CDR(accountcode)=${EXTEN})
    [/code]

    (Looking at the code above, slapped together years ago now, that might stand for a little fixing.)

    I don’t suppose there’s a way to hook via the ivr-*-custom to track the key events because it uses WaitExten. If there were, the progression of what the caller did could be trapped in a channel variable by appending each event. (just thinking out loud)

  7. Peter,

    The new CEL system is exactly made for such event tracking. Given that, it’s the way to go imho.

    As mentioned, it’s “easy” to add dialplan to start to track such events which we are not adverse to doing. It means those who need this can manually setup CEL logging and do their own analysis until we can get something integrated into FreePBX.

    Maybe some motivated developer will go as far as to consider creating a module (free, commercial or both) that can accelerate this. We do have the commercial market place now so …

  8. If possible, I would like to have the ability to define a preferred outgoing route for each extension.

    I know this is possible with some creative use of prefixes or “Custom Contexts” but I would feel more confident using it if it was simply an option during extension creation.

    I had previously used “Asterisk GUI” in which you created “DialPlans” (I guess this was it’s own custom context) which consisted of an assortment of “Outgoing Rules”, each extension was then tied to a “DialPlan”.

    Our company has 3 internal departments and this not only helped to track each departments usage but also made sure that the outgoing CID was consistent each time. As a side benefit it provided a very simple way of controlling who could make International calls etc.

  9. there are multiple ways to achieve what you are asking for.

    You can use the “unsupported” custom context module to do this, which is in fairly wide spread use so there is a large base for community support on this.

    You can also use the CID field in the outbound routes to restrict routes to certain extensions.

    Both of these options, although possibly slightly tedious, are fairly straight forward to implement.

    Not to say we are not constantly looking for ways to make things more intuitive but just fyi in this case…

  10. I, for one, will miss FOP. I don’t use it for call handling (transfers, etc), since it sucks at that. But it worked fine, at least most of the time, for just being able to see who was on the phone and which line they were using, and which incoming line/trunk was ringing on inbound calls. Simple troubleshooting and system status while doing MACs to the system.

    Something that performs that functionality within FreePBX would be awesome. Even if it’s a text only table-like layout with several columns which stay updated with relevant information: Inbound/Outbound – Call destination/origination (extension/IVR/call group in use for the call) – Number calling/called – time of call – trunk/line – etc

    Or, could FOP just be re-written/simplified to be read-only (no call handling)?

    Or is there something else I could use?

  11. I agree with the previous poster that FOP is very handy to get a quick overview of extension and trunk status, view active channels and calls, etc…
    So please leave it in for the time being until a good alternative is ready to replace it.
  12. Some of the issues with FOP:
    [list]
    [*] it sucks a TON of system resources (we’ve seen major system performance degration, especially when using queues)
    [*] It also is a pain to configure if your not using the default layout (say – if you have more extensions that fit on the page)
    [*] most of the functionality is outdated (i.e. doesnt work with asterisk 1.8
    [*] is poorly integrated to FreePBX and has no developer standing behind it
    [*] is no longer maintained, even outside the realm of FreePBX
    [/list]

    From a non this-is-cool-to-show-off-when-it-works point of view, I really think it needs to go. As they say: “No point in beating a dead horse”

  13. @TechOne – no, fop cant be easily rewritten (otherwise we would have!). Yes there are other products on the market that dont suffer from the downsides that fop has. Have at look at iSymphony for one.
  14. @orion – the question is if the end justify the means. Even its limited use is limited, meaning that even those installs that can use it just to see which extensions are in use are limited: There are many factors in play when using fop, and the resources that it consumes (both from your system and from a development point of view) really doesn’t justify its continued inclusion.

    By way of clarification, we are by no means against having a properly working, properly maintained product as part of FreePBX. We have been EXTREMELY patient with fop to see if there will be architectural improvements and to see if anyone will step up to the plate to maintain it. We are totally cool with a replacement – provided it meets certain guidelines (mainly, that it doesn’t suffer the same issues that brought us here in the first place). At this point however, it seems that the time has come to pull the plug.

  15. Greetings …

    Improvements to CDR would be welcome, I did a little hacking to add the PIN codes display and might even be better to be able to display People/Accounts with PINs, but that is a pretty small coding project. What would be nice, is the function to be able to import call costing from Telcos. Giving users the ability to keep the Telcos honest and also a first step at better cost predication and maybe work on Least Cost Routing, using the imported history, just an idea, that I wish to work on during some spare time.

    Call Recording, accessible via User Portal or e-mailed after a call, I think somebody has already suggested this, but I can see working and easy to put in place for my users.

    FOP is great for diagnostic or to inform users with larger systems or simple phones, but yes, it has many failings, like, not working well with mISDN system. Still need to figure out why the latest mISDN FreePBX module is not working.

    Thanks
    Mailed
    LeeT

  16. For those using FOP and Asterisk 1.8, what are you seeing?

    What is working, what is not working?

    From the bits and pieces of feedback we are getting, we keep hearing it is severely broken in 1.8. Is that really the case? I understand the concern of FOP going away. As I indicated in the post, we feel our hands are tied. We are not “deciding” to take it out. We are feeling that we’ve been “beating a dead horse with a stick” for a while now and the horse just is not coming back to! We’ve also looked at multiple other solutions and have been in constant talks with other vendors such as the guys at iSymphony and asternic wrt to FOP2 to see what might be possible for alternative “free” options which would address the “hobbiest” base that may not be able to justify paying for a solution, while making sure there are high class paid solutions which there are (again, products like iSymphony) with whom we have been working together for years to get these professional solutions more tightly integrated with FreePBX and which will be available in the marketplace.

    So feedback on 1.8 please in case we are not hearing right?

  17. I can certainly understand why FOP should go away, considering performance problems.

    Does iSymphony show trunks/lines? From what I’ve seen of it, it doesn’t. I really want to be able to easily see what inbound trunks are ringing, and who is on the phone with which external caller, etc…

  18. I have two small suggestions;

    * One I spent a bunch of time recently walking someone through DAHDI who had used ZAP at one time. We got to the Chanel Banked Centrex lines and setup the “ZAP Channel DIDS” module so that inbound the routing worked the way they wanted. Since this is mostly tags and context names, could we get it updated to Dahdi Channel DIDS or maybe some non technology specific label (Inward Dids)?? Spending lots of time explaining why we don’t have ZAP any longer and then telling someone to use ZAP Channel DIDs is a bit confusing.

    * On another note, a number of years ago Phillipe was nice enough to help me during a Huntsville class with a mod to force the outbound call to a Centrex Channel (Channel Bank slot) with a combination of a data entry in Asterisk and a modified context. This has been a big help because now the outbound PSTN call almost always goes out the trunk assigned as the Inward route so it acts like a private line in a copper world. A SIP /IAX2 solution would be better, but the customer is always right..

    TIA —

  19. I don’t know how many organizations use Conferences like we do (4xPRIs + SIP Trunking). We’ve issued one or more conference “rooms” to our employees who can bring up their conferences on an ad hoc basis. Much like the voicemail having a portal, could we have a conferences portal?

    The WebMeetMe is something close to what I’m thinking, but without the scheduling and AD integration. The core features would include:

    [code] – Ability to change Admin PIN
    – Abiiity to change User PIN
    – Ability to change the conference options:
    – Leader Wait:
    – Quiet Mode:
    – User Count:
    – User join/leave:
    – Music on Hold:
    – Music on Hold Class:
    – Allow Menu:
    – Record Conference:
    – Maximum Participants:
    – Mute on Join:
    – While a conference is in session, the admin can:
    – see all callers by number and caller-id
    – mute individual channels in an active meetme
    – mute all but admin in an active meetme
    – control the speaking level of each channel
    – control the loudness of each channel
    – dial a number to be added to the conference without PIN
    – kick a caller
    – Bonus points would be given for an active GUI that can display the current “talker”
    – Multiple Admin’s may be using GUI on the same meetme simultaneously
    – Ensure it can support >70 simultaneous members in the meetme
    [/code]
    This probably has merits of being its own app or an app in the fbpx store. (I only wish I had time and php/ajax/html5 skills.)

  20. I’ve been using the system for a couple of years now to host small business VOIP Service and want to thank you guys and say it’s great. I’ve managed to get custom parking lot group assignments working (including a GUI change to assign it to extensions), Missed Call e-mail notifications (custom script), CDR and report modifications to show DNID (dialed number), and recording integration with our web-based platform. I’ve also been able to restrict outbound calls to specific routes using available tools and do some other interesting things with the platform. Thanks again for all your hard work – it’s really great.

    I’m currently on 2.8.1.4 on Asterisk 1.8.4.

    I was originally a fan of FOP, but as our systems have grown, we’ve turned it off. A replacement desktop tool for this or seperate service for it – runnable on a seperate server would be nice, but we’ll do iSymphony if we REALLY need it – so far, we’re ok without it.

    I’m far from an expert, but have some experience and here are some things I’d like to see – forgive my ignorance in advance if there are other solutions for these that I should be looking at – I also realize that these are my personal and business desires and that there are a lot of other people out there with other needs that may take priority:

    1. Customers and/or Groups creation ability along with the ability to assign any object (extension, ring-group, inbound route, ivr, etc..) to that group with permissions to see or change it and REPORT on it. I’d like to be able to assign inbound routes to a client and run some call reports, for example. Reporting in general could definitely use a lift. The CDR reports, much like FOP seem to be pretty stagnate.

    2. Recording flexibility and new reporting capabilities – it would be nice for me to get away from the seperate web and sql based platform that I run for this. There’s a big question in my mind about whether recording changes (and possibly a new interface) would be part of CDR data and reports or would have options to configure and control it completely seperate from CDR’s. Ideal for me would be recordings including in a call log report which was tied to the customers/groups concept as described above – as part of an overall reporting overhaul – where CDR reports would become call-detail reports with play controls for recordings, but could be grouped and/or restricted by customer and/or group. Summary reports would be great too – by group, geography, area code, DNID, etc…. Customizable call dispositions, notes, and other fields would be a nice add. here too for the call detail interface. Customers like to listen to them, select if they made a sale or not, write notes about the call, etc…

    3. Redundancy/Replication – Some sort of built-in support to replicate the configs/db/recordings, etc… and/or have a back-up/secondary server with a shared IP would be awesome. I know there are solutions out there for this, but I think nearly everyone would be more confident in having 2 servers look like 1.

    4. End of call post-back URL support might be good – we could send our call data to google analytics which may help with the reporting end of things…not sure how far that could be taken, but it’s worth a look.

    5. E-mailing recordings at call completion would be nice along with the above – similar to voicemail, but for all recorded calls if you turn it on.

    6. Missed call notification via e-mail on the interface would be nice as opposed to the custom scripting currently required.

    7. Simple screen-pop tool and/or Com object to write one. I don’t necessarily want a soft-phone – although a tool that provided call control of existing hard-phones would be a nice addition…not sure if we could control answer and dialing on a hard-phone, but hangup and hold probably could be pretty easy. Maybe answer and dialing could also be done via info/options msgs.

    8. Number pool management built into the system seperate from inbound routes. It would be nice to keep track of numbers that you may have which are not assigned to anything – or numbers that you decommission. Also nice if assigned numbers showed the client/group requested in item 1.

    9. Click-To-Call creation/management built into the interface would be cool. I’m doing click-to-call today with custom web-scripts and AMI, but it would be nice to be able to manage it in the interface.

    I’m sure there’s more that I’m not thinking about, but hopefully the above spark a few ideas. Feel free to e-mail me or respond to the thread if you want more info.

  21. While we don’t have much of a problem with managing WHEN or IF a call gets recorded, we do record EVERY incoming call to our main customer service queue.

    Based on that fact, we generate a very large number of call recordings in /var/spool/asterisk/monitor, which take up surprisingly little space when recorded as wav49 format.

    Based on this, I would like to see two things WRT recordings:

    1.) A dedicated interface for finding and reviewing call recordings. Normally I know who took the call, and when, and I can find the call in the CDRs, but I cannot get to the recording without going into MySQL to look up the UniqueID, because ARI chokes on the large number of recordings.
    2.) A tool that archives recordings by date. Without this, we end up with absurd numbers of recording files in the monitor directory, which makes finding what you want difficult.

    I also like the idea of being able to track DID in the CDRs. Something as simple as knowing which numbers have been receiving the most traffic would be huge. One example is that many companies will use a new DID specifically for one marketing campaign, and track response by how many calls come in to that number. If there’s a way to do this now (besides the accountcode trick mentioned above), I am unaware of it.

    Tom

  22. I also have been looking for Trixbox-like call recording functionality for a long time now. Basically, it is just a link to the recorded file in a CDR report. IIRC, there were security and scalability/speed problems with the TB implementation, but the essence of the request is that the process for finding the call recordings should not require more work than just finding the call in the CDRs. Searching via incoming trunk, callerID, date/time, called party, etc would be ideal.
  23. I’m in the middle of rebuilding my server at work for two reasons: 1) It needs an upgrade and a cleaning and some cleaner routing, and 2) Almost everyone in my 40-person office is complaining about FOP being broken. Like the above posters, my people use it to see who’s on a call and for how long.

    I must at least ask to not get rid of it, though I understand if it must go for the greater good.

    I would have no problem with FOP2 if it was just a little easier to manipulate during installation (especially if one is upgrading from the original). I have purchased a license for it and never did get it to work correctly- though that’s not the programmer’s fault! I’ve seen the product in operation; Asternic can be proud of themselves.

  24. Already reinstalled a few times.
    And I’m not getting anywhere with installing mISDN.
    The results are:

    yum install asterisk18-misdn
    (Since that is supposedly the correct incantation)
    And I get:

    —> Package asterisk18-misdn.i386 0:1.8.7.1-1_centos5 set to be updated
    –> Processing Dependency: mISDN-kmod for package: asterisk18-misdn
    –> Processing Dependency: mISDN for package: asterisk18-misdn
    –> Processing Dependency: mISDNuser for package: asterisk18-misdn
    –> Running transaction check
    —> Package asterisk18-misdn.i386 0:1.8.7.1-1_centos5 set to be updated
    –> Processing Dependency: mISDN-kmod for package: asterisk18-misdn
    —> Package mISDN.i686 0:1.1.7.2-3_centos5 set to be updated
    –> Processing Dependency: kmod-mISDN for package: mISDN
    —> Package mISDNuser.i386 0:1.1.7.2-1_centos5 set to be updated
    –> Finished Dependency Resolution
    mISDN-1.1.7.2-3_centos5.i686 from pbx has depsolving problems
    –> Missing Dependency: kmod-mISDN is needed by package mISDN-1.1.7.2-3_centos5.i686 (pbx)
    asterisk18-misdn-1.8.7.1-1_centos5.i386 from pbx has depsolving problems
    –> Missing Dependency: mISDN-kmod is needed by package asterisk18-misdn-1.8.7.1-1_centos5.i386 (pbx)
    Error: Missing Dependency: mISDN-kmod is needed by package asterisk18-misdn-1.8.7.1-1_centos5.i386 (pbx)
    Error: Missing Dependency: kmod-mISDN is needed by package mISDN-1.1.7.2-3_centos5.i686 (pbx)

    Which I think stems from the fact that dependancies ask for:
    – mISDN-kmod
    – kmod-mISDN

    But I’m not a yum guru, so I’m relucant to run anything like yum update, since that created an ever greater mess ending in me losing dadhi stuff.

  25. Greetings …

    I think this is the wrong place to be asking this question, but I will try and help away.

    You need to install the kmod-mISDN for the kernel you running. I have had this problem before, so I have manually checked and installed the correct kmod that is available for my kernel. Some times, kernel come out before the kmod is updated, so you need to check if there is a kernel and kmod.

    I think you should be able to do …

    yum install mISDN-kmod-base asterisk-misdn

    and that should pull in all your needed dependencies.

    Mine looked like this …
    [leet@pbx ~]$ rpm -qa |grep -i misdn | sort
    asterisk-misdn-1.8.7.1-1_centos5
    kmod-mISDN-1.1.7.2-3_centos5.2.6.18_238.12.1.el5
    kmod-mISDN-1.1.7.2-3_centos5.2.6.18_238.19.1.el5
    kmod-mISDN-1.1.7.2-3_centos5.2.6.18_238.9.1.el5
    kmod-mISDN-1.1.7.2-3_centos5.2.6.18_274.3.1.el5
    mISDN-1.1.7.2-3_centos5
    mISDN-kmod-base-1.1.7.2-2_centos5.2.6.18_128.1.16.el5
    mISDNuser-1.1.7.2-1_centos5

    And I have both mISDN and DAHDI running, so it should not be a problem.

    You might also find more details at http://www.asterisk.org/downloads/yum

    Best of luck
    LeeT

  26. YUP,

    I totally agree.
    But I sort of forgot where I was, being happy to find anything about ISDN here….
    It seems a sort of subject with very little concise attention.
    I’d be happy to remove my submission and put it somewhere in the forum for history…

    Perhaps because ISDN did not make it to what is was set to be, and it is not much used in the US?

  27. Not a problem.

    Mmm, I use mISDN because we have access to in-expensive USB ISDN TA devices. Which for up to 5 ISDN devices works well.

    I hope you come right, if you need more help, let me know.

    FreePBX mISDN module is not working so well at the moment and I don’t know enough php to fix the current problem, you will have to manually configure your mISDN install once the rpms are in place.

    Thanks
    Mailed
    LeeT

Leave a Reply