Aastra XML

the hardest part is example templates.. you could possibly even do it yourself after a little bit of understanding how the system takes a template with variables in it, and writes out the final file with values that replace those variables. I did similar with the cisco 79x1 series templates.

You were the one I was hoping for a reply from. We have been using the scripts for several years so I have a pretty good understanding of how they work. Is there anyone I can hire to redo them for thirdlane mte? I will dig in myself but have a feeling I am going to run into time constraints.

Email me the sample file you currently using, to moshe (at) voore dot com

I will try to mass around with it

The template is easy. It is the PHP scripts for visual voicemail, DND, parking lot, etc. I was hoping somebody already customized. I have just started digging in. http://www.aastratelecom.com/cps/rde/xchg/SID-0A781896-C77C1962/03/hs.x…

I am not an XML programmer and I am interested in this also. I am currently evaluating Thirdlane MTE but the barrier for me at this point is the lack of the Aastra XML scripts.

I fail to see why this is a barrier. If as you say you are not a programmer (not that XML is programming) why does your inexperience tell you that you MUST have XML when the many other thirdlane users have been using it for years with Aastra phones relying on the non-xml based configuration format. What do you believe XML will grant you?

I only recently started using the self-config functionality provided by the Aastra XML scripts and it has cut down on my work load because it lets my customers setup their own BLFs and speed dials meaning I don't have to configure these buttons for them. It also lets each person customize their own phone just the way they want it. Prior to my use of Aastra's self-config I was editing CFG files by hand and in the past it has taken up a fair amount of my time.

Aside from my recent usage of self-config I would not want to live without Aastra's visual parking lot, visual voicemail or visual day/night applications. Although not as heavily used a have customers who love Aastra's follow-me, DND, call forwarding, presence and meet-me functionality. Aastra has been developing these scripts for a few years and it looks like they have really devoted some time and effort to making these XML scripts work really good. If you were to look at these you would see that someone has spent a ton of time programming to make these work as well as they do.

When I say my barrier for ThirdLane is the lack of Aastra's XML scripts, I don't mean the self-configuration piece (although the more I use it the more I like it). I'm just not sure I could live without all of these other scripts: parking, voice-mail, day/night, dnd, call-fwd, presence, meet-me, follow-me, queue management, directory etc. All of these XML scripts developed by Aastra make their phones work so easy for customers that losing them would make me feel like I am taking a step backward in technology.

On another note, I built my first ThirdLane server a little over a week ago and I just got my first trunk working today so I am still in the very early stages of finding out what it is and/or is not capable of.

Well said. Once you use the Aastra XML features, all other phones seem lacking in comparison.

many of the things you mentioned are part of the user portal of thirdlane PBX. Its generally a bad idea to have a phone responsible for those tasks since should the phone be unreachable (maybe your internet went out) then those functions would cease to exist. I cannot speak to exact mechanics of those features since I have not looked into them. I can say that if its something you want to incorporate into your thirdlane PBX environment you should hire someone like myself to look into integrating this 3rd party software into your system.

for the record, what you describe is nothing to do with provisioning and everything to do with 3rd party software integration. Provisioning is simply telling the phone how to register to the PBX when it downloads a file, and possibly some pre-defined feature codes that execute asterisk-based functions.

what your describing sounds more like a separate piece of software which has nothing to do with provisioning and more to do with extra features and functions. Essentially its a similar task to integrating isymphony into thirdlane or perhaps even more complex than that.

before you make that decision, really get into and play with the user portal and familiarize yourself with its feature sets. The upside of the user portal is that most of those features exist without the dependency of a physical phone. If your XML scripts are all run from the display of the phone it does not lend itself to being useful if someone is at home with a cold/flu and want to remotely setup find-me/follow-me to their cell phone.

These are all PHP apps running on the asterisk server. They are much more useful than you make them out to be. They make things like conference calling crazy easy. The phones without them just seem broken in comparison. I like a lot about the polycoms, but one look at what Aastra had already put together for the Asterisk community and I was sold. Unfortunately, we are still running separate openVZ containers for each client.

so your saying that it lends itself to STE but not so much MTE since one website cannot possibly understand the complexities of varying contexts for origination?

I am saying that Aastra provides the scripts for single tennant/freepbx. I don't see why they could not be rewritten for MTE. Just going to take time/someone with more experience with MTE. I have the php experience, I just lack the Thirdlane experience.

well if you want to hire me to collaborate on integrating them send me an email. make sure you include your forum username so I know what its in regard. I get lots of email messages inquiring about support and often have no idea whom they are in the forum and what their needs are related to. Integrating a webpage into MTE might be a lot more complicated than you think. Consider that every tenant has a completely different origination context and often these PHP scripts hard-code something like from-internal or from-inside whereas we have values like from-inside-tenant and from-inside-redir-tenant.