Status of Multimedia Communication

For me, multimedia communication is one of the three axes around which IMS can revolution telecommunications.

Multimedia communication is a central capability of the SIP protocol as specified by the IETF. It permits to combine and dynamically add, remove or replace any type of communication components (e.g. messaging, voice, video) and application components (e.g. gaming, shared browsing, whiteboard) whithin the same SIP session.

Multimedia communication should not be mixed up with early IMS rich voice services, which aim at adding specific media components to a voice-centric session. There might be - sensitive telecom people please directly jump to the next sentence - multimedia sessions without a voice component from beginning to end. However, voice is likely to remain the privileged way to communicate for long, and therefore one of the main components in multimedia sessions.

In this post I will try to describe the current status of multimedia communication in both existing IMS implementations and in standardization.

Implementations: Devices Can Do It, Application Layer Cannot

In my first post on multimedia communication I identified 3 related challenges for the operator. The first one is to simply enable multimedia communication in an IMS network.

Multimedia session management is a natural peer to peer feature of SIP, and can therefore be easily supported by devices. In the mobile industry, most of the IMS client frameworks I have seen are able to support multimedia sessions.

The IMS core network is not an issue either, as it can support any type of session.

Problems concentrate in the application layer, as early IMS application and media servers are dedicated to the support of single medium sessions, with the medium being voice, video, voice bursts (push to talk over cellular), or messaging.

This implies that as soon as an application server is chained in the signaling path of an IMS session, it is likely that this session can only support a single medium. "Fortunately", current IMS clients are implemented to also support a single medium in a session.

Standardization Overview

ETSI TISPAN seems to essentially see IMS as a new telephony network over IP. In cooperation with 3GPP, the group has been pushing for the standardization of services that simply replicate existing circuit-switched services.

OMA (Open Mobile Alliance) is the main standardization body for IMS services/enablers. This is therefore the main responsible for the extreme silo-ization of early IMS services.

However, this is also from OMA that the light may come through the Converged IP Messaging (CPM) work item. Despite its name (is it to deceive enemies of multimedia communication?) CPM requirements cover the full scope of multimedia communication, both for 2-party and for multiparty sessions. CPM might be THE most important item under specification these days.

By having a look at the contributions for CPM over the past months I have the feeling that this item has been strongly pushed by operators, and that apart from a few exceptions major telco vendors' involvement has been lagging a little bit.

Requirements have been defined, architecture work has just started.

I hesitate to even mention it but 3GPP has an R7 work item called "Multimedia Telephony". For me the terms "multimedia" and "telephony" cannot be associated, as telephony is an old circuit-switched centric concept, and it does not make sense to consider that multimedia communication can be reduced to a telephony service in which voice is replaced by several media components. Not only multimedia communication deals with combining multiple media components in a single session, but it also will totally change the way to communicate, and this new communication paradigm will not be called "telephony".

This said, the name accurately reflects the content of specifications: it might be about multimedia, but it is definitely about telephony. The current multimedia telephony specifications simply define how such services as call waiting, call hold or call barring can be implemented in IMS.

Why is it so Hard?

As usual this is mainly about culture and organizations.

For instance, voice has always been voice and messaging has always been messaging. In legacy networks, these services have nothing in common. They are owned by different organizations within the vendor and operator companies. These organizations do not speak to each other and multimedia communication could even threaten their very existence as separate entities.

OMA is a standardization that used to specify only silo services before IMS services were pushed in by a few companies. The OMA organization is totally fragmented, and the OMA architecture group has never been an overall architecture group, such as WG SA2 is in 3GPP.

There might also be a business issue: as a supplier, is it more interesting to implement and sell, say, 5 silo services, or is it better to integrate all these services in a more coherent and compact architecture?

When is There a Real Risk to Miss the Multimedia Communication Bandwagon?

The first risk is when standardization or a supplier proposes to "enrich" a silo service with one or two more media components, e.g. messaging added to push to talk. An operator may end up having in its network a voice server also supporting messaging, next to a messaging server also supporting voice. Suppliers may be happy to upgrade their silo servers, but the losers will be the operator and the end-user.

Otherwise, if you consider early IMS services for communication...

Voice-centric telephony is not an issue. The service is so important that it will remain for years, more especially as long as the circuit-switched network exists. It therefore makes sense for an operator to deploy IMS for voice telephony. However, as the motivation is usually cost reduction, the operator may prefer to minimize the costs for the IMS telephony application servers and go for cheap black boxes that implement the most important telephony added value services (unless the operator already uses an open platform like JAIN SLEE for IN). Investments for more open platforms can be targeted at multimedia communication and other IMS advanced services.

Push to talk over cellular is not a successful enough service to be an issue.

The real risk for an operator to waste money is for IMS session-based messaging. This chat and instant messaging service is very important, and an investment in a silo implementation may not be future proof.

In a next post, I will address architecture aspects for supporting multimedia communications.

Christophe

IMS for Fixed Operators

Fixed and mobile operators tend to have very different perceptions of IMS.

The introduction of IMS in the fixed domain is relatively recent, as it dates from the decision of ETSI TISPAN in 2003 or 2004 to include 3GPP IMS as part of its Next Generation Network (NGN) architecture. The fixed version of IMS consists of extensions to 3GPP IMS (new entities, new behaviors in existing IMS entities), which makes that an IMS core network complying with both 3GPP and TISPAN specifications can simultaneously support fixed and mobile access.

For fixed operators, IMS enables both VoIP and other "multimedia" services (this potential for new services is one argument to distinguish IMS from a more classic softswitch architecture). The fact that IMS is a common technology between mobile and fixed access also permits these operators to envisage offering their services to mobile handsets by becoming a Mobile Virtual Network Operator (MVNO), thus hitting back to the Fixed Mobile Substitution problem of the last years.

IMS is part of the "new generation" network that will replace the aging, heterogeneous, and costly circuit-switched network used for 1st line telephony. In this context, IMS can support the quality of service, the scalability, the reliability, the security, and the regulation constraints currently associated to a PSTN service, while simpler VoIP implementations already deployed by fixed operators can remain 2nd line cheap telephony alternatives to Skype, Gizmo, Google Talk and others.

Therefore, contrary to mobile operators, fixed operators thinking about replacing their circuit-switched network have a good reason to deploy IMS, and many will want to start introducing it fast (phasing out the old network and migrating subscribers to the new one is not an easy and instant process). For once in telecommunications, many operators are eager to introduce in their network a technology whose standardization/implementation (i.e. adaptation of 3GPP "multimedia" and mobile IMS to voice-centric and fixed requirements) is still not completed.

The not so positive side of the story is that the focus put on simulating plain old telephony services makes that fixed operators usually dedicate little effort to think of the next steps, and what IMS can offer beyond being a systematic replica of how a circuit-switched network works. This also largely contributes to the perception that IMS is just a technology to re-create the old telco world over IP.

This is a pity, because fixed operators have important IMS-related assets compared to mobile operators: no bandwidth problems, the possibility to rely on the openness of personal computers to easily test and introduce innovative services, and the possibility to find interesting synergies with newly introduced services like IPTV.

It should also be noted that re-creating on technologies like IP and IMS a legacy user experience created decades ago on a network optimized for it is not a simple thing. Some of the complexity is related to the need to artificially recreate a (limited) legacy user experience with a network and a protocol, which were made to naturally support a much richer one. This may lead to fixed network technicians complaining about the unability of IMS and SIP to faithfully and optimally replicate circuit-switched features while the same technicians totally ignore alternative and better features provided by the technology.

Christophe