I'm Chris LeCroy, I'm the engineering manager for the streaming server. I've been doing that for about three years, I guess. I'm going to talk to you at a high level about the QuickTime streaming server. Some of the things I'll talk about are, kind of explain what the servers do, what they are. I'll give you some status on our latest version. I'm also going to give you an overview of some of the functionality and some of the typical configurations of the server.

Which is something that's in the documentation, but it might be nice for me to get up and actually talk about it a little bit. I'll give a real high level overview of some of the streaming protocols. Which is important because it's actually possible to write tools around these protocols that will interact and interoperate completely with the streaming server and the streaming client. I'll also mention a couple of ways that you can extend the streaming server. Go through a few of the development opportunities and then just kind of talk about our general future direction.

So what are the QuickTime Streaming Server and the Darwin Streaming Server? It says three servers in one, but actually it's more than three. But the three major things we do are video on demand, which basically allows you to serve stored content off of a hard drive. It's a lot like a web server serving static HTML, except the server streams movies instead of serving up HTML.

The server does live stream reflecting. And what that means is that you've got a broadcaster or some kind of an input source sending media to the server. And then the server reflects that out to a massive number of clients, thousands of clients. We also do something we call simulated live using our playlist broadcaster feature.

And what that allows you to do is to have stored content on the server and have that broadcast kind of in a delayed fashion as if it were a live broadcast. It's really good for doing delayed broadcasts obviously and also for doing things like setting up internet radio stations. You can actually create playlists of songs or of videos and play that out to the server as if it were a live stream. The server is completely standards based.

When we decided to get into the streaming server business, we kind of took a look around and decided that we didn't need another, a third proprietary format. So we decided to go completely with standards. And we actually believe in it's standard. Believe in it so much that Apple is one of the founding members of the Internet Streaming Media Alliance, which is an organization whose charter is basically to make sure that MPEG-4 streaming and MPEG-4 in general works in an interoperable fashion between different vendors. The server scales really well.

On a single processor machine, we can do over 2,000 concurrent off of disk movies or off of disk connections or streams. And we can do well over 3,000 when it's reflected from a live broadcast. That's on a single processor machine. There are also ways to kind of tie machines together and do even larger broadcasts.

The Relay feature allows you to set up a collection of machines so that one relay can relay out to other relays, which allows you to do instead of maybe 2,000 clients, you can have 10 machines and do 20,000 clients. and we of course support UDP. UDP is, for those of you who don't know, is kind of the sister or the brother to TCP, except that it's not reliable. And that's the normal way to stream media using RTP, which is a standard protocol.

We also can tunnel over HTTP, and the reason we do that is is to allow streams to get through firewalls that are not configured to allow RTP traffic to come through. So basically a request will look just like an HTTP request to a firewall or to a proxy. And everything, all the media can get through without any trouble that way. The IS people love us for doing that.

The QuickTime Streaming Server and the Darwin Streaming Server are also open sourced. So a point of confusion for a lot of people has been that they're continually asking, "What's QuickTime Streaming Server and what's Darwin Streaming Server? What's different about these two?" And the answer, especially as of the latest version, is that there's absolutely no difference whatsoever. We simply use QuickTime Streaming Server as the brand name for the Mac OS X version of the server. And we use Darwin Streaming Server to refer to any other platform that the server runs on, and to the open source project.

So we build obviously for Mac OS X and we ship a binary for that. We also build binaries under the Darwin name for Linux, Solaris, FreeBSD, and Windows NT 2000. And we actually build these things and treat them as a first class citizen in terms of being equal to Mac OS X. We do test those versions of the server. We do put effort into making sure that they perform well. So you can download the binaries and you can be assured that it's at least as good as Mac OS X. Thank you.

