Digium appears to be deprecating the meetme application currently included in Dahdi in favor of app_confbridge, which doesn't require the dahdi_dummy driver or other hardware dependencies.
Any thought on converting Thirdlane to using app_confbridge?
Thx,
Josh
Whoa. Clearly struck a nerve
Whoa. Clearly struck a nerve there.
I am in agreement that the Asterisk 1.6 branch has been a long road for many, but to say that it will "never be up to production standards" is a bit of a stretch. At minimum, it contradicts a great deal of experience that I, and many others, have had running Asterisk 1.6 successfully in production environments.
As I'm sure you're aware, app_meetme has a dependency on DAHDI (and not simply for timing), as the channel mixing exists within DAHDI. There are a number of us, on all version of Asterisk, that would prefer not to use this architecture for various reasons. Contrary to your statement, app_confbridge is included in 1.6.2 and has been through over a year of development and testing. The merge happened slowly. Meetme is being replaced.
If you're going to blanket state that 1.6 isn't ready for production anywhere, then I think Thirdlane should be philosophically consistent and simply remove support for Asterisk 1.6 until such time as it's deemed production-worthy. If one is going to claim support for 1.6, then there should be a reasonable effort to encapsulate all feature functionality.
Just my .02.
Josh
its never going to be up to
its never going to be up to production standards because digium and the asterisk development team has already decided to do an about-face on their 1.6 plans. They have now labeled 1.8 as the next long term release and one targeting those who use it at a service providing level. 1.6 is going to play out as a testing ground and all the real work toward stability will probably happen in the 1.8 branch. 1.4 wasn't itself stable until around 1.4.12 some 9mos after 'release'. If you're claiming to run 1.6 in production then you aren't serious about your production or have no production to speak of. There is no one that can live without DTMF if they are offering services to end-users. If you haven't noticed any DTMF problems or one-way audio problems coming out of the last 4months of releases then you definitely are not running anything production-worthy. I'm not talking about a pbx running 6 phones in some shop somewhere. I am talking about 200 extension minimums with an array of users with an array of needs. I am talking IAD's inter linking legacy pbx's. I am talking hosted environments and trunking to other pbx's. There's a reason why digium themselves has not rolled their platform to 1.6. 6 months after 1.8 branch releases you watch and see switchvox step right into the 1.8 branch and skip 1.6 all together.
We can argue about this
We can argue about this theoretically all day. The fact of the matter is that I have real 24 x 7 customers and call centers live on 1.6. Not everyone, and certainly not without appropriate understanding of risk and limitations. But there are compelling reasons - scalability, improvements in AMI, etc.. to move to 1.6 in some environments. Is 1.8 ultimately where we are headed for a LTR? Yes, and we are all aware of that at this point. In some cases, however, the challenges with 1.6 were worth it from the customer point of view. A simple blanket statement that everyone is going to have one way audio all the time and DTMF issues that can't be solved is clearly unhelpful - and inaccurate - as I can show you plenty of large production installations on 1.6 with fully functional DTMF and audio.
In any event, this is immaterial. If the belief is that 1.6 isn't production ready for anybody, then Thirdlane should simply pull support for it in their product or add appropriate disclaimers suggesting we not use it. If Thirdlane is going to support 1.6, which I believe is the stated direction, then it only follows that we should adhere to what is supported in the Digium roadmap, which means that meetme is being replaced with app_confbridge. I don't see how that can be argued any other way.
I do understand your point of view and no one should be changing systems for the sake of changing them. Many of my installs will continue to be 1.4. But if Thirdlane is going to claim support for 1.6, there should be a roadmap item to replace meetme with app_confbridge.
you are speaking like newbie.
you are speaking like newbie. Thirdlane supports 1.6.0, NOT 1.6.2, if you had been around when Russel Bryant discussed the naming convention of the 1.6 tree you wouldn't assume all 1.6 is the same. 1.6.0 is a complete branch; 1.6.1 is a complete branch; 1.6.2 is again another complete branch. Choosing to support 1.6.0 and not 1.6.2 is no different than choosing to support 1.4 and not 1.6.0. Going from 1.6.0 to 1.6.1 is a significant change in structure. Going from 1.6.1 to 1.6.2 is another significant change in structure, commands have been depreciated command structure changes. This takes a tremendous toll on thirdlane and ever new platform that once again re-writes how dialplan gets structured suddenly adds hundreds of lines to the UI just to generate dialplan. Once 1.6.2 is 6 months old and the revision level reaches around 1.6.2.12 you'll start to see more support in thirdlane. But to argue that just because TL isn't adopting bleeding edge changes in 1.6.2 that somehow means they dont 'support 1.6' just goes to show that you really need to do your research and RTFM.
Perhaps you should read the
Perhaps you should read the FAQ on this website before you post. You can find it by going to Support -> FAQ, in case you're not familiar with it:
Q:
Which versions of Asterisk are supported?
A:
Thirdlane PBX Manager supports Asterisk 1.4.X and Asterisk 1.6.X. Thirdlane PBX offers a choice of installing Asterisk 1.4.X or 1.6.X.
In no uncertain terms, Thirdlane is claiming to support Asterisk 1.6.2. Don't see anywhere that it says 1.6.0.x only, as you directly state. If that's the case, I'd definitely like to know that. Also, if you'd ever installed Thirdlane on 1.6.2, there are no warnings on the Thirdlane installation script when one installs against 1.6.1 or 1.6.2, which itself doesn't differentiate between branches of Asterisk.
Thank you for the versioning lesson. While I didn't agree with Russell on this one, I do happen to understand the approach.
At any rate, this discussion is generating more heat than light. All I was really looking for was a statement on when support for app_confbridge was likely. You are correct in stating that there are challenges in dialplan generation - challenges which are exacerbated by the near-constant deprecation of syntax by the Digium team. I'm not expecting immediate or perfect version synchronization, but it is something that will need to be addressed.
support for it will likely
support for it will likely occur when 1.8 support is built into the UI and we can stop supporting 1.4 on all new releases. the flash app that visually manages the conferences is designed to listen for AMI events from the meetme application. This would have to be re-written to instead listen for the other application's AMI events. This would need to happen at a time where we officially kill meetme support for good.
additionally the code that compares how to deal with 1.4 vs 1.6 versions does not differentiate between the branches so by rolling out a late feature in 1.6.2 it will break anyone running any other branch of 1.6, expecting those sytnax and functions to exist. The only reason we are able to introduce support for the multi-tenant parking introduced in 1.6.1 is due to a complete non-existence of anything prior to that version. It's not choosing between the two. It is merely creating the configs for 1.6.1 and those using 1.6.0 won't be able to have any parking. Officially the MTE version support will be relabeled to 1.4 and 1.6.1 due to there being absolutely no manner in which 1.6.0 branches can park calls.
in the interim, flashed based UI aside, you can easily add your own scripts for ConfBridge as the wiki indicates that the dialplan syntax will remain identical. It seems as simple as cloning tl-dialconference-prompted and changing MeetMe to ConfBridge. There is no sample confbridge.conf file and the digium bug tracker indicates that it parses meetme.conf
Thanks Erik. I appreciate
Thanks Erik. I appreciate the response. I think your approach is very fair.
The documentation on implementation of confBridge is pretty lacking at this point, but I am going to look into the approach you propose.
I'll report back and contribute whatever code we change. I can live without the flash conference management for the moment, but may look at what it would take to reproduce some of this functionality another way.
Josh
no
app_meetme is not part of dahdi, its part of asterisk. Its not being depreciated anytime soon and app_confbridge is not part of asterisk at the moment. this is the wrong place if you're asking for bleeding edge features that can cost people who use them millions in lost revenue and lawsuits. Thirdlane will only switch to new features only after a long proven history of stability on platforms proven to be stable. The whole 1.6 tree of branches arent even up to production standards right now. There are documented serious DTMF problems right now. There are documented 1-way audio problems right now. NEITHER is something the TL customers can say 'screw-it' and just roll out some fly-by-night feature at the expense of their customer base. Theres a chance that 1.6.x.x will never be up to production standards with the latest intent to call 1.8 the next long-term-release build.