Continuing our series of PHP examples, today we’ll revisit sendmms.php, which we originally published on our discussion board 5 years ago at http://www.nowsms.com/discus/messages/1/1113.html.
The sendmms.php script is considerably more complex than the sendsms.php script. The reason for this increased complexity is because an MMS message is more complex than an SMS message.
However, I have to admit that our 5 year old example can be a little difficult to follow. Over the years, I’ve answered quite a few questions about the script, as the way that you specify the files to include in the MMS message is a little confusing.
So in this posting, we’ll update sendmms.php, and make it a little easier to follow.
The updated sendmms.php can be downloaded at http://www.nowsms.com/download/sendmms-php.txt.
The first part of sendmms.php consists of PHP functions that you will call in your PHP script … namely MmsInit, MmsAddField, MmsAddFile and MmsSend. Include these functions in your script without editing them.
After these functions are defined, sendmms.php contains a simple example showing how to use these functions to send an MMS message through a NowSMS server.
1.) First, you need to initialise the parameters to point to your NowSMS server:
/* Set parameters for connecting to the NowSMS server */
$nowsmsHostName = “127.0.0.1”; /* IP Address or host name of NowSMS Server */
$nowsmsHostPort = “8800”; /* NowSMS Port number for the web interface */
$nowsmsUsername = “test”; /* “SMS Users” account name */
$nowsmsPassword = “test”; /* “SMS Users” account password */
2.) Second, you need to call MmsInit to initialise the MMS message structure.
$mmsMessage = MmsInit();
3.) Third, you need to add the necessary MMS header fields and attributes desired for your MMS message, calling the MmsAddField fuction.
$mmsMessage = MmsAddField ($mmsMessage, “PhoneNumber”, “+447777777777”);
$mmsMessage = MmsAddField ($mmsMessage, “MMSFrom”, “firstname.lastname@example.org”);
$mmsMessage = MmsAddField ($mmsMessage, “MMSSubject”, “Subject of Message”);
The “PhoneNumber” field specifies the recipient(s) for the MMS message. This can be a comma delimited list of phone numbers, or it can be the name of a NowSMS distribution list.
The “MMSFrom” field specfies the sender of the MMS message. Normally, this would be a phone number, short code or e-mail address. (And your MMS service provider may either require a specific value here, or they may overwrite the value you supply with the address associated with your service.)
The “MMSSubject” field specifies the subject of the MMS message.
Those are the most common MMS header fields. Optionally, you might also want to include an “MMSText” field to specify some text to be included in the MMS message. Text can also be included in an MMS message as a text file reference.
4.) Fourth, you specify the files to include in the MMS message using the MmsAddFile function. These files might be images, video, text, or other file types supported by the receiving device.
$mmsMessage = MmsAddFile ($mmsMessage, “f:\\temp\\filename.gif”, “image/gif”);
An MMS message can contain one or more of these included files. If you do not include a SMIL file component, NowSMS will build one automatically, so for full control of the MMS message presentation, you will want to include your own SMIL file, where you reference your file components by their short filename (without the full path, e.g., filename.gif … NOT f:\temp\filename.gif).
The files referenced in the PHP script must be local files, residing on the same server as the PHP script. Remember to escape backslashes in the path so as not to confuse the PHP interpreter(c:\temp\file becomes c:\\temp\\file).
The last parameter of MmsAddFile is the MIME content type, e.g., “image/gif”, “image/jpeg”, “image/png”, “text/plain” or “application/smil” … however, note that current versions of NowSMS ignore the MIME content type when messages are submitted via the interface used by this PHP script. Instead, NowSMS uses the file extension to determine the content type (e.g., “.gif”, “.jpg”, “.png”, “.txt”, “.smil”).
5.) Fifth and finally, you call MmsSend to submit the MMS message.
MmsSend ($nowsmsHostName, $nowsmsHostPort, $nowsmsUsername, $nowsmsPassword, $mmsMessage);
Those are the basics.
For the curious, the MmsAddField function can be used to specify any NowSMS URL parameter that is valid for sending an MMS message.
For example … here is an incomplete list of additional parameter fields that can be specfied using the MmsAddField function.
“MMSFile” – As I’ve noted above, this script attaches local files to the MMS message. However, what if you want to include files that reside on a separate web server instead? In that case, do not use the MmsAddFile function. Instead, use $mmsMessage = MmsAddField ($mmsMessage, “MMSFile”, “http://www.nowsms.com/media/logo.png” ); and specify the file components as URL references via the “MMSFile” parameter field.
“MMSDeliveryReport” – “Delivery Report” specifies whether or not a delivery report is requested for the message. Set to “Yes” to request a delivery report. Note that any delivery report would be directed back to the phone number or e-mail address specified in the “MMSFrom” address.
“MMSReadReport” – “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 “MMSFrom” address.
“MMSPriority” – “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.
“MMSMessageClass” – “Message Class” is an attribute defined in the MMS specifications. “Personal” is the message type that is used for standard user-to-user communications. Other defined message classes that are supported by this parameter include: “Informational” and “Advertisement”.
“MMSWAPPush” – Set to “Yes” to indicate that the message being sent should be sent as an “Multimedia WAP Push” message instead of as an MMS message.
It is also possible to specify forward locking and DRM constraints to be applied against the content of the MMS message. Forward locking and DRM constraints apply to non-text parts of the MMS message (i.e., in a forward locked message, text could still be forwarded, but images or video could not). Please note that not all devices support forward locking and DRM constraints, therefore use these parameter settings only after testing thoroughly with mobile phones used by your message recipients.
“MMSForwardLock” – Forward locking is the most basic level of DRM (Digital Rights Management). 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. (IMPORTANT NOTE: NOT ALL DEVICES SUPPORT FORWARD LOCK, WHEN NOT SUPPORTED THE CONTENT WILL APPEAR AS GARBAGE OR MAY BE REJECTED BY THE OPERATOR MMSC.)
“DRMRestrict” – Beyond forward locking, More advanced DRM (Digital Rights Management) 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 “DRMRestrict” to “Yes”. When this setting is enabled, forward lock is also implied, and the value of the “MMSForwardLock” setting is ignored. (IMPORTANT NOTE: NOT ALL DEVICES SUPPORT DRM RESTRICTIONS, WHEN NOT SUPPORTED THE CONTENT WILL APPEAR AS GARBAGE OR MAY BE REJECTED BY THE OPERATOR MMSC.)
“DRMRestrictTextXML” – “Yes” specifies that the rights object should be encoded in text XML format. “No” specfies that the rights object should be encoded in binary XML format. The default is “No”.
When DRM Restrictions are specfied, it is generally necessary to specify one or more DRM Permissions and one or more DRM Constraints regarding the MMS message content.
DRM Permissions specify what types of access are allowed against the objects in a message that is protected with DRM.
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, specify all permissions that are required for the different types of objects that are being sent.
“DRMPermissionPlay” – Set to “Yes” to enable DRM “Play” Permission.
“DRMPermissionDisplay” – Set to “Yes” to enable DRM “Display” Permission.
“DRMPermissionExecute” – Set to “Yes” to enable DRM “Execute” Permission.
“DRMPermissionPrint” – Set to “Yes” to enable DRM “Print” Permission.
DRM Constraints specify constraints with regard to how long a DRM protected object object should remain accessible to the user.
“DRMConstraintCount” – “# of Accesses (count)” specifies the the user can only access the DRM protected object this number of times before access is no longer allowed.
“DRMConstraintStart” – “Start Date (yyyy-mm-dd)” specifies that the user will not be allowed to access the DRM protected object until on or after the specified date. (Note that you must specify the date in yyyy-mm-dd format, e.g., 2008-12-24.)
“DRMConstraintEnd” – “End Date (yyyy-mm-dd)” specifies that the user will not be allowed to access the DRM protected object after the specified date. (Note that you must specify the date in yyyy-mm-dd format, e.g., 2008-02-24.)
“DRMConstraintInterval” – “# of Days (interval)” specifies that the user will be allowed to access the DRM protected 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 “” 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 comments and further discussion, please click here to visit the NowSMS Technical Forums (Discussion Board)...