| DRM wrapper |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - MMS & Advanced Issues ⬆ Archive through July 14, 2004 ⬆ |
◄ ► |
| Author | Message | |||
| Lars Nielsen, MobileNation ApS - Denmark New member Username: Larsmservice Post Number: 31 Registered: 10-2003 |
Hi. I LOVE the Multimedia Wap Push with Forward-Lock  . It got me thinking of another way of running this via nowsms, and i hope you take it seriously Bryce... The way it works today is that now sms creates everything needed and sends a wappush to the recipient. That's great... But not enough;-) This here could be great: MyWebServer sends a GET request to now sms, telling it to create a multimedia wappush with forward lock. It also sends the HTTP URL to the content which needs to be wrapped into DRM. Nowsms would now do the work and send a wappush to the recipient. But i want this: Instead of sending a wappush, nowsms should return an answer back the MyWebServer with an URL the the DRM-wrapped content. Returning an answer from a GET is just to do some Document.write etc.etc. MyWebServer would now be able to create a download system or other stuff etc. etc. Was this too much Bryce ? Can you see what i mean ? ;)Lars | |||
| Lars Nielsen, MobileNation ApS - Denmark New member Username: Larsmservice Post Number: 32 Registered: 10-2003 |
Actually this would be very usefull if you, like we have, has a wappage where we find out about the phone that enters. Does it support DRM or not. If yes, we can send the DRM-wrapped content, and if not we can deliver the content without DRM. Another issue is that wap portals are really going big time right now. And when buying content on a wapportal, wappush is not needed. So when a user wishes to download content on the portal, we can just tell nowsms to create DRM-wrapping, nowsms returns the URL, and we can lead the user to the content. ;)Lars | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 2628 Registered: 10-2002 |
Lars, I like the idea. But I think if we were to implement it, I would do it a little differently. I'm concerned that some mobile phones are going to require the boundary parameter to be present. So rather than just returning the DRM wrapped content back to the application, I'd like to be able to return the full header, so that we could include the boundary in the content-type header. I'd imagine that the content server would include a link like this: http://nowsmsip:port/fowardlock?http://server:port/path/filename.ext NowSMS could fetch the content, and return it back with a DRM wrapper. In fact, we could even detect an older phone that has the SonyEricsson proprietary forward lock support, and use that as an alternative. But I guess what you would lose with that approach is the dynamic URL generation, as that part of things can also be quite useful. So perhaps another alternative could exist for that option ... http://nowsmsip:port/fowardlockurl?http://server:port/path/filename.ext NowSMS would still fetch the URL, and create the wrapper, but it would return a redirect ("Location:" header) response with a dynamic URL generated on the NowSMS server, instead of returning the content directly. The idea behind this latter approach is that these requests would most likely be generated by an application server, rather than as a link in a web/WAP page. The web server would send the GET request to NowSMS, and NowSMS would return a dynamically generated URL link in the Location header. So the web server could parse that dynamically generated URL and include it in its page. What do you think? | |||
| Lars Nielsen, MobileNation ApS - Denmark New member Username: Larsmservice Post Number: 34 Registered: 10-2003 |
The idea is great Bryce. Is it ready tomorrow ;-) As i see it we are moving nowsms over to be more than it might have started out to be. Now we are almost moving it towards being a wap-server/gateway. In order to explain my problem i need to show you what happends when a user orders content in our system. There are two scenarios; 1 is a wap push and the other is when ordering content from a wap-portal. 1. The wap push. A user orders a wallpaper by sending a sms to us. We create a wml page with a link to the content. Now we tell nowsms to send a wappush to the user. The user enters the page where there is a link to the content. Very simple so far. But when the user hits the page, we do some advanced stuff so we can deliver the content correctly. First of all we look at the useragent data. Now we can find out if the phone supports DRM, and via our own developed phone-catalogue, we find out how the wallpaper should be delivered(gif/jpg/etc.) and the screensize. The user presses the link to the content, which really is an .asp file. This file does the converting and delivers by doing a response.binarywrite and so on. We do have a BIG problem on this system. The sonyericsson T68i does not accept the asp page that delivers the actual content, so instead we create a gif file physically. That's about it. Our system has taken a long time to develop, and is constantly being developed on. Nowsms is actually able to do a lot of these steps, but not all of them. If it was able to do all of them, many developers would scream happily for nowsms ;-) This is how i would like nowsms to work on these kind of orders: We tell nowsms to send a multimedia wappush to the user. At the same time we tell nowsms where it should fetch the content. Nowsms downloads the content, and waits for the user to enter the dynamically created WMLpage. When the user enters the page, nowsms looks in the useragent-data to see if the phone supports DRM or not. And via this it creates a copy of the content, or a DRM wrapped copy of the content. That's about it. What's your oppinion on this Bryce ? Too much for nowsms or is this the direction you guys would like nowmsms to go ? Now for the other version where the user orders in a wap session. Wap portals are getting very big now, and they are going to get much bigger. We have built two portals in Denmark for two different phonecompanies, so we know quite a bit about how much money investors are putting into it. A user sees a wallpaper on the portal that user wishes to download. The user presses the download link, and here is what should be happening in our server with nowsms installed ;-) The user presses the link. We send a GET to nowsms with information regarding the content and the URL to the content. Nowsms downloads the content, and answers back to the GET request with an url to a WML page on the nowsms server. We redirect the user to the nowsms-wml-page, and nowsms takes a look at the useragent-data, and via that creates a copy of the content, or a DRM wrapped copy of the content. In the header of the nowsms-wml-page there is a location: tha redirects to the content, so that after the user has downloaded the content, the user is redirected back to the portal. This could also be solved by telling nowsms in the first GET where the user should be redirected to after the download is complete. WHOA! That was actually it. I have only a few things left. If we were to use the geniously developed Multimedia WapPush in all our solutions, we would need to bee able to decide 100% how the wml page should look like. That could be solved by having templates installed in a subfolder under \nowsms\. Another thing i noticed is that the .ini file you create changes the status from pending to Delivered. Are we able to tell the system that the user can only download the content if status=pending, and if status=delivered, then the user should not be able to download ??? Finally we have some problems redirecting with sonyericsson t68i and T610. Does this have anything with what you wrote below ? Thankyou Bryce for a great software that really has done wonderfull things for our company. We have become one of the leading mobile developer companies in Denmark with the largest customers contacting us for solutions. And nowsms is almost allways there in our solutions. You Wrote:"In fact, we could even detect an older phone that has the SonyEricsson proprietary forward lock support, and use that as an alternative." Could you please explain this ??? | |||
| Lars Nielsen, MobileNation ApS - Denmark New member Username: Larsmservice Post Number: 43 Registered: 10-2003 |
Was my last thread too long ? No one wants to answer me these very very very important questions Or is it just little me that thinks this could be the most important upgrade for the nowsms software... Just to be sure, here is the most important lines in my thread above (a bit rewritten): Now for the other version where the user orders in a wap session. A user sees a wallpaper on the portal that user wishes to download. The user presses the download link, and here is what should be happening in our server with nowsms installed ;-) The user presses the link. We send a GET to nowsms with information regarding the content and the URL to the content + we tell nowsms to DRM-wrap it or not. Nowsms downloads the content, and answers back to the GET request with an url to a WML page on the nowsms server. We redirect the user to the nowsms-wml-page, and nowsms takes a look at the useragent-data, and via that creates a copy of the content. In the header of the nowsms-wml-page there is a location: tha redirects to the content, so that after the user has downloaded the content, the user is redirected back to the portal. This could also be solved by telling nowsms in the first GET where the user should be redirected to after the download is complete. ;)Lars | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 2804 Registered: 10-2002 |
Hi Lars, Let's see where to start ... I've been thinking a lot about DRM. The issue is really how to handle forward lock for older devices that don't support DRM. Do you go ahead and allow the user access to the content (and accept that the user might be able to forward it), or do you return an error message? At present, we just present the forward-lock content, and an older phone will not understand it. I wouldn't see a problem with adding an option to strip the forward lock if the receiving device did not support that attribute. (This would not be a default setting, but I can see where many content providers would opt for this as a "practical" solution.) Regarding my statement:
Ignore this statement. SonyEricsson has implemented a proprietary header for forward-lock of an MMS message in all of their phones. I was thinking that we could conceivably convert OMA DRM to this format if appropriate ... but if we did this is something that could only apply to MMS content, not WAP push content. So I don't think this is at all related to any redirect issues you are having with some SE devices.
To be honest, we're going in a lot of directions simultaneously. We need to put up a "solutions" page that gives ideas of different ways that customers are using NowSMS. Basically, we've got implmentations of a lot of different SMS, MMS and WAP related technologies inside of NowSMS. And we're always looking for different ways to put them to use. Sometimes the practical implementation of the technology is different from the way that it was originally envisioned.
That's an interesting point. We could have had the content retrieval engine look directly at this INI file in order to determine whether or not to serve up the content. We didn't do it that way. Instead, we allow you to set an ExpireDynamicLinks=## parameter in MMSC.INI (under the [MMSC] header), where ## is the number of minutes after the link is first accessed before it should be automatically deleted. This setting applies to both MMS messages and multimedia WAP push. So, it's not quite real time.
The handling of the redirect links is the only bit that really requires some thought for how it is implemented. (Well, it all requires thought, but that is the bit that gives me the most pause.) Here's what I'm thinking... We implement a variation on the MM WAP Push where instead of sending out a push (and the "Message Submitted" response, we send back a response with a redirect ("Location:") header pointing to the WML file that was generated. We also add additional parameters that can be specified in the request that generates the MM WAP Push. We add a "MMWAPTemplate" parameter that tells us which template to use. And then we add support for parsing additional "MMWAPTemplate-xxx" parameters, where we look for "@@xxx@@" in the template file, and replace it with the value by this parameter. (This could be used to handle your requirement of specifying where to send the user next.) Thoughts? (Aside from asking if its done yet.  ) | |||
| Lars Nielsen, MobileNation ApS - Denmark New member Username: Larsmservice Post Number: 59 Registered: 10-2003 |
Hi Bryce. First of all. Thanx for replying on my sometimes very long threads in here. Do you go ahead and allow the user access to the content (and accept that the user might be able to forward it), or do you return an error message? No. We dont use nowsms for that. Instead we use our own system, but would like to use nowsms. Here's how it's done. The user hits the wml page which actually is a .asp file. We look at the useragent, and find out which phone it is. We look in our own-develope phone database to see if that phone supports DRM. If true, we wrap the content in DRM and redirects the user to the content via a href= and so on... I wouldn't see a problem with adding an option to strip the forward lock if the receiving device did not support that attribute. (This would not be a default setting, but I can see where many content providers would opt for this as a "practical" solution.) That would be perfect. When the user hits your multimedia wap push wml page, you look at the phone and do the DRM if the phone supports it. YEAH;-) ExpireDynamicLinks=## That ought to do the trick. The thingi dont like here is that maybe we have different settings for this. Maybe the idea was for us to be able to set it in the POST/GET to nowsms. &ExpireDynamicLinks=10 etc. The handling of the redirect links is the only bit that really requires some thought for how it is implemented. (Well, it all requires thought, but that is the bit that gives me the most pause.) I see your point. I did not create nowsms. Wish i did ;-) So i don't know how big a change it is to you. I think that a lot can be done with an answer to a request. I have never really undestood why you answered a request with some HTML. Instead of answering back with ok, or error messages so that we could use that. Hope you undestand what i am saying... Chapter: Here's what Bryce is thinking... Generally i think your last lines are 100% the way i would like to see it. I wonder how you can undestand my english and needs ;-) | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 2823 Registered: 10-2002 |
Ok Lars, That should keep us busy for awhile, but I think it makes sense. -bn | |||
| Lars Nielsen, MobileNation ApS - Denmark New member Username: Larsmservice Post Number: 60 Registered: 10-2003 |
;) Fantastic.... | |||
