: Refer to Chapter 12, "Splitting Live Presentations," in the RealServer Administration Guide for instructions on setting live stream security as well as configuring your transmitting server for pull splitting using the RealSystem Administrator utility.
: The RealServer Administration Guide is available online at the following web address:
: http://service.real.com/help/library/guides/server8/realsrvr.htm

If a pull-split listen port other than the default (2030) will be used, the manifest file for the hosted domain should identify the port to be used along with the host name under the server definition.

: For example, if port 2070 were to be used, the manifest file would read:

<server name="transmitting-server">

<host name= "10.89.1.1:2070"/>

</server>

: If no port is defined after the host name, the default port is used as the listen port.

The Security Type parameter is set to None.

Configuring WMT Publisher for Live Streaming

To serve live content using Windows Media Services over your CDN, make sure the following conditions have been met:

Windows Media Services are installed and running on your origin server.

: If you are running Microsoft Windows® 2000 Server, Windows Media Services is included. Otherwise, download Windows Media Services from the Windows Media Web site at the following address and then install it:
: http://www.microsoft.com/windows/windowsmedia/default.asp
: Directions for installing Windows Media Services can be found at:
: http://www.microsoft.com/windows/windowsmedia/serve/wms_install.asp

Your firewall has been configured to allow traffic to and from the Windows Media servers and clients.

: Generally, content streamed using TCP Unicast uses TCP port 1755 for traffic in to and out from the Windows Media servers, while content streamed using UDP Unicast uses TCP Port 1755 for traffic in to the Windows Media servers and a UDP port between 1024 and 5000 for traffic out from the Windows Media servers.
: However, different configurations exist depending on your own network and firewall configuration. Refer to the Microsoft documentation on "General Protocol and Firewall Information" for Windows Media Services online at:
: http://www.microsoft.com/windows/windowsmedia/serve/firewall.asp

A publishing point for live streamed content has been created. With live content, the Windows Media Encoder is used to encode directly from the source (that is, a live video feed) to a publishing point. Each requesting client receives a separate live stream.

: Refer to the Microsoft documentation on configuring Windows Media Services for live unicasting online at:

On-Demand Caching Web Site Content

This section explains the steps necessary to publish content on your CDN and to create functioning links to CDN content on your web page. This section contains information on the following topics:

For all example URLs, refer to the sample manifest file provided in Example 3-2.

Caching Content on Your CDN

To place content on your CDN, you must alter your web site content URLs to point to your CDN hosted domain.

For example, if your web site contains the following content URL:

http://www.cisco.com/images/logo.gif

You can place the content named on your CDN hosted domain, http://www.elearning.cisco.com by modifying the original URL to read:

http://www.elearning.cisco.com/images/logo.gif

When a user visiting your web site requests the page on which the logo.gif is located, that image is retrieved from the nearest CDN cache. If the image is not already cached on a Content Engine that is assigned to the specific hosted domain, it is retrieved from the origin server and placed in the cache of Content Engines belonging to the hosted domain. Subsequent requests for the image are retrieved from the cache rather than the origin server.

Creating URLs that Link to CDN Content

All URLs pointing to CDN content use the following structure:

http://hosted_domain_name/cdn-url

Optionally, CDN URLs can contain a CDN media tag that force a media play server designation (for example, RealServer, Windows Media Server, QuickTime Server) for the content item using the following format:

http://hosted_domain_name/cdn_media_tag/cdn-url

Links rely on playserver mappings for each type of content that is hosted (that is, PDF, JPG, MPG, WMV, AVI, RM). Play server mappings can be found in the manifest file or the PlayServerTable and are consulted by the CDN software using the following hierarchy:

A playserver designation embedded in the actual content URL is checked first.

The playserver attribute for the <item /> tag corresponding to the piece of content is checked second.

The playserver attribute for the <item-group /> tag corresponding to the piece of content is checked third.

If defined, the playserver attribute for the hosted domain in <playServerTable> </playServerTable> in the manifest is checked fourth, according to the following order:

<content-type /> tags are checked first in <playServerTable>
<extension> tags are checked second in <playServerTable>

Though removing CDN media tags from URLs makes the job of modifying web site content for deployment on a CDN much easier, it also requires increased attention to playserver mappings in the manifest file to ensure that all file types being served have been associated with one of the supported playserver types.

The elements of these URLs are described in Table 3-1. Be aware that all URL information is case sensitive—ignoring case sensitivity in your published web pages will result in the CDN being unable to retrieve the requested content.

Table 3-1: Components of a CDN URL

URL Component	Description
hosted_domain_name	Fourth-level domain name assigned to your hosted domain or the alias assigned to that hosted domain. See the "About Creating the CDN Subdomain" section for more information on creating CDN subdomains.
cdn_media_tag	Optional. The media server designated to handle the content item to which you are linking. If no cdn media tag is supplied, the playserver attributes in the manifest file are checked in order of preference as described. CDN-media is used as the default playserver designation and causes the request to be resolved using a playserver mapping in the manifest file. See Table 3-3 for a list of media formats, organized by extension. The following cdn media tags are supported in CDN URLs: cdn-media cdn-real cdn-qtss cdn-http cdn-wmt
cdn-url	Relative location of the content item on the CDN device. This value is supplied by the cdn-url or src attribute in the <item> tag in the manifest file for each piece of content. Wildcard characters are accepted in the cdn-url attribute only when you link to live content. Actual content URLs must of course point to the actual content item.

URLs for Content Served Using Web Server

The web server can be used to serve content that cannot be served using other content servers (RealServer, WMT, or QuickTime). What follows are two examples of URLs for content that will be served using the web server:

http://www.cisco.meetings.com/agendas/q4results.pdf
 
http://www.cisco.meetings.com/cdn-http/agendas/q4results.pdf

In the first example, no cdn media tag is applied in the URL, so the request will resolve to the web server based on a mapping of the PDF extension in the <playServerTable> area of the manifest file.
In the second example, a cdn media tag, cdn-http, is supplied in the URL forcing the CDN software to stream the content file using the designated server.

URLs for Content Served Using RealServer

