RealTime

This would be great!!

Cheers,

Chris A

I would love to see it as well

Realtime is no more a holy grail than T.38 was. Those that dont understand what it _really_ is seem to think its the magic bullet that cures cancer, makes the rain clouds go away, and puts an end to world hunger. Using 'REALTIME' is as obscure a reference as saying "why don't we use code 'optimizations' when building PBX Manager?" It is not a method nor a feature. There are 10 different realtime modules and 8 or 9 'databases' (more if you count every possibility in unixODBC). There is no way to make it work with every possible database and every possible module. What do we tell people that say they demand it use LDAP as the database backend instead of MySQL? Or those that argue for PostgreSQL or PervasiveSQL or UnixODBC and its children? Some modules are downright troublesome from a support standpoint. For example, using realtime for dialplan would all but eliminate any and all troubleshooting when something goes wrong. I really dont think the customer base would be OK with buying a product that we refuse to support because we have no means to trouble shoot call problems when they occur.

If and when realtime gets rolled into PBX Manager, it would have to be a fresh install and you would have to move your tenants over to it one at a time. All your choices will be removed from you. No longer would you get to pick your database engine. No longer would you get to choose if you install a database at all. The list of pre-requisites would grow ten fold and the change would be so significant there would be absolute, positively, no upgrade. The entire user interface would have to be re-written from the ground up.

One other mention regarding realtime for sip.conf. Are you aware that presence is currently borked with realtime? Also are you aware that MWI has several logged bugs with realtime? Will your customers accept their sidecars not working and no message waiting lamps if you move sip.conf into the realtime database?

Which modules of realtime are you referring?

If you are talking about your document regarding openser+ asterisk realtime are you aware that ALL THIRDLANE FEATURES would be non functional? You would be throwing your license down the drain. Openser + asterisk realtime = openser dialplan, asterisk as JUST voicemail storage and conference rooms.

that means no tenant manager, no GUI, no recorded files, no hunt lists, no nothing. Have you ever coded dialplan in openser? If you haven't, give that a try. Its not for the weak of heart :)

We have been using Realtime (full and partial) implementations of Asterisk for the last year or so - both commercial and homegrown, MySQL and Postgres. While it is very cool (I love being able to make changes in the database), in our experience with most of our installations for premise and hosted pbx functionality, it is far less headache using non-realtime. We have been pulling back our realtime boxes and moving back to non-realtime implementations of Asterisk.

Brian

Eric,

all that may and may not be true and in some cases I agree with you BUT it does need to be done sooner then later. When several people are in MT making changes and adding configurations to the system at the same time and TL requiring asterisk to reload over an over again in seconds / minutes causing asterisk to crash and dropping every call when it does.

George

It is a 100% code rewrite, not just to incorporate some aspects of mysql storage, but to replace the UI with a LAMP design. In terms of scalability, concurrent writes, and anything else, this is the obvious conclusion. While rewriting there's other stupid things that have to go, for scalability sake. 90% of the bugs ive had to fix in the last 6mos have involved chan_local. It has no business in a business class MTE switch and its causing a lot of scaling problems. Customers asking for some half-baked features that drag chan_local back to the feeding trough could literally be costing MTE owners thousands of dollars because they find themselves having to buy a 2nd and 3rd MTE every few hundred tenants just because these 'features' kill scalability. Dont get me wrong, Im for designing a highly scalable version that can handle thousands of concurrent calls.. but 'sooner' is probably a really long time off.

Theres a lot of changes in 1.6 that drastically reduce load and increase scaling. Right now, 0% of them are utilized.

examples:

stop using chan_agent->chan_local relationship and add a sip channel directly to the queue with AddQueueMember

re-do the hunt list to stop nesting a dial within a dial (chan_local nightmares) and just call the SIP channels directly

replace Macro's with Gosub which requires rewriting all the scripts ('s' cant be used as an extension or it rewrites CDR)

store voicemail, SIP friends (if presence can get resolved), few other things into mysql via almost-realtime.

Investigate if database value/keys can be stored in realtime instead of astdb so that user portal changes don't have to go through the AMI.

Since this re-write will look nothing like previous versions, there is no way to upgrade to this. Therefore some manner of export->import data grid will have to get built.

I wish I could tell you this is something that could be done in just a few months, but I would be completely lying if I did.