MMS

Multimedia Messaging Service

MMS technology is a key component of the Nokia Series 40 Developer Platform. All Series 40 Developer Platform devices are capable of receiving and sending MMS messages. The device-native MMS client integrates with other native applications, such as the address book and camera controls, to provide a smooth multimedia experience for users. With the majority of wireless operators already offering MMS data services, MMS is quickly gaining popularity, and it offers a major revenue opportunity for developers and content providers. In this article, we discuss how to develop MMS applications. This article include the following:

• Messaging services: covers the basics of MMS, its network infrastructure, and business opportunities. We discuss the modes of MMS applications. Since most MMS applications reside on a PC (or on a server), not on a handset, we discuss how to send and receive MMS messages from the PC side.

• Authoring MMS messages: covers how to create MMS messages on a PC. We discuss the MMS client characteristics for Nokia devices, the basics of SMIL, and how to use Nokia's MMS content authoring tools.

• The Nokia Mobile Server Services API Library: introduces the Java APIs for Nokia MMSC servers. We can use those APIs to develop external MMSC applications for any External Application InterFace (EAIF) or MM7 standard compatible MMSCs. After reading this article, you will be able to grasp the key concepts of MMS

Services Of Messaging

MMS extends the text-based Short Message Service (SMS) to multimedia content. While SMS is limited to text and to basic graphic content with Smart Messaging, MMS is able to encapsulate virtually any media file, including text, photographs, video, screen savers, ring tones, audio files, and animations. However, it should be noted that suitable content is constrained by the media-handling capabilities of individual devices (see the next section for Nokia device characteristics). MMS is often described as the next-generation messaging service. MMS can be used by consumers to message friends, family, and business colleaguesessentially providing peer-to-peer messaging. MMS can also be used by content providers to deliver content or application functionality through an operator's Multimedia Messaging Service Center (MMSC).

Many mobile devices on the market, including all Nokia Series 40 and Series 60 mobile phones, already support MMS. Most operators deliver phones preconfigured for their MMS service. Users with MMS-capable phones purchased before their operator offered MMS service can configure their phones, either using over-the-air (OTA) configuration, usually initiated from a Web support site, or manually. For example, the Web site https://secure.mouse2mobile.com/clients/nokia/americas/mms/ can send the MMS configuration directly to any MMS subscriber phone in North America via WAP Push. The user just needs to accept and save the message for the settings to take effect. The Nokia Web site provides links to MMS configurator services in other parts of the world as well. To access those services, point your browser to http://www.nokia.com/ and select the menu's Support | Phone Support | Settings.

Advantages Of MMS And Its Oppotunities

Consumers benefit from MMS technology by having the opportunity to experience richer entertainment and information content. For instance, applications are available that allow consumers to send their friends animated greeting cards instead of simple text messages.

For developers, the possibilities for creating exciting new entertainment applications using MMS are virtually limitless. MMS provides services for everything from downloading and playing music, storing pictures and creating online photo albums, to composing and editing animations and greeting cards to send to friends.
Network operators also benefit from MMS because they charge consumers directly for the MMS services, indirectly for the bandwidth used to deliver the services, or recoup their investment by decreasing subscriber turnover rate. Operators actively seek value-added MMS services that can justify premium pricing. There are ample opportunities for developers to structure revenue share deals with operators based on applications that generate MMS usage and demand for data bandwidth.

The MMS Infrastructure

A key component of the MMS infrastructure is the MMSC server. Nokia is a major manufacturer of MMSCs. From the developer's and user's perspectives, the MMSC is very much like an email server in the Internet infrastructure. The sender sends her message to the MMSC operated by her mobile network operator. Depending on the receipt phone number in the message header, the MMSC routes the message to the target MMSC operated by the recipient's network operator.

The communication between the MMSCs is typically through the wired Internet using the standard HTTP and email protocols. The recipient MMSC first sends a WAP Push message to the recipient device notifying it of the incoming MMS message. The message provides a location to download the media content. The MMS-enabled device is automatically triggered to download the media content via WAP in the background. Once the message is completely downloaded and assembled, the device alerts the user and launches the MMS viewer application. Delivery of MMS messages is designed to be immediate but can be delayed by heavy loads on servers or by network congestion. On the current GPRS networks, it is not uncommon for an MMS message to take more than 15 minutes to be delivered to its recipient. The above process is illustrated in Figure 1.