In addition to that, because we're open sourced, developers have ported the Darwin Streaming Server to a wide variety of platforms. Basically every major platform you can think of. It's been ported to Mac OS 9 by some people in Brazil. It's been ported to SGI's iRix. It's been ported to Hewlett Packard's HPUX. Compaq ported it to their True64 operating system. It's been ported to basically every flavor of Linux in the world.

It's available on almost everything. I think I heard something about a BOS version, but I'm not actually sure if that's out or around right now. And because it's open source, we... Also make the source code available to the public in kind of two forms. You can download the source code for any GM version just as a tarball. So you've always got a copy of the GM version of the source code.

In addition to that, we actually do our development in a public CVS repository. So if you were to bop over to our CVS repository right now and do an update or a checkout from there, you'd actually get code that's in progress by the Apple engineers and various Darwin developers. It's a great way to help us out.

You can download that stuff. And if you see a bug, fix it for us. If there's been a bug, we'd be happy to roll it into the CVS repository for you. So where are we at today? probably all know that we just released QuickTime Streaming Server 3.0 this week.

It's available for download on the web as an installer, and that can install on Mac OS X desktop or Mac OS X server. But it's actually already included with Mac OS X server as one of the standard services on that package, or on that product. And of course, we've got all of the Darwin binaries up there for download as well for all the various platforms that Apple actually builds on.

What's new in 3.0? I'll give you a high-level overview of each of these. I'm going to go into detail on each of these in a second. Skip protection is a new feature. It's actually not a feature. It's more of a collection of quality of service enhancements that we've added to the server.

It's an ongoing process for us to always improve quality. We've added a web-based administration to the server. If you're familiar with Streaming Server 2, we had for Mac OS X a little Cocoa-based app that did some limited administration. It looked nice. It was aquafied. But for the other platforms, configuration basically meant that you needed to get over to the server, tell it in, modify some text files, stop the server or send a SIGHUB to the server, and hope you got everything right, hope you didn't screw up the config file.

And we decided that that was too complicated, so we decided to do a UI for all platforms. We've strengthened the other features. We've added authentication. And by that I mean authentication that happens when a client tries to connect to the server and access a movie that's been protected.

And we've also, in conjunction with QuickTime 5, added some APIs that allow you to do live broadcasts and to do basically encoding from an input source, broadcast that out to a server. So we support that, and we support some of the new features they added, such as announce support. I'll get into that in a second. And broadcasting via reliable transport. We've also done a couple of API enhancements that I'll talk about, too.

So skip protection. If you guys were at the keynote, you probably saw Avi do the demo where he had two movies up side by side. He pulled the plug, which was intended to simulate packet loss. The old 2.0 version of the stream stopped, and the 3.0 version just kept on going. There are a couple of things that we did that allowed that to happen.

So the first thing that we do is we now do intelligent retransmission of lost packets. Basically, the client is continually telling the server which packets it got and lost, and the server makes some decisions based upon whether there's enough bandwidth, whether the packet's really important, or whether the client will even be able to use it. It may be too late to even retransmit. So it does some intelligent retransmission there. In conjunction with that, we actually do congestion avoidance in our algorithms.

We don't just blindly retransmit things, and the reason we do that is that if the server's being notified of packet loss, and we just start retransmitting more data, and it turns out that the packet loss is caused because there's not enough bandwidth or there's a congested link somewhere on the net, all we're going to do is exasperate the problem. So we try to be really smart about what we actually retransmit. In conjunction with this, we do something we call over-buffering. And what that is is basically sending the media. We send the media at faster than real time.

And the reason we do that is that typically you've got a three-second buffer in the client, and what over-buffering allows is for us to stretch that buffer out, and it gives us a lot more time to perform retransmit. So instead of performing retransmit up in this little three-second buffer, we may have up to 25 seconds to do a retransmit, which gives us a lot of time to recover from just temporary conditions on the internet and things like that.

So over buffering is cool, but you don't want to just like send things as fast as you can. We actually need to know how fast of a connection each client has. So we have something, we've built some technologies into the server that actually can detect the available bandwidth for each of the clients that are connected. And we use that when we're doing the over buffering.

