<html>

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">


<meta name=Generator content="Microsoft Word 10 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman";}
a:link, span.MsoHyperlink
        {color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {color:blue;
        text-decoration:underline;}
pre
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";}
span.EmailStyle18
        {font-family:Arial;
        color:navy;}
@page Section1
        {size:8.5in 11.0in;
        margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
        {page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=blue>

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>I get excellent image quality from the
Logitech.&nbsp; However, I&#8217;m using Windows XP, Directshow capture interfaces,
and Windows Media compressors/decompressors with the ConferenceXP software, so
there&#8217;s a lot of variance between software implementations.</span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=MsoNormal style='margin-left:.5in'><font size=2 face=Tahoma><span
style='font-size:10.0pt;font-family:Tahoma'>-----Original Message-----<br>
<b><span style='font-weight:bold'>From:</span></b> Darin Oman
[mailto:darin@ucar.edu] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Thursday, August 29, 2002
10:02 AM<br>
<b><span style='font-weight:bold'>To:</span></b> Jay Beavers<br>
<b><span style='font-weight:bold'>Cc:</span></b> ag-tech@mcs.anl.gov<br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [AG-TECH] FW: [AVT]
Multiple IP address scenarios in a multicast environment</span></font></p>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>&nbsp;</span></font></p>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>Jay,<br>
<br>
Just curious - on your PIG with the USB camera, are you having the problem that
I and others have been having with the bluish tint?<br>
<br>
Darin Oman<br>
NCAR<br>
<br>
Jay Beavers wrote:<br>
<br>
</span></font></p>

<pre style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>We're just using standard tower workstations -- a Dell Precision 530 for<br>
instance.&nbsp; For smaller environments, I'm using the smaller form factor<br>
PCs like the mini configuration Precision 340.&nbsp; The holdup there has<br>
been the lack of a good half height AGP video card with multiple video<br>
outs.<br>
<br>
I've finally got a hold of a half height AGP NVIDIA Quadro4 NVS 200<br>
which drives two displays.&nbsp; If you're doing small nodes (1-3 cameras,<br>
1-2 displays), the combination of a Precision 340 with the Quadro4 would<br>
be great -- 2'x2'x4&quot;.&nbsp; For most AG node scenarios though, I'd stick with<br>
the Precision 530.<br>
<br>
We've been trying out laptop portable nodes, but we're still faced with<br>
three problems:<br>
<br>
&nbsp;* Laptops come with 1394, but without power so a clunky external 1394<br>
powered hub with power adapter is needed, or we have to stick with 1 USB<br>
camera (Logitech QuickCam Pro 3000)<br>
&nbsp;* Pushing large amounts of multicast over wireless 802.</span></font></pre><pre
style='margin-left:.5in'><font size=2 face="Courier New"><span
style='font-size:10.0pt'>11a has failed<br>
on our first set of 802.11a equipment (Proxim Harmony).&nbsp; 802.11b is<br>
working OK, but isn't a scalable solution.<br>
&nbsp;* A Gentner XAP-400 et al is a little hard to move around ;-) and the<br>
ClearOne didn't work well enough to replace it.<br>
<br>
The first two aren't showstoppers for laptop deployments, but the third<br>
is.<br>
<br>
&nbsp;- jcb<br>
<br>
-----Original Message-----<br>
From: Jonathan C. Humfrey [<a href="mailto:jch@cs.ucsb.edu">mailto:jch@cs.ucsb.edu</a>] <br>
Sent: Thursday, August 29, 2002 9:02 AM<br>
To: Jay Beavers<br>
Cc: Osland, CD (Chris) ; <a href="mailto:ag-tech@mcs.anl.gov">ag-tech@mcs.anl.gov</a><br>
Subject: RE: [AG-TECH] FW: [AVT] Multiple IP address scenarios in a<br>
multicast environment <br>
<br>
<br>
<br>
Jay,<br>
<br>
Can you tell me what the exact setup of your display machine is?&nbsp; Are<br>
they<br>
rackmount?&nbsp; I have had a real problem with our display machine which<br>
uses<br>
a SuperM</span></font></pre><pre style='margin-right:0in;margin-bottom:12.0pt;
margin-left:.5in'><font size=2 face="Courier New"><span style='font-size:10.0pt'>icro motherboard made for a server and we end up getting a lot<br>
of<br>
loss in the rendering process... we're looking for a rackmount dual<br>
processor machine that will render much more effectively.&nbsp; Any<br>
suggestions?<br>
<br>
Jonathan<br>
<br>
On Thu, 29 Aug 2002, Jay Beavers wrote:</span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>We're using 1394 cameras in addition to analog PCI based capture</span></font></pre></blockquote>

<pre style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>cards.</span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>1394 cameras have many advantages (integrated power, control, and data<br>
cables; higher quality all-digital signal; lower CPU utilization) and<br>
one of them is that realistically you can fit 3 cameras per PCI slot.<br>
In other work at MSResearch that involve camera arrays, they use 5+</span></font></pre></blockquote>

<pre style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>1394</span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>cameras running at 640x480 and software to create one very large,</span></font></pre></blockquote>

<pre style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>highly</span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>detailed image that appears as one virtual large video source.&nbsp; You</span></font></pre></blockquote>

<pre style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>can</span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>see this in the papers on the 'Ring Camera'.&nbsp; This isn't ready for<br>
AG-like scenario trials yet, as it's still in early prototype stage.<br>
<br>
With the continuing march upwards in PC capacity, I don't foresee<br>
multi-node computers as being required by number or quality of video<br>
streams.&nbsp; We're quite happy doing multiple capture and multiple render<br>
streams on our dual P-IV workstations today, and we could easily go up<br>
in capacity over 50% by moving from our 1.7 GHz CPUs to 2.8 GHz CPUs<br>
that are now available (and go from 400 MHz dual channel RD-RAM to 533<br>
MHz dual channel RD-RAM at the same time).&nbsp; We take advantage of the</span></font></pre></blockquote>

<pre style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>CPU</span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>assist provided by cards like the NVIDIA GeForce and the DirectX Video<br>
Acceleration architecture that is part of DirectShow which allows the<br>
graphics card to offload significant portions of the decoding and<br>
rendering.<br>
<br>
We are using multiple computers per node now for pure logistical<br>
reasons.&nbsp; We're using one computer to handle all the A/V traffic, a<br>
wireless Tablet PC to drive PowerPoint with ink, and a laptop as the<br>
administrative/diagnostic console.&nbsp; Our hope is to make the<br>
administrative console needed only for occasional onsite diagnostics<br>
(like adjusting the microphone gain/gating settings for the room) as<br>
operations continues to get simpler.&nbsp; Our admin console used to be on<br>
the A/V node, but we found it is too disruptive to use to have the<br>
operator run over to the A/V node whenever any adjustments need to be<br>
made ;-)&nbsp; We're looking at other solutions, like moving the A/V node</span></font></pre></blockquote>

