• Host Name: This is your application’s web address (remove the http://)
• Username: This is your application’s system username
• Password: This is your application’s system password

Login using your FTP Client

While you are installing a Hosted Application, you will be given the option to “Customize your application’s URL”; simply enter in a term that describes your site or your business.  For example, if you are creating a site for Acme Corporation, simply enter “acme” in the “Customize your application’s URL” field.

Secure Shell or SSH is a network protocol that allows data to be exchanged using a secure channel between two networked devices. SSH was designed as a replacement for Telnet and other insecure remote shells, which send information, notably passwords, in plaintext, rendering them susceptible to packet analysis. The encryption used by SSH is intended to provide confidentiality and integrity of data over an unsecured network, such as the Internet.

Getting your SSH/SCP Credentials

You will need the following information:

• Host Name: This is your application’s web address (remove the http://)
• Username: This is your application’s system username
• Password: This is your application’s system password
• Port: 22

SSH

1. Open a terminal (or other SCP client such as PuTTY SCP)

Files

Upload

1. “SCP” files to your server.  In your terminal type in the following information:
   1. scp path/to/yourFile.html <<Username from above>>@<<Host Name from above>>:~/htdocs/path/to/yourFile.html                      <—Hit “Enter” after you’ve entered in this information
      1. In this example, it would be: scp path/to/yourFile.html joomla_8935@joomla-8935-nickhost.app.standingcloud.com:~/htdocs/path/to/yourFile.html
   2. You will be prompted for your password.  Enter it and hit enter.
      1. In this example, it would be ‘nzmyikzgqn‘
2. Your file should now be on your server.

Download

1. “SCP” files from your server.  In your terminal type in the following information:
   1. scp <<Username from above>>@<<Host Name from above>>:~/htdocs/path/to/yourFile.html path/to/yourFile.html                     <—Hit “Enter” after you’ve entered in this information
      1. In this example, it would be: scp joomla_8935@joomla-8935-nickhost.app.standingcloud.com:~/htdocs/path/to/yourFile.html path/to/yourFile.html
   2. You will be prompted for your password.  Enter it and hit enter.
      1. In this example, it would be ‘nzmyikzgqn‘
2. Your file should now be on your local machine.

Folders

Upload

1. “SCP” folders to your server.  In your terminal type in the following information:
   1. scp -r path/to/yourFolder <<Username from above>>@<<Host Name from above>>:~/htdocs/path/to/yourFolder                      <—Hit “Enter” after you’ve entered in this information
      1. In this example, it would be: scp -r path/to/yourFolder joomla_8935@joomla-8935-nickhost.app.standingcloud.com:~/htdocs/path/to/yourFolder
   2. You will be prompted for your password.  Enter it and hit enter.
      1. In this example, it would be ‘nzmyikzgqn‘
2. Your folder should now be on your server.

Getting Started:

Log in to the Media Portal – the security method uses only your registered email address.

Use this format:

http://mediaportal.level3.com

username: your email address

password: your current Level 3 Media Portal password

Site Admin

• Role management
• Access groups
• API keys

Role Management

Confirm the permissions in a role created by Level 3 or create a new “Custom” role and assign permissions to it.

Access Groups

Check the contents of existing groups, create new child groups, assign services and then users to the groups. If a user is not in the system, you can invite them while editing the access group.

API Keys

The Media Portal API provides the ability to request data directly about the CDN services for use in customer’s own processing. This option provides a key used in building authorization for the API requests.

The API provides access to three broad areas:

• Historical reports

• Real-time monitoring

• Self-service ordering and provisioning.

Reports

•  CDN Usage Reports
  

The Usage Reports Dashboard provides an overview of a month’s traffic for each service within the selected access group.

Opening the report: To open this report, select this menu option: Reports->CDN Usage Reports

The Usage Reports now include all services on a single navigational interface. To display a report, you select the access group first, then the service. At the left side of the Usage Reports screen, select the access group you would like to view, then select the product (Caching, Streaming or Storage) and a date range, and then click Go.

You can also view a table of totals for the specified date range for the access group and all the properties within the group:

Select any row in the table to see a time series chart below. Report type tabs at the bottom of the screen provide additional data views for the product.

Service Management

• Content Invalidation

The term ‘Invalidation’ refers to the on-demand content expiration system for caching or streaming resources that is provided by CDN network.

An invalidation request specifies the information for resources that should be refreshed across the network. It is the combination of:

• Caching: Property and Path

• Streaming: Streaming ID and Path

In this feature, you can:

• Submit URLs or Streaming assets for invalidation

• Browse previously-submitted invalidations

• Query the database and check on the status of invalidations

Submitting invalidation requests:

In general, invalidate resources by following these steps:

1. Select the Service Management > Content Invalidation menu option.

2. In the Access Group list on the left side, select the group associated with the resources to be invalidated.

3. Click the New Request link.

4. Select the Invalidation Type to be used for the request:

5. Normal. Issues a GIMS (GET with an If-Modified-Since: header) request the next time the resource is requested (assuming that the resource being invalidated has a Last-Modified: header).

6. Force. Makes an unconditional revalidation on the next request, which causes the resource to be reloaded.

7. Check the Ignore Case box to match URLs in the invalidation request against resources in cache without regard to letter case.

8. Check the Notify when complete box to request that an email be sent to your address when this invalidation is completed.

Note: An email alert is also sent if an invalidation is not complete within 12 hours.In the Property drop-down list, select the property that contains the resources to be invalidated.

You can preclude most of a long list by typing part of the property name.

Both Caching properties and Streaming IDs can be listed in the Property drop-down list if they exist in the access group. Select either.

9. In the Path: field, type the path to the resource on the origin server relative to the web root. A path can be specified as either a complete path (in an abspath style), or it can use one or more wildcard specifications.

10. Click the Submit button.

A confirmation screen displays listing all of the resources and paths to be invalidated.

If the list is correct, click OK.

A success message displays with the invalidation ID, signaling the start of the invalidation process.

Click OK to accept the success message.

Tools

• Caching Real Time Monitoring
• Streaming Real Time Monitoring

Caching Real Time Monitoring

The Media Portal displays a selection of data measures reported in near real time from the edge caching nodes. Snapshots of the data are gathered every five minutes and displayed as part of the totals in a regions table, time series chart and map.

The display is updated every 20 seconds, if new data is available. Data begins to display after the access group is selected and continues to be collected as long as the chart or map is open. The real time data is not stored.

Use the Show Threshold option to display significant changes. When one of the data values increases or decreases more than the Threshold percentage, the value is displayed in another color. For example, an increase over 10% displays in green and a decrease over 10% displays in red.

Streaming Real Time Monitoring

The Media Portal displays real-time reporting from the edge streaming nodes. Snapshots of the data are gathered every 15 to 30 seconds and displayed as part of the totals in the Stream table and the time series displayed in the chart.

The real time data is not stored but you can email or save the contents of the table or chart after the data has been collected.

Edge server sites around the world are proactively configured to meet the real-time usage demands that customers place on web operations.  This flexible capacity model enables greater cost-efficiency in operation, reduces the overall costs of managing websites and improves site performance.  End users receive the constant high-quality web experience they want, resulting in customer loyalty, enhanced brand equity and lower operational costs.

When using Reverse Proxy mode, the customer has a choice in how they create their On Demand stream links. Customers can elect to directly embed the Level 3 provided hostname or they can use their own hostname.

Static portion of the RTMP/MMS link/[DirectoryPath(s)]/file name

Protocol://[Level_3_provided_hostname]/[Level_3_SubscriberID]/[file_name]

e.g. mms://level3mediawm.fplive.net/level3media/directory1/sampleFile.wmv

    mms://video.foo.com/level3media/directoy1/sampleFile.wmv

http://origin.foo.com/directory1/sampleFile.wmv

Customers can directly embed the customer specific hostname as well as any directory path that would be required to access the content at the customer’s origin server. Since Level 3 may not have the content item in its local storage, it will need the pathway to get to the content at the origin server. It is not necessary to embed the origin hostname in the URL path as that information is contained within the Level 3 streaming configuration. If the edge server does not have the content, Level 3 will fetch the content at the customer’s origin Web server using the directory path provided in the end user URL.

Similarly, customers can just as easily delegate a vanity hostname, e.g. video.foo.com, via a CNAME delegation, see Integrating with Internet Traffic Manager, as well as the directory path to that would lead to the media file on the origin server.

The Level_3_provided_hostname is the customer specific Level 3 generated sub-domain from the fplive.net domain.

The Directory Path(s) is location where the file is located on the customer’s HTTP Web server. If the content is located in the root directory, then there should not be any path in the streaming URL.

The file_name is the name of the streaming asset that is to be played.

Integrating with Internet Traffic Manager

Level 3 makes use of its Internet Traffic Manager (ITM) to provide global load balancing capabilities across the streaming platform. The fplive.net hostname is simply pointed to resolve to the ITM platform via a CNAME such that it can provide real-time decision logic on which available Level 3 stream cluster is the closest to the end user. Since the fplive.net hostname is nothing more than an abstraction to the streaming IP addresses, this provides Level 3 with some operational efficiencies to add and remove streaming servers into the platform without the customer having to make any modifications to their streaming links.

Some customers may want to obfuscate the fact that Level 3 is powering their streams. In such instances, customers may wish to create their own vanity streaming hostnames and then CNAME that hostname over to the Level 3 provided hostname. As a reminder, you will need to have a specific vanity hostname per format type. W3C best practices dictate that double CNAMEing is not prudent; however, this practice will not affect most end users and is used quite commonly.

e.g.

video.example.com CNAME 1d examplewms.fplive.net

If using a vanity hostname, the customer will still need to use the Content_Location directory path when constructing their URIs; however, the double CNAME will effectively hide the fact that Level 3 is powering the streams. The media player will only display the customer’s vanity hostname and not display the chased hostname to *.fplive.net back to the media player. NOTE: if an end user were to query the vanity hostname using DIG, the fplive.net domain will be returned in the answer as the nameserver will chase the CNAME in order to return an answer to the end user. Level 3 recommends that customers using their own vanity hostnames use a TTL in their DNS entry of at least 1 day to minimize DNS lookup times for the end user.

Windows Media

The Level 3 streaming platform uses native Microsoft Windows Media Streaming Servers and as such is able to leverage a wide variety of streaming protocols. Customers are free to use whichever protocol they prefer. The most common protocol is mms.

To construct a Level 3 Windows Media streaming link there are five (5) key components:

mms://level3mediawm.fplive.net/level3media/sampleFile.wmv

-or-

rtsp://level3mediawm.fplive.net/level3media/sampleFile.wmv

The Level 3 streaming platform will pass through any optional query string parameters1 that the customer may have embedded into their stream link.

Adobe Flash

As with Windows Media links, constructing a Level 3 Flash streaming link requires five (5) core components; however the integration of these components is different:

Protocol://Level 3 Hostname + Level 3 Subscriber ID + Directory Path + Media Asset

With Flash streaming, the customer must specify the resource location. This is typically the static portion provided by Level 3.

Format:

resource=rtmp://[level3_hostname]/[Level3_SubscriberID] e.g. resource=rtmp://level3mediafs.fplive.net/level3media

Filename includes the customer-added Directory Path structure and the Media Asset (the file name itself). Place the optional file directive before the directory path:

filename= [{optional file directive}:directory path + file name]

where ‘file name’ follows this format: sampleFile.flv

If the directory path is included in the connect string, then use this filename format:

resource=rtmp://[level3_hostname]/[Level3_SubscriberID]/[Directory Path]

filename=[{optional file directive}:file name]

Flash Media service playback is a two-stage process.

• At stage 1, the player connects to the application (resource) on a server. See Adobe Flash Streaming Integration for more information.
• At stage 2, the media asset is played back.

By design, at stage 1 player should use the resource path (rtmp://[level3_hostname]/[Level3_SubscriberID]) and at stage 2 a full path and asset name (directory path + filename). For your convenience, Level 3 Flash Media service also accepts other ways of dividing the RTMP URL but the Level 3_SubscriberID must be always used at stage 1 and the media asset file name at stage 2.

Adobe Flash Helper Directives – Format Type

By default, the Level 3 Flash Media service (FMS) assumes that the streamed file asset is in some form of a FLV file; therefore, it is not necessary to specify the .flv format type in the stream path if the asset is a FLV supported content type. Depending on how the customer’s player is developed, it may still need to denote the .flv file extension, but the streaming URL does not need to include a flv helper directive.

When dealing with H.264 encoded (mp4 and its variants) or mp3 encoded content, it is necessary tell the FMS server that it is dealing with a content item other than FLV supported file. To this end, it is necessary to insert a helper file in the URI path immediately before the file asset name. The helper file is not considered part of the origin path and is extrapolated at the edge Flash Media Server before any backhand pass to the customer’s origin server location so it is not necessary to modify the actual file asset name or directory structure.

The helper directives are expressed in any one of the following supported file formats: flv:, mp3: or mp4:. The default format if unspecified is flv:. Again, it is not necessary to include the flv: file extension in the URI path. Below is an example of the application of the helper directive inserted before the file name.

Streaming URL submitted into the SWF container:

rtmp://level3mediafs.fplive.net/level3media/mp4:hdvideo.mp4 rtmp://level3mediafs.fplive.net/level3media/mp4:anotherhdvideoexample.mov rtmp://level3mediafs.fplive.net/level3media/folder1/mp3:audio.mp3

Path to origin server:

http://origin.foo.com/hdvideo.mp4 http://origin.foo.com/anotherhdvideoexample.mov http://origin.foo.com/folder1/audio.mp3

It is a best practice to have the file extension and file type directive in the URL. This is to ensure that if you have assets that are named the same; the CDN platform knows which asset to retrieve from the origin server. The request to the origin server will make use the of file extension listed in the URL. If there is a format type directive listed but no file extension, the edge FMS box will assume that the file extension is that of the helper directive in the URL path. If the format type directive is not present and your content is H.264 encoded or mp3 encoded, the file may fail to play.

location of the helper directive in the RTMP URL

It’s important to place the helper directive correctly in the RTMP link, especially when the asset is in a subfolder. The helper directive should be passed to the server at the beginning of the media asset string (including the full path).

rtmp://[level3_hostname]/[Level3_SubscriberID]/[helper:]/[full_path_to_asset]

Sample MP4 RTMP link:

rtmp://level3mediafs.fplive.net/level3media/mp4:folder1/folder2/sampleFile.mp4

However, some Adobe Flash players accept a full URL and automatically divide it into two parts. In this case it’s crucial to know how the link is divided to put the helper in the right place. Some players might divide links in the desired way (the helper directive must be placed before the path to the media asset), but it is common to use only the file name at stage 2 (the helper directive must be placed just before the file name). It also might happen that player uses one part of the path at stage 1 and the other part at stage 2, but the helper directive still must be placed at the beginning of the ‘filename’ string used at stage 2. If in doubt, please contact the player application developer to ask which part of the RTMP URL is used at which stage.

Adobe Flash Streaming Integration

Customers can use an Adobe Flash player provided by Level 3 or use one of their own preference. For more information on using the Level 3 player, see Level 3 Media Player Configuration Tool. You can insert the player code in a web page, which then calls the player from a Level 3 server. The code provided by the Media Player Configuration Tool includes this call.

Flash Media Services

The Level 3 streaming platform uses the Flash Media Server 3.0.1 application, which ensures compatibility with the H.264 codec.  From a Live Flash streaming codec standpoint, customers may elect to use either On2’s VP6 codec or the new MPEG-4 based H.264 codec.  Most customers will opt to use either the On2 Flix software, available for a nominal fee directly from On2, or Adobe’s Flash Media Encoder, which is freely available for commercial use.

Flash Media – High Level Workflow Process for Live  Push-Based Streaming

Step 1: Customer Pushes Content to Level 3 Flash Publishing Point

The customer pushes the live event via their Flash Media Encoder to a Level 3 Flash Publishing Point. Level 3 will provide a URL where the end user can push the stream to and subsequently an URL which the customer can embed into their Flash player distributed to their end users.

Step 2: End User Requests Live Flash Stream

End users are directed to the closest available Level 3 edge Flash streaming server by way of the provided Level 3 stream link.

Step 3: Level 3 Flash Server Subscribes to Live Feed

The Level 3 edge Flash Media Server (FMS) will subscribe to the Level 3 FMS Publishing Point server used to acquire the live signal feed.  If the edge server is already subscribed to the live feed, it will not have to re-subscribe to the live feed.

Step 4: Deliver the Live Flash Stream

Once the Level 3 edge FMS receives enough information to fill its buffer, it in turn will begin playback to the end user within the customer’s Flash player.

Multipoint Publishing

The Level 3 Live Flash streaming service has been designed to pull the live feed from the customer’s Flash Media Server- also known as Multipoint Publishing.  Adobe’s Flash Media Development server is available free of charge from Adobe and can be commercially be used to support live signal acquisition.  Under this scenario, the Flash Media Server Developer server can be used as a local Flash Publishing Point. The benefit of using Multipoint Publishing is that it provides the customer flexibility and scalability to their streaming application.  As with the live Windows Media workflow, the customer’s Flash Media Server must be available to Level 3 on an publicly available IP address.

Currently, Level 3 does not allow customers to deploy any customer specific server-side code on the Level 3 Flash streaming servers nor inject any data messages into the outbound stream.   Sometimes, customers will want to insert information into the Flash stream to support advertising, tracking beacons, or SWF interactivity.  By using Multipoint Publishing, it allows the customer to insert custom information into the live Flash data feed.  For these reasons, Level 3 strongly recommends Multipoint Publishing as the main method of live Flash signal acquisition.

Flash Multipoint Publishing Streaming – Live Streaming Workflow

Step 1: Customer Pushes Content to Internal Flash Media Server

The customer pushes the live event via their Flash Media Encoder to a local Flash Media Server machine.  The customer’s Flash Media Server must be exposed via a publicly addressable IP address.

Step 2: Level 3 Acquires Live Signal Feed

Level 3’s streaming service will acquire the live Flash feed by initiating a pull from our Flash Media Server(s).  In the case where there is a primary and a backup feed, Level 3 will use disparate server locations to ensure diversity.  Level 3 will provide the customer with a URL which the customer can embed into their SWF file where end users can retrieve the live stream feed from the Level 3 streaming network.

Step 3: End User Requests Live Flash Stream

End users are directed to the closest available Level 3 edge Flash streaming server by way of the Level 3 provided stream link.

Step 4: Level 3 Flash Server Subscribes to Live Feed

The Level 3 edge Flash Media Server (FMS) will subscribe to the Level 3 FMS Publishing Point server used to acquire the live signal feed.  If the edge server is already subscribed to the live feed, it will not have to re-subscribe to the live feed.

Step 5: Deliver the Live Flash Stream

Once the Level 3 edge FMS receives enough information to fill its buffer, it in turn will begin playback to the end user within the customer’s Flash player.

Flash Media Encoder Publishing (Limited Availability)

Not all customers have the ability or need to establish a Multipoint Publishing workflow.  In recognition of this, Level 3 can support a workflow where the customer can directly push their content to a Level 3 FMS Publishing Point without having to stand up their own FMS Publishing Point.  Customers using this method of live signal acquisition cannot inject their Flash streams with metadata unless it is done via their Flash encoder.  At this time, push-based signal acquisition for Flash is in Limited Availability meaning that we are supporting only a limited number of Flash Publishing Points.  Please consult your account representative if you wish to explore using this ingest option.

Flash Media – High Level Workflow Process for Live  Push-Based Streaming

Step 1: Customer Pushes Content to Level 3 Flash Publishing Point

The customer pushes the live event via their Flash Media Encoder to a Level 3 Flash Publishing Point. Level 3 will provide a URL where the end user can push the stream to and subsequently an URL which the customer can embed into their Flash player distributed to their end users.

Step 2: End User Requests Live Flash Stream

End users are directed to the closest available Level 3 edge Flash streaming server by way of the provided Level 3 stream link.

Step 3: Level 3 Flash Server Subscribes to Live Feed

The Level 3 edge Flash Media Server (FMS) will subscribe to the Level 3 FMS Publishing Point server used to acquire the live signal feed.  If the edge server is already subscribed to the live feed, it will not have to re-subscribe to the live feed.

Step 4: Deliver the Live Flash Stream

Once the Level 3 edge FMS receives enough information to fill its buffer, it in turn will begin playback to the end user within the customer’s Flash player.

Integrating with Internet Traffic Manager

Level 3 makes use of its Internet Traffic Manager (ITM) to provide global load balancing capabilities across the streaming platform.  The fplive.net hostname is simply pointed to resolve to the ITM platform via a CNAME such that it can provide real-time decision logic on which available Level 3 stream cluster is the closest to the end user.  Since the fplive.net hostname is nothing more than an abstraction to the streaming IP addresses, this provides Level 3 with some operational efficiencies to add and remove streaming servers into the platform without the customer having to make any modifications to their streaming links.

Some customers may want to obfuscate the fact that Level 3 is powering their streams.  In such instances, customers may wish to create their own vanity streaming hostnames and then CNAME that hostname over to the Level 3 provided hostname.  As a reminder, you will need to have a specific vanity hostname per format type.  W3C best practices dictate that double CNAMEing is not prudent; however, this practice will not affect most end users and is used quite commonly.

e.g.

video.example.com  CNAME 1d examplewms.fplive.net

If using a vanity hostname, the customer will still need to use the Content_Location directory path when constructing their URIs; however, the double CNAME will effectively hide the fact that Level 3 is powering the streams.  The media player will only display the customer’s vanity hostname and not display the chased hostname to *.fplive.net back to the media player.  NOTE: if an end user were to query the vanity hostname using DIG, the fplive.net domain will be returned in the answer as the nameserver will chase the CNAME in order to return an answer to the end user.  Level 3 recommends that customers using their own vanity hostnames use a TTL in their DNS entry of at least 1 day to minimize DNS lookup times for the end user.

Reverse Proxy Mode

When the Level 3 platform is working in reverse proxy mode, the streaming platform will actively draw the content onto the streaming platform from a customer’s Web server when content requests are made.  This offers the advantage of not having to hand over the entire asset library over to Level 3, immediate access to new content, as well as a more simplified workflow.  The con against using a reverse proxy is that upon an initial request, the first user’s response time will be slower as the content does not already reside on the local media server- the content needs to be retrieved first.  On subsequent end user requests for the same streaming asset, the content is already resident on the edge; therefore, there is no performance lag. For most streaming content, there is more than a 1:1 delivery relationship, hence the initial performance lag is more than outweighed by the more simplified workflow and cost savings of not having to pay for additional storage on the Level 3 platform.

When using reverse proxy mode for On Demand streaming, the content must be exposed via a customer HTTP Web server.  As an alternative, customer may elect to use Level 3’s Origin Storage product for hosting media files.  The Level 3 edge media server will fetch the content via an HTTP request and draw the assets onto the platform using a just-in-time methodology.  The Level 3 edge server does not need to receive the entire asset in order to stream the content.  Once the edge server fills its buffer up enough to start playback, it will begin to stream the file to the end user.

Reverse Proxy – High Level Workflow process for On Demand streaming

Step 1: End User Requests for Stream Asset

The customer will embed the On Demand stream link within a Web page or directly request the media asset via an external stand alone player.  The end user request is directed to a Level 3 streaming media sever.

Step 2: Fetching the Asset from the Origin Server

In the event that the Level 3 streaming media server does not have the content locally, it will initiate an HTTP request to the customer’s origin Web server to get the content.  Alternatively, the customer can elect to use Level 3’s Origin Storage in lieu of their own Web server.

Step 3: Stream the Asset

Once the Level 3 streaming server receives the rich media asset, it begins to play back the stream for the end user.

Forward Proxy Mode

In forward proxy mode, the customer actively pushes their entire content library to the distribution platform and is made available to the Level 3 streaming servers.  The net effect is that your content is actively deployed throughout the entire network and is immediately available upon an end user request.  By prepositioning content at the edge servers, the end user response is faster for the first initial request as the content is already resident.  The downside of using the On Demand platform in forward proxy mode is that the entire content library consideration set must be provided to Level 3 in advance of any end user request – leading to additional storage charges.

Forward Proxy – High Level Workflow process for On Demand streaming

Step 1: Upload content

Content is uploaded to one of two Level 3 FTP staging servers.  To ensure ingress availability, Level 3 provides customers with a primary and a secondary staging location.  Either location may be used to transfer content to the streaming platform.  NOTE: It is not necessary to publish content to both FTP staging points.

Step 2: Replication of content

As customers FTP content to the Level 3 streaming staging servers, it is automatically replicated across the entire Level 3 streaming platform.  Customers do not need to do anything to trigger content replication- this is automatically handled by the Level 3 ingest locations.  Changes to the content repository are checked every five (5) minutes and replicated to the edge streaming clusters; however, depending on system load and batch cycles it make take longer for content to replicate system wide.

Step 3: Embed Level 3 streaming link

Once your streaming content is uploaded to the Level 3 customer staging location, customers need to generate the On Demand streaming links.  The stream links can be directly embedded into an HTML page or the media player directly using a customer specific hostname generated by Level 3.  See Creating On Demand Stream Links for more details on how to construct Level 3 streaming links.

Step 4: Directing end user to Level 3 streaming clusters

End users are directed to the Level 3 streaming platform via a customer specific hostname.  This hostname is specific to a streaming media format.  The streaming hostname that Level 3 provides customers is powered by Level 3’s global load balancing service called Internet Traffic Manager (ITM). The ITM service helps ensure that end users are directed to the nearest streaming cluster.

File Format Support

Level 3 supports many of the common streaming file types. The charts below illustrate the formats Level 3’s streaming service can deliver.

Windows Media

Adobe Flash

Level 3’s Flash delivery service supports the following file formats:

After a while you will get a lot of information at the bottom of the page.