in Telephony

a perspective on XML Services for VoIP Telephones

Last Wednesday I attended a talk at the Toronto Asterisk Users’ Group given by Hung Lam, Aastra‘s IP Product Portfolio Director, on the topic of developing XML-based services for Aastra’s IP telephones. It’s clear that Aastra is trying to compete with Cisco in the same space; Cisco’s Unified IP Phone portfolio includes support for their own XML-based information services. In fact, Aastra’s own XML dialect is based largely on the equivalent Cisco dialect.

I won’t go into details about Aastra’s offering in this space; hopefully TAUG will be able to procure Hung’s slides and put them up on its website to give a PowerPoint-style overview of Aastra’s feature set. (The XML Development Kit also includes extensive documentation and sample code for developers wishing to implement their own applications.) I only wanted to make a couple of observations, as follows.

  1. While the use of XML services on one’s IP phone display is nifty, I have yet to see a "killer application" that would justify development of applications in this space. The main problem is that the functionality of any application is likely to be reproducible on a user’s Internet-connected desktop anyway, at a fraction of the development time, and with a far richer user interface. Given that this is Voice-over-IP we’re talking about, and given the proximity of a business user’s desktop computer to his/her IP phone, there’s no real reason to invest a great deal of time into developing interactive applications for one’s phone when one could write the same applications (or get them for free!) on the desktop.
  2. As such, any XML service would have to meet some need that cannot be fulfilled with the user’s desktop PC. Clearly that implies some integration with phone-specific functions; for example, a multimedia XML-based corporate directory that allows one ot place phone calls directly from the output, or speech-to-text translation of incoming calls to the phone display (e.g. for hearing-impaired users), and so on.
  3. The lack of standards-based markup languages will hinder widespread adoption of XML services for VoIP. No developer is going to want to create one version of his/her application for Cisco phones, and then have to port it to Aastra phones, and then Uncle Vaclav’s phones, etc. There is going to have to be a push by some standards body (e.g. W3C) to make this a reality. Alternatively, some VoIP phone manufacturer could take up the torch and initiate such a standardization process. This would be a great opportunity for an upstart like Aastra to get a leg up on its competitor (Cisco) by being the (very public) sponsor of a new standard for VoIP XML services.
  4. Security is still a problem area with phone-based XML services, much more so because phones like Aastra’s 9113i can act as both XML service clients (nothing more than an HTTP client) and servers. This means, in a legitimate scenario, a VoIP PBX can POST data to the phone in a push model. It also means that any other illegitimate device on the same network segment could push data to the phone. Given that the scope of commands one can run through the push interface is quite extensive, this could pose quite a security risk. There needs to be some kind of authorization mechanism that the phone imposes on any candidate server wishing to contact it to prevent rogue servers from pushing, say, a mass "reset" command to the broadcast address and resetting all VoIP phones on that LAN segment!

In conclusion, I think XML-based services on VoIP phones are very neat, but I have yet to see a good business need for them at present. There are also some technical concerns and standardization issues that must be addressed before these APIs will see widespread adoption by both developers and end-users alike.

Write a Comment

Comment

  1. As to item #4, there not only is an authorization mechanism for push access to phones, but it is required before the phone will accept anything. The syntax to setup each phone goes like this:

    xml application post list: 192.168.0.178