Good afternoon and welcome to session 719, Administering QuickTime Streaming Server. My name is Stephen Tonna. I'm a product manager on the QuickTime product marketing team. And I just want to remind you that if you have any questions, if you can hold them until the end, that'd be great. And then just line up at a microphone so that we can have the whole session translated properly. And without further ado, I'd like to introduce Chris LeCroy, who is an engineering manager on the server team at Apple.

Hi, I'm Chris LeCroy. I've been working on the streaming server since its inception. QuickTime Streaming Server was actually a part of the very first release of Mac OS X Server. It started out as QuickTime Streaming Server version 1. It's been in every version since then. With Panther, we're announcing QuickTime Streaming Server 5. It's got some new features that are actually pretty nice. We've got things like home directory support.

We've really tightened down the security of the server so it's even more secure than it was before. We have written a new administration application. We've written a new content management application. We've made it more tightly integrated with Mac OS X Server as a whole, so it integrates with some of the other services on Mac OS X Server. We are going to show you a little bit of that today. First, I'm going to have somebody come up and demo, somebody, John Anderson, demo the new admin.

We'll take a look at the content management tools. Then I'm going to give everybody an opportunity to maybe fall asleep because I'm going to go into some advanced administration. My goal is to see how many people either walk out or fall asleep. If I can do half the room, I'm doing really well. We're going to get really esoteric in here.

Okay. So the new admin. This is a native Mac OS X application, or it's a plug-in actually. It's a plug-in to the Mac OS X server admin. So it's completely integrated with all of the other services on the admin, or other services on the server inside the admin. It's not web-based. So in the past, I think beginning with QuickTime Streaming Server 3, we had a web-based admin. This is not web-based. This is a Mac OS X Cocoa application.

We do still provide the web-based admin, though, and there are a couple of reasons for that. One is that maybe you're not going to be on a Macintosh when you need to administer. So if you're on a Windows machine or a Linux machine, you can still get into the web-based admin and make changes to the server. The other reason is that QuickTime Streaming Server is the version of the server that we ship with Mac OS X Server. We also produce something called Darwin Streaming Server, which is really just an exact copy of QuickTime Streaming Server. It's the exact same source code.

The only difference is it doesn't have all of the nice Macintosh GUI that we are providing. And that's an open-source project that we provide binaries for Solaris, Windows, Linux. The source code is available. It's been ported to a bunch of different platforms. And that's another big reason for why the web-based UI is still there. So I'm going to have John come up and show you a little bit of the new streaming server admin.

I'm John Anderson. I work in the engineering team on UI, basically, for QTSS. So let me go ahead and launch the server admin. This is the server admin tool for the entire Mac OS X server machine. And you can actually use it to administer multiple servers at once. So you could use it to administer an entire rack of QuickTime Streaming Server machines. But what I'm going to do is I'm going to go ahead and go over here to QuickTime Streaming. That actually isn't stopped, but we'll just forget we saw that.

Did you do that? What? Okay, here we go. So if you go to the Connections tab, for example, you can see the connected users. This is pretty similar to the Web UI for those who have seen it. Fairly similar functionality. That's where you can see the connected users and the active relays, and you can sort them however you want to.

And just like the Web UI, you can see all of the logs from here, the error log, the access log, have easy access to those. So you don't have to FTP into the server to get those. You can just get them pretty easily. There's this graphs feature. This is pretty cool. This actually shows you how many users have been connected.

The throughput is... Isn't streaming admin tool running, Chris? Yeah. Or no, maybe not. Okay, so it would show you, were there any users connected, a graph over time. And maybe, Chris, after you run the streaming admin tool for a while, you can bring this up again? You can come by and see it later. Settings, of course, this is the important stuff.

This is the meat of the matter. You can set, for example, what the root folder is, where you put all of your media files, what your maximum connections. A lot of these are over from the web as well. One thing that is new and is pretty significant that was not in previous versions is this IP bindings tab.

And so this actually allows you, if you're streaming on port 80, of course, you can't stream on the same IP address as an Apache server, because that's also streaming on port 80. So this is something that's new in this... QTSS admin that allows you to specifically tell it to bind to certain IP addresses, and then you can go ahead and turn on streaming on port 80 and do multiple hosts on the same machine. There's a better relay UI. I'm really not going to get into that because that's pretty complex. And logging. So this really gives you a lot of the stuff from the web end.

It basically gives you everything from the web admin and more, and gives you some graphs to represent some things, and it's just a lot easier to use. Great. Thanks. Actually, you might as well stay up here because you're going to be back in about 30 seconds. I can do that. Back to the slides.

So we also showed, if you guys were at the QuickTime keynote Tuesday, we showed a new application called QTSS Publisher. And QTSS Publisher is an application that lets you remotely manage all of the content on your streaming service. You may have an XServe sitting someplace in a back room. This application will allow you to do things like upload all of your movies to the server from wherever you're at, and automatically prepare them for the internet, for hinted streaming, for progressive download.

It'll help you a lot with all of the HTML issues that you'll need to deal with when you're trying to get multimedia up on the internet. It'll let you manage playlists and edit annotations in. This application is actually driving some Unix tools that we wrote that sit on the back end. And you can use those tools yourself. I'll show you a little bit more about those later in the session. But I'm going to have John demo QTSS Publisher now.