Figure 1. The MMS infrastructure.

An MMS recipient address could also be an email address. In this case, the originating MMSC delivers the message directly to the recipient's email server using the SMTP protocol. The MMS message appears to be an email message with media file attachments in the recipient's email reader application.

Since the MMS relies on a packet data network to receive WAP Push and automatically download the media content, it requires at least a 2.5G wireless data network (i.e., either a GSM GPRS or a CDMA 1x network). The network operators and device manufacturers can both impose a limit on the maximum MMS message size. Large messages are slow to download. They could overrun the device's limited memory and offer no obvious user-experience improvements over smaller messages on the phone's limited display and audio hardware. In addition, since wireless data services are typically charged according to the bandwidth usage, unsolicited large messages are actually a security threat to users. Most wireless operators limit MMS message sizes from 30KB to 180KB. The Nokia devices have MMS size limits from 45KB to 100KB.

MMSC Access

To deliver MMS messages from our applications to the end users, it is crucial for us to gain access to the network operator's MMSC servers. However, operators, especially in the United States, often maintain tight control over their MMSCs. Only authorized parties are allowed to connect to the MMSC. Although making MMSCs talk with each other is technically simple, interoperability is a difficult business issue even between big operators themselves.

As a result, it is not always possible to send MMS messages across different networks. For developers, the issue is more complicated, since we have to make a business deal for MMSC access with each major operator in order to reach a broad range of end users. We expect network operators to gradually open their MMSCs to third-party developers in the future as the MMS technology and business model mature. Forum Nokia helps developers to gain access to live MMSCs in Europe, Asia, and North America via the Nokia Developer Hub program. The MMSC typically exposes its service to external applications via an HTTP-based interface. Two data protocols are supported by Nokia MMSC servers.

• The External Application InterFace (EAIF) is a binary data protocol over HTTP. It is a nonstandard protocol supported by all Nokia MMSC servers.

• The MM7 protocol is an XML Web Services standard used to access MMSCs and defined by the 3GPP. The MM7 protocol should be supported by most new MMSC servers in the future.

The detailed specifications of EAIF and MM7 are not important to MMS application developers, since the Nokia Mobile Server Services Library provides an easy-to-use Java API to wrap around those protocols..

An alternative way to access MMSCs is through commercial MMS gateway services, such as the http://www.csoft.co.uk/ Web Service. The gateway service provider has negotiated contracts with multiple operators. It exposes a simple HTTP-based interface to developers. For a small subscription fee, we can send MMS messages directly from our backend applications. The MMS message is enclosed in a .mms file. We can just upload it via HTTP POST to the gateway server and the gateway sends it to the target phone number.

MMS Application Modes

MMS applications can interact with users in several different ways. For MMS developers, it is important to understand the application modes and choose the best message delivery mechanisms.

Peer-to-Peer Messaging Mode

MMS enables mobile users to send multimedia messages to each other. For example, a user with a camera phone can send photos to peers via MMS. In this mode, the users typically use the MMS client software that is factory-installed on the handset. With the current generation Series 40 devices, the native MMS client software is not programmatically accessible and hence there is little opportunity for developers. However, two new developments in the near future might change the landscape for this type of applications drastically.

• The J2ME File I/O API (JSR 75) will provide access to the native file system on the device. That would allow a J2ME application to exchange media files with the native MMS client. For example, we can retrieve media files from MMS messages and use them in J2ME applications.

• The J2ME Wireless Messaging API 2.0 (JSR 205) will enable J2ME applications to send MMS messages directly to each other. Together with MMAPI, it could open exciting new opportunities for peer-to-peer smart-client applications.

The Terminating Mode

An MMS terminating application receives messages. A good example is the mobile photo blog application. The camera phone takes a picture, composes the MMS message, and sends it to the server. The server extracts the photo from the message, processes it, and makes it available from the blog Web site. The terminating application can receive the MMS message either by integrating with the MMSC or through a standard email account.

When integrated with an MMSC, the terminating application is associated with a special phone number easily accessible to users. In this case, the terminating application is typically an HTTP server that listens for incoming connections. The phone number, server address, and port number are registered in the operator's MMSC route table. When the user sends an MMS message to the registered number, the MMSC connects to the terminating application's server and posts the message content over HTTP using Nokia's EAIF protocol or the standard MM7 protocol. Direct integration with the MMSC allows us to take full advantage of the MMSC features (e.g., to use easy-to-remember special phone numbers). But, as we have discussed, it is also difficult and potentially costly to sign business arrangements with the operators to gain the MMSC access.

