With the death of Aastra XML scripts, what are you using now?

With the death of the Aastra XML scripts, I no longer feel that these phones have enough of an edge to keep me away from the competition.

A few phones I have been looking at to replace my beloved 6757i’s/6737i’s for future installs:
Grandstream GXP2200 (Grandstream hasn’t finished developing all the features for it, but it shows promise, I’ve enjoyed playing with it the last few weeks)
Grandstream GXP2124 (10/100…)
Polycom Soundpoint 550/650 (10/100 ethernet Polycom? Come on. give us an affordable gigabit model)
Yealink SIP-T38G
Snom 870

I have yet to find a phone with visual voicemail or visual parking (for good reason, people don’t like being sued).

I’d like to hear what others are using/will be using to replace their Aastra line. I know a few of the active members here have used Aastra’s exclusively for a long time, I’d like to hear your thoughts on the future of Aastra and what you will be using if you are not sticking with Aastra.

we still use Aastra and sell thousands of them monthly to our customers. The XML scripts in the Distro work real well and I know people use them daily.

Yes, I know they work fine now, but what is the future? I thought all development was ceased. Aastra doesn’t develop them anymore due to legal issues and I read a few times that you guys will no longer touch them due to legalities. It is only a matter of time before they start breaking as Asterisk continues to be developed and Aastra’s firmwares continue to change, and there will be no-one willing to fix them. That doesn’t settle right with me. I don’t want to be using phones with a strong risk of losing the features I love just by keeping FreePBX and Asterisk updated, and buying new phones with the newest firmwares already on them. When I went from 2.6 to the 3.2 series of firmware, it was a nightmare until the firmware was updated, and Schmooze updated the scripts.

If I misunderstood the situation, then someone please comment. I love the phones and would rather never give them up.

Some things may have changed on that front. I have not talked to Tony on the “state of Aastra XML” in awhile.

The other issue is support for new model phones.

We will use Aastra as long as the Distro includes their XML scripts. If the time comes that it does not, we’ll likely switch to Grandstream. I have one of the GXP2200’s and it’s looking pretty good so far…

The Aastra XML scripts are great, but with the constant refinement of the endpoint manager, we find that our clients have been mixed in the past, but now prefer the non-XML scripts (because they can use Endpoint Manager to centrally configure the phones without editing .conf files…)

You have a point on configuration, but the XML scripts are so much more. They allow access to meet me conference rooms, they have a visual parking lot, visual voicemail, a company wide phonebook, and other awesome features. Features that I have yet to come across on any other Asterisk friendly phone.

I think the major issue here is with legality, as pointed out above. This is most prominent for the Visual Voicemail feature, which was the subject of a number of lawsuits from the original Patent holder (and which affect far more than just Aastra by the way). The main issue, as I understand it, is that the patent basically covered any form of visually notifying you about messages and phone numbers in a mailbox, and nobody seemed to be even trying to challenge it in court, so as a result nobody else has bothered to try and implement these type of features for fear of the same type of lawsuits.

Having said all that, if you want to take on the legal responsibility yourself the Aastra XML scripts are very easy to follow guide-lines for how to do it. After all most of them that implement the features you want (i.e. visual voicemail, visual call park, etc) are simply PHP scripts that hook into Asterisk and generate XML for the phone to display. Similar scripts could easily be written for any other sets that support XML capabilities (Yealink, etc), you’d just have to alter the output of the XML to format what the phone specs say. Again the major issue is you are then taking on the legal responsibility for that should lawsuits arise in the future. I assume thats why none of the FPBX devels want to go near it…


That’s correct information about the intellectual property.

Adding new phones is also simple. My biggest concern is what happens when Aastra changes the XML in a software update that breaks something?

As a businessman I will have to decide if I want to freeze on version of Aastra firmware or take on the update ourselves.

I think that we may be able to skate for another year and a new option will present itself.

Just out of curiosity does Aastra have a history of changing the XML interface and breaking the scripts? Generally once a manufacturer introduces an API they don’t tend to alter it to the point of damaging/breaking the existing interface (tends to just be add extra features or enhancements). Or is the Aastra XML interface not a public feature (i.e. it’s there and they write stuff to use it but there’s no declaration that third parties should implement it).

Just curious…

Yes, Aastra had a hell of a time when they released version 3 for the 6753i/55i/57i, etc… They did change the way they did things and it did break certain aspects of the scripts for months until the scripts (and firmware) could be updated to accommodate. If you dig into them, they have checks with three or four different parameters to serve up different code to different firmware versions.

SkykingOH has the same issue with future support as I do. Do I take on the maintenance myself (I’m tiny, I don’t want legal issues)? Never update (At some point Aastra will update the firmware on shipped phones and there is no way to downgrade)? Find a different solution (Probably the best thing, but I haven’t found anything that comes close)? I have no idea… Hopefully the future will bring good things.

As has been mentioned, it is not just Aastra that is affected by this issue. Other vendors, have similar systems and are affected similarly.
In the case of Aastra, the question though is what are the modalities of licensing the said Patent(s).
Is the patent holder just a troll? In which case its a non-starter; or would Aastra have a shot at adding a small incremental price to their phone that would then include the patent royalty fee.
I’ve noticed that the phones look for a <mac>.lic file during boot, so conceivably a license could go in there too.