QTSS Publisher is basically, it's there to save you a lot of steps. We get a lot of questions on the mailing list where it's like, okay, I know where my movies folder is. I put my movie up there, and that's kind of it. Like, you don't really know, where do we go from here? So that's where QTSS Publisher kind of fits in. This is a client server app.

So this is installed with the admin tools, and you can connect either, in this case, we're connecting to local hosts, and of course you can also connect to a remote server, and that's important to emphasize, that you can run this from anywhere, and that you're connecting to your server.

As you can see here from the media view, you can see all of your media. You can see it collated basically as a list that you can sort through, for example, or you can see it as an outline so you can see your actual file tree here. And we also separated out, of course, into media library and mp3 library.

And that basically is mp3 library is all your mp3s, and your media library is basically all your everything but mp3s. So that's the best way of kind of distinguishing between the two. The streaming standards are different, of course, for mp3 files, it's icecast streaming, and for media, it's RTSP.

So that's the main distinction there. So what I'm going to do is I'm going to go ahead and go to the MP3 library, and I'm going to highlight a song, and I'm going to go to the settings view. So here you can see all the ID3 tags for that MP3 movie, and you can edit them, change them remotely. And if you go to the URL tab, you can see this checkbox that says media is available for download. So when you're working in these libraries, you're actually working in a sort of staging area.

So you can go ahead and put movies up here, and you can upload them, and they will not be available to the public immediately. So you can go ahead and change all of your settings and everything like that before you make them available to the public for streaming.

So for example, here I can go ahead and make it available for download and apply my changes. And this will actually give me the URL for the MP3 file so that I can stream it on demand. Is there sound on this? Give me a detailed-- Please enter your-- So I picked a weird song, but that's OK.

And if you do want to upload media, then all you have to do is go to the media view or basically any list of content, and you can just take a file. I'm not really going to drag it up, but I could just take this clipping file, for example, and drag it in, and then you can just pick where you want it to go, and it will get uploaded. And if it's a movie file, you don't have to worry about making it ready for fast start. You don't have to worry about making it ready for hinting. That all happens in the background on the server as it's uploaded.

So, let's see. So the next thing I'm going to do is I'm going to make an MP3 playlist. Because of course, on-demand MP3 is one thing, but of course another thing that a lot of people technically will usually do is they'll start up a playlist so they can have basically an MP3 radio station going. So I can go in here and click New Playlist, and I'll make an MP3 playlist, and we'll just call it My Music.

So I can go in here and, yeah, I can either from the folder view here or from the song view, I can just pick. I'm going to be really moody and go for like a Linkin Park and then followed it up with REM. And I guess that's all I have is Linkin Park and REM. So you can see that this is very Mac-like. I mean, you can take things and drag them to rearrange them. Apparently not, but-- This is beta.

So you can drag any of these files in that you want, set them up, and then when you're ready, just hit start. And the playlists will-- oh, I don't have a broadcast password. OK, here's another time to see the admin. Let's go ahead and go in here and set an mp3 broadcast password.

So while he's doing that, mp3 broadcast passwords in Icecast or Shellcast, you need to provide a password, basically, for people to be able to broadcast to a server. So he's setting that right now. And why does that matter? Because the broadcaster that broadcasts MP3s actually broadcasts to the streaming server, which then distributes out to clients. So you've got to have a password on that server.

So we may end up skipping the broadcast of the My Music playlist. Sounds like Linkin Park and REM, basically. Yeah, it's Linkin Park and REM. It's probably not going to be a real surprise to you at any point anyway. So what we'll do is... We'll just click OK on that error message and go on with the demo. Next thing we'll do is we'll just look at some movies. I'm going to go back to here to the list view, and I'm going to highlight this losing grip movie, which is about how I feel right now.

You can see here you can set all the annotations. The final version, of course, is going to have the full list of annotations in there. I just put a few of them in here so far. It's the same idea. You can go in here and change the movie annotations remotely, so you don't have to download the movie and change the annotations and then upload it back up again. Here you see a couple buttons here. Media is available for streaming. Media is available for download. If you make something available for download, what it's going to do is it's going to prepare it for free.

It's going to put it in your web server folder and make it available there so that it can be viewed by Fast Start. If it's something short like a movie trailer or a video or something, that might work really well for that. For example, here, if I say make available for download... Click on that link and you can see by the little progress bar that goes along here that it's actually fast starting the movie.

What I'm going to do in this case is I'm going to make it available for streaming. So this is going to go through QuickTime Streaming Server instead. So this is going to put a hinted movie in the QuickTime Streaming movies folder. And so it's the same thing here. I can click on this URL and you get instant on. It's already streaming.

The thing here, of course, is that you're not going to want to hand somebody the URL. I mean, it's another stopping point, right? It's like a where do you go from here. You've got this RTSP URL. You're not going to tell your users to type it into the QuickTime player. And so that's what the purpose of the links view is.

And this view will basically give you a list of everything that's publicly available. So it's assumed that your playlists are publicly available, of course. And any of the movies and MP3 files that you've made available for streaming or download will show up here. And so you can see here that... For example, the losing grip movie is still highlighted.

And in this display tab, you can basically explain how it is that you want this to be embedded in a page. So for example, here it's selected that you want it to open in the QuickTime player. So it's going to show this custom image. And when they click on it, it's going to open a QuickTime player with that movie playing in it. Optionally, I can embed it in the web page, which would have the same behavior, except that the movie would play in the page itself. Or I can have it autoplay, so it starts playing as soon as it's played.