RealServer Version 8.0 or higher can be used to serve a variety of RealNetworks content types including RealAudio (RA), RealMedia (RM), and SMIL format files, as well as live presentations.

URLs for On-Demand Content Served Using RealServer

What follows are three examples of valid URLs for on-demand (not live) content served from the CDN using RealServer, based on the sample manifest file in Example 3-2:

http://www.cisco.meetings.com/present/q4presentation.rm
 
http://www.cisco.meetings.com/cdn-real/present/q4presentation.rm
 
http://www.cisco.meetings.com/cdn-media/present/q4presentation.rm

In the first example, no CDN media tag is applied in the URL, so the request will resolve to the content server based on a mapping of the RM extension in the <playServerTable> area of the manifest file.

In the second example, a CDN media tag, cdn-real, is supplied in the URL forcing the CDN software to stream the content file using the designated server.

In the third example, the default CDN media tag, cdn-media, is supplied, causing the file to be served according to the <extension> mapping for RM in the <playServerTable> area of the manifest file.

URLs for Live Content Served Using RealServer

Live presentations can be resolved just like any other content handled by RealServer, provided you know the name of the live content in advance. For example, your manifest file might name the following item:

<!--live content item-->
<item src="/encoder/q4live.rm" cdn-url="/live/q4presentation.rm" 
type="live"/>

In this case, your published URL linking to this file might look like this:

http://www.cisco.meetings.com/present/live/q4presentation.rm

However, because many live presentations are not named in advance of when they air, the Cisco CDN software allows you to wildcard references to live presentations in the manifest file in addition to specifying file names in advance.

Wildcarding allows the CDN software to properly map all live RealNetworks streams to RealServer, regardless of name, as long as they carry the proper file extension (for example, RM).

See the sample manifest file provided in Example 3-2 to view the wildcarded mapping for RealServer live content.

If you will be wildcarding references to live presentations in your manifest file, you need to supply the cdn-live tag to any URLs for live content. For example:

http://www.cisco.meetings.com/cdn-live/present/live/q4presentation.rm

The cdn-live tag ensures that a connection is established to the RealServer encoder mountpoint based on the <extension> mapping in the <playServerTable>, even though no exact filename mapping is possible.

URLs for Content Served Using Quicktime Server

QuickTime server can be used to serve a variety of content types including MOV, QT, MP4, and AVI.

Note We recommend mapping AVI files to Windows Media as opposed to QuickTime, due to the easy availability of the Windows Media Player on end user desktops.

What follows are three examples of URLs for QuickTime content that will be served using QuickTime Server:

http://www.cisco.meetings.com/facilities/newHQ.mov  
 
http://www.cisco.meetings.com/cdn-qtss/facilities/newHQ.mov
 
http://www.cisco.meetings.com/cdn-media/facilities/newHQ.mov

In the first example, no CDN media tag is applied in the URL, so the request will resolve to the content server based on a mapping of the MOV extension in the <playServerTable> area of the manifest file.
In the second example, a CDN media tag, cdn-qtss, is supplied in the URL forcing the CDN software to stream the content file using the designated server.
In the third example, the default CDN media tag, cdn-media, is supplied, causing the file to be served according to the <extension> mapping for MOV in the <playServerTable> area of the manifest file.

URLs for Content Served Using Windows Media Services

Microsoft's Windows Media Services can be used to serve a variety of Windows media content types including Windows Media Audio (WMA), Windows Media Video (WMV), and Active Server (ASF) format files, as well as live presentations.

URLs for On-Demand Content Served Using Windows Media Services

What follows are three examples of valid URLs for on-demand (not live) content served from the CDN using Windows Media Services, based on the sample manifest file in Example 3-2:

http://www.cisco.meetings.com/marketing/prodroadmap.asf

http://www.cisco.meetings.com/cdn-wmt/marketing/prodroadmap.asf

http://www.cisco.meetings.com/cdn-media/marketing/prodroadmap.asf

In the first example, no CDN media tag is applied in the URL, so the request will resolve to Windows Media Services based on a mapping of the ASF extension in the <playServerTable> area of the manifest file.
In the second example, a CDN media tag, cdn-wmt, is supplied in the URL forcing the CDN software to stream the content file using the designated server.
In the third example, the default CDN media tag, cdn-media, is supplied, causing the file to be served according to the <extension> mapping for ASF in the <playServerTable> area of the manifest file.

URLs for Live Content Served Using Windows Media Services

Live presentations can be resolved just like any other content handled by Windows Media Services, provided you know the name of the live content in advance. For example, your manifest file might name the following item:

<!--live content item-->
<item src="/encoder/roadmap.asf" cdn-url="/live/prodroadmap.asf" 
type="live"/>

In this case, your published URL linking to this file might look like this:

http://www.cisco.meetings.com/marketing/live/prodroadmap.asf

Wildcarding allows the CDN software to properly map all live Windows Media streams to Windows Media Services, regardless of name, as long as they carry the proper file extension (for example, ASF).

See the sample manifest file provided in Example 3-2 to view the wildcarded mapping (for RealServer live content in the example).

If you will be wildcarding references to live presentations in your manifest file, you need to supply the cdn-live tag to any URLs for live content. For example:

http://www.cisco.meetings.com/cdn-live/marketing/live/prodroadmap.asf

The cdn-live tag ensures that a connection is established to the Windows Media Services encoder mountpoint based on the <extension> mapping in the <playServerTable>, even though no exact filename mapping is possible.

Pre-Positioning Web Site Content

To pre-position content on your CDN, you must create a manifest file that points to that content. A manifest file might point to content in one location on your web server, or name content from a number of different web server locations. Before building a manifest file, however, you first have to know the relative location for all content items that you will be pre-positioning on the CDN.

After you have a list of all the content on your web site that you will be placing on your CDN and its relative location on your origin server, you can generate a manifest file that identifies the content—live or VoD—to the CDN software. See the "Pre-Positioning Web Site Content" section for instructions on generating a manifest file.

Creating a List of Web Site Content

The simplest way to generate a list of web site content is manually. If you have a small amount of content that you will be pre-positioning, or content that is centralized in one or two locations on your web server, you may not need to separately list your web site content before generating a manifest file for it.