In addition to that, we've improved our thinning algorithms. And what thinning is, is there are situations where There just isn't enough bandwidth and somebody's asked to watch a movie that maybe requires 44k but their modem is only running at 40k. So what thinning is, is a mechanism where we actually select packets based upon their priority and just don't send those. And the idea there is to decrease the bandwidth of that stream so that the client gets at least some semblance of a usable stream.

In the past with 2.0, the shifts when we were doing thinning were pretty abrupt. You'd see a movie, it would look like crap. We would thin, it would immediately go to a slideshow. If that didn't work, we'd go down to audio. And basically we've just kind of smoothed that progression a little bit.

And skip protection is, like I said, it's not a feature. It's just our umbrella term for quality of service enhancements to the server. And the things we've added for 3.0 are just the beginning. We plan to do quality of service enhancements for every release of the server moving forward.

An obvious goal is to get the broadcast quality at some point. And even beyond that, better than broadcast quality. There are some things we think we can do with interactivity and just really high quality video, high resolution video that we're going to be looking into over time. It's going to take a long time, obviously.

Next new feature is our web-based administration. And one of our goals with kind of from the beginning with this server is that we wanted to make it extensible for developers and we wanted it to be easy to extend. So we kind of took that philosophy to heart when we did the web-based administration.

And the way this works is we implemented it as basically a collection of HTML that contains some tags in it and some Perl scripts that know how to parse those HTML files and read those tags, make a request off to the streaming server for data, and kind of reformat the HTML so that it looks like normal HTML on the web browser.

We built kind of a mini web server based on Pearl, which is just a very simple little web server for actually talking to the web browsers. The web browsers never talk directly to the streaming server. And as I said, it's extensible just by replacing some of the -- in simple cases, just adding some additional HTML with whatever tags. In more complex cases, if you've got some complicated data that you need to parse, then you might have to write a little Pearl CGI that does the parsing for you. And of course, it's secure. The little mini web server actually does SSL.

And I probably have this upside down, don't I? Okay, and here's a screenshot. I'm actually gonna demo. I was gonna show you just a screenshot, but I decided that a demo might be better. Just going to quickly show you a couple of the features in the web-based admin. So this is kind of the initial screen. It's basically just a snapshot of what's happening with the server. Hopefully you guys can all see that in the back.

If I had a lot of, I could check my CPU load here, I can see how many bytes have been served, I can see how much bandwidth is going out. Kind of a convenient thing. Here are some of the general settings here. You navigate just by moving through these tabs.

and you can view the logs in the admin. Here's an error log, lots of errors. And another thing we added is UI for the Playlist Broadcaster. If you guys are familiar with that, you'll actually like this. In the past, you actually needed-- setting up the playlist broadcaster on all platforms really consisted of modifying multiple text files and people inevitably got it wrong. And so we've added UI here. Basically, you can create a new playlist.

Here are all the movies listed down here that are in this playlist. You can tell it how you'd like it to play, sequential, weighted random. You can tell it to turn logging on, things like that. And then turning this on or off is just a matter by clicking the little play button here. and the broadcast automatically gets started up and automatically starts talking to the server and you've automatically got your internet radio station or your broadcast happening at that point.

I guess you guys hated the text files, huh? Announce support. So like I mentioned, QuickTime 5 has added, they've made the broadcaster APIs public. So in the past we had, there was one broadcaster, it was Sorenson, and the way that worked is that you would set up your broadcast, plug your camera in, you'd have the Sorenson broadcaster generate an SDP file, which is a file that had basically a description of the session, you would, So, you have to take that file, get access to the server that you're going to broadcast to. In a lot of cases, you actually had to go in and modify the SDP file, which meant that you needed to understand the SDP format.