In this case, I'm going to go ahead and have it open in the QuickTime player. And if we look at the bandwidth tab, you can see that you can actually create ref movies here. So you can specify, for example, that if somebody's on a broadband connection, they can see the streaming version. And if they're not, then they get the fast start version. Or maybe you can transcode it to a lower bit rate or anything like that.

So this is basically ref movies made easy. And once you set that up, you can go to the HTML tab and What I could do here, for example, is I can highlight all this stuff, copy it, and then I'm going to launch BBEdit and make the world's simplest web page.

So I'll just do a new HTML document. I'm not even going to title it, except that... And just paste that in. Now if I take that movie off my desktop and drag it onto Safari, You can see we have a movie with me. So that's pretty cool. I mean, that takes you the rest of the steps to getting something actually onto a page.

And not only can you drag that into BBEdit, but you can also drag it into Dreamweaver and GoLive and stuff like that, and it'll show up right away as--it actually shows up as an ActiveX control because it has to be compatible with Internet Explorer 6 for Windows. Pay no attention to the man behind the curtain. That's one of those demo things.

But yes, very astute of you to notice that, actually. So, that's pretty cool, but there's another step that we can go to with this, which is that you can highlight, you can multiple select, or even do a single select of these links, and you can click the Make Web Page button. And what this will actually do is this will take that HTML code, and it will run it through what's called Apache XSLT, which means it's XML Style Sheet Transformations.

It's a well-documented and very versatile standard for templating, and it means that while we'll provide some templates for you, you can go out and make your own. And so I can type in a name here. I can say, like, My Avro Movies. And so what this will actually do is make a web page from your template with the movies in it. And here's where it's actually paying attention to the stuff that I had chosen in that.

Thanks, John. Okay, so this is stopping point one for those of you who want to leave. It's going to get really boring after this. John's kind of the highlight of the show here. I'm going to talk a little bit about firewalls. Firewalls are something that have been in the past the bane of streaming, but then things are getting better, and I can talk to you a little bit about why firewalls are a problem and why they're getting better. I'm going to show you how to work through the command line a little bit and then talk about some troubleshooting and some configuration.

options that you can do there that you can't do from the UI. So first firewalls, next, and proxies. So when we first started out doing streaming, QuickTime Streaming Server 1, We had a hard time getting streams to go through anything because the firewalls, it was fairly new stuff. Firewalls were not configured to deal with it.

There were not necessarily proxies around. NAPs had no idea what to do with anything. So we did a few things. We added the ability to tunnel... The protocols we use over HTTP, which is great, that gets around firewalls and NATs because they know what to do with HTTP, but it's not really the best way to stream. It's not the way we like to stream. We like to use the standard protocols.

I want to show you kind of why these protocols are a problem. So streaming is comprised of three protocols typically on the wire. You've got RTSP, and that's the protocol that runs on TCP, runs on ports 554, 70, 70, or 80, or whatever port the server is configured to use.

It's a lot like HTTP, and it's basically just a way for the player, the player initiates this to say, I'd like to watch a movie. What is the movie? What does it look like? Okay, I want to watch these tracks. Okay, play the movie. And the way that protocol works is the client makes a request over TCP, and the server responds.

And each of those boxes is a separate request. It's not one big request like that. This is typically not a problem for firewalls because firewalls are usually configured to allow, and the firewall I'm referring to is the firewall that's on the player side. Firewalls are typically configured to allow TCP connections from a client that are initiated from a client inside your network to work properly.

If the client initiated it, it's probably safe. Not all of them, but most of them are. The problem comes into play when we get done with the RTSP and start sending data. So data gets sent over RTP, and RTP and RTCP traditionally run over UDP. So the problem with UDP versus TCP.

Is that TCP is not connectionless. It's a protocol that keeps the connection. The connection is there. UDP is connectionless. When a client initiates a request to a server via TCP, that connection stays open until the client or the server closes that connection. And so firewalls, they're happy with that. They know where the connection came from. They know who owns both ends. And as long as it stays up, they're happy with it. The problem with UDP.

Is that it's connectionless. Every packet you send is basically a brand new little mini connection to the server. So what just happened here is that the TCP all got through fine. The streaming server started to send media tracks and status tracks, which are via UDP. And the firewall sees these things coming in at it bound for that QT player on port 6970 and up. And it's like, where did these come from? It has no idea where it came from. And so they're just bounced right off the firewall.

Um. Um. Um. So that's the really big problem. Not so problematic is the client sends back UDP packets to the server. These are usually not a problem because the server is not going to have a firewall that blocks that stuff or it will be properly configured because you're doing streaming of course. But you may have a firewall that will block outgoing UDP as well.

These status packets contain things like, things that might be interesting to the server like... Which packets the client received, which ones it missed, what its average bandwidth was, what its frame rate was, things like that. And you'll see a little bit more of that when I get into more esoteric topics. Okay, so kind of to recap firewalls. So the problem with firewalls is that RTP and RTCP are sent out of band from the RTSP connection, right? They're sent via UDP, they're completely separate. Number one, excellent.

Firewalls consider those to be unsolicited. They don't know why anybody would be sending these to the player because the firewall has no idea that it was negotiated out of band via RTSP. NATs have a different problem. So what NATs do is they take a single IP address and then they'll map all of the traffic coming through that router, the NAT router, and redirect it to the proper client on the back end. I think most of you are familiar with NATs.

