Looks like the thread full of insults and lookie heres RE: you timing post missed the point. I will assume you are referring to this:
grep ZAPTEL `find . -name \*.c`./apps/app_meetme.c:"Please note: A ZAPTEL INTERFACE MUST BE INSTALLED FOR CONFERENCING TO WORK!\n\n"./apps/app_meetme.c:"A ZAPTEL INTERFACE MUST BE INSTALLED FOR CONFERENCING FUNCTIONALITY.\n";./channel.c:#ifdef ZAPTEL_OPTIMIZATIONS./channel.c:#ifdef ZAPTEL_OPTIMIZATIONS./channel.c:#ifdef ZAPTEL_OPTIMIZATIONS./channel.c:#ifdef ZAPTEL_OPTIMIZATIONS./channel.c:#ifdef ZAPTEL_OPTIMIZATIONS./channel.c:#ifdef ZAPTEL_OPTIMIZATIONS./file.c:#ifdef ZAPTEL_OPTIMIZATIONS./file.c:#ifdef ZAPTEL_OPTIMIZATIONS./file.c:#ifdef ZAPTEL_OPTIMIZATIONS./file.c:#ifdef ZAPTEL_OPTIMIZATIONS
More or less, the timing lesson you were given as a response is not untrue but is also not relevant to your question. Where it may be true that for TDM you have an enormous dependency on time sync you have much less with VoIP. The bigger reason for the Zaptel timing for non-hardware stuff comes from the hatred of threads that Asterisk has.
In a typical call in Asterisk, 2 channels exist within 1 thread. This thread must poll both channels and service them based on socket events. The first problem is that not every channel type has a socket (most do but IAX2, for example, does not which is another can of worms). The second problem is that most routines in Asterisk make the assumption that if you read from the channel in a loop you can write to the channel on each pass and have perfect timing. Sorry, thanks for playing, but you cannot do that. Many protocols (SIP for example) have VAD (Voice Activity Detection) support. This means that the far end of your call may not send any voice because the other guy is not talking so why bother. When this occurs the poor Asterisk channel expecting reads to dictate writes simply halts in place DoH!
This problem is fixed by a friendly "Don't use VAD" console message. And they are trying to improve on it by somehow trying to weave some logic in there to make that poll timeout and let it work still using good ol' Zaptel timer but it's like digging a hole too deep and just makes the mess bigger if both channels we in their own independent I/O thread the problem would be gone.
The next place Zaptel is wedged into place is in the channel I/O routines. A pipe is opened inside the channel to allow the queuing of frames meaning you can write them as fast as you want and the channel will deliver them at a steady interval. Thank goodness Asterisk is hard coded to only operate at 8000hz! This also compensates for the channels with no socket you can just queue all the inbound frames instead of write them. This constant pulse is also courtesy of Zaptel timer.
Next there is the file delivery system which is really the one place you really need a timer for sure since the file is simply a large collection of data so it must be fed at a timed interval this also is somewhere the Zaptel timer is used.
The timer is also used by the external music on hold system. The default system uses an external pipe to an mp3 player that also spits the data out too fast since it has no soundcard for timing so the Zaptel timer to the rescue again!
The one place you cannot avoid the timer is the MeetMe application. This is a conference system that depends on the Zaptel to do the audio buffering/muxing and the timing. There is, however, a purely soft-timed algorithm-based conference application available.
I have respect for you so therefore I will simply address your concerns and move on. Please be aware that I am not taking my ball and going home. In fact, I currently have 2 or 3 issues open in the Asterisk bug tracker and I now have a policy not to submit any more until older ones are cleared up.
I am not close-minded and I will use/develop for any software that I find a need for. I still have much more Asterisk code I can submit.
Now, to adress the concerns:
we have rejected some of his more radical patches (mostly implementing the idea that everything, even the module loader itself, should be able to be unloaded). While we agree with modular design, there should be a limit; something has to be core, or all your product is is a module loader.
This patch did not propose to make the module loader unloadable rather to make it possible to load an alternate implementation of the PBX functionality.
At the time of that posting there was a general agreement that the Asterisk dialplan and the resulting codepath of traversing the PBX needed work but nobody wanted to break the program to fix it. With that patch one could build an alternate PBX callflow engine without disturbing the existing one. This is actually an important idea which i carried to FreeSwitch that the core would only deal with interfaces and pure low-level functionality. And to implement a PBX it would be done in higher level code supplied in the module API. I agree something has to be core and I have thousands of lines of code in my core already.
The other problem with Asterisk modules are that many of the in-tree modules carry cross dependencies that make it impossible for the core to function without them. This isn't true. I'm not sure where he got this idea, but certainly some modules depend upon others. That should be a given, but the idea that the core depends upon a module isn't true. Perhaps we modularized something that he thought should be core?
I'm sorry but it is true. Allow me to elaborate with specific examples but before I do, remember, in the previous paragraph I was accused of not wanting anything in the core and now my problem is that I want more in the core.
Here is a patch, written by me, that fixes a catch-22 in the Asterisk music on hold caused by the core being dependant on the loadable music on hold module.
The symbols ast_moh_start and ast_moh_stop were referred to in the core in several places and these symbols only existed in the dynamic module object therefore if you did not load the music on hold module the entire application would fail to start. At the time I wrote this patch there were still several other such issues that may or may not have been addressed but it still demonstrates the design issues and the inability to define how the core interacts with the modules.
EXHIBIT B There is a module called res_features.so which contains the actual code that is executed when two channels are bridged ast_bridge_call and the entire parking concept ast_park_call both of the functions are used in other modules causing a module cross dependancy. Many operating systems will not even let you do this because you must employ lazy linking where 1 dynamic object is forced to trust that certian symbols will exist when the time comes.
soon all the developers will be nothing but users who have no other choice but to try and be developers
It's unfortunate to hear such an elitist attitude. We all were only users once. Those of us who were interested enough l
My name is Anthony Minessale, After considerable contribution to Asterisk I have learned a great deal about telephony here is a list of my personal contributions to Asterisk: http://www.cluecon.com/anthm.html
The biggest lesson I have learned is that the fundamentals of Asterisk are built on assumptions and hard coded limitations. The flow chart for its code will make you dizzy:
People who use asterisk from the outside wouldn't know there is absolutely no structure or discipline in the code and may not care. But once they invest a ton of time trying to make their dream Telco or whatever their dreams may be, the truth is all too obvious. Spoken from experience, only a seasoned technical wizard with years of computer skills to boast will ever be able to successfully implement Asterisk beyond a modest implementation. To truly understand how Asterisk works holds only a slightly smaller prerequisite. To those who find this unimportant, I understand your point, but be aware that Asterisk, being an open source project, needs to have a somewhat easy learning curve to attract new developers especially considering the developer turnover they suffer due to the maddening politics their community has to offer. The development is focused on owning all the code even if it means re-inventing things that already exist just to maintain the right to sell the code. This practice is fine with me though I am less than pleased by the end result when the home-rolled version is a poor contender with several existing solutions. The modular intentions of Asterisk are great though there is no structure there either. Any module can dig its way into nearly all of the code of the core and often, inexperienced module programmers will re-implement existing functionality to the extent that even inside the same C source file, you may find multiple versions of the same functions with different names. The other problem with Asterisk modules are that many of the in-tree modules carry cross dependencies that make it impossible for the core to function without them. Some modules even depend on each other. This practice limits the portability since many operating systems will not tolerate one dynamic object from using symbols from another without hard linking them together. This is not the worst offense as far as portability; there are dozens more with many being accredited to Linux-specific assumptions. Apart from the technology problems the biggest remaining problem to consider is the community. The first experience for most Asterisk newcomers is an IRC channel where people fight for supremacy like information hungry pirates hording what they know and then sticking it to people for being so "stupid". (In other words, in the same boat they were in a few months back.) For those of us who are experienced developers, we are used to the l33t thing. The deal breaker is the issue management process. Submissions will generally be ignored for months then a one sentence overview will command the developer to fix minor issues and resubmit. This is almost tolerable if the submitted code was a new feature but more times than not it also happens with meaningful clean-up and repair of broken core functionality. I have heard this same complaint from countless ex-asterisk contributors over the past year and I am sure it is the number one cause of their ex status.
In conclusion, I actively develop Asterisk code but now I only do it as a consultant. I am quite good at it and I know what I am talking about and I feel that the issues with Asterisk will never be addressed because there may be more Asterisk users every day but there are also less developers every day too and soon all the developers will be
Speaking of RSS, I just made a voice RSS Browser yesterday.
The source code is available to download and the program will let you turn just about any RSS feed into an IVR in less than a minute.
http://www.pbxfreeware.org/
Please bear with me because it took a great deal of discipline to choose kind words for my reply. You must resist the urge to compulsively say the first thing that comes into your mind especially when your words will be seen by many thousands of people. The statement that C is slow and has no compiler is a dead giveaway that you have no idea at all what you are talking about. It may look nice to see your words in print and all but you must realize that it is a moot point to try and compare C to Java because Java is a language designed to run on any platform and in most cases the Java Implementation itself is written in C. Take Linux for instance, The entire operating system it 100% C, every UNIX variant is like a big living breathing C environment including Sun Solaris where Java was born. So you see, you are welcome to appreciate Java but keep in mind that C is the low level language that just about every other programming language is written in. So to summarize, Everything you do in Java is in turn calling C or C++ code which then calls the operating system's system call. Therefore you should avoid saying things like Java is faster or better than C or the next person that replies may not be so civil.
I'm not sure which of my statements you will quote this time in your alogrytmic attempt to gently flame me in your next reply but I hope it's a good one so that means actually read my whole statement this time as you choose.
The issue of insecurity is obvious but it is rediculous to say that something related to pop-up boxes in a browser has anything to do with JavaScript just because the mechinism was implemented with it. To me that proves you do not understand how it works very well. The JavaScript maintainers in most cases ARE the browser devlopers as well or at least work closely with them. Mozilla, for instance, happens to maintain both in thier CVS tree. Regardles of this, the same guy or 2 different guys developing the engine and the browser the security still is guarded at the place where they meet. So i'm not burying my head anywhere because chances are the same guy is going to fix it from my point of view as is from yours only he will have his Mozilla Browser hat on not his JavaScript one. I'll restate that the componets of JavaScript that even make a pop-up window possible is only found in browser implementations so it's not JavaScript as a whole that needs work only the 'Browser' object module. There is no kop-out only clarification. Enjoy the last word as I have nothing more to say on this matter. Perhaps instead of trying to subtly insult me and my Asterisk module that happens to prove my point perfectly, you should use that last word to post your proposal on what feature you plan to add to one of the open source JavaScript engines and maybe submit some code. Then you can try to convince the closed source implementations to adopt this new uber secure enhancement.
but, It is out of the scope of the language to be responsible for how it will be implemented in a browser when a browser is not the only application it is able to be implemented in. The Document and Browser objects in JavaScript are not standard they are addon's used when the language is applied to a document rendering model. Therefore the developers who implement the marraige of JavaScript to a browser are indeed responsible to make sure it does not raise any security concerns. When I added JavaScript to Asterisk I had to implement serurity features that only make sense in a PBX and I would not have expected the language to come standard with a way to handle that situation.
See http://www.cluecon.com/res_js.html for reference
It may be possible for JavaScript to help evil-doers but it's up to the implementer of the Application using the engine to avoid that, not the language or its core developers.
If every invention that could potentially be used for evil was struck down there would be nothing left. JavaScript can do plenty of good and the developers of the open source engines have gone out of their way to make it well documented, embeddable and extensible so you can add it to almost anything that needs a little help with a language parser. In fact, I myself have recently added JavaScript to the Asterisk PBX system to drive IVR and it works quite well without much concern for exploits.
RES_JS for Asterisk: http://www.cluecon.com/res_js.html
Slashdot Mirror
Looks like the thread full of insults and lookie heres RE: you timing post missed the point. I will assume you are referring to this:
./apps/app_meetme.c:"Please note: A ZAPTEL INTERFACE MUST BE INSTALLED FOR CONFERENCING TO WORK!\n\n" ./apps/app_meetme.c:"A ZAPTEL INTERFACE MUST BE INSTALLED FOR CONFERENCING FUNCTIONALITY.\n"; ./channel.c:#ifdef ZAPTEL_OPTIMIZATIONS ./channel.c:#ifdef ZAPTEL_OPTIMIZATIONS ./channel.c:#ifdef ZAPTEL_OPTIMIZATIONS ./channel.c:#ifdef ZAPTEL_OPTIMIZATIONS ./channel.c:#ifdef ZAPTEL_OPTIMIZATIONS ./channel.c:#ifdef ZAPTEL_OPTIMIZATIONS ./file.c:#ifdef ZAPTEL_OPTIMIZATIONS ./file.c:#ifdef ZAPTEL_OPTIMIZATIONS ./file.c:#ifdef ZAPTEL_OPTIMIZATIONS ./file.c:#ifdef ZAPTEL_OPTIMIZATIONS
grep ZAPTEL `find . -name \*.c`
More or less, the timing lesson you were given as a response is not untrue but is also not relevant to your question. Where it may be true that for TDM you have an enormous dependency on time sync you have much less with VoIP. The bigger reason for the Zaptel timing for non-hardware stuff comes from the hatred of threads that Asterisk has.
In a typical call in Asterisk, 2 channels exist within 1 thread. This thread must poll both channels and service them based on socket events. The first problem is that not every channel type has a socket (most do but IAX2, for example, does not which is another can of worms). The second problem is that most routines in Asterisk make the assumption that if you read from the channel in a loop you can write to the channel on each pass and have perfect timing. Sorry, thanks for playing, but you cannot do that. Many protocols (SIP for example) have VAD (Voice Activity Detection) support.
This means that the far end of your call may not send any voice because the other guy is not talking so why bother. When this occurs the poor Asterisk channel expecting reads to dictate writes simply halts in place DoH!
This problem is fixed by a friendly "Don't use VAD" console message. And they are trying to improve on it by somehow trying to weave some logic in there to make that poll timeout and let it work still using good ol' Zaptel timer but it's like digging a hole too deep and just makes the mess bigger if both channels we in their own independent I/O thread the problem would be gone.
The next place Zaptel is wedged into place is in the channel I/O routines. A pipe is opened inside the channel to allow the queuing of frames meaning you can write them as fast as you want and the channel will deliver them at a steady interval. Thank goodness Asterisk is hard coded to only operate at 8000hz! This also compensates for the channels with no socket you can just queue all the inbound frames instead of write them.
This constant pulse is also courtesy of Zaptel timer.
Next there is the file delivery system which is really the one place you really need a timer for sure since the file is simply a large collection of data so it must be fed at a timed interval this also is somewhere the Zaptel timer is used.
The timer is also used by the external music on hold system. The default system uses an external pipe to an mp3 player that also spits the data out too fast since it has no soundcard for timing so the Zaptel timer to the rescue again!
The one place you cannot avoid the timer is the MeetMe application. This is a conference system that depends on the Zaptel to do the audio buffering/muxing and the timing. There is, however, a purely soft-timed algorithm-based conference application available.
http://www.voip-info.org/wiki-Asterisk+app_confere nce
Nearly all of these uses can be replaced with low resolution timers and normalization techniques (gettimeofday with incremental waypoints) a
Sir,
I have respect for you so therefore I will simply address your concerns and move on. Please be aware that I am not taking my ball and going home. In fact, I currently have 2 or 3 issues open in the Asterisk bug tracker and I now have a policy not to submit any more until older ones are cleared up.
http://bugs.digium.com/view.php?id=5161
http://bugs.digium.com/view.php?id=5162
I am not close-minded and I will use/develop for any software that I find a need for. I still have much more Asterisk code I can submit.
Now, to adress the concerns:
we have rejected some of his more radical patches (mostly implementing the idea that everything, even the module loader itself, should be able to be unloaded). While we agree with modular design, there should be a limit; something has to be core, or all your product is is a module loader.
I believe he is referring to http://bugs.digium.com/view.php?id=3666
This patch did not propose to make the module loader unloadable rather to make it possible to load an alternate implementation of the PBX functionality.
At the time of that posting there was a general agreement that the Asterisk dialplan and the resulting codepath of traversing the PBX needed work but nobody wanted to break the program to fix it. With that patch one could build an alternate PBX callflow engine without disturbing the existing one. This is actually an important idea which i carried to FreeSwitch that the core would only deal with interfaces and pure low-level functionality. And to implement a PBX it would be done in higher level code supplied in the module API. I agree something has to be core and I have thousands of lines of code in my core already.
The other problem with Asterisk modules are that many of the in-tree modules carry cross dependencies that make it impossible for the core to function without them.
This isn't true. I'm not sure where he got this idea, but certainly some modules depend upon others. That should be a given, but the idea that the core depends upon a module isn't true. Perhaps we modularized something that he thought should be core?
I'm sorry but it is true. Allow me to elaborate with specific examples but before I do, remember, in the previous paragraph I was accused of not wanting anything in the core and now my problem is that I want more in the core.
EXHIBIT A
http://bugs.digium.com/view.php?id=2998
Here is a patch, written by me, that fixes a catch-22 in the Asterisk music on hold caused by the core being dependant on the loadable music on hold module.
The symbols ast_moh_start and ast_moh_stop were referred to in the core in several places and these symbols only existed in the dynamic module object therefore if you did not load the music on hold module the entire application would fail to start. At the time I wrote this patch there were still several other such issues that may or may not have been addressed but it still demonstrates the design issues and the inability to define how the core interacts with the modules.
EXHIBIT B
There is a module called res_features.so which contains the actual code that is executed when two channels are bridged ast_bridge_call and the entire parking concept ast_park_call both of the functions are used in other modules causing a module cross dependancy. Many operating systems will not even let you do this because you must employ lazy linking where 1 dynamic object is forced to trust that certian symbols will exist when the time comes.
soon all the developers will be nothing but users who have no other choice but to try and be developers
It's unfortunate to hear such an elitist attitude. We all were only users once. Those of us who were interested enough l
My name is Anthony Minessale, After considerable contribution to Asterisk I have learned a great deal about telephony here is a list of my personal contributions to Asterisk: http://www.cluecon.com/anthm.html
The biggest lesson I have learned is that the fundamentals of Asterisk are built on assumptions and hard coded limitations. The flow chart for its code will make you dizzy:
http://www.freeswitch.org/astdoc/structast__channe l__coll__graph.jpg
http://www.freeswitch.org/astdoc/pbx_8c__incl.jpg
People who use asterisk from the outside wouldn't know there is absolutely no structure or discipline in the code and may not care. But once they invest a ton of time trying to make their dream Telco or whatever their dreams may be, the truth is all too obvious. Spoken from experience, only a seasoned technical wizard with years of computer skills to boast will ever be able to successfully implement Asterisk beyond a modest implementation. To truly understand how Asterisk works holds only a slightly smaller prerequisite. To those who find this unimportant, I understand your point, but be aware that Asterisk, being an open source project, needs to have a somewhat easy learning curve to attract new developers especially considering the developer turnover they suffer due to the maddening politics their community has to offer. The development is focused on owning all the code even if it means re-inventing things that already exist just to maintain the right to sell the code. This practice is fine with me though I am less than pleased by the end result when the home-rolled version is a poor contender with several existing solutions. The modular intentions of Asterisk are great though there is no structure there either. Any module can dig its way into nearly all of the code of the core and often, inexperienced module programmers will re-implement existing functionality to the extent that even inside the same C source file, you may find multiple versions of the same functions with different names. The other problem with Asterisk modules are that many of the in-tree modules carry cross dependencies that make it impossible for the core to function without them. Some modules even depend on each other. This practice limits the portability since many operating systems will not tolerate one dynamic object from using symbols from another without hard linking them together. This is not the worst offense as far as portability; there are dozens more with many being accredited to Linux-specific assumptions. Apart from the technology problems the biggest remaining problem to consider is the community. The first experience for most Asterisk newcomers is an IRC channel where people fight for supremacy like information hungry pirates hording what they know and then sticking it to people for being so "stupid". (In other words, in the same boat they were in a few months back.) For those of us who are experienced developers, we are used to the l33t thing. The deal breaker is the issue management process. Submissions will generally be ignored for months then a one sentence overview will command the developer to fix minor issues and resubmit. This is almost tolerable if the submitted code was a new feature but more times than not it also happens with meaningful clean-up and repair of broken core functionality. I have heard this same complaint from countless ex-asterisk contributors over the past year and I am sure it is the number one cause of their ex status.
In conclusion, I actively develop Asterisk code but now I only do it as a consultant. I am quite good at it and I know what I am talking about and I feel that the issues with Asterisk will never be addressed because there may be more Asterisk users every day but there are also less developers every day too and soon all the developers will be
Speaking of RSS, I just made a voice RSS Browser yesterday. The source code is available to download and the program will let you turn just about any RSS feed into an IVR in less than a minute. http://www.pbxfreeware.org/
Please bear with me because it took a great deal of discipline to choose kind words for my reply. You must resist the urge to compulsively say the first thing that comes into your mind especially when your words will be seen by many thousands of people. The statement that C is slow and has no compiler is a dead giveaway that you have no idea at all what you are talking about. It may look nice to see your words in print and all but you must realize that it is a moot point to try and compare C to Java because Java is a language designed to run on any platform and in most cases the Java Implementation itself is written in C. Take Linux for instance, The entire operating system it 100% C, every UNIX variant is like a big living breathing C environment including Sun Solaris where Java was born. So you see, you are welcome to appreciate Java but keep in mind that C is the low level language that just about every other programming language is written in. So to summarize, Everything you do in Java is in turn calling C or C++ code which then calls the operating system's system call. Therefore you should avoid saying things like Java is faster or better than C or the next person that replies may not be so civil.
I'm not sure which of my statements you will quote this time in your alogrytmic attempt to gently flame me in your next reply but I hope it's a good one so that means actually read my whole statement this time as you choose.
The issue of insecurity is obvious but it is rediculous to say that something related to pop-up boxes in a browser has anything to do with JavaScript just because the mechinism was implemented with it. To me that proves you do not understand how it works very well. The JavaScript maintainers in most cases ARE the browser devlopers as well or at least work closely with them. Mozilla, for instance, happens to maintain both in thier CVS tree. Regardles of this, the same guy or 2 different guys developing the engine and the browser the security still is guarded at the place where they meet. So i'm not burying my head anywhere because chances are the same guy is going to fix it from my point of view as is from yours only he will have his Mozilla Browser hat on not his JavaScript one. I'll restate that the componets of JavaScript that even make a pop-up window possible is only found in browser implementations so it's not JavaScript as a whole that needs work only the 'Browser' object module. There is no kop-out only clarification. Enjoy the last word as I have nothing more to say on this matter. Perhaps instead of trying to subtly insult me and my Asterisk module that happens to prove my point perfectly, you should use that last word to post your proposal on what feature you plan to add to one of the open source JavaScript engines and maybe submit some code. Then you can try to convince the closed source implementations to adopt this new uber secure enhancement.
but, It is out of the scope of the language to be responsible for how it will be implemented in a browser when a browser is not the only application it is able to be implemented in. The Document and Browser objects in JavaScript are not standard they are addon's used when the language is applied to a document rendering model. Therefore the developers who implement the marraige of JavaScript to a browser are indeed responsible to make sure it does not raise any security concerns. When I added JavaScript to Asterisk I had to implement serurity features that only make sense in a PBX and I would not have expected the language to come standard with a way to handle that situation. See http://www.cluecon.com/res_js.html for reference
It may be possible for JavaScript to help evil-doers but it's up to the implementer of the Application using the engine to avoid that, not the language or its core developers. If every invention that could potentially be used for evil was struck down there would be nothing left. JavaScript can do plenty of good and the developers of the open source engines have gone out of their way to make it well documented, embeddable and extensible so you can add it to almost anything that needs a little help with a language parser. In fact, I myself have recently added JavaScript to the Asterisk PBX system to drive IVR and it works quite well without much concern for exploits. RES_JS for Asterisk: http://www.cluecon.com/res_js.html