The “Send MMS Message” web form allows you to define a subject, message text, and optionally include multiple content files (uploaded via the browser). Content files may include text files, audio files, image files, SMIL files, and/or other supported MMS content types. The gateway automatically compiles the MMS message file and uses the gateway’s built-in MMSC to send the message. An MMS message sent via this facility will be routed via the MMSC, and could either be delivered directly by the MMSC, or could be routed by the MMSC to an operator MMSC for delivery.
Note that this menu interface also allows for the sending of a pre-compiled MMS message file. If you are sending a pre-compiled MMS message file, that file should be submitted as the only content file for the message, and it should have a “.mms” file extension.
The web form allows you set some message attributes, and to specify Digital Rights Management (DRM) restrictions over the content of the message.
“Delivery Report” specifies whether or not a delivery report is requested for the message. Note that any delivery report would be directed back to the phone number or e-mail address specified in the “From” address.
“Read Report” specifies whether or not a read receipt is requested for the message. Note that the receiving client may choose not to send a read receipt. Any read receipt report would be directed back to the phone number or e-mail address specified in the “From” address.
“Priority” is a user defined priority to be associated with the message. Generally, any priority definition associated with the message is ignored by the underlying transport, but the receiving client may decide to display messages differently based upon this priority setting.
“Message Class” is an attribute defined in the MMS specifications. “Personal” is the message type that is used for standard user-to-user communications.
Digital Rights Management Options
When sending an MMS message via this interface, it is possible to specify Digital Rights Management (DRM) restrictions over the content of the message.
The most basic level of DRM is forward locking. When “Forward Lock” is set to “Yes”, this indicates that the receiving device should not allow any non-text objects in the message to be forwarded off of the device. The device may allow the user to extract pictures, videos or sounds from the message and save them on the phone. However, any such objects remain forward locked, such that they cannot be forwarded to another user or transferred to another device.
More advanced DRM restrictions can be applied to limit the number of times that the user can access an object, or start and end dates can be specified to limit how long the user can access an object.
These advanced DRM restrictions can be applied by setting “Restrict Content w/ DRM” to “Yes”. When this setting is enabled, forward lock is also implied, and the value of the “Forward Lock” setting is ignored.
“DRM Rights Format” specifies whether the DRM rights object should be encoded using a Text XML format, or a Binary WBXML format. While Binary WBXML format is always preferred for separate delivery objects, many Nokia phones only support Text XML format for the combined delivery process supported by this interface.
“DRM Permissions” specify what types of access are allowed against the object. For example, an audio or video object requires “Play” permission before the user can access it. An image requires “Display” permission before the user can access it, and it requires “Print” permission if the user is to be allowed to print the image to a printer , perhaps over Bluetooth. An application requires “Execute” permission before the user can make use of the application. In all cases, the forward locking is assumed, so that the user is not allowed to forward or transfer the object from the device.
If you are sending multiple types of objects in the MMS message, check all permissions that are required for the different types of objects that you are sending.
“DRM Constraints” specify constraints with regard to how long the object should remain accessible to the user. It is possible to specify one or more of these constraints.
“# of Accesses (count)” specifies the the user can only access the object this number of times before access is no longer allowed.
“Start Date (yyyy-mm-dd)” specifies that the user will not be allowed to access the object until on or after the specified date. (Note that you must specify the date in yyyy-mm-dd format, e.g., 2006-02-24.)
“End Date (yyyy-mm-dd)” specifies that the user will not be allowed to access the object after the specified date. (Note that you must specify the date in yyyy-mm-dd format, e.g., 2006-02-24.)
“# of Days (interval)” specifies that the user will be allowed to access the object for this number of days after initial receipt of the object. The user can either enter a number of days here, or they can enter any valid value defined for the “<interval>” element in the OMA DRM Rights Expression Language specification. For example, P2Y10M15DT10H30M20S represents a duration of 2 years, 10 months, 15 days, 10 hours, 30 minutes and 20 seconds.
For additional information on DRM Restrictions, please see Digital Rights Management on page 320.
The “Additional Headers” option allows additional headers defined by the MMS Encapsulation Specification (MM1) to be inserted into the resulting MMS message. These MMS headers should be specified in a text format, such as:
Note that NowSMS will filter headers that are actually included in the MMS message based upon the resulting MMS message and delivery method. When NowSMS is configured for direct delivery as an MMSC, it is possible to specify any MMS headers that are valid for either an M-Notification.ind or M-Retrieve.conf PDU, and NowSMS will include the headers in the resulting PDUs as appropriate. When NowSMS is routing MMS messages to an operator MMSC via a GPRS modem, it is possible to specify any MMS headers that are valid for an M-Send.req PDU.