I had ported Widevine CDM to cobalt RELEASE_9 branch. Playback of purchased video very well in beginning of 5 minutes. After 5 minutes, decrypt failed, the reason is key expiration.
After review DRM related API in starboard, I have two questions:
1.How to handle "renewal" message from CDM? how to inform upper layer when such message existed?
2.If key/license expired, how to reflect such status to upper layer?
Thanks
You can call SbDrmSessionUpdateRequestFunc with kSbDrmTicketInvalid if the update request was generated by the DRM system (Widevine CDM in this case).
Cobalt will pass these messages to server to get new license.
Check the comment in Drm.h and you also need SB_API_VERSION >= 4 in your platform.
Related
I have an app that uses in-app purchases (IAP), specifically auto-renewable subscriptions.
Occasionally it seems that, when a subscription automatically get renewed, the local receipt doesn't get updated automatically. As a result, checking locally if an active subscription is available results false. Performing the same validation remotely (using Apple servers) returns true.
How and when is the local stored receipt updated or is this something that can only be triggered manually? If so, does this need to happen using SKReceiptRefreshRequest or SKPaymentQueue's restoreCompletedTransactions? Based on Apple's documentation the former seems to be the way to go:
A request to refresh the receipt, which represents the user's transactions with your app.
Unfortunately, this fails, perhaps because it thinks there's noting to update? However there is: as the local receipt is outdated as it doesn't contain the renewed subscription status.
I want to ensure I'm doing things correctly and this behavior (that again happens occasionally) is not something on Apple's end.
Thanks for any feedback.
I'm porting a working application from previous iOS's and am having trouble with the new in app purchase receipts.
The way we work now is to take the transactionReceipt property from the SKPaymentTransaction object and send it to the server for validation.
From what I could gather from other questions, it seems that the receipt is now held in one place, being :
[[NSBundle mainBundle] appStoreReceiptURL];
There are a few things I don't understand here :
Is there now one receipt for all of the purchased products?
If so, does this file grow and grow and grow?
If I want to send single receipts for single products to the server, how can I?
Is the only way to send the full file to the server all the time?
Very confused by this, any help would be greatly appreciated.
From what I've been able to gather via Apple's documentation.
1) There is one receipt for all purchased products. In order to perform server side validation you send the entire receipt to your server, which forwards it to Apple for verification. See this post on the Apple Developer Forums (starting around comment 13) https://devforums.apple.com/thread/193893?tstart=0
2) Non-consumables will remain in the receipt forever, so yes it will grow and grow. Consumables are removed lazily from the receipt once finished via a call to finishTransaction. See https://devforums.apple.com/message/876265#876265
3) The iOS6 way of looping through updatedTransactions and sending individual receipts to your server for validation seems at odds with the new iOS7 design. This post on the Apple Developer forums suggests you "Send the whole list of transactions to your server with the receipt. When the receipt is verified, deliver all of the products, and finish all of the transactions." https://devforums.apple.com/message/897870#897870
4) That really does seem to be the case.
If you believe the iOS7 documentation is lacking you can raise a bug report with Apple
How is dead device identification done in windows phone when we make use of micosoft push notification service? Does mspn store information about such devices? Is it possible for an application to retrieve the list?
Uri Channels can expire. This is why you should regularly check and refresh them from the client.
If the channel is no longer valid (as will happen when the app isn't used for a long time and the URI expires) you'll get an error in the repsonse when you try and send the message.
You shoudl use this method to detect URIs that are no longer valid.
There is no way to get a list of URIs that are no longer valid or to test validity without sending a message.
There is no way to ask the server for any expired notification channels however if you look t the response codes coming back from the MS services when you're attempting to send a notification (from your server) you'll be able to determine if the channel has expired. If you look at Push Notification Service Response Codes for Windows Phone you'll note that basically if you get a 404 Not Found back from the service then the channel has been expired and you should stop sending to it. It's worthwhile handling the other cases as well. Eg. Handling 200 OK / QueueFull messages correctly allows you to lighten the workload on your server by pausing notifications for that subscription for a period of time.
With the release of the new subscription option from In-App Billing API we started a proof of concept of the service and we found a few issues. Has anyone else tried it and would have some answers for us? Here's the issues we have been facing so far:
1 – While testing the unsubscribe functionality, the Google Play interface displays a white page with an “Item not found” message and a retry button. Is it due to the fact the app is not yet published? If yes, how can we test this flow without publishing it first?
2 – Inter device synchronization. When making a subscription on one device, other devices tied to the same account did not receive a OnPurchaseStateChange event. Is it again due to the fact the app is not published? Or are subscriptions tied to a particular device and not to an account?
3 – On our Google merchant page, when we cancel a purchase, the device does not receive a notification telling the subscription has been cancelled. Is this a bug? As a workaround we are manually checking the current time and comparing with the expiration date to force a restore transactions call. At this point, we are able to see the subscription is no longer valid. Do you think this is an acceptable solution?
4 – When a subscription is made, two transactions show up on the Google Merchant page: a FAILED transaction with a value of $0 and a valid one with the value we charged. Is this the expected behavior? What’s the purpose of the $0 FAILED transaction?
If anyone has faced similar issues we would like to know. Maybe these could be bugs on Google's end or maybe we did not understand 100% how it is supposed to work.
Thanks in advance.
1.I had the same issue and after I published (and later unpublished) my app I could see the app page in the market,so you can publish and than unpublish.
2.I didn't check it with subscriptions ,but for managed item i didn't get purchaseStateChange on two different devices as expected.
3.I do get subscription expired after canceling one,but only after a while.
I didn't understood how you can get the expiration date ?
you only can get it with access to play developer api.
the restore transactions will give you same purchaseStateChange as you got when purchase the item.
*in the developer guide it is recommanded to use restore transactions only in first app use.
4.I have same issue,and i heard at least about 10 people with same 0$ charge.
When i make a call that from 1016 to 1015 ,and my voip phone support msrp,so i want to send text-message form one leg to the other. I find that FreeSwitch handle the incoming message as a normal sip invite and will generate a session (also a channel)instance for the invite i make.The channel state is set to CS_NEW,then it into the sofia state callback to handle the different stage of sip procedure.When the sdp is parsed ,the freeswitch tell me the sdp is not match,so the session is turn off and the channel is hungup.I don't know how to configuration(if the freeswitch support msrp),or how to make this right.Thank you very much if you can give me more infomation.
I would suspect that you might be running an older code base that doesn't have MSRP support it was only recently added to FreeSWITCH in JIRA FS-3748 (DEC-2011). If you're running the latest code then the proper course of action would be to reopen FS-3748 (http://jira.freeswitch.org/browse/FS-3748) and report your findings on the JIRA and seek a possible fix.
StackOverflow isn't the proper location to report bugs.
Thanks,
Brian West
FreeSWITCH.org