<pre style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>to</span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>an operations closet or using Mira devices (LCD monitors with Remote<br>
Desktop logic built in) or providing a web-based admin interface<br>
directly on the A/V node to keep the Admin functions integrated on the<br>
A/V node.<br>
<br>
We can make signals from multiple computers 'appear' to be from one<br>
logical place by sending signals from the same CName, at least until</span></font></pre></blockquote>

<pre style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>we</span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>start using SSM and then the IP address becomes important.&nbsp; I don't</span></font></pre></blockquote>

<pre style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>have</span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>a clear concept of whether we would ever use the same CName among more<br>
than one computer.&nbsp; In our scenario, education, we generally give a<br>
'room' CName to the A/V workstation (E.G. <a
href="mailto:MSR-113-1021@Microsoft.Com">MSR-113-1021@Microsoft.Com</a>)<br>
and use a 'professor' CName (E.G. <a href="mailto:DrBob@Washington.Edu">DrBob@Washington.Edu</a>) for the Tablet<br>
PC and an 'operator' CName (E.G. <a href="mailto:JBeavers@Microsoft.Com">JBeavers@Microsoft.Com</a>) for the<br>
operator's console.&nbsp; Strictly speaking, what's a &quot;node&quot; in that design<br>
and what are just &quot;personal&quot; devices?<br>
<br>
&nbsp;- jcb<br>
<br>
-----Original Message-----<br>
From: Osland, CD (Chris) [<a href="mailto:C.D.Osland@rl.ac.uk">mailto:C.D.Osland@rl.ac.uk</a>] <br>
Sent: Thursday, August 29, 2002 7:21 AM<br>
To: Jay Beavers; <a href="mailto:ag-tech@mcs.anl.gov">ag-tech@mcs.anl.gov</a><br>
Subject: RE: [AG-TECH] FW: [AVT] Multiple IP address scenarios in a<br>
multicast environment <br>
<br>
It may not be relevant (I'm not in any sense a network type person)<br>
but I foresee a requirement for more than one capture computer to<br>
be regarded as part of a single node.&nbsp; There are already times when<br>
I would like to put out more than 4 video streams, and I also want<br>
to start to use higher bandwidth links (e.g. 640x480, 800x600 and<br>
1024x768 off computers).&nbsp; There aren't many motherboards with more<br>
than 6 PCI slots, and with one gone on networking, a second video<br>
capture computer that appeared seamlessly in the venue would be a<br>
bonus.<br>
<br>
I don't know whether this requires what you are discussing; if it<br>
doesn't, please ignore!<br>
<br>
Cheers<br>
<br>
Chris Osland<br>
<br>
____________________________________________________________________<br>
Chris Osland&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></font></pre><pre style='margin-left:.5in'><font
size=2 face="Courier New"><span style='font-size:10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Office tel: +44 (0) 1235 446565<br>
Digital Media and Access Grid&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Medialab tel: +44 (0) 1235 446459<br>
BIT Department&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Access Grid room tel: +44 (0) 1235 445666<br>
e-mail:&nbsp;&nbsp; <a href="mailto:C.D.Osland@rl.ac.uk">C.D.Osland@rl.ac.uk</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fax: +44 (0) 1235 445597<br>
<br>
CLRC Rutherford Appleton Laboratory (Bldg. R18)<br>
Chilton, DIDCOT, Oxon OX11 0QX, UK<br>
<br>
[The contents of this email are confidential and <br>
are for the use of the intended recipient only.<br>
If you are not the intended recipient do not take <br>
any action on it or show it to anyone else,<br>
but return this email to the sender and delete your copy of it.]<br>
<br>
<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: Jay Beavers [<a href="mailto:jbeavers@microsoft.com">mailto:jbeavers@microsoft.com</a>]<br>
Sent: 29 August 2002 06:19<br>
To: <a href="mailto:ag-tech@mcs.anl.gov">ag</a></span></font></pre><pre
style='margin-left:.5in'><span class=MsoHyperlink><u><font size=2 color=blue
face="Courier New"><span style='font-size:10.0pt'><a
href="mailto:ag-tech@mcs.anl.gov">-tech@mcs.anl.gov</a></span></font></u></span><br>
Subject: [AG-TECH] FW: [AVT] Multiple IP address scenarios in a<br>
multicast environment <br>
<br>
<br>
FYI, thought I would forward over this discussion I started on the</pre></blockquote>

<pre style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>IETF</span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>AVT mailing list (AVT owns RTP, the transport of AG).<br>
<br>
We're looking into enabling browsing of active participants in Venues<br>
that you're interested in but not joined to, as well as thinking about<br>
tiering multicast traffic between 'important' and 'less important'<br>
streams.<br>
<br>
If anyone on AG-Tech has thoughts in this area, I'd love to hear them.<br>
<br>
&nbsp;- jcb<br>
<br>
-----Original Message-----<br>
From: Colin Perkins [<a href="mailto:csp@isi.edu">mailto:csp@isi.edu</a>] <br>
Sent: Tuesday, August 27, 2002 12:10 PM<br>
To: Jay Beavers<br>
Cc: <a href="mailto:avt@ietf.org">avt@ietf.org</a><br>
Subject: Re: [AVT] Multiple IP address scenarios in a multicast<br>
environment <br>
<br>
Comments inline...<br>
<br>
--&gt; &quot;Jay Beavers&quot; writes:</span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>Scenario 1, Who's Talking?<br>
<br>
An application is using RTP over multicast UDP on an IPv4, IGMPv2<br>
network.&nbsp; When a client subscribes to a multicast group address using<br>
IGMPv2, the client receives all traffic on that multicast group</span></font></pre></blockquote>

<pre style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>address,</span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>including all RTP and RTCP traffic, regardless of sender or port.<br>
<br>
The client application can join any one of 30 available multicast</span></font></pre></blockquote>

</blockquote>

<pre style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>group</span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>addresses.&nbsp; The list of possible multicast group addresses and their<br>
associated details is obtained via a unicast query once at the start</span></font></pre></blockquote>

</blockquote>

<pre style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>of</span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>the client application.&nbsp; The client wants to get some information</span></font></pre></blockquote>

</blockquote>

<pre style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>about</span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>who is in each multicast group, preferably by receiving the RTCP SDES<br>
traffic from each multicast group on port 5005.<br>
<br>
For discussion sake, there are five clients in each multicast group,<br>
each client sending 1 Mb/s of RTP traffic.&nbsp; Each client is assumed to<br>
have at least 10 Mb/s of quality connectivity to an unloaded network<br>
backbone.<br>
<br>
Problem 1:<br>
<br>
If the client application sends a multicast group address join</span></font></pre></blockquote>

</blockquote>

<pre style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>request</span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>for all 30 multicast group addresses, they will receive the RTCP SDES<br>
traffic, but also the RTP traffic from each multicast group.&nbsp; This</span></font></pre></blockquote>

<pre style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>works</span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>out to 30 * 5 * 1 Mb/s = 150 Mb/s of aggregate traffic, vastly</span></font></pre></blockquote>

<pre style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>exceeding</span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>the 10 Mb/s client network capacity.<br>
<br>
Potential Solution 1:<br>
<br>
Are there any thoughts about how to approach this?&nbsp; I hesitate to</span></font></pre></blockquote>

</blockquote>

<pre style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>load</span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>group membership state on a server due to scalability, reliability,</span></font></pre></blockquote>

</blockquote>

<pre style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>and</span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>stale data concerns.</span></font></pre></blockquote>

<pre style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>Valid concerns. If you did choose this approach, a well connected</span></font></pre></blockquote>

<pre style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>group</span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>member could listen to the RTCP and allow SNMP queries (the RTP MIB</span></font></pre></blockquote>

<pre style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>can</span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-right:0in;margin-bottom:12.0pt;margin-left:.5in' wrap=""><font
size=2 face="Courier New"><span style='font-size:10.0pt'>provide SDES information).</span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>Source Specific Multicast wouldn't solve this, as I would need to<br>
subscribe to all sources to receive their RTCP traffic which would</span></font></pre></blockquote>

</blockquote>

<pre style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>also</span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>bring down their RTP traffic unless RTP and RTCP were separated onto<br>
separate IP addresses.&nbsp; I've also wondered if RTCP SDES traffic could</span></font></pre></blockquote>

<pre style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>be</span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>duplicated to one shared multicast group address, the problem being<br>
knowing which SSRCs are associated with which multicast group</span></font></pre></blockquote>

</blockquote>

<pre style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>addresses</span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>(associated by a RTCP APP packet perhaps?)</span></font></pre></blockquote>

<pre style='margin-right:0in;margin-bottom:12.0pt;margin-left:.5in' wrap=""><font
size=2 face="Courier New"><span style='font-size:10.0pt'>Or use two multicast groups per session, one for the data and one for<br>
the<br>
RTCP? </span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>---<br>
<br>
Scenario 2, We're All Equal, But Some Are More Equal Than Others:<br>
<br>
The same application is running, but the number of participants has<br>
increased, perhaps because the conversations are using a lecture or<br>
panel discussion model.&nbsp; Now we have a few (5?) important clients and</span></font></pre></blockquote>

<pre style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>50</span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>less important clients.<br>
<br>
It's decided that the important clients should continue sending the 1<br>
Mb/s of data.&nbsp; Less important clients can send an occasional (every</span></font></pre></blockquote>

</blockquote>

<pre style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>30</span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>seconds) high resolution snapshot as well as 100 kb/s of A/V streams.<br>
<br>
If all data is sent over one multicast group address, the aggregate<br>
network bandwidth is 5 * 1 Mb/s + 50 * 100 kb/s = 10 Mb/s, severely<br>
stretching the network capacity of the clients.&nbsp; The clients would<br>
prefer to receive the streams for important clients and the snapshots<br>
for less important clients.&nbsp; Optionally, the 100 kb/s streams from</span></font></pre></blockquote>

</blockquote>

<pre style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>the</span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>less important clients would be enabled on a stream by stream basis.<br>
<br>
Problem 2:<br>
<br>
Source Specific Multicast has some relevance here, as it could be</span></font></pre></blockquote>

</blockquote>

<pre style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>used</span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>to subscribe to a subset of the less important client A/V streams.<br>
However, the client would still want to receive RTCP and snapshot<br>
information from all clients.<br>
<br>
Potential Solution 2:<br>
<br>
Traffic could be broken into two multicast group addresses again,</span></font></pre></blockquote>

</blockquote>

<pre style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>with</span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>unfiltered traffic (RTCP, RTP snapshots) being on one address and</span></font></pre></blockquote>

<pre style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>source</span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>filtered traffic (RTP A/V streams) being on a separate address.&nbsp; This<br>
would also allow IGMPv2 networks to work, as clients on that network<br>
could subscribe to only the traffic on the unfiltered multicast group<br>
address and lose only the capacity to see A/V streams from the less<br>
important clients.</span></font></pre></blockquote>

<pre style='margin-right:0in;margin-bottom:12.0pt;margin-left:.5in' wrap=""><font
size=2 face="Courier New"><span style='font-size:10.0pt'>You could also run two RTP sessions, one for the &quot;important&quot; clients,<br>
and<br>
one for the rest, each with their own RTCP. The CNAME fields would let<br>
you<br>
relate participants between the sessions.</span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>---<br>
<br>
In both these cases, the solution involves sending RTCP on a separate</span></font></pre></blockquote>

<pre style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>IP</span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>address from its associated RTP streams, which certainly isn't</span></font></pre></blockquote>

<pre style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>mentioned</span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>in RFC 1889 anywhere.&nbsp; Any other thoughts on how to approach these<br>
scenarios?</span></font></pre></blockquote>

<pre style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>See above. I don't have strong objections to sending RTCP on a</span></font></pre></blockquote>

<pre style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>separate</span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre
style='margin-right:0in;margin-bottom:12.0pt;margin-left:.5in' wrap=""><font
size=2 face="Courier New"><span style='font-size:10.0pt'>multicast group to the associated RTP, in the first example.<br>
<br>
Colin</span></font></pre></blockquote>

<pre style='margin-left:.5in' wrap=""><font size=2 face="Courier New"><span
style='font-size:10.0pt'>&nbsp;</span></font></pre>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>&nbsp;</span></font></p>

</div>

</body>

</html>