If you are pre-positioning only a small, or easily managed amount of content, proceed to the "Creating a Manifest File" section.

Spider Script

If, however, you will be placing all your website content on a CDN, the easiest and most efficient way to generate a list of all the content that must be pre-positioned is to use a spidering tool (called "Spider") to "crawl" your site. The Spider script follows any HREF links back to the content they point to, and makes a record of that content and its location.

For more information on the Spider script, see the "About Placing Content on Your CDN" section.

For instructions on using the Spider script to generate a list of your web site content, or modifying the Spider script to suit the needs of your own web servers, see the "Listing Web Site Content Using the Spider Script" section.

Creating a Manifest File

After you have successfully crawled your web site, reviewed the output from your Spider script, and decided which content you will be pre-positioning, you are ready to generate a manifest file.

This section contains instructions for generating a manifest file and information on the following topics:

The manifest file is an XML-based file that provides powerful features for representing and manipulating CDN data. Manifest files need to be created for each of your hosted domains and exist in a one-to-one relationship with the hosted domain. After reading the manifest file, the CDN software uses its instructions to replicate content from your web server to Content Engines on the CDN that are assigned to your hosted domain.

Manifest Script

The easiest and most efficient way to generate your manifest file is to use an automated script that builds the manifest syntax based on content rules you specify, and use the list of content items generated by your Spider script.

As with the Spider script, Cisco provides a generic manifest generation script ("Manifest") to its CDN customers. Written in PERL, this script can be used to output an XML-format manifest file that conforms to Cisco CDN standards.

For instructions on locating and using the Manifest script to generate a manifest file that points to your web site content, see the "Selecting Live and Pre-position Content Using the Manifest Script" section.

Manifest File Limitations

When generating your manifest file, keep in mind the following limitations:

For versions of the Internet CDN software prior to Version 2.1.1, the manifest cannot contain more than 10,000 content items.
The total of size of all the objects named in any single manifest file for a hosted domain cannot exceed 2 gigabytes. (Live content does not count toward the hosted domain size.)

Manifest File Document Type Definitions

Example 3-1 provides type definitions for the various elements of an Internet CDN manifest file. Details on each manifest file element follow.

Example 3-1: Manifest Document Type Definitions (DTDs)

<!-- CdnManifest - DTD for Cisco iCDN 2.0 pre-positioned content manifest. Copyright (c) 
2001 by Cisco Systems, Inc., Waltham, Massachusetts -->
 
<!ENTITY % playServerTable SYSTEM "PlayServerTable.dtd">
%playServerTable;
 
<!ELEMENT CdnManifest (playServerTable?, options?, server*, (item | item-group)*)>
  <!ELEMENT options EMPTY>
  <!ATTLIST options
            clearlog (true | false) "false"
            rd CDATA #IMPLIED
            prepos-tag CDATA #IMPLIED
            live-tag CDATA #IMPLIED
            notFoundUrl CDATA #IMPLIED
            noRedirectToOrigin (true | false) "false"
            timeZone CDATA #IMPLIED
            manifest-id CDATA #IMPLIED>
 
  <!ELEMENT host EMPTY>
  <!ATTLIST host
            name CDATA #REQUIRED
            proto (http) "http"
            port CDATA #IMPLIED
            user CDATA #IMPLIED
            password CDATA #IMPLIED>
 
  <!ELEMENT server (host+)>
  <!ATTLIST server
            name CDATA #REQUIRED>
 
  <!ELEMENT contains EMPTY>
  <!ATTLIST contains
            cdn-url CDATA #REQUIRED>
 
  <!ELEMENT item (contains*)>
  <!ATTLIST item
            cdn-url CDATA #IMPLIED
            src CDATA #REQUIRED
            server CDATA #IMPLIED
            playserver (real | wmt | http | qtss) #IMPLIED
            type (prepos | live) #IMPLIED
            ttl CDATA #IMPLIED
            serve CDATA #IMPLIED
            prefetch CDATA #IMPLIED
            expires CDATA #IMPLIED
            alternateUrl CDATA #IMPLIED
            streamProperty CDATA #IMPLIED
            noRedirectToOrigin (true | false) #IMPLIED>
 
  <!ELEMENT item-group (item | item-group)*>
  <!ATTLIST item-group
            server CDATA #IMPLIED
            playserver (real | wmt | http | qtss) #IMPLIED
            type (prepos | live) #IMPLIED
            ttl CDATA #IMPLIED
            alternateUrl CDATA #IMPLIED
            cdnPrefix CDATA #IMPLIED
            srcPrefix CDATA #IMPLIED
            streamProperty CDATA #IMPLIED
            noRedirectToOrigin (true | false) #IMPLIED>

Manifest File Structure and Syntax

Table 3-2: CDN Manifest File Syntax