So what happens is a NAT gets this UDP packet and it looks at it and it's like, I have no idea who to send this to, so it just drops it. There are ways to fix this. One, as I mentioned, is to stream on port 80. Other ways to fix that are to configure your firewall. The problem with configuring a firewall is that you basically have to open up ports 6970 through 6800 or something like that.

For incoming UDP, well, there's a potential security risk there. You don't want to just open up ports and allow packets to come through that you don't understand. So what you normally would do is you'd set up a proxy, a streaming proxy. So streaming proxies typically live in the DMZ on the client side where the player is.

They understand RTSP, RTP, RTCP, all of the protocols involved in streaming. The server will see the proxy as just another client. And the client will see the proxy as just another server. So there's no problem there with compatibility. And what happens is the proxy translates the requests from the client and from the server.

So the server is seeing the proxy as one client. The proxy actually acts sort of as a NAT, basically, a NAT for streaming. Here's a diagram to make it a little bit easier to understand, I think. So on the left, you've got the streaming server and the internet. So this is you. You're the guys administering the server. What you need to tell people who can't stream or sysadmins on that side is that they need a streaming proxy.

And the proxy lives right there in the DMZ. And the DMZ is an area that the firewall trusts. So things coming from that proxy server will be trusted by the firewall and allowed through to the clients. Anything that tries to bypass that streaming proxy or go around the DMZ is going to hit the firewall and get blocked because the firewall is going to say, I don't know who you are, I don't trust you, goodbye. That's basically how proxies work.

and how to get around firewalls. Okay, so this is the second point where people may want to, will probably want to think about leaving. I'm going to kind of go through command line options in QuickTime Streaming Server. So QuickTime Streaming Server is comprised of a bunch of command line tools.

Whenever, when you see things like the admin app, the admin that John was showing, or the QtSS publisher, or the web-based admin, all those really are just facades that are on top of these command line tools. They just, all they do is configure those, configure the config files, change the options on the command line, and just execute these tools.

So if you... I really want to get down and dirty. There are all kinds of things you can do in the command line that you can't do in the GUI, so I'm going to run through a few of these briefly. These are just good things to know. Probably a lot of it will not make sense to you right now, but if you're really doing streaming, there's going to come a time when you need to do something, and this is the information that will come in handy.

It's not documented completely. It's not something we put a lot of effort into documenting. We're trying to get better. But we have a mailing list, and all the engineers are on that mailing list. And they're really good about answering questions, and we'd actually love to answer. We love to see people messing with things like this. So starting off with the first command line tool is QuickTime Streaming Server. So that's the command line tool. That is the QuickTime Streaming Server, basically.

And so what I'm showing here is basically the usage for that tool. If you were to type commit QuickTime Streaming Server dash v for version, it would show you this. A couple of things that are to kind of point out. So when you're... QuickTime Streaming Server normally runs as a daemon, so the D that you see there, dash D, running foreground, that causes it to stay in the foreground, and in that mode, QuickTime Streaming Server will actually generate print apps out under the terminal, and you can kind of watch what's happening.

You can watch more or less, depending upon some other changes that you've made, which I'll show you later. Dash P allows you to specify which port you want the server to listen to. So this is really useful when somebody's having a problem someplace, you've got a streaming server that's up and running, you don't want to bring it down to mess around with config files or do all of this troubleshooting.

You can just say dash P8764, just pick a random port, and when you have the client that you're working with connect using that port in their URL, and the server will run off to the side. It won't have any impact on the server that's already running, so you can run multiple servers that way.

And then there are a couple of options for specifying custom config files. There's a default location for config files, but if you wanted to do some troubleshooting on the side, you can tweak the config files in a different location and then point the server off to those. The -s option is actually pretty interesting if you just kind of want to monitor your server. It'll basically just align at a time, show you how many clients are connected. I think it shows whether they're getting packet loss or not, things like that.

So moving from the command line options for QuickTime Streaming Server, I want to go to the config file. So the config file is XML-based. It's really modular. The server's really modular, right? If you've ever heard any of us talk about the streaming server before, it's basically a core server built with multiple modules. We've got a module for doing QuickTime movies. We've got a module for doing MP3s. We've got a module for doing reflections of broadcast. We have a module for doing administration.

The XML follows that format, so each module has its own little block of configuration. In the library QuickTime streaming config directory, which is the default location for all the config files, you'll see a streaming server XML-sample file, and that file is actually fully commented. The file that the server normally uses doesn't have comments in it, so this is kind of some partial documentation.

You'll find things in there that you will not even... You have no hope of understanding, but probably best not to touch those. There are over 140 attributes in there, and most of them don't need to be touched. But they come in useful to different people depending upon what they're trying to do.

If you do modify a file, a config file, and you don't want to restart the server, if you send it a HUP signal, if you guys are familiar with using the kill command, it's kill dash HUP, uppercase like that, and the process ID of the server. That will force the server to reread its preferences and pick up your new changes. And I have no idea what those last two lines are.

Well, if you really mess up, I think I know what it's supposed to say. So if you really mess up your config file, you can delete it and the server will automatically generate a new one for you. Misty Edit, I think. So here's what some of the attributes look like. As I said, they're XML. So this is a sample file, so it's got the comments in it, things like auto restart to Boolean, set it to true if you want the server to auto restart if it crashes, although it never crashes.

