IMS is the Holy Grail but Open Source could make it real
Karl Heinz Van Der Made, Director of services, KPN Netherlands presented the IMS service experiences, based on the following number of services deployed:
10 VoIP
8 primary suppliers
7 stove pipes
4 commercial services
2 video
2 wholesale
2 network PBX
1 Mobile
1 cool new services second life
IMS is the Holy Grail: the ROI for migrating to an IMS core network is not there as voice is still the only volume service. There is little value in converged voiced services : who would pay for caller ID on TV? KPN has deployed pre-IMS or partial-IMS products from 3 vendors and had to face interoperability issues.
KPN current developments aim at replicating the creativity from Web providers (Skype). They seem IMS most valuable when involving smaller systems integrators with open source components such as OpenSER, Asterisk, and the Open IMS from Fokus. They want to provide good integration with non-voice services including MSN IM, Presence, LBS.
Extended presence for rich communications
I presented how HP used Jabber XCP to develop a rich group communication services on top of IMS. The XCP server is accessed by the handset client software using XMPP (RFC 3920 and 3921)for :
- Peer to Peer or group instant messaging
- Recording of instant message
- Presence information and authorization
Waiting for IMS handset clients
Kamran Kordi, from T-Mobile innovation stressed the issues of client developments. Today a service provider has to support more than 10 platforms x 2 handsets x 2 software drops/year = 40, at horrendous costs.
The IMS SIP terminal specification were set in 2002. But SIP and 3GPP/XCAP increase complexity, video streaming requires multi-threaded and caching, the result is high handset prices. Mid-range handsets are necessary to ensure take up. He commented positively on JSR 281 IMS client standardization and J2ME compilers. This JSR provides a high-level API to access IMS services.