Manifest Tag	Description	Options	Syntax Example
<CdnManifest> </CdnManifest>	Required. The <CdnManifest> tag marks the beginning and end of the manifest file content. At a minimum, each <CdnManifest> tag set must contain at least one item that will be fetched and stored on the hosted domain, and may optionally reference a list of host servers from which content will be fetched. Any number of servers, hosts, and items can be defined, up to a limit of 10,000 items in the manifest file.		`<CdnManifest> <server name="origin-ser ver"> <host name="www.name.com" proto="http" port="80" /> </server> <item cdn-url= "logo.jpg" server="originserver" src= "images/img.jpg" type="prepos" playserver="http" ttl=300/> </CdnManifest>`
<playServerTable> </playServerTable>	Optional. Playserver tables provide a way for you to set default mappings for a variety of media types on your hosted domains. Mappings can be set for both MIME content types (the preferred mapping) and file extensions. Playserver tables allow you to override default mappings on the Content Engine for content types on a particular hosted domain. <playServerTable> tags are enclosed within the <CdnManifest> tags and name at least one playserver, for example, RealServer, to which certain MIME types and file extensions are mapped.		<CdnManifest> <playServerTable> <playServer name="real"> <contentType name="application/x-pn-r ealaudio" /> <contentType name="application/vnd.rn -rmadriver" /> <extension name="rm" /> <extension name="ra" /> <extension name="rp" /> <extension name="rt" /> <extension name="smi" /> </playServer> <playServer name="wmt"> <extension name="asx" /> <extension name="asf" /> <extension name="avi" /> </playServer> <playServer name="http"> <contentType name="application/pdf" /> <contentType name="application/postsc ript" /> <extension name="pdf" /> <extension name="ps" /> </playServer> </playServerTable> <server name="test.origin.com/"> <host name="http://tst.orgn.co m" proto="http" /> </server> <item cdn-url="pic1.mpg" src="pic1.mpg" server="seaotter.sightpa th.com/" type="live" ttl="1" /> </CdnManifest>
<playServer> </playServer>	Required for <playServerTable> tag. The <playServer> tag names a media server type on the Content Engine that will be responsible for playing the content types and files with extensions that are mapped to it using the <content-type> and/or <extension> tags. The <playServer> tag is enclosed within <playServerTable> tags.	name (required) Each <playServer> tag names the type of server to which content will be mapped using the name attribute. Content Engines support four types of playservers: real (RealMedia RealServer) http (web server) qtss (Apple QuickTime) wmt (Microsoft Windows Media)	<CdnManifest> <playServerTable> <playServer name="real"> <contentType name="application/x-pn-r ealaudio" /> <contentType name="application/vnd.rn -rmadriver" /> <extension name="rm" /> <extension name="ra" /> <extension name="rp" /> <extension name="rt" /> <extension name="smi" /> </playServer> <playServer name="wmt"> <extension name="asx" /> <extension name="asf" /> <extension name="avi" /> </playServer> <playServer name="http"> <contentType name="application/pdf" /> <contentType name="application/postsc ript" /> <extension name="pdf" /> <extension name="ps" /> </playServer> </playServerTable> <server name="test.origin.com/"> <host name="http://tst.orgn.co m" proto="http" /> </server> <item cdn-url="pic1.mpg" src="pic1.mpg" server="tst.orgn.com/" type="live" ttl="1" /> </CdnManifest>
<contentType>	Optional. The <contentType> tag names a MIME content type that is being mapped to a playserver. The <contentType> tag must be enclosed within a <playServer> tag set. When both <contentType> and <extension> tags are present in a PlayServerTable for a particular media type, the <contentType> mapping takes precedence.	name (required) The MIME content type of media that will be mapped to the playserver.	<CdnManifest> <playServerTable> <playServer name="real"> <contentType name="application/x-pn-r ealaudio" /> <contentType name="application/vnd.rn -rmadriver" /> <extension name="rm" /> <extension name="ra" /> <extension name="rp" /> <extension name="rt" /> <extension name="smi" /> </playServer> </playServerTable> <server name="test.origin.com/"> <host name="http://tst.orgn.co m" proto="http" /> </server> <item cdn-url="pic1.mpg" src="pic1.mpg" server="tst.orgn.com/" type="live" ttl="1" /> </CdnManifest>
<extension>	Optional. The <extension> tag names a file extension that is being mapped to a playserver. The <extension> tag comes after the <playServer> tag. When both <contentType> and <extension> tags are present in a playServerTable for a particular media type, the <contentType> mapping takes precedence.	name (required) Provides the file extension for a mapped content type. Valid extensions are: Playserver = real rm smi ra rp rt Playserver = http pdf ps asx wax wvx wmx Playserver = qtss qt mov mp4 Playserver = wmt asf wma wmv wm	<CdnManifest> <playServerTable> <playServer name="real"> <contentType name="application/x-pn-r ealaudio" /> <contentType name="application/vnd.rn -rmadriver" /> <extension name="rm" /> <extension name="ra" /> <extension name="rp" /> <extension name="rt" /> <extension name="smi" /> </playServer> </playServerTable> <server name="test.origin.com/"> <host name="http://tst.orgn.co m" proto="http" /> </server> <item cdn-url="pic1.mpg" src="pic1.mpg" server="tst.orgn.com/" type="live" ttl="1" /> </CdnManifest>
<server> </server>	Required (minimum of one host). The <server> tags define a host or set of hosts (or "origin servers") from which content is to be retrieved. The <server> tags are contained within <CdnManifest> tags and contain one or more <host> tags, which identify hosts (server locations) from which content will be retrieved. Within each <server> tag set, be sure to list hosts in order of importance.	name (required) Primary hostname or IP address of the server from which content will be retrieved.	`<CdnManifest> <server name="origin-ser ver"> <host name="www.name.com" proto="http" port="80" /> </server> <item cdn-url= "logo.jpg" server="originserver" src= "images/img.jpg" type="prepos" playserver="http" ttl=300/> </CdnManifest>`
<host />	Required. The <host/> tag (defines a web or live server from which content is to be retrieved for hosting on the hosted domain. Multiple host servers can be defined within a single <server> tag set. The <host> tag must be enclosed within <server> tags. Multiple <host> tags may appear within the same <server> tag set, and should be listed according to their importance, with the most important host listed first.	name (required) Identifies the DNS name or IP address of the host. This attribute may also point to a directory on the host. port (optional) Identifies the TCP port through which traffic to and from the host will pass. The port used is dependent on the protocol used. The default port is 80. proto (optional) Identifies the communication protocol that is used to fetch content from the host. HTTP is the only supported protocol. user (optional) Identifies the secure login used to access the host. password (optional) Identifies the password for the user account required to access the host server.	`<CdnManifest> <server name="origin-ser ver"> <host name="www.name.com" proto="http" port="80" /> </server> <item cdn-url= "logo.jpg" server="originserver" src= "images/img.jpg" type="prepos" playserver="http" ttl=300/>` </CdnManifest>
<options/>	Optional. The <options/> tag is a manifest designation that allows you to specify global settings for the hosted domain using the predefined attributes described in the paragraphs that follow. The <options> tag is enclosed within the <CdnManifest> tags and specifies at least one global setting for the hosted domain. When omitted, default values or <item>-level equivalents are used. If parameters are defined in both the manifest file <options> tag and the <item> tag for a particular piece of content, the <item>-level designation takes precedence.	manifest-id (optional) Specifies a unique, numeric identifier for the manifest file that is used to distinguish it from other manifest files on your CDN. noRedirectToOrigin (optional) When set to false, this attribute allows the CDN to redirect requests for a content item to the origin server if it has not been pre-positioned yet. When set to true, this attribute prevents the CDN from redirecting content to the origin server if it has not been pre-positioned on the hosted domain cache.	`<CdnManifest> <server name="origin-ser ver"> <options timeZone="EST" noRedirectToOrigin= "true" /> <host name="www.name.com" proto="http" port="80" /> </server> <item cdn-url= "logo.jpg" server="originserver" src= "images/img.jpg" type="prepos" playserver="http" ttl=300/>` </CdnManifest>
<options />		timeZone (optional) Specifies the time zone that is used by all content items and item groups on the hosted domain. When not specified, the default timezone, Greenwich Mean Time (GMT), is used. See "CDN Supported Time Zones," for a list of supported time zone abbreviations. clearlog (optional) Determines whether or not the hosted domain log file is purged whenever a new manifest file is received. By default, this option is set to false. When set to false, the CDN software continues to append log file entries to the existing log file even after the manifest has changed. When set to true, hosted domain log file is purged when a new manifest is received.	`<CdnManifest> <server name="origin-ser ver"> <options timeZone="EST" clearlog= "true" /> <host name="www.name.com" proto="http" port="80" /> </server> <item cdn-url= "logo.jpg" server="originserver" src= "images/img.jpg" type="prepos" playserver="http" ttl=300/> </CdnManifest>`
<item />	Required. The <item> tag names a single piece of content on the hosted domain, for example, a graphic, MPEG video, or RealAudio sound file. Content items may be listed individually, or items with shared attributes may be grouped using the <item-group> tag. The <item> tag must be enclosed within <CdnManifest> tags and may also be enclosed within <item-group> tags. Each manifest can contain a maximum of 10,000 items.	src (required) Relative path to the content item on the origin server, starting from the host URL. When no cdn-url value is specified, the src attribute is used in the published content URL. type (optional) Indicates how the content should be handled. Two options are supported: prepos—Content should be pre- positioned on the hosted domain. This is the default value. live—Content is a live broadcast and cannot be pre- positioned. When the type is live, the playserver must be either real or wmt. alternateUrl (optional) Names an absolute path to a content file (for example, an error message page) that is used if the src (source) location is invalid.	`<CdnManifest> <server name="origin-ser ver"> <host name="www.name.com" proto="http" port="80" /> </server> <item cdn-url= "logo.jpg" server="originserver" src= "images/img.jpg" type="prepos" playserver="http" ttl=300/> </CdnManifest>`
<item />		cdn-url (optional) Relative location of the content on the Content Engine. It is possible to use wildcard () values in the manifest file only when the content item is live content (type = "live"). The published content URL must point to the live content item on the live server. The value supplied for the cdn-url* attribute becomes one part of the published request URL that end users see and link to. If no cdn-url value is supplied, the cdn-url is set to the src attribute.	`<CdnManifest> <server name="origin-ser ver"> <host name="www.name.com" proto="http" port="80" /> </server> <item cdn-url= "images/logo.jpg" server="originserver" src= "images/img.jpg" type="prepos" playserver="http" ttl=300/> </CdnManifest>`
<item /> (continued)	(continued)	noRedirectToOrigin (optional) When set to false, allows the CDN to redirect requests for a content item to the origin server if the content item is not yet pre-positioned at the location specified by the src attribute tag. When set to true, prevents the CDN from redirecting content to the origin server if it cannot be found in the hosted domain cache expires (optional) Designates a time in yyyy-mm-dd hh:mm:ss format after which the content item will no longer be served from the CDN. All dates and times are interpreted as being local for the Content Engine. As long as the expires attribute designates a time in the future, the content item will continue to be served from the CDN.	`<CdnManifest> <server name="origin-ser ver"> <host name="www.name.com" proto="http" port="80" /> </server> <item cdn-url= "logo.jpg" server="originserver" src= "images/img.jpg" type="prepos" playserver="http" ttl=300/> </CdnManifest>`
<item /> (continued)	(continued)	playserver (optional) Names the server that will be used to play this media item. When specified, this value overrides any content mapping in the <playServerTable> area. Valid playservers are: real (RealServer) wmt (Windows Media Services) qtss (QuickTime Server) http The CDN software supports live streaming only on the RealServer and Windows Media Services platforms. prefetch (optional) Designates a time in yyyy-mm-dd hh:mm:ss format after which a content item should be retrieved from the origin server and repositioned on the Content Engine. Date and time are local to the Content Engine.
<item /> (continued)	(continued)	serve (optional) Specifies the date and time after which grouped content items can be requested from the Content Engine in yyyy-mm-dd hh:mm:ss format. The default time zone is GMT unless otherwise specified using the <options> tag. server (optional) Identifies the server from which the content item will be fetched. The name specified must match the <server name = ""> value. If omitted, the origin server of the hosted domain is assumed to be the server. This attribute can also be used within an <item-group>.	`< CdnManifest> <server name="origin-ser ver"> <host name="www.name.com" proto="http" port="80" /> </server> <item cdn-url= "logo.jpg" server="originserver" src= "images/img.jpg" type="prepos" playserver="http" ttl=300 /> </CdnManifest>`
<item /> (continued)		streamProperty (optional) For use with Windows Media files (WMA, WMV, and ASF) only. Specifies one or more file attributes that are displayed in the Windows Media Player when the file is played. The supported attributes are: Abstract Title Author Copyright ttl (optional) The ttl attribute identifies the period, in minutes, for which the content item should be controlled for changes before release. The default value is 30 minutes.	`<CdnManifest> <server name="origin-ser ver"> <host name="www.name.com" proto="http" port="80" /> </server> <item cdn-url= "q4results.asf" server="originserver" src= "video/q4results.asf" type="live" playserver="wmt" streamProperty = "author='paul roberts' title='Cisco Q4 Results' copyright='Cisco 02'" ttl=300/> </CdnManifest>`
<contains />	Optional. Identifies other pieces of content that are embedded within the content item currently being described. For example, the components of a SMIL-format file Requests for an item using <contains /> links are only accepted after the CDN determines that all dependent content items are present in the cache. The <contains /> tag must be enclosed within the <item> </item> tags.	cdn-url (required) Identifies the public location for the content item on the hosted domain. The value supplied for the cdn-url attribute becomes one part of the published request URL that end users see and link to. If no cdn-url value is supplied, the cdn-url is set to the src attribute.	`<CdnManifest> <server name="origin-ser ver"> <host name="www.name.com" proto="http" port="80" /> </server> <item cdn-url="house.rp" src="house/house.rp"> <contains cdn-url="img08.jpg"/> <contains cdn-url="img09.jpg"/> <contains cdn-url="img1.jpg"/> <contains cdn-url="img2.jpg"/> <contains cdn-url="img3.jpg"/> </item> </CdnManifest>`
<item-group> </item-group>	Optional. The <item-group> tag names a collection of content items with shared attributes on the hosted domain, for example, a group of graphics on the same host with the same Time To Live (TTL) value. If an attribute is specified in both the <item-group> tag and separately for a grouped content item, the <item>-level attribute takes precedence over the group attribute. The <item-group> tag must be enclosed within <CdnManifest> tags and contain two or more <item> tags identifying content items that share the attributes named by the <item-group> tag.	<item /> (required) Names a content item. Any <item-group> must have at least one content item and no more than 10,000 total items named in a single manifest file. alternateUrl (optional) An alternate absolute path to a single content file, for example an error page, that will be used in the place of the content item if the src (source) location is invalid. cdnPrefix (optional) Names a directory or partial path that is placed in the published request URL immediately before the value named by the item's cdn-url attribute.	`<CdnManifest> <server name="orgsv"> <host name="www.name.com" proto="http" port="80" /> </server> <item-group server="web-server" type="prepos" ttl="300"> <item cdn-url="wild.ram" src="wildlife.ram"/> <item cdn-url="gg.mpeg" src="GoldenGate.mpeg"/> <item cdn-url="jbg.mp3" src="JohnnyBeGood.mp3" /> <item cdn-url="paul.asx" src="fin371k.asx" /> </item-group> </CdnManifest>`
<item-group> </item-group> (continued)	(continued)	noRedirectToOrigin (optional) When set to false, allows hosted domain Content Engines to redirect requests to the origin server if they cannot be found at the location specified by the src attribute. When set to true, prevents hosted domain Content Engines from redirecting requests to the origin server if they cannot be found in the hosted domain cache. playserver (optional) Names the server that will be used to play the grouped content items. This value overrides any content mapping in the <PlayServerTable>. Valid playservers are: real (RealServer) wmt (Windows) qtss (QuickTime) http Live streaming is only supported for real and wmt. See Table 3-3 for a list of files supported by each playserver.
<item-group> </item-group> (continued)	(continued)	server (optional) The origin server from which the grouped content items will be fetched. The name specified must match the server name in the <server> tag. srcPrefix (optional) Names a directory or partial path that is used to build a directory structure for the items in the content item group. The value specified by the srcPrefix attribute is placed in the published request URL before the item's src attribute. streamProperty (optional) For use with Windows Media files (WMA, WMV, and ASF) only. Specifies one or more file attributes that are displayed in the Windows Media Player when the file is played. The supported attributes are: Abstract Title Author Copyright	`<CdnManifest> <server name="orgsv"> <host name="www.name.com" proto="http" port="80" /> </server> <item-group server="web-server" type="prepos" ttl="300"> <item cdn-url="wild.ram" src="wildlife.ram"/> <item cdn-url="gg.mpeg" src="GoldenGate.mpeg"/> <item cdn-url="jbg.mp3" src="JohnnyBeGood.mp3" /> <item cdn-url="paul.asx" src="fin371k.asx" /> </item-group> </CdnManifest>`
<item-group> </item-group> (continued)	(continued)	ttl (optional) Identifies the period, in minutes, for which the grouped content item should be controlled for changes before release. The default value is 30 minutes. type (optional) Indicates how each grouped content item should be handled. Two options are supported: prepos—Content should be pre-positioned on the hosted domain. This is the default value, which is applied in the event that no type is specified. live—Content is a live broadcast and cannot be pre-positioned.	`<CdnManifest> <server name="orgsv"> <host name="www.name.com" proto="http" port="80" /> </server> <item-group server="web-server" type="prepos" ttl="300"> <item cdn-url="wild.ram" src="wildlife.ram"/> <item cdn-url="gg.mpeg" src="GoldenGate.mpeg"/> <item cdn-url="jbg.mp3" src="JohnnyBeGood.mp3" /> <item cdn-url="paul.asx" src="fin371k.asx" /> </item-group> </CdnManifest>`

Table 3-3: Supported Media File Formats Grouped by Manifest File Content Type

Extension	Supported Formats	Notes
http	Audio Visual Interleaved (AVI) Graphics Interchange Format (GIF) Hypertext Markup Language (HTML, HTM) Joint Photographic Experts Group (JPG) Microsoft PowerPoint (PPT) Microsoft Word (DOC) Motion Picture Experts Group (MPEG, MPG) MPEG Audio Layer 3 (MP3) Portable Document Format (PDF) QuickTime Movie (MOV) ASX	The content item will be handled by an HTTP server; this tag is used for content that cannot be streamed by any of the servers listed in the previous section, for example, Adobe PDF, PostScript (PS), and MPG files.
media	AVI GIF HTML, HTM JPG PPT DOC MPEG, MPG) MP3 PDF	This is the default value used by the Cisco Internet CDN Software. Use the media tag when no playserver is specified to handle a content item; the linked item may be a pre-positioned or a live content item.
qtss	QuickTime (QT) MOV	The content item will be handled by the Apple QuickTime Darwin Streaming Server.
real	RealAudio (RA) RealMedia (RM) RealPix (RP) RealText (RT) Synchronized Container Format (SMIL)	The content item will be handled by RealServer.
wmt	ASF (includes WMA and WMV) ASX	The content item will be handled by Windows Media Services.