An easier and cheaper approach is to receive MMS messages via your own email servers. The MMS client on Nokia devices can send messages to email addresses. We can write an application that polls the email server periodically to retrieve the messages. The JavaMail API provides a standard and easy-to-use API to retrieve messages via any email protocol and parse the multimedia parts of the message.

The terminating application mode is illustrated in Figure 2.

The Originating Mode

An originating application sends MMS messages to mobile devices. An example for such an application is a mobile content provisioning service. The user could call in or use her mobile Web browser to order a picture or a ringtone. The originating MMS application would send the media file to the phone once the payment is received. As we have discussed, the MMS application could send MMS messages to handsets via direct integration with the MMSC (EAIF or MM7 over HTTP, or the Nokia Mobile Server Services Library) or via MMS gateways (HTTP upload of .mms files). The originating application mode is illustrated in Figure 3.

Figure 3. The originating MMS applications.

The Originating-Terminating Mode

An originating-terminating application can both send out MMS messages and receive MMS messages. An example is an MMS-based mobile trivia application. The backend application sends questions to the handset, and the user responds by replying with the choice number in the message body. However, we have to note that the current MMS infrastructure does not provide sufficient support for highly interactive applications, since it could take a long time for the message to deliver.

The easiest way to develop originating-terminating applications is to integrate with MMSCs. However, it is also possible to use mixed originating and terminating solutions. For example, we can send out MMS messages via mobile MMS gateways and receive replies via a special email address.

Authoring MMS Messages

MMS messages are the core of any MMS application. The MMS messages carry the rich media content. They are delivered to the user's handset and played back by the MMS viewer application on the device. We start our discussion by introducing the MMS characteristics of Nokia devices.

Nokia Device Characteristics for MMS

An MMS message consists of several text or multimedia components. There are many kinds of media content, and not all MMS-compatible devices support all media types. Table1 lists the MIME types and media filename suffixes supported on Nokia Series 40 and Series 60 Developer Platform devices. The symbols are as follows.

• N/A indicates that this media type is not supported on this class of device.

• S/R indicates that both sending and receiving are supported. The user can view the media file in the on-device MMS viewer application.

• R indicates that receiving is supported and the user can view the media files in the MMS viewer.

• R1 indicates that this media type file can be received in an MMS message but has to be saved to the device memory and opened by another application.

Table 1. Supported MIME Types on Nokia MMS Handsets

For Series 60 devices, we can pass Java applications (JAR and JAD files) and WML content in MMS messages. This content can be saved to the device memory and then opened by the Java Application Management Software and the WML/xHTML browser application.

For older specialized Series 40 devices, there are several notable exceptions to Table 1. In particular,

• The Nokia 6650 and 3105 devices support progressive jpeg images.

• The Nokia 6220, 6650, 6820, and 7200 devices support 3gpp video files.

• The Nokia 3200, 6220, 6650, 6810, 6820, and 7200 devices support amr audio files, and they support MMS message sizes up to 100KB.

For the exact and most up-to-date MMS specifications for Nokia devices, please refer to the "Messaging Characteristics in Nokia Phones" document published on Forum Nokia. In addition to supporting the individual media types, some Nokia devices support an MMS presentation component that ties together the media file attachments in the MMS message.

Small Into To SMIL

The MMS presentation component is written in an XML-based markup language called Synchronized Multimedia Integration Language (SMIL). SMIL is supported on Series 40 Developer Platform 2.0 devices as well as all Series 60 Developer Platform devices. In a nutshell, the SMIL part in an MMS message provides instructions to the MMS client on how to present the other multimedia parts in the same message.

It works similarly to the way HTML Web pages provide rendering instructions to Web browsers. For example, it can specify how images or video clips can be laid out on the screen. More interestingly, the SMIL can specify timing information of the presentation. For example, the SMIL presentation can play back an audio file for a specified period of time while an image is displayed. We can also use SMIL to program a timed slide show through the images attached in the MMS message. Without the SMIL component, the MMS message will be displayed as a series of discrete media objects in the viewer, which the user can step through using the device's scroll key.

