NCast N-Way Server - Manual (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 de-
encapsulated 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