Sample Manifest File

Example 3-2 shows a functional manifest file. Use this sample as a model when creating or troubleshooting your own manifest files.

Example 3-2: Manifest File Containing Pre-positioned and Live Content

<?xml version="1.0"?>
<!DOCTYPE CdnManifest SYSTEM "CdnManifest.dtd">
<CdnManifest>
 
<!--playserver mappings for content type-->
<!--these are consulted after URL, item, then item-group mappings-->
<playServerTable>
<playServer name="real">
    <contentType name="application/x-pn-realaudio" />
    <contentType name="application/vnd.rn-rmadriver" />
    <extension name="rm" />
    <extension name="ra" />
    <extension name="rp" />
    <extension name="rt" />
    <extension name="smi" />
  </playServer>
<playServer name="qtss">
    <contentType name="application/qt-foo" />
    <extension name=".mov" />
  </playServer>
<playServer name="wmt">
    <extension name="asx" />
    <extension name="asf" />
    <extension name="avi" />
  </playServer>
<playServer name="http">
    <contentType name="application/pdf" />
    <contentType name="application/postscript" />
    <extension name="pdf" />
    <extension name="ps" />
  </playServer>
</playServerTable>
 
<!--manifest file options-->
<options timeZone="EST" />
 
<!--origin servers -->
<server name="origin-web-server">
  <host name="http://www.cisco.com/media"/>
	 <host name= "192.168.3.15" />