An example of a working licensing model is the G.729 codec or Digium FAX license. Aastra (and other vendor’s) phones have the G.729 codecs built-in, which you can use without having to pay a license for them, because it is part of the selling price of the phone. You do of course have to have a corresponding G.729 license the PBX, and with Digium making the G.729 licences available in an easy to acquire fashion, its win-win for the implementer and the customer.

The issue with respect future compatibility is that Aastra aren’t the only ones who have developed XML scripts for Aastra phones. There is nothing that prevents other entities from developing XML scripts, and those entities would be unhappy if Aastra went and made big changes to how the XML works on the phones. Any development shop doing such work would of course expect a certain natural progression from version to version, and would need to update their product along the way.
Of course with open source, there might not be a maintainer, but the XML scripts are “out there”, and you can’t put the genie back in the bottle.

I for one, find the XML scripts to be extremely useful in scenarios where all the endpoints are Aastra. In which case, you can just set it up to log into the phone with the ext/pass and it sets itself up. This makes day-to-day maintenance simple for a junior level tech. I’m sure there’s probably a patent being infringed there too! I think software patents stifle innovation in general, but that’s another discussion.

In the end though, Aastra never offered the XML scripts in anything other than an “unsupported” fashion, so it was well within their purview to withdraw the product at any time should they choose to do so, but even they seem to be having some sort of identity crisis over it since their web site still lists it here, but the download link just redirects to the homepage. --Caveat Utilitor.


I don’t think I’m alone in saying I would happily pay an extra amount ($10-$30) per phone for continued development of the Aastra XML scripts and royalties to the patent trolls.

Lets bring this thread back from the dead.

Personally I find Aastra’s wild changes to their firmware more of a road block than loosing the XML scripts. Who wants to develop on top of firmware that changes month to month?

So far end point manager meets my needs for 90% of what the XML scripts did. Visual voicemail is nice but can be frustrating for phones that are in noisy environments. Users need the set off hook to hear recordings and checking 15 messages on the visual XML app like this is a pain.

That said I think Schmooze has potential with their new commercial end point manager. I’d buy into it if they can provide reliable support, patch often as much as firmware is updated, and adds full support for all the features the non XML firmware can support.

Can they pull it off? I’ll keep tinkering with the open source End Point Manager until I see some results.


I have been playing with 8 different models of phones and have pretty much decided Aastra is dead to me. There are plenty of other solid phones (although less features) that are nicer than the Aastra’s in a lot of ways. I got a bad batch of 57i Phones (faded screens after 10 months on ALL OF THEM) and they would 100% not work with me. They HAD to get the old phones back, and what do they send me? Refurbished. For a batch defect…

Anyways, I just ordered a Digium D70. With it’s age and support ramping up, I feel as if this may be the ultimate answer to getting all the Aastra features I loved AND MORE! I can’t wait.

The commercial endpoint manager is $25, buy into it anyways. I have been happy with the open source version so far, but I may purchase the commercial version just to see what they do better. Can anyone comment on the major differences? Besides a facelift on the GUI, I haven’t read about any major differences.

I can comment that the commercial endpoint manager is not based on, nor does it share any code with the open source. It’s a different approach (base files vs. templates, drag and drop buttons etc.)

back to the original question, what phones + manager are people using that is not aastra xml?

I have done over 100 deployments with 6757i phones and aastra xml, but now that the whole 67 series is effectively ‘legacy’ and development has stopped on xml scripts, where do we go?

I understand visual voicemail is legally troublesome, but there are other killer features that I can’t find an alternative to. Visual parking lots, follow me, and transfer by directory are great but lacking in everything I see.

I’ve tested grandstreams, and my opinion is that they are absolute junk. Snom is meh. My preference would be to use polycom vvx as they are very nice handsets, great sound, and they look professional. How do I get beyond basic line appearances and complicated xml config files?

Check out the REST apps for Aastra, Yealink and Digium.

As far as “complex XML configs” and not keeping up with FreePBX (how could you miss the announcement) I am continually baffled by the integrators level of knowledge. I am trying to be nice for Lent (though I am not Catholic) so I will just leave it at that.

REST apps work very well.

no REST apps for Polycom, which just happens to be the most recognizable IP phone brand other than Cisco. No REST apps for the newest Aastra phones (68xx) either.

The cheap Yealinks look like crap, like a low end clone of a Cisco 79xx series, and the nicer ones starting at a T46G (cheapest professional looking unit) is $100 more than a similar Polycom (VVX410) which I feel has a better handset and better build. Digium phones look great for 2001.

Basically, I would only consider putting a VVX400+ or an Aastra 6867i+ on a desk at a new customer. I’m not really worried about existing customers with aastra 67xx phones, they have functional systems with xml scripts already and there is no need to change, but I’m not willing to stay stuck in 2006 with my products.

Also, polycom’s xml configuration files do get complex quickly. Obscure, overly long keys and difficult to decipher documentation if you want anything more than a few line buttons and BLF. This is a common opinion, even among seasoned people.

Our RestApps fully support the new 686X series phones as does our EPM. http://wiki.freepbx.org/display/FCM/RESTful+Phone+Apps-Supported+Devices