How to Troubleshoot Live Smooth Streaming Issues? – Part 1 (Basics)

This is a blog that I’ve been thinking about writing for a long time. Ever since the first IIS Live Smooth Streaming event (French Open in spring 2009), I’ve been directly involved in supporting many online events powered by our technologies. We have also helped our customers solve many issues through support emails and forum posts. In general, troubleshooting live smooth streaming issues isn’t that difficult once you understand the technology and know where to look and what to look for. Hopefully after reading this blog, you will feel more confident and empowered working with your live streaming servers. I would also like to suggest you reading my other blogs here and here if you haven’t done so since they’re very related.

Before we dive into the details of troubleshooting, I think it would be helpful to first review the basic design and protocols that Live Smooth Streaming uses.

As illustrated above, there are a few basic protocols in work here:

1. Encoder to Push Publishing Point

In most cases, a Push publishing point is created to accept push encoder streams. The push encoder streams come into the server as long-running POST HTTP requests. For a given publishing point, there can be one or multiple simultaneous POST connections each of which is identified by a stream ID. For example in the diagram above, there are three streams being pushed into the publishing point and their IDs are “300k”, “500k” and “1000k”. Each stream can contain one or multiple tracks each of which usually corresponds to a video bitrate or audio bitrate. For example in this case, stream ID 300k could have both 300k video track and an audio track. Stream ID is generated and often configurable on the encoder side and the only requirement from the server side is that different streams must have different stream IDs. Multiple POST connections to the same publishing point with the same stream ID are considered redundant backup streams.

2. Publishing Point to Publishing Point

With IIS Live Smooth Streaming, you have the option to chain multiple servers together for better redundancy and scalability. The protocol used for inter-server communication is very similar to the encoder-to-server case. The same number of streams/connections are established between the two servers and the stream ID values remain the same. The only thing new here is that you can set up a Pull publishing point which uses GET request to pull long-running streams from the upstream publishing point.

3. Publishing Point to Client

While all the connections among encoders and servers are long running connections, requests from the client are all short-lived GET requests. Smooth Streaming client first issues a manifest request to download the manifest and then issues fragment requests, with parameters indicating bitrates and media types, to download fragments for playback.

Ok, enough for part one. In the next blog, I’ll start drilling down into detailed steps of live smooth streaming diagnostics.