Developers guidelines
August 2006
Multimedia Messaging Service (MMS) in Sony Ericsson entry level phones
Developers guidelines | MMS
Preface Purpose of this document The Developers Guideline for MMS is designed to give the reader a deeper insight of how to design applications for Multimedia Messaging Service MMS). The Multimedia Messaging Service standard uses specifications from the 3rd Generation Partnership Project (3GPP) and Open Mobile Alliance (OMA), to specify how rich media content can be transmitted mobile-to-mobile or network-to-mobile. This document applies to the T68, T230, T290, T300, T310, T610, T630, Z600, J210, J220, J230 and Z300 series of mobile phones. People who can benefit from this document include: • Application providers
• Operators and service providers
• Content providers
• Software developers
• Content aggregators
• Business decision-makers
It is assumed that the reader has a basic understanding of WAP/Browsing and MMS, and also some technical familiarity with email messages and mark-up languages (HTML, XML etc).
This document is published by Sony Ericsson Mobile Communications AB, without any warranty*. Improvements and changes to this text necessitated by typographical errors, inaccuracies of current information or improvements to programs and/or equipment, may be made by Sony Ericsson Mobile Communications AB at any time and without notice. Such changes will, however, be incorporated into new editions of this document. Printed versions are to be regarded as temporary reference copies only.
These Developers guidelines are published by: Sony Ericsson Mobile Communications AB, SE-221 88 Lund, Sweden Phone: +46 46 19 40 00 Fax: +46 46 19 41 00 www.sonyericsson.com/ © Sony Ericsson Mobile Communications AB, 2006. All rights reserved. You are hereby granted a license to download and/or print a copy of this document. Any rights not expressly granted herein are reserved.
*All implied warranties, including without limitation the implied warranties of merchantability or fitness for a particular purpose, are excluded. In no event shall Sony Ericsson or its licensors be liable for incidental or consequential damages of any nature, including but not limited to lost profits or commercial loss, arising out of the use of the information in this document.
16th edition (August 2006) Publication number: EN/LZT 108 5216 R16B
2
August 2006
Developers guidelines | MMS
Sony Ericsson Developer World On www.sonyericsson.com/developer, developers will find documentation and tools such as phone White papers, Developers guidelines for different technologies, SDKs (Software Development Kits) and relevant APIs (Application Programming Interfaces). The Web site also contains discussion forums monitored by the Sony Ericsson Developer Support team, an extensive Knowledge base, Tips and tricks, example code and news. Sony Ericsson also offers technical support services to professional developers. For more information about these professional services, visit the Sony Ericsson Developer World Web site.
Trademarks and acknowledgements The IrDA Feature Trademark is owned by the Infrared Data Association and is used under licence there from. The Bluetooth word mark and logos are owned by the Bluetooth SIG, Inc. and any use of such marks by Sony Ericsson is under license. Other product and company names mentioned herein may be the trademarks of their respective owners.
3
August 2006
Developers guidelines | MMS
Document conventions Products Sony Ericsson mobile phones are referred to in this document using generic names as follows: Generic names Series
Sony Ericsson mobile phones
J210
J210i, J210c
J220
J220i, J220c, J220a
J230
J230i, J230c, J230a
T68
T68i
T230
T226, T230, T238
T290
T290i, T290c, T290a
T300
T300, T302, T306, T308
T310
T310, T312, T316
T610
T610, T616, T618
T630
T628, T630
Z300
Z300i, Z300c, Z300a
Z600
Z600, Z608
Terminology and abbreviations Term
Explanation
3GPP
3rd Generation Partnership Project
AMR
Adaptive Multi Rate, a sound format used in MMS
EMS
Enhanced Messaging Service, an enhancement of the SMS standard. This makes it possible to include pictures, melodies, sounds and animations in messages, and also to receive and edit new pictures and melodies on the phone
iMelody
The iMelody format, specified by IrDA™, is a minimal set of tones that can be used in EMS applications to transfer melodies, such as ring tones, between devices.
JPEG
Joint Photographic Experts Group.
4
August 2006
Developers guidelines | MMS
Term
Explanation
MIDI
Musical Instrument Digital Interface
MMS
Multimedia Messaging Service. A system application by which an MMS client is able to provide a messaging operation with a variety of media types. To use this service, it must be supported by your network.
MMS Client
The MMS end point located on the mobile client device.
MMS Server
A server that provides storage and operational support for MMS
MIME
Multipurpose Internet Mail Extensions
MPEG
Moving Picture Experts Group standard
OMA
Open Mobile Alliance.
Service Provider
A company that provides services, for example subscriptions to mobile phone users.
SMIL
Synchronized Multimedia Integration Language
SMS
Short Messaging Service. Allows messages of up to 160 characters to be sent and received via the network operator's message centre to your mobile phone. Messages are stored if the phone is off or out of reach ensuring that they reach you. To use this service, it must be supported by your network.
SVG
Scalable Vector Graphics. A language for describing two-dimensional graphics in XML
UAProf
User Agent Profile, a feature that enables the phone to respond to a request from the server, to inform of the phone’s capabilities.
vCalendar
vCalendar automates the exchange of calendar items between devices.
vCard
vCard automates the exchange of personal information typically found on a traditional business card.
vNote
vNote automates the exchange of notes between devices.
WAP
Wireless Application Protocol. Handheld devices, low bandwidth, binary coded, a deck/card metaphor to specify a service. A card is typically a unit of interaction with the user, that is, either presentation of information or request for information from the user. A collection of cards is called a deck, which usually constitutes a service.
WSP
Wireless Session Protocol
XML
eXtensible Markup Language
5
August 2006
Developers guidelines | MMS
Document history Change history 2004-08-23
Version R11A
Revised edition. Information about the K700 series, S700 series, K500 series and Z500 series added
2004-10-05
Version R12A
Information about the V800 series added
2004-10-26
Version R12B
Minor editorial changes
2004-10-28
Version R13A
Information about the T290 series added
2005-03-21
Version R14A
14th edition. Removed information about Z1010, K700, S700, K500, Z500, and V800 series from this document.
2005-09-30
Version R15A
Information about the J210 series added
2006-02-13
Version R16A
Information about the J220, J230 and Z300 series added
2006-08-22
Version R16B
Document layout changed
6
August 2006
Developers guidelines | MMS
Contents Overview ......................................................................................................................8 Architecture ...............................................................................................................9 Examples of use ....................................................................................................9 Content adaptation ..............................................................................................10 UAProf (User Agent Profile) .................................................................................10 OTA configuration ................................................................................................10 MMS message types ................................................................................................11 The multipart message ............................................................................................11 Encoding and values in MMS headers ................................................................12 Encoding in the MMS body .................................................................................12 Supported MIME types .............................................................................................14 MMS MIME types ....................................................................................................15 Image MIME types ..................................................................................................15 Audio MIME types ...................................................................................................16 vFormats .................................................................................................................16 Executables .............................................................................................................17 Other MIME types ...................................................................................................17 Using assigned numbers registered within IANA ....................................................17 SMIL ...........................................................................................................................19 The SMIL language .................................................................................................20 Contents and presentation ..................................................................................20 SMIL support in Sony Ericsson mobile phones ...................................................20 DRM ............................................................................................................................26 Supported DRM MIME types ..................................................................................27 MMS in Sony Ericsson mobile phones ...................................................................28 Phone specifications ...............................................................................................29 MMS templates .......................................................................................................29 Downloadable MMS-templates ...........................................................................29 Related information ...............................................................................................32 Documents and links ...............................................................................................32
7
August 2006
Developers guidelines | MMS
Overview Using the Wireless Application Protocol (WAP) as bearer technology, Multimedia Messaging allows users to send and receive messages containing slide style presentations. When fully implemented, the messages may include any combination of text, graphics, photographic images, speech and music clips or video sequences. High-speed transmission technologies EDGE, GPRS and UMTS (W-CDMA) enable powerful messaging applications. An MMS message consists of a “slide show”. The sender captures and selects images, adds the texts and sounds, and sets the timing of the presentation.
8
August 2006
Developers guidelines | MMS
Architecture The mobile phone communicates with the WAP Gateway using WAP transport protocols. Data is transported between the WAP Gateway and the MMS Server using the HTTP protocol.
The MMS Server is at the centre of an MMS system. The following functions and services can be executed by the server: • • • •
Store MMS messages Forward MMS messages to external networks. Send MMS messages as email, using the SMTP protocol over the Internet. Send MMS messages via the SMS-C, thus enabling users of non-MMS mobile phones to receive MMS messages and view the text as SMS messages and the whole message via Web or WAP. • Perform Content adaptation
Examples of use User A addresses a multimedia message to user B’s mobile number (MS-ISDN). The completed message will be sent via the WAP Gateway to the MMS server. The MMS server will store the message and send a notification to User B's phone. It will retrieve the message automatically or manually depending on the user's settings. The user will then be able to read it from the MMS Inbox. If user A sends an MMS to a user on a different network, the MMS server will forward the message to the correct MMS server in the target network (assuming interconnect agreements are in place) and the message will be stored on the MMS server in the target network. It will be retrieved and read by the recipient's mobile phone in the same way as in the first example above. If User A sends an MMS to an e-mail address, the MMS server will package the contents and use SMTP to send the message as an e-mail over the Internet.
9
August 2006
Developers guidelines | MMS
Content adaptation The MMS server is able to perform limited content adaptation – for example from MMS to SMS – so that processing and air time is not wasted in sending messages to mobile phones that do not have adequate capability to receive them. The MMS server also vouches for high quality messaging, for example by format conversion. This means that the server recognizes which formats are supported in the mobile phone, and adapts the MMS messages to these formats. The WAP User Agent Profile (UAProf) is used to communicate the mobile phone's capabilities to the MMS server. These features depend on the configuration of the MMS servers and will therefore be operator-dependent.
UAProf (User Agent Profile) The UAProf functionality makes it possible for the MMS server to get information about the mobile phone's capabilities. The UAProf Header in the handset contains the required information for the server to identify the proper UAProf file and access capability information for the specific handset. The capability information can be hardware related, for example screen size, or software related, for example MMS support. The UAProf information can be used by the server to make the proper content adaptation of the MMS message. It is also possible for the server to prepare, or select, a version of an MMS message that is optimized for the capabilities of the receiving device. Examples of MMS related information (receiving mobile phone) in the UAProf: • • • • •
MMS version The maximum size of a multimedia message in bytes The maximum size of an image in units of pixels Supported content formats Supported character sets
OTA configuration Users can easily get MMS into their phone. MMS is configurable via OTA, meaning that the user does not have to configure the settings manually. The configuration is done by the operator.
10
August 2006
Developers guidelines | MMS
MMS message types The MMS is implemented on top of WAP 1.2.1. Most mobile phones on the market, including all Sony Ericsson mobile phones, support MMS messages up to 50 kByte, including header information and payload. Note, however that network limitations may also restrict the maximum message size.
The multipart message In order to be able to send an MMS message over the air, all of its parts have to be packaged into a multipart message. The methods used are based on the MIME standard, currently in use in most Internet email traffic, for example. This also ensures that MMS will have a certain compatibility with e-mail.
SMIL part with two slide descriptions
Text for first slide
Text for second slide
Image for Image for first slide second slide MMS header
Audio for first slide
Audio for second slide
MMS body
Figure 1. This example of a packaged MMS message consists of several related parts. The order of the parts in the message body does not matter.
11
August 2006
Developers guidelines | MMS
Encoding and values in MMS headers Content-Type: The MMS header includes a Content-Type parameter, stating the MIME type of the MMS message. The Content-Types used are the following: • Application/vnd.wap.multipart.related This MIME type shall be used when there is a SMIL presentation included in the MMS. It is recommended to include a “start” parameter in the MMS header. It specifies the Content-ID of the SMIL presentation. If the “start” parameter is included, the header must also include the “type” parameter, with the value application/smil. If the “start” and the subsequent “type” parameters are omitted, the SMIL presentation must be the first part of MMS body. Note: The “start” and “type” parameter values are written without quotation marks. • Application/vnd.wap.multipart.mixed This MIME type shall be used when there is no SMIL presentation included in the MMS body. • Application/vnd.wap.multipart.alternative This MIME type indicates that the multipart contains alternative content types. The mobile phone will choose the "best" supported MIME type. If more than one of the alternatives are supported, the last one will be chosen. Some of the MMS headers have been defined as "Encoded-string-value". The character set IANA MIBEnum value in these headers shall be encoded as Integer-value (Short-integer or Long-integer). The character set us-ascii (IANA MIBenum 3) shall be always accepted. If the character set is not specified (simple Text-string encoding) the character set is us-ascii (lower half of ISO 8859-1). When the text string cannot be represented as us-ascii, the character set shall be encoded as utf-8 (IANA MIBenum 106) which has unique byte ordering. In the MMS headers the supported characters shall be at least those in ISO 8859-1. The headers whose definition is Text-string (Content-Location, Message-ID, etc.) shall contain only usascii characters (lower half of ISO 8859-1).
Encoding in the MMS body For each part of the MMS body the following encoding parameters can be used. Content-Type: This is the “type of content” description of a part in the MMS body. • application/smil; charset="US-ASCII" – this is Content-Type for the SMIL presentation part • image/jpeg – an example of Content-Type for an image part. • text/plain – an example of Content-Type for a text part.
WSP multipart encoding shall be used. Content types in WSP multipart headers shall be encoded using WSP binary values whenever available. If they are not available, text encoding shall be used.
12
August 2006
Developers guidelines | MMS
Content-Location. This is a unique reference for each part of the message. This format is useful to make references. Other parts of the message can refer to another Content-Location, by using a relative URL reference. For example , where “bigimage.jpg” is the Content-Location for a part of the same message. Content-ID. This is the unique Content-ID for each part of the message. The presentation part can refer to another Content-ID, by using a “cid:” reference. For example , where “” is the Content-ID for a part of the same message (note that the brackets are removed in the reference string). The Content-ID does not have to be globally unique and it does not require a legal address definition. The maximum size of Content-ID or Content-Location shall be 100 characters. Character encoding with WSP multipart headers (Content-ID, Content-Location, etc.) shall be us-ascii (lower half of ISO 8859-1), as there is no WSP specific definition for the character set encoding in part headers.
13
August 2006
Developers guidelines | MMS
Supported MIME types The tables below list all MIME types supported in the Sony Ericsson mobile phones in this document.
14
August 2006
Developers guidelines | MMS
MMS MIME types Note: Assigned Numbers are used when available and registered within IANA. Y = Yes, N = No, R =Receiving only T68, T230, T290, T300, T310, J210, J220, J230, Z300
MIME
T610, T630, Z600
application/vnd.wap.mms-message
Y
Y
application/vnd.wap.multipart-mixed
Y
Y
application/vnd.wap.multipart-alternative
R
R
application/vnd.wap.multipart-related
Y
Y
Notes
Always used for normal messages
Image MIME types Note: Assigned Numbers are used when available and registered within IANA. Y = Yes, N = No, R =Receiving only MIME
T68, T230, T290, T610, T630, Z600 T300, T310, J210, J220, J230, Z300
JPEG (baseline)
image/jpeg
Y
Y
GIF87
image/gif
Y
Y
GIF89A
image/gif
Y
Y
PNG
image/png
N J210, J220, J230, Z300=R
N T630=Y
WBMP
image/vnd.wap.wbmp
Y
Y
BMP
image/bmp
N J210, J220, J230, Z300=R
N T630=Y
15
August 2006
Developers guidelines | MMS
Audio MIME types Note: Assigned Numbers are used when available and registered within IANA. Y = Yes, N = No, R =Receiving only
MIME
AMR
MIDI
iMelody
T68, T230, T290 T300, T310, J210, J220, J230, Z200
T610, T630, Z600
audio/amr
Y
Y
audio/x-amr
R T300=N
R
audio/midi
Y T68=N
Y
audio/x-midi
R T68=N
R
audio/mid
R T68=N
R
text/x-iMelody
Y
Y
audio/iMelody
N
R
vFormats Note: Assigned Numbers are used when available and registered within IANA. Y = Yes, N = No, R =Receiving only
MIME
T68, T230, T290, T300, T310, J210, J220, J230, Z300
T610, T630, Z600
vCard
text/x-vCard
Y J210, J220, J230, Z300=N
Y
vCalendar
text/x-vCalendar
Y J210, J220, J230, Z300=N
Y
vNote
text/x-vNote
Y J210, J220, J230, Z300=N
Y
16
August 2006
Developers guidelines | MMS
Executables Note: Assigned Numbers are used when available and registered within IANA. Y = Yes, N = No, R =Receiving only
MIME
Java JAR
application/java-archive
T68, T230, T290, T300, T310, J210, J220, J230, Z300 N
T610, T630, Z600 R
Other MIME types Note: Assigned Numbers are used when available and registered within IANA. Y = Yes, N = No, R =Receiving only
MIME
T68, T230, T290, T300, T310, J210, J220, J230, Z300
T610, T630, Z600
Text
text/plain
Y
Y
SMIL
application/smil
Y
Y
SMS over MMS
application/x-sms
R
R
application/vnd.3gpp.sms
R
R
Sony Ericsson Themes
application/vnd.eri.thm
Y J210, Z300=N
Y
MMS template
application/vnd.sonyericsson. mms-template
N
N
Using assigned numbers registered within IANA According to the MMS Encapsulation Protocol version 1.x and the MMS Conformance Specification, assigned numbers for WSP multipart headers and content types with encoding version 1.3 and lower shall be used.
17
August 2006
Developers guidelines | MMS
MIME types in Sony Ericsson phones with assigned numbers MIME type
assigned no.
image/jpeg
0x1E
image/gif
0x1D
image/png
0x20
image/vnd.wap.wbmp
0x21
vCard
0x07
vCalendar
0x06
text/plain
0x03
application/vnd.wap.multipart.mixed
0x23
application/vnd.wap.multipart.alternative
0x26
application/vnd.wap.multipart.related
0x33
18
August 2006
Developers guidelines | MMS
SMIL The MMS messages use a subset of the Synchronized Multimedia Integration Language (SMIL) as the presentation language. SMIL, pronounced as "smile", is an XML protocol specified by the World Wide Web Consortium (W3C). It can be regarded as an analogy to what HTML is for the Web. SMIL can control both layout and timing of multimedia objects. The first phase of MMS uses a limited subset of SMIL elements, "MMS SMIL". The messages consist of a "slide show", that is, a succession of one or several pages.
19
August 2006
Developers guidelines | MMS
The SMIL language There are SMIL tags available to specify user interactivity, timing, sound and positioning on the screen. However, the actual appearance of the presentation depends on the characteristics of the receiving device. A presentation created for one device, may appear differently on another. This is in full analogy with HTML on the Web, where the appearance of a Web page depends on the type of browser, and the browser settings.
Contents and presentation Each multimedia message will be represented by one SMIL presentation. All the slides in the presentation have the same layout. Each one contains at most two regions. One of the regions contains text and the other contains an image (it is also possible to have just an image region or just a text region). The slides are in fact frames that define the layout and refer to the content (text, images and audio), which is kept separate. The duration of each slide can be set in number of seconds. Inside each slide, timing for the different media objects can be set individually.
Presentation adapted for a mobile mobile phone A slide in a SMIL presentation contains information about how different multimedia elements should appear on a display. Due to the characteristics of todays mobile devices, such as their screen sizes, processor power and audio facilities, there are limits to how MMS messages can be reproduced on the receiving devices. Therefore, SMIL presentations are designed to allow the receiving device to re-arrange the presentation, if necessary. For example, the relative positioning of image and text may be altered by the receiving device. Or, for example, the duration time set for each slide may be replaced by the user pressing a phone key to advance to next slide. Of course, if the receiving mobile phone can fit the SMIL layout in its screen as is, no change will be necessary.
SMIL support in Sony Ericsson mobile phones Support for more advanced SMIL presentations in MMS creates several problems concerning editing and backwards compatibility. Therefore, MMS messages created in or sent from the Sony Ericsson phones mentioned in this document conforms only to the MMS SMIL subset, specified by OMA. The user can compose an MMS message using the mobile phone, a PC, or any other device with the appropriate MMS software. The MMS messages can also be automatically generated by a service or content provider. The MMS message payload consists of separate parts: • One part containing the description of the slides, using MMS SMIL. • One part containing the actual contents of the slides - text, images and sound. The SMIL part is encoded text and the character set shall be UTF-8 with lower half of ISO 8859-1 character set (us-ascii set).
20
August 2006
Developers guidelines | MMS
The SMIL mark-up is very similar to HTML mark-up. In more general uses of SMIL mark-up, more tags and attributes are available. However, in MMS messages sent from Sony Ericsson mobile devices, it is recommended not to use more types of tags or attributes than detailed in the following table. For more detailed information about an element or attribute, please see the SMIL 2.0 specification on http://www.w3.org/TR/smil20/.
Tags and descriptions The following tags and attributes are supported for sending and receiving MMS messages in all MMS enabled Sony Ericsson mobile phones. Tags used in MMS SMIL
Description
Support in Sony Ericsson phones
Required tags for the entire SMIL message definition.
Yes
Required tags for the Head section.
Yes
Optional attribute tags (in head section, similar to HTML). All receiving clients have to be able to accept a message that contains meta fields. However, the receiving client may ignore the meta information.
Ignored
Tags for defining the layout (in head section). This section sets the recommended layout for all the slides in the presentation. All receiving clients have to be able to accept the layout section. However, the receiving client may ignore the layout information. This will normally be the case on mobile devices. It is recommended, but not required, to include the layout section.
Yes
Tag that specifies the entire screen area of the message (required if there is a layout section), with attributes “width” and “height” in pixels. The maximum area recommended for full interoperability is 160 x 120 pixels.
Yes
An optional “backgroundColor” or “backgroundcolor” (deprecated) attribute can be used to change the color for all slides. Values in plain text or hex, for example “white”, “red”, “0xFFFFFF”
Tags for the Image region (required if there is a layout section), with attributes “size” (pixels or percent value) and position, “left” and “top”. Image and Text regions must be specified so that they do not overlap.
21
Ignored. Media objects in each slide are presented in the order that they appear in the SMIL presentation.
August 2006
Developers guidelines | MMS
Tags used in MMS SMIL
Description
Support in Sony Ericsson phones
Tags for the Text region (required if there is a layout section), with attributes “size” (pixels or percent value) and position, “left” and “top”. Image and Text regions must be specified so that they do not overlap.
Ignored. Media objects in each slide are presented in the order that they appear in the SMIL presentation.
Tags for the section. The section contains the descriptions of each slide.
Yes
Optional tags for specifying that one or several pages (between the tags) should be repeated.
Yes
Required tags for each slide description (in body section). The tags must not be nested.
Yes
The “par” (short for “parallel”) tag indicates that all elements in the slide should be displayed simultaneously (see margin note). In fact, this is always the case in MMS SMIL messages. In more general uses of SMIL mark-up, more complex settings are possible. The optional “dur” attribute sets the recommended duration for the slide (value in ms or s). However, the receiving client may ignore the duration attribute, and for example prompt the user to press a phone key to advance to the next slide.
22
Note: See also tag descriptions , and , for timing of the individual objects in the slide, using the “begin” and “end” attributes. Note: The maximum number of events in an MMS message depends on the device.
August 2006
Developers guidelines | MMS
Tags used in MMS SMIL
Description
Support in Sony Ericsson phones
Tags for the only image region of each slide. There can be max 1 image per slide.
Yes
This tag can be left out completely if no image should be displayed in the slide. The “src” file must be a valid image of a supported format.
Note: The maximum number of objects in an MMS message depends on the device.
The attribute value of “region” must be “Image”. The optional “alt” attribute is used for alternative text. The optional “begin” attribute sets the delay after which the object should appear in the slide (value in ms or s, relative to slide start). The optional “end” attribute sets the moment at which the object should disappear (value in ms or s, relative to slide start). If a “begin” time is set without an “end” time, the object remains for the duration of the slide. However, the receiving client may ignore the “begin” and “end” attributes, and for example prompt the user to press a phone key to present the next object.
23
August 2006
Developers guidelines | MMS
Tags used in MMS SMIL
Description
Support in Sony Ericsson phones
Tags for the only text region of each slide. There can be max 1 text per slide.
Yes
This tag can be left out completely if no text should be displayed in the slide. The “src” file must be a valid text of a supported format. The attribute value of “region” must be “Text”. The optional “alt” attribute is used for alternative text. The optional “begin” attribute sets the delay after which the object should appear in the slide (value in ms or s, relative to slide start). The optional “end” attribute sets the moment at which the object should disappear (value in ms or s, relative to slide start). If a “begin” time is set without an “end” time, the object remains for the duration of the slide.
Note: The maximum number of objects in an MMS message depends on the device. Additional (optional) “textsize” parameter can be used. Values: small, normal or large. Additional (optional) “foreground-color” parameter can be used. Values in plain text or hex, for example “white”, “red”, “0xFFFFFF”
However, the receiving client may ignore the “begin” and “end” attributes, and for example prompt the user to press a phone key to present the next object.
24
August 2006
Developers guidelines | MMS
Tags used in MMS SMIL
Description
Support in Sony Ericsson phones
Optional tags for the sound played with a slide. There can be max 1 sound/melody per slide.
Yes
This tag can be left out completely if no sound should be played with the slide.
Note: The maximum number of objects in an MMS message depends on the device
The “src” file must be valid audio of a supported format. The optional “alt” attribute is used for alternative text. The optional “begin” attribute sets the delay after which the object should appear in the slide (value in ms or s, relative to slide start). The optional “end” attribute sets the moment at which the object should disappear (value in ms or s, relative to slide start). If the “end” attribute is omitted, the sound will continue to play on the successive slides. However, the receiving client may ignore the “begin” and “end” attributes, and for example prompt the user to press a phone key to present the next object.
25
August 2006
Developers guidelines | MMS
DRM DRM (Digital Rights Management) is a mechanism to limit distribution of media objects in MMS is an important requirement from content providers. A typical situation is when a user buys a background picture from a content provider. The content provider should be able to limit the possibility for the user to forward these pictures to other phones.
26
August 2006
Developers guidelines | MMS
Supported DRM MIME types Y = Yes, N = No, R =Receiving only
MIME
T68, T230, T290, T300, T310, J210, J220, J230, Z300
T610, T630, Z600
OMA DRM Forward-lock
application/vnd.oma.drm.message
N T230=R T290=R J210, J220, J230, Z300 =Y
R T610=N
Proprietary DRM
application/vnd.sem.mms. protected
R
R
Note: The SonyEricsson proprietary solution only differs from the OMA DRM Forward-lock in one aspect. The object wrapped inside the MIME type shall be WSP encoded instead of textual as in the standardized OMA solution. That is, the propriteray solution can be regarded as multipart/mixed with one object inside. Use the MIME type application/vnd.sem.mms.protected encoded as a multipart object with one object, and the WSP encoded object inside will be forward-locked when received in the SonyEricsson mobile phone.
27
August 2006
Developers guidelines | MMS
MMS in Sony Ericsson mobile phones The table below specifies MMS related features of the Sony Ericsson mobile phones in the scope of this document.
28
August 2006
Developers guidelines | MMS
Phone specifications T68, T300, T310
T230, T290
T610, T630, Z600
J210, J220, J230, Z300
Display size
101x80
101x80
128x160
128x128
MMS display size
101x80
101x80
128x141
128x110
Number of colors
256
4,096 T226: 512
65,536
65,536
Message size
255 kb
255 kb
255 kb
50 kb
Max number of objects
13
13
13
Limited by message size
Max size of text objects (characters)
1000
1000
1000
700
Supported MMS version
1.0
1.0
1.0
1.2
MMS templates Downloadable MMS-templates The Sony Ericsson MMS templates makes message creation easier and faster. An MMS template is a predefined multimedia message including subject, presentation information, texts and media files. It does not contain recipients and message options (expiry time and so on). MMS templates can be preloaded in the production and customization phases. Templates can also be downloaded via WAP/http or from a PC via Infrared or Bluetooth™. The user can add text and media to a pre-defined template, and the result will be a professionally designed slide presentation. Each template consists of: • A SMIL document that defines the message structure and referenced files. • One xml document (texts.xml) with the title of the template and the texts referenced by the SMIL document. • Zero or more images. • Zero or more melodies. • Zero or more audio files. All files are packaged into a single file archive (TAR). The archive must not contain any folders.
29
August 2006
Developers guidelines | MMS
Language dependant text files (texts.xml) Each text file has an entry in the texts.xml file. Each entry except the default entry, which is last, is identified with a ISO639 (http://www1.ics.uci.edu/pub/ietf/http/related/iso639.txt) language identifier. The "texts.xml" file must be saved as UTF8. UTF8 allows the file to contain ISO-10646 characters like Chinese, Russian, Hebrew, etc. All file names are case sensitive. Example: Titel åäö och presenterar i
Title and presents in
TAR All template files are packed into an archive using TAR (Tape Archive). The extension of the archive is .tpl.
30
August 2006
Developers guidelines | MMS
MIME type The MIME type for MMS templates is application/vnd.sonyericsson.mms-template.
MMS template downloading When a template file has been downloaded or beamed via Bluetooth or Infrared to the phone, all the files in the TAR archive are extracted into the MMS template folder. The TAR file itself is not stored in the phone.
31
August 2006
Developers guidelines | MMS
Related information Documents and links • MMS White Paper, EN/LZT 108 4963 (Sony Ericsson Developer World, http://www.sonyericsson.com/developer) • MMS Conformance Specifications (Sony Ericsson Developer World, http://www.sonyericsson.com/developer) • WAP-205: MMS architecture overview (http://www.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?DocName=/wap/wap-205-mmsarchoverview-20010425-a.pdf) • WAP-206: MMS client transactions (http://www.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?DocName=/wap/wap-206-mmsctr-20020115-a.pdf) • WAP-209-MMS, MMS Encapsulation proposed SCD (http://www.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?DocName=/wap/wap-209-mmsencapsulation-20020105-a.pdf) • World Wide Web Consortium (W3C): Synchronized Multimedia Integration Language (SMIL 2.0) Specification: W3C Working Draft 21 September 2000 (http://www.w3.org/TR/2000/WD-smil2020000921/) • The MIME Multipart/related content type, Levinson E., August 1998. • MIME Encapsulation of Aggregate Documents, such as HTML (MHTML), Palme J., Hopmann A., Shelness N., March 1999. • 8-bit single byte coded graphic character sets, Part 1: Latin Alphabet No. 1, ISO/IEC 8859-1:1998(E). • The Unicode Standard Version 3.0, The Unicode Consortium, Addison-Wesley, Reading (MA), January 2000. ISBN 0-201-61633-5. • Sony Ericsson Developer World (http://www.SonyEricsson.com/developer) - information, developer tools, documentation and software updates on mobility products and technologies; check frequently! • http://www.3gpp.org - the 3rd Generation Partnership Project • http://www.irda.org - the Infrared Data Association • http://www.w3c.org - the World Wide Web consortium • http://www.etsi.org - the European Telecommunications Standards Institute
32
August 2006
Developers guidelines | MMS
Index A architecture ........................................................... 9 assigned numbers .............................................. 17 audio MIME types ............................................... 16 B body .................................................................... 12 C configuration ....................................................... 10 content adaptation .............................................. 10 Content-ID .......................................................... 13 Content-Location ................................................ 13 Content-Type ...................................................... 12
U UAProf ................................................................ 10 User Agent Profile ............................................... 10 V vFormats ............................................................. 16 W WAP ...................................................................... 8 Wireless Application Protocol ............................... 8
D DRM .................................................................... 26 DRM MIME types ................................................ 27 E email ..................................................................... 9 encoding ............................................................. 12 Ericsson Themes ................................................ 17 executables, MIME types ................................... 17 H header ................................................................. 12 I IANA .................................................................... 17 image MIME types .............................................. 15 M message format .................................................. 11 message size ...................................................... 11 MMS body .......................................................... 12 MMS header ....................................................... 12 MMS Server .......................................................... 9 MMS supported MIME types .............................. 15 MMS template .............................................. 17, 29 O OTA configuration ............................................... 10 P phone specifications ........................................... 29 S SMIL .................................................................... 19 SMIL tags (sent messages) ................................. 21
33
August 2006
