Causes of 408's in a Windows Media Services log

One common question I get from Windows Media Services admins who have looked through their log files is about the cause of the 408 status codes. Before answering the question directly, I need to define what a 408 is. Simply put, it is an abnormal disconnect. All it means is that at some point during the stream the client disconnected and did not report its statistics back to the server. Normally Windows Media Player posts a log message back to the server that contains information about the client’s playback experience when the playback stops (or a similar event). If the server does not receive this log post, for whatever reason, it takes the statistics it has compiled on its own and writes out a log entry with the c-status code of 408 in the log.

As for the causes, there could be a number of them. The client simply could have lost its connection to the Internet. In load balancing scenarios it’s not uncommon to see 408’s when the load balancer does not have affinity (sticky settings) set. In load balancing scenarios, when the player attempts to post back to the server, particularly if the client is using HTTP 1.0 for the connection, it posts on a new TCP session. That new session could get load balanced to a different server. The original server that had streamed the audio/video to the client then does not receive the log post, so it logs a 408. Occasionally we also see misbehaved clients (non-Windows Media Player clients that still report that they are WMP) and proxies. I have noticed that in some logs clients that have the cs(User-Agent) field with a value of: NSPlayer/9.0.0.2980. This is the original release of WMP 9 with no hotfix updates. It is extremely rare to see a client that has not been hotfixed. More likely this is a proxy that is impersonating a WMP client. It’s possible that the proxy is somehow not passing the client stats from the client on to the WMS server.