False if you want it to just go ahead and die. The movie folder location, which you see in the UI, that's basically what it looks like in the config file. Down below you see some debugging options, and I'll show you some more about these things later. Let you kind of put the server into modes where it'll kind of show you more information as it's running.

So here are some of the interesting ones. So these are kind of things that people tend to want to play with because they want to do things we never thought of. We have a technology called skip protection in the server, and one of the things that it does is it will send media faster than real time.

The reason it does that is it wants to grow the buffer on the client side. The reason it wants to do that is it gives us a lot more time if we do need to retransmit a packet. So basically, it helps to improve the quality. We have that fixed, we have that capped right now at 25 seconds.

If you had a reason to put that down to 10 seconds or up to a minute or five minutes, whatever, that's the value you would change. The server also runs as whoever you launch it as. It needs to be typically launched as root because it needs to bind to some low numbered ports. It needs to bind to port 554, port 80, and anything under 1024 you need to be root to bind to.

So what you can do is set both of these, and this will cause the server, after it binds to those ports, to... The problem with being root, of course, is security problems. This will cause the server to set its user ID and its group ID down to whatever user you specify here, and this is basically a good thing to do for security reasons.

Some options for error log verbosity. The bind IP address option is actually available in the IP, or I mean in the admin now. I don't know why anybody would ever want to do this, but before we had instant on, there used to be like a minimum three-second buffer, and we put this in here because there was a reason for people to increase that buffer. Don't ask me why, but if you ever need to do that, that's how you do it.

Another component of streaming is the concept of a blob of text called SDP. It stands for Session Description Protocol. It basically describes the movie. It's got information about each track, what format each track is in, that information. That information is actually embedded in a QuickTime movie or an MPEG-4.

If you have some reason to override that information and don't want to have to edit the movie, you just need to do a quick little hack, then you can turn this option on, drop in a file named movie name dot whatever the movie name is dot SDP that has basically a full SDP description in it, and that'll cause the server to pick that up rather than using the SDP information out of the movie. So it's kind of an advanced thing, but it actually can come in useful in emergencies.

If you don't want to generate the SDP by hand, you can set this option to true, and this will cause the server, whenever a movie is requested, to take the SDP information from the movie and spit out a little text file. So that's kind of a quick way to get the SDP up and running and then make a little tweak to it. With both of these options set, then everything will work the way you'd like it to. You can have login, login GMT time or local time. For the admin module, I'm going to show you a little more about an admin protocol we have later.

The admin protocol only allows local access right now for security reasons, so you've got to be on the local machine to use this protocol. If you wanted to allow outside access, you could set the local access only to false, and then you could provide a list of IP addresses that are the only IP addresses that are allowed to get in, which is kind of medium security.

And then this last one is MP3 max flow control time. So this is basically the size of a buffer that we use when streaming MP3s. So if you have problems with MP3 players kind of going through that rebuffering thing that they do go through sometimes, if you increase this value, that many times will take care of that.

Okay, moving on. These are a little more esoteric. They're dropping like flies. This is awesome. So when you're using a broadcaster with the server, there are a couple of behaviors that you may or may not like. There are ways to override those. So the first one is that if a broadcaster stops for some reason and there are a bunch of clients listening to it, our server will keep those clients connected so that if the broadcaster comes back up, it'll just continue working. And the only thing the client will see is just kind of a blank spot, right? The stream will stop for a little bit and then start back up.

You may have a reason to have the behavior work the opposite way, which is to actually have all of the client connections just get dropped when you stop the broadcaster. So this is the option that you would use for that. Our broadcaster also has the ability to automatically announce that it's got a broadcast to the server. That's on by default. If you wanted to turn that off for whatever reason, typically security, you could turn that off, although that is an authenticated transaction.

So it's kind of minorly secure already, but this will give you even more security. Then another kind of behavior of the server is that... If a broadcaster crashes for some reason, the QuickTime Streaming Server doesn't necessarily know, it doesn't immediately assume that the broadcaster is gone. It can't. So what'll happen is that it'll sit there and wait, and it'll wait for a certain amount of time, and if it doesn't receive any more data from the broadcaster, it'll eventually time it out.

Well, that can be a problem. If you're in the middle of doing a live broadcast and something bad happens, you don't have two or three or four minutes, whatever that timeout is, to get, you know, you want to get the broadcaster back up and running, and you want it to start broadcasting again. What you can do is you can change this value.

And a little more about firewalls, so I don't need to talk too much about the port numbers. These are the port numbers that the server, by default, binds to. If you wanted to, you could turn off some of these ports. The 8054 is the standard RTSP port, 8000 and 8001 are the standard MP3 broadcasting ports, and 7070 is kind of a historical real networks RTSP proxy port number.

And the reason we have that in here is that back in the old days, this actually helped us to get through some of the firewalls because they were configured for real streaming. Another important one, this one will have you pulling your hair out if it ever happens to you. So you remember that status from the client comes back via USB. So I mentioned that that contains things like which packets the client received, which ones it lost. It also is used for something else that's really important.

The server uses that to determine whether the client is still alive or not. And if a server determines that a client is no longer alive, it's going to basically drop its connection after two or three minutes. So you can end up with configurations usually on your end. If you have a configuration where you put a round robin DNS in front of your streaming, what's going to happen is that that round robin is going to know what to do with all of the TCP because it understands, remember those are persistent connections, it knows which end belongs to everybody. What's going to happen is that clients are going to start sending UDP packets at your round robin.

