| CONTENTURLTYPE |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - MMS & Advanced Issues ⬆ Archive through October 14, 2015 ⬆ |
◄ ► |
| Author | Message | |||
| sam Frequent Contributor Username: Samdsouza Post Number: 132 Registered: 08-2006 |
Hi Des When i am sending Wap Multimedia Message with Forward Lock and/or Restrict Content w/ DRM flaged as YES then the image/content is not getting displayed. Also below the "Download File image.jpg.dm i get "(@@CONTENTURLTYPE@@)". Is this some kind of issue with the web interface? Also I tested the Send MMS Message.htm and the precompiled .mms file is being sent as a link similar to send multimedia message. Is there any web interface to send pure MMS to a mobile handset which is using NowSMS as its MMS server? Kindly do let me know Thanks Sam | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4400 Registered: 08-2008 |
Hi Sam, I'm not sure that there's any good way to handle this type of content. We will fix the problem so that the actual content type is displayed instead of @@CONTENTTYPEURL@@ ... however it would seem that presenting the content to the end user to download in protected format is of no real world use unless the recipient has an app on the phone that can do something with it. For the other issue, I don't see any problems sending a pre-compiled MMS file out via MMS or having it converted to web linked format properly. The only issue I am aware of is that such a file must have a ".mms" file extension. -- Des NowSMS Support | |||
| sam Frequent Contributor Username: Samdsouza Post Number: 133 Registered: 08-2006 |
Hi Des Thanks for your valuable inputs. Its highly appreciated. So that means Forward Lock and/or DRM settings wont work with the "web linked multimedia" message right? Will it work with the "MMS message" page? Kindly do let me know. When i send a precomplied MMS with a .mms extension via Send MMS Message.htm i get the web link. Not the pure MMS delivered on the handset. Is this the way this is supposed to work? How do i deliver MMS directly on the handset using the web interface? Also the developer options in web interface settings is not working properly. Even with this setting enabled it doesnt show the developer options. Thanks once again. Sam | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4408 Registered: 08-2008 |
Hi Sam, I need more specific information to understand.
Forward lock and/or DRM settings will not work with "web linked multimedia". It will work if you send as an MMS message, provided that the client supports it. The OMA DRM standard was a good attempt at standards based DRM for mobile devices. Nokia implemented in Symbian devices. SonyEricsson also implemented support in some of their devices. However, the standard was never embraced by Google or Apple, so those DRM functions do not work with Android or iPhone. As a result, in the real world, the DRM functionality is of limited, if any, use.
And if your content is something other that a precompiled MMS, then it works properly and goes out as an MMS message? I do not understand why that would be. Or are you saying that all content from "Send MMS Message" goes out as "web linked multimedia"? Depending on your configuration, that may be. It depends on what your default MMSC routing is ... if it is convert to web link, then it will be converted.
How so? What is missing? There are system-wide restrictions and user account based restrictions. Perhaps you are seeing user account based restrictions (any restriction on message types disables developer options for that user account). -- Des NowSMS Support | |||
| sam Frequent Contributor Username: Samdsouza Post Number: 134 Registered: 08-2006 |
Hi Des Thanks for your time on this. Regarding my points: 1. DRM Without Android support OMA DRM standard wont work out. How about NowSMS handling this stuff. For example the following settings: # of Accesses (count): NowSMS keeps the number of counts and then deletes the mms url from the NowSMS server. Start Date (yyyy-mm-dd): NowSMS keeps a tab/synchronises with the server time for the start date. End Date (yyyy-mm-dd):NowSMS keeps a tab/synchronises with the server time for the end date and then deltes the mms url/content form the nowsms server. # of Days (interval):NowSMS keeps the interval counts and then deletes the mms url from the NowSMS server. If the above happens then the content can be protected to some extent without the OMA DRM standard without the need of Forward Lock settings. Also if there would be anyway of capturing the users mobile number then you can control the content to a large extent....like bind the mobile number to the content..so if i am sending it to a particular number that numbers handset can only access the content... 2. Yes ..was the default route issue...thanks.... 3. user account based restrictions..yes that was it....thanks for that..... 4. One more query. When am sending a MMS notification the message does get delivered to the android handset....displays on the lock screen as "hidden sender address" but when i click on the sms inbox the message disappears....and no content is downloaded on the handset. Kindly do let me know. Thanks Sam | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4423 Registered: 08-2008 |
Hi Sam, 1. That is an interesting idea. For now, the setting described in the following link may be of interest to you: http://support.nowsms.com/discus/messages/1/11180.html 4. Is the content valid MMS format? How did you generate the MMS content? -- Des NowSMS Support | |||
| sam Frequent Contributor Username: Samdsouza Post Number: 135 Registered: 08-2006 |
Hi Des Thanks for your reply. Regarding the points: 1. ExpireDynamicLinks Have checked that settings...its very useful but not as affective as the DRM settings. This would be useful in global settings. But for individual mms sends the settings which i have mentioned would be useful. In short i think that the settings need to be applied per batch or per mms sends. The start date and end date logic can be integrated with ExpireDynamicLinks settings....the Accesses (count) and Days (interval) would need to be integrated as a setting. 2. MMS notification I tried sending the precomplied MMS from mmssamples.zip which is mentioned in one of the threads...i even tried sending a precomplied MMS genereated on the NowSMS server but both had the same results..i didnt use the "Additional Headers" settings/paramter while sending the notification.... Kindly let me know Thanks Sam | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4445 Registered: 08-2008 |
Hi Sam, 1. Variations on this idea will be looked into for the future. 2. Are you just putting the file on a web server somewhere? (I assume you have never used NowSMS as a direct delivery MMSC.) Does your mobile operator use a separate APN for MMS? If so, off network MMS is effectively blocked unless you change APN settings ... the notification will go to the device but the actual MMS content will be unreachable. (http://www.nowsms.com/howmmsworks.htm) Check your web server logs to see if the content is even being fetched ... NowSMS does fetch it to validate MIME type when submitting, but you'd see a second access from the phone itself, if the MMS APN allows. -- Des NowSMS Support | |||
| sam Frequent Contributor Username: Samdsouza Post Number: 136 Registered: 08-2006 |
Hi Des Thanks for your reply. This sounds idiotic but what is the difference between sending a MMS message and a MMS notification? Both kinda look the same for me the only difference i find that in MMS notification the mms content has to e precompiled in a .mms extension on any server...and in send mms message thing the .mms is stored on the NowSMS server. Is that the only difference? Regarding the issue no. 2 Are you just putting the file on a web server somewhere? Yes. and MIME type has been configured properly for .mms extension. And the mms notifcation gets submitted properly and is processed properly by NowSMS. I assume you have never used NowSMS as a direct delivery MMSC I tested the mms notification both the ways. Using NowSMS as direct delivery MMSC and other with the mobile operator MMSC. I found excat same behaviour. Does your mobile operator use a separate APN for MMS? If so, off network MMS is effectively blocked unless you change APN settings ... the notification will go to the device but the actual MMS content will be unreachable. (http://www.nowsms.com/howmmsworks.htm) The operator allows off network MMS. Also as i mentioned i saw the same behviour on the handset which used NowSMS as the MMSC. Check your web server logs to see if the content is even being fetched ... NowSMS does fetch it to validate MIME type when submitting, but you'd see a second access from the phone itself, if the MMS APN allows. NowSMS fetches the content properly while submitting. But the server logs dont show the content being fetched. Any reason why the content would not be fetched? Kindly let me know Sam | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4447 Registered: 08-2008 |
Hi Sam, It sounds like the operator uses a separate APN for MMS and effectively blocks off-network MMS. What I call an MMS "ghost message" on an Android device occurs when the device receives an MMS notification but is unable to access the content. (You see "hidden sender address", but in my tests I always see a real sender address.) This happens because the handset receives the MMS notification but cannot access the MMS content URL. It's easy to recreate this in an otherwise working environment by simply turning data access off on an Android phone. MMS notifications are sent via SMS, the phone then uses data to fetch the MMS content from a URL specified in the MMS notification. (This is described in more detail at http://www.nowsms.com/howmmsworks.htm) When you send an MMS message, the MMS content URL included in the MMS notification is dynamically generated by the MMSC, using the host name configured for the MMSC and the HTTP port number for the MMSC. The receiving device fetches the URL to complete the MMS delivery process. The receiving device must be able to access the MMS content URL to complete the delivery process. So generally speaking, it must be accessible over the internet. But then there is the issue of separate APNs for MMS. The reason for this is because many operators do not charge for data related to MMS, but only per message. (Some charge for both.) If they are not charging for data on MMS, then their MMS APN is locked down to prevent external access, meaning that MMS can only be delivered via the operator MMSC. (It is also possible that even when the same APN is used for normal data and MMS, the operator could block MMS content from other than their MMSC for security reasons. We've never seen this, but in this case, you would normally see an attempted GET of the content URL in your logs.) This is the part that puzzles me:
Can that handset send an MMS message to itself using NowSMS as the MMSC? If it can post a message to the MMSC but not retrieve it, does the host name in the MMS Server URL match the host name configured on the MMSC itself? -- Des NowSMS Support | |||
| sam Frequent Contributor Username: Samdsouza Post Number: 138 Registered: 08-2006 |
Hi Des You were right about operator MMSC. I got confused with the settings on the handset. It works as you have mentioned. So MMS notification would only work if NowSMS is used as an MMSC on the handset. Thanks for your time on this. Highly appreciated. Regards Sam | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4467 Registered: 08-2008 |
Hi Sam, Yes, MMS notification will only work if the MMS APN setting in the handset allows access to external MMSC URLs. -- Des NowSMS Support | |||
| sam Frequent Contributor Username: Samdsouza Post Number: 147 Registered: 08-2006 |
Hi Des Possible to get this looked into: ExpireDynamicLinks Have checked that settings...its very useful but not as affective as the DRM settings. This would be useful in global settings. But for individual mms sends the settings which i have mentioned would be useful. In short i think that the settings need to be applied per batch or per mms sends. The start date and end date logic can be integrated with ExpireDynamicLinks settings....the Accesses (count) and Days (interval) would need to be integrated as a setting. Need this to get started with the client. Kindly let me know Regards Sam | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4491 Registered: 08-2008 |
Hi Sam, We could possibly add a configurable expiration per message, relative to submit time, or relative to first open. But it requires more discussion and analysis. The other parameters are interesting, but add significant complexity and relatively little value. I would caution, however, that quickly expiring the content does not prevent a smartphone from saving a copy of content that is displayed. We can only invalidate/expire the link from which the content is served. With that consideration, I am not sure that this would meet typical DRM concerns. -- Des NowSMS Support | |||
| sam Frequent Contributor Username: Samdsouza Post Number: 153 Registered: 08-2006 |
Hi Des Thanks for your reply. I belive following two settings sounds doable right: "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.) Above 2 settings would also be fine to start off with..... Following two parameters are complex right: "# of Accesses (count)" specifies the the user can only access the object this number of times before access is no longer allowed. "# 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. If the above 2 settings happens then the content can be protected to some extent without the OMA DRM standard without the need of Forward Lock settings. Regarding this point of yours "I would caution, however, that quickly expiring the content does not prevent a smartphone from saving a copy of content that is displayed. We can only invalidate/expire the link from which the content is served." Agreed. How about using a javascript to disable right click save option in the templates stored in the mmssms folder? This way atleast the user cannot save on his mobile directly......atleast for the multimedia sends... Also how about allowing browers to access the content only from mobile devices...capture the header value of the incomming request...if its a mobile request allow it...if its a non mobile (PC) request disallow it...this can futher protect the content.... Regarding this point of yours "With that consideration, I am not sure that this would meet typical DRM concerns. " Agreed here also. But atleast there is some kind of DRM for the sends and the content provider can protect to some extent..this would be very helpful...the other option is that there is no DRM protection at all.... Awaiting your inputs Regards Sam | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4493 Registered: 08-2008 |
Hi Sam, This quickly becomes more and more complicated. Unfortunately the disable right click Javascript has no effect on iPhone or Android. There do appear to be alternatives for both of those platforms ... the iPhone logic is pretty straight-forward ... add style="-webkit-touch-callout: none;" to the body attribute. Android is more complicated ... a good start is probably here: http://stackoverflow.com/questions/3413683/disabling-the-context-menu-on-long-ta ps-on-android After doing this and adding the JavaScript right-click flag, we have to either remove the "click for full size" or change how that works. Right now we link directly to the image, so the image would have to be in an HTML wrapper with Javascript and the iPhone CSS. Assuming we've made it this far, the one thing we can't prevent is doing a screen capture on the device, which is quite easy. My concern is that there are other considerations than just expiring the content at the server. The biggest hurdle I see is changing how that "Click for full size" option works. -- Des NowSMS Support | |||
| sam Frequent Contributor Username: Samdsouza Post Number: 155 Registered: 08-2006 |
Hi Des Thanks for your inputs. Highly appreciated. Regarding the right click disable if those are the issues lets ignore that point. I mean the content can be saved if the user wishes so. Or the user can just open the URL in a PC browser or forward the SMS to another mobile number. So if that cant be stopped then from a content providers viewpoint can we do the following: "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.) This is not mandatory but would help if present. "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.) This would be required as the content might be time specific. The content might be required/useful till a specific date or after a specific date that content would no longer be valid. Similar to ExpireDynamicLinks settings. "# of Accesses (count)" specifies the the user can only access the object this number of times before access is no longer allowed. Lets say there is a bulk content push to 100 users. It is possible that the download of content is restricted to 100 hits only? Or this is not worthwhile cause a valid mobile receipient might like to access the content more then 1 time? "# 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. This sounds similar to end date setting but based on the number of days right? Would be useful but not mandatory if the other setting is done. My concern is that you cant bind the content to a specific mobile number. There is no way to collect the mobile number of the user who is accessing the content. So the user can easily forward the dynamic URL to any other mobile and that other mobile can access the content. The way out might be that the content URL be different for each and every user. Lets say there is a bulk content push to 100 users. then 100 urls (pointing to the same content) are generated and sent to this 100 numbers. Once the specific URL is retrieved then that URL is expired. So nobody can access the URL. So even if the user forwards the URL it wont display the content. Does this sound logical? Need some kind of DRM for the sends and the content provider can protect the content to some extent..this would be very helpful...the other option is that there is no DRM protection at all.... Kindly let me know your views. Sam | |||
| sam Frequent Contributor Username: Samdsouza Post Number: 156 Registered: 08-2006 |
Regarding the dynamic URL generation for all mobile numbers. If this can be done then NowSMS can generate a Read Report for the web multimedia sends also as the URL would be unique for the specific mobile number | |||
| sam Frequent Contributor Username: Samdsouza Post Number: 160 Registered: 08-2006 |
Hi Des I had a word with the client on this and regarding your point "My concern is that there are other considerations than just expiring the content at the server. " I agree that the user can save the content on his smart phone and then can forward that content. The client is ok with that as that requires some kind of effort from the user. He would need to save the content and then attatch it and then send via emial/mms. The clients main concern is that the user should be able to forward the SMS to other users. This is very easy for the user to do it via SMS. And the person who gets the forwarded SMS can very easily download the mms content via the link. Possible to get the dynamic+individual URL done for each mms sends? Kindly let me know Thanks Sam | |||
