|Send MMS picture message with PHP?||Search|
|SMS & MMS Technical Forum » NowSMS Support - MMS & Advanced Issues (Product Support Only) » Archive through July 07, 2009 » Send MMS picture message with PHP?||« Previous || Next »|
Post Number: 2
I found this guide that explains how to process a received MMS message with a PHP script:
It looks complicated. I plan to try it.
But my first need is not to receive MMS messages, it is for to send them.
If it is possible to receive, then it must be possible to send. How do I write a PHP script to send an MMS message?
|Des - NowSMS Support
Post Number: 229
Processing a received MMS message with the PHP script in the example is not as difficult as you might think. There is just a lot of detail in that link that you reference.
The example script processes the pieces of the received MMS message and builds a web page log of received messages.
I guess it's a little confusing because it creates a separate log for every different phone number that sends in an MMS message.
We run the script on an IIS server. c:\upload is a virtual directory for the web server, and IIS is configured to show a directory list of that directory.
Under that directory, you have subdirectories with phone numbers (e.g., +44777777777). Each of those subdirectories has an index.html that is a web page log of all MMS messages received from that phone number. So essentially, it works like a simple mobile MMS blog. You send MMS messages into the script, and it generates a very simply blog of these messages.
What you do with the received messages would depend on what you're trying to accomplish.
But we figured that we get lots of questions about MMS blogging, and that made for a good simple example.
Give the script a try, and if you have any problems/questions about it, I'll try to help you out. Usually the only thing you have to do is make sure that your script has write access to whatever directory that is hard coded in the script.
Post Number: 3
Hi again Des!
Thank you for the fast reply!
That is very interesting information.
But how do I send an MMS message from a PHP script? Or can I only receive an MMS message?
|Des - NowSMS Support
Post Number: 230
Sigh. Serves me right for having a pint at lunchtime. I guess I did not read your question completely.
There's an example PHP script for sending an MMS message at http://www.nowsms.com/discus/messages/1/1113.html.
That script is about 5 years old, and it works, but it is a little more confusing than it needs to be.
So I've taken the liberty of updating that script to 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 those who are 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 (mostly copy & paste from the NowSMS manual reference for URL parameters).
"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.
|Kate Sarah Boxwell
Post Number: 1