Hello!
In light of my recent lay-off from Digium, I find myself looking for a job and any consulting
work I can get until I find one. If anyone has any ideas or propositions, call me at 307-899-5535,
or email me at murf at parsetree dot com...
One area where I might be able to help:
The state of CDR processing in Asterisk is somewhat in limbo. On the one hand,
somewhere near 16 CDR bugs have been recently unassigned in the issue tracker,
and on the other hand, my work to provide a next-generation CDR generator
has only a rough start; the CEL work is still needing another review, and someone
to take care of the issues found in that review; perhaps someone will step into that role.
Since there's bills to pay, kids to feed, etc., I can't justify pushing any of these issues
for free. However, there exists a window of opportunity for the community!
Between now, and the time I get a "real job", I might have time to work on completing
the CEL->CDR converter I've proposed.
The cost of the project is a function of the deliverables, milestones, and etc. Depending
on what is wanted, it seems to me a 2-8 week project (to be realistic). The RFCs
document I published earlier would end up as the documentation, of course, and one
of the deliverables.
The catch: Before I start, one or a set of the community must guarantee that they'll support this
work. . As to what you get in return, I'm pretty flexible; I can develop in a public branch, and
supply a patch, or if my client(s) would prefer, I could keep the results private for some amount
of time, and then release them. I'd assume that it'd be nice to not have to patch this in forever.
Again, what you would get: CDRs generated that are dependable, easy to
maintain (for me or anyone else), and easier to manipulate via the dialplan
via a much simpler interface (IMHO). No spending weeks with the current
interface trying to find the magic combination of commands that will give you
what you need.
This is perhaps the best deal you could ever hope for with CDR's. I'd wager I
could do the job quicker and better than anyone else. I've been playing with
the ideas for over 2 years, and I have over 30 years of development experience.
I know pretty much what is wanted, and how to get there. If there's not
enough interest, I'm sure someone (perhaps Digium) will either fix the current
interface, or finish where I started, or submit something new; it's just a
matter of time. Or you could allow me to speed things up a bit!
I will not fix the bugs in the current CDR implementation. It's not worth it to you or me.
You might find some sharp unsuspecting kid willing to try, but even if he
succeeded, you'd still be left with problem code, hard to fix and maintain, and it
will break horribly whenever somebody made even small changes to the PBX
engine, masquerade code, etc. (Well, I *say* I won't do it, but for the right price,
I can do whatever is wanted!)
And I suspect that he/she would not succeed. I have a patch supplied that solves
maybe 1/2 of the open bugs, but breaks CDRs for assisted transfers even worse
than how it is broken now, and estimated that it would take 2 more weeks to *try*
to repair that damage and make them work right, or at least prove that the approach
was wrong. No, that is *not* the right way to handle this situation. But, of course,
individuals, the community, and Digium are always free to do as they wish!
Respond in private if you are interested in this or any other effort. Again, my phone is
307-899-5535, and my email is murf at parsetree dot com.
(ParseTree is my own little consulting corp).
In light of my recent lay-off from Digium, I find myself looking for a job and any consulting
work I can get until I find one. If anyone has any ideas or propositions, call me at 307-899-5535,
or email me at murf at parsetree dot com...
One area where I might be able to help:
The state of CDR processing in Asterisk is somewhat in limbo. On the one hand,
somewhere near 16 CDR bugs have been recently unassigned in the issue tracker,
and on the other hand, my work to provide a next-generation CDR generator
has only a rough start; the CEL work is still needing another review, and someone
to take care of the issues found in that review; perhaps someone will step into that role.
Since there's bills to pay, kids to feed, etc., I can't justify pushing any of these issues
for free. However, there exists a window of opportunity for the community!
Between now, and the time I get a "real job", I might have time to work on completing
the CEL->CDR converter I've proposed.
The cost of the project is a function of the deliverables, milestones, and etc. Depending
on what is wanted, it seems to me a 2-8 week project (to be realistic). The RFCs
document I published earlier would end up as the documentation, of course, and one
of the deliverables.
The catch: Before I start, one or a set of the community must guarantee that they'll support this
work. . As to what you get in return, I'm pretty flexible; I can develop in a public branch, and
supply a patch, or if my client(s) would prefer, I could keep the results private for some amount
of time, and then release them. I'd assume that it'd be nice to not have to patch this in forever.
Again, what you would get: CDRs generated that are dependable, easy to
maintain (for me or anyone else), and easier to manipulate via the dialplan
via a much simpler interface (IMHO). No spending weeks with the current
interface trying to find the magic combination of commands that will give you
what you need.
This is perhaps the best deal you could ever hope for with CDR's. I'd wager I
could do the job quicker and better than anyone else. I've been playing with
the ideas for over 2 years, and I have over 30 years of development experience.
I know pretty much what is wanted, and how to get there. If there's not
enough interest, I'm sure someone (perhaps Digium) will either fix the current
interface, or finish where I started, or submit something new; it's just a
matter of time. Or you could allow me to speed things up a bit!
I will not fix the bugs in the current CDR implementation. It's not worth it to you or me.
You might find some sharp unsuspecting kid willing to try, but even if he
succeeded, you'd still be left with problem code, hard to fix and maintain, and it
will break horribly whenever somebody made even small changes to the PBX
engine, masquerade code, etc. (Well, I *say* I won't do it, but for the right price,
I can do whatever is wanted!)
And I suspect that he/she would not succeed. I have a patch supplied that solves
maybe 1/2 of the open bugs, but breaks CDRs for assisted transfers even worse
than how it is broken now, and estimated that it would take 2 more weeks to *try*
to repair that damage and make them work right, or at least prove that the approach
was wrong. No, that is *not* the right way to handle this situation. But, of course,
individuals, the community, and Digium are always free to do as they wish!
Respond in private if you are interested in this or any other effort. Again, my phone is
307-899-5535, and my email is murf at parsetree dot com.
(ParseTree is my own little consulting corp).
--
Steve Murphy
ParseTree Corp
Posts
No comments:
Post a Comment