Guides and Resources
Start typing to search…

Subscription streaming service

1. Streaming Security - SSL (HTTPS)

We support SSL streaming (HTTPS) and it is a label requirement that all of our streaming partners use this. To do this you only need to replace the HTTP protocol with HTTPS in the URL before signing it.\


2. Browser / Web-Based Streaming Security Testing

If you use a web-based application then you must ensure that it is completely secure. This primarily involves using the developer tool modules that come with the browsers to check if content URLs can be captured and used to download content (which is forbidden).

We have a single-use URL policy applied to web-streaming API keys so the URLs can only be used once on those keys, and verification client-side is needed to ensure that this applies within your web application. The best approach is for the URLs to be completely hidden where possible.

You must ensure that your web application is resilient to the following:

a) Testing General Capture Tools and Techniques

You must test for capture and reuse of the URL using the browser’s developer tools to ensure that it cannot be exploited.

Browsers to be checked: Firefox, Chrome, Safari and Internet Explorer.

When visiting your web app, open any pages where music is accessible and check the page using the dev tools. eg: on Firefox a right-click will give options like ‘inspect element’, ‘page source’ etc - test the content URLs using those tools and the equivalent tools for the other browsers.

b) Firefox Capture Tool Testing

This test applies to 3 specific tools available for Firefox browser, and you must ensure that the stream URLs cannot be exploited in Firefox using any of these tools:

1. Download Helper extension [downloadhelper.net]
2. Flashgot extension [flashgot.net]
3. Firebug [getfirebug.com]

c) In the event of a hack tool being released publicly

If a hack tool or workaround is made public so that it becomes possible to save the stream then you must implement a fix within a reasonable time period, otherwise the affected streams must be disabled. In such cases you must contact your Client Success Manager to provide assistance.

Note this does not apply to tools, such as TotalRecorder and SnapZ Pro that spoof system drivers.\


3. Mobile and Web Stream Security

Due to the differences in security on Web and Mobile platforms we have different security policies on the Web and Mobile keys in line with the labels’ security requirements.

If streaming on both Web and Mobile platforms you must only use the Web API keys for all Web streaming activity, and only the Mobile API keys for all Mobile streaming activity.\


4. Buffering and Caching

The labels specify the following requirements around buffering and caching which must be adhered to:

a) Content must be non-trivially obfuscated when buffered on any storage medium.

For non-mobile devices, buffering of content may only be done in brief (one minute) segments.

b) Buffered content must not be left on non-volatile storage or in RAM after playback ends, if permitted by the operating system. In no case may buffered content be saved to removable media.

c) Any temporary files stored locally in a cache must be encrypted and not accessible to be exploited or shared from the device. You must also ensure files are flushed from the memory as soon as possible.\


5. Country Restrictions

Stream playback must be denied to users who are outside the licensed geographical countries or territories.

Users must be filtered by one of the 2 methods below:

  • using IP lookup if the service is free to the consumer.
  • by a validated billing address for any paid service.\

6. User Device Restrictions

There are certain restrictions related to an end user device, as follows:

a) Only one user device is permitted to stream per subscriber account at any one time.

b) A maximum of 5 different devices are permitted per subscriber account.

c) A maximum of 3 different devices are permitted to store offline playlists per subscriber account\


7. API Implementation Security For External User Accounts

When using non-MassiveMusic external user accounts your API credentials must never be stored or passed on to end user devices or client apps. They must always be kept within a trusted environment, such as a secure server. Any generated signed URLs can be sent to the end user device.

Additional API keys with restricted permissions can be provided for making non-user related API calls directly from clients.\


8. Reporting - Data That You Log

There are 2 types of data that you must log with us that relates to subscription streaming, as follows:

a) creating / updating user subscriptions (online+offline) user/unlimitedStreaming

In order that a user can stream content they must first be authorized to do so, and you authorize the user via the POST user/unlimitedStreaming endpoint. A few general guidance notes about using this endpoint:

(i) When operating with your own users (ie: your own User ID values), where it asks for ‘oauth_token’, please instead use your own User ID value in its place.