</server>
 
<!--secondary origin server that also runs RealServer -->
<server name= "live-streamer"> 
	 <host name="192.168.3.15" /> 
<server/>
<!--grouped content items-->
<item-group
      server="origin-web-server"
      type="prepos"
      ttl="300">
 <item cdn-url="newHQpresentation.rm" src="newHQpresentation.rm" /> 
  <item cdn-url="animatedlogo.mpg" src="animlogo.mpg" /> 
  <item cdn-url="companytheme.mp3" src="cotheme.mp3" /> 
  <item cdn-url="newHQlayout.avi" src="newHQ.mov" /> 
</item-group>]
 
<item-group
      server="origin-web-server"
      type="prepos"
      ttl="300">
 <item cdn-url="roadmap.asf" src="prodroadmap.asf" /> 
  <item cdn-url="roadmaptalk.wma" src="rmtalk.wma" /> 
  <item cdn-url="newHQlayout.avi" src="newHQ.avi" /> 
</item-group>]
 
<!--non-grouped content items-->
<item cdn-url="q3presentation.rm"
  	src="present/q3presentation.rm"/>
<item cdn-url="q1.smi"
  	src="house/house.smi">
    <contains cdn-url="q1presentation.rm"/>
    <contains cdn-url="q1.rt"/>
  </item>
 