After that, you would start the broadcaster up and typically it wouldn't work the first time. You'd look at your SDP file, figure out what's going on. Basically, it was a mess and we didn't think it was easy enough. So we decided we needed to automate that. So we've added some support to the broadcaster APIs to use standard RTSP and to use the announce method in RTSP. And what that means is that all you need to do now is type in an IP address on the broadcaster application.

Specify the name of the broadcast and press start. At that point what happens is the broadcaster will send all of that information that was originally in the SDP over to the server. The server will say, first of all it will ask are you okay to do this and actually authenticate the broadcaster. The reason for that is you don't want to have anybody being able to broadcast to your server.

Once it decides that the authentication is okay, it will let the broadcaster know things are cool, go ahead and send me over all of the information that I need. The broadcaster will start broadcasting and you're done. Basically it's type in a couple of fields, push a button, you're done.

In addition to the announced support for broadcasters, there was a problem with the original broadcaster broadcast only on UDP. And as I mentioned, UDP is a non-reliable transport, which means that packets can get lost. So that's a minor problem when you're a client watching a stream and one or two packets get lost and then everything's fine after that. It's a major problem when a broadcaster is sending data to a reflector and it loses packets because then every single client loses those packets.

So we decided we needed to have a reliable transport. And we decided to just go with TCP rather than doing anything real complex. The second problem with using TCP is that the buffer sizes are typically too small. So with reliable broadcast, the broadcaster is actually able to tell the server how large it would like its buffer. So it can tell the server.

I'd like a one-minute buffer. And what that allows is for situations where TCP gets into congestion problems or maybe a little flow control problem, it gives the broadcaster plenty of time or the TCP stack plenty of time to get caught up and make sure that basically all the packets get through and everybody's happy. Which means that all of your clients will receive a much better quality stream in the case of packet loss between the broadcaster and the server. So those are the new features.

I'm going to talk about some of the typical configurations that you can put the server into. The thing to note is that these are not modes that the server goes into. The server can be configured to do any one of these or all of them at the same time. These are just different ways the server can be operated. We've got video on demand, simulated live streaming, and a more advanced configuration is relay streaming. Relay streaming. So I'll go into those in more detail. I actually have pictures here for you guys to look at.

So probably the most typical form of streaming is stored media streaming or video on demand. And this is actually, as I mentioned, just like, or it's analogous to web servers serving static HTML. Basically, all you need to do is take some hinted movie files, drop them into a directory on your server. The client will make a request to the server just using a URL. It looks like an HTTP URL except it says RTSP. Server will go out, try to find that movie and then just begin streaming it to the server.

And as I mentioned, these movies need to be hinted. And what hinting does is it takes a standard QuickTime movie and it adds some additional track for each track in the movie. It adds an additional track and that track basically contains information that the server uses to determine which blobs of media to put into which packets and what time to send them out. So one of the big advantages of that is that it allows the server to be completely agnostic about media formats. That's why we're able to stream media on a Linux server or a FreeBSD server where QuickTime APIs don't exist and the codecs don't exist.

Next configuration is live streaming, which adds a couple of pieces to the puzzle. First, you need a camera or some form of an input source. And what you do is hook that camera up to an encoder broadcaster machine. And the job of the broadcaster or the encoder is to obviously encode the incoming stream and then to packetize it into RTP format and send it off to a server or a client. So in this picture, though, you'll see that it sends it off to a server, and there's a really good reason for that. You technically can send things directly from the broadcaster, but you can't send things directly from the server.

So decoding and encoding can take quite a bit of CPU, and so it's really not a good idea if you want to scale to any more than a few clients. So what happens in this case is that the encoder encodes one stream and broadcasts one stream to the server, and then the server, which has hardly any load on it because it's not doing any encoding, can broadcast out to thousands of clients.

Simulated Live. This is the playlist broadcaster I just showed you. And the way that works is kind of a combination of live streaming, not really, and video on demand. And the way it works is you put your hinted movie files onto the hard drive of the server and you create a playlist, which can be either a single movie or unlimited number of movies. And then there's a little tiny process that runs for each playlist on the server machine itself.