(ii) A plancode is just a way to indicate the type of subscription being granted to the user in respect of the user/unlimitedStreaming endpoint.

There are 2 plancodes that you can use to indicate the type of subscription, below, please ensure that you use the correct plancode for each logged subscription.

premium-unlimited-streaming

standard-unlimited-streaming

The key difference between the Standard and Premium subscriptions is that Premium allows offline (cached) streaming playback, whereas the Standard subscription does not allow offline playback.

You must log the correct plancode for the subscription.

Note, there is also a planCode to use for trial subscriptions but this must be approved by the label(s) first. Your Client Success Manager can provide further details upon request.

(iii) Regarding the ‘ActivatedAt’ parameter, this should be the date that the subscription is first registered and the exact same value would be logged each month (until the subscription has finished). As this is the date that the subscription is first activated, any logged streams (described in point b) below) should not have dates earlier than the ActivatedAt date.

(iv) Regarding the subscription date parameters ‘currentPeriodStartDate’ to ‘expiryDate’, please ensure the dates line up correctly from month to month. The subscription period should be no longer than 1 calendar month and the two date parameters should be aligned.

  • ‘currentPeriodStartDate’ - should be the date time each month when the subscription is renewed.

  • ‘expiryDate’ - should be no more than 1 calendar month after the ‘currentPeriodStartDate’.

The next ‘currentPeriodStartDate’ period should be the same as the previous expiry date to ensure the subscription continues seamlessly.

For further clarity and guidance on the time and date parameters, below are some examples of how to roll over the dates and times for subscription renewals, running from January to April, where in the case of this example the standard or premium subscription was activated on the 29th day of January. The examples are followed by some explanatory points:

Month 1 - January

activatedAt=2015-01-29T14:03:00Z&

currentPeriodStartDate=2015-01-29T14:03:00Z&

expiryDate=2015-02-28T14:03:00Z&

Month 2 - February

activatedAt=2015-01-29T14:03:00Z&

currentPeriodStartDate=2015-02-28T14:03:00Z&

expiryDate=2015-03-29T14:03:00Z&

Month 3 - March

activatedAt=2015-01-29T14:03:00Z&

currentPeriodStartDate=2015-03-29T14:03:00Z&

expiryDate=2015-04-29T14:03:00Z&

Month 4 - April

activatedAt=2015-01-29T14:03:00Z&

currentPeriodStartDate=2015-04-29T14:03:00Z&

expiryDate=2015-05-29T14:03:00Z&

Some related points:

As the subscription was started on the 29th day of January, the subscription renewals cannot go beyond the 29th day of subsequent months.
But in the case of the February example there are only 28 days in the month, so you would use the 28th day as the expiry date for February.
In March you would revert back to the original subscription renewal date of the 29th day. You would not go beyond the 29th day, since the subscription was originally set-up on the 29th day, so that is the maximum expiry date it can have in any subsequent month.
Note that the time values match across the monthly renewals and are not sequential by the second:
ie: a 14:03:00 start-time could be interpreted to expire at 14:02:59 on the following month.

We do not use this logic so the time should be the exact same value for each monthly renewal.

Note ActivatedAt date is the same in all monthly subscription renewals, it is always the original activation date.
(v) The ‘recurringFee’ parameter is the price of the monthly subscription that the user pays and includes any taxes.

(vi) Any user subscription must be logged / updated only once per month. Although there is no need to update the subscription any more than once per month, you can do so if you see benefit, but please discuss with your Client Success Manager for full details.

(vii) If you are unsure whether an attempted request to log a subscriber has been successful, for example, if the response is slower than usual, then please first check whether the first attempt has been successful before re-attempting to log the subscriber again.

You can use GET user/unlimitedStreaming to check for existing subscriber status.

(viii) When making a GET request to check subscriber status, please ensure you don’t use the POST command because POST will send a new subscriber log.

Using GET will request the existing status.

b) logging streams user/subscription/log

You must log all user streaming activity via the user/subscription/log endpoint (which applies to both online and offline streaming). These streaming logs can be sent in batches.