<!--live content-->
<item-group server="live-streamer" type="live">
    <item src="/encoder/live.rm" cdn-url="/present/live/*" />
</item-group>
</CdnManifest>

Validating Manifest File Syntax

Because correct and accurate manifest file syntax is vital to the proper deployment of your web site content on the CDN, Cisco makes a manifest file syntax checker available, at no cost, to its customers. This command-line based utility can be used to proof the manifest files you have created for your hosted domain.

When run, the manifest validator reviews each line of your manifest file, identifying syntax errors where they exist and determining whether or not the manifest is valid and ready for use in importing content to your hosted domain. The results of the manifest validator's review of the manifest file are output to a text file in a location that you name.

Obtaining the Manifest File Validator

The manifest validator is designed to run in both the Windows (95/98, NT, 2000 and XP) environment and the Linux (RedHat 6.2) environments.

Cisco provides the manifest validator utility free of cost through its website, Cisco.com.

To obtain a copy of the manifest validator:

Step 1 Launch your preferred web browser and point it to:

http://www.cisco.com/cgi-bin/tablebuild.pl/cdn-sp

Step 2 When prompted, log in to Cisco.com using your designated Cisco.com username and password.

The Cisco Internet CDN Software download page appears, which lists the available software updates for the Cisco Internet CDN Software product.

Step 3 Locate the file named manifest-validator.zip. This is a ZIP archive containing the files for the manifest validator utility.

Step 4 Click the link for the manifest-validator.zip file. The download page appears.

Step 5 Click the Software License Agreement link. A new browser window will open displaying the license agreement.

Step 6 After you have read the license agreement, close the browser window displaying the agreement and return to the Software Download page.

Step 7 Click the filename link labeled Download.

Step 8 Click Save to file and then choose a location on your workstation to temporarily store the zip file.

Step 9 See the "Installing the Manifest File Validator" section for instructions on installing the validator utility.

Installing the Manifest File Validator

Before installing the manifest validator, you must first install the Java (TM) 2 Runtime Environment, version 1.2 or 1.3 on your workstation. The Java 2 Runtime Environment (JRE) contains the Java virtual machine, runtime class libraries, and Java application launcher. These components are necessary to run the Cisco manifest validator utility.

If you are using an earlier version of the JRE on your workstation, please install either version 1.2 or 1.3. You can download the latest version of the JRE along with instructions for installing it from the following web site:

http://java.sun.com

After you install the JRE, use the following instructions to install, then run the Cisco manifest validator utility:

Step 1 Create a directory for the manifest validator on your local drive. For example:

c:\manifest

Step 2 Locate the manifest validator archive. This file is named manifest-validator.zip and was provided to you by your service provider.

Step 3 Unzip the manifest validator files into the directory you created.

Step 4 Verify that all manifest validator files are present in the manifest directory you created. Table 3-4 contains a list of the sources files that constitute the manifest validator utility and their purpose.

Table 3-4: Manifest Validator Source Files

Validator File Name	Purpose
xerces.jar	syntax parser
manval.zip	standalone manifest validator
CdnManifest.dtd	document type definitions for the CDN manifest file
PlayServerTable.dtd	document type definitions for CDN PlayServerTables, used to define media servers (Real, Windows Media) for the CDN
validate	shell script used to run the validator
validate.bat	batch file to run the validator

Running the Manifest File Validator

After you have installed the Java 2 Runtime Environment and the Cisco manifest validator program files, you are ready to run the validator on a manifest file that you have created.

If you have not created a manifest file yet, see the "Pre-Positioning Web Site Content" section and "Sample Manifest File Scripts."

The manifest file validator can be run in one of two modes:

Default mode —the manifest validator checks the syntax of your manifest file to make sure that source files are named for each content item in the manifest.