Figure 4 shows an MMS message with image and audio components but no SMIL presentation. Figure 5 shows how the SMIL presentation ties the two media parts together by playing back the audio while displaying the image. Hence, SMIL allows us to compose sophisticated MMS messages that produce an excellent user experience.

Figure 4. Objects in an MMS message without the SMIL presentation.

Figure 5. The SMIL presentation ties media objects in a message together.

Structure Of SMIL Document

A SMIL document is a properly formatted XML document. The entire document must be enclosed inside a pair of  tags. The root element has the following two children elements.

• The element defines shared information across the document, such as the screen layout and available transition effects. For simple MMS messages, we can ignore the element altogether.

• The element contains the instructions on how the media files should be played back. It is required in all SMIL documents.

Two types of playback elements can be used inside the element: the parallel and sequential playback elements.

The Playback Control Elements

The element in a SMIL document encloses media elements that are played parallel to each other. For example, we can play a music clip while at the same time displaying a picture on the screen (see the following listing).

The playback length of the element is by default the longest media child element. We can alter this behavior by changing the value of the endsync attribute. For example, endsync="first" would cause the element to stop when the first media element is stopped. We could also specify an arbitrary playback length for the element using the dur attribute. For example, the attribute value dur="5s" would cause the playback to stop after 5 seconds. The begin attribute can be used to specify the initial delay before the playback is started. The repeatCount attribute specifies how many times this element should be repeated, with the value indefinite indicating an indefinite playback loop until the user interrupts it.

We can also play back media elements in sequence using the element in SMIL. That is analogous to a slide show (see the listing below).

The begin, dur, and repeatCount attributes can also be used together with the (seq) element. The and (seq) elements can be nested in a SMIL document. For example, we can have a picture slide show with a single music track or a slide show with a different music clip for each picture. See the sample code at the end of this section for an example of nested and elements.

The Media Elements

The media elements inside the or (seq) elements indicate what media files to play and how to play them. We saw the image and audio media elements in the above examples. Table 2 lists the media elements defined in SMIL. The src attribute specifies the referenced media filename, and the dur attribute specifies the duration of the playback. The media object type must be one of those supported by the device's MMS viewer.

Table 2. Media Elements in SMIL

Layout Management

As we mentioned, the element in a SMIL document can be used to hold definitions of shared attributes. For example, we can specify how the screen should be divided into display areas using the element. Each display area is specified by a element inside . The top, left, bottom, and right attributes of the element specify the position of the display area; the width and height attributes specify the size of the display area. The element is a sibling of elements, and it specifies the overall screen size. Using the element, we can display multiple media objects at the same time on the screen. The following example shows a photo with a line of text caption below it.

In addition to layouts, we can also define transition effects between children elements in the element. SMIL has a number of predefined transition effects to use when we change from slide to slide. For more information, please refer to the SMIL specification available from http://www.w3.org/AudioVideo/.

A Music Slide Show Example

Combining all we learned above, the following listing shows a SMIL presentation that runs a picture slide show with background music. Each of the pictures stays on the screen for a different length of time.

Nokia Developer's Suite for MMS

The Nokia Developer's Suite (NDS) for MMS is a content authoring tool that allows us to test SMIL-based MMS messages to device emulators. The user interface of the software is very simple. Upon starting up, the program locates all the suitable device SDKs installed on the current computer and lists them in the lower right panel. We can click on the Start New button to create new SDK emulator instances (see Figure 6).

Figure 6

We have to start the Nokia Connectivity Framework in order to send messages from the NDS for MMS to the Series 40 Developer Platform 2.0 SDK emulator.

Then, we can select a SMIL file in the top panel and fill in the route and message header information. We click on the Create button to create a new .mms file that has all the media elements embedded. The .mms file is saved in the same directory as the .smil file, and it can be sent as a standalone message to commercial MMSC gateway services. We can see the content of the generated .mms file in the lower left panel (see Figure 7).

Figure 7. Create MMS file from the SMIL presentation.

After the .mms file is created, we can click on the Send button to send it to selected emulator instances. The emulator displays a new message alert (see Figure 8). Once we accept the alert, the MMS viewer application is automatically launched to display the message.

Figure 8. New messaging alerts.

Unfortunately, the version 1.0 of the Series 40 Developer Platform 2.0 SDK does not yet support SMIL presentation properly. Until this known issue is resolved, to test your SMIL presentations properly on the PC, we recommend installing the free RealOne media player and opening the SMIL file from there.