CDN Compliancy Tips for Media Players

Article Featured Image

Another example is where Nokia phones with Real clients falsely interpret SDP session bit rate information. This leads to constant buffer underruns and buffer overruns. CDNs and streaming server vendors had to jump through hoops and adapt their SDP sessions constantly for these specific clients because Nokia and Real ignored the problem.

They should have used a proper modern server environment in their lab. Or even better, they should have worked with a real-life CDN to test the product before putting it on the market. They should have checked about legacy and unsupported technologies. They should have implemented the Windows Media client's ability to process MMS requests but connect to RTSP on port 554. Don't assume compliancy on paper or from a lab environment.

Tip 7: Implement Protocol Rollover

Even though many protocols don't formally spec protocol rollover, it is a must-have for media clients. For instance, the 3GPP RTSP streaming spec formally prescribes RTSP via UDP on port 554. However, in many environments, UDP is blocked due to NAT routing. That is why most CDNs and streaming services also support rollover to HTTP via TCP on port 80.

One specific example is where a mobile phone vendor forgot to implement such a rollover function. It isn't formally part of the standard, but the entire industry does it anyway to make the standard work in real life. End users of these smart phones constantly complain that streams don't work on their devices. Whoops.

Vendors must do more real-life field tests. In lab enviroments, cell phones always work great. If they had worked with a CDN, their product would have been more rugged and tested. And used. Now they lose to the competition. Many CDNs also support various interprotocol redirect functions, which are great to redirect clients, for instance HTTP->RTSP redirect. The more protocols your client supports, the better the chance that your end users will get a decent stream.

Tip 8: Do Not Cache Playlists

A very common mistake is that media players tend to cache playlists. We have seen it in virtually all WinAmp-like clients, including iTunes. These clients assume that URLs in the playlist are static.

Wrong! A CDN is not a static environment. You cannot assume that a URL has an unlimited validity. Most CDNs use anti-deep linking technologies, involving tokens that expire after a few minutes.

If these clients cache a playlist, then the user will be able to stream or download the first object, but in the meantime the token expires for all the other objects. The result: the end user can't download or stream what they paid for. Whoops.

Tip 9: Stick to Your Own Specs

We have seen quite a few vendors who designed their own media player technology. And then they suddenly changed the client or the server without informing the industry. This can be quite frustrating to CDN operators and content publishers: end users install a new client or upgrade their smart phone and suddenly the stream breaks. Unfortunately, we have seen all major vendors pulling these tricks unfortunately, whether they changed something in how HTTP adaptive streaming behaves (Apple) or changed their protocol spec overnight (Adobe). Backward compliancy is extremely important!

Tip 10: Support Referrer Files!

Referrer files (e.g. RAM, QTL, ASX, XSPF, SMIL) are a great tool for CDNs to redirect clients to specific delivery nodes. Almost every media streaming technology has its own implementation. The CDN doesn't passively use DNS or responds with a simple HTTP redirect: the CDN generates an instruction file, which can be parsed by the client so it will always connect to the right delivery node.

Referrer files are the most underestimated technology in CDN-client integration!

Referrer files are the most ideal way for CDNs to instruct clients how to respond. Instead of having to rely on DNS (best effort technology) or on HTTP redirect, CDNs can put quite some intelligence into referrer files, such as protocol, server and port rollover, bringing much higher uptime (broadcast grade uptime) to clients than possible with DNS or redirect based CDNs.

Unfortunately many embedded clients claim to fully support a specific streaming technology. Even when they implemented all kinds of protocols and ports, many of them simply forgot to implement the referrer file. Which really limits the CDN and client interaction possibilities.

The best referrer file spec is Microsoft Windows Media ASX (WMX). Unfortunately Microsoft decided not to support their own technology with Smooth Streaming. Doh! It is on-the-shelf technology that Microsoft could have used to smooth (pun intended) the migration from all those Windows Media-based services to Smooth Streaming. It could have brought them back world domination in streaming, after losing their market share to Flash.

Also, if you decide to implement support for referrer files, make sure you fully implement according to the specs. For instance, if the referrer file contains a list of servers, make sure you rollover to alternative servers, or protocols as described in the referrer file.

So make sure your client supports referrer files to make sure your viewers get the best streaming experience out there.

Streaming Covers
Free
for qualified subscribers
Subscribe Now Current Issue Past Issues
Related Articles

StreamZilla Debuts Multi-CDN Service, Targets Mid-Size Companies

The company plans to save customers money while improving performance by routing traffic away from underperforming CDNs.