Subject: [XCON] ViPr scenario

From: "Rosen, Brian" <[email-masked]>
Date: Sun, 9 Jul 2006 15:25:51 -0400

Since the beginning of the xcon effort, I have been trying to make sure
that devices that are not simple endpoints with simplistic media
handling capabilities can be accommodated by the xcon work.  The current
scenarios document has an example of a device that can handle more than
one stream of a given type, but I'd like to describe a real shipping
product that has significantly different capabilities that I believe
xcon media handling should support.

ViPr is a video conferencing device that is end system mixed = there is
no central anything.  The endpoints multicast audio and video streams to
each other.  The signaling meets the xcon assumptions fairly well; there
is a "focus" that has two way sip sessions with each participant (one of
the endpoints takes this role when a conference starts). 

A ViPr can send one large video stream and/or one small video stream.
It can send one audio stream.  A ViPr can receive zero to 4 large video
streams, and zero to 16 small video streams.  It can receive zero to 16
audio streams.  It end system mixes these streams.  In the current
implementation, the size of the conference determines how many streams
are sent, but user interfaces may control which streams.  For example,
in a 4 way conference, each ViPr normally sends one large video stream,
no small video streams, and one audio stream.  It receives 3 large video
streams and 3 audio streams.  In a 12 way conference, a ViPr would
always be sending a small video stream, sometimes would be sending a
large video stream, and would be sending an audio stream.

The focus receives requests from endpoints to direct streams to that
endpoint.  This is most often needed in larger (greater than 4
participants) conferences.  In general, in larger conferences, there are
only 4 large windows, and thus not all participants can be viewed in
large windows.  For conferences from 2-5 participants, each participant
sees all other participants in large windows (but not themselves). For
conferences of 6-17 participants, each participant other than "self" is
seen in a small window, and up to 4 participants appear in large
windows.  Users can select which 4 explicitly, can use "last n speakers"
mechanisms, or moderators can control what appears in any specific large
window.  When a request for a specific stream for a specific endpoint is
received, the focus checks conference policy to see if the operation is
allowed.  If it is, then it determines if the endpoint whose large
stream is needed is already multicasting.  If it is, then it returns a
new SDP to the requesting endpoint informing it of the multicast address
to use for the stream.  If the endpoint whose large stream is needed is
not multicasting (because no one was viewing it prior to the request),
the focus sends it a new SDP to request it to send its stream.  It then
sends a new SDP to the requesting endpoint with the multicast address to
use to receive the stream.  For conferences with more than 16
participants, each endpoint can select which participants it sees in its
small windows (also permitting "last n speakers").  Similar effects
happen for the audio streams.  For conferences of up to 4 participants,
audio streams are always multicast.  For conferences greater than 16
participants, Voice Activity Detection is used to gate sending of
streams.

Most of the documents that have been proposed do not completely handle
the ViPr case, but could reasonably be extended to do so.  We have two
different kinds of video streams, and multiples of them being received.
There are local audio and video mutes, as you would expect, and the
state of those is reflected on the wire to conserve bandwidth.  Since it
is locally mixed, there is no need for "volume controls" on the wire,
nor for any kind of panelization mechanism.  It's just the ability to
turn on and off the multicasting of the streams and receive the
multicast addresses to get the desired streams.

Brian

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon