[Asterisk-Users] Rewriting asterisk to a full-scale system? (WAS: IBM to Run VoIP On Linux)

Roy Sigurd Karlsbakk roy at karlsbakk.net
Sat Nov 8 13:56:57 MST 2003


I beleive there's an (at least below) unmentioned argument why Asterisk  
may fail getting really big:
Since Digium/Mark refuses to include any code that isn't copyrighted  
Digium/Mark, I'm afraid quite a few developers may be effectively  
excluded. By requiring a 'giveaway' to Digium/Mark, we stand the chance  
that the project one day will change its license to a (more) closed  
license (as just happened to MySQL, for instance). We already have  
channel drivers not included in the asterisk CVS because of this  
(chan_oh323 and chan_capi).

I am not saying this license change will happen, but there's always a  
chance, and for some the requirement of giviing away the copyright to  
their own code may be a hinder to write it in the first place.

roy


On Saturday, Nov 8, 2003, at 10:16 Europe/Oslo, WipeOut wrote:

> Can I add to this and say that another thing that could be hindering  
> the takup is "Single System" VoIP scalability and a certain amout of  
> "Enterprise" flexibility..
>
> Let me explain those two..
>
> Before you start reading these and thinking "This guy is mad!!" let me  
> just say that I love Asterisk and use it every day, but if M$ and IBM  
> are getting into the game there is cause for concern.. The features I  
> am going to talk about are very much "Future Dreams" becasue to  
> impliment them would probably mean re-creating the entire code base  
> from the groud up so I don't expest to see the features ant time  
> soon.. I do think that these sorts of featured will be in the IBM and  
> M$ IP PBX's and that is why I think Asterisk needs them..
>
> So lets get started..
>
> I know that many Asterisk servers can be connected together to scale  
> the size of the system but this is still a problem because it is a  
> headache to manage.. What is needed to get the big enterprise players  
> on board is the ability to manage the PBX as a single entity no matter  
> how many "servers" there are.. "servers" should simply be add on  
> modules to the overall PBX to improve its VoIP call volume handling  
> power.. I think the only way to achive this would be to make Asterisk  
> a "clustered" software that sits a level above the "servers".. The  
> VoIP phones will see one "Asterisk Server" that listens on a single IP  
> address per subnet on the network but behind that single system image  
> could be one, two or fifty servers providing the processing power for  
> all the calls, and as power is needed you simply have to add servers..  
> If you need more PRI lines just add a Digium card to a server and  
> enable that server as a "gateway" node in the cluster..
>
> With in this model the voicepath between the "servers" in the cluster  
> needs to be dynamic so the shortest path is always used (IAX can  
> probably handle this quite well already), and CDR must be accurate  
> maybe one or two of the nodes needs to allocated the task of being the  
> CDR server and all other servers will feed back to the central server  
> with the call logging information..
>
> In "Enterprise" flexibility I am taking about user and phone  
> management and services..
>
> On the phone management side (and I know many don't seem to like the  
> idea) but a platform independent full featured management interface is  
> needed.. If its done in Java or web based running on the Asterrisk  
> sever itself, similar to how webmin has its own web server, does not  
> matter but we live in a world now where admins like GUI management  
> tools..
>
> Leading on from that is an "Operator Interface" for receptionists and  
> phone operators to be able to manage calls.. See which lines are busy,  
> connect calls and the various other things that these interfaces do..
>
> Next a monitoring interface (somthing similar MRTG would probably do  
> it..) showing server loads and statistics so system management and  
> upgrading is easy to see and plan for..
>
> Then the need to support hot desking.. By this I mean that the phone  
> and the user need to be seperate entities on the system.. then the  
> user can sit down at any phone  on any desk run through a login  
> procedure (either on the phone or in some easily accesible interface)  
> and all their calls will then be routed to that phone.. I know there  
> are hacks and work arounds to getting this kind of functionality using  
> queues and the Asterisk DB and various other options but it needs to  
> be a standard working system..
>
> Finally an automatic provisioning system.. New user joins the company,  
> click a button on the management interface and give them their  
> extension number and extension password.. no editing files and  
> restarting servers or anything like that its all done behind the  
> scene..
>
> So did I just thumb suck these concepst out of this air?? not totally..
>
> Last year I did a contract at a large comnpany in London and was  
> working on a user provisioning system.. This company has thousands of  
> users in a single building (and a single PBX) in London, and thousands  
> more accross the country.. It was a provisioning system so I needed to  
> talk to the telecoms guys to see if we could automatically provision  
> the phone extensions from the central application.. So a lot of my  
> ideas here come from what I saw they had and things they said they  
> would like to have..
>
> Anyway I will stop rambling on now..
>
> I still think Asterisk is great for SOHO and medium businesses, and  
> when the Digium multiport analog or a BRI card (I know ISDN cards can  
> be used but it would be nice to have one that provided Zaptel timing  
> and one that would probably be a lot cheaper than the current active  
> ISDN options.) comes out it will be great for the small companies as  
> well..
>
> Later..
>
> John Todd wrote:
>
>>
>> Yes, it is a well-kept secret, which is a shame since it obviously  
>> fits so many different requirements.  Here are some late-night  
>> musings as to why new users coming to Asterisk is only a stream when  
>> it should be a river:
>>
>> 1) No >1.0 release.  In fact, no release structure at all really.  
>> (Hold your flames: I know this is to be remedied soon, along with  
>> backtrack patches for security/stability.)
>>
>> 2) No books (yet.)  This also is going to be remedied soon.
>>
>> 3) Advocates fall (generally) into two camps:
>>      a) IT staff who have much more on their minds than being VoIP  
>> advocates, and who normally are told what to do.  Even if they have  
>> experience with * in testbed situations, the larger vendors come in  
>> and throw whitepapers/jargon/FUD at executive staff, who make  
>> telephony decisions, thus overruling clueful staff.
>>
>>      b) CLEC or other telephony-oriented people who will try very  
>> hard to prevent anyone from knowing what they use, or how they use  
>> it, since that is a competitive disadvantage if others should start  
>> to use the same software-driven architectures.  There are some  
>> obvious exceptions to this, but you'll very rarely see (ever?) any  
>> posts by the two or three major IPCSP's that use Asterisk as part of  
>> their core systems.
>>
>>   There are of course others who do not fall into one of these two  
>> camps, and those are the people being the "zealots" getting  
>> conversions to Asterisk.  Personally, as an example, I have over two  
>> dozen institutions, companies, and very clueful individuals that I've  
>> introduced to Asterisk simply based on chatting with them. (excluding  
>> clients, who already have intentions on installing Asterisk.)  The  
>> time it takes to explain why Asterisk is so useful is quite  
>> labor-intensive, actually, and the educational process takes some  
>> time even with the most clueful engineering types, simply because  
>> there are so MANY things to take into consideration with Asterisk and  
>> any telephony questions in general.
>>
>> 4) Hardware vendors are still blowing enough "QOS" issues around that  
>> it obscures open-source VoIP solutions.  "VoIP won't work" is still a  
>> claim I hear EVERY DAY, until I disagree and tell that person that  
>> I'm disagreeing with them over a VoIP call that crosses a continent  
>> twice, across the public Internet (and three carriers.)  This is  
>> obviously not Asterisk-specific, but it's certainly an issue that  
>> scares people away from OSS solutions that don't include "magic  
>> hardware."
>>
>> 5) I would say that it's becoming less of a secret, so don't give up  
>> hope.  The almost-unmanageable flood of newbie posts to the Asterisk  
>> lists in the last two months or so is evidence that success is  
>> sometimes more of a headache than one would want.
>>
>>
>> In short, nothing in the above 4 "worry" items scares me, and  
>> Asterisk is and will become the telephony platform of choice for a  
>> large percentage of conversions to VoIP in the coming years.  Fret  
>> not: you'll be the apache of VoIP soon enough.
>>
>> JT
>>
>>
>>
>>> Asterisk has got to be about the best kept secret in telephony.   
>>> I've seen
>>> numerous articles on slashdot about VoIP, even in relation to Linux  
>>> and
>>> only *once* has the post even mentioned Asterisk.  Am I missing  
>>> something,
>>> or is Asterisk clearly a good potential player in any kind of  
>>> linux-based
>>> soft-switch idea?
>>>
>>> Mark
>>>
>>> On Sat, 8 Nov 2003, Dave Cotton wrote:
>>>
>>>>  For those who don't wake up at 5.00 am and start reading /.
>>>>
>>>>
>>>> http://searchnetworking.techtarget.com/originalContent/ 
>>>> 0,289142,sid7_gci935769,00.html
>>>>
>>>>
>>>>  --
>>>
>>>  > Dave Cotton <dcotton at linuxautrement.com>
>>
>> _______________________________________________
>> Asterisk-Users mailing list
>> Asterisk-Users at lists.digium.com
>> http://lists.digium.com/mailman/listinfo/asterisk-users
>>
>
>
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users




More information about the asterisk-users mailing list