At your round robin DNS machine. So it's going to get them and it's not going to know which of your back end machines to send it to. So what this option does is it tells, the streaming servers to actually embed their own IP address inside one of the transactions that goes all the way back to the client.

That'll cause the client to bypass DNS round robin when it's sending those status packets and send them directly around to the server, which is fine, it doesn't affect bandwidth or anything like that, which is typically why you would have a DNS round robin set up. But it makes everything just magically work. Bind IP address, we already talked about that a little bit in the UI.

Don't need to go into that. OK, so MP3 streaming at the command line. This is probably something you are more likely to use. MP3 streaming, because it's basically for every broadcast you're doing or every playlist you're doing, you're running one copy of this tool. And so there are, if you guys are like kind of savvy Perl scripters, whatever, you can actually write your own tools to kind of start and stop playlists, manage playlists, and the command line is really the way you want to do that.

Some of the options here are... Let's drop down to the dash X there, pre-flight configuration. What that's going to do is that's actually going to walk through all of the configuration files and make sure that those all look okay. The one underneath that is check MP3 files. That's going to do a fast scan through all of your MP3 files and look for problems. Corrupt files, data rates that don't match, things that will cause them not to play properly in a player when you're doing a broadcast, or when you're doing a playlist, I mean. Other options are pretty self-explanatory, I think.

Configuration files. So MP3 streaming is comprised of two required files when you do a broadcast, a config file and a playlist file. And then there's some optional meta files, and I'll get into each of these in a little more detail. So the config file looks like this. It's got basically a bunch of the same things you saw in the command line options. It's also got things like your broadcast name, your mount point, which is basically the portion of the URL that a user would type in after the IP address.

Actually, they wouldn't type it in. You would use QTSS Publisher, and it would all be up on your website. The broadcast password... Max, upcoming list size. This will help to control the file I'm going to explain in just a second. The bit rate you want to use for doing pre-flighting, as it's scanning through all those MP3 movies, that's the bit rate it's going to use to determine whether they're valid or not.

And then the playlist file. Playlist files are pretty simple. They're basically just a list of paths to MP3 files. In addition, they've got a number to the right of them, and that number is the number that's used when you're doing weighted random playlists. Weighted random playlists are playlists that play randomly, but the higher a number is, the higher a weight is on a song, the more often it'll play. So you can adjust these numbers from from 0 to 10 or 1 to 10. So here are the optional files.

So

There's actually a Macintosh application. The name is escaping me right now. Okay, so streaming load tool. So this is our tool that allows you to... Put load on a server. That's what we typically use it for. It's basically a QuickTime player simulator. It doesn't actually show any movies, but it does all of the networking and acts just like a real QuickTime player as far as the server is concerned.

We use it for performance testing at Apple. Most people who are deploying big servers will use it for that as well. They want to find out how many streams the server is comfortable with. We use it for stress testing. That's how we find a lot of bugs. We just load it up with as many streams as we can at one time.

We also use it for protocol testing. The streaming load tool supports all of the variations of the RTSP protocols that QuickTime Streaming Server supports. We have... Tunneling over port 80, HTTP, we've got standard RTSP, we've got the skip protection enhancements, which are standard, but they're kind of extensions to RTSP, and so on. And this simulator supports all of those, so you can test those protocols. And it works with servers and proxies, because it does look just like a standard streaming client.

This is what the command line options are pretty straightforward. Not a whole lot there. Most of the information that you're going to modify will be in the config file. The config file is again text format. It's not XML, it's just a key value pair file. Some of the options you're going to want to set possibly are the client type. Reliable UDP is skip protection.

UDP is standard RTSP. HTTP is tunneling over, tunneling RTSP over HTTP. TCP is interleaved RTSP. Most of you probably don't care about this. Number of concurrent clients. This tool can simulate more than one client. So if you wanted to simulate 100 clients, you would set concurrent clients to 100.

Movie length. So you might want to control how long the movie is actually watched. It may be a 20-minute movie, but you just want to do a little 10-second test to make sure that the movie is up and running. Just set that to 10 seconds. Run forever means that the tool just runs forever. You'd normally use that if you're doing performance testing. It's hard to tell how long it's going to take you to get everything all set up. So you just get this thing going, crank it up, and it just runs forever until you stop it.

The load tool also generates logs, and these logs contain all kinds of information. I'm going to show you one in a second about what happened with each of the sessions. And URLs, of course. You need to specify which movies you want to watch. The load tool can take a list of URLs. So if you've got 100 movies on your server and you want to have this tool walk through every one of them, just include all 100 URLs in the config file and it'll do that. So here's what the output looks like in the terminal.

So one important thing here is the checking for streaming load tool .mov on the target servers. So what that's saying, the way streaming load tool works is that it requires that a movie with this name is on the server, otherwise it's not going to run. And the reason we do that is we don't want people to take streaming load tool and just start putting stress on everybody's servers, right? So the only way it'll work is if there's a movie with this name on your server, so you need to make sure of that before you use it.