Check size mode —the manifest validator checks the syntax of your manifest file to make sure that source files are named for each content item in the manifest, then follows the URL for each content item to verify that the content is placed correctly and, if possible, to determine the size of the item. A special switch (-s) is used to run the validator in "check size" mode.

When running the manifest file validator, you are required to input the following information:

The name and location of your manifest file, expressed either as a network file location <file> or a valid Internet URL <url>

The name and location of the manifest validator's output file <output>.

(Optional.) When running the manifest file validator in check size mode, the length of time <seconds> that the manifest file validator should attempt to confirm the existence of content named in the manifest.

To run the manifest validator utility:

Step 1 If you are running Windows, open a command prompt. Otherwise, proceed to Step 2.

Step 2 Change directories to the program directory for the manifest validator. For example, if you are running Windows, you would enter the following at the command prompt:

C:\>cd manifest
C:\manifest>

Step 3 Run the manifest validator as follows:

If you are running Windows, enter the validate command and provide either a path and file name or URL pointing to your manifest file in the following format:

validate -f [<file> | -u <url>] -o <output> [-s <seconds>]

If you are running Linux, enter the following commands, providing either a path and file name or URL that points to your manifest file in the following format:

chmod u+x validate
validate -f [<file> | -u <url>] -o <output> [-s <seconds>]

After you execute the validator, text output is displayed, which indicates that the validator is running.

Step 4 Wait until the following message is displayed, which indicates that the validator has completed processing the manifest file you pointed to:

Finish parsing /<manifest_file_name>.xml

Step 5 Locate the output file in the location you specified and review it for errors.

The final lines of the manifest file validator's output will indicate whether or not the manifest is valid or not. For example, a valid manifest file output might read:

number of manifest warnings: 1
number of manifest errors: 0
manifest syntax is CORRECT
finish parsing

In this instance, one non-fatal syntax irregularity was located, but the manifest file as found to be syntactically correct. This file could be transferred to your service provider and used to deploy web site content to your CDN.

The output file for an invalid manifest file will list the number of errors and warnings issued. For example:

number of manifest warnings: 1
number of manifest errors: 1
manifest syntax is INCORRECT
finish parsing

See the "Understanding Manifest File Validator Output" section next for detailed information that will help you understand the manifest file validator results.

Understanding Manifest File Validator Output

Your manifest file validator output file will appear in the location you specified (using the -o option) when the validator was run.

Each output file will have a similar structure and syntax and will clearly identify any errors or warning messages stemming from your manifest file syntax. Manifest files are judged by the validator either to be:

CORRECT—possibly containing syntax irregularities, but syntactically valid and ready for deployment on a CDN

INCORRECT—containing syntax errors and unsuitable for deployment on a CDN

Syntax Errors

The manifest file validator issues syntax errors only when the manifest file validator cannot identify a source file for a listed content item—either because it is not listed, or it is listed using improper syntax. All files containing syntax errors are marked INCORRECT.

Syntax errors are identified in the output with the ERROR label. The line number containing the error is provided, as well as the manifest attribute for which the error was issued, valid options, and the default value for that attribute. For example, the following error appears in Example 3-3:

ERROR: japan.xml:13:Skip item because src is not defined.

In this example:

japan.xml is the manifest file name.
13 is the manifest file line number where the error occurs.
src is the manifest file attribute generating the warning.

Example 3-3: Manifest File Validator Output Containing Errors and Warnings

start parsing file japan.xml

start options

 option clearlog: false

 option rd: null

 option prepos-tag: null

 option live-tag: null

 option notFoundUrl: null

 option noRedirectToOrigin: false

 option timezone: JST

 option manifest-id: null

end options

start server

 server name: WMTServer

start host

  host name: origin.cdn-japan.com

  host proto: http

  host port: 80

  host user: ceadmin

  host password: 3kDC

  creating new hash entry for WMTServer and origin.cdn-japan.com

 end host

end server

WARNING: japan.xml:13:Attribute "src" is required and must be 
specified for element type "item".

start item

 item src: null

 ERROR: japan.xml:13:Skip item because src is not defined.

end item

end CdnManifest

number of items processed: 1

number of manifest warnings: 1

number of manifest errors: 1

manifest syntax is INCORRECT

finish parsing

A total number of errors encountered in the manifest file is provided at the end of the validator output file.

Syntax Warnings

The manifest file validator issues syntax warnings for a wide variety of irregularities in the manifest syntax. Files containing syntax warnings may be marked CORRECT or INCORRECT, depending on whether or not syntax errors have also been issued.

Syntax warnings are identified in the output with the WARNING label. In addition to the label, the line number containing the warning is provided, as well as the manifest attribute for which the warning was issued, valid options and the default value for that attribute. For example, the following warning might appear in the output for the japan.xml manifest file:

WARNING: /~content/manifest/japan.xml:12:Attribute "type" with value 
"vod" must have a value from the list "(prepos|live)"

In this example:

japan.xml is the manifest file name.
12 is the manifest file line number where the warning was issued.
type is the manifest file attribute generating the warning.
vod is the offending value.
(prepos | live) are the valid options for that attribute.

A total number of warnings encountered in the manifest file is provided at the end of the validator output file.

Repairing Manifest File Syntax

After you have identified syntax errors and warnings using the output from the manifest file validator tool, you can correct your manifest file syntax, then re-run the manifest file script on the corrected file.

To repair your manifest file:

Step 1 Open your manifest file using your preferred XML- or text-editing tool.

Step 2 Referring to your manifest file validator output, use the line numbers provided by the manifest file validator to locate the syntax violations in your manifest file.

In general, it is a good idea to review each WARNING and ERROR tag in your manifest. Some warnings, while still allowing the manifest file validator to find your manifest file syntax correct, may still be the source of problems when you deploy your web site content.

Step 3 After you have made all necessary corrections for syntax warnings and errors, save your manifest file.

Step 4 Run the manifest file through the manifest file validator again and review the validator output for errors and warnings.

Step 5 Repeat Step 1 through Step 4 until all errors and warnings have been adequately resolved and until the manifest validator labels your manifest file CORRECT.