Professional Documents
Culture Documents
Messaging
Forum.Nokia.com
Contents
1 INTRODUCTION ............................................................................................................................................ 6
2.1.1 Adobe GoLive with Nokia Developer's Suite for MMS ....................................................7
2.2.1 Adobe GoLive with Nokia Developer's Suite for MMS ................................................. 10
2.4.1 Series 60 SDK for Symbian OS, Nokia Edition Series 60 SDK for Symbian OS –
Chinese, Nokia Edition ......................................................................................................................... 16
5 REFERENCES ................................................................................................................................................24
Change History
12 June 2003 V1.0 Initial document release – NOTE! This document was previously
released as “Getting Started with MMS” version 1.1, but was renamed,
as another document with that name will appear shortly.
Disclaimer
The information in this document is provided ”as is,” with no warranties whatsoever, including any warranty of
merchantability, fitness for any particular purpose, or any warranty otherwise arising out of any proposal,
specification, or sample. Furthermore, information provided in this document is preliminary, and may be changed
substantially prior to final release. This document is provided for informational purposes only.
Nokia Corporation disclaims all liability, including liability for infringement of any proprietary rights, relating to
implementation of information presented in this document. Nokia Corporation does not warrant or represent
that such use will not infringe such rights.
Nokia Corporation retains the right to make changes to this specification at any time, without notice.
The phone UI images shown in this document are for illustrative purposes and do not represent any real device.
Copyright © 2003 Nokia Corporation.
Nokia and Nokia Connecting People are registered trademarks of Nokia Corporation.
Java and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc.
Other product and company names mentioned herein may be trademarks or trade names of their respective
owners.
License
A license is hereby granted to download and print a copy of this specification for personal use only. No other
license to any other intellectual property rights is granted herein.
1 INTRODUCTION
The goal of the following document is to give developers a “big picture” view of how to use the
currently available Nokia MMS tools. It is primarily aimed at server-side developers, but client-side
developers should find it valuable as well.
We will briefly explain what each tool can be used for, and then go through a step-by-step example,
where the end result will be your creation of an MMS on a phone simulator that will appear as it
would on a real MMS terminal.
Finally we will cover some important details to remember when creating your first MMS message:
Should it include a presentation part or not? What about using MMS as a transport method?
This document is intended to be a practical supplement to the theory presented in How to Create MMS
Services. It is recommended that you download that document to serve as a reference while reading
this one. If and when an item is not fully explained here, a more detailed explanation may be found in
its “companion” document.
It is our hope that this document will live up to its name, and truly help you get started developing
MMS applications.
Depending on your needs, you may want to use different tools for creating MMS messages. Are you
creating messages on-the-fly based on input from the user? Or are you creating fixed content? Do
you need to have control over MIME types or are you sending plain gifs and jpgs? Whatever the case,
one of the following should be able to fulfill your needs.
Adobe GoLive is a professional content authoring tool that helps you create media-house-quality fixed
content. Nokia Developer’s Suite for MMS (NDS) can be used as a plug-in with Adobe GoLive to
encapsulate your fixed content into MMS format. MMS creation using Adobe GoLive with NDS is “SMIL-
based” – you create a SMIL presentation; define the images, text, and audio parts you want in the
presentation; and then encapsulate the presentation as an MMS message.
Using Adobe GoLive with NDS you have no control over the MIME types of the various parts which are
added to the presentation – the MIME types are defined based on the extensions of the file names.
Nokia Mobile Internet Toolkit (NMIT) has primarily been used for developing WML content, but as of
version 3.1 provides MMS support as well. NMIT has an easy-to-use MMS wizard that helps you create
MMS messages in a content-based fashion: You specify what content you want to include in the
message, and the wizard will create an MMS message that includes those parts.
You can choose to include your own presentation part (written in SMIL), have one created for you by
the wizard, or not include one at all (see Chapter 3: Tips for Creating MMS Messages for more
information about MMS messages with or without presentation parts). In any case you can further
edit the message as you see fit, changing the order of the parts, editing the presentation part to
group/order the presentation of the parts correctly, or even editing the MIME types of some parts.
• There is an extra MMS header with “space” as name – you should edit the name so that it is blank,
or choose not to include the header.
• If using Content-ID labels , you should enter them as “<label>” including the quote marks (this is
important if the label is referenced in the presentation part – in this case as cid:label).
• Lots of “extra” headers are included by default – this causes an increase in message size.
• The first two lines of NMIT-generated SMIL must be removed to work in Series 60 emulators (in
actual phones they should be OK).
• It is not possible to choose character encoding.
• The order of objects in the encapsulated MMS message is same as that seen in the toolkit.
• Saved MMS messages have message-type m-retrieve.conf, which is for MMSC-to-client messages
(see Chapter 2.2: Send MMS Messages).
The Nokia MMS Java Library includes a compiled library and its complete source code. The library
provides the same kind of content-based message creation as NMIT, but without the easy-to-use
wizard. You provide the various parts, including your own presentation part, and the library will
encode it in MMS format. Note that you must also set all the headers yourself. Of course this gives you
extra control that you might not normally have with other tools, but at the same time it requires that
you have a deeper understanding of how MMS messages are put together.
Some items to notice about creating MMS messages with Nokia MMS Java Library:
• US-ASCII is the default encoding for text parts – it is not user definable.
• “<label>” for Content-ID results in Content-ID header (SMIL href=“cid:label”).
• “label” for Content-ID results in Content-Location header (SMIL href=“label”).
• Subject encoding is not supported.
• The order of objects in the encapsulated MMS message is not necessarily the same order in which
they are added to the message.
• Source code is provided, so you are free to fix anything exactly the way you want.
The Nokia Mobile Server Services (NMSS) API and Library are essentially a more up-to-date version of
the MMS Java Library. The two are not compatible, and the MMS Java Library is no longer supported,
but we recommend using it as a starting point, as it comes with clearer examples. After becoming
familiar with MMS application development, the NMSS API and Library are definitely the best tools to
use, as they will be kept up-to-date.
The NMSS API and Library includes a compiled library and its complete source code. The library
provides basically the same kind of content-based message creation as the MMS Java Library. Keep in
mind that while you have extra control over headers, etc., this still means you must have a deeper
understanding of how MMS messages are put together.
Some items to notice about creating MMS messages with NMSS API and Library:
This is not actually a tool, but simply the source code (based on MMS Java Library v1.1) used to create
the HelloWorld sample from the document How to Create MMS Services. The comments in this source
code explain some points that are not necessarily covered anywhere else. You can use this source
code to become more familiar with the inner workings of MMS messages. It is also used in the step-
by-step example in Chapter 2.5 Combining Several Tools – Step-By-Step Example.
Here, again, there are several tools available. Certain tools may be more suitable for your message-
sending needs. You will be better able to decide what tools will work best for you after reading this
section and Chapter 2.3: Receive MMS Messages.
The most common scenario in real life would most likely be that your application sends MMS
messages to an MMSC via an external application interface. For testing purposes, however, that may
not be possible or desirable for one reason or another. See Figure 2 for an at-a-glance look at the
Nokia MMS tools, and the possible destinations when sending MMS messages with these tools. For
example, the MMS Java Library and GoLive with NDS for MMS can send MMS messages to four possible
destinations. (The figure simply groups the tools – it does not attempt to say that the MMS Java
Library sends its messages through GoLive.) The “MMSC Emulator” mentioned in the figure simply
refers to any tool that can emulate an MMSC to the extent that it can receive MMS messages along the
EAIF.
With Nokia Developer’s Suite for MMS (NDS) installed as a plug-in with Adobe GoLive, you can create a
SMIL presentation and then encapsulate it into MMS format, as explained in Chapter 2.1: Create MMS
Messages, above. After that, though, you can also “wrap” the MMS message with HTTP headers, and
“deploy” it.
• A directory - useful if you want to see the MMS message using one of Nokia’s terminal simulators
• A real-live Nokia MMSC – uses Nokia’s External Application Interface (EAIF), so will not work with
other interfaces
• A Nokia MMSC emulator – so long as the emulator supports the EAIF
• An application that supports the EAIF –typically an application you are testing
Viewing MMS messages in a simulator will be covered in Chapter 2.3: Receive MMS Messages. Sending
to a live MMSC will of course require an agreement with the MMSC owner, which could be an operator
or perhaps a Forum Nokia Developer Hub. If your real MMS terminal is configured to a live MMSC that
you can send MMS messages to, this will allow you to get the messages delivered to your own MMS
terminal (as opposed to seeing the message in a simulator).
The Nokia MMSC External Application Interface (EAIF) emulator is a tool that enables application
developers to test applications without a live connection to a Nokia MMSC. The EAIF emulator provides
the basic functionality of the external application interface by emulating some functions of a live
Nokia MMSC. The emulator does not provide support for the WAP gateway interface or any such
interface (e.g., Push Proxy gateway) other than the EAIF.
To use the EAIF emulator to send MMS messages, the messages must be in encoded format and of
message-type m-send.req. Note that of the tools mentioned above in Chapter 2.1: Create MMS
Messages, all can save messages in encoded format, the only problem being NMIT, which encodes the
message with the wrong message-type for these purposes. The solution is to use a hex editor to edit
the second byte of the message from 84H to 80H.
With the MMS file stored in the proper directory and the proper configurations in place, you can use
the EAIF emulator to send the MMS message to:
• A real-live Nokia MMSC – utilizes Nokia’s EAIF, so will not work with other interfaces
• A Nokia MMSC emulator – as long as the emulator supports the EAIF
• An application that supports the EAIF – this would typically be an application you are testing
The same comments apply here as with Adobe GoLive “deployment” in the previous section.
Understanding the terminology of the EAIF emulator is a bit tricky. Note that the main purpose of the
EAIF emulator is to test your own applications. When trying to determine what mode you should start
the emulator in (Application Originating, Application Terminating,…), think in terms of what kind of
application you would be testing. When would you need the EAIF emulator to send MMS messages —
in order to emulate the MMSC to test a terminating application.
The Nokia Mobile Server Services (NMSS) emulator is much more than just an up-to-date version of the
MMSC EAIF emulator. It provides a development and testing environment for not only the Nokia MMSC,
but also the Nokia Delivery Server and Nokia Terminal Management Server. The package contains
emulators and developer documentation. The emulator platform is based on Borland Enterprise
Server.
The functionality in MMS application testing is essentially the same as in the EAIF emulator.
Once properly configured, you can use the NMSS emulator to send MMS messages to:
• A real-live Nokia MMSC – utilizes Nokia’s EAIF, so will not work with other interfaces
• A Nokia MMSC emulator – as long as the emulator supports the EAIF
• An application that supports the EAIF – this would typically be an application you are testing
Again, sending to a live MMSC will require an agreement with the MMSC owner – see the earlier
comments regarding Adobe GoLive “deployment."
Since the originating/terminating thinking for the EAIF emulator was confusing, that thinking has
been reversed in the NMSS emulator. With the NMSS emulator, try to think only of the MMS messages
– are they originating from the emulator or terminating there? To send MMS messages from the
emulator, it must be in originating mode.
• It is not possible to send an MMS message unless it has first been received by the emulator in
terminating mode, and thus stored in the database – see Chapter 2.3: Receive MMS Messages.
• It is possible to change the TO-field before sending.
The library comes with an example application for sending an MMS message. We recommend taking a
look at it and then adapting it to your needs. With the library you can send an MMS message to:
• A directory - useful if you want to see the MMS message using one of Nokia’s terminal simulators
• A real-live Nokia MMSC – utilizes Nokia’s EAIF, so will not work with other interfaces
• A Nokia MMSC emulator – as long as the emulator supports the EAIF
• An application that supports the EAIF – this would typically be an application you are testing
The NMSS API and Library also comes with an example application for sending an MMS message. As
mentioned earlier, the MMS Java Library examples are clearer, and we recommend starting there, but
for further development you will want to become familiar with the NMSS way of doing things.
With the NMSS API and Library you can send an MMS message to:
• A real-live Nokia MMSC – utilizes Nokia’s EAIF, so will not work with other interfaces
• A Nokia MMSC emulator – as long as the emulator supports the EAIF
• An application that supports the EAIF – this would typically be an application you are testing
NMIT doesn’t really allow you to “send” an MMS message in the same sense that the other tools do,
but you can use it to:
The EAIF emulator can be configured for testing originating applications, which means that it listens to
a certain port for incoming MMS traffic, just as an MMSC would do. In addition, there is a parameter in
the emulator configuration file (eaifem.properties), “MMSIN”, that specifies which directory any
incoming MMS message should be copied to. Some of Nokia’s MMS terminal emulators can detect
when an MMS message is copied to their “inbox,” and automatically display the message. A “green
light” in the EAIF emulator indicates that the headers for the message are in good shape, and then the
terminal emulator can let you see that the message itself is correct. (Additional information in this
section details which emulators can automatically detect incoming MMS messages.)
The EAIF emulator simply listens to a port, and can therefore receive MMS messages from:
• A real-live Nokia MMSC – utilizes Nokia’s EAIF, so will not work with other interfaces
• A Nokia MMSC emulator – as long as the emulator supports the EAIF
• An application that supports the EAIF – this would typically be an application you are testing
As described earlier, the terminology of the EAIF emulator may seem rather odd. It will help to just
think in terms of what kind of application you would be testing. When you want the EAIF emulator to
receive MMS messages, the one sending them would be an originating application, so set the emulator
to “Application Originating” mode.
• Note that if the MMSIN parameter points to bad/non-existent directory, the EAIF emulator will
crash on MMS reception.
The NMSS emulator can also be configured to receive MMS messages from the same sources as the
EAIF emulator:
• A real-live Nokia MMSC – utilizes Nokia’s EAIF, so will not work with other interfaces
• A Nokia MMSC emulator – as long as the emulator supports the EAIF
• An application that supports the EAIF – this would typically be an application you are testing
For the NMSS emulator, when you want MMS messages to terminate at the emulator, put the emulator
in terminating mode. The NMSS emulator can break the MMS message down into its parts and the
parts can be seen in binary format, but the message cannot be viewed as in an emulator.
Some points to consider when using the NMSS emulator for receiving MMS messages:
• It can be configured to store received MMS messages in its database -- messages can then be sent
using the emulator in originating mode.
• It is not possible to route incoming messages to the “inbox” of emulators.
• After receiving an incoming message, the emulator responds with HTTP code 200, not 204 as it
should.
The library comes with an example application for receiving an MMS message. The application
receives an MMS message, decodes it, prints some of its headers to standard output, and breaks the
message into various parts, saving separate parts to permanent store. It is also fairly easy to edit the
application so that it writes the encoded version of the message to permanent store – this can be
used as above to send the message to an emulator’s “inbox.” We recommend that you take a look at
it, and then adapt it as you see fit.
• A real-live Nokia MMSC – utilizes Nokia’s EAIF, so will not work with other interfaces
• A Nokia MMSC emulator – as long as the emulator supports the EAIF
• An application that supports the EAIF – this would typically be an application you are testing
Note that there are certain known problems with the MMS Java Library:
• Encoding for text parts is not supported – can lead to trouble when decoding non-US-ASCII texts
• Subject encoding is not supported – can lead to trouble when decoding non-US-ASCII subjects
• Decoding of messages from Nokia Series40 / Ericsson terminals fails – fixes are available from
Messaging Discussion Boards (forum.nokia.com/support --> Discussion Boards)
Again, we provide the source code, so you are free to edit and improve the library as you see fit.
The NMSS API and Library currently come with no example application for receiving an MMS message.
As mentioned earlier, the MMS Java Library examples are clearer, and we recommend starting there,
but for further development you will want to become familiar with the NMSS way of doing things.
With the NMSS API and Library you can receive an MMS message from:
• A real-live Nokia MMSC – utilizes Nokia’s EAIF, so will not work with other interfaces
• A Nokia MMSC emulator – as long as the emulator supports the EAIF
• An application that supports the EAIF – this would typically be an application you are testing
Many of the problems from the Nokia MMS Java Library should be fixed in the 1.0.1 and later versions
of the NMSS API and Library, so that it can handle, for example, encoded subjects and text parts, as
well as deal properly with MMS messages from Nokia Series 40 or Ericsson MMS terminals.
All of the following emulators can work with the Nokia Mobile Internet Toolkit, and can have MMS
messages created with that tool “pushed” to them. They will then display the message as it would
appear in a live terminal. Some of the emulators have a special directory “inbox,” and will
automatically display MMS messages that are copied into this directory. This can be useful when
messages are coming from tools other than NMIT.
And what’s the difference between an emulator and a simulator? An emulator is based on an early
version of actual phone software and should therefore be much closer to the real thing than a
simulator, which is not based on actual phone software.
This simulator does not function as a standalone tool, and can only display MMS messages created and
“pushed” with the Nokia Mobile Internet Toolkit (NMIT). It can be used to see what an MMS would
look like on some of the earliest MMS terminals such as the Nokia 6590 and the Nokia 3510. With so
many color-screen terminals on the market these days, though, you may find that you have little use
for the old black-and-white ones.
This emulator can display MMS messages created and “pushed” from NMIT, and it also supports the
“inbox” concept. Use it for example to see how your MMS messages with video will look on the Nokia
6650.
2.3.5.3 Series 60 Content Authoring SDK for Symbian OS, Nokia Edition
This emulator can display MMS messages created and “pushed” from NMIT, and it also supports the
“inbox” concept. There are loads of Series 60 terminals on the market – use this tool to see how good
your MMS content looks on them!
This emulator can display MMS messages created and “pushed” from NMIT, and it also supports the
“inbox” concept. To check how your MMS messages look on the lower-end color-screen terminals, try
this Nokia 3510i emulator. Note that in order to get automatic MMS message updates you must start
the emulator from the command line and specify the inbox:, e.g., “3510i.exe –inbox Inbox” (and
ensure that there is a sub-directory named “Inbox”).
This emulator can display MMS messages created and “pushed” from NMIT, and it also supports the
“inbox” concept. The Nokia 7210 is a good representative for Series40 terminals with regard to MMS
capabilities. Note that in order to get automatic MMS message updates you must start the emulator
from the command line and specify the inbox, e.g., “7210.exe –inbox Inbox” (and ensure that there is
a sub-directory named “Inbox”).
If rather than develop applications for the server side of things, you are more interested in developing
applications to run on MMS clients (terminals), then the tool to use is the Series 60 SDK for Symbian OS.
Depending on your application you may find some of the previously mentioned tools useful as well.
The Series 60 SDK for Symbian OS features several Application Programming Interfaces (APIs) with
which to build your software. It is compatible with the Nokia 7650 and Nokia 3650. It also includes a
Series 60 terminal emulator, which supports the “inbox” concept, and so in that sense can be used to
“receive” MMS messages from some other tools.
Now that we’ve covered what each of the tools can do, let's see how these tools can fit together. The
goal of this exercise is to:
• Use another instance of the MMSC EAIF emulator to receive the message
• View the received message in the Series 60 CA SDK for Symbian OS, Nokia Edition
The exercise in depicted in Figure 4. Two instances of the MMSC EAIF emulator are used. The first one
emulates an MMSC and supposedly sends its message to a terminating application that we are testing.
(It sends the MMS message wrapped in HTTP headers to a certain port.) But instead of an application,
we put another MMSC EAIF emulator on the receiving end. It listens to the proper port, and emulates
an MMSC waiting for input from an originating application. Note that the figure shows a choice of
what emulator to use for viewing the MMS message in the end. This could in fact be any of the
emulators that support the “inbox” concept.
Prerequisite Note: It is important to have the Java 2 SDK Standard Edition v1.3.1_02 (or higher)
installed. The SDK can be downloaded from the Sun Web site (http://java.sun.com). Note! There may
be some problems if you're using SDK 1.4, but we can't say for sure. Version 1.3.1 definitely works. If
you encounter a problem with Version 1.4, try Version 1.3.1. (You'll need to set your CLASSPATH to
include, for example, the jdk1.3.1_02\jre\lib directory, and PATH to include, for example,
jdk1.3.1_02\bin.)
Next, go to http://forum.nokia.com/tools. Under Messaging Tools, you’ll find the tools listed below.
Download numbers one through three, and either number four or five, or both:
5) Series 60 Content Authoring SDK 1.0 for Symbian OS, Nokia edition (23M)
Zip file - Execute setup.exe – Same type of installation procedure as with the Nokia 7210 Content
Authoring SDK 1.0.
• Start Sending and Receiving EAIF emulators by running the appropriate startup.bat files in the bin
directories.
• For the Sending_TestTA emulator, choose Application->Terminating For Receiving_TestOA
emulator, choose Application->Originating.
• Now use the Sending_TestTA emulator to send the Sample MMS — green lights should appear in
both EAIF emulators, and the terminal emulator should display the message content.
At this point, you should take the time to read some more documents, understand why the tools work
the way they do, perform any trouble shooting, and build your own example application.
Try both the Series 60 and Nokia 7210 CA SDKs – and notice the difference in the outcome. Can you
find part of the reason for the difference in the How to Create MMS Services document? What about
using NMIT to create the same message – do you get the same results? How about using the NMSS API
and Library for the same thing?
This sample was merely intended to get you started. If you had problems with it, check through the
available documents, and if you can’t find an answer to your question, please post it on the Messaging
Discussion Boards on the Forum Nokia site. We’ll answer your question as soon as possible.
In the remainder of this document, we will lay down some guidelines for creating MMS messages.
Typically, an MMS message will consist of something that should be “displayed” to the user, some
combination of images, text, and audio clips. It may contain only one of these items, or it may contain
all of them, but in this typical example, it is expected that the recipient will open the message and
experience it immediately. In this type of case, it is strongly recommended that a presentation part
accompany the message.
When your MMS message includes a presentation part, the content type of the MMS message is
application/vnd.wap.multipart.related, and its content type header should look like this:
Content-Type: application/vnd.wap.multipart.related;
type=”application/smil”;
start=”<0000>”
The value of the start parameter can be anything, but should be enclosed in brackets as in the
example.
An MMS message consists of several parts, and each part has its own headers. The header for the
presentation part in our example would look like this:
Content-Type: application/smil
Content-ID: <0000>
It is important that either the MMS message header contain a reference to the presentation part in the
form of the start parameter, or that the presentation part be the very first part of the MMS message
body. In the example headers above, the “start” parameter of the MMS message content type header
refers to the Content ID of the presentation part.
The presentation part should be written using the limited subset of SMIL, which has been laid down in
the MMS Conformance Document (see References). This should be written using only US-ASCII
characters, and should use utf-8 encoding. Note that if US-ASCII characters are utf-8 encoded, this is
the same result as if they had been encoded using US-ASCII, any of the ISO-8859-X encoding schemes,
or Windows CP1252. In other words, as long as your editing tools do not encode text in some more
“exotic” way, for example, using utf-16 encoding, then you should not have to worry about this issue
if you remember to use only US-ASCII characters in the presentation part.
Here is a sample presentation part, which we recommend using as a guide. To guarantee the best
possible interoperability with various terminals, don't use anything fancier than what is shown here.
The presentation has a head and a body part. The layout sizes given here are based on the latest MMS
Conformance Document (version 2.0), which recommends a maximum image size of 160 x 120. If you
are developing MMS content for a particular terminal, you will naturally want to use values for that
terminal in order to maximize the experience for the end user. This example layout has a picture in
the top 120 pixels, with text starting below that.
<smil>
<head>
<layout>
<root-layout width="160" height="140"/>
<region id="Image" width="160" height="120" left="0" top="0"/>
<region id="Text" width="160" height="20" left="0" top="120"/>
</layout>
</head>
<body>
<par dur="5s">
<img src="SmileyFace.gif" region="Image" />
<text src="HelloWorld.txt" region="Text" />
<audio src="HelloWorld.amr" />
</par>
<par dur="10s">
<img src="cid:TheEnd.gif" region="Image" />
<text src="cid:TheEnd.txt" region="Text" />
<audio src="cid:YCBNYH.amr" />
</par>
</body>
</smil>
The body consists of a series of <par> containers, each corresponding to a single “slide.” The first
<par> container includes: SmileyFace.gif in the Image region and HelloWorld.txt in the Text region,
and plays an audio clip HelloWorld.amr. The duration of the slide is set to five seconds. If the
recipient’s viewer supports timing, after five seconds, the second slide will automatically be shown. If
not, the recipient may use some manual method to switch to the second slide. Note that the duration
of a slide should naturally be at least as long as the duration of the audio component.
One slide can have at most one image, one text, and one audio clip, but does not necessarily have to
have all of these. There should be two regions specified in the <layout> section: Image and Text.
We’ve used two different methods of referencing in this example. For the second slide, the references
to the actual content are preceded by “cid:”. This is a reference to the Content-ID header of the part
that contains the content in question. In slide one, there is no such prefix in the references. This
means that they are references to a Content-Location header.
As stated earlier, an MMS message is a multipart message, each part having its own headers. The
content parts have at least two headers: Content-type and either Content-ID or Content-Location. The
headers for the audio clip parts of these two slides would look like this:
Content-type: audio/amr
Content-Location: HelloWorld.amr
Content-type: audio/amr
Content-ID: <YCBNYH.amr>
Either type of reference may include, for example, a number series instead of file names:
“../images/TheEnd.gif” or “01234” are both equally valid, as long as the references in the presentation
part match the Content-ID or Content-Location headers of the actual content. Content-ID references
increase the size of your SMIL presentation by four characters (“cid:”) as compared to Content-Location
references. Long plain text references, while easy to understand, also add extra length to your MMS
message — exactly twice their length, because they are included in both the presentation part and in
the header of the actual content. For this reason you may want to consider using a numbering
scheme instead. The savings may seem trivial, but the MMS Conformance Document recommends
keeping MMS messages to under 30 kBytes, so content developers may be looking for ways to squeeze
as much as possible into that 30 kBytes.
Note that the Content-IDs and Content-Location references need not be globally unique for MMS
messages, as long as they are unique within the message itself.
Consult the MMS Conformance Document for more details concerning the use of SMIL.
As for content formats, it is recommended that you use only those formats mentioned in the MMS
Conformance Document.
For images, these are baseline JPEG with JFIF exchange format, GIF87a, GIF89a, and WBMP. The size of
the image that should be supported by all terminals is 160 x 120. Not all terminals actually have
displays of that size, but they have some way of showing images of this size, and the terminal vendors
have therefore agreed to this size in the MMS Conformance Document.
We recommend using JPEG images when possible, as they typically pack smaller than GIFs.
For text, use US-ASCII, utf-8, or utf-16 with explicit Byte Order Mark.
For Personal Information Management (PIM), use vCalendar version 1.0 (text/x-vCalendar), and vCard
version 2.1 (text/x-vCard), with the condition that if the terminal has a calendar, then it must support
vCalendar.
In some cases you may wish to use the MMS message as a type of container for transporting a single
object, or content that the recipient’s MMS viewer is not expected to support directly. An example of
this might be when sending a Nokia ringing tone to the Nokia 7650. The MMS viewer of the Nokia
7650 cannot directly support this content, and indeed, it is expected that the user will save this
content to the terminal so that it can be used later. Here, the presentation part of the message is
completely unnecessary, and would just take up extra space.
When your MMS message does not include a presentation part, the content type of the MMS message
is application/vnd.wap.multipart.mixed, and its content type header should look like this:
Content-Type: application/vnd.wap.multipart.mixed
As mentioned earlier, an MMS message is a multipart message, and each part has its own headers.
However in this case, since no Content-ID or Content-Location is needed, the header for the content
parts only need include Content-Type, e.g.:
Content-Type: application/vnd.nokia.ringing-tone
Note that this type of MMS message may still contain several parts, so, for instance, you could include a
Nokia ringing tone and a MIDI or WAV version of the same tone in the same message, and let the
recipient decide (possibly based on the terminal’s capabilities) which of these to save and begin using.
Content sent in this manner will most likely not be of formats recommended by the MMS Conformance
Document, but will instead be intended for a particular terminal whose capabilities are known
beforehand.
5 REFERENCES
How to Create MMS Services Version 3.2
http://forum.nokia.com/documents
OMA Multimedia Messaging Service version 1.1, including MMS Conformance Document
http://www.openmobilealliance.org/omacopyrightNEW.asp?doc=OMA-MMS-v1_1-20021104-C.zip
Series 60 Content Authoring SDK 1.0 for Symbian OS, Nokia edition
http://forum.nokia.com/tools
Go to Forum.Nokia.com
1 Forum.Nokia.com provides the tools and resources you need for content and application development
as well as the channels for sales to operators, enterprises, and consumers.
Forum.Nokia.com
2 Forum.Nokia.com/tools has links to tools from Nokia and other industry leaders including Borland,
Adobe, AppForge, Macromedia, Metrowerks, and Sun.
Forum.Nokia.com/tools
3 The documents area contains useful white papers, FAQs, tutorials, and APIs for Symbian OS and Series
60 Platform, J2ME, messaging (including MMS), and other technologies. Forum.Nokia.com/devices lists
detailed technical specifications for Nokia devices.
Forum.Nokia.com/documents
Forum.Nokia.com/devices
Forum Nokia offers free and fee-based support that provides you with direct access to Nokia engineers
4 and equipment and connects you with other developers around the world. The Nokia OK testing
program enables your application to enjoy premium placement in Nokia's sales channels.
Forum.Nokia.com/support
Forum.Nokia.com/ok
Go to Forum.Nokia.com/business to learn about all of the marketing channels open to you, including
5 Nokia Tradepoint, an online B2B marketplace.
Forum.Nokia.com/business
Place your applications in Nokia Tradepoint and they're available to dozens of buying organizations
6 around the world, ranging from leading global operators and enterprises to regional operators and
XSPs. Your company and applications will also be considered for the regional Nokia Software Markets
as well as other global and regional opportunities, including personal introductions to operators, on-
device and in-box placement, and participation in invitation-only events around the world.
Forum.Nokia.com/business