So it shows you what the options were, and then it just kind of shows you every second kind of status until it gets done and then it's done. So that's the output there. And this is the log. The logs have all kinds of information in them. I'm not even sure you guys can kind of parse through all of that. It'll show you things like total packets lost, duplicate packets, what the data rate was for the stream, basically all that stuff. If there were an error, it would show you an error. There's a couldn't connect to server error. It's in the middle.

So what this is good for is this makes it possible for people to write tools in Perl or shell scripts or whatever that go off and periodically call streaming load tool with a preset, predefined list of URLs. Those tools can then parse through this log and then actually kind of monitor status. They can send you an email when they see a problem or they can generate HTML and show you the status of all your streams. We've done this at Apple before. It's actually kind of cool.

So, new in Panther Server, I talked about a couple of tools that the QTSS publisher uses. We have now provided some command line tools for manipulating QuickTime movies for internet preparation, basically. Qt Media is a new tool. It allows you to do things like change the annotations, make the movie a fast start movie, add a hint track to the movie, and so on. It's pretty straightforward.

This is going to be really good for workflow. People can set up scripts that do all of this stuff automatically. Cron jobs, you can have the Unix form of a folder action and have a cron job that watches folders and automatically hints movies and shoves them off in the right spot.

Next tool is QtRef, and this is just a command line tool for creating ref movies. So you can do all of this through the terminal. If you're at the machine, I don't know why you'd want to do that, but if you need to SSH in from a Windows machine or a Unix machine, you can still do things with QuickTime. Okay, so you thought that was boring. Now it's going to get really esoteric.

So the server's got some troubleshooting modes. We use these-- at Apple, we do a lot of streaming. We've come across a lot of problems. As I mentioned, firewall problems. It's really hard to figure out why people are not able to get a stream sometimes or if they're seeing blips or not good quality video.

We have some modes in the server that really let you kind of dive really deep down and kind of troubleshoot these problems. They're basically what you would see in a packet sniffer, but we format things because we understand what the protocol is. We format them into a, I don't want to say human readable, but engineer readable format.

So here are a couple of them. You can turn on RTSP debug printf. So remember, you saw all of the negotiation between the server and the client. I want to watch this movie. What does it look like? Back and forth, the TCP thing. This will just kind of dump all of that to the terminal as it's happening. You can kind of monitor those things.

Packet header printf. This will print packet headers for all of the RTP and the RTCP packets. We don't print, obviously, the media from the RTP packets because it wouldn't be very useful. And then you can, the options here let you specify which of those things you want to see. If you turn ACK off, you'll get far fewer packets. I'm going to kind of show you how that works now.

Just so you can see how horrendous it is. Flip over to the demo machine. So I'm going to... I'm going to cheat a little bit. I'm not going to type the entire command in. But basically what I'm doing is launching the... You guys see that okay up there? No.

I'll highlight each thing. So, sudo, as you may not know, is just a way to run things basically as super user without actually becoming super user. QuickTime Streaming Server is the command I'm running. I want to run this server using a config file that I have modified, and I've turned on those options that I just showed you. I'm running in debug mode, dash D. And I've already got a server running on this machine.

I don't want to interrupt that one, so I'm going to tell it to actually do all of its streaming on port 8765. So let me start it up. I'm asking for my root password because of the sudo command. So the server's running, and I'm going to show you what happens when you connect a client with all of these debugging options turned on. It's very fun.

So can you guys read that? Do you know what it means? Anyway, basically the point here is to show you that there is all kinds of information coming out of there. So let me flip back to the slides. I'll kind of show you just a little bit of some of the information that... comes through. Slide. Unless you guys were still watching that.

Okay, so you probably couldn't see it because it went by way too fast, so here's what RTSP looks like. This is the output that you'll get when you put it into this mode, showing you the output. IP of the server, showing you the port that the client connected to on the server, 7070 in this case, which is a little interesting. Maybe that's part of the problem somebody's having. Shows you the port that the client's using, not all that important. The URL they used.

Shows you the bandwidth. The bandwidth here is 2 billion and something. Basically, that means that they've got it set to LAN. It's set to the highest bandwidth possible. If they had their QuickTime player set to modem, it would say whatever modem rate QuickTime player sends back. That can be useful when people are complaining about not getting high quality content.

Maybe they've left their QuickTime player set to modem speed. Look at that and you can tell immediately what happened. Also, in the user agent field, you can tell what version of QuickTime they've got. You can tell which OS they're running on, which CPU, things like that, and that can be really useful when you're trying to troubleshoot as well.

The response from Describe has a couple of little, it's a little less interesting when you're troubleshooting, but let's just kind of walk, go through the red ones here. That X accept retransmit, R retransmit, that basically tells you that the server and the client have agreed to do skip protection.

If you don't see that in the response, then it means that they're not going to get skip protection, and they're probably not going to get instant on as well. So this could help, won't tell you what the problem is, but it can kind of get you closer to determining what the problem is.

All of that information, starting with the V equals sign and all the way down to the red MPEG, that's the SDP information I was talking about. So this is the description of each track of the movie, the format of the movie, all that kind of stuff. Not that useful for troubleshooting usually, but sometimes.

Setup request is a request that the client makes after-- so the first request it makes is that describe you saw, which is basically the client saying to the server, tell me about this movie at this URL. Comes back, client looks through all of that SDP information, and it decides which tracks it wants to play.

It doesn't have to play them all. And then it sends a setup request for each track that it would like to play. So if you look at the setup request, look at the red areas. Track-- it's saying here that I want track three of the sample 300k bit movie.

