10. Revision History ........................................................................................................................ 40
NCast Corporation Revision 1.3
Page 3
Page 4
NCast N-Way Reference Manual
1.Introduction
1.1.PURPOSE
The NCast N-Way Reference Manual is intended for the Network engineer who will be tasked with the job of
installing and setting up an N-Way Server. This guide is designed to cover topics in depth and assumes the
reader is familiar with network protocols such as multicast, topics such as webcasting and running of a Linuxbased web server.
1.2.DOCUMENT OVERVIEW
This document is divided into three major sections: introduction to the operation and functionality of an N-Way
Server, instructions on how to configure the server for customer accounts, and configuration of a Telepresenter
for use with N-Way service.
1.3.TERMSAND DEFINITIONS
A complete discussion of network protocols, Internet streaming, webcasting and related topics is beyond the
scope of this document. Other sources cover this material in great detail. The following are brief definitions of
some of the terms used throughout this manual.
AAC – Advanced Audio Coding, a wideband audio encoding and compression algorithm.
IETF – Internet Engineering Task Force, the standards body for Internet protocols.
ISO – International Standards Organization
Latency – The end-to-end time delay between a change in the source image and the
corresponding change in the remotely displayed image.
Lip-sync – The synchronization of independent audio and video streams at a receiving decoder so
that the presentation is in the same time relationship as the source.
MPEG Compression – MPEG is an acronym for Motion Picture Experts Group, an industry-wide
committee that has defined a series of standards for the compression of audio and video source
material.
MTU – The maximum transmission unit is the maximum number of bytes permitted in a
transmitted packet.
Multicast – A family of computer transmission protocols where multiple receivers access a single
transmitted packet stream.
NCCP – NCast Conference Control Protocol provides coordination, control and identification of
participants in a multi-way collaborative conference session.
N-Way – An NCast proprietary service for multicast bridging and webcasting.
RFC – Request for Comments, an Internet protocol standard.
RTSP – Real-Time Streaming Protocol is an IETF approved protocol for control of real-time
streaming on the Internet.
Telnet – An IP network based protocol, which was originally used to connect remote consoles and
terminals to mainframes, but is now used as a general, bi-directional, byte oriented
communications facility. See RFC’s 854 and 855.
Unicast – Refers to a point-to-point connection between two Internet host machines.
NCast Corporation
Revision 1.3
Page 4
Page 5
NCast N-Way Reference Manual
1.4.TELEPRESENTER UNITS
The Telepresenter is a stand-alone network communications appliance which captures RGB (VGA) signals from
a desktop or laptop, compresses the image with an industry standard compression algorithm, packetizes and
transmits the imagery as an internet media stream, receives a media stream from the internet, decompresses the
imagery, and presents the received information to a viewing audience through use of a large-screen computer
(VGA) monitor or via a room projector. Some Telepresenter models also archive the media stream in real-time,
allowing for playback by the recipient at a later date.
The following Telepresenter models are capable of using N-Way services:
Telepresenter S – A small stand-alone unit used primarily for webcasting.
Telepresenter G2 – A rack mounted unit with streaming and archiving capabilities.
Telepresenter M2 – A desktop unit with MPEG-2 video, PCM audio and JPEG graphics.
Telepresenter M2P – A rack mounted unit with streaming, archiving, collaboration and PIP capabilities.
Telepresenter M3 – A rack-mounted unit with streaming, archiving, collaboration, UXGA and PIP
capabilities.
Telepresenter M3 Series 2 – A rack-mounted unit with streaming, archiving, collaboration, WUXGA, HD
and PIP capabilities.
All Telepresenter models share a core operating system and base set of features.
1.5.N-WAY SERVER FUNCTIONALITYAND MODESOF OPERATION
The N-Way Server supports the following major services:
1.5.1.One-to-Many Streaming using RTSP and the Auto Unicast (Announce) Feature
In this configuration a Telepresenter is given the IP address of the server and utilizes a unicast RTP stream to
broadcast directly to the server. The server then “reflects” the streams to clients logged in via RTSP protocol.
The “Auto Unicast (Announce)” facility is a mechanism within the RTSP protocol to automatically provide the
server with the correct SDP media-file information. The server automatically installs an .SDP file for the Session
and client players simply reference that .SDP to begin the connection and begin playing. The .SDP file is also
automatically removed when the Session stops, thus disconnecting any connected clients. The Announce feature
eliminates the need to manually configure and install .SDP files at the server.
NCast Corporation
Revision 1.3
Page 5
Page 6
NCast N-Way Reference Manual
1.5.2.Archive Playback using RTSP
Several models of the Telepresenter allow recording of webcasts or conferences. These files are created as
MPEG media files and stored locally until the file is downloaded and removed from the unit.
A Telepresenter is not designed to be a Video-on-Demand playback server. Continuous playback of captured
files would interfere with the real-time capture and encoding activities of the unit. Nor is there any provision for
backed-up storage of the files. These functions are best done elsewhere in the network.
An N-Way Server is capable of storing archived files and playing them back on demand from its hard-drive. Files
may be uploaded to the server using the automatic FTP upload facilities within the Telepresenter.
There is a configuration page within the Telepresenter to define the FTP server, account and password. The
archived .mp4 file, along with its associated .xml file, can be uploaded immediately after a Session stops, or the
upload can be programmed for later in the day or after business hours when the network will be less busy.
Once the file is residing in the content directory on the server, a simple RTSP link is all that’s needed to play back
the file on demand.
1.5.3.Multicast Bridging
Through the use of N-Way bridging and tunneling protocols, multiple Telepresenters, which are not situated on a
native multicast network, can participate in a conference through the use of the server as a bridge. All the
standard Telepresenter modes of operation (one-way streaming, full-duplex streaming and collaboration mode)
are supported through use of the bridge. The N-Way Server must be located at a network point where multiple
streams (one for each participating unit) can exist and flow without impacting or overloading the network.
Multicast traffic at each end point is forwarded through the tunnel and emerges at the bridge where it is routed to
all participating parties. The simplest conceptual model for this usage is a hub-and-spoke arrangement, where
each remote Telepresenter is at the end of a spoke, and the N-Way Server is the hub located in a high-bandwidth
network operations center.
More complex architectures are possible for special applications (See Chapter 6). If the N-Way Server itself is
located on a multicast network, traffic can flow from the multicast network through the bridge and its tunnels to the
NCast Corporation
Revision 1.3
Page 6
Page 7
NCast N-Way Reference Manual
remote units (but the reverse of that flow is not supported). Also, multicast traffic from the local LAN of each
remote unit maybe forwarded to the bridge. Contact NCast for details on the uses and potential limitations of
network architectures beyond a simple hub-and-spoke arrangement.
In each case, multicast traffic (the media streams) generated by the remote Telepresenter is encapsulated into a
packet which is sent via unicast to the N-Way bridge, where it is unpacked and mixed with all other multicast
streams present at the bridge. The server looks at all the multicast traffic in the mix, and forwards, via the reverse
unicast connection, the media streams desired by a remote unit. Multicast group traffic not requested by a remote
unit is discarded and not forwarded to any remote site.
1.5.4.One-to-Many Streaming using Multicast Bridging and RTSP
In this mode of operation one of the Telepresenters designated as the “Sender” is generating a media stream and
forwarding this stream via a multicast tunnel to the N-Way Server. At the server the media stream packets are deencapsulated and placed onto the local network as a multicast source. A streaming server process running in the
N-Way Server can then accept RTSP protocol requests from remote desktops and forward media streams in the
local multicast mix to the remote clients.
This mode of operation allows many hundreds of viewers (who have only unicast connections) to watch the
encoded output of a single Telepresenter. The N-Way Server must be at a network point where the aggregation
of many unicast streams will not impact functioning of the network.
There is, within each Telepresenter, a similar one-to-many RTSP connection function, and for small groups and
low bandwidth connections the use of an N-Way Server is not required. However, the number of viewers is limited
and it is possible that the sending (encoding) Telepresenter is at a network location where the aggregation of
multiple unicast streams will choke the network connection. In this case, the encoded stream should be tunneled
to a central network point where mass distribution to a large number of clients is workable.
1.5.5.Collaboration Mode Streaming to the Desktop using RTSP
Telepresenters can be used in a special mode called “Collaboration Mode” where each Telepresenter in the
conference can be given floor control in turn, and the other participating units will be viewing the graphics or video
output of the unit, which currently “has the floor”. Thus, the conference coordinator can switch presentations from
a central site to some remote site to allow a remote presenter (a student presenting a report, a foreign workgroup,
a remote knowledge expert, etc.) to speak and be seen by all the participants in the conference. When the remote
presenter is finished, the coordinator continues with his/her presentation from the central site and all the units are
redirected to view the proceedings emanating from the central location.
If this collaborative event is to be viewed by remote desktops, two important technical issues must be resolved.
First, as the source of the graphical or video presentation switches from Telepresenter to Telepresenter, the RTP
stream-id changes with each switch, and most desktop client players are unable to re-sync onto a media stream
with a new and different stream-id. They typically “lock-on” to the first stream-id they find, and ignore media with
all other stream-id’s. The net result is that the viewer sees only media from one presenter, and the picture is
frozen while other presenters have the floor.
Also, in a collaborative conference, each Telepresenter is continuously generating an audio stream, and these
multiple audio streams must be mixed into one sound source somewhere for playback. This function is normally
NCast Corporation
Revision 1.3
Page 7
Page 8
NCast N-Way Reference Manual
handled by each Telepresenter’s audio subsystem, but in the case of a desktop player there is no capability to do
this. So, the server must decompress each incoming audio stream, mix all the streams together, and create a
single outgoing audio stream for the desktops.
Collaboration mode to desktops is fully functional for the M2 series of Telepresenters, but the graphics and audio
components are not currently available for the G2 and M3 units.
1.5.6.One-to-Many Streaming using RTSP and the Auto Unicast (Announce) Feature
In this configuration a Telepresenter is given the IP address of the server and utilizes a unicast RTP stream to
broadcast directly to the server. The server then “reflects” the streams to clients logged in via RTSP protocol.
The “Auto Unicast (Announce)” facility is a mechanism within the RTSP protocol to automatically provide the
server with the correct SDP media-file information. The server automatically installs an .SDP file for the Session
and client players simply reference that .SDP to begin the connection and begin playing. The .SDP file is also
automatically removed when the Session stops, thus disconnecting any connected clients. The Announce feature
eliminates the need to manually configure and install .SDP files at the server.
1.5.7.Archive Playback using RTSP
Several models of the Telepresenter allow recording of webcasts or conferences. These files are created as
MPEG media files and stored locally until the file is downloaded and removed from the unit.
A Telepresenter is not designed to be a Video-on-Demand playback server. Continuous playback of captured
files would interfere with the real-time capture and encoding activities of the unit. Nor is there any provision for
backed-up storage of the files. These functions are best done elsewhere in the network.
An N-Way Server is capable of storing archived files and playing them back on demand from its hard-drive. Files
may be uploaded to the server using the automatic FTP upload facilities within the Telepresenter.
NCast Corporation
Revision 1.3
Page 8
Page 9
NCast N-Way Reference Manual
There is a configuration page within the Telepresenter to define the FTP server, account and password. The
archived .mp4 file, along with its associated .xml file, can be uploaded immediately after a Session stops, or the
upload can be programmed for later in the day or after business hours when the network will be less busy.
Once the file is residing in the content directory on the server, a simple RTSP link is all that’s needed to play back
the file on demand.
1.5.8.Web Server
Finally, an N-Way Server may be used as a web server. An industry-standard Apache web server is provided with
the standard software installation, and this may be configured to run on any interface that is not used for
streaming server access (no port-80 conflicts). The server operator must be familiar with the standard
configuration files utilized by the Apache software.
1.5.9.Administrative Features
Access to N-Way services is organized by accounts, which are defined by the server administrator.
•Each account may be restricted by password and Telepresenter serial number.
•Each account defines a range of multicast addresses permitted for use.
•Each account defines a maximum number of concurrent sessions.
•An account may declare a variable number of access channels for desktop viewing.
•An account creates a list of viewers, each with a separate access password.
•For each account session time and traffic are recorded and may be used for customer billing.
•Real-time web access provides views of current sessions, viewers and traffic.
•System logs are stored in an SQL database for processing on a daily, weekly or monthly basis.
NCast Corporation
Revision 1.3
Page 9
Page 10
NCast N-Way Reference Manual
•Daily, weekly and monthly reports may be generated and emailed to clients.
•Directory based authentication for video-on-demand playback.
NCast welcomes customer feedback and input on these facilities, and will work with clients to add needed
enhancements.
NCast Corporation
Revision 1.3
Page 10
Page 11
NCast N-Way Reference Manual
2.Server Administration
2.1.CONFIGURING N-WAY NETWORK INTERFACES
The first task required for installation of the server is to properly configure the IP interfaces and to supply other
necessary networking information. There are two network interfaces on the server (known as “eth0” and “eth1”)
and these provide the ability to configure the server for two different networks (an inside network and an outside
network, perhaps) or to double the output capacity on a single network through use of parallel interfaces. In any
case, for initial configuration, only the “eth0” interface needs to be set up. This is easily accomplished through
menus on the graphical interface. Log in as “root” (account information for the server is separately supplied) and
bring up the network configuration menu:
Select the interface to be configured “eth0” and supply the usual IP information (DHCP or static IP settings,
netmask and gateway). Also check that the required DNS and Hostname settings are correct. In general, the
server must be on a static IP address as clients will be unable to find the server if a dynamic DHCP address is
used. DHCP service is possible if the DHCP server knows the MAC interface address and assigns a static IP
based on the MAC numbers.
NCast Corporation
Revision 1.3
Page 11
Page 12
NCast N-Way Reference Manual
2.2.HOSTNAME SETTING
The server requires a valid hostname. If not already configured through the above menus, start a terminal session
and enter the hostname command followed by a valid hostname for your network:
hostname nway.server.com
2.3.REMOTE DESKTOP ADMINISTRATION USING VNC
Often the server is located in a centralized Network Operations Center or equipment room and local console
access is either impossible or at a minimum, very inconvenient. A remote desktop facility is available through use
of the VNC protocol (many clients are available for different operating systems). The VNC server is not enabled
by default and must be started through use of the vncserver command. Log in as “root” and from a terminal
session enter:
vncserver
NCast Corporation
Revision 1.3
Page 12
Page 13
NCast N-Way Reference Manual
2.4.FTP UPLOAD ACCOUNTS
A default FTP upload account is configured for the server (see the password information sheet) and any number
of additional user accounts may be added to facilitate upload of archive files from the Telepresenters. For
example, an institution might want to configure a separate account for each Telepresenter in use. Due to
restrictions on FTP upload, it will be necessary to configure the “home” directory of the account as a folder in the
content directory of the streaming server. For example, the “home” directory for the default account is this:
/usr/local/movies/m3
If the “home” direct is elsewhere (i.e. “/home/myftpaccount”) the archived files will not be playable by the
streaming server and must be moved after upload.
2.5.ARCHIVE PLAYBACK
Files that were recorded and archived on a Telepresenter may be uploaded to the server and played back on
demand. The media content directory on the server is located in this directory:
/usr/local/movies
Files placed there (or in sub-directories of this directory) will be available for playback through use of a URL
formatted for RTSP. The following is an example of a properly formatted RTSP link:
rtsp://nway.server.com/m3-archived-file.mp4
Complete details on how to setup client players for RTSP usage is beyond the scope of this manual. See Chapter
7 on “Client Web Page Linkage” for some examples of common methods to solve this problem.
2.6.DEFININGAN N-WAY ACCOUNT
The following sections on Account setup and management are only required if the N-Way multicast bridging
facilities are used. If live streaming and archived playback are the only facilities to be used on the server, this
section and the following may be skipped.
The design of the N-Way Server software was organized so that multiple independent companies, businesses or
organizations would be able to use the same server without interference, conflict or lack of security. To facilitate
this, an account structure was set up which provides the following features:
•Unique multicast addresses for each account, which prohibits accidental or deliberate diversion of media
streams from one company or organization to another.
•Access to the server through password authentication and serial number verification.
•Lists of different program channels and viewers for different accounts.
•Usage and billing information for each account, Telepresenter unit and Viewer.
Consequently, an ISP or service provider may use one server at a central facility to handle the requirements of
multiple customers, organizations, departments or individuals.
NCast Corporation
Revision 1.3
Page 13
Page 14
NCast N-Way Reference Manual
Thus the first step in setting up an N-Way Server is to define what accounts (company, organization, department
or individual) will be required and then for each account prepare the following information:
•Account name and password
•Range of multicast addresses which will be utilized by the account
•Serial numbers of Telepresenters which will use the account
•The list of Viewers (desktop users) who will be able to access the server
•The list of Program Channels (live broadcasts) which Viewers will be able to access
Once this information is available the server administrator can proceed to the step of account creation.
2.7.ACCOUNT CREATION
A new account is created by logging in to the administrative screens of the server, going to the Accounts page,
and clicking on “Add Account”:
NCast Corporation
Revision 1.3
Page 14
Page 15
NCast N-Way Reference Manual
Once all basic information has been entered (see the image below for a completed example) click on the “Add”
button to add the account. The account will be available immediately for use.
2.8.ACCOUNT MODIFICATION
If information about the account needs to be modified in any way, click on the “More” button. All account contents
may be modified from this screen.
2.3.1.Serial Numbers
The “Serial Numbers” field is a comma-separated list of Telepresenter serial numbers. Only units listed will be
privileged to sign into this account.
If the N-Way Server is being run as a service, this allows the service provider to charge for each additional
Telepresenter added to the account.
It also is a method for verifying that a Telepresenter is a valid member of a given account, even if the
Telepresenter forwards the correct account name and password.
2.3.2.Multicast Addresses
This is a comma-separated list of multicast addresses or multicast address ranges to be used by the account. If a
Telepresenter attempts to use a multicast address not in this list the traffic will not be forwarded. Use of the entry
keyword “all” will allow all multicast addresses to be used.
Since the N-Way service may be used by any number of commercial businesses or organizations, it is important
to keep the addresses in use unique to each account. If there is overlap, parties from one organization will be
able to eavesdrop on the conversations and media streams of another organization.
If the address ranges for two organizations overlap, then those two accounts will be able to communicate with
each other on the overlapping addresses.
NCast Corporation
Revision 1.3
Page 15
Page 16
NCast N-Way Reference Manual
The preferred address ranges to use are administratively scoped multicast addresses with the most locally
scoped range available. See the discussion on multicast addresses in the Telepresenter Reference Manual.
2.3.3.Maximum Session Count
The Maximum Session Count limits the maximum number of Telepresenters which may be connected
simultaneously using this account. For a service provider this allows limits on units in use and gives the provider
an opportunity to charge higher fees for larger accounts.
Also, since this limits the number of concurrent sessions, it may be used as a method to restrict the total
bandwidth consumption of the account. Bandwidth usage over the desired level may not be appropriate for the
facilities of the network connection providing the N-Way service.
For simple multicast bridging, no further server entries are required. The account names, serial numbers and
multicast addresses are all that’s needed to connect multiple Telepresenters for streaming or collaboration work.
2.9.ACCOUNT CHANNELS
If part of the N-Way Service requirement is live streaming to desktops, then Account Channels must be created.
An Account Channel defines the multicast addresses to be viewed by the desktop Viewer.
NCast Corporation
Revision 1.3
Page 16
Page 17
NCast N-Way Reference Manual
From the Account Setup page click on the “Edit Account Channel Information” button. Enter a name for the
Channel. This can be the same name as the Channel in use by the transmitting Telepresenter, or be some other
name meaningful to the Viewer, such as “Weekly Meeting” or “Corporate Training 1” or the like.
The Video, Audio, Graphics and NCCP (Conference) multicast addresses listed here must be valid addresses
listed in the account setup page, and must exactly correspond to the multicast addresses in use by the
Telepresenter originating the webcast.
When the Viewer logs into the N-Way Server to view the webcast, they will see “Weekly Meeting” (or whatever
the channel name is) as the hot link to click on to launch their client media player.
2.10.ACCOUNT VIEWERS
Finally, the administrator must enter names and passwords for all the Viewers authorized to view the webcast.
This allows the service provider to register Viewers for pay-per-view events, allows the administrator to delete
Viewing accounts for employees that may have left the company, or allows the content providers to add or cancel
viewing subscriptions to their list of authorized Viewers.
One or more of the Viewers may be designated as an “Administrator” in which case the list of authorized Viewers
and their passwords may be administered by an account representative without the involvement of the server
administrator. It is anticipated that lists of authorized viewers will change frequently, and the server administrator
should not be burdened with these changes.
Viewer account names must be unique, not only within an account, but across all accounts for the server.
Statistics are kept on each Viewer, so time spent on the system can be logged and recorded for billing purposes
or for simply tracking the time each Viewer was engaged with the system.
NCast Corporation
Revision 1.3
Page 17
Page 18
NCast N-Way Reference Manual
Any number of Viewers may be registered to an Account, and there are no restrictions on the amount of viewing
time permitted.
2.11.WEB SERVER CONFIGURATION
The N-Way Server runs an industry standard Apache Web Server to receive requests for administrative functions
and to present Viewers with their logon and Channel screens. Information and documentation on the Apache
Server may be found at this website:
http://www.apache.org
As is usually the case for this server, the configuration information will be located in this file:
/etc/httpd/conf/httpd.conf
Port 80 on this system is reserved for HTTP media streaming, so standard web requests must be directed to an
alternate port. Another alternative is to configure the server with a secondary IP address, which will be used
exclusively for web requests.
Contact NCast for additional help on configuring web server functionality.
NCast Corporation
Revision 1.3
Page 18
Page 19
NCast N-Way Reference Manual
3.Telepresenter N-Way Access
3.1.N-WAY SETTINGS
The following configuration information is only required if N-Way multicast bridging services are to be used. For
simple live streaming, FTP Upload and on-demand playback, these settings are not required. This connection to
the server is not needed.
The use of N-Way bridging services requires that the Telepresenter be enabled for an N-Way connection. This
setting is located on the N-Way menu under the Configuration tab.
The following is an example of the N-Way setup screen:
The Username and Password fields must match the N-Way Server account setup for your organization. The
Primary server field is the domain name or IP address of the N-Way Server to be used. The port setting must
match the port setting configured in the server. A TCP connection to this port on the server must be allowed to
pass any firewalls in use.
The Secondary server field is the domain name or IP address and port of a backup or rollover server, which will
be contacted if the connection to the Primary server fails. All units in a session must be connected to the same
server for communications to function.
After filling in all the required fields the state should be set to “Enabled” and an update done. The web page will
reflect connection status or connection attempts in the “Connection state” line of the page.
If a session is not using the N-Way Server for communication, the state should be “Disabled” as all traffic
generated by the unit will be forwarded to the server whenever a connection is present. This could unnecessarily
clog up the local network connections for the organization.
NCast Corporation
Revision 1.3
Page 19
Page 20
NCast N-Way Reference Manual
g
3.2.CHANNEL MTU SETTINGS
Packets transported through the multicast tunnel are limited to a size that is less than the MTU available for the
network link supporting the tunnel. If the media packet length is kept to the usual MTU size of 1500, packet
fragmentation will occur causing severe performance degradation.
The reduced packet length MTU must be set to 1476 or less for the Channel(s) used in an N-Way supported
session. A good policy is to reserve a set of Channels specifically for N-Way use. The MTU will then be correct
for the tunnel, and the other channels for other sessions will not need to utilize a non-standard MTU size.
MTU
es
chan
Change the MTU fields as shown and update the Channel settings.
3.3.MULTICAST SETTINGS
The multicast addresses entered into the address fields must be within the range of the multicast addresses
authorized for the N-Way account. If they are out of range, communication will be blocked in both directions by
the server.
The use of administratively-scoped multicast address ranges is a good policy for this service. The TTL setting
may be set low, but must be at least 1 or greater.
3.4.OPERATING RESTRICTIONS
There are some restrictions on use of Telepresenters with an N-Way Server:
•Only one Telepresenter may be connected to an N-Way Server from a local LAN segment. Only one
multicast tunnel can originate or terminate on a LAN segment.
•If a Telepresenter is on the same LAN segment as an N-Way Server, it need not use tunneling to join an
N-Way session, and the N-Way connection should be “Disabled”. The Telepresenter and Server will
NCast Corporation
Revision 1.3
Page 20
Page 21
NCast N-Way Reference Manual
communicate with each other using normal multicast broadcasts. The MTU restrictions must be adhered
to in this case as its outbound traffic will be encapsulated by the server.
•Firewalls in the path of an N-Way Server and its clients must allow TCP and UDP traffic on these ports:
oAn initial TCP connection is made from the client to the server on the configured N-Way port,
which is “10201” in the examples of this manual.
oOnce the connection is established, UDP traffic between client and server can be expected on
ports in the range 32000:32999
NCast Corporation
Revision 1.3
Page 21
Page 22
NCast N-Way Reference Manual
4.Information Pages Reference
4.1.SESSION PAGE
The Session Page summarizes the current sessions active on the server and reports the history of Sessions
completed.
The server administrator may check this page to verify what units are currently on-line and active.
Contact NCast for information on how to obtain these statistics in machine-readable form. All Session statistics
are kept by the server in an SQL database that may be accessed in a variety of ways depending on customer
requirements.
4.2.VIEWERS PAGE
The Viewers Page lists which Viewers are currently active and provides a history of Viewers that have been
active. Included is information on the Channel viewed, the time period, and amount of traffic sent to the Viewer.
NCast Corporation
Revision 1.3
Page 22
Page 23
NCast N-Way Reference Manual
Contact NCast for information on how to obtain these statistics in machine-readable form.
4.3.STATISTICS PAGE
The Statistics Page gives an overview of all accounts and their transmission activity.
Monthly customer billings may be generated from the statistics provided.
NCast Corporation
Revision 1.3
Page 23
Page 24
NCast N-Way Reference Manual
4.4.LOGS PAGE
The Logs Page reflects Login-Logout activity on the Server.
Contact NCast for information on how to obtain this report in machine-readable form.
4.5.CONFIGURATION PAGE
The Configuration Page sets up various parameters related to the server end of the multicast tunnel, and a few
other settings needed for internal operations of the server.
The tunnel interface must be specified, particularly if there is more than one Ethernet connection to the server. All
tunnel traffic will be routed via this interface.
The tunnel port is the port on which the server listens for incoming connection requests from remote
Telepresenters. This need only be changed if there is a conflict with some other port used by the system.
The Statistics Update specifies how frequently current operating statistics are logged to the database.
NCast Corporation
Revision 1.3
Page 24
Page 25
NCast N-Way Reference Manual
The Log Level controls the level of detail recorded for each connection and for ongoing traffic. A change in this
value is only required for diagnostic work.
The N-Way Server Start/Stop button controls the activity of the server’s tunneling process. If stopped, all tunnel
connections are broken, and no new sessions may be initiated.
The Converter Start/Stop button controls the activity of the server’s process which creates a unified media stream
in collaboration mode. If this process is not active, streams to desktops from collaboration sessions will not be
available (Note: This functionality is currently available only for the M2 series of Telepresenters).
A small status box in the upper right corner of each web page reports the current status of these two processes.
NCast Corporation
Revision 1.3
Page 25
Page 26
NCast N-Way Reference Manual
5.Server Access
5.1.WEB INTERFACE
Access to the administrative and viewer web pages on the server must use a non-standard HTTP port, typically
“8008” or similar. Standard HTTP port 80 access is used for media streaming and is not available for web service.
Thus, a typical URL for administrative access would look like this:
http://nway.server.com:8008/
For viewer access the URL would be this:
http://nway.server.com:8008/viewer
To assist viewers and administrators easier access to the server, redirect commands may be installed in the
configuration file of the organization’s main web server to eliminate the need for use of a non-standard HTTP port.
The following are example Apache commands for a typical redirection:
The above command redirects administrative access from
http://www.ncast.com/viewer
to
http://nway.server.com:8008/
viewer
5.2.STREAMING SERVER INTERFACE
Access to the administrative web pages for the streaming server use a non-standard HTTP port, “1220”. This port
provides administration of process that controls RTSP streaming, and presents a live update of clients currently
connected to the streaming server. For access, use this URL:
http://nway.server.com:1220
NCast Corporation Revision 1.3
Page 26
Page 27
NCast N-Way Reference Manual
5.3.SECURE SHELL
Normal access to the server will be via secure shell (ssh) or secure file transfer protocol (sftp).
Contact NCast for account names and passwords to access the server.
5.4.PORT USAGE
The following ports are used for RTSP streaming:
•80 - HTTP (TCP)
•554 - RTSP (TCP)
•6970-6999 - used for dynamic UDP broadcast
•7070 - RTSP (TCP)
Firewall administrators must open these ports for successful RTSP connections.
NCast Corporation
Revision 1.3
Page 27
Page 28
NCast N-Way Reference Manual
6.N-Way System Operation – Detailed Examples
6.1.THE N-WAY CLIENT
If the simple multicast bridging arrangement described in Section 1.5 is not used, then a more in-depth
understanding of how the N-Way system works is required, and this chapter provides greater detail on how the
multicast bridge operates and how packet tunnels are created and used.
Within each Telepresenter multiple system processes are running, and when N-Way activity is enabled a new
process called the “N-Way Client” is launched and activated. The figure below shows the activity and packet flow
through the N-Way Client:
When a multicast session is started, the media stream sources (graphics and audio encoding processes)
generate two types of multicast packets. The first type, RTP (UDP) packets contain encoded graphics or audio
material and are shown as brown arrows in the diagram. The second type, IGMP control packets, are requests
sent to routers to “join” a multicast group, and are depicted as black arrows. Since these are multicast packets,
they are routed to all clients on the LAN (shown as a blue horizontal line).
When the N-Way Client launches it sets up a socket (connection to the internet), which allows it to eavesdrop on
all the packet activity into and out of the Telepresenter. The diagram above shows two separate connections to
the Ethernet LAN, even though there is only one physical connection. This is because two separate and
independent sockets are in use, one for the Media Source and one for the N-Way Client.
When the Client sees an IGMP packet with a source address of its own machine, it encapsulates this request and
forwards it to the server with the intention of telling the server “I have Media Source processes here that are
interested in any traffic on the multicast address group contained in this IGMP packet”. The N-Way Server notes
this request and passes the IGMP request to the LAN on which the server resides. An encapsulated IGMP
request is shown in the diagram as a black arrow encased in an orange box.
If the Client sees an RTP (UDP) packet it checks first if the multicast address in the packet is current (an IGMP
join request has been issued for this multicast group) and then it checks if the source address of the RTP packet
is the same as the source address of its own machine. If so, the RTP packet is encapsulated and sent to the
server. An encapsulated RTP packet is shown in the diagram as a brown arrow encased in an orange box.
When the N-Way Client receives an encapsulated packet from the server, it unpacks it and broadcasts it on the
local LAN connection. Only RTP type packets will be received. The packet which is broadcast will be a multicast
NCast Corporation
Revision 1.3
Page 28
Page 29
NCast N-Way Reference Manual
packet with the source address of the originating machine and the TTL value will be set to 1. The media decoding
processes in the Telepresenter (or PCs connected to the local LAN) will receive this packet and determine what
appropriate processing steps are needed.
If the N-Way Client option “Send Local Only” is off, then RTP packets from the LAN with the correct multicast
group address (a “join” is active) will be forwarded as well. This allows media streams from other Telepresenters
on the same LAN to use the tunnel established by this N-Way Client.
If the N-Way Client option “Receive Local Only” is off, then IGMP requests from other Telepresenters on the LAN
will be forwarded to the server. This allows the N-Way Client tunnel to be used to receive multicast traffic on
behalf of other machines on the LAN.
6.2.N-WAY CONNECTIVITY - SENDING
In the diagram below Telepresenter “A” is set to broadcast graphics and audio on some multicast group address.
Telepresenter B and the PC on that LAN will receive these broadcasts directly through multicast packets placed
on the LAN by Telepresenter “A”. If the N-Way Client is enabled, this multicast traffic is encapsulated and sent to
the server as a unicast stream. When the N-Way Server receives these encapsulated messages it processes
each packet in two ways. First, it un-encapsulates the packet and places it on the server’s local LAN as a
multicast packet from Telepresenter A (source address of “A”) with a TTL (time-to-live) value of 1. It also checks
to see what other N-Way connections are active, and if one of them has requested multicast traffic with this
packet’s multicast address, it forward this multicast packet through the tunnel to the requesting Telepresenter.
So Telepresenter “C” receives a copy of the multicast traffic from the server, as does any PC attached to the LAN.
Remote Telepresenters connected to the server will also get the traffic if they previously requested it.
6.3.N-WAY CONNECTIVITY - RECEIVING
In the case where Telepresenter “A” wants to receive traffic from a particular multicast group, it uses the N-Way
Client to forward an IGMP request for that group to the server, which then makes its own request for any multicast
traffic on that group. If there is multicast traffic on the LAN for the group (shown in the diagram as originating from
Telepresenter “C”) then the server picks it up and forwards it as encapsulated packets through the unicast tunnel
to the N-Way Client on Telepresenter “A” which will unpack the RTP messages and place them as multicast
traffic on the LAN of Telepresenter “A” (the TTL is set to 1 and the source address is from Telepresenter “C”).
With this arrangement, all machines on the LAN may receive the multicast traffic from Telepresenter “C”.
NCast Corporation
Revision 1.3
Page 29
Page 30
NCast N-Way Reference Manual
6.4.N-WAY RESTRICTION – SERVERAND CLIENTONTHE SAME LAN
As an example of what might go wrong when these rules are followed, consider the case where a Telepresenter
and the Server are located on the same LAN.
An RTP packet generated by Telepresenter “C” is encapsulated and sent via the unicast tunnel to the Server. The
Server then unpacks this packet and places it on its local LAN (same LAN as Telepresenter “C”). Here’s where a
packet storm begins.
The N-Way Client on Telepresenter “C” sees a multicast packet with a validly joined multicast group, and with a
source address of its own machine. Passing these two tests permits the Client to encapsulate the packet again
and forward it once more to the Server. An endless feedback loop has been created and a packet storm on the
LAN begins, taking down all other traffic on the LAN.
6.5.N-WAY RESTRICTION – TWO TUNNELSONTHE SAME LAN
A second configuration situation, which is automatically prohibited by the server is the case where two
Telepresenters on the same LAN try to establish individual tunnels to the server.
In the diagram below we assume that Telepresenter “A” has established a tunnel (shown as orange
encapsulation packets) and Telepresenter “B” has established a tunnel (shown as yellow encapsulation packets).
Why can this cause a problem?
Let Telepresenter “A” create a media packet which is encapsulated and sent via the unicast tunnel to the server.
This packet is also multicast on the LAN so Telepresenter “B” gets a copy directly from “A” via the LAN. The
Server receives the packet, places it on its local LAN, and notes that Telepresenter “B” has asked for traffic from
this particular multicast address. It encapsulates it for transmission to “B” (the yellow packets) and shortly
thereafter it arrives at “B”. The fact that now a duplicate packet has arrived at “B” is not a serious problem (other
than causing double the traffic on the LAN. The media processing procedures will discard the packet because the
sequence number has already been used.
NCast Corporation
Revision 1.3
Page 30
Page 31
NCast N-Way Reference Manual
But, and here is the difficulty, the N-Way Client at “B” will place the packet onto the LAN with the source address
of Telepresenter “A” and send it out with a TTL of 1. At this point Telepresenter “A” receives the packet, and the
N-Way Client inside “A” determines that a multicast packet with a current group address and a source address of
the local machine has arrived, and therefore should be forwarded up the tunnel to the server. We have now
created a cyclic feedback loop from “A” to the Server to “B” and back to “A”, and the only thing limiting packet flow
will be the maximum bandwidth in the links connecting the Server to the LAN of the Telepresenters.
6.6.N-WAY RESTRICTION – MULTIPLE HOPSFROMTHE LAN
A final comment concerns limitations of traffic flow outside the local LAN. Packets arriving at the Server are
multicast on the local LAN with the source address of the originating machine. Because of rules determining how
multicast distribution networks are set up, this implementation does not allow these packets to flow to a native
multicast network if the Server is situated on one. Only machines connected to the Server’s local LAN will be able
to receive these broadcasts. Consequently, to reinforce this point, the Server sets the TTL of the packet to 1 to
make sure that no forwarding of any type will happen.
The same situation applies to multicast packets arriving at the N-Way Client. These packets cannot be natively
multicast beyond the local LAN, and therefore the TTL is set to 1 as a reinforcement of this condition.
NCast Corporation
Revision 1.3
Page 31
Page 32
NCast N-Way Reference Manual
7.Client Web Page Linkage
7.1.MEDIA PLAYER LINKS
There are three common methods through which a desktop media player receives media streams:
•RTSP – A player makes an RTSP request to connect to the server and receives the media stream under
control of the RTSP protocol.
•Multicast – A player joins a media-stream multicast group and thus receives the media playback.
•HTTP – The player makes an HTTP request to the server and receives the media stream via TCP
protocol.
The mechanisms by which players receive this linkage information varies by the type of protocol used and by the
type of player.
7.2. RTSP LINKS
A media player which supports the RTSP protocol will require a link of the following form to play a media file:
In the case of a live media stream, the link would most likely reference an .sdp file:
rtsp://nway-server.ncast.com/my-stream.sdp
or
rtsp://nway-server.ncast.com:554/my-stream.sdp
If the client is using the NCast Windows Media Player plug-in, this is the required link:
ncrtsp://nway-server.ncast.com/my-stream.sdp
or
ncrtsp://nway-server.ncast.com:554/my-stream.sdp
7.3.MULTICAST LINKS
A media player which will be using a multicast network for delivery of media streams needs to join the appropriate
multicast group for audio and video. The multicast group information is delivered via download of an .sdp file:
One simple method to deliver RTSP linkage information to a Quicktime player is through construction of a special
type of movie called an “RTSP Movie”. With a simple ASCII text editor, create a file “my-rtsp-movie.mov” with the
following single line of information:
Then simply create a link to this movie on the web page:
http://www.ncast.com/movies/my-rtsp-movie.mov
The web browser will create a blank page and then will play the movie.
7.5.LAUNCHING QUICKTIME PLAYER – QTL FILES
To launch a Quicktime Player as an independent entity apart from the web page, the web page must reference a
“.qtl” file containing the following text:
The Player will use the RTSP link information embedded in this file.
7.6.LAUNCHING WINDOWS MEDIA PLAYER – ASX FILES
To launch Windows Media Player as an independent entity apart from the web page, the web page must
reference a “.asx” file containing the following text:
<ASX version = "3.0">
<Entry>
<Ref href="ncrtsp://nway-server.ncast.com:554/my-stream.sdp" />
</Entry>
</ASX>
The Player will use the RTSP link information embedded in this file.
7.7.EMBEDDING QUICKTIME PLAYERINA WEB PAGE
The following HTML code is used to embed a Quicktime movie in a web-page window:
The .mov file referenced above will typically be an rtsptext movie as discussed earlier.
Consult the Quicktime documentation on the Apple website for additional information about the parameters used
and other features available.
NCast Corporation
Revision 1.3
Page 34
Page 35
NCast N-Way Reference Manual
8.Archive Management, Access and Playback
8.1.THE CONTENT DIRECTORY
The streaming server subsystem on the N-Way server stores content in a content directory, and any .mp4 file
or .sdp file to be played or accessed must be in this content directory or in a sub-folder of the top-level content
directory.
The master directory is named:
/usr/local/movies
During live broadcasts .sdp files created with the Announce feature will be found there. The default FTP account
that ships with the server utilizes the following directory as its”home” directory:
/usr/local/movies/m3
When one logs into the server with the default account all files contained in the “m3” folder will be displayed or
accessed.
8.2.MANAGING CONTENT
There are many different methods or tools which may be used to manage archives in the content directory:
•Graphical Interface – Log in as “root” to the server and the desktop will display a file system icon.
Navigate to the content directory by clicking on the directory and file icons.
•Graphical Interface via VNC – If a remote VNC desktop connection has been established, file
management may be accomplished in this manner as well.
•Command Line FTP – Windows and many other systems support command line interfaces where “get”
and “put” commands may be used to transfer files.
•Graphical FTP – There are many different utilities which present the user with a graphical interface to the
FTP subsystem (WinFTP, etc.).
•HTTP Access – An ordinary web browser may be used to view the contents of the archive. Simply enter
an FTP url into the browser: ftp://nway.server.com
•For Windows users one of the easiest ways to manage content is to make the archive a “Network Place”.
Follow these steps:
oFrom the Start Menu, go to “My Network Places”
oClick on “Add a Network Place”
oIn the “Internet or network address” field type ftp://nway.server.com
oWindows will ask for account name and password information
oA folder window will appear with all files listed in the content directory. Use the normal methods
for managing files, such as drag-n-drop, right clicks for rename or deletion, etc. to manage the
content.
or something similar.
NCast Corporation
Revision 1.3
Page 35
Page 36
NCast N-Way Reference Manual
8.3.CONTENT METADATA
When a video (.mp4) file is uploaded from a Telepresenter, an associated meta-data file is uploaded as well. This
file, in XML format, contains useful information about the contents and format of the video file just recorded. Items
such as the Title, Presenter, Description, Duration, Aspect Ratio, etc. are contained in this file and these items
form the basis for indexing the file, for creating RSS or other announcements about the file, and for management
of the file through automatic scripts. Details about the contents of this file may be found in the Telepresenter
Reference Manual. Do not delete these files unless it is absolutely certain that they will not be needed.
<?xml version="1.0" encoding="UTF-8"?>
<archive version=”1.0”>
<filename>20071119-143215-001.mp4</filename>
<title>Weekly update</title>
<presenter>The CEO</presenter>
<description>The CEO’s weekly discussion on the state of the company.</description>
<unit>Telepresenter Room 209</unit>
<channel>Streaming 1</channel>
<start>2007-11-19 14:32:15</start>
<duration>00:30:09</duration>
<timezone>-0800</timezone>
<width>1024</width>
<height>768</height>
<aspect_width>4</aspect_width>
<aspect_height>3</aspect_height>
<main_window>0,0,1024,768</main_window>
<pip_window>0,0,240,180</pip_window>
<bitrate>768</bitrate>
<framerate>30</framerate>
</archive>
8.4.CONTENT PLAYBACK
Normally, links for playback of archived files will be presented to the user on the organization’s website or in an
associated course management system. The N-Way Server, however, also provides a basic utility program for
displaying and linking to content which can be used if other methods are not available or not needed. This
program is called “nwayfiles” and may be reached at this URL:
http://nway.server.com:8008/cgi-bin/nwayfiles.py
This program, when invoked, searches through all content directories (starting at /usr/local/movies/m3) and
presents a search list to the user to assist in selecting which archived files to display:
NCast Corporation
Revision 1.3
Page 36
Page 37
NCast N-Way Reference Manual
Use the dropdown menus to tighten the search criteria, and press “Search” to display all files that meet the
search criteria:
The files found meeting the search requirements are displayed along with the XML metadata, such as Duration,
Title, Presenter, etc. The hot-link under the Windows column will launch Windows Media Player for playback
(requires an MPEG-4 plug-in). The Quicktime links will launch Quicktime, and the Other links present a page with
an RTSP link that may be used to start an RTSP session with some other client (e.g. VLC).
The nwayfiles.py utility is a Python script located in the “/home/nway/httpd/cgi-bin/” directory, and customers
should feel free to alter or adapt this script to suit their needs. A new logo, header text, etc. are easily changed in
the program. One customer used the framework of this program to enter file descriptions and other metadata into
the institutions SQL database for recorded media.
NCast Corporation
Revision 1.3
Page 37
Page 38
NCast N-Way Reference Manual
Security Notice: All files indexed by this program will be displayed and be playable by any viewer who has
access to and chooses to invoke this URL. This script MUST BE REMOVED if security restrictions are to be
enforced.
8.5.PODCASTINGAND RSS
At the bottom of each of the above pages is a small hot-link labeled “RSS”. Right-clicking on this link and copying
the shortcut (URL) into an RSS reader (like iTunes) enables the subscriber to be notified of daily updates to files
on the server. All new “episodes” (recorded archives) will be listed each time the RSS reader does an update,
and the subscriber will have the option to download and play selected files.
The RSS reader can be set for automatic download, and when a client PDA is synced to the PC doing the
download, all recorded sessions or classes will be automatically transferred to the portable. This enables
completely automatic and unattended delivery of presentations and lectures to the user with no manual
intervention required.
NCast Corporation
Revision 1.3
Page 38
Page 39
NCast N-Way Reference Manual
9.References
9.1.MPEG COMPRESSION
ISO 14496-12 - ISO base media file format
ISO 14496-14 - MP4 file format
9.2.PACKET TRANSMISSION
IETF RFC 3550 “RTP: A Transport Protocol for Real-Time Applications”, H. Schulzrinne, et. al., July 2003
IETF RFC 3551 “RTP Profile for Audio and Video Conferences with Minimal Control”, H. Schulzrinne, et. al., July 2003
IETF RFC 3016 “RTP Payload Format for MPEG-4 Audio/Visual Streams”, Y. Kikuchi, et. al., November 2000
IETF RFC 3640 “RTP Payload Format for Transport of MPEG-4 Elementary Streams”, J. van der Meer, et. al., November 2003
IETF RFC 2326 “Real Time Streaming Protocol (RTSP)”, H. Schulzrinne, et. al., April 1998
IETF RFC 2327 “SDP: Session Description Protocol”, M. Handley, et. al., April 1998
9.3.MULTICAST
IETF RFC 1112 “Host Extensions for IP Multicasting”, S. Deering, August 1989
IETF RFC 3171 “IANA Guidelines for IPv4 Multicast Address Assignments”, Z. Albanna, et. al., August 2001
IETF RFC 3180 “GLOP Addressing in 233/8”, D. Meyer, et. al., September 2001
IETF RFC 3138 “Extended Assignments in 233/8”, D. Meyer, June 2001
IETF RFC 2365 “Administratively Scoped IP Multicast”, D. Meyer, July 1998
IETF RFC 2327 “SDP: Session Description Protocol”, M. Handley, et. al., April 1998
NCast Corporation Revision 1.3
Page 39
Page 40
NCast N-Way Reference Manual
10.Revision History
Revision 1.3 – Explanation of configuring network interfaces for the server, hostname setting, remote
desktop administration and FTP upload. New section on Archive Management, Access and Playback.
Description of the “NwayFiles” utility program. Tools for podcasting and RSS.
Revision 1.2 – Information on FTP services and Automatic Unicast (Announce feature). Details on
creating client web pages and RTSP links.
Revision 1.1 – Additional detailed information on operation of the N-Way system in Chapter 6.
Revision 1.0 – Initial revision based on software Release 1.0.
NCast Corporation
Revision 1.3
Page 40
Loading...
+ hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.