And it basically goes through and parses those files, reads the hint tracks, and then streams those things in local loopback to the streaming server, which then broadcasts that out to all of your clients. So what this looks like from a client perspective is a live feed, even though it's really not.

They're not going to be able to thumb back and forth in the movie. They're all going to see the same thing at the same time. And it's really useful for doing things like delayed broadcasts. Let's say you've got an event that you pre-recorded. You can drop that on the server, create a playlist with that individual file in it, start it up at whatever time you want to start it, and then everybody can tune in.

And then as I mentioned, it's also really good for creating things like internet radio stations. If you go to -- actually go up to Apple's QuickTime TV site and look at Warner Records, for example. They've actually created kind of a mini-MTV using the playlist broadcaster. It just shows video after video throughout the day.

and more complex, and probably doesn't affect most of you, but it can certainly affect some of you, is a configuration we call relay streaming. And relay streaming is used for live or simulated live, and it's used for allowing you to do events that are much bigger than what one server can handle. So basically we've added just another layer between the server connected to the encoder and the client.

So you've got the live stream coming into your relay server, and instead of that server broadcasting out to clients, it broadcasts out to other servers, which means that you can have, instead of one machine doing 3,000, you could have maybe 10 machines doing 30,000 concurrent streams. So it allows you to do really large events.

This is effectively what companies like Akamai and Digital Island are doing for their live events. I don't think they're using our code, but they've got something that looks really similar to this. So I'm going to go over kind of the three major protocols we use really briefly here.

First one is RTSP, and it stands for Real Time Streaming Protocol. The second one is RTP, and Real Time Streaming Protocol actually is kind of the control mechanism from the client to the server. It lets the client tell the server what to do. Real Time Transport Protocol is the protocol that the media is actually sent on, and that operates under UDP typically. It can be on TCP. We do both actually with HTTP tunneling.

And RTCP is Real Time Control Protocol. It's actually used by the – the way it works is that the client uses that protocol to tell the server how things are going. Is it losing packets? Is there network jitter happening? Things like that. And I've got a little picture here that'll – RTSP is based on HTTP.

It actually looks almost identical. The difference is that instead of HTTP in the header, it'll say RTSP. And instead of methods like GET and PUT, it'll have methods like PLAY and PAUSE and DESCRIBE and SETUP. RTP runs on a different port. RTSP typically is on port 554. RTP happens on a different port from the server. And that's the stream that the media actually gets streamed on.

RTP is basically the way the packets look. It's pretty simple. It's just got a little header on the top of the packet that is in RTP format and then a blob of media. The client knows how to decode that media once it gets it or de-packetize it. RTCP, as I mentioned, is a status channel from the client back to the server. And that's what the server actually uses that for doing all of the quality of service features that I talked about with skip protection. That's how we get notified that packets are getting lost and which packets are getting lost. Whoops.

Here's an example session. I think you guys can read that. So I'm going to walk through what happens when somebody presses the play button on a movie. So the first thing that happens is the client will send an RTSP describe request to the server. That contains just a URL, basically. And the URL looks a lot like an HTTP URL.

It will have the server name, slash, and then a path to the movie. And the server responds to a describe request with information about that movie. And the information that it responds with are things like the number of tracks, what types of media each of the tracks are, maybe the bit rate of each track, the language of the tracks, things like that.

So once the client's got that information, it can then make a decision about which tracks it actually would like to listen to. For example, you might have a movie that's got a single video track and three language tracks, Spanish, English, and French. The client will then send a setup request for each of the tracks that it actually wants to listen to.

So in this case, it's going to say, "I'm going to send back a setup for the video track and a setup for one of the audio tracks that it would like to hear." server will respond with OKs to both of those. And then the client sends a play request which tells the server, OK, now start streaming me the things that I asked you to set up. At that point, media just gets sent out over RTP. Everybody's happy.