Streams that are requested as part of pre-fetching functionality, but never played on the device, should still be logged with a zero second play time.

c) MassiveMusic uses DDEX Reporting, so we require a DPID (DDEX Party Identifier) for all of our partners. When getting started with discussing reporting requirements with MassiveMusic, you will need to visit http://dpid.ddex.net/reg.php and enter the service details, you will then get a code which MassiveMusic will then associate with your partnerID in the Data Warehouse.

Important:

We require you to retain a backup record of all your logs. The record should include a record of when the streams were initially logged to the user/subscription/log endpoint.\


9. Trials and Voucher Promotions

If you are considering offering trial streaming subscriptions or voucher promotions on your service, for example, allowing a user to have a 30 day free trial, you must notify us beforehand as the labels will need to explicitly agree to that usage via the approvals process. They may require that any such trial subscriptions be charged at full subscription cost.\


10. Application Testing and Approval

We must test and approve your application prior to launch to ensure it is fully compliant with the agreed licenses, this is a measure that ensures you are safe to launch the application without breaching any terms. The details of the testing and approval process is twofold as follows:

a) Informal Review - you must provide us with a beta / test version Android version (apk) and an iOS version that we can test, at least 4 weeks prior to your planned launch date. This allows us enough time to conduct an initial informal check of the application to see if we can spot any compliance issues at an early stage and allow you plenty of time to address any failure points.

b) Formal Approval - you must also provide us with your final application build at least 10 days prior to your launch date so that we can conduct a formal approval process. If approval is declined we will notify you of the failure point(s) which should then be rectified before re-submitting again for the approval process.

The application(s) must be fully approved before a launch can take place.

Note it is not permitted to make available publicly any sort of application version prior to our approval process. This includes no non-private Beta testing and no submittals to Google Play / the App store.\


11. Use of Content in your Application

Due to the strict requirements from the labels concerning use of their content it is not permitted to use any label content within your application, for testing or otherwise, until the labels have provided specific approval for use of their content.\


12. Indicating ‘Explicit’ Content

Where content is marked with an ‘Explicit’ flag you must reflect the same within the product title and the track title. This is usually expressed at the end of the name in brackets. eg: (Explicit)\


13. Processing takedowns

Where a label has initiated a content ‘takedown’ MassiveMusic shall remove that content from our API and Feeds.

Takedowns are indicated in the daily incremental release feeds by way of a ‘D’ command (Delete). If you have your own database of content and use the feeds you must observe the takedown immediately and remove the content from your service within 24 hours.\


14. Processing Metadata Updates

Metadata updates are communicated via our daily incremental feeds. If you use the feeds you must ensure that all data updates are processed within 24 hours.\


15. Provide us with a Launch Plan and Integration Updates

In order to make sure your launch can proceed as smoothly as possible you must provide to us full details of your launch plans at the earliest possible opportunity including any key development and launch dates.

Please allow a 4 week period prior to the launch date which we can reserve for application and report testing.

Specifically, inform your Client Success Manager with:

Planned Launch Date.
Planned Final Testing Date (at least 4 weeks prior to launch date).
Any other notable information, beta testing plans and key dates.
Updates on notable developments during your integration stage.\


16. Provide us with financial reporting information for all direct label licensing

If you have direct agreements with the labels and MassiveMusic are reporting to the labels on your behalf then you must provide us with all of the agreed financial terms with each of the labels so that we can build the report mechanisms accordingly. We must receive all such financial details before we can begin building reports.\


17. Logging and Report Testing

Logging and reporting are complex areas that can be subject to unexpected issues. We have a logging and report testing process that we must undertake prior to service launch to ensure that if issues do present themselves that we can tackle them before the service launches.

This testing process requires that you conduct both subscriber and stream logging activity with multiple users via the associated API endpoints and then we carry out checks of the data.

This is detailed in the next section. Your Client Success Manager can provide you with data templates and any further guidance.\


18. Partner-side Payments / Verifying User Location

If you are using your own transaction mechanism to take payments from end users then you must use the customer billing address to verify the location of the end user.

Updated 5 months ago