Another important thing is that it's telling you which ports that it would like you to send media to. This can help you dealing with firewall issues. This is the client telling the server, "Send data to me on these ports via UDP." And then, it won't help with troubleshooting, but in the response there you'll see this X random data, and then underneath that you're going to see about 1400 bytes worth of random data.

Don't be disturbed by that. So basically what that is, that's part of our skip protection technology and the instant on technology. We do some active bandwidth measurement, and this is one of the ways we kind of determine bandwidth. We kind of send this random probe packet out there, and then we measure the time it takes to get back, and that helps us to determine bandwidth. Okay, so that's RTSP. Now, RTCP, these are the status packets that go back and forth. These are coming from the client. How do I know that? It says app right there.

It's got all kinds of information in it. Some of it useful, some of it not. But it's going to show you. And these things come over often, every five seconds to 30 seconds or whatever. It depends on basically which player you're talking to. It'll show you the bit rate of the client, the number of packets received, the number of packets dropped.

And you can kind of monitor these things in real time if you wanted to. It's a little difficult. You'd probably have to write a tool that actually parsed all this output and monitored things. It's a little difficult. You'd probably have to write a tool that actually parsed all this output and monitored things.

So the server supports a protocol that lets you talk to it directly via HTTP to set and get its attributes and to get basically its status. The server is an object-oriented. It's written in C++ inside the server. If you know anything about programming, there are all kinds of objects, and there's this whole hierarchy of values that you can grab out of the server.

Because it's HTTP-based, though, it's really easy to write tools over it. You just send HTTP requests, you get data back, you can parse through it, do whatever you want with it. That's what we use for the web admin. Web admin makes requests, parses it all out, generates HTML, and then puts it up on a web page. The easiest way to deal with it is probably to use Curl for a web browser. If you want to just kind of look at things really quickly without writing a tool. And you use port 554 for this. It's pretty straightforward, though. Here's what a request looks like.

It's authenticated, so you need to provide a username and password, and then your host name, and then an attribute path. So, as I said, the server's very modular and object-oriented. This is kind of the standard path to get to an attribute that belongs to this, actually to the server itself.

So, modules, admin, server, movie folder. Here are some Curl commands. I'm going to actually go over and do a couple of them over here. That's what commands would look like. That star that you see there, we can flip back over here. Thank you. So first let me kind of show you curl. So curl is basically just a command line, like, Client for making requests.

It can do HTTP, FTP. I mean, what it does is it just returns things in raw format. It doesn't try to format it at all. So if I were to curl www.apple.com in a new terminal, because I spewed too much stuff into that one. I'm going to get back Apple's website in HTML form. So that's basically what curl does. I'll clean that up.

So if I wanted to talk to streaming admin server, I would use curl, use the format that I talked about. Now, notice at the end I put a star. Star is a wild card. That means show me everything inside the server object. I hit that. It's going to ask me for the password.

There is all kinds of stuff in here. Some of this is If you're familiar with the QuickTime Streaming Server programming APIs, you probably understand what some of these are. I'm sure most of you are not. It's showing me all kinds of things in here. The current bandwidth of the server, the total connections that it's ever served since it's come up, the current bandwidth. If I really wanted to get... Stephen Tonna, Chris LeCroy, John Anderson A server client sessions. I'm still using the wildcard there because I want to see all of the sessions. And I probably don't have any because I think our... Yes, it didn't find any.

So basically with that, I'm not going to continue because I think this is probably not that interesting to people, but it would show you a list of all of the current connections. They would all have an ID attached to them, and then if I wanted to dive down further, I could say, okay, I want to see session number X. It would show you all the attributes for that connection.

So you can remotely monitor your server, remotely troubleshoot your server, and actually look at what's happening on the server with all of the clients. Okay, how many people are asleep? Okay, so kind of closing things down here. So for more information, we've got the roadmap here. A couple of QuickTime sessions, 720 and 722. They did cancel the session Wi-Fi and 3G. Let the Games Begin has been canceled.

Tomorrow, if you want to be probably a little bit less bored, but it is definitely more technical, the QuickTime Streaming Server programming session is going to happen tomorrow. If you're an open source programmer that wants to learn about modules, you should show up. If you just want to know where to start when you're working on the server, our open source project is available to you to modify as much as you like, as long as you abide by Apple's open source license. John Murata, our lead engineer on the server, is going to go through the entire architecture of the server and kind of walk you through how to get started on actually modifying the actual source code on the server.

We've got a bunch of QuickTime sessions. Kind of one to note is the producer listening party with QuickTime. You're going to see probably a little more QTSS publisher there, and John's going to do an MP3 playlist that actually works, I think.

If you need to contact anybody about QuickTime Streaming Server, anything QuickTime, [email protected]. Guillermo Ortiz is your man. Documentation. I don't see it on here. Let me back up.

Okay, I won't back up. But if you're not aware of this, we have a couple of mailing lists for the streaming server. We have a user's mailing list and we have a developer's mailing list. The developer's mailing list is mainly for people who are actually doing coding on the server, writing plugins, although a lot of administrators are there too.

And then the user playlist is more for system administrators and people who are deploying the server. Go to lists.apple.com, just search for streaming, and subscribe. They're great lists. They have massive amounts of good information. Browse the archives if you want to see what I'm talking about. And we're all on the lists and we try to be as responsive as we can.