Nothing more happens until the stream either ends or the client sends either a teardown request if the movie wants to be completely shut down or somebody presses the pause button and they just want to pause the movie.

There are a lot of ways to extend the streaming server. I think it's pretty clear that the QuickTime streaming server is easily the most extensible streaming server in the world. There are other servers out there that are not typically extensible other than maybe some module APIs. We have a lot of ways to extend.

The most obvious way is that the source code is all available. You can take the source code and do whatever you want with it. We have source for the server. We also have a proxy server that we have source for. All of the source code is available for the admin that we added for 3.0. The only issue here is that Apple's got a license we call the Apple Public Source License. What that license says is if you're going to make modifications to the core code of products that are open sourced by Apple, we just ask that you send it to us.

We send those changes back so that we can share them with the rest of the open source community. Other than that, you're free to do whatever you'd like. And a lot of times you might make changes that have no meaning to us, and we're not going to roll that into the server, but you still need to post that so the public can see it.

There's a way to get around that with the streaming server though. Because we recognize that there are companies that are going to want to build things that have some really strong intellectual property value or are just proprietary and they don't want other people to see it. The way to do that is to build a module that attaches into the server. And the reason it doesn't fall under the APSL is that you're not modifying any of our source code, you're actually just writing brand new source code that belongs to you.

The plugin API that we use for these is really similar to the Apache plugin API, if you're aware of that. It uses concept of roles and callbacks during different states in the server. There are two ways to build modules. You can build them as dynamic modules. And those are basically standalone little shared libraries that you drop into a directory. The server auto-discovers those, asks them to register for their roles, and away they go.

Or you can compile the module directly into the server. And then it just becomes a module. It becomes a part of the single server binary. And in fact, most of the server features are implemented as modules. So things like the ability to reflect live streams as a module, error logging, access logging, authentication, the module that lets the web-based admin work, those are all done as modules that are just built into the server. We think we did a really good job of making sure that that API or that architecture was really high performance because we use it.

This session covers the latest features of Version 3.0 of the Darwin Streaming Server. Chris LeCroy is basically a way to get and set attributes in the server using simple HTTP requests. And the requests will basically have a URL to the server, and then maybe some parameters at the end that tell the admin module whether you want to get a value, set a value, delete a value, things like that. And this is what the web-based admin uses this primarily. So the things that can be built around this are, like, I'd like to see somebody write some really cool monitoring applications. They don't have to be written in Perl or anything like that.

They can be written in any language because it is just straight HTTP. Maybe some advanced configuration or advanced administration applications, things like that. The kind of last way to extend the server I want to talk about is...

There are a couple of really good reasons for doing this. First one might be that maybe you don't like our admin. Maybe you want to repurpose it for your corporation or you want to repurpose it and sell a product to somebody. You can just take the existing admin and modify it.

Probably a more common reason to extend it would be that you write a module for the server and you want to have some user interface for your module. So what you can do is just create some HTML files with the special tags, possibly write a Perl CGI, drop it into a directory and it will automatically appear in the user interface along with all of the UI that we've written. It basically becomes a first class citizen in the admin. It might show up as an additional tab in our admin or something like that. Yeah.

and all of these ways of extending the server. There's a session immediately following this, and we'll have some streaming server engineers up to show you how to do each of these extensions. See a little bit more of the web admin and a little bit about the API as well as how the admin protocol can work.

So, development opportunities. So we don't have... A gigantic team at Apple working on the streaming server. So we can only do so much. We think we've done a really great reference server. We think it's a really high-performance server. But there are, like, hundreds of features that we're just never going to be able to get to because we don't have enough people to do it.

We do have, on the other hand, 500 Darwin developers that are building things around this thing. So we really want to get developers out there building things around this, possibly building the server and repurposing it as your own product. We actually really promote that. As long as you follow the Apple public software license, there's actually absolutely no issue with doing that.

