I tried to record the DISA calls (using IPKall numbers) without success.
On searching over the Net, I found the following resource ( http://seal-7.blogspot.com/2008/06/recording-transport-with-freepbx.html), but could not confirm whether it would be compatible with the FreePBX?
I request the developers and experts and confirm whether it is the ideal way. Thanks!
(Posted here too: http://www.freepbx.org/trac/ticket/2790#comment:4 Sorry for crossposting but I thought it is relevant and worth) 
Hi Guys,
Any updates regarding this Ticket #2790 ?
Recording DISA calls
It is a very useful function in PBX.
I was really hoping that it would be in the upcoming release of 2.7
I am working on a large project, and recording outgoing DISA calls is probably the most important feature of it.
I was so happy to see that this was planned for v.2.7, but unfortunately - no.
What about a “bounty”? My company would gladly help pushing development in the right direction with a few hundred US$…
Looks like it’s pretty important to at least a few of you.
You can always engage the paid support department on such requests, if one of you has not already done so…
Excuse me for maybe being rude, but I find 150 US$ a little stiff to have someone look into it, and then, if at all possible, present a final price?
We all need to find a way to make a living, I understand that. But in most jobs, it’s quite common that the customers ask “how much for the job?”, and it’s not a 150 for that answer…
Oh well, sorry, this doesn’t help my case, does it…
netphreak,
the support folks used to do what you requested.
The problem became that so many requests come in that if no filter is provided, the team ends up spending 30-60 minutes to work out what it will take to do x, y or z feature request. Well when 1 of 10 people are willing to pay what things really cost, that results in 5-10 hours of time spent just assessing costs for each request that they are engaged into doing.
That is why they now charge to “assess” the costs of doing a feature. And don’t mi-understand what that means. When a developer “assesses” what it is going to take to do something, it means they are starting to do the work. There is no overhead in that.
If you are looking for ball park figures, that’s a hard call to provide. A typical feature can take anywhere from a couple hours to dozens of hours depending on how complex it is.
Not to belabor this but here’s another perspective if you don’t like that one. I’ve got a leak in my hot tub. It’s going to cost me $100 for the guy to come out and then tell me what is wrong and how much it might cost to fix (if he can figure it out in 30 minutes). Oh - and he didn’t give me the hot tub for free to begin with, otherwise, maybe I should expect him to come out for free :-).
Given how important you indicate this feature is in your blog post, spending $150 to get something started given the cost you paid for the software (also developed by those same folks) is not exactly “stiff” when you take all that into consideration.
I hope this helps you understand the reasons and maybe a different perspective.
Thank you for your answer Philippe!
I can imagine the number of requests you receive - which is a good thing after all 
I will try to get my boss to spend some money on this.
Just a short follow up to your plummer example: When I decided we needed to extend our house with 2 more rooms, we called a few carpenters. They all came, and didn’t ask a dime to let me know what it would cost Though, I see your point with 1:10 (probably even less) “customers” actually willing to pay at some point. The carpenters would have a much higher chance of geting paid for the job in the end - and a much higher price, I assure you
What frightens me about starting to roll this ball, is that I see the original ticket is 2 years old, and nothing have happened. Which indicates this is probably not an easy goal to achieve…
netphreak,
there are plenty of tickets that are 2+ years old. Features get worked on for various reasons that all translate to some developer is interested in doing it for one reason or another.
Sometimes its something they want, sometimes it is pure academic interest, sometimes it is money.
There are also tickets that don’t get done because they get “lossed” in the bug tracker. Adding MoH to conferences is a perfect example. I just stumbled across the ticket in the 11th hour before closing the 2.7 release, complete with a patch that applied perfectly to test it out. (granted I ended up having to make some minor fixes to what the contributor had applied but…).
The other consideration of putting any feature into the product, and is considered in the “cost” of doing it, is long term support of the feature. (Cost being effort, $, etc.). Because often there is more backend work to maintain a feature then implementing it initially. (That’s one of a couple reasons why modules like Custom Contexts has never been put in as a Core Team supported module - which is about to seriously break in 2.8 for example.)
So I can’t honestly tell you what Recording in DISA is going to entail. My gut expectation is it probably is not that much work (Add a GUI field, add the required dialplan to trigger the recording). On the other hand, maybe there is more to it given how DISA let’s you re-initiate new calls, etc. - and all of that needs to be examined as well as tested with various scenarios once implemented…
I can do this for less than $150.
Make a virtual extension. Set inbound recording to Always. Set the unavailable destination to be the DISA you made. Set an inbound route (or IVR option, whatever) to point to this extension. Done.
Wow, that’s what I call a late reply
Over the 3 years since last time I participated in this thread, I’ve given up freepbx and the like, plain old Asterisk is the way to go if you have the need for more customized installations.
Funny to be reminded of this topic anyway
Yah, but I figured someone else might want to know a way, even after all these years. We’ve skipped FreePBX except on customer boxes and moved to OpenSIPS as the primary SIP router for our platform.
suggestion by Bitnetix really works but, default CRD become good for nothing… even we cant relate call recordings… we get 2 eateries in CDR for each call without the number which was dialed…
any one have any good suggestion…
simply want to provide dial tone to callers and keep track on who is calling whom… in CRD and call recordings.
suggestion by Bitnetix really works but, default CRD become good for nothing… even we cant relate call recordings… we get 2 eateries in CDR for each call without the number which was dialed…
any one have any good suggestion…
simply want to provide dial tone to callers and keep track on who is calling whom… in CRD and call recordings.
I tried the solution from Bitnetix but couldn’t get it to record. I have the virtual extension set up to force record the call then set the unavailable to the DISA I made. The system flows as expected but no recordings show up for the virtual extension. Was this ability changed with updates? Or is there now some better way to set the DISA to record and retrieve the recording?
I’m using FreePBX 12.0.38 Asterisk 11
I second this. I have implemented Bitnetix’s work around a while ago. The file name for call recordings identifies only the phone number who dialed the DISA, not who they called, and this makes it very difficult to track these down.
I actually have my assistant go through billing details daily with my outbound trunk provider, to identify the number, or numbers, that was called, and modify the file names of the recordings. VERY time consuming.
I would think the #1 reason for having a DISA is to record the calls, so it’s strange that a workaround is necessary in the first place, but can we at least get a better work-around that solves the file naming issue?