You can take the server, port it over to your device, and then you can go There are also a bunch of plug-ins we'd like to see written. So we have some really basic authentication in the server.

I'd like to see a module that does some authentication with a stronger back-end authority maybe or with a database of user accounts. It's also possible to write modules that use a database as the means of storage for all of your content. I think that's kind of a vertical market, but there's definitely an opportunity to do that. And I think that's a great way to do that.

And of course you can do additional logging and reporting modules. And maybe a cool feature would be, or a cool product would be to kind of build an entire broadcast system for internet broadcasting, similar to what TV stations use. They've got software that manages all of the scheduling and which content to serve and add-in solution and things like that.

And it might be interesting to see somebody write some modules into the server that do that and kind of go after that vertical market. And as I mentioned, monitoring tools via the admin protocol. Admin protocol's new, so I hope to see a bunch of those coming out. And of course web-based administration extensions, possibly. Do a web-based admin that's purposed for some corporation and sell it into the corporation, things like that.

So our future directions are actually pretty simple. We plan to continue working towards standards and to support standards. We actually work with the IETF to extend the protocols when we think that they've got some limitations. A good example of that is that we recently proposed an internet draft to the IETF that makes it possible to write streaming caching servers that work much better with streaming media.

Nobody else has done this, and it was something that was desperately needed. Basically the streaming caches were at the mercy of the network. They didn't have any information coming to them about packets that were being sent to them or ways to get the media sent to them in a reliable fashion. And so we worked on an extension with the IETF to do that.

As I mentioned, Apple is also a founding member of the Internet Streaming Media Alliance, which is basically an MPEG-4 alliance, and we are big on making sure that MPEG-4 works with all of the different vendors, and I think you're going to see a lot of MPEG-4 coming out of Apple over the next year. And of course we plan to continuously improve quality and of course performance.

Sometimes we get lucky, we get a really fast machine and that helps us automatically, but we're continually looking at the software and looking for ways to make the software perform better. And of course we'll always be looking at adding new features and looking for other leading edge technologies to add into the server.

So there are a few places that you can go to get more information about the streaming server. The first place, or maybe the second place or third place, I'm not sure, depends on you, but we have a mailing list for developers. And that list is actually a really high quality list. I've gone on a lot of mailing lists, some of them are not high quality. This one is good.

The traffic is probably between 5 to 20 messages a day. They're all very focused and very development related. It's a great way to have contact with the engineers because all of the engineers and some of the marketing people are actually on this mailing list and monitoring and replying to questions.

The best way to get to it is to just go to lists.apple.com and search for the word "stream." You'll find the developers list and you'll also see a users list, which is interesting too if you want to find out what users are doing or if you want to become a user and figure out how to use the server better. All of the open source information, the Darwin versions of the server, are all available on Apple's open source website at www.opensource.apple.com.

and for things that are more client related or authoring related, you should go to Apple's developer site for QuickTime. That's developer.apple.com/quicktime. Even though you may not ever write any networking code, it's actually a good idea to understand what the protocols do and how they work. And so go to the IETF site and check out the RFCs for the major protocols we use. RTSP is 2326, RTP is RFC 1889, and SDP is 1998.

And here are the sessions that are remaining at WWDC that are related to the streaming server. So immediately following this session in this room, you don't even have to get out of your chairs, is a session on how to customize and extend the streaming server. And we'll have some streaming server engineers up for that.

There's a feedback forum tonight at 3:30 in room J1. And that's going to be -- that feedback forum is actually intended for both QuickTime client and server issues. It's just kind of an uber QuickTime feedback forum.

If you need to contact anybody with developer related questions, you should contact Jeff Lowe. He's the QuickTime Technology Manager for Apple Worldwide Developer Relations. His email is [email protected]. He also handles